vLLM réduit la latence des agents multi-tours grâce au transfert bidirectionnel du cache KV
Imagen generada con gpt-image-2.5-sunburst para InferamaSource ↗
01

Le défi de la latence dans l'inférence découplée

L'inférence des grands modèles de langage (LLM) est devenue un goulot d'étranglement critique pour les applications agentiques, où la latence accumulée entre les tours affecte directement l'expérience utilisateur. Dans les architectures découplées, les phases de préremplissage (prefill) et de décodage (decode) s'exécutent sur des nœuds séparés pour optimiser l'utilisation des ressources, mais cette séparation introduit une dépendance critique : le transfert du cache de clés et de valeurs (KV) entre ces nœuds.

Traditionnellement, la gestion du cache KV se limitait à la mémoire locale de chaque instance. Cependant, dans les charges de travail multi-tours, le contexte de la conversation croît de manière exponentielle. Recalculer ce contexte à chaque tour génère une surcharge computationnelle inutile. L'évolution de vLLM vers un modèle de transfert bidirectionnel vise à résoudre ce problème en permettant aux nœuds de prefill et de decode de partager et de réutiliser l'état KV précédemment calculé, minimisant ainsi le temps d'inactivité et le recalcul.

02

Mécanisme de transfert push-based et bidirectionnel

Le cœur de cette optimisation réside dans l'utilisation d'un connecteur push-based basé sur NIXL (NVIDIA Inference Xfer Library). Contrairement aux modèles pull-based, où le nœud de décodage sollicite activement les données, le modèle push-based permet au nœud de prefill d'envoyer proactivement le cache KV au nœud de décodage dès qu'il est disponible. Cela élimine la latence d'attente associée à la demande et à la négociation du transfert.

La nature bidirectionnelle de ce transfert est cruciale pour les agents multi-tours. Non seulement le cache du prefill est transféré vers le decode pour initier la génération, mais il est également possible de mettre à jour et de retourner des états intermédiaires. Cela signifie qu'à la fin d'un tour, le cache KV résultant peut être stocké et réutilisé au tour suivant, évitant au système de traiter chaque interaction comme une demande indépendante depuis zéro.

Flux de transfert bidirectionnel

Processus simplifié de la gestion du cache KV dans un cycle multi-tours.

  1. 01Tour N : Le nœud de prefill traite le nouveau prompt et le cache KV accumulé du tour précédent.
  2. 02Transfert Push : Le cache KV mis à jour est envoyé proactivement au nœud de décodage.
  3. 03Décodage : Le nœud de decode génère la réponse sans recalculer le contexte précédent.
  4. 04Persistance : Le cache KV final est conservé pour être réutilisé au Tour N+1.
03

Impact sur le Time To First Token (TTFT)

Le Time To First Token (TTFT) est la métrique la plus sensible pour la perception de la vitesse dans les interfaces conversationnelles. En déplaçant la coordination du transfert hors du chemin critique via le connecteur NIXL, vLLM parvient à réduire drastiquement le temps qui s'écoule entre la réception de la demande et la génération du premier jeton.

Dans les charges de travail agentiques, où le contexte d'entrée est étendu et partiellement réutilisé, la réduction du TTFT est proportionnelle à la quantité de contexte réutilisé. Le transfert bidirectionnel permet au système d'identifier quelles parties du cache existent déjà sur le nœud de destination et de ne transférer ou recalculer que ce qui est strictement nécessaire, optimisant ainsi la bande passante réseau et la latence de calcul.

04

Résultats sur les instances AWS EC2 P5en

Les benchmarks réalisés sur des instances Amazon EC2 P5en, équipées de l'interconnexion AWS EFA (Elastic Fabric Adapter), démontrent l'efficacité de cette architecture. Le réseau haute vitesse d'EFA est un prérequis fondamental pour que le transfert du cache KV ne devienne pas un nouveau goulot d'étranglement, permettant au mouvement des données d'être presque aussi rapide que l'accès à la mémoire locale.

Dans les tests avec le modèle Qwen3-32B, une réduction du TTFT de jusqu'à 1,6 fois a été observée par rapport à l'inférence découplée standard. Pour le modèle GLM-5-FP8, l'amélioration a été encore plus marquée, atteignant une réduction de 3,3 fois du TTFT. Ces chiffres confirment que la réutilisation du contexte est plus bénéfique pour les modèles avec des contextes longs et des charges de travail avec une forte réutilisation de préfixes.

Comparaison de l'amélioration du TTFT (EC2 P5en + EFA)

Réduction du Time To First Token pour les charges de travail agentiques multi-tours.

ModèleAmélioration du TTFTContexte de test
Qwen3-32B1,6xAgentique multi-tours
GLM-5-FP83,3xAgentique multi-tours
05

Implications pour les architectes IA

Pour les équipes déployant des agents IA dans le cloud, cette optimisation a un double impact : réduction des coûts et amélioration de l'expérience utilisateur. En réutilisant le cache KV, le nombre d'opérations de calcul (FLOPs) nécessaires par tour est réduit, ce qui se traduit par une consommation GPU moindre par demande. Cela permet de servir plus d'utilisateurs simultanés avec la même infrastructure ou de réduire la taille de la flotte de GPU pour une charge de travail donnée.

De plus, l'amélioration de la latence est critique pour respecter les SLO (Service Level Objectives) dans les applications interactives. L'architecture de vLLM, combinée à l'infrastructure réseau haute vitesse, positionne l'inférence découplée non seulement comme une technique d'optimisation du débit, mais comme une stratégie viable pour les applications à faible latence et haute interactivité, telles que les copilotes de code et les assistants conversationnels complexes.

Questions ouvertes

  • Les benchmarks proviennent d'AWS et n'ont pas été vérifiés de manière indépendante dans d'autres environnements cloud ou sur d'autres matériels.
  • L'impact exact sur la consommation de mémoire RAM/GPU par rapport à l'inférence monolithique n'est pas détaillé dans les sources primaires fournies.
  • La disponibilité de cette fonctionnalité dans des versions spécifiques de vLLM et sa compatibilité avec d'autres fournisseurs cloud ne sont pas spécifiées.
06

Poursuivre l’exploration

06

Sources consultées

03

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.

Proposer une correction