vLLM apprend aux nœuds decode à renvoyer le KV-cache et réduit le TTFT jusqu'à 3,3 fois

L'équipe de vLLM a ajouté à l'inférence désagrégée un transfert bidirectionnel du KV-cache. Les nœuds prefill peuvent désormais récupérer auprès des nœuds decode le cache déjà calculé des tours précédents du dialogue, sans recalculer tout le contexte à chaque tour. Sur les longs prompts multi-tours, le temps jusqu'au premier token (TTFT) baisse jusqu'à 3,3 fois.

Où le temps se perdait

Dans une architecture de disaggregated serving, les phases prefill et decode tournent sur des pools de GPU distincts. Le prefill traite le prompt et construit le KV-cache, puis le transmet à un nœud decode, qui génère la réponse token par token. La séparation se justifie : le prefill est limité par le calcul, le decode par la mémoire et la bande passante, et chaque pool peut être dimensionné pour sa propre charge.

Mais le transfert du cache était à sens unique, du prefill vers le decode. Dès le deuxième tour, du travail superflu apparaissait. Le client envoie tout l'historique du dialogue plus la nouvelle réplique. Le cache de cet historique se trouve déjà sur le nœud decode, mais le nœud prefill n'en sait rien et recalcule tout.

Pour un chat classique, c'est tolérable. Pour des agents, non. Une boucle agentique compte des dizaines d'étapes : appel d'outil, réponse, raisonnement, appel suivant. Le contexte grossit jusqu'à plusieurs dizaines de milliers de tokens, alors que la part nouvelle à chaque étape reste faible. On paie le prix fort du prefill pour ce qui a déjà été calculé une minute plus tôt.

Comment fonctionne le canal retour

L'idée est simple. Après avoir généré la réponse, le nœud decode conserve le KV-cache du prompt comme celui des tokens générés. Quand le tour suivant arrive, le nœud prefill peut lui demander le préfixe correspondant, le recevoir et ne calculer que la nouvelle queue. Ensuite, tout se passe comme avant : le cache complet repart vers le decode.

Au lieu de recalculer tout l'historique, le système transfère par le réseau des tenseurs déjà prêts. Le gain apparaît quand ce transfert via l'interconnexion coûte moins cher qu'un nouveau calcul. Plus le préfixe commun est long, plus l'écart est marqué.

Les chiffres clés de l'annonce :

• accélération du TTFT : jusqu'à 3,3x ;
• scénario : longs prompts multi-tours ;
• ce qui est économisé : le calcul de prefill redondant sur l'historique déjà traité ;
• sens du transfert : decode → prefill, en plus de prefill → decode ;
• plateforme : vLLM en configuration avec nœuds prefill et decode séparés.

La valeur de 3,3x est présentée comme une borne supérieure. C'est le meilleur cas sur de longs dialogues, et non un résultat moyen garanti. Dans un échange court, avec un petit préfixe, la différence sera nettement plus modeste.

Ce que l'annonce ne dit pas

La version abrégée de l'annonce ne donne pas les détails dont dépend l'effet réel : quel transport et quel connecteur sont utilisés, sur quel matériel et avec quel modèle les mesures ont été faites, comment la charge réseau évolue et quel est l'impact du schéma sur le débit global. Ces éléments figurent probablement dans le texte complet du blog, qu'il vaut mieux lire avant tout déploiement.

Il reste aussi une question d'architecture. Pour qu'un nœud decode puisse renvoyer le cache, il doit le conserver, or la HBM des GPU est limitée. Plus les sessions durent, plus la pression sur la mémoire augmente et plus la politique d'éviction compte. Si le cache a déjà été évincé, il n'y a aucun gain et le prefill revient au recalcul complet.

À qui cela servira en pratique

D'abord aux équipes qui exploitent déjà vLLM en configuration désagrégée et servent des agents, des assistants de code ou d'autres sessions longues. Pour elles, le TTFT aux dernières étapes de la boucle détermine la vitesse perçue du produit.

Avant de déployer, il faut vérifier sur son propre trafic :

• quelle est la part de préfixe répétée d'un tour à l'autre et comment elle croît au fil de la session ;
• si la bande passante de l'interconnexion entre nœuds prefill et decode est suffisante ;
• combien de temps les nœuds decode conservent le cache et à quelle fréquence il est évincé avant le tour suivant ;
• comment évoluent les p95/p99 du TTFT, et pas seulement le meilleur résultat.

Si les préfixes sont longs et que les sessions tiennent dans la fenêtre de conservation du cache, l'effet peut approcher celui annoncé. Si les dialogues sont courts ou disparates, le bénéfice sera moindre et la complexité supplémentaire du schéma pourrait ne pas être rentabilisée.