llama.cpp vs vLLM vs Exllama

#Trois backends, trois philosophies

Un backend d'inférence transforme des tokens d'entrée en tokens de sortie, vite. Les différences : langage (C++ vs Python), portabilité (CPU vs GPU only), formats (GGUF, AWQ, EXL2, FP16), stratégies mémoire (mmap vs paged).

#llama.cpp

Langage

C++ pur, zéro dépendance Python. Se compile partout.

Format

GGUF. Tous les modèles open source récents ont une version GGUF sur HuggingFace.

Matériel

CPU (x86, ARM), GPU NVIDIA (CUDA), AMD (ROCm ou Vulkan), Apple Metal, Intel Arc (Vulkan), mobiles (iOS, Android).

Forces

Portabilité inégalée, mmap du modèle (faible RAM), quantizations variées (Q2 à FP16), Flash Attention, KV cache quantifié.

Faiblesses

Batching moins efficace que vLLM (pas de paged attention). Latence single-request excellent, throughput multi-requêtes moyen.

Écosystème

Ollama, LM Studio, Jan, llama-cpp-python, tous l'utilisent. C'est le standard de facto.

#vLLM

Langage

Python + CUDA. Dépendances lourdes, venv obligatoire.

Format

HuggingFace direct (FP16, BF16), AWQ et GPTQ pour quantifier. Pas de GGUF natif.

Matériel

NVIDIA principalement, AMD ROCm récemment (encore expérimental), pas de CPU réel.

Forces

PagedAttention révolutionnaire (gestion VRAM par pages, batching continu), throughput extrêmement élevé, metrics Prometheus natifs, speculative decoding.

Faiblesses

Orienté serveur production, pas pratique pour un usage solo. Lourd à installer. Pas de CPU.

Écosystème

Le choix dès qu'on sert plusieurs utilisateurs simultanément (SaaS interne, chatbot équipe).

#ExLlamaV2

Langage

Python + CUDA, assez léger.

Format

EXL2 (format maison), GPTQ. Quantizations EXL2 sont parmi les plus efficaces (bits fractionnaires, par couche).

Matériel

NVIDIA RTX 20/30/40/50 exclusivement. Pas d'AMD, pas de CPU, pas de Mac.

Forces

Latence single-request la plus basse sur RTX, tensor parallelism efficace (multi-GPU), très bon support des longs contextes.

Faiblesses

NVIDIA only, écosystème plus petit, pas aussi connu qu'il le mérite.

Écosystème

TabbyAPI (serveur OpenAI-compatible), Text Generation WebUI comme frontend principal.

#Benchmark comparatif

Sur Mistral 7B en Q4_K_M / AWQ / EXL2 équivalents, RTX 4090, single prompt 512 tokens → 256 tokens de sortie :

llama.cpp (GGUF Q4_K_M + FA)

TTFT 80 ms · tok/s 110

vLLM (AWQ)

TTFT 120 ms · tok/s 130 (single) · tok/s 2000+ (20 req parallèles)

ExLlamaV2 (EXL2 4.0 bpw)

TTFT 55 ms · tok/s 140 (single)

#Mémoire VRAM (Mistral 7B, contexte 8k)

llama.cpp Q4_K_M + FA

~5 Go (modèle) + 1 Go (contexte) = 6 Go

vLLM AWQ

~4.5 Go (modèle) + 3 Go (KV cache paged) = 7.5 Go

ExLlamaV2 EXL2 4.0 bpw

~4 Go (modèle) + 1 Go (contexte) = 5 Go

#Quel backend pour quoi

Usage solo, Mac ou PC mixte

llama.cpp (via Ollama ou LM Studio). Portable, confortable, rapide en single.

Équipe, chatbot multi-users

vLLM. PagedAttention et batching continu rendent le serveur de prod imbattable.

Perf max single-user sur RTX

ExLlamaV2 via TabbyAPI. Parfait pour un dev qui veut le moins de latence possible sur sa propre machine.

Matériel hétérogène

llama.cpp. Seul qui tourne partout.