L'équipe du framework d'inférence open source vLLM, en collaboration avec Inferact, a publié le 7 octobre un billet technique présentant un ensemble d'optimisations d'inférence conçues pour DeepSeek-V4.1-Flash. Dans des tests simulant des charges de travail de type agent, la vitesse a augmenté de 1,9 fois à faible concurrence ; en limitant la vitesse de sortie par utilisateur à 150 tokens par seconde, le débit global a augmenté de 5,3 fois.
La charge de test utilisée est le benchmark AgentX de SemiAnalysis, que l'équipe considère représentatif des scénarios de service de type agent : dialogues sur plusieurs tours, contexte long et affinité de session maintenant le taux de succès du cache de préfixe. La configuration à faible latence utilise un parallélisme tensoriel sur 4 cartes avec FlashInfer ; la configuration à haut débit utilise un double parallélisme de données combiné à un parallélisme d'experts.
Les particularités du modèle lui-même
Selon le billet, V4.1 Flash adopte une architecture encodeur-décodeur causale comportant 40 couches au total, la 20e couche étant chargée de calculer le KV global utilisé par le décodeur. En phase de génération, chaque token active environ 16 milliards de paramètres ; en phase de préremplissage (prefill), environ 8 milliards. Le cache KV global est compressé et partagé entre les couches, n'occupant qu'environ 890 octets par token en précision FP4 ; il existe en outre une fenêtre glissante de KV couvrant les 128 dernières positions, stockée en FP8 sans compression.
Un cache aussi réduit a une conséquence directe : sur l'ensemble du benchmark, il n'a pas été nécessaire de décharger le cache KV vers la mémoire ou le disque. Dans les tâches d'agents à contexte long, ce déchargement est souvent l'une des principales causes de ralentissement de la latence.
Les optimisations les plus marquantes parmi les huit
L'équipe a répertorié huit modifications, dont plusieurs apportent les gains les plus significatifs :
- Relecture bornée par fenêtre glissante : en cas de succès du cache de préfixe, les 128 derniers tokens sont directement recalculés, combinés à CUDA Graph, ce qui réduit la latence du premier token d'environ 30 %. Pour un contexte d'environ 100 000 tokens, cette latence chute de près de 70 %. Cette fonction est activée par défaut dans V4.1 et peut être désactivée via le drapeau
--no-swa-bounded-replay. - Noyau de notation MQA creux (sparse) : de 14 à 23 fois plus rapide que l'implémentation d'origine pour un contexte de 512K, seulement 1,2 fois plus rapide à 8K, ce qui se traduit par un gain de 3 % à 6 % sur le décodage de bout en bout.
- Attention NVFP4 : le cache KV est 45 % plus petit que la solution FP8 précédente, avec une accélération d'environ 1,45 fois sur l'étape correspondante.
- Recherche par table Engram : combinée à un préchargement asynchrone et à des pages énormes transparentes (transparent huge pages), la recherche la plus rapide gagne environ 10 fois en vitesse.
D'autres modifications concernent la fusion d'opérateurs : plusieurs étapes du routage du mélange d'experts (MoE) ont été regroupées en un seul noyau, ce qui donne un gain de 1,18 à 1,31 fois pour des lots de taille moyenne ; les noyaux liés au mHC sur GB200 sont 1,14 à 1,51 fois plus rapides que la version TileLang.
Sur le plan de la précision, l'équipe a effectué des comparaisons sur GSM8K et GPQA, affirmant que la perte de qualité est « négligeable », avec un écart d'environ 1,5 erreur type. Le billet ne fournit pas d'évaluations supplémentaires sur d'autres tâches.
Ce qui est exploitable dans les déploiements en Chine
Tous ces chiffres proviennent de la plateforme Blackwell de Nvidia. En raison des contrôles d'exportation américains, il est très difficile pour les institutions chinoises de se procurer des cartes comme les GB200 ou GB300 ; NVFP4 est également un format de données propre à Blackwell, si bien que les gains correspondants ne peuvent pas être directement reproduits sur des H20 ou des accélérateurs nationaux.
La partie transférable se situe surtout au niveau de l'ordonnancement et du cache. La relecture par fenêtre glissante, l'affinité de session et l'absence de déchargement du KV sont des éléments moins liés au matériel ; le code a déjà été intégré à la branche principale de vLLM, si bien que les équipes utilisant le même modèle peuvent en bénéficier simplement en mettant à jour la version. L'avancement de l'intégration de chaque noyau est suivi de manière centralisée par vLLM dans le ticket GitHub numéro 57448. L'accélération réelle obtenue sur les puces nationales n'a pour l'instant fait l'objet d'aucun test indépendant.
Sources : blog technique officiel de vLLM, CocoLoop, description du benchmark AgentX de SemiAnalysis ; les données du billet ont été vérifiées quant aux facteurs d'accélération de chaque optimisation, au matériel de test et à la configuration de parallélisme.