AI-translated from English; not yet reviewed by a fluent editor. # vLLMs Kimi K3-Dekodierpfad erreicht in einem bestimmten GB300-Test 842 Token pro Sekunde > vLLM meldet für Kimi K3 auf 16 GB300-GPUs mit einem bestimmten DSpark-Aufbau einen aggregierten Dekodierdurchsatz von 842 gegenüber 488 Token pro Sekunde. Prefill ist ausgeschlossen. 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 hat einen optionalen, modellspezifischen Dekodierpfad für Kimi K3 auf NVIDIA-Blackwell-GPUs integriert. In seinem [Bericht vom 16. Oktober](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) meldet das Projekt 842 erzeugte Token pro Sekunde gegenüber 488 mit unverändertem vLLM, ein Zuwachs um den Faktor 1.73×. Der Vergleich gilt für eng begrenzte Bedingungen: jeweils eine Anfrage, Tensorparallelität über 16 GB300-GPUs, spekulatives Dekodieren mit DSpark und sieben Entwurfs-Token, eine synthetische Akzeptanzlänge von sechs, ein Eingabe-Token und 1000 Ausgabe-Token. Die Zahl misst den aggregierten Dekodierdurchsatz nach dem Prefill. Sie misst nicht, wie schnell eine vollständige Nutzeranfrage abgeschlossen wird. Für Entwickler, die eine Erprobung dieses Pfads erwägen, liegt der nützliche Fortschritt in der Verbindung eines deutlichen Dekodierergebnisses mit einer recht genauen Beschreibung des Einsatzbereichs. Die [integrierte Implementierung](https://github.com/vllm-project/vllm/pull/61867) wird über `decode_backend: latency_specialized` ausdrücklich aktiviert; die Standardeinstellung `auto` verwendet weiterhin das bisherige Dekodierverfahren. Laut vLLM zielt der spezialisierte Pfad auf GB300-Installationen mit acht oder 16 GPUs in einer NVLink-Domäne. Prefills, gemischte Batches und nicht unterstützte Schritte fallen auf den normalen Forward-Pfad des Modells zurück. ## Wo die Zeit verbraucht wurde Kimi K3 ist laut seiner [Modellkarte](https://huggingface.co/moonshotai/Kimi-K3) ein großes Mixture-of-Experts-Modell. Beim Dekodieren führt ein Inferenzsystem wiederholt Attention aus, wählt Experten aus und tauscht Daten zwischen GPUs aus, um die nächsten Token zu erzeugen. Das vLLM-Team entwickelte einen CuTe-DSL-Pfad, der diese Operationen auf die erwarteten Tensorformen spezialisiert. Der Bericht beschreibt unterschiedliche Attention-Projektionskernel für kleine und größere Batches; die Verschmelzung von Attention-Ausgabeprojektion, GPU-übergreifender Reduktion und anschließenden Residualoperationen; aufgeteilte Router-Berechnungen; die Überlappung gemeinsam genutzter und gerouteter Experten; sowie das Vorabladen von Gewichten während der Kommunikation. In einem gezeigten Trace pro Schicht benötigt der spezialisierte Pfad 13 Kernel und 69 Mikrosekunden, während unverändertes vLLM 23 Kernel und 130 Mikrosekunden benötigt. Dies ist ein gemeldeter Trace für die gezeigte Konfiguration, keine Angabe zur Anwendungslatenz. Der Einsatzbereich ist ebenso wichtig wie das Kerneldesign. Der [Pull Request](https://github.com/vllm-project/vllm/pull/61867) beschreibt die GB300-Validierung bei TP8 und TP16, nicht spekulatives Dekodieren bis Batch 64, DSpark-Verifikation mit drei bis sieben Entwurfs-Token und optionale Kontextparallelität beim Dekodieren. Laut Beschreibung wurden für die Leistungsoptimierung ein FP8-KV-Cache, ein FP32-SSM-Cache und die Gewichte des Modellanbieters verwendet. Modellgewichte, Scheduling, Sampling und DSpark-Drafter bleiben unverändert. So kann ein Inferenzteam eine geänderte Dekodierimplementierung in einer vertrauten übrigen Softwareumgebung vergleichen. Es bedeutet aber auch, dass die Optimierung nicht jeden Teil der Inferenz beschleunigt. ## Die beiden Benchmark-Tabellen getrennt lesen Das Ergebnis von 842 gegenüber 488 verwendet **TP16 auf 16 GB300-GPUs, Batch 1, DSpark mit sieben Entwurfs-Token, synthetische Akzeptanzlänge sechs, DL=7, ISL=1 und OSL=1k**. vLLM bezeichnet die Metrik als aggregierte Dekodier-Token pro Sekunde und schließt Prefill aus. Die synthetische Akzeptanz legt fest, wie viele vorgeschlagene Token der Benchmark annimmt; sie ist keine anhand von Nutzerprompts gemessene Akzeptanzrate. Eine Installation mit anderen Prompts, anderem Akzeptanzverhalten, anderen Batchgrößen oder Eingabelängen braucht eigene Messungen. Der Beitrag enthält auch eine [Tabelle ohne spekulatives Dekodieren](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation). Bei TP16 werden beispielsweise 256.4 Token pro Sekunde bei Batch 1 und 3606.1 bei Batch 64 gemeldet, mit Verbesserungen um 1.88× beziehungsweise 1.62× gegenüber den jeweiligen Standardkonfigurationen. Das sind aggregierte Ergebnisse der TP-Gruppe ohne spekulatives Dekodieren. Sie lassen sich nicht mit der DSpark-Zahl kombinieren, um bei Batch 64 ein schnelleres Erlebnis pro Nutzer zu behaupten. Eine weitere Zahl im Beitrag betrifft [AgentX](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#improvement-on-agentx), eine Arbeitslast, die Verkehrsmuster von Programmieragenten mit synthetischen Inhalten nachspielt. vLLM meldet bei einer Nebenläufigkeit von eins eine P90-Interaktivität von 403.2 gegenüber 223.7 Token pro Sekunde und Nutzer. Das optimierte Ergebnis lief auf **16 GB300-GPUs**, der frühere Vergleich dagegen auf **acht**. Weil sich zusammen mit der Implementierung die GPU-Anzahl ändert, isoliert dieser 1.8×-Vergleich die Verbesserung des Dekodierpfads nicht. AgentX enthält zudem längere Kontexte, Dialogrunden, Pausen und Cache-Wiederverwendung. Seine Metrik beantwortet daher eine andere Frage als der reine Dekodierbenchmark. Zwischen dem öffentlichen Beitrag und der früheren [Leistungstabelle des Pull Requests](https://github.com/vllm-project/vllm/pull/61867) gibt es eine kleine Abweichung: Letztere nennt 838 gegenüber 489 Token pro Sekunde für TP16, Batch 1, DSpark DL7 und synthetische Akzeptanz sechs. Die hier verwendete Zahl 1.73× stammt aus dem Vergleich 842 gegenüber 488 im Beitrag. Die frühere Tabelle liefert nützliche Belege für einen ähnlichen Lauf, doch die beiden Zahlenpaare dürfen nicht vermischt werden. vLLM hat den Code und die eigene Validierung veröffentlicht; BIG CHANGE hat keinen der beiden Läufe reproduziert. ## Was eine Evaluierung erfordern würde Ein aussagekräftiger lokaler Vergleich würde mit dem [integrierten PR und seiner angegebenen Konfiguration](https://github.com/vllm-project/vllm/pull/61867) beginnen: dieselben Kimi K3-Gewichte des Modellanbieters, ein GB300-System mit 16 GPUs in einer NVLink-Domäne, TP16, die Cacheformate und die exakte DSpark-Konfiguration des hervorgehobenen Tests. Führen Sie den Standardmodus `auto` und den ausdrücklich gewählten Modus `latency_specialized` unter derselben Last aus und erfassen Sie den Dekodierdurchsatz getrennt von Prefill, Zeit bis zum ersten Token, Ausgabedurchsatz und Latenz pro Anfrage. Eine Workstation oder ein kleinerer GPU-Pool kann das hervorgehobene Ergebnis mit 16 GB300 nicht direkt reproduzieren. Der Beitrag nennt keine Mietkosten für diese Konfiguration. Der [Validierungsbericht des PR](https://github.com/vllm-project/vllm/pull/61867) nennt numerische Prüfungen und Modellevaluierungen einschließlich AIME25, GPQA-Diamond und eines MRCR-Tests mit langem Kontext. Er beschreibt auch einen während der Entwicklung gefundenen Synchronisationsfehler sowie Schwankungen bei Tests mit langen Ausgaben. Diese Prüfungen bieten mehr zu untersuchen als ein Geschwindigkeitsdiagramm, bleiben aber Belege der Implementierenden selbst. Ein Inferenzteam muss entscheiden, ob seine tatsächliche Hardware, Batchverarbeitung, Kontextlängen und spekulative Akzeptanz den unterstützten Konfigurationen so weit entsprechen, dass sich eine Messung dieses optionalen Pfads mit eigenem Datenverkehr lohnt. ## Die große Veränderung Der in vLLM integrierte Kimi K3-Pfad stellt eine spezialisierte, optionale GPU-Dekodierimplementierung mit dokumentiertem Benchmark und nachvollziehbarer Validierung bereit. Das stärkste öffentliche Kernergebnis lautet **842 gegenüber 488 aggregierte Dekodier-Token pro Sekunde, also 1.73×, bei TP16 auf 16 GB300-GPUs mit Batch 1, sieben DSpark-Entwurfs-Token und einer synthetischen Akzeptanzlänge von sechs**. Prefill ist ausgeschlossen. Ob ein bestimmter Dienst davon profitiert, hängt von seiner Hardware und der vollständigen Arbeitslast seiner Anfragen ab. ## Quellen und weiterführende Informationen - [vLLMs technischer Beitrag vom 16. Oktober](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) erläutert die Dekodieränderungen und liefert die Konfiguration für 842/488, die Tabelle ohne spekulatives Dekodieren und den AgentX-Vergleich. Die Ergebnisse stammen vom Projekt und NVIDIA-Mitwirkenden Benjamin Chislett. - [Der integrierte vLLM-Pull-Request #61867](https://github.com/vllm-project/vllm/pull/61867) dokumentiert die optionale Einstellung, unterstützte Konfigurationen, Implementierungsgrenzen, Validierung und eine frühere DSpark-Tabelle mit 838/489. Er ist die Dokumentation von Code und Ergebnissen, keine unabhängige Reproduktion. - [Die Kimi K3-Modellkarte von Moonshot AI](https://huggingface.co/moonshotai/Kimi-K3) identifiziert das Modell und die Gewichte, auf die sich die Implementierung bezieht. - [Die AgentX-Methodik](https://inferencex.semianalysis.com/agentx) beschreibt die Arbeitslast zur Wiedergabe von Datenverkehr hinter dem getrennten Interaktivitätsvergleich. ## Sources - [vLLM, Kimi K3 in vLLM intensiv optimieren: schnell und verantwortungsvoll vorankommen (2026-10-16)](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — Technischer Bericht aus erster Hand und Quelle des Ergebnisses 842/488 beziehungsweise 1.73×. Er nennt TP16 auf 16 GB300-GPUs, Batch 1, DSpark DL7, synthetisches AL6, ISL1, OSL1k und aggregierte Dekodier-TPS ohne Prefill. Dazu kommen gesonderte Ergebnisse ohne spekulatives Dekodieren sowie für AgentX. - [vLLM-Pull-Request #61867, spezialisiertes Kimi K3-Dekodieren](https://github.com/vllm-project/vllm/pull/61867) — Integrierte Implementierung und von den Autoren durchgeführte Validierung. Dokumentiert die endgültige optionale Einstellung, unterstützte Konfigurationen und den Rückfall auf den Standardpfad. Die frühere DSpark-Tabelle nennt 838/489 bei TP16 B1 und synthetischem AL6; diese Zahlen werden daher nicht mit dem Paar aus dem Blog kombiniert. - [Moonshot AI, Kimi K3-Modellkarte](https://huggingface.co/moonshotai/Kimi-K3) — Identifiziert das Modell und die Gewichte des Modellanbieters; belegt die Leistung von vLLM nicht unabhängig. - [InferenceX, AgentX-Methodik und Datensätze](https://inferencex.semianalysis.com/agentx) — Beschreibt die Arbeitslast zur Wiedergabe von Datenverkehr, die dem separat gemeldeten Interaktivitätsvergleich zugrunde liegt. Beim vLLM-Vergleich ändert sich auch die GPU-Anzahl.