vLLM lar agenter skrive Kimi K3-kjernene: opptil 1,9 ganger raskere dekoding og ny review-modell
mandag 19. oktober · KI-generert · Kilde: vLLM
Test den nye dekodingsbanen hvis du kjører Kimi K3 på GB300, og bruk vLLMs fast-track-krav som mal når agentene dine skriver ytelseskode.
Kodeagenter skriver nå GPU-kjerner raskere enn vLLM-vedlikeholderne rekker å lese dem. Det er utgangspunktet for et innlegg vLLM-teamet publiserte 16. oktober, samme dag som PR #61867 ble merget: en ny dekodingsbane for Kimi K3 der nesten alle operasjoner er byttet ut med egne CuTe DSL-kjerner, bygget med agentassistanse for NVIDIA GB300 med 8 eller 16 GPU-er.
Med spekulativ dekoding (DSpark, sju utkast-tokens og syntetisk akseptlengde 6) når Kimi K3 842 tokens i sekundet ved batch 1 på 16 GB300, 1,73 ganger raskere enn standard vLLM med samme oppsett. Uten spekulering ligger gevinsten på 1,88–1,92× ved batch 1–2 på TP16 og faller til 1,31× ved batch 64 på TP8. Banen er opt-in og slås på med decode_backend satt til latency_specialized, og all koden ligger isolert i vllm/models/kimi_k3/nvidia/.
«KI-verktøy har gjort det nesten gratis å lage en PR, men å gjennomgå en koster like mye som før, eller mer» — Lucas Wilkinson, Red Hat, i vLLMs RFC om reproduserbare evals
Derfor foreslår teamet en fast-track for modelloptimaliseringer (RFC #59665). Endringene skal holdes inne i modellens egen kode, scopet avgrenses til bestemt maskinvare og batchstørrelser, og funksjoner som full kontekst, temperatur-sampling og strukturert output kan ikke optimaliseres bort. Agentene skriver testene, kjører benchmarkene og dokumenterer når optimaliseringen gjelder. Mennesker vurderer designet og bevisene i stedet for hver linje.
Kimi K3-arbeidet viser hvorfor kravene trengs. En gjennomgang avslørte at kompilatoren flyttet lesing av aktiveringer foran en synkroniseringsventing, og evals på lang kontekst som MRCR og AIME25 fant numeriske feil som ikke dukket opp i frittstående kjernetester med mock-input.
Hva bør du gjøre?
- Kjører du Kimi K3 på GB300 med TP8 eller TP16: test banen med --additional-config og decode_backend latency_specialized mot din egen trafikk.
- Lar du agenter skrive ytelseskritisk kode: krev tester som faktisk treffer den endrede kodestien, og evals på lang kontekst i tillegg til kjernetester.