Chapitre 10 — La couche moteur LLM

Dixième billet de la tournée chapitre par chapitre de LLM Primer VI : Mettre à l'échelle les systèmes IA. Le chapitre qui nomme la frontière entre le moteur et la plateforme, et parcourt les cinq moteurs qui dominent cette couche en 2026.

Pourquoi ce chapitre existe

Les Chapitres 1–9 ont parcouru la machinerie qu'une seule passe avant touche : la boucle autoregressive, le cache KV, le substrat GPU, la quantification qui le rétrécit, le batching qui cache son temps mort, et le décodage spéculatif qui brise sa dépendance séquentielle. Rien de cela ne s'installe comme une bibliothèque qu'on pip install et qu'on oublie. Quelqu'un le câble en un runtime mono-nœud qui enveloppe un modèle, possède le cache KV, ordonnance les requêtes dans un batch continu et expose une API d'inférence. Ce runtime est le moteur. Le Chapitre 10 nomme le travail de la couche moteur, la distingue de la couche plateforme (Chapitre 11) et parcourt les cinq moteurs — vLLM, TensorRT-LLM, SGLang, TGI, Ollama — qui font des arbitrages mécaniques différents sur le même travail.

10.1 vLLM est le défaut natif Python

vLLM est le moteur vers lequel la plupart des équipes de production devraient se tourner en premier, car il prend la bonne décision par défaut sur chaque axe où un débutant ne saurait comment décider, et il le fait en Python. PagedAttention lui donne un effondrement de la fragmentation de 60–80 pour cent vers un chiffre à un chiffre, ce qui double environ la taille de batch réalisable sur le même GPU. Le batching continu s'y superpose naturellement, avec le préremplissage par tronçons qui mélange préremplissage et décodage dans la même itération pour que la frontière entre eux ne soit pas du temps mort. Le partage de préfixe en copie-sur-écriture est gratuit grâce à la conception de la table de blocs. L'interface est authentiquement batch hors ligne ou HTTP compatible OpenAI en quelques lignes, et chaque nouvelle architecture de modèle atterrit vite, la communauté étant large. C'est le moteur sur lequel se standardiser quand l'opérateur n'a pas de raison précise d'en choisir un autre.

10.2 TensorRT-LLM achète du débit avec un pipeline de build

Le pitch de TensorRT-LLM est étroit. Si le parc est exclusivement NVIDIA, si chaque point de débit par dollar compte, et si l'équipe accepte une taxe d'ingénierie pour compiler des fichiers moteur spécifiques par modèle et par génération matérielle, TRT-LLM extrait 15–35 pour cent de débit en plus que vLLM sur le même matériel. Le mécanisme est au niveau du kernel : abaisser le graphe transformer dans un IR spécifique NVIDIA, fusionner les kernels adjacents (layernorm + matmul + activation en un seul lancement), sélectionner des kernels optimaux par forme depuis une bibliothèque pré-réglée, produire un moteur sérialisé et l'exécuter sous Triton Inference Server. La fusion compte parce que le surcoût de lancement d'un kernel est de 5–10 μs à chaque fois et qu'une passe avant 70B naïve en lance des milliers par token. La taxe est le pipeline de build lui-même — une étape de compilation par modèle, par GPU, par régime de batch dont la plupart des équipes sous-estiment le coût opérationnel. SGLang est l'autre spécialisation : RadixAttention stocke le cache KV de tout préfixe de prompt que le moteur a déjà vu dans un arbre radix, donc deux requêtes qui partagent un préfixe de k tokens partagent le KV pour exactement ces k tokens à travers les batches et à travers le temps. Sur des charges agentiques avec de longs prompts système partagés et de courts suffixes variables, SGLang délivre 2–6× le débit de vLLM, et son DSL de sortie structurée impose des schémas JSON au niveau des logits, garantissant que la sortie valide.

10.3 L'arbre de décision passe par la forme de la charge, non par le débit d'affiche

Les cinq moteurs s'étalent sur un petit arbre de décision. Portable dev ou périphérie avec accélérateurs mixtes → Ollama. Parc GPU production, exclusivement NVIDIA, QPS élevé, ROI du débit qui justifie le pipeline de build → TensorRT-LLM. Matériel mixte ou changements fréquents de modèle, charge dominée par des motifs structurés à préfixe lourd (agents, appels d'outils, longs prompts partagés) → SGLang. Matériel mixte, charge chat générale, intégration Hugging Face poussée → TGI. Tout le reste → vLLM. La décision n'est pas permanente : les moteurs sont interchangeables à la frontière API — ils parlent tous l'HTTP style OpenAI — donc un routeur au niveau plateforme peut déplacer du trafic par modèle, par charge ou par région sans changer le code client. Beaucoup de piles de production font tourner deux ou trois moteurs côte à côte. Méfiez-vous du benchmark d'affiche : « tokens par seconde sur Llama-2-7B à batch 1 » répond à une question qu'aucune charge de production ne pose. Faites vos benchmarks sur votre propre modèle, votre distribution de prompts, votre profil de concurrence ; une demi-journée qui économise des mois.

Ce que prépare le Chapitre 10

Chaque moteur décrit dans ce chapitre s'arrête à la même frontière. Il connaît les kernels, les blocs KV et le batching continu ; il ne connaît pas les répliques, les locataires, les chaînes ou l'authentification. Le Chapitre 11 parcourt la couche plateforme qui traite ces sujets — Ray Serve, KServe, BentoML, Triton Inference Server — et montre que le choix est beaucoup moins une question de fonctionnalités que de savoir quel modèle opérationnel correspond à l'infrastructure et aux compétences existantes de l'équipe.

Prochaine étape — Chapitre 11 : La couche plateforme et orchestration. Ray Serve, KServe, BentoML, Triton — les quatre plateformes qui siègent au-dessus du moteur, choisies sur l'adéquation avec la culture d'exploitation.