Le Problème
Faire tourner un grand modèle de langage (LLM) localement coûte cher. Un GPU avec suffisamment de VRAM pour faire tourner un modèle de 35B coûte plusieurs milliers de dollars. Les API Cloud sont pratiques, mais vous payez au token, vos données transitent par les serveurs de quelqu'un d'autre, et vous n'avez aucune flexibilité sur le modèle ou sa configuration.
En même temps, des plateformes cloud gratuites de GPU comme Google Colab et Kaggle existent — mais les utiliser comme un véritable serveur LLM n'est pas simple. Les sessions expirent, les navigateurs doivent rester ouverts, les modèles doivent être retéléchargés à chaque fois, et des outils comme Ngrok coupent les longues connexions HTTP, ce qui casse le streaming de tokens.
L'objectif était simple : faire tourner un puissant LLM multimodal open source sur un GPU gratuit, l'exposer comme une API standard, et s'y connecter depuis n'importe quelle machine — sans se battre avec les limitations de la plateforme à chaque session.
La Solution
L'installation utilise trois outils fonctionnant ensemble :
Kaggle comme hôte GPU — T4 x2 gratuit (30 Go de VRAM combinés), jusqu'à 12 heures par session, 30 heures de GPU par semaine. Assez pour faire tourner Qwen3.6 35B entièrement sur GPU sans besoin de mode hybride.
llama.cpp comme moteur d'inférence — le binaire natif, pas un wrapper. Il donne un contrôle précis sur le déchargement (offloading) des couches GPU via -ngl, expose un serveur HTTP standard compatible OpenAI, et gère nativement l'entrée multimodale via un fichier projecteur de vision séparé (mmproj).
Cloudflare Quick Tunnel pour l'URL publique — aucun compte requis, aucune limite de requêtes, et aucun timeout sur les longues connexions HTTP. Ce dernier point est crucial : le niveau gratuit de Ngrok coupe les réponses en streaming, ce qui le rend inutilisable pour le streaming de tokens LLM.
Le modèle est Qwen3.6-35B-A3B, quantifié en 4-bit par Unsloth (UD-Q4_K_XL, ~22 Go). Il supporte l'entrée multimodale (texte + images) et un mode de pensée hybride qui peut être activé par requête sans redémarrer le serveur.
Étapes de Mise en Œuvre
1. Stockage persistant du modèle
Le premier problème à résoudre était le retéléchargement de 22 Go à chaque session. La solution : télécharger le modèle une seule fois depuis HuggingFace directement sur les serveurs de Kaggle en utilisant snapshot_download avec des filtres pour ne récupérer que les deux fichiers nécessaires — le modèle principal et le projecteur de vision mmproj. Les deux sont sauvegardés en tant que Dataset Kaggle privé, monté en lecture seule en moins de 10 secondes lors de chaque session ultérieure.
2. Binaires llama.cpp persistants
Compiler llama.cpp à partir des sources avec le support CUDA prend environ 26 minutes. Exécuter cela à chaque session n'était pas acceptable. Même approche que pour le modèle : compiler une fois, sauvegarder les binaires (llama-server, llama-cli, llama-mtmd-cli) et leurs bibliothèques partagées (fichiers .so) comme un second Dataset Kaggle.
Cette étape posait un problème peu évident : llama-server est lié dynamiquement à libllama-common.so. Copier uniquement le binaire sans ses fichiers .so provoque un crash immédiat avec l'erreur cannot open shared object file. La solution a été de collecter tous les fichiers .so de l'arbre de compilation et de les inclure dans le dataset, puis de définir LD_LIBRARY_PATH=/kaggle/working avant de lancer le serveur.
3. Correction du lieur (linker) CUDA pour Kaggle
Le standard cmake -DGGML_CUDA=ON échoue sur Kaggle avec :
/usr/bin/ld: cannot find -lCUDA::cuda_driver
Le vrai libcuda.so sur Kaggle se trouve dans /usr/local/nvidia/lib64/ (le point de montage du pilote GPU), et non là où cmake cherche par défaut. La solution est un lien symbolique :
ln -sf /usr/local/nvidia/lib64/libcuda.so /usr/local/cuda/lib64/libcuda.so
Combiné avec -DCMAKE_PREFIX_PATH=/usr/local/nvidia et -DCMAKE_CUDA_ARCHITECTURES=75 (T4 = sm_75), cela produit une version CUDA fonctionnelle.
4. Vérification de l'état (health check) au démarrage du serveur
llama-server renvoie un HTTP 200 avec {"status": "loading"} pendant que le modèle charge, et un HTTP 200 avec {"status": "ok"} uniquement lorsqu'il est vraiment prêt. Vérifier uniquement le code de statut fait apparaître le serveur comme prêt avant qu'il ne le soit réellement. La vérification correcte attend que r.json().get("status") == "ok".
5. Mode de pensée par requête
Qwen3.6 supporte un mode de pensée hybride où le modèle raisonne étape par étape avant de répondre. Ceci est contrôlé via chat_template_kwargs passé dans le corps de la requête — et non comme un flag au démarrage du serveur. Cela signifie que le même serveur en cours d'exécution gère les deux modes selon ce que le client envoie :
# Mode direct
extra_body={"chat_template_kwargs": {"enable_thinking": False}}
# Mode pensée
extra_body={"chat_template_kwargs": {"enable_thinking": True}}
Pas de redémarrage nécessaire. Deux terminaux, deux modes, un seul serveur.
6. Script client
Un petit client CLI chat.py gère l'historique des conversations, l'entrée d'images via /image path/to/file, et le basculement du mode de pensée via --thinking. Il ajuste automatiquement temperature et top_p selon les recommandations officielles d'Unsloth pour chaque mode.
Défis
Le problème du type de GPU Kaggle. L'API de Kaggle (kaggle kernels push) ne peut pas spécifier le type de GPU de manière programmatique. Pousser une nouvelle version de kernel alloue toujours le GPU disponible par défaut — souvent un P100 au lieu du T4 x2. Il y a une demande de fonctionnalité ouverte pour cela, mais aucune solution de contournement n'existe via la CLI. La seule solution est d'ouvrir le notebook Kaggle dans un navigateur une fois par session, de sélectionner manuellement le GPU T4 x2, et de cliquer sur Run All. Tout le reste est automatisé.
La chaîne de dépendances des .so. La première version du dataset de binaires ne contenait que les exécutables. Le serveur crashait immédiatement à chaque lancement avec une erreur de bibliothèque partagée manquante. Retracer tous les fichiers .so produits par la compilation et les inclure dans le dataset, combiné à la définition de LD_LIBRARY_PATH à la fois dans l'environnement Python et le sous-processus lancé par Popen, a pris plusieurs itérations pour fonctionner.
Gestion de l'URL de session. L'URL de Cloudflare Quick Tunnel change à chaque session. Pour la rendre récupérable sans garder le navigateur ouvert, le notebook du serveur écrit l'URL dans /kaggle/working/server_url.txt dès que le tunnel démarre. Ce fichier est accessible via kaggle kernels output depuis la machine locale.
Résultat
La configuration finale démarre en 5 à 6 minutes par session : ~5 secondes pour copier les binaires du dataset, puis le temps de chargement du modèle. Pas de retéléchargement, pas de recompilation.
Le serveur expose une API entièrement compatible OpenAI. Tout client qui fonctionne avec OpenAI fonctionne ici sans modification — Python SDK, LangChain, LlamaIndex, Open WebUI, curl :
from openai import OpenAI
client = OpenAI(
base_url="https://xxxx.trycloudflare.com/v1",
api_key="none",
)
response = client.chat.completions.create(
model="qwen3.6-35b-a3b",
messages=[{"role": "user", "content": "Hello!"}],
)
Avec une image :
response = client.chat.completions.create(
model="qwen3.6-35b-a3b",
messages=[{
"role": "user",
"content": [
{"type": "text", "text": "What is in this image?"},
{"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
]
}],
)
Le projet est open source. Tous les notebooks sont documentés cellule par cellule, et le README couvre chaque client et cas particulier.
GitHub: https://github.com/Tahsine/kaggle-llm-server
The Problem
Running a large language model locally is expensive. A GPU with enough VRAM to run a 35B model costs several thousand dollars. Cloud APIs are convenient, but you pay per token, your data goes through someone else's servers, and you have no flexibility over the model or its configuration.
At the same time, free cloud GPU platforms like Google Colab and Kaggle exist — but using them as a proper LLM server is not straightforward. Sessions expire, browsers need to stay open, models need to be re-downloaded every time, and tools like Ngrok cut long HTTP connections which breaks token streaming.
The goal was simple: run a powerful open-source multimodal LLM on a free GPU, expose it as a standard API, and connect to it from any machine — without fighting with the platform's limitations every session.
The Solution
The setup uses three tools working together:
Kaggle as the GPU host — free T4 x2 (30GB VRAM combined), up to 12 hours per session, 30 hours of GPU per week. Enough to run Qwen3.6 35B fully on GPU with no hybrid mode needed.
llama.cpp as the inference engine — the native binary, not a wrapper. It gives precise control over GPU layer offloading via -ngl, exposes a standard OpenAI-compatible HTTP server, and handles multimodal input natively via a separate vision projector file (mmproj).
Cloudflare Quick Tunnel for the public URL — no account required, no request limits, and no timeout on long HTTP connections. This last point is critical: Ngrok's free tier cuts streaming responses, which makes it unusable for LLM token streaming.
The model is Qwen3.6-35B-A3B, quantized to 4-bit by Unsloth (UD-Q4_K_XL, ~22GB). It supports multimodal input (text + images) and a hybrid thinking mode that can be toggled per request without restarting the server.
Implementation Steps
1. Persistent model storage
The first problem to solve was re-downloading 22GB at every session. The solution: download the model once from HuggingFace directly onto Kaggle's servers using snapshot_download with pattern filters to grab only the two necessary files — the main model and the mmproj vision projector. Both are saved as a private Kaggle Dataset, mounted read-only in under 10 seconds on every subsequent session.
2. Persistent llama.cpp binaries
Compiling llama.cpp from source with CUDA support takes ~26 minutes. Running this every session was not acceptable. The same approach as the model: compile once, save the binaries (llama-server, llama-cli, llama-mtmd-cli) and their shared libraries (.so files) as a second Kaggle Dataset.
This step had a non-obvious issue: llama-server is dynamically linked against libllama-common.so. Copying only the binary without its .so files causes an immediate crash with cannot open shared object file. The fix was to collect all .so files from the build tree and include them in the dataset, then set LD_LIBRARY_PATH=/kaggle/working before launching the server.
3. CUDA linker fix for Kaggle
The standard cmake -DGGML_CUDA=ON fails on Kaggle with:
/usr/bin/ld: cannot find -lCUDA::cuda_driver
The real libcuda.so on Kaggle lives in /usr/local/nvidia/lib64/ (the GPU driver mount), not where cmake looks by default. The fix is a symlink:
ln -sf /usr/local/nvidia/lib64/libcuda.so /usr/local/cuda/lib64/libcuda.so
Combined with -DCMAKE_PREFIX_PATH=/usr/local/nvidia and -DCMAKE_CUDA_ARCHITECTURES=75 (T4 = sm_75), this produces a working CUDA build.
4. Server startup health check
llama-server returns HTTP 200 with {"status": "loading"} while the model loads, and HTTP 200 with {"status": "ok"} only when truly ready. Checking only the status code causes the server to appear ready before it actually is. The correct check waits for r.json().get("status") == "ok".
5. Thinking mode per request
Qwen3.6 supports a hybrid thinking mode where the model reasons step-by-step before answering. This is controlled via chat_template_kwargs passed in the request body — not as a server startup flag. This means the same running server handles both modes depending on what the client sends:
# Direct mode
extra_body={"chat_template_kwargs": {"enable_thinking": False}}
# Thinking mode
extra_body={"chat_template_kwargs": {"enable_thinking": True}}
No restart needed. Two terminals, two modes, one server.
6. Client script
A small chat.py CLI client handles conversation history, image input via /image path/to/file, and the thinking mode toggle via --thinking. It automatically adjusts temperature and top_p per Unsloth's official recommendations for each mode.
Challenges
The Kaggle GPU type problem. The Kaggle API (kaggle kernels push) cannot specify the GPU type programmatically. Pushing a new kernel version always allocates whatever GPU is available by default — often a P100 instead of T4 x2. There is an open feature request for this, but no workaround exists via the CLI. The only solution is to open the Kaggle notebook in a browser once per session, manually select GPU T4 x2, and click Run All. Everything else is automated.
The .so dependency chain. The first version of the binaries dataset contained only the executables. The server crashed immediately on every launch with a missing shared library error. Tracking down all the .so files produced by the build and including them in the dataset, combined with setting LD_LIBRARY_PATH in both the Python environment and the subprocess launched by Popen, took several iterations to get right.
Session URL management. The Cloudflare Quick Tunnel URL changes every session. To make it retrievable without keeping the browser open, the server notebook writes the URL to /kaggle/working/server_url.txt as soon as the tunnel starts. This file is accessible via kaggle kernels output from the local machine.
Result
The final setup starts in 5–6 minutes per session: ~5 seconds to copy binaries from the dataset, then model loading time. No redownloading, no recompilation.
The server exposes a fully OpenAI-compatible API. Any client that works with OpenAI works here without modification — Python SDK, LangChain, LlamaIndex, Open WebUI, curl:
from openai import OpenAI
client = OpenAI(
base_url="https://xxxx.trycloudflare.com/v1",
api_key="none",
)
response = client.chat.completions.create(
model="qwen3.6-35b-a3b",
messages=[{"role": "user", "content": "Hello!"}],
)
With an image:
response = client.chat.completions.create(
model="qwen3.6-35b-a3b",
messages=[{
"role": "user",
"content": [
{"type": "text", "text": "What is in this image?"},
{"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
]
}],
)
The project is open source. All notebooks are documented cell by cell, and the README covers every client and edge case.