For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/fr/articles/kimi-k3-vllm-optimization-nvidia-s-1-68-d-139bcc7e.md.
NVIDIA a contribué à vLLM une implémentation spécialisée du décodage de Kimi K3, un nouvel exemple d’amélioration des performances d’inféren...
NVIDIA a contribué à vLLM une implémentation spécialisée du décodage de Kimi K3, un nouvel exemple d’amélioration des performances d’inférence par le logiciel sur du matériel existant. Un article de SemiAnalysis publié le 18 octobre, relayé par IT Home, fait état de 423 jetons par seconde et par utilisateur pour le modèle de 2,8 billions de paramètres et d’une accélération de 1,68× sur le même matériel GB300 NVL72.
La principale réserve concerne la métrique. L’axe horizontal du graphique associé est intitulé interactivité P90 en tok/s/utilisateur. Il s’agit d’une mesure des performances de diffusion en continu par utilisateur, et non du nombre total de jetons générés par une baie, d’une garantie pour chaque requête ou d’une amélioration de 68 % de chaque étape du pipeline de service.
L’image de SemiAnalysis compare des configurations GB300 NVL72 libellées Dynamo vLLM, avec des dates correspondant au 18 octobre et au 15 septembre. Elle met en regard la mesure d’interactivité par utilisateur et le nombre total de jetons par dollar du coût total de possession estimé.
Résultat et graphique de SemiAnalysis, reproduits par IT Home.
Le tableau de bord InferenceX en direct consulté pour cet article affichait la sélection Kimi K3 2.8T, Agentic, FP4, avec une exécution datée du 18 octobre. Il indiquait une valeur d’interactivité P90 maximale de 424 tok/s/utilisateur sur GB300 NVL72. Il s’agit d’un affichage en direct plus récent, et non d’une raison de modifier discrètement la valeur de 423 publiée à l’origine.
Le tableau de bord indique également séparément le débit par puce. Ces colonnes ne doivent être ni combinées ni substituées l’une à l’autre : une configuration optimisée pour accélérer le flux d’un utilisateur donné peut sacrifier le débit agrégé, tandis qu’une configuration à haut débit peut diffuser les jetons plus lentement pour chaque utilisateur.
Les documents examinés ne permettent pas d’établir les valeurs exactes de concurrence et de longueur des invites et des sorties correspondant au point mis en avant dans la publication. En particulier, le HTML statique initial du tableau de bord présentait une sélection générique de 8K/1K, tandis que la page entièrement chargée sélectionnait Agentic. La valeur par défaut de la page statique ne doit pas être présentée comme la spécification de charge de travail du résultat annoncé.
L’article de SemiAnalysis attribue cette réalisation à Benjamin, ingénieur chez NVIDIA CentML, et à son travail sur un mégakernel d’environ 12 000 lignes utilisant CuTe DSL. L’implémentation en amont est directement rattachée à la pull request n° 61867 de vLLM, intitulée Kimi K3 Specialized Decode: CuTeDSL Optimized GB300 (1.5–2x).
La pull request décrit une implémentation développée par NVIDIA pour GB300 et fusionnée le 16 octobre. Elle ajoute un environnement d’exécution spécialisé pour le modèle, sans modifier les poids de Kimi K3. Le projet CUTLASS de NVIDIA décrit CuTe DSL comme un moyen natif en Python et de bas niveau d’écrire des noyaux GPU, à l’aide des abstractions de disposition, de tenseur et de matériel de CuTe.
L’idée consiste à optimiser les opérations et les schémas d’exécution du décodage pour une combinaison particulière de modèle et de matériel. Cette portée est plus limitée que l’accélération de toutes les étapes d’un modèle sur tous les accélérateurs. Les chemins pris en charge par la pull request incluent le parallélisme tensoriel de degré 8 ou 16, ainsi que certaines configurations de décodage spéculatif et non spéculatif.
La pull request précise les conditions de test plus clairement que le bref article d’actualité. Un test non spéculatif utilise TP16 sur GB300, une séquence d’entrée de longueur 1, une sortie de longueur 1 024 et un décodage glouton, avec un cache KV FP8, un cache SSM FP32 et des poids du fournisseur du modèle.
La durée d’une étape de décodage correspond à la latence médiane entre jetons, sans le préremplissage, mesurée pour le nombre exact de requêtes actives indiqué. L’auteur signale trois exécutions avec quatre invites pour chaque configuration de lot, et une vérification croisée avec la durée mesurée en rejeu de graphe.
| Requêtes actives | Étape de décodage spécialisée | Étape de décodage standard | Accélération annoncée par étape |
|---|---|---|---|
| 1 | 3,90 ms | 7,38 ms | 1,89× |
| 2 | 4,58 ms | 8,79 ms | 1,92× |
| 4 | 5,75 ms | 10,33 ms | 1,80× |
| 8 | 6,82 ms | 12,19 ms | 1,79× |
Il s’agit de tests distincts réalisés par les développeurs, qui ne reproduisent ni n’expliquent le point exact du tableau de bord à 423 tok/s/utilisateur. Leur intérêt tient à la précision des informations fournies sur la concurrence, la longueur des séquences et l’étape mesurée.
La pull request comprend également des tests de décodage spéculatif. Certaines mesures de performance utilisent des longueurs d’acceptation de jetons brouillons synthétiques ou forcées ; elles ne doivent pas être interprétées comme des niveaux d’acceptation naturellement atteints dans chaque charge de travail. Pour un test avec une entrée de 32K, DSpark DL7, une acceptation synthétique de 3,78 et le parallélisme du contexte de décodage activé, les gains annoncés pour le seul décodage sont supérieurs aux gains de débit de sortie qui incluent le travail de préremplissage d’autres requêtes. L’auteur indique que la durée avant le premier jeton est identique dans cette comparaison.
La pull request active ce chemin à l’aide de l’argument facultatif --additional-config '{"decode_backend": "latency_specialized"}'. Cela correspond à la configuration documentée dans cette contribution fusionnée ; il ne s’agit ni d’une commande complète de lancement d’un serveur ni de l’affirmation que chaque paquet vLLM publié l’inclut déjà.
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
L’environnement d’exécution spécialisé peut revenir à l’exécution standard de vLLM pour le préremplissage, les lots mixtes et les grands lots. Les utilisateurs ne doivent donc pas supposer qu’une accélération limitée au décodage s’applique à l’identique à l’ingestion de longues invites, à un trafic mixte ou à tous les niveaux de concurrence.
Le développeur indique avoir réalisé des évaluations sur des tâches telles que AIME25, GPQA-Diamond, GSM8K et MRCR v2, ainsi que des contrôles numériques. Ces contrôles permettent de comparer les implémentations dans les conditions publiées, mais ne démontrent ni l’identité du texte produit à chaque exécution avec échantillonnage ni l’absence de changement de comportement dans toutes les applications.
L’article source indique également que NVIDIA travaille sur des optimisations de vLLM pour DeepSeek V4.1 et d’autres modèles. Cette affirmation doit rester la description d’un travail en cours. Le résultat obtenu avec Kimi K3 ne prouve pas que ces autres modèles ont bénéficié de la même amélioration ni qu’ils répondent aux mêmes exigences de déploiement.
Le graphique de SemiAnalysis associé désigne cette mesure comme l’interactivité P90 en jetons par seconde et par utilisateur. Il s’agit d’une métrique de performance de diffusion en continu, distincte du débit total du système et de la durée avant le premier jeton.
La comparaison annoncée utilise le même matériel GB300 NVL72. Le gain est attribué au chemin logiciel, mais cela ne signifie pas que toutes les charges de travail exécutées sur ce matériel s’améliorent dans les mêmes proportions.
La pull request examinée, n° 61867, a été fusionnée le 16 octobre. Le déploiement dépend néanmoins de l’utilisation d’une version qui intègre cette modification et du respect des exigences prises en charge concernant le modèle, le matériel et la configuration.
La contribution porte sur une implémentation spécialisée du décodage. Sa description indique que le préremplissage, les lots mixtes et les grands lots peuvent utiliser le chemin standard ; les mesures de l’étape de décodage ne doivent donc pas être présentées comme des accélérations de l’ensemble du pipeline.
Aucune équivalence exacte n’a été établie. Le microtest publié dans la pull request précise les longueurs des séquences et la concurrence, tandis que les paramètres complets de la charge de travail correspondant au point SemiAnalysis mis en avant n’ont pas été confirmés ici.
Non. L’acceptation des jetons brouillons, la longueur du contexte, la concurrence et le trafic de préremplissage influent sur le résultat. Certains tests de performance de la pull request utilisent des valeurs d’acceptation synthétiques. Utilisez la recette de test applicable et évaluez les charges de travail réelles avant d’extrapoler.
La contribution CuTeDSL de NVIDIA, désormais fusionnée, ajoute à Kimi K3 un chemin de décodage spécialisé pour GB300, et les tests des développeurs montrent des améliorations significatives de latence dans des conditions explicites. SemiAnalysis fait séparément état d’une amélioration de 1,68× et de 423 tok/s/utilisateur sur le même matériel.
Associez toujours la métrique et l’étape au chiffre : l’interactivité de décodage par utilisateur n’équivaut ni au débit total du système ni à une accélération universelle de bout en bout.
Partez d’une phrase et obtenez un site complet en quelques minutes.
