Három flag a gyártói receptből, egyik sem gyorsított
Egy unalmas mérés, amiből nem lett változtatás — és a mellékterméke, ami mégis megtanított valamit a spekulatív dekódolásról
Van egy hardvergyártói „agent-ready” serving recept a mi modellcsaládunkhoz. Néhány flagben eltér attól, amit mi futtatunk. A kérdés kézenfekvő: segítenek-e ezek a flagek a mi modellünkön, a mi vasunkon, a mi terhelésünkön, vagy a recept egy olyan setupra van hangolva, ami nem a miénk?
Lemértük. Egyik flag sem került be. A cikk arról szól, hogy ez miért nem kudarc, hanem a mérés rendes kimenete, és arról az egy karról, ami nem egyszerűen rossz volt, hanem workloadfüggő.
Miért érdemes egyáltalán lemérni egy publikált receptet
Ez a fajta kísérlet a legunalmasabb, és pont ezért spórolja a legtöbb időt. Egy publikált receptet átvenni olcsó: bemásolod a flageket az indítási parancsba, és kész. Fél évvel később rájönni, hogy az egyik flag 3%-ot visz el az átbocsátásból, már nem olcsó, főleg úgy, hogy addigra a parancs mellé nőtt öt másik változtatás, és nem tudod, melyik mit csinál.
A gyártói ajánlás nem gyanús attól, hogy gyártói. Csak nem a te terhelésedre készült.
Amit mértünk
Kumulatív létra a produkciós alapkonfigurációtól indulva. Minden variáns saját motorindítást igényel, tehát mindegyik egy hidegindítás plusz egy mérési kör, nagyjából 20 perc karonként.
| Variáns | Mi kerül az alaphoz | Hipotézis |
|---|---|---|
v0_baseline | — (a jelenlegi produkció) | referencia |
v1_flashinfer | --attention-backend flashinfer | az explicit FlashInfer attention segít |
v2_async | + --async-scheduling | az ütemezés és a forward pass átfedése emeli az átbocsátást |
v3_spec3 | num_speculative_tokens 2 → 3 | a hosszabb draft több elfogadott tokent hoz lépésenként |
Modell: Qwen3.6-35B-A3B-FP8, DGX Sparkon, GB10 chipen (sm_121a). Terhelés: hat egyszálú workload 29-től nagyjából 159 000 prompt tokenig, plusz két párhuzamos mix 8-as konkurencián, 60 másodperc mixenként. Dokumentumkorpusz nincs benne, ez kiszolgálási mérés, nem pontosságmérés.
Az elsődleges döntési metrika az aggregált átbocsátás 8 párhuzamos kérésnél. Másodlagos: egyszálú dekódolás workloadonként, TTFT, és a spekulatív elfogadási arány a motor metrics végpontjáról.
A döntési szabályt a futás előtt rögzítettük: egy flag csak akkor kerül be, ha az aggregált átbocsátás érdemben javul, és az indítási log tiszta a kernel-fallback figyelmeztetésektől. Ez a sorrend nem formalitás. Ha a szabályt utólag hozod meg, addig fogod alakítgatni, amíg valamelyik kar nyer.
Amit szándékosan nem mértünk
Három dolgot kihagytunk, és ezt érdemes kimondani, mert a hallgatólagosan kihagyott kar ugyanolyan torzítás, mint a rosszul mért:
- 4 bites súlyok Marlin MoE backenddel — a recept fő párosítása. Más checkpoint-formátumhoz tartozik; az FP8-as modell marad az érettebb kernel-úton. Ez később saját mérést kapott.
fastsafetensorsbetöltési formátum — ezen a platformon GDS nélkül ismerten OOM-ol egy nagy modell betöltése közben.- Másik tool-call parser — ez funkcionális változás, nem teljesítménybeli. Az ügynökünk streaming útja az aktuális parserhez kötött, vakon cserélve eltörne a tool-argumentumok streamelése. Ehhez funkcionális teszt kell, nem benchmark.
Az eredmény: semmi nem élte túl
| Variáns | Aggregált átbocsátás (c=8) | Egyszálú | Ítélet |
|---|---|---|---|
v1_flashinfer | −2,2% | semleges | elutasítva |
v2_async | −2,4% | semleges | elutasítva |
v3_spec3 | −3,6% | +8,9% átlag | elutasítva — lásd lent |
A számok relatívak: a repóban is aggregált formában publikáljuk őket, abszolút tok/s nélkül. Ez a mérés célja szempontjából elég, a kérdés nem az volt, hogy milyen gyors a gépünk, hanem hogy egy flag mozdít-e rajta.
Az első két kar itt véget is ér. A --attention-backend flashinfer azért nem hoz semmit, mert az alapértelmezett választás ehhez a modellhez már egyenértékű utat választ. Az explicit felülbírálás legfeljebb elrontja. Az --async-scheduling pedig egy olyan átfedést próbál kihasználni, ami ezen a hardveren nem szűk keresztmetszet.
A harmadik kar: itt lett érdekes
A v3_spec3 nem lapos veszteség. Tankönyvi spekulatív dekódolási átváltás, és a törésvonal pontosan az alapszintű elfogadási arány mentén húzódik.
Ahol a modell már eleve jól jósolja meg a saját következő tokenjeit — szigorú JSON, hosszú kontextus folytatása —, ott a hosszabb draft majdnem ingyen extra sebesség. Ahol nem, ott a plusz draft token eldobott munka, párhuzamos terhelésnél pedig valódi kérésekkel versenyez ugyanazért a számítási kapacitásért.
Ez a kettősség a lényeg. A JSON-kinyerésnél az elfogadás 99,5%-ról csak 98,3%-ra esik, a harmadik draft token szinte mindig jó. A rövid chatnél 64,6%-ról 43,8%-ra: itt a harmadik tokent az esetek több mint felében eldobjuk, de a kiszámolásáért így is fizettünk.
A mi produkciós modellünk chatet és kinyerést is szolgál ki, tehát a vegyes profil dönt: a draft hossza marad 2.
A tanulság, amit tovább viszünk
A spekulatív dekódolás hangolása workload-hangolás. Egyetlen num_speculative_tokens érték csak egyetlen elfogadási rezsimre helyes, és egy olyan modellnek, ami szigorú JSON-kinyerést (99,5% elfogadás) és rövid csevegést (58–65%) is kiszolgál, nincs egyetlen ilyen rezsimje.
Ebből következik egy nyitott irány is: ha a kinyerést és a chatet külön motorpéldányra bontanánk, példányonként más draft-hossz mehetne, 3 a kinyerésnek, 2 a chatnek. Ez ma nem éri meg az üzemeltetési többletet, de a mérés megmutatta, hol van a határ, ahol megérné.
Amit a mérés magáról a mérésről mondott
Az elsődleges metrika az aggregált átbocsátás volt 8 párhuzamos kérésnél. Senki nem ellenőrizte, hogy mennyi a produkciós konkurencia valójában.
1 és 3 között van. Az idő nulla százalékában megy 8 fölé.
Ez egyetlen elutasítást sem változtat meg, egyik kar sem volt pozitív semmilyen konkurencián. De azt jelenti, hogy ennek a rendszernek a döntésre releváns metrikája nem a telített átbocsátás, hanem a válasz első tokenjéig eltelt idő. És a v3_spec3 érvelése megérdemelt volna egy alacsony konkurenciájú keresztezési mérést, ami itt nem futott le.
Ezt utólag könnyű okosságnak látni. Valójában ez a legdrágább hibaosztály: egy olyan üzemi ponton mérni, ahova a rendszer soha nem jut el. Most a jó dolgokat utasította el rossz indoklással. Legközelebb rosszakat fogadhat el, ugyanazzal a magabiztossággal.
Összefoglalva
Egy publikált gyártói recept egyetlen flagje sem javított a produkciós alapkonfiguráción, tehát nem változtattunk semmit. A mérés értéke nem a változtatás, hanem az, hogy a következő fél évben nem kell újra végiggondolni ezt a kérdést, és hogy közben kiderült, a spekulatív draft hossza nem globális beállítás.
- A gyártói recept nem transzferál hardver- és kvantálási határon át. A nyereségei olyan kernel-utakból jönnek, amik ezen a chipen vagy nem léteznek, vagy nem érhetők el egy blokk-skálázott FP8 checkpointtal. A flagek átmásolása nem rövidítés, hanem tesztelés nélküli változtatás, amin rajta van egy gyártó neve.
- A spekulatív dekódolás hangolása workload-hangolás. Ahol az elfogadási arány eleve magas, ott a hosszabb draft +13–19%; ahol alacsony, ott −9%. Vegyes profilnál a rosszabb eset dönt.
- Előbb mérd meg a terhelést, utána válassz metrikát. Egy olyan üzemi ponton futó benchmark, ahova sosem jutsz el, jó dolgokat utasíthat el rossz okból.
- A nemleges eredmény is eredmény. Négy hidegindítás, nagyjából másfél óra gépidő, nulla változtatás — és egy lezárt kérdés, ami eddig minden konfigurációs vitában felmerült.
A mérés 2026. július 1-jén készült egy GB10-alapú fejlesztői gépen, egyetlen motorbuildon, variánsonként egy futással (n=1). A karonkénti −2 és −4% közötti eltérések önmagukban a zajszint közelében vannak, a robusztus megállapítás nem egy-egy delta, hanem hogy egyetlen kar sem lett pozitív. A hibával záruló futásokat eldobtuk. A mérés semmit nem mond arról, hogy a recept működik-e azon a hardveren és kvantálási formátumon, amire íródott.