Frameworks de serving de LLM : comment choisir un runtime ?
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Choisissez un runtime qui prend en charge votre modèle exact, sa quantification et votre matériel, puis évaluez ses réglages avec le trafic prévu. vLLM, SGLang, TensorRT-LLM et llama.cpp sont des candidats utiles pour différents déploiements. Aucun nom de framework ne garantit la latence la plus faible pour votre charge de travail.
Vérifiez la compatibilité du modèle et du matériel avant de consacrer du temps aux tests de charge.
Choisissez les candidats selon le comportement requis
| Besoin | Candidat à tester | Données à recueillir |
|---|---|---|
| Serving général sur GPU avec plusieurs requêtes | vLLM | Débit respectant le SLO et pression sur la mémoire |
| Nombreux préfixes répétés ou génération structurée | SGLang, avec un autre runtime compatible | Taux de succès du cache et validité de la sortie |
| Optimisation propre à NVIDIA | TensorRT-LLM | Modèles et précisions pris en charge, et latence sous charge |
| CPU, Apple silicon ou exécution portable de GGUF | llama.cpp | Capacité à tenir en mémoire et vitesse sur la machine cible |
| Configuration simple de modèles locaux | Ollama | Capacité du flux de travail local à gérer la concurrence requise |
Ces comparaisons sont des points de départ, pas des capacités exclusives. Par exemple, d’autres runtimes de serving proposent aussi la mise en cache des préfixes et le structured output.
vLLM documente le serving, la gestion de la mémoire, l’ordonnancement et les options de déploiement. SGLang inclut la réutilisation des préfixes et des fonctions de génération structurée. Le guide de démarrage rapide de TensorRT-LLM utilise une API de modèles de haut niveau et une commande de serving ; vérifiez les exigences du backend et du modèle plutôt que de supposer que chaque déploiement nécessite un moteur précompilé.
Hugging Face a archivé le dépôt de TGI en mars 2026. Son README recommande d’autres moteurs pour les nouveaux projets.
Comparez avec la même distribution de requêtes
Utilisez le même artefact de modèle, le même matériel, la même précision, les mêmes prompts et les mêmes limites de sortie. Testez des préfixes uniques et répétés si le cache compte. Relevez le délai jusqu’au premier token, le temps par token de sortie, les échecs de requêtes et le débit à vos seuils de latence.
Testez aussi l’annulation, les entrées mal formées, les requêtes longues simultanées et le comportement au redémarrage. Un runtime qui réussit un test court avec une seule requête peut nécessiter d’autres limites d’admission sous charge.
La comparaison des frameworks de serving dans le LLM Engineering Guide relie le choix du runtime aux optimisations d’inférence.