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

# Umabot sa 842 token bawat segundo ang decode path ng Kimi K3 sa vLLM sa isang partikular na GB300 test

> Iniulat ng vLLM ang 842 kumpara sa 488 pinagsama-samang decode token bawat segundo para sa Kimi K3 sa 16 GB300 GPU gamit ang isang partikular na DSpark setup. Hindi kasama ang prefill.

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.

Naisama na ng vLLM ang isang opsyonal na decode path na partikular sa Kimi K3 sa mga NVIDIA Blackwell GPU. Sa [paglalahad nito noong Oktubre 16](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel), iniulat ng proyekto ang 842 token na nalilikha bawat segundo kumpara sa 488 sa karaniwang vLLM, o pagtaas na 1.73×. Makitid ang saklaw ng paghahambing: isang request lamang sa bawat pagkakataon, tensor parallelism sa 16 GB300 GPU, DSpark speculative decoding na may pitong draft token, synthetic acceptance length na anim, isang token na input at 1000 token na output. Sinusukat ng bilang ang pinagsama-samang decoding throughput pagkatapos ng prefill. Hindi nito sinusukat kung gaano kabilis matapos ang buong request ng isang user.

Para sa mga inhinyerong nagpapasya kung susuriin ang path na ito, ang kapaki-pakinabang na pag-unlad ay ang pagsasama ng malaking resulta sa decode at ng medyo malinaw na paliwanag kung saan ito naaangkop. Ang [naisamang implementasyon](https://github.com/vllm-project/vllm/pull/61867) ay opsyonal na pinapagana sa pamamagitan ng `decode_backend: latency_specialized`; patuloy na gumagamit ng karaniwang decoding ang default na `auto` na setting. Ayon sa vLLM, nakatuon ang espesyal na path sa mga GB300 deployment na may walo o 16 GPU sa iisang NVLink domain, habang bumabalik sa karaniwang model forward path ang mga prefill, halo-halong batch at hindi suportadong hakbang.

## Saan napunta ang oras

Isang malaking mixture-of-experts model ang Kimi K3, ayon sa [model card nito](https://huggingface.co/moonshotai/Kimi-K3). Sa decoding, paulit-ulit na nagpapatakbo ng attention, pumipili ng mga expert at nagpapalitan ng data ang mga GPU sa isang serving system upang makalikha ng susunod na mga token. Gumawa ang vLLM team ng CuTe DSL path na nag-aangkop sa mga operasyong ito para sa inaasahang hugis ng mga tensor. Inilalarawan nito ang magkakaibang attention projection kernel para sa maliliit at mas malalaking batch; pagsasanib ng attention output projection, reduction sa pagitan ng GPU at kasunod na residual work; paghahati-hati ng mga kalkulasyon ng router; pagsasabay ng trabaho ng shared at routed expert; at paunang pagkuha ng mga weight habang nagkokomunikasyon. Sa isang per-layer trace sa post, gumagamit ang espesyal na path ng 13 kernel at 69 microsecond, samantalang gumagamit ang karaniwang vLLM ng 23 kernel at 130 microsecond. Isa itong iniulat na trace para sa ipinakitang setup, hindi bilang ng latency ng application.

Kasinghalaga ng disenyo ng kernel ang saklaw. Inilalarawan ng [pull request](https://github.com/vllm-project/vllm/pull/61867) ang GB300 validation sa TP8 at TP16, non-speculative decode hanggang batch 64, DSpark verification na may tatlo hanggang pitong draft token, at opsyonal na decode context parallelism. Nakasaad na gumamit ang performance work ng FP8 KV cache, FP32 SSM cache at mga weight ng tagapagbigay ng modelo. Hindi binabago ng path ang model weight, scheduling, sampling o DSpark drafter. Dahil dito, maihahambing ng serving team ang binagong decode implementation habang pamilyar ang natitirang stack, ngunit nangangahulugan din na hindi pinabibilis ng optimization ang bawat bahagi ng serving.

## Basahin nang magkahiwalay ang dalawang benchmark table

Ginagamit sa resultang 842 kumpara sa 488 ang **TP16 sa 16 GB300 GPU, batch 1, DSpark na may pitong draft token, synthetic acceptance length na anim, DL=7, ISL=1 at OSL=1k**. Tinatawag ng vLLM ang sukatan na pinagsama-samang decode token bawat segundo at hindi nito isinasama ang prefill. Itinatakda ng synthetic acceptance kung ilang iminungkahing token ang tatanggapin ng benchmark; hindi ito acceptance rate na sinukat mula sa mga prompt ng user. Kailangang magsukat mismo ang deployment na may ibang prompt, pagtanggap ng token, laki ng batch o haba ng input.

Mayroon ding [non-speculative table](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation) sa post. Sa TP16, halimbawa, iniulat nito ang 256.4 token bawat segundo sa batch 1 at 3606.1 sa batch 64, na may pagtaas na 1.88× at 1.62× kumpara sa kani-kanilang karaniwang configuration. Pinagsama-samang resulta ang mga ito ng TP group na walang speculative decoding. Hindi maaaring pagsamahin ang mga ito sa bilang ng DSpark para sabihing mas mabilis ang karanasan ng bawat user sa batch 64.

May isa pang bilang sa post na tungkol sa [AgentX](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#improvement-on-agentx), isang workload na muling nagpapatakbo ng mga pattern ng traffic ng coding agent gamit ang synthetic na nilalaman. Iniulat ng vLLM ang P90 interactivity na 403.2 kumpara sa 223.7 token bawat segundo bawat user sa concurrency na isa. Tumakbo ang optimized na resulta sa **16 GB300 GPU**, samantalang tumakbo ang naunang paghahambing sa **walo**. Dahil nagbabago ang bilang ng GPU kasabay ng implementasyon, hindi ibinubukod ng 1.8× na paghahambing ang pagpapahusay sa decode path. May mas mahahabang context, mga turn, paghinto at muling paggamit ng cache din ang AgentX, kaya ibang tanong ang sinasagot ng sukatan nito kaysa sa purong decode benchmark.

May maliit na pagkakaiba sa pagitan ng pampublikong post at ng naunang [performance table ng pull request](https://github.com/vllm-project/vllm/pull/61867): nakatala sa huli ang 838 kumpara sa 489 token bawat segundo para sa TP16, batch 1, DSpark DL7 at synthetic acceptance na anim. Ang 842 kumpara sa 488 sa post ang pinagmulan ng 1.73× na bilang dito. Kapaki-pakinabang na ebidensya ang naunang table ng isang kahawig na run, ngunit hindi dapat paghaluin ang dalawang pares. Nailathala na ng vLLM ang code at sarili nitong validation; hindi muling isinagawa ng BIG CHANGE ang alinman sa dalawang run.

## Ano ang kailangan sa isang pagsusuri

Magsisimula ang makabuluhang lokal na paghahambing sa [naisamang PR at nakasaad na configuration nito](https://github.com/vllm-project/vllm/pull/61867): kaparehong Kimi K3 weight mula sa tagapagbigay ng modelo, GB300 system na may 16 GPU sa iisang NVLink domain, TP16, mga cache format at eksaktong DSpark setup para sa pangunahing test. Patakbuhin ang karaniwang `auto` at ang opsyonal na `latency_specialized` sa iisang workload, saka itala ang decode throughput nang hiwalay sa prefill, oras bago lumabas ang unang token, output throughput at request-level latency. Hindi direktang makakopya ng pangunahing resulta sa 16 GB300 ang isang workstation o mas maliit na GPU pool. Walang tinutukoy na gastos sa pagrenta ng setup na iyon ang post.

Ang [paglalahad ng validation sa PR](https://github.com/vllm-project/vllm/pull/61867) ay nag-uulat ng numerical check at model evaluation, kabilang ang AIME25, GPQA-Diamond at long-context MRCR test. Inilalarawan din nito ang synchronization error na nakita habang binubuo ang implementasyon at pagkakaiba-iba sa mga test na may mahabang output. Mas marami itong naibibigay na susuriin kaysa sa isang speed chart, ngunit ebidensya pa rin ito mula sa mga gumawa ng implementasyon. Kailangang magpasya ang serving team kung sapat na kahawig ng suportadong configuration ang aktuwal na hardware, batching, haba ng context at speculative acceptance nito upang makatuwirang sukatin ang opsyonal na path sa sarili nitong traffic.

## Ang malaking pagbabago

Nagbibigay ang naisamang Kimi K3 path ng vLLM ng isang espesyal at opsyonal na GPU decode implementation na may dokumentadong benchmark at tala ng validation. Ang pinakamalakas na pampublikong pangunahing resulta ay **842 kumpara sa 488 pinagsama-samang decode token bawat segundo, o 1.73×, para sa TP16 sa 16 GB300 GPU sa batch 1 na may pitong draft token ng DSpark at synthetic acceptance length na anim**. Hindi kasama ang prefill. Kung mapapahusay nito ang isang partikular na serbisyo ay nakasalalay sa hardware ng serbisyong iyon at buong workload ng mga request nito.

## Mga sanggunian at karagdagang babasahin

- [Ang teknikal na post ng vLLM noong Oktubre 16](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) ay nagpapaliwanag ng mga pagbabago sa decode at nagbibigay ng 842/488 setup, non-speculative table at AgentX comparison. Iniulat ang mga resulta ng proyekto at ng NVIDIA contributor na si Benjamin Chislett.
- [Ang naisamang vLLM pull request #61867](https://github.com/vllm-project/vllm/pull/61867) ay nagdodokumento ng opsyonal na setting, suportadong configuration, hangganan ng implementasyon, validation at naunang 838/489 DSpark table. Tala ito ng code at mga resulta, hindi isang independiyenteng pag-uulit ng pagsubok.
- [Ang Kimi K3 model card ng Moonshot AI](https://huggingface.co/moonshotai/Kimi-K3) ay tumutukoy sa modelo at mga weight na ginamit na sanggunian ng implementasyon.
- [Ang metodolohiya ng AgentX](https://inferencex.semianalysis.com/agentx) ay naglalarawan ng traffic-replay workload sa likod ng hiwalay na interactivity comparison.

## Sources

- [vLLM, Masinsing pag-optimize ng Kimi K3 sa vLLM: mabilis at responsableng pagsulong (2026-10-16)](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — Teknikal na paglalahad mula mismo sa gumawa at pinagmulan ng 842/488, 1.73× na resulta. Tinukoy nito ang TP16 sa 16 GB300 GPU, batch 1, DSpark DL7, synthetic AL6, ISL1, OSL1k at pinagsama-samang decode TPS na walang prefill. May magkahiwalay ding non-speculative at AgentX result.
- [vLLM pull request #61867, espesyal na decode ng Kimi K3](https://github.com/vllm-project/vllm/pull/61867) — Naisamang implementasyon at tala ng validation na isinagawa ng mga may-akda. Nakadokumento ang pinal na opsyonal na setting, suportadong configuration at fallback. Nasa naunang DSpark table ang 838/489 sa TP16 B1 synthetic AL6, kaya hindi pinagsasama ang mga bilang na iyon sa pares mula sa blog.
- [Moonshot AI, Kimi K3 model card](https://huggingface.co/moonshotai/Kimi-K3) — Tinutukoy ang modelo at mga weight ng tagapagbigay ng modelo; hindi nito independiyenteng pinatutunayan ang performance ng vLLM.
- [InferenceX, Metodolohiya at mga Dataset ng AgentX](https://inferencex.semianalysis.com/agentx) — Inilalarawan ang traffic-replay workload na ginamit sa hiwalay na iniulat na interactivity comparison. Binabago rin ng paghahambing ng vLLM ang bilang ng GPU.