vLLM je spojio opcionu putanju dekodiranja specifičnu za Kimi K3 na NVIDIA Blackwell GPU-ovima. U svom prikazu od 16. oktobra projekat navodi 842 generisana tokena u sekundi naspram 488 za standardni vLLM, odnosno dobitak od 1.73×. To poređenje ima uske granice: jedan zahtev u datom trenutku, tenzorski paralelizam na 16 GB300 GPU-ova, DSpark spekulativno dekodiranje sa sedam predloženih tokena, sintetička dužina prihvatanja od šest, ulaz od jednog tokena i izlaz od 1000 tokena. Broj meri zbirnu propusnost dekodiranja nakon prefill faze. Ne meri koliko brzo se završi ceo korisnički zahtev.

Za inženjere koji odlučuju da li da procene ovu putanju, koristan pomak je spoj značajnog rezultata dekodiranja i prilično jasnog prikaza gde se on primenjuje. Spojena implementacija uključuje se izborom preko decode_backend: latency_specialized; podrazumevana postavka auto i dalje koristi standardno dekodiranje. vLLM kaže da specijalizovana putanja cilja GB300 implementacije sa osam ili 16 GPU-ova u jednom NVLink domenu, dok se prefill, mešovite grupe i nepodržani koraci vraćaju na standardnu putanju prolaza unapred kroz model.

Gde je odlazilo vreme

Kimi K3 je veliki model sa mešavinom eksperata, prema njegovoj kartici modela. Tokom dekodiranja sistem za posluživanje više puta izvršava pažnju, bira eksperte i razmenjuje podatke između GPU-ova da bi proizveo naredne tokene. Tim vLLM-a napravio je putanju u CuTe DSL-u koja specijalizuje te operacije za očekivane oblike tenzora. Njihov prikaz opisuje različita jezgra projekcije pažnje za male i veće grupe; spajanje izlazne projekcije pažnje, redukcije između GPU-ova i narednih rezidualnih operacija; proračune rutera podeljene na delove; preklapanje zajedničkih i rutiranih eksperata; i unapred učitavanje težina tokom komunikacije. U tragu po slojevima prikazanom u objavi specijalizovana putanja koristi 13 jezgara i 69 mikrosekundi, dok standardni vLLM koristi 23 jezgra i 130 mikrosekundi. To je prijavljeni trag za prikazanu postavku, a ne podatak o kašnjenju aplikacije.

Obuhvat je važan koliko i dizajn jezgara. Zahtev za izmenu opisuje GB300 validaciju pri TP8 i TP16, nespekulativno dekodiranje do grupe 64, DSpark verifikaciju sa tri do sedam predloženih tokena i opcioni kontekstni paralelizam pri dekodiranju. Navodi da je rad na performansama koristio FP8 KV keš, FP32 SSM keš i težine dobavljača modela. Putanja ne menja težine modela, raspoređivanje, uzorkovanje ni DSpark generator predloga. To timu za posluživanje omogućava da izmenjenu implementaciju dekodiranja uporedi uz poznato okruženje, ali znači i da optimizacija ne ubrzava svaki deo posluživanja.

Dve tabele testova čitajte odvojeno

Rezultat 842 naspram 488 koristi TP16 na 16 GB300 GPU-ova, grupu 1, DSpark sa sedam predloženih tokena, sintetičku dužinu prihvatanja šest, DL=7, ISL=1 i OSL=1k. vLLM metriku naziva zbirnim brojem tokena dekodiranja u sekundi i isključuje prefill. Sintetičko prihvatanje fiksira koliko predloženih tokena test prihvata; nije izmerena stopa prihvatanja iz korisničkih upita. Implementacija sa drugačijim upitima, ponašanjem prihvatanja, veličinama grupa ili dužinama ulaza zahteva sopstveno merenje.

Objava daje i nespekulativnu tabelu. Pri TP16, na primer, navodi 256.4 tokena u sekundi za grupu 1 i 3606.1 za grupu 64, uz dobitke od 1.88× i 1.62× u odnosu na odgovarajuće standardne postavke. To su zbirni rezultati TP grupe bez spekulativnog dekodiranja. Ne mogu se kombinovati sa DSpark brojem da bi se tvrdilo da korisnik dobija brže iskustvo pri grupi 64.

Drugi broj u objavi odnosi se na AgentX, radno opterećenje koje ponavlja obrasce saobraćaja programerskih agenata sa sintetičkim sadržajem. vLLM navodi P90 interaktivnost od 403.2 naspram 223.7 tokena u sekundi po korisniku pri konkurentnosti jedan. Optimizovani rezultat dobijen je na 16 GB300 GPU-ova, dok je ranije poređenje koristilo osam. Pošto se broj GPU-ova menja zajedno sa implementacijom, to poređenje od 1.8× ne izdvaja poboljšanje putanje dekodiranja. AgentX takođe uključuje duže kontekste, razmene, pauze i ponovnu upotrebu keša, pa njegova metrika odgovara na drugačije pitanje od čistog testa dekodiranja.

Postoji mala razlika između javne objave i ranije tabele performansi zahteva za izmenu: druga navodi 838 naspram 489 tokena u sekundi za TP16, grupu 1, DSpark DL7 i sintetičko prihvatanje šest. Poređenje 842 naspram 488 iz objave izvor je ovde navedenog broja 1.73×. Ranija tabela je koristan dokaz sličnog izvršavanja, ali se dva para ne smeju mešati. vLLM je objavio kod i sopstvenu validaciju; BIG CHANGE nije ponovio nijedno izvršavanje.

Šta bi procena zahtevala

Smisleno lokalno poređenje počelo bi od spojenog PR-a i navedene konfiguracije: iste težine dobavljača modela Kimi K3, GB300 sistem sa 16 GPU-ova u jednom NVLink domenu, TP16, formati keša i tačna DSpark postavka naslovnog testa. Pokrenite standardni auto i opcioni latency_specialized pod istim opterećenjem, a zatim zabeležite propusnost dekodiranja odvojeno od prefill faze, vremena do prvog tokena, izlazne propusnosti i kašnjenja na nivou zahteva. Radna stanica ili manji skup GPU-ova ne mogu neposredno da ponove naslovni rezultat sa 16 GB300. Objava ne utvrđuje cenu iznajmljivanja te postavke.

Njegov prikaz validacije PR-a navodi numeričke provere i evaluacije modela koje uključuju AIME25, GPQA-Diamond i MRCR test dugog konteksta. Opisuje i grešku sinhronizacije otkrivenu tokom razvoja i varijacije u testovima dugog izlaza. Te provere čitaocima daju više za ispitivanje od grafikona brzine, ali ostaju dokazi samih implementatora. Tim za posluživanje treba da odluči da li njegovi stvarni hardver, grupisanje, dužine konteksta i spekulativno prihvatanje dovoljno liče na podržane konfiguracije da opravdaju merenje ove opcione putanje na sopstvenom saobraćaju.

Velika promena

Spojena vLLM putanja za Kimi K3 čini dostupnom specijalizovanu, opcionu GPU implementaciju dekodiranja uz dokumentovan test i trag validacije. Najjači javni naslovni rezultat je 842 naspram 488 zbirnih tokena dekodiranja u sekundi, odnosno 1.73×, za TP16 na 16 GB300 GPU-ova pri grupi 1 sa sedam DSpark predloženih tokena i sintetičkom dužinom prihvatanja šest. Prefill je isključen. Da li poboljšava određenu uslugu zavisi od njenog hardvera i celokupnog opterećenja zahteva.

Izvori i dodatna literatura