12 novembre 2026 · Équipe VRAMfarm

vLLM, Ollama ou llama.cpp : avec quoi faire tourner votre LLM, et les commandes

Si vous êtes la seule personne à parler au modèle, les trois sont à peu près aussi rapides et c’est Ollama qui demande le moins de travail : une commande d’installation et un ollama run. Si un script envoie 50 requêtes en parallèle ou si dix collègues utilisent le même modèle, vLLM tire de la même carte environ 5 à 10 fois plus de tokens par seconde au total, et l’écart grandit avec la charge. llama.cpp, le moteur dont Ollama est issu, est celui qu’il vous faut quand vous voulez contrôler chaque octet : fichiers de quantification exacts, types de cache, couches qui restent sur le CPU.

Les trois tournent sur un serveur loué avec une image PyTorch vide, et les trois proposent une API compatible OpenAI. Les différences tiennent au batching, aux formats de fichiers et à la façon de gérer la mémoire.

La version courte

Ollama repose sur les mêmes fondations GGML que llama.cpp : leurs formats de fichiers, leurs niveaux de quantification et leur vitesse pour un seul utilisateur sont donc proches. Ce qu’Ollama ajoute, c’est le confort : une bibliothèque de modèles aux noms courts, la détection automatique du GPU, des modèles chargés à la demande. Ce qu’il cache, c’est le contrôle, et vous vous en apercevez le jour où un modèle tourne lentement et où vous devez comprendre pourquoi.

Vitesse : une conversation contre cinquante

Pour une seule conversation, la génération de texte est limitée par la bande passante mémoire : pour chaque nouveau token, la carte relit le modèle entier une fois. Le moteur compte moins que la taille du fichier. D’où un résultat inattendu : vLLM qui sert un modèle 8B dans son BF16 d’origine (16 Go) est plus lent pour un utilisateur qu’Ollama avec un fichier en 4 bits (5 Go), tout simplement parce qu’il lit trois fois plus d’octets par token.

Le batching change la donne. vLLM lit les poids une seule fois pour tout un lot de requêtes et ajoute les nouvelles requêtes au lot en cours à mesure que les anciennes se terminent : le débit total croît presque linéairement avec le nombre d’utilisateurs, jusqu’à épuisement du calcul ou de la mémoire de cache. Fourchettes indicatives pour un modèle 8B sur une RTX 4090, tirées du calcul de bande passante et de retours de la communauté, pas de nos propres benchmarks :

La vitesse pour un utilisateur est largement suffisante sur chaque ligne : on lit à 5 à 8 tokens par seconde. L’écart se creuse avec la charge : un bot de support, un outil interne pour une équipe, ou un traitement par lots qui classe 100 000 descriptions de produits pendant la nuit. Pour ces usages, vLLM est le bon moteur, et le coût par million de tokens montre l’effet sur la facture.

Deux autres moteurs méritent d’être connus. SGLang est une alternative proche de vLLM, avec des formats similaires et un serveur compatible OpenAI, performant sur de nombreuses requêtes qui partagent un long préfixe. TensorRT-LLM tire le maximum des cartes NVIDIA de data center, mais demande plus de configuration. Si vous hésitez entre les trois premiers, vous n’avez besoin ni de l’un ni de l’autre.

Comment chacun gère la mémoire

La plupart des histoires de « c’était lent » et de « ça a planté » viennent de là.

Ollama déborde sur le CPU sans vous prévenir. Si le modèle et son contexte ne tiennent pas, Ollama déplace des couches vers la RAM système et continue à une fraction de la vitesse. Dans notre propre test, Qwen3 32B sur une carte de 24 Go avec un contexte de 32k a envoyé 18 % de ses couches sur le CPU et est tombé d’environ 30 tokens par seconde à 2,5. Lancez ollama ps : la colonne PROCESSOR doit indiquer 100% GPU. Réglez le contexte avec OLLAMA_CONTEXT_LENGTH, et rappelez-vous que OLLAMA_NUM_PARALLEL multiplie le cache : quatre slots parallèles à 8k de contexte demandent le cache de 32k.

llama.cpp fait exactement ce que vous lui dites. -ngl fixe le nombre de couches envoyées sur le GPU (99 veut dire toutes), -c fixe le contexte total, et -np le nombre de slots parallèles qui se le partagent : -c 32768 -np 4 donne à quatre utilisateurs environ 8k chacun. Pour les modèles mixture-of-experts qui ne tiennent pas, --n-cpu-moe garde une partie des poids des experts en RAM système tandis que les couches partagées restent sur le GPU, ce qui fait tourner de gros modèles MoE sur des cartes plus petites à une vitesse utilisable.

vLLM réserve la mémoire d’avance. Par défaut, il prend 90 % de la carte au démarrage et remplit avec du KV cache ce que les poids n’utilisent pas. Il vérifie ensuite qu’une requête au contexte maximal tient, et refuse de démarrer si ce n’est pas le cas ; le message d’erreur indique le plus grand contexte qui tiendrait. Réglez --max-model-len sur ce dont vous avez vraiment besoin, et baissez --gpu-memory-utilization si autre chose doit partager la carte. Le guide CUDA out of memory couvre le reste.

Ollama : commandes de démarrage

Sur un serveur PyTorch vide, dans le terminal Jupyter ou en SSH :

curl -fsSL https://ollama.com/install.sh | sh
OLLAMA_CONTEXT_LENGTH=8192 OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 \
  ollama serve > /workspace/ollama.log 2>&1 &
ollama run qwen3:8b

N’importe quel GGUF de Hugging Face fonctionne aussi : ollama run hf.co/<user>/<repo>:Q4_K_M. L’API écoute sur le port 11434 :

curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" \
  -d '{"model": "qwen3:8b", "messages": [{"role": "user", "content": "Hello"}]}'

Si vous voulez seulement une fenêtre de chat, vous n’avez besoin de rien de tout cela : l’application prête à l’emploi Private ChatGPT installe d’elle-même Ollama, un modèle Qwen3 ou MiMo et Open WebUI, comme l’explique votre propre ChatGPT avec Open WebUI.

llama.cpp : compiler une fois, puis lancer

llama.cpp doit être compilé avec CUDA. L’image du serveur contient le runtime CUDA mais pas le compilateur : installez donc d’abord la boîte à outils de NVIDIA. Elle télécharge quelques Go, qui comptent comme du trafic, et la compilation prend 5 à 15 minutes :

wget -q https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
dpkg -i cuda-keyring_1.1-1_all.deb && apt-get update -qq
apt-get install -y -qq cuda-toolkit-12-8 cmake git build-essential
export PATH=/usr/local/cuda-12.8/bin:$PATH

git clone https://github.com/ggml-org/llama.cpp /workspace/llama.cpp && cd /workspace/llama.cpp
cmake -B build -DGGML_CUDA=ON && cmake --build build --config Release -j

Téléchargez ensuite un GGUF et démarrez le serveur avec quatre slots parallèles :

pip install -U huggingface_hub
hf download <user>/<repo>-GGUF <model>-Q4_K_M.gguf --local-dir /workspace/models
./build/bin/llama-server -m /workspace/models/<model>-Q4_K_M.gguf \
  -ngl 99 -c 32768 -np 4 --flash-attn on --host 127.0.0.1 --port 8081

Sur nos serveurs, le port 8080 est occupé par Jupyter, d’où le 8081. llama-server sert l’API de type OpenAI sur /v1 et une page de chat simple à la racine. Si vous comptez réutiliser llama.cpp, gardez le dossier compilé /workspace/llama.cpp dans le dossier enregistré plutôt que de recompiler à chaque fois.

vLLM : une API en deux commandes

pip install "vllm==0.11.0" "transformers>=4.56,<5"   # compilé pour CUDA 12.8
vllm serve Qwen/Qwen3-8B --max-model-len 16384 \
  --host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &

Un simple pip install vllm installe la dernière version avec sa propre build de PyTorch, et à l’automne 2026 cette build cible une version de CUDA plus récente que ce que gèrent les pilotes de nombreuses machines : le moteur ne démarre alors pas. C’est pourquoi la commande ci-dessus fixe vLLM 0.11.0 (PyTorch 2.8, CUDA 12.8), la version qu’utilise notre serveur vLLM ; sur une machine dont la fiche du catalogue indique CUDA 13 ou plus récent, vous pouvez prendre une version ultérieure. Vérifiez la version CUDA affichée avant le lancement ; les incompatibilités entre CUDA et le pilote expliquent comment lire ces chiffres. Le serveur vLLM prêt à l’emploi évite cette étape : vLLM y est installé dans une version adaptée à la machine, et il démarre de lui-même un modèle Qwen 7B. Pour y servir un autre modèle, lancez pkill -f "vllm serve" et démarrez votre propre commande sur le port 8000.

Depuis votre code, utilisez le client OpenAI standard avec votre propre adresse :

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="change-me")
r = client.chat.completions.create(model="Qwen/Qwen3-8B",
    messages=[{"role": "user", "content": "Summarise this ticket: ..."}])
print(r.choices[0].message.content)

Les mêmes lignes, avec une autre URL de base, connectent un bot Telegram, un pipeline RAG ou une application existante écrite pour OpenAI.

Accéder à l’API depuis l’extérieur, et la garder en marche

Un serveur n’a pas d’IP publique à lui ; SSH, Jupyter et les applications passent par notre adresse, avec des ports attribués à ce serveur. Sur le serveur vLLM, le port 8000 est déjà publié, et le tableau de bord affiche l’adresse de l’API. Sur un serveur PyTorch vide, seuls SSH et Jupyter sont publiés : accédez donc à Ollama ou à llama.cpp par un tunnel SSH depuis votre ordinateur, ssh -p <port> -L 8081:localhost:8081 root@<address> (port et adresse sur la fiche du serveur ; le guide de la clé SSH explique comment configurer la clé), puis utilisez http://localhost:8081. Une image Docker personnalisée peut publier son propre port. Docker n’est pas disponible à l’intérieur du serveur, c’est pourquoi toutes les commandes ici installent avec pip ou un script.

Tout ce qui est accessible de l’extérieur a besoin d’une clé. vLLM accepte --api-key, llama.cpp accepte aussi --api-key, et Ollama n’a pas de clé à lui : gardez-le derrière un tunnel.

Démarrez les serveurs de longue durée avec nohup ... & et un fichier de log comme ci-dessus, ou dans tmux (apt-get install -y tmux, puis tmux new -s llm), pour qu’ils continuent quand vous fermez le navigateur ou la session SSH. Ils s’arrêtent avec le serveur : la facturation prend fin dans la minute où vous cliquez sur Arrêter, et le lancement suivant repart d’un disque vierge, à l’exception de ce que vous avez gardé dans le dossier enregistré.