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

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, 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 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. 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 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 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, 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: 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: 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 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 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 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 ay tumutukoy sa modelo at mga weight na ginamit na sanggunian ng implementasyon.
• Ang metodolohiya ng AgentX ay naglalarawan ng traffic-replay workload sa likod ng hiwalay na interactivity comparison.