Vos données ne devraient jamais quitter votre machine — voici comment faire tourner un LLM sans cloud en 2026

Janvier 2026, Ollama dépasse les 300 000 étoiles GitHub et devient le moyen le plus cité de faire tourner un LLM sur un poste de travail. Mars 2026, vLLM livre le support natif du speculative decoding et du structured output contraint par grammaire, consolidant sa position de serveur d’inférence de référence en production. Juin 2026, llama.cpp atteint 100 000 commits et supporte plus de 40 architectures de modèles — le tout sans GPU.

Faire tourner un LLM chez soi n’est plus un rite initiatique pour hobbyistes. Trois outils, trois philosophies, et une réalité simple : la bonne solution dépend de votre matériel, pas de vos compétences. Voici ce que chaque outil fait vraiment, avec les chiffres de VRAM et de débit qui permettent de choisir.

Ollama — la simplicité comme fonctionnalité

Ollama est né d’une frustration : docker run un modèle de langage devrait être aussi simple que docker run nginx. En 2026, la promesse est tenue. Une installation en une ligne (curl -fsSL https://ollama.com/install.sh | sh), un ollama pull llama3.3:70b, et un ollama run suffisent à dialoguer avec un modèle.

L’architecture repose sur llama.cpp en backend — Ollama ne réinvente pas l’inférence, il l’empaquette. Sous le capot, il utilise les GGUF quantifiés de la communauté et expose une API REST compatible OpenAI (/v1/chat/completions) qui permet à n’importe quel client compatible — Open WebUI, Continue.dev, Cursor — de s’y brancher sans configuration. Le système de Modelfile (ollama create) permet de versionner un prompt système, des paramètres et un modèle de base dans un fichier unique, reproductible.

Les limites sont connues et assumées. Ollama charge un seul modèle à la fois en mémoire — pas de batching concurrent, pas de continuous batching. Le parallélisme GPU est basique : répartition par couches entre plusieurs GPU, sans tensor parallelism au sens strict. La latence est acceptable pour un utilisateur unique (25 à 50 tokens/seconde sur un Llama 3.3 70B Q4_K_M avec une RTX 4090 24 Go), mais s’effondre dès qu’on sert plusieurs requêtes simultanées.

Le cas d’usage canonique d’Ollama : le développeur qui veut un assistant de code local sur sa machine, ou le testeur qui évalue un modèle avant de le déployer ailleurs. L’outil excelle quand le nombre d’utilisateurs est égal à un.

# Installer Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Télécharger et exécuter un modèle
ollama pull llama3.3:70b
ollama run llama3.3:70b

# Servir derrière une API OpenAI-compatible
ollama serve
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.3:70b","messages":[{"role":"user","content":"Explique PagedAttention"}]}'

vLLM — l’inférence de production

vLLM est né au Sky Computing Lab de UC Berkeley en 2023 avec une idée simple qui a tout changé : le key-value cache des modèles transformers ne devrait pas être alloué de manière contiguë. PagedAttention — l’innovation centrale — découpe le cache KV en blocs non contigus, comme un système d’exploitation pagine la mémoire virtuelle. Résultat : la fragmentation mémoire est quasi nulle, et le batch de requêtes peut tripler sans changer le GPU.

En 2026, vLLM (version 0.8.x) est le standard de facto pour servir des LLM en production. Le continuous batching fusionne dynamiquement les requêtes entrantes plutôt que d’attendre qu’un batch soit plein. Le speculative decoding utilise un petit modèle draft pour prédire plusieurs tokens d’avance, qu’un modèle plus grand valide en une seule passe — gain de latence mesuré jusqu’à 3× sur des tâches de code. Le prefix caching réutilise automatiquement le cache KV des préfixes communs (prompt système, few-shot examples) entre requêtes successives.

L’API est 100 % compatible OpenAI, y compris les streaming responses, les function calls, et le structured output (JSON contraint par grammaire via guided_json). Le support matériel couvre NVIDIA (CUDA), AMD (ROCm), Intel (XPU), et les Apple Silicon (via MPS, expérimental).

# Installer vLLM
pip install vllm

# Servir un modèle avec tensor parallelism sur 4 GPU
vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 4 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.95 \
  --enable-prefix-caching

Le ticket d’entrée est plus élevé que pour Ollama : une H100 80 Go sert un Llama 3.3 70B à 800-1200 tokens/seconde en batch, mais il faut au minimum une A100 40 Go ou deux RTX 4090 pour le charger confortablement. vLLM exige aussi Python, pip, et une compréhension minimale du tensor parallelism — c’est un outil d’ingénieur infrastructure, pas de développeur solo.

Le cas d’usage de vLLM : servir un ou plusieurs modèles à une équipe, une application ou une API publique, avec des exigences de débit et de latence. C’est le choix par défaut d’une stack d’inférence professionnelle.

llama.cpp — le CPU comme GPU

llama.cpp est le projet qui a prouvé qu’un LLM peut tourner sans GPU. Né en mars 2023 d’un rewrite C++ de l’inférence LLaMA par Georgi Gerganov, il est devenu en trois ans et demi le socle sur lequel Ollama, LM Studio, GPT4All et des dizaines d’autres outils construisent leur backend.

Son innovation centrale est le format GGUF — un conteneur binaire qui embarque le modèle, sa configuration et ses métadonnées dans un fichier unique, avec quantification intégrée. Les quantifications vont de Q2_K (2 bits, qualité dégradée mais 2-3 Go de VRAM) à Q8_0 (8 bits, quasi sans perte), en passant par le sweet spot Q4_K_M (4 bits, perte inférieure à 1 % sur la plupart des benchmarks). Le modèle DeepSeek V4 Pro, en Q4_K_M, tient sur deux RTX 4090 au lieu de huit H100.

llama.cpp est aussi le seul des trois à fonctionner de manière crédible en CPU pur. Un Llama 3.3 8B Q4_K_M atteint 15 à 20 tokens/seconde sur un Ryzen 9 7950X — assez pour du chat conversationnel. Le M3 Ultra d’Apple avec sa mémoire unifiée à 800 Go/s atteint des débits comparables à un GPU milieu de gamme sur des modèles 70B, grâce au backend Metal de llama.cpp. L’AVX-512 sur les serveurs Intel récents et le backend Vulkan élargissent encore la couverture matérielle.

# Cloner et compiler llama.cpp
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && make -j

# Télécharger un modèle GGUF depuis Hugging Face
wget https://huggingface.co/bartowski/Llama-3.3-70B-Instruct-GGUF/resolve/main/Llama-3.3-70B-Instruct-Q4_K_M.gguf

# Inférence interactive en CPU pur
./llama-cli -m Llama-3.3-70B-Instruct-Q4_K_M.gguf \
  -n 256 -t 16 -p "Explique PagedAttention"

# Serveur HTTP compatible OpenAI
./llama-server -m Llama-3.3-70B-Instruct-Q4_K_M.gguf \
  --port 8080 --n-gpu-layers 40

La limite de llama.cpp est architecturale : pas de PagedAttention (la gestion mémoire GPU est moins efficace que vLLM), pas de continuous batching natif (le serveur traite les requêtes séquentiellement ou par lots statiques), un débit en throughput bien inférieur à vLLM sur GPU. Mais c’est le seul outil qui couvre tous les cas où un GPU n’est pas une option.

Tableau comparatif

Verdict — quel outil pour quel cas

Si vous êtes développeur et voulez un assistant local de code ou de chat, prenez Ollama. Vous l’installez en trente secondes, vous le couplez à Open WebUI ou Continue.dev, et vous avez un substitut crédible à ChatGPT pour les tâches non sensibles. Une RTX 4090 24 Go suffit pour un Llama 3.3 70B Q4_K_M à ~30 tokens/seconde. Pas besoin d’en savoir plus.

Si vous construisez un produit qui sert des LLM à plusieurs utilisateurs, partez sur vLLM. Le continuous batching et le prefix caching divisent le coût par token par deux à quatre par rapport à une solution naïve, et l’écosystème est devenu assez mature pour que les bugs de production se comptent désormais sur les doigts d’une main. Provisionnez au minimum une A100 40 Go ou deux RTX 4090, et montez en tensor parallelism quand votre trafic le justifie.

Si vous n’avez pas de GPU, ou si vos données ne doivent jamais quitter un CPU, utilisez llama.cpp directement — ou via Ollama qui l’empaquette. Un serveur bare metal récent avec 64 Go de RAM et AVX-512 fait tourner un Llama 3.3 8B Q4_K_M à 20 tokens/seconde sans carte graphique. Ce n’est pas instantané, mais c’est le prix de la souveraineté matérielle totale.

La question n’est plus « puis-je faire tourner un LLM chez moi ? ». Elle est devenue « lequel de ces trois outils correspond à ce que je protège — mes données, ma latence, ou mon budget GPU ? ». La réponse n’est pas la même à 14 h sur un laptop qu’à 2 h du matin dans un cluster Kubernetes.

Références

• Ollama — GitHub Repository, consulté le 29 juillet 2026.
• vLLM — GitHub Repository, consulté le 29 juillet 2026.
• llama.cpp — GitHub Repository, consulté le 29 juillet 2026.
• vLLM Documentation — PagedAttention, vLLM Project.
• vLLM Documentation — Speculative Decoding, vLLM Project.
• GGUF Format Specification, ggerganov/ggml.
• Hugging Face — GGUF Quantization Types, Hugging Face Hub Documentation.
• Ollama Blog — OpenAI Compatibility, Ollama, 2025.