Vous avez choisi votre modèle et votre GPU. Reste à choisir le runtime d'inférence : le logiciel qui va exécuter le LLM. Ce choix a un impact direct sur les performances (vitesse, latence), les coûts (utilisation GPU), et la facilité de déploiement. Les trois options principales en 2025 : vLLM, llama.cpp, et TGI. Ce guide vous aide à choisir en fonction de votre contexte.
Ce que le dirigeant doit savoir
Le runtime, c'est le "moteur" qui fait tourner votre LLM. Un mauvais choix peut signifier :
- Performances dégradées : réponses lentes, utilisateurs frustrés
- Coûts GPU gaspillés : un runtime inefficace sous-utilise votre matériel coûteux
- Difficultés de maintenance : certains runtimes sont plus simples à opérer que d'autres
Bonne nouvelle : les trois options présentées ici sont toutes gratuites et open-source. Le coût, c'est le temps de mise en place et l'expertise nécessaire.
Réponse directe
llama.cpp pour les POC et le déploiement simple (CPU possible). vLLM pour la production avec du batching et une API OpenAI-compatible. TGI si vous êtes dans l'écosystème Hugging Face et voulez du monitoring intégré.
Vue d'ensemble
| Critère | llama.cpp | vLLM | TGI |
|---|---|---|---|
| Simplicité | ⭐⭐⭐ | ⭐⭐ | ⭐⭐ |
| Performance (débit) | Bon | Excellent | Très bon |
| Batching | Limité | Continuous batching | Continuous batching |
| CPU support | ✅ Excellent | ❌ GPU only | ❌ GPU only |
| API OpenAI-compatible | Via wrapper | ✅ Native | Custom (compatible) |
| Quantization | GGUF (Q2-Q8) | AWQ, GPTQ | AWQ, GPTQ, EETQ |
| Multi-GPU | Limité | ✅ Tensor parallel | ✅ Tensor parallel |
llama.cpp
Le couteau suisse du LLM local. Écrit en C++, ultra-portable, peut tourner sur CPU, GPU NVIDIA, Apple Silicon, et même des microcontrôleurs.
Points forts
- Fonctionne sans GPU (CPU, Apple M1/M2/M3)
- Format GGUF : quantization flexible (Q2 à Q8)
- Installation simple : un binaire suffit
- Communauté très active
Limites
- Batching moins optimisé que vLLM/TGI
- Moins adapté à la haute concurrence
Cas d'usage idéal
POC, usage individuel, déploiement sur machine sans GPU dédié, Apple Silicon.
# Lancer un modèle avec llama.cpp (serveur API) ./llama-server -m llama-3.1-8b-instruct.Q4_K_M.gguf \ --host 0.0.0.0 --port 8080 \ -c 4096 -ngl 99
vLLM
Le champion du débit. Développé par UC Berkeley, vLLM introduit le "PagedAttention" qui optimise la gestion de la mémoire GPU.
Points forts
- Continuous batching : gère des dizaines de requêtes simultanées
- API 100% compatible OpenAI
- Support multi-GPU natif (tensor parallelism)
- Intégration facile avec LangChain, LlamaIndex
Limites
- Nécessite un GPU NVIDIA (pas de CPU, pas d'AMD pour l'instant)
- Configuration plus complexe que llama.cpp
Cas d'usage idéal
Production avec plusieurs utilisateurs, API interne, remplacement d'OpenAI par un modèle local.
# Lancer vLLM avec API OpenAI-compatible python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3.1-8B-Instruct \ --host 0.0.0.0 --port 8000
TGI (Text Generation Inference)
L'option enterprise. Développé par Hugging Face, TGI est conçu pour la production avec monitoring et observabilité intégrés.
Points forts
- Continuous batching + Flash Attention
- Metrics Prometheus intégrées
- Support des modèles Hugging Face natif
- Docker image officielle, déploiement simple
Limites
- Moins de modèles supportés que vLLM
- Performances parfois légèrement inférieures à vLLM
Cas d'usage idéal
Production dans un environnement Kubernetes, besoin de monitoring avancé, écosystème Hugging Face.
# Lancer TGI avec Docker docker run --gpus all -p 8080:80 \ -v /data:/data \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id meta-llama/Llama-3.1-8B-Instruct
Arbre de décision
1. Avez-vous un GPU NVIDIA ?
→ Non : llama.cpp
→ Oui : continuez
2. Plus de 5 utilisateurs simultanés ?
→ Non : llama.cpp (simple et suffisant)
→ Oui : continuez
3. Besoin de monitoring Prometheus natif ?
→ Oui : TGI
→ Non : vLLM (meilleur débit)
Performances comparées (ordre de grandeur)
Sur un GPU A100 40GB avec Llama 3.1 8B :
| Métrique | llama.cpp | vLLM | TGI |
|---|---|---|---|
| Tokens/s (1 user) | ~80 | ~90 | ~85 |
| Tokens/s (10 users) | ~30 | ~70 | ~65 |
| TTFT (ms) | ~200 | ~150 | ~180 |
Ces chiffres sont indicatifs. Les performances réelles dépendent du modèle, de la quantization et de la configuration.
"Commencez par llama.cpp pour valider votre cas d'usage. Passez à vLLM ou TGI quand vous avez besoin de scaler."