Routage optimisé pour l'inférence pour les clusters LLM

RÉSUMÉ : Les mêmes 16 GPU, deux fois plus d'utilisateurs. Votre facture de GPU reste stable tandis que la capacité double. Un cluster qui gérait 20 utilisateurs simultanés en gère désormais 200. Ces chiffres sont rendus possibles par l'ordonnanceur d'inférence de llm-d, conçu pour acheminer chaque requête dans un cluster distribué avec une visibilité sur chaque nœud, chaque file d'attente et chaque cache. Les requêtes de grands modèles de langage (LLM) sont lentes, non uniformes et coûteuses ; l'ordonnanceur d'inférence est conçu précisément pour cela.

Le modèle qui fonctionne partout ailleurs

Chaque heure-GPU a un prix ; la question est de savoir quelle quantité de travail vous en tirez.

Kubernetes permet de créer, de déployer et d'exploiter des services distribués à grande échelle. Dans une configuration Kubernetes standard, vous définissez un déploiement, un nombre de réplicas, et un service Kubernetes vous fournit un point d'entrée avec un équilibrage de charge « round-robin » sur l'ensemble de vos pods. Pour les API REST, les services web et les microservices, ce modèle est pratiquement parfait. Les requêtes sont rapides, uniformes, et chacune prend environ moins d'une seconde pour s'exécuter.

Mais dès que vous commencez à servir de grands modèles génératifs à l'échelle, tels que Llama, Mistral ou des modèles open source de classe GPT, cette hypothèse ne tient plus.

Quand le round-robin atteint ses limites

Les requêtes d'inférence LLM ne sont pas comme les requêtes HTTP normales, et ce sont ces différences qui mettent à mal l'équilibrage de charge standard :

• Variabilité temporelle : Une requête peut prendre moins d'une seconde ou plus d'une minute, selon ce qui est demandé au modèle. Le round-robin distribue les requêtes, pas le travail. Si un réplica reçoit une série de requêtes longues et coûteuses, il devient un goulot d'étranglement tandis qu'un autre reste largement inactif.
• Variabilité de structure : Des instructions courtes avec des réponses générées longues se comportent différemment des instructions longues avec des réponses courtes. Le profil de calcul, la pression sur la mémoire et le temps d'exécution sont tous différents.
• Variabilité de phase : Chaque requête d'inférence comporte deux phases internes : le pré-remplissage, qui traite l'intégralité de l'instruction d'entrée en un seul passage parallèle, et le décodage, qui génère la réponse un jeton à la fois. Ces deux phases présentent des profils de ressources, des durées et une sensibilité à la charge différents. Un système qui ne peut pas les distinguer ne peut optimiser ni l'une ni l'autre.

Le round-robin a été conçu pour des charges de travail où les requêtes sont brèves, uniformes et peu coûteuses. Un ordonnanceur qui ne peut pas voir l'intérieur de la requête les traite comme s'il s'agissait de la même chose.

Figure 1 : Le round-robin distribue le nombre de requêtes, pas le travail. Les cinq mêmes requêtes (de tailles et de coûts de calcul variés) arrivent de manière inégale sur les pods. Un pod est submergé par deux requêtes longues tandis qu'un autre reste pratiquement inactif. Le routage sensible à l'inférence détecte la structure, la taille ainsi que la charge, et équilibre plutôt le travail réel.

Un succès de cache sur le mauvais pod est un échec de cache

vLLM est le moteur d'inférence de référence pour les LLM ; chaque accélérateur matériel majeur est optimisé pour lui et les nouveaux modèles sont livrés avec une prise en charge vLLM dès le premier jour. Il gère exceptionnellement bien les mécanismes d'inférence sur un seul nœud.

vLLM a introduit la mise en cache de préfixes pour traiter l'une des parties les plus coûteuses de l'inférence, en retraitant les mêmes préfixes d'instruction de manière répétée. Lorsque plusieurs requêtes partagent un préfixe commun (une instruction système, un document ou un historique de conversation), vLLM peut mettre en cache l'état clé-valeur (KV) du premier calcul et le réutiliser pour les requêtes suivantes. En cas de succès de cache, l'étape de prefill est entièrement ignorée : le délai d'obtention du premier jeton (TTFT) chute proportionnellement à la part de l'instruction qui était déjà mise en cache, mais seulement si la requête atteint le réplica spécifique qui détient ce cache.

Une requête qui serait presque gratuite sur un réplica est acheminée vers un autre où elle repart de zéro. L'optimisation existe, mais le routage round-robin l'ignore.

À faible trafic, c'est une occasion manquée. À grande échelle, vous payez deux fois pour le même calcul.

Passer du nœud au cluster

Chaque pod ne voit que lui-même, même si chaque pod vLLM gère bien sa part de requêtes : gestion de la mémoire, regroupement efficace et service des jetons aussi vite que le matériel le permet. Il ne sait pas ce que ses pairs traitent, quels réplicas sont sous charge, ni où se trouve l'état du cache de préfixe dans le cluster. 

Le problème de coordination se situe au-dessus du nœud et Kubernetes est la plateforme de choix pour l'infrastructure distribuée et l'orchestration à l'échelle, c'est pourquoi llm-d est conçu dès le départ pour être natif de Kubernetes afin de résoudre précisément ce problème. 

L'Inference Gateway (IGW) est la concrétisation de cette approche : une couche de trafic reposant sur Envoy et l'API Kubernetes Gateway qui comprend les charges de travail LLM, et pas seulement le HTTP. Derrière elle, l'Inference Scheduler surveille chaque pod de l'InferencePool en temps réel (profondeur de la file d'attente, état du cache KV, charge) et achemine chaque requête vers la bonne instance plutôt que vers la suivante dans la rotation.

Figure 2  : L'Inference Gateway (IGW) reçoit chaque requête et consulte l'Inference Scheduler (EPP) via ext_proc. L'ordonnanceur évalue tous les pods de l'InferencePool selon deux signaux en direct (état du cache KV et charge), renvoie le point de terminaison sélectionné à l'IGW, et l'IGW transmet la requête. En cas de succès de cache, la partie mise en cache du prefill est réutilisée et le décodage commence immédiatement. En cas d'échec de cache, le prefill s'exécute intégralement.

Ordonnancement des inférences à grande échelle : Même matériel, deux fois plus de capacité

L'ordonnanceur d'inférence (l'Inference Scheduler de llm-d, ou EPP) est ce qui concrétise la coordination au niveau du cluster. Au lieu de traiter tous les pods comme interchangeables, il achemine chaque requête en fonction de signaux en temps réel : État du cache KV, profondeur des files d'attente et charge. Chaque requête va vers la bonne instance, à chaque fois.

Les résultats des tests de performance de llm-d v0.5 montrent ce que cela apporte en pratique.

Ordonnancement d'inférence (Qwen3-32B, 8 pods vLLM, 16 NVIDIA H100) :

• Débit jusqu'à 109 % plus élevé par rapport à un service Kubernetes de base. Les mêmes 16 GPU servent environ deux fois plus d'utilisateurs simultanés pour le même objectif de niveau de service (SLO).
• Délai d'obtention du premier jeton (TTFT) jusqu'à 99 % plus court sous une charge équivalente. Le test de performance montre que le TTFT de base grimpe jusqu'à un niveau critique de ~80 secondes sous une charge élevée. L'ordonnancement intelligent le maintient à ~150 ms. C'est la différence entre un produit qui semble défaillant et un autre qui semble instantané.
  • Le test de performance maintient ~11 000 jetons de sortie/s sur 16 GPU. En supposant ~1 000 jetons par réponse et ~3 requêtes par minute par utilisateur actif, cela se traduit par environ 200 utilisateurs simultanés tout en respectant l'objectif de niveau de service (SLO), sur un matériel que le service Kubernetes de base ne parvient plus à servir correctement au-delà de 20.

Chaque résultat est géré par un contrôle de version et lié à un guide reproductible spécifique.

Figure 3 : ordonnancement d'inférence llm-d par rapport au Kubernetes de base, TTFT moyen et débit total par rapport au QPS. Topologie : 8 pods vLLM, 16 NVIDIA H100 (TP=2). Charge de travail : préfixe partagé synthétique, 150 groupes × cinq instructions, longueur système/question/sortie de 6k/1,2k/1k. Résultats : TTFT P50 136–157 ms, 4,5–11 k jetons de sortie/s, débit jusqu'à 109 % plus élevé et TTFT jusqu'à 99 % plus bas par rapport à à la configuration de référence. Source : llm-d v0.5.

vLLM optimise le nœud, llm-d optimise le cluster

vLLM et llm-d sont conçus pour fonctionner ensemble, et l'écart de performance entre l'utilisation de l'un sans l'autre est mesurable : Deux fois plus d'utilisateurs sur le même matériel, une latence 99 % meilleure sous charge, un cluster qui tient aussi bien à 250 utilisateurs simultanés qu'à 20.

Si vous exécutez deux réplicas ou plus, l'ordonnancement d'inférence intelligent s'applique dès aujourd'hui à votre charge de travail. L'écart de performance n'est pas progressif, c'est la différence entre un cluster capable de monter en charge et un autre qui est à la traîne. 

C'est ici que commence l'inférence distribuée.

Constatez vous-même la montée en charge

Les guides llm-d et les configurations de test de performance derrière chaque chiffre de cet article de blog sont publics et reproductibles. Un bon point de départ est la version llm-d v0.5.

Red Hat AI Enterprise inclut une version de llm-d prise en charge par l'entreprise avec un essai gratuit de 60 jours de Red Hat AI Enterprise. C'est un bon point de départ si vous souhaitez exécuter cela sur votre propre infrastructure.

Si vous souhaitez d'abord voir l'ordonnanceur en action, l'Introduction to llm-d Interactive Demo explique comment les requêtes sont acheminées.

Note de l'auteur : Données de test de performance provenant de la version llm-d v0.5. Tous les résultats sont reproductibles à l'aide des configurations sous contrôle de version publiées dans les guides llm-d.