Édition Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# La voie de décodage Kimi K3 de vLLM atteint 842 jetons par seconde dans un test précis sur GB300

> vLLM annonce 842 contre 488 jetons de décodage agrégés par seconde pour Kimi K3 sur 16 GPU GB300, avec une configuration DSpark précise. Le préremplissage est exclu.

By BIG CHANGE Editorial

Published: 2026-10-18T20:03:34.885Z
Updated: 2026-10-18T20:03:34.885Z
Canonical: https://bigchange.ai/blog/kimi-k3-vllm-gpu-inference-benchmark

![Conceptual charcoal illustration of the rear of a generic compute cabinet with rack units and secured cables in a data-center aisle.](https://bigchange.ai/api/media/file/kimi-k3-decode-cabinet-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual GB300 chassis, vLLM installation or measured result is depicted.

vLLM a intégré une voie de décodage facultative, propre à Kimi K3, sur les GPU NVIDIA Blackwell. Dans son [compte rendu du 16 octobre](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel), le projet annonce 842 jetons générés par seconde contre 488 pour vLLM standard, soit un gain de 1.73×. Cette comparaison a un périmètre étroit : une requête à la fois, parallélisme de tenseurs sur 16 GPU GB300, décodage spéculatif DSpark avec sept jetons brouillons, longueur d’acceptation synthétique de six, entrée d’un jeton et sortie de 1000 jetons. Ce chiffre mesure le débit agrégé de décodage après le préremplissage. Il ne mesure pas la rapidité d’exécution d’une requête utilisateur complète.

Pour les ingénieurs qui envisagent d’évaluer cette voie, l’avancée utile tient à l’association d’un résultat de décodage important et d’une description assez explicite de son domaine d’application. L’[implémentation intégrée](https://github.com/vllm-project/vllm/pull/61867) s’active volontairement avec `decode_backend: latency_specialized` ; le réglage par défaut `auto` conserve le décodage standard. Selon vLLM, la voie spécialisée vise les déploiements GB300 avec huit ou 16 GPU dans un même domaine NVLink, tandis que les préremplissages, les lots mixtes et les étapes non prises en charge reviennent au parcours standard de propagation avant du modèle.

## Où passait le temps

Kimi K3 est un grand modèle à mélange d’experts, selon sa [fiche de modèle](https://huggingface.co/moonshotai/Kimi-K3). Pendant le décodage, un système d’inférence exécute à répétition l’attention, choisit des experts et échange des données entre GPU pour produire les jetons suivants. L’équipe vLLM a créé une voie CuTe DSL qui spécialise ces opérations pour les formes de tenseurs attendues. Son compte rendu décrit des noyaux de projection de l’attention différents pour les petits lots et les lots plus grands ; la fusion de la projection de sortie de l’attention, de la réduction entre GPU et des opérations résiduelles suivantes ; des calculs de routeur répartis ; le chevauchement des experts partagés et routés ; et le préchargement des poids pendant les communications. Dans une trace par couche présentée dans le billet, la voie spécialisée utilise 13 noyaux et 69 microsecondes, contre 23 noyaux et 130 microsecondes pour vLLM standard. Il s’agit d’une trace annoncée pour la configuration illustrée, pas d’une mesure de latence applicative.

Le périmètre importe autant que la conception des noyaux. La [pull request](https://github.com/vllm-project/vllm/pull/61867) décrit la validation GB300 en TP8 et TP16, le décodage non spéculatif jusqu’au lot 64, la vérification DSpark avec trois à sept jetons brouillons et le parallélisme de contexte de décodage facultatif. Elle précise que le travail sur les performances utilisait un cache KV FP8, un cache SSM FP32 et les poids du fournisseur du modèle. La voie laisse inchangés les poids, l’ordonnancement, l’échantillonnage et le générateur de brouillons DSpark. Une équipe d’inférence peut ainsi comparer une implémentation de décodage modifiée dans un environnement familier, mais cela signifie aussi que l’optimisation n’accélère pas chaque partie du service.

## Lire séparément les deux tableaux de benchmark

Le résultat de 842 contre 488 utilise **TP16 sur 16 GPU GB300, lot 1, DSpark avec sept jetons brouillons, longueur d’acceptation synthétique six, DL=7, ISL=1 et OSL=1k**. vLLM appelle cette métrique le nombre de jetons de décodage agrégés par seconde et exclut le préremplissage. L’acceptation synthétique fixe combien de jetons proposés le benchmark accepte ; ce n’est pas un taux d’acceptation mesuré sur les prompts des utilisateurs. Un déploiement avec d’autres prompts, comportements d’acceptation, tailles de lot ou longueurs d’entrée nécessite ses propres mesures.

Le billet fournit aussi un [tableau sans décodage spéculatif](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation). En TP16, par exemple, il annonce 256.4 jetons par seconde au lot 1 et 3606.1 au lot 64, avec des gains respectifs de 1.88× et 1.62× face aux configurations standard correspondantes. Ce sont des résultats agrégés du groupe TP sans décodage spéculatif. On ne peut pas les combiner au chiffre DSpark pour affirmer une expérience plus rapide par utilisateur au lot 64.

Un autre chiffre du billet concerne [AgentX](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#improvement-on-agentx), une charge qui rejoue les profils de trafic d’agents de programmation avec du contenu synthétique. vLLM annonce une interactivité P90 de 403.2 contre 223.7 jetons par seconde et par utilisateur avec une concurrence d’une requête. Le résultat optimisé a été exécuté sur **16 GPU GB300**, tandis que la comparaison précédente utilisait **huit GPU**. Comme le nombre de GPU change en même temps que l’implémentation, cette comparaison de 1.8× n’isole pas l’amélioration de la voie de décodage. AgentX comprend aussi des contextes plus longs, des tours de dialogue, des pauses et la réutilisation du cache : sa métrique répond donc à une autre question que le benchmark de décodage pur.

Il existe un léger écart entre le billet public et le précédent [tableau de performances de la pull request](https://github.com/vllm-project/vllm/pull/61867) : ce dernier indique 838 contre 489 jetons par seconde pour TP16, lot 1, DSpark DL7 et acceptation synthétique six. La comparaison de 842 contre 488 du billet est la source du chiffre de 1.73× employé ici. Le tableau antérieur apporte un élément utile sur une exécution similaire, mais les deux paires ne doivent pas être mélangées. vLLM a publié le code et sa propre validation ; BIG CHANGE n’a reproduit aucune des deux exécutions.

## Ce qu’exigerait une évaluation

Une comparaison locale pertinente partirait de la [PR intégrée et de sa configuration déclarée](https://github.com/vllm-project/vllm/pull/61867) : mêmes poids Kimi K3 du fournisseur du modèle, système GB300 avec 16 GPU dans un domaine NVLink, TP16, formats de cache et configuration DSpark exacte du test mis en avant. Exécutez le mode standard `auto` et le mode facultatif `latency_specialized` avec la même charge, puis consignez le débit de décodage séparément du préremplissage, du délai avant le premier jeton, du débit de sortie et de la latence par requête. Une station de travail ou un plus petit ensemble de GPU ne peut pas reproduire directement le résultat phare à 16 GB300. Le billet n’établit pas de coût de location pour cette configuration.

Le [compte rendu de validation de la PR](https://github.com/vllm-project/vllm/pull/61867) présente des vérifications numériques et des évaluations du modèle comprenant AIME25, GPQA-Diamond et un test MRCR à long contexte. Il décrit également une erreur de synchronisation découverte pendant le développement et des variations dans les tests à longue sortie. Ces vérifications donnent davantage à examiner qu’un graphique de vitesse, tout en restant les éléments produits par les auteurs de l’implémentation. Une équipe d’inférence doit décider si son matériel réel, sa mise en lots, ses longueurs de contexte et son acceptation spéculative ressemblent assez aux configurations prises en charge pour justifier de mesurer cette voie facultative sur son propre trafic.

## Le grand changement

La voie Kimi K3 intégrée à vLLM rend disponible une implémentation GPU de décodage spécialisée et facultative, accompagnée d’un benchmark et d’un historique de validation documentés. Le résultat public le plus marquant est **842 contre 488 jetons de décodage agrégés par seconde, soit 1.73×, en TP16 sur 16 GPU GB300 au lot 1, avec sept jetons brouillons DSpark et une longueur d’acceptation synthétique de six**. Le préremplissage est exclu. L’amélioration éventuelle d’un service dépend de son matériel et de la charge complète de ses requêtes.

## Sources et lectures complémentaires

- [Le billet technique de vLLM du 16 octobre](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) explique les changements de décodage et fournit la configuration 842/488, le tableau non spéculatif et la comparaison AgentX. Les résultats sont rapportés par le projet et Benjamin Chislett, contributeur NVIDIA.
- [La pull request vLLM #61867 intégrée](https://github.com/vllm-project/vllm/pull/61867) documente le réglage facultatif, les configurations prises en charge, les limites de l’implémentation, la validation et un précédent tableau DSpark de 838/489. C’est la trace du code et des résultats, pas une reproduction indépendante.
- [La fiche du modèle Kimi K3 de Moonshot AI](https://huggingface.co/moonshotai/Kimi-K3) identifie le modèle et les poids auxquels l’implémentation se réfère.
- [La méthodologie AgentX](https://inferencex.semianalysis.com/agentx) décrit la charge de rejeu du trafic derrière la comparaison d’interactivité distincte.

## Sources

- [vLLM, Optimisation poussée de Kimi K3 dans vLLM : avancer vite et de manière responsable (2026-10-16)](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — Compte rendu technique de première main et source du résultat 842/488, 1.73×. Il précise TP16 sur 16 GPU GB300, lot 1, DSpark DL7, AL6 synthétique, ISL1, OSL1k et TPS de décodage agrégés hors préremplissage. Il fournit aussi des résultats distincts non spéculatifs et AgentX.
- [Pull request vLLM #61867, décodage spécialisé de Kimi K3](https://github.com/vllm-project/vllm/pull/61867) — Implémentation intégrée et relevé de validation effectuée par les auteurs. Documente le réglage facultatif final, les configurations prises en charge et le retour à la voie standard. Le tableau DSpark antérieur indique 838/489 en TP16 B1 avec AL6 synthétique ; ces chiffres ne sont donc pas combinés à la paire du billet.
- [Moonshot AI, fiche du modèle Kimi K3](https://huggingface.co/moonshotai/Kimi-K3) — Identifie le modèle et les poids du fournisseur ; n’établit pas indépendamment les performances de vLLM.
- [InferenceX, Méthodologie et jeux de données AgentX](https://inferencex.semianalysis.com/agentx) — Décrit la charge de rejeu du trafic utilisée pour la comparaison d’interactivité publiée séparément. La comparaison vLLM modifie également le nombre de GPU.