Optimisation de Flame pour égaler le débit de vLLM autonome

Des chercheurs ont comparé les performances de Flame, un framework de serving Python intégrant vLLM, avec celles d'instances vLLM autonomes. Publiée le 24 octobre 2026, cette étude détaille comment des stratégies de réglage spécifiques ont permis à Flame d'atteindre une quasi-parité avec le moteur de référence sur deux GPU NVIDIA B200. Les résultats soulignent l'importance de la mise en cache des préfixes et de l'admission asynchrone des requêtes pour minimiser la surcharge dans les déploiements de grands modèles de langage.

Ce qui s'est passé

L'évaluation s'est concentrée sur deux charges de travail distinctes utilisant le modèle Llama 3.1 8B Instruct. La première charge impliquait 64 requêtes sans réutilisation de documents, tandis que la seconde comportait 256 requêtes où quatre questions étaient posées sur chacun des quatre documents, permettant ainsi la réutilisation des préfixes. Dans les deux scénarios, le système traitait de courtes rafales finies de trafic plutôt que des charges continues en régime permanent. L'objectif était de déterminer si Flame pouvait maintenir au moins 99 % du débit obtenu par une configuration soignée de vLLM autonome.

Les premiers tests ont révélé un écart significatif lors de l'utilisation des configurations par défaut. Cependant, après la mise en œuvre d'un placement persistant des workers pour améliorer la réutilisation du cache, les chercheurs ont réduit considérablement la différence. D'autres optimisations incluaient l'augmentation des tailles de lot, le passage à l'admission asynchrone du moteur et l'application d'une compression sans perte aux entrées. Dans la configuration finale, le débit médian de complétion de Flame n'était inférieur que de 0,55 % à celui de vLLM autonome sans réutilisation de documents, et de 0,86 % avec réutilisation des préfixes. Bien que deux paires d'essais sur cinq aient manqué la cible stricte de 99 % lors des tests de réutilisation, l'écart maximal observé n'était que de 2,03 %.

Comment cela fonctionne

Le mécanisme central pour améliorer les performances dans les deux systèmes était l'affinité des préfixes. Lorsqu'un assistant répond à plusieurs questions concernant le même document, il traite à répétition les mêmes jetons initiaux. En maintenant ce préfixe sur un seul GPU, le système évite de reconstruire les clés et les valeurs d'attention depuis zéro. Les chercheurs ont implémenté une carte côté client qui hache les blocs de jetons pour attribuer les préfixes inédits au shard ayant la charge de préremplissage estimée la plus faible. Cela garantissait que les questions suivantes portant sur un document spécifique atteignaient toujours le même worker, permettant à vLLM de réutiliser efficacement les blocs KV résidents.

Au-delà de la mise en cache, l'équipe a traité la manière dont les requêtes étaient admises dans le moteur d'inférence. L'adaptateur Flame original passait les lots de manière synchrone, obligeant les tâches ultérieures à attendre la fin des invocations en cours. La version optimisée utilisait une API asynchrone qui admettait toutes les requêtes d'un lot simultanément. Elle employait également une compression zlib niveau 1 pour réduire la taille des entrées transmises, ce qui est particulièrement efficace pour les prompts riches en texte. Enfin, le gel du tas de démarrage Python a réduit les pauses de ramasse-miettes pendant l'inférence, stabilisant davantage le débit.

Détails clés

• Les expériences utilisaient deux GPU NVIDIA B200 exécutant vLLM 0.28.0 et Torch 2.13.0+cu130.
• L'affinité des préfixes a augmenté le débit médian de 77,5 % pour vLLM autonome et de 73,4 % pour Flame dans les scénarios de réutilisation.
• Le débit médian final pour Flame était de 7,586 requêtes/s sans réutilisation et de 28,350 requêtes/s avec réutilisation.
• La compression des entrées a réduit la taille de l'entrée encodée du service pour la rafale de réutilisation de plus de 6 Mo à environ 388 Ko.
• Le gel du tas de démarrage a réduit les pauses maximales de ramasse-miettes par worker de 8,80 ms à 4,59 ms.
• L'étude n'a pas démontré d'avantage de performance provenant du planificateur sensible aux données de Flame dans ces tests spécifiques.

Pourquoi c'est important

Pour les ingénieurs construisant des services LLM en production, cette comparaison clarifie d'où provient réellement la surcharge dans les frameworks de serving encapsulés. Elle montre que la pénalité liée à l'utilisation d'une couche d'orchestration de plus haut niveau comme Flame n'est pas inhérente à l'architecture, mais découle de paramètres sous-optimaux par défaut en matière de regroupement (batching) et de synchronisation. En comprenant que la localité des préfixes et l'admission asynchrone sont critiques, les développeurs peuvent ajuster leurs propres stacks pour minimiser les pics de latence et maximiser l'utilisation du GPU.

Les conclusions mettent également en garde contre l'hypothèse selon laquelle les fonctionnalités d'un framework se traduisent automatiquement par des gains de performance. Le planificateur sensible aux données de Flame n'a pas surpassé le mappage explicite côté client, plus simple, utilisé dans les tests. Cela suggère que, pour de nombreux cas d'usage, des stratégies de routage directes combinées à une gestion rigoureuse des ressources peuvent être plus efficaces que des algorithmes de planification complexes. Les équipes devraient privilégier des facteurs mesurables tels que les taux de réussite du cache et l'occupation des lots plutôt que des avantages théoriques de planification.

Ce que vous pouvez faire

• Implémentez l'affinité des préfixes dans votre routage client pour garantir que les requêtes partageant un contexte atteignent la même réplica GPU.
• Passez aux API asynchrones pour l'admission au moteur afin d'empêcher le traitement par lots de bloquer les nouvelles requêtes.
• Activez la compression sans perte pour les entrées riches en texte afin de réduire la surcharge réseau et mémoire lors du transfert.
• Ajustez les fenêtres et les limites de formation des lots pour équilibrer latence et débit en fonction de vos motifs de trafic.
• Surveillez les pauses du ramasse-miettes et envisagez de geler les objets de longue durée lors de l'initialisation des workers.
• Validez les performances avec des tests de rafales finies qui imitent vos motifs d'utilisation réels, y compris les scénarios de réutilisation des préfixes.