Logiciels d'inférence LLM : llama.cpp, vLLM, SGLang

Trois moteurs dominent l’écosystème LLM en 2026 : llama.cpp pour l’inférence portable et locale, vLLM pour le serving production multi-utilisateurs, et SGLang pour les workloads agentiques et structurés à très haut débit. Les autres outils (Ollama, LM Studio, MLX, TensorRT-LLM) sont soit des wrappers de ces moteurs, soit des cas d’usage spécialisés. Cet article les compare et détaille le choix réel de SoberCloud.

Les trois moteurs principaux

Si vous ne deviez retenir que trois noms, ce seraient ceux-ci :

• llama.cpp : référence pour l’inférence locale (CPU/GPU hybride, GGUF, edge). Backend de Ollama, LM Studio, Jan.
• vLLM : référence pour le serving GPU multi-utilisateurs. Innovations : PagedAttention, continuous batching.
• SGLang : challenger optimisé pour les workloads agentiques (longs prompts, tool calling, JSON structuré). Innovation : RadixAttention.

Vue d’ensemble

Outil	Cas d’usage	Performance	Facilité	Multi-GPU
llama.cpp	Local, edge, CPU/GPU hybride	★★★	★★★	Oui
vLLM	Production GPU, throughput max	★★★★★	★★★	Oui
SGLang	Agents, structured output, RAG	★★★★★	★★★	Oui
Ollama	Wrapper llama.cpp, dev rapide	★★★	★★★★★	Limité
LM Studio	Wrapper GUI (llama.cpp + MLX)	★★★★	★★★★★	Non
MLX / mlx-lm	Apple Silicon natif	★★★★★	★★★★	N/A
TensorRT-LLM	NVIDIA enterprise, latence min	★★★★★	★★	Oui

Formats supportés par logiciel

Chaque logiciel supporte un ensemble spécifique de formats de modèles. Ce tableau aide à choisir le bon format selon l’outil d’inférence.

Logiciel	GGUF	SafeTensors	AWQ	GPTQ	EXL2/EXL3	MLX
llama.cpp	Natif	Non	Non	Non	Non	Non
Ollama	Natif	Import	Non	Non	Non	Non
LM Studio	Oui	Non	Non	Non	Non	Oui (Mac)
vLLM	Partiel	Natif	Oui	Oui	Non	Non
MLX	Non	Conversion	Non	Non	Non	Natif
ExLlamaV2	Non	Oui	Non	Non	Natif	Non
TensorRT-LLM	Non	Conversion	Oui	Oui	Non	Non

EXL2/EXL3 (ExLlamaV2) sont des formats de quantification haute performance qui exigent ExLlamaV2 ou TabbyAPI comme runtime. vLLM, Ollama et llama.cpp ne les supportent pas. Avec vLLM, optez pour AWQ ou GPTQ ; pour llama.cpp/Ollama, utilisez GGUF.

llama.cpp — le couteau suisse

Écrit en C/C++ pur sans dépendances externes, llama.cpp est la référence pour la portabilité extrême. Il fonctionne partout : serveurs, laptops, Raspberry Pi, téléphones, et même dans le navigateur (WebAssembly).

• CPU/GPU hybride : seule solution efficace pour l’offloading partiel.
• Formats : GGUF natif avec K-quants intégrés.
• Quantification on-the-fly : convertit FP16 vers quantifié en minutes.
• Startup rapide : pas de compilation JIT, prêt instantanément.
• Serveur OpenAI-compatible : llama-server.

C’est votre seul choix si vous devez utiliser le CPU ou mixer CPU/GPU. Idéal pour les machines sans GPU dédié ou quand le modèle ne tient pas entièrement en VRAM.

Ollama — simplicité maximale

Ollama encapsule llama.cpp dans une interface ultra-simple inspirée de Docker. Une seule commande pour télécharger et lancer un modèle.

# Modèles 2026 populaires
ollama run qwen3.6:27b           # Qwen3.6 Dense 27B
ollama run qwen3.6:35b-a3b       # Qwen3.6 MoE 35B (3B actifs)

# Créer un modèle personnalisé
cat > Modelfile << 'EOF'
FROM qwen3.6:27b
PARAMETER temperature 0.7
PARAMETER top_p 0.8
PARAMETER top_k 20
PARAMETER num_ctx 32768
SYSTEM "Tu es un assistant expert en programmation Python."
EOF

ollama create mon-assistant -f Modelfile
ollama run mon-assistant

LM Studio — interface graphique

Application desktop avec interface graphique intuitive, parfaite pour les débutants. Supporte à la fois llama.cpp (GGUF) et MLX (Apple Silicon) comme backends.

• Recherche de modèles : navigation et téléchargement depuis les dépôts publics.
• Serveur local : API compatible OpenAI en un clic.
• CLI : lms load, lms server start.
• Dual backend : llama.cpp ou MLX selon le hardware.

LM Studio est propriétaire (closed-source) et peut être plus gourmand en ressources qu’Ollama. Pour la production ou l’automatisation, préférez les outils CLI.

vLLM — production à haute performance

Issu de UC Berkeley (Sky Computing Lab), vLLM est la référence du serving GPU en 2026. Son innovation fondatrice est PagedAttention, inspirée de la pagination mémoire des systèmes d’exploitation.

• PagedAttention : KV cache alloué en blocs non-contigus, fragmentation quasi nulle contre 60-80 % en allocation classique.
• Continuous batching : nouvelles requêtes ajoutées au batch sans attendre la fin de la précédente.
• Tensor / Pipeline / Expert Parallelism : scaling multi-GPU et multi-nœud transparent.
• Quantification : AWQ, GPTQ, FP8, INT4 (Marlin), GGUF (partiel).
• Décodage accéléré : EAGLE-3, Medusa, MTP, n-gram.
• Backends : CUDA, ROCm (AMD), Intel Gaudi, AWS Trainium, TPU.

from vllm import LLM, SamplingParams

llm = LLM(
    model="Qwen/Qwen3.6-27B-Instruct",
    tensor_parallel_size=2,
    quantization="awq",
    speculative_config={             # Décodage spéculatif EAGLE-3
        "method": "eagle3",
        "model": "EAGLE3-Qwen3.6-27B",
        "num_speculative_tokens": 5,
    },
    max_model_len=131072,
    enable_prefix_caching=True       # KV cache partagé entre requêtes
)

sampling_params = SamplingParams(temperature=0.7, top_p=0.8, top_k=20, max_tokens=512)
outputs = llm.generate(["Explique le machine learning"], sampling_params)
print(outputs[0].outputs[0].text)

SGLang — le challenger des workloads agentiques

Développé par LMSYS (auteurs de Chatbot Arena et Vicuna), SGLang vise les workloads où la latence et la structuration de la sortie comptent autant que le débit : agents IA, RAG, tool calling, JSON contraint, conversations multi-tours.

• RadixAttention : KV cache organisé en arbre radix, réutilisation automatique de tout préfixe partagé entre requêtes (gain ×3 à ×5 sur les workloads d’agents).
• Compressed Finite State Machine : génération de JSON / regex strictement contrainte avec un overhead quasi nul.
• DSL frontal : @sgl.function permet de scripter des workflows multi-tours avec fork, join, control flow conditionnel.
• Speculative decoding NEXTN/EAGLE intégré, support natif du MTP DeepSeek.
• Backends : NVIDIA (CUDA), AMD (ROCm), Intel Gaudi, AWS Trainium.

Sur un workload d’agent où chaque requête commence par un system prompt de 4000 tokens et 20 tours de conversation partagés, SGLang ne recalcule jamais le KV cache de la partie commune : on passe d’environ 80 req/s (vLLM sans prefix cache) à environ 280 req/s (SGLang RadixAttention) sur Qwen3.6-27B avec H100.

Comparaison détaillée

Ces trois moteurs ne s’opposent pas : ils ciblent des points très différents du compromis latence / débit / coût d’opération.

Critère	llama.cpp	vLLM	SGLang
Origine	G. Gerganov (2023)	UC Berkeley (2023)	LMSYS (2024)
Langage	C/C++ pur	Python + kernels CUDA	Python + Triton + CUDA
Cible matérielle	CPU, GPU, edge, mobile	GPU NVIDIA/AMD/Intel/TPU	GPU NVIDIA/AMD/Gaudi
Format modèle	GGUF	SafeTensors, AWQ, GPTQ, FP8	SafeTensors, AWQ, GPTQ, FP8
KV cache	Linéaire + quant Q4-Q8	PagedAttention + prefix cache	RadixAttention
Batching	Continuous basique	Continuous mature	Continuous + zero-overhead
Multi-GPU	Layer-split (+ hybride)	TP / PP / EP, multi-nœud	TP / DP / EP, multi-nœud
Décodage spéculatif	Vanilla (draft GGUF)	Vanilla, EAGLE-3, Medusa, MTP	NEXTN, EAGLE-3, MTP
Sortie structurée	Grammar GBNF	guided_decoding	Compressed FSM
Throughput (27B, H100, 100 req)	~150 tok/s	~3500 tok/s	~4200 tok/s
Latence p99 single user	~80 ms	~120 ms	~95 ms
Cas idéal	Local, edge, modèle hors VRAM	Serving multi-tenant	Agents, RAG, JSON

Comment choisir en 3 questions

1. Le modèle tient-il dans la VRAM d’un GPU disponible ? Sinon → llama.cpp (offload CPU/GPU).
2. Y a-t-il plusieurs requêtes concurrentes ? Non → llama.cpp. Oui → vLLM ou SGLang.
3. Workload structuré (JSON, regex) ou agentique (longs prompts partagés) ? Oui → SGLang. Non → vLLM.

MLX — Apple Silicon natif

Framework développé par Apple, optimisé pour les puces M1/M2/M3/M4. Il exploite la mémoire unifiée pour éliminer les copies CPU↔GPU.

• Mémoire unifiée : zéro transfert, CPU et GPU partagent la même RAM.
• Évaluation paresseuse : calculs différés pour optimisation automatique.
• Environ 230 tok/s sur M2 Ultra contre ~150 tok/s pour llama.cpp à config équivalente.
• mlx-lm : package dédié aux LLM avec quantification intégrée.

Le choix SoberCloud

SoberCloud privilégie une inférence sobre, en exploitant au mieux le matériel disponible plutôt qu’en empilant les GPU. Nos tests couvrent deux profils matériels aux caractéristiques opposées.

llama.cpp Vulkan sur Strix Halo. Un AMD Ryzen AI MAX+ 395 “Strix Halo” (iGPU Radeon 8060S gfx1151, 128 Gio de mémoire UMA) fait tourner llama.cpp avec le backend Vulkan (image kyuz0/amd-strix-halo-toolboxes). En Qwen3.6-35B-A3B MoE quantifié Q5_K_XL, il atteint environ 73 t/s. vLLM n’est pas une option ici : il n’est pas supporté sur gfx1151 (bug Triton). C’est l’illustration directe du raisonnement « modèle qui ne tient pas confortablement en VRAM dédiée + pas de support vLLM → llama.cpp ».

vLLM sur RTX 3090. Une RTX 3090 24 Go (CUDA, architecture Ampere) sert Qwen3.6-27B quantifié int4 AutoRound via vLLM, avec prefix caching et chunked prefill activés. C’est le cas d’usage canonique de vLLM : serving GPU dense, multi-requêtes, format SafeTensors quantifié.

LiteLLM en façade. Un proxy OpenAI-compatible comme LiteLLM permet de router vers le bon backend selon l’alias du modèle demandé. Les clients ne voient qu’une seule API ; le routage llama.cpp/Vulkan contre vLLM/CUDA reste invisible.

Pour aller plus loin

• Drivers GPU : Vulkan, ROCm, CUDA
• Quantification avancée