Statique
Des lots de taille fixe qui attendent d’être remplis. Convient aux traitements hors ligne, mauvais pour du trafic interactif car tout le monde attend le lot.
Guide de l’inférence IA
Optimisation du service
Les techniques au niveau système qui décident combien de requêtes une flotte de GPU peut servir, et à quelle vitesse : batching, gestion mémoire du cache KV, accélération du decode, séparation des phases, parallélisme et routage. Latence, débit et coût s’opposent ; c’est la charge de travail qui décide quel angle l’emporte.
Batching : le premier levier de débit
Une requête isolée laisse la majeure partie d’un GPU inoccupée ; regrouper les requêtes amortit chaque lecture de poids sur de nombreux jetons. La façon de les regrouper compte :
Dynamique
Les lots se ferment sur une fenêtre de temps ou un plafond de taille, ce qui borne l’attente. Mieux, mais le lot se termine encore au rythme de son membre le plus lent.
Continu
Le planificateur travaille à la granularité du jeton : les séquences terminées sortent en cours de route, les requêtes en file entrent immédiatement. C’est la valeur par défaut courante (vLLM, SGLang, TensorRT-LLM) et le plus grand gain d’utilisation à lui seul.
Le chunked prefill l’affine encore : les longs prompts sont découpés en morceaux intercalés avec des étapes de decode, si bien qu’un prompt énorme ne peut plus bloquer le streaming de jetons de tous les autres. Une politique de batching est une politique de latence ; mesurez le TTFT et la latence entre jetons, pas seulement les jetons par seconde.
Mémoire du cache KV : pagination, réutilisation, déchargement
PagedAttention
Un service naïf réserve une mémoire KV contiguë pour la longueur maximale possible de chaque requête, et en gaspille l’essentiel en fragmentation. PagedAttention emprunte les idées de la mémoire virtuelle : le cache vit dans des blocs de taille fixe alloués à la demande, avec une table de blocs qui associe les positions logiques de chaque séquence à des blocs physiques. Le gaspillage se réduit à peu près au dernier bloc partiel, des préfixes identiques peuvent partager des blocs physiques, et la mémoire récupérée se transforme en lots effectifs plus grands. Introduit par vLLM et désormais standard dans les moteurs de service ; c’est un gain de gestion mémoire, pas un noyau plus rapide.
Prefix caching
Si deux requêtes commencent par des préfixes de jetons strictement identiques (même prompt système, mêmes exemples, même historique de conversation), le travail de prefill de ce préfixe peut être calculé une fois puis réutilisé, ce qui réduit le TTFT et le calcul de prefill à chaque succès. Cela exige des correspondances de jetons exactes, d’où l’importance de la discipline de prompt : contenu statique en premier, valeurs volatiles (horodatages, données utilisateur, identifiants de requête) le plus tard possible, sérialisation déterministe. Suivez le taux de succès ; un taux faible signale en général que le gabarit de prompt laisse fuir de la variabilité en tête.
Déchargement du cache KV
Le cache croît linéairement avec le contexte et la concurrence, et la HBM du GPU s’épuise en premier. Le déchargement déverse le cache le plus froid vers la RAM CPU, un SSD local ou des stockages distants, puis le récupère à la demande, si bien que les sessions de chat inactives et les longs contextes partagés cessent d’immobiliser la HBM (LMCache est l’exemple open source le plus visible, intégré à vLLM). Cela vaut le coup pour les longs contextes et les sessions reprenables ; l’arbitrage est le temps de transfert contre le recalcul, alors mesurez les deux chemins sur vos paliers de stockage.
Décodage spéculatif : des jetons plus rapides, la même distribution
Le decode est limité par la mémoire, il reste donc du calcul disponible à chaque étape. Un brouillonneur peu coûteux propose plusieurs jetons ; le modèle cible les vérifie en une passe et accepte la plus longue suite correcte. Les jetons acceptés arrivent pour une fraction du coût ; les brouillons rejetés retombent sur un décodage normal, et les schémas de vérification exacts préservent la distribution de sortie du modèle cible.
- Brouillonneurs : un petit modèle séparé, des têtes de décodage supplémentaires sur le modèle cible (à la Medusa), un brouillon au niveau des représentations (famille EAGLE) ou une simple recherche de n-grammes dans le prompt. Les implémentations rédigent souvent plusieurs continuations candidates et vérifient tout l’arbre en une passe groupée.
- La variable déterminante est le taux d’acceptation : un brouillonneur bien aligné sur du texte prévisible (code, sortie structurée) aide beaucoup ; un brouillonneur mal accordé peut ralentir le service.
- Interactions : le brouillonneur consomme de la mémoire et de la complexité de planification, et les gains s’amenuisent aux très grandes tailles de lot, là où la marge de calcul disparaît. Les directions de recherche sont passées en revue dans optimisation avancée.
Passer à l’échelle : désagrégation, parallélisme, routage
Désagrégation prefill/decode
Le prefill est limité par le calcul et arrive par rafales ; le decode est limité par la bande passante et reste régulier. Colocalisés, ils interfèrent : un long prefill bloque le flux de jetons de tout le monde. La désagrégation exécute les phases sur des pools de workers distincts, dimensionnés et réglés indépendamment, le worker de prefill expédiant le cache KV à un worker de decode via un réseau rapide. Le transfert est la taxe : cela devient rentable à l’échelle d’une flotte et pénalise à petite échelle ou pour des prompts courts ; parmi les frameworks, vLLM, SGLang et NVIDIA Dynamo.
Stratégies de parallélisme
Le parallélisme de données réplique le modèle et répartit le trafic. Le parallélisme de tenseurs découpe chaque couche entre plusieurs GPU pour faire tenir des modèles surdimensionnés, au prix d’une communication à chaque étape (il réclame des liens de classe NVLink). Le parallélisme de pipeline attribue des plages de couches à des étages, avec du microbatching pour combler les bulles du pipeline. Le parallélisme d’experts répartit les experts MoE entre les appareils. Les déploiements réels combinent tout cela, et le bon dosage est empirique : le parallélisme de tenseurs ajoute de la pression sur la bande passante, tandis que la réplication réduit la marge de cache KV par GPU. Mesurez donc les configurations plutôt que de raisonner a priori.
Routage d’inférence
Avec de nombreux réplicas, le routeur devient une surface d’optimisation. Le tourniquet ignore tout ce qui compte pour un LLM ; de meilleurs signaux sont la charge active, la marge mémoire et surtout la localité de cache : un routage conscient des préfixes ou collant à la session envoie les requêtes là où leur état KV réside déjà (le hachage cohérent sur le préfixe du prompt est l’astuce courante, utilisée par des projets comme llm-d). Les flottes désagrégées routent par phase, et des classes de priorité ou de SLA ainsi que la localité des adaptateurs peuvent alimenter le même score. À ne pas confondre avec le routage de sélection de modèle entre gammes de modèles, traité dans patterns agentiques.
Inférence par lots hors ligne
Toutes les charges de travail ne sont pas interactives. Vectoriser des corpus, rattraper des classifications, balayer des résumés et lancer des évaluations tolèrent des heures de latence, ce qui change entièrement la cible d’optimisation : saturer le matériel, utiliser la capacité disponible ou hors pointe (les fournisseurs vendent des paliers batch remisés exactement pour cela), et ajouter du post-traitement et des contrôles qualité avant que les résultats ne soient consommés. Tenir le travail par lots à l’écart de la flotte interactive protège en outre vos SLO de latence.
Mesurez avant de croire
- Mesurez le TTFT, la latence entre jetons, la latence de bout en bout (médiane et P99), le débit à concurrence fixe et le coût par requête ; un résultat à un seul chiffre dissimule les arbitrages.
- Utilisez la forme de votre propre trafic : distributions de longueur de prompt et de sortie, motif de concurrence, potentiel de succès de cache. Les charges synthétiques uniformes flattent toutes les optimisations.
- Les générateurs de charge conçus pour le service de LLM (GenAI-Perf, LLMPerf, ou des scripts k6/Locust) rapportent des métriques au niveau du jeton que les outils HTTP génériques ignorent.
- Consignez le modèle, la quantification, le matériel, la version du moteur et la configuration avec chaque résultat ; des mesures non étiquetées ne peuvent être ni comparées ni reproduites.
- Les benchmarks de qualité (suites de type MMLU) et les benchmarks de performance répondent à des questions différentes ; un changement de service doit être validé à la fois contre un objectif de latence et contre une évaluation de justesse.