Inclusion AI Ling-3.0-flash modelljének batch-méret-1 (batch size 1) értékelésén NVIDIA DGX Spark klaszteren végzett profilozás azt mutatta, hogy a dekódolás memória-sávszélesség-érzékeny: a végrehajtási időt elsősorban a modellsúlyok olvasása határozza meg. Két művelet emelkedett ki különösen: a mixture-of-experts (MoE) számítás és az output-réteg (LM head) projekciója, amely a teljes szókincsre ad logit-értékeket. Ezek alapján két lehetséges cél adódott: csökkenteni az egy dekódolási lépésre jutó súlyforgalmat és növelni a egy ellenőrzési körben előállított tokenek számát.
A cikk három optimalizációt mutat be, amelyek ezekre a költségekre hatnak:
- Humming MXFP4 MoE kerneljeinek használata az expert-routing számítás gyorsítására.
- Online FP8 kvantálás az LM head-re, hogy csökkentsük a súlyolvasási volumenét.
- Multi-token prediction (MTP) spekulatív dekódolás NEXTN-nel, több token egyidejű tervezésére és ellenőrzésére.
A Ling-3.0-flash implementáción keresztül bemutatott eredményekhez kód és telepítési instrukciók elérhetők a Ling cookbookban.
Modell és kiinduló konfiguráció
A vizsgálat Ling-3.0-flash-fp4 modellt használta, amely egy MoE architektúra: összesen 124 milliárd paraméter, és egy tokenre átlagosan 5.1 milliárd aktív paraméter jut. A háló 42 rétegből áll: 35 Kimi Delta Attention (KDA) lineáris-attenciós réteg és 7 multi-head latent attention (MLA) réteg. Minden MoE réteg tokenenként nyolc szakértőhöz routolja a tokeneket 512 routed expert közül, valamint egy közös (shared) expertet is használ.
Ling-3.0-flash natív 256k-token kontextusablakkal rendelkezik, ami akár 1M tokenig kiterjeszthető. Az előző Ling flash modellhez képest javul a hosszú távú feladatstabilitás, a tool-calling pontossága és a harness kompatibilitás. A fejlesztők engedélyezhetik a komplex agent feladatokra való gondolkodást vagy kikapcsolhatják azt késleltetés-érzékeny interakciókhoz.
A baseline a hivatalos cookbook W4A8 konfigurációját követte: FlashInfer MXFP4 MoE kerneljei, NVIDIA CUTLASS sűrű GEMM és az –enable-fp32-lm-head opció. Az LM head a 2,560 dimenziójú rejtett térből 157,184 tokenes szókincsre vetít.
A teljes MXFP4 telepítési útmutató a MXFP4 deployment notebookban található.
Optimalizáció 1: Humming MXFP4 MoE backend
Az első optimalizáció a flashinfer_mxfp4 MoE végrehajtó rutint cseréli le a humming könyvtárra. A Humming egy független kernelkönyvtár (humming-kernels pip csomag), amely az NVRTC-t (NVIDIA CUDA Runtime Compilation) használja, és futásidőben generál, majd fordít specifikus CUBIN binárisokat a tényleges M/N/K dimenziókra, adattípusokra és GPU architektúrára. Ezeket a binárisokat cache-eli (~/.humming/cache), ami specializáltabb kernelváltozatot ad a Ling-3.0-flash alakokra (például a viszonylag keskeny moe_intermediate_size = 768 esetére). A fordítás finomabb granularitású: egyedi kernel másodpercek alatt elkészül, míg a FlashInfer CUTLASS útja ninja-val 97 targetet fordít és percek-tízek perceket igényel.
Teljesítmény-eredmények (synthetikus munkaterhelet, 32K beviteli token, 2K kimenet, batch size 1):
- Baseline TPOT: 27.71 ms / Decode throughput: 36.09 tok/s
-
- Humming MoE backend TPOT: 25.35 ms / Decode throughput: 39.45 tok/s
- Relatív javulás: +9.3% throughput
Optimalizáció 2: Online FP8 LM head kvantálás
A checkpointban az LM head BF16 formátumban van tárolva és a modules_to_not_convert listán szerepel, ezért betöltéskor nem kvantálódik. A szókincs GEMM mérete 157,184 × 2,560, és minden generált tokennél az egész súlyblokkot be kell olvasni. Sávszélességi szűk keresztmetszet mellett ez jó célpont a tömörítésre.
A javítás dinamikus FP8 kvantálást alkalmaz csupán az LM head összeállításakor; a modell többi része a checkpoint FP8/MXFP4 konfigurációjával töltődik be. A LM head BF16 → FP8 átalakítása megközelítőleg megfelezi a réteg olvasási volumenét. A konfigurációt SGLANG_ENABLE_FP8_LM_HEAD=1 környezeti változóval lehet engedélyezni.
Megjegyzés: ez a beállítás kizárja az –enable-fp32-lm-head opciót, amely FP32 logit-kimenetet és lassabb vokabuláris-GEMM utat használ.
Cumulative eredmények (Humming már aktív):
-
- Online FP8 LM head TPOT: 22.76 ms / Decode throughput: 43.94 tok/s
- Relatív a baseline-hoz: +21.7% throughput
- Relatív a csak Humming-hoz: +11.4% throughput
Optimalizáció 3: MTP spekulatív dekódolás NEXTN-nel
Az első két optimalizáció az egy dekódolási lépés költségét csökkentette; a spekulatív dekódolás ehelyett a dekódolási lépések számát csökkenti.
Ling-3.0-flash tartalmaz egy NEXTN predikciós réteget (num_nextn_predict_layers: 1), amit közvetlenül lehet tervező (draft) modellként használni további képzés vagy letöltés nélkül. A konfiguráció három draft lépést és négy-tokenes verifikációs ablakot használ: minden körben a draft három token egymás után történő előrejelzését adja, a célmodell pedig egyszerre négy pozíciót ellenőriz, elfogadva a helyes prefixet.
A haszon két mennyiségtől függ: az accept length (átlagosan egy körben elfogadott tokenek száma) és a verification-cost ratio (egy verifikációs lépés költsége viszonyítva egy normál dekódolási lépéshez). A mért verifikációs arány körülbelül 2.26 volt. A verifikációs költség fő forrása nem az attention számítás volt: batch size 1 esetén a KV olvasások kicsik voltak a súlyolvasáshoz képest. Az elsősorban költségforrást az MoE expert aktiváció jelentette: egy normál dekódolás egy tokenre 8 expertet aktivál, míg egy verifikáció négy token esetén akár 32 expertet is aktiválhat.
Fontos integrációs megjegyzés: ha online FP8 LM-head kvantálás és MTP egyszerre engedélyezett, a draft modellnek meg kell osztania a teljes LM-head modult a targettel, nem csak magát a súlytensort. Az eredeti Ling NEXTN implementáció nem tette elérhetővé ezt az interfészt. Ennek hiányában a framework csendben visszaesik: a draft FP8 súlyokat kap, de BF16-ként értelmezi azokat, az accept length 1.00-ra esik, és az áteresztőképesség a baseline-nál rosszabb lesz. A teljes LM-head megosztásával a normál token-elfogadás visszaáll. A Ling cookbook részletezi, hogyan lehet FP8 LM-head kvantálást és MTP-t együtt engedélyezni.
Cumulative eredmények (Humming és FP8 már aktív):
-
- MTP (NEXTN, steps=3 / topk=1 / draft_tokens=4) TPOT: 9.72 ms / Decode throughput: 102.88 tok/s
- Relatív a baseline-hoz: +185.1% throughput
- A synthetic munkaterhelten az MTP accept length elérte a 3.90-et (ez a synthetic környezetben optimistább, a valós feladatokon alacsonyabb lesz)
End-to-end mérés GSM8K-on
A komponens-szintű vizsgálatok szintetikus 32K/2K munkaterhelten készültek; ezek segítenek az egyes komponensek izolált értékelésében, de a repetitív kimenetek és a determinisztikus mintavétel túlbecsülik a spekulatív dekódolás előnyét. Ezért az értékelés kiterjedt egy valódi végponti összehasonlításra is: az összes 1,319 GSM8K kérdést felhasználva.
Beállítások: öt-shot prompting (példák a tréningből), teljes tesztkészlet értékeléshez, temperature=0.6, top_p=0.95, top_k=29, max_tokens=32,768, chain-of-thought engedélyezve. A három optimalizáción kívül minden változó egyezett: sampling paraméterek, parser, öt-shot protokoll, random seed, és memóriaallokáció. A Time to First Token (TTFT) a első kimeneti token késlekedését méri.
Eredmények a teljes GSM8K mérésen:
- Baseline TPOT: 26.45 ms; optimalizált TPOT (három módszerrel): 18.56 ms (−29.8%)
- Decode throughput: baseline 37.81 tok/s → optimalizált 53.89 tok/s (+42.5%)
- GSM8K pontosság: baseline 96.89% → optimalizált 96.82% (−0.08 százalékpont; nincs statisztikailag kimutatható pontosságvesztés)
- MTP accept length a valós feladaton: 2.68
- Átlagos latencia: baseline 15.21 s → optimalizált 11.49 s (−24.5%)
- Latency P50 / P95: baseline 8.36 s / 50.20 s → optimalizált 6.11 s / 38.60 s (−27% / −23%)
- Mean TTFT: baseline 0.207 s → optimalizált 0.214 s
- Kéréshibák / trancsokciók: mindkettőnél 0 / 0
Megjegyzés: a synthetic és a valós munkaterheletek különbségei miatt a szintetikus tesztben mért 185.1%-os throughput-növekedés nem garantálja az azonos mértékű javulást valós feladatokon. A synthetic környezet ismétlődő kimenetei könnyebben elfogadható draftokat eredményeznek (accept length 3.90 vs GSM8K 2.68), más sampling paramétereket használtak (synthetic: greedy vs GSM8K: temperature és topp/topk), és a kimenethossz eloszlása is eltér.
Következtetések és üzembehelyezési tanácsok
A három optimalizáció kombinálva csökkentette az egy-tokenre jutó időt és a dekódolási lépések számát: Humming és az FP8 LM head a lépésenkénti költségeket csökkentik, míg az MTP a lépések számát. A teljes GSM8K értékelésen ezek együtt 42.5%-os áteresztőképesség-növekedést és 24.5%-os átlagos késleltetés-csökkenést eredményeztek, pontosság-romlás nélkül.
Ugyanakkor a stacking (egymásra rakás) nem feltétlenül automatikus: minden optimalizációnak helyes integrációra van szüksége. A gyakorlatban előfordulhat, hogy egy-egy hiányzó interfész miatt a rendszer csendben visszalép egy rosszabb konfigurációra (például ha a draft és target nem osztja meg a teljes LM-head modult), ami lassabb működést eredményezhet, mint a nem optimalizált baseline. Üzembe helyezéskor érdemes ellenőrizni, hogy minden optimalizáció valóban aktív a rendszer indításakor — ez megbízhatóbb, mint csak későbbi teljesítményértékekből próbálni következtetni erre.
A Ling cookbook útmutatói részletezik a Humming, az online FP8 LM-head kvantálás és az MTP/ NEXTN beállítását és együttes használatát.
