A kínai nyílt forráskódú projektfavorit, DeepSeek a hétvégi nyílt kiadással ismét olyan eszközt tett elérhetővé, amely befolyásolhatja az AI-fejlesztést: a DSparkot, egy MIT-licencű, spekulatív dekódolásra épülő rendszert. A cél az, hogy a nagy nyelvi modellek (LLM-ek) gyorsabban szolgáltassanak válaszokat anélkül, hogy megváltoztatnák a célmodell kimeneti eloszlását.
Mi az a DSpark és hogyan működik?
A DSpark ötlete leegyszerűsítve: a nagy modell "egylépéses" token-generálását kiegészít egy előre futó, könnyebb vázmodellel (draft), amely pár lépéssel előre megjósolja a várható token-sorozatot. A célmodell ezeket a javaslatokat párhuzamosan ellenőrzi; ha a javaslatok jók, a rendszer többszörös token-lépést tud egyszerre végrehajtani, ha rosszak, a DSpark igyekszik elkerülni a felesleges ellenőrzéseket.
A kiadás része egy technikai cikk, modell-checkpointok és a DeepSpec nevű kódbázis, amely a spekulatív dekódoló modulok betanításához és kiértékeléséhez szükséges eszközöket adja. A forráskód és a checkpointok elérhetők a DeepSeek GitHub és Hugging Face oldalain, MIT-licenc alatt.
Mire jó ez a gyakorlatban?
A DSpark célja egyike a legdrágább problémáknak az AI-üzemeltetésben: hogyan szolgáljunk ki nagy modelleket elég gyorsan valós felhasználói igények mellett, miközben a hardverhasználatot gazdaságossá tesszük. Ez fontossá válik fogyasztói chatbotok, kódsegítők, agentikus munkafolyamatok és vállalati AI-rendszerek esetén, ahol a felhasználók hosszabb válaszokat várnak gyorsan befolyó token-sorrendben.
DeepSeek saját beszállításaira alkalmazta a DSparkot a DeepSeek-V4 családon. Konkrétan a DeepSeek-V4-Flash (284 milliárd paraméteres mixture-of-experts modell, 13 milliárd aktív paraméterrel) és a DeepSeek-V4-Pro (1,6 billió paraméter, 49 milliárd aktív paraméter) esetén futtatták a rendszert; mindkettő támogat kontextusablakokat akár egymillió tokenig.
Teljesítményadatok — gyártásban mért gyorsulás
DeepSeek élő gyártási mérései szerint DSpark 51%-os aggregált áteresztést ér el a DeepSeek-V4-Flash esetén egy 80 token/másodperc/felhasználó cél mellett, és 52%-os javulást a DeepSeek-V4-Pro esetén 35 token/másodperc/felhasználó cél mellett. Az egy-felhasználós token-generálásnál a cég 60–85% gyorsulást jelent V4-Flashnél és 57–78% gyorsulást V4-Pronál a korábbi MTP-1 gyártási alaphoz képest, azonos rendszerkapacitás mellett.
Ezek a különböző százalékok különböző méréseket írnak le: az 60–85% és 57–78% értékek azt mutatják, mennyivel gyorsabban kap töltődő tokeneket egy egyes felhasználó DSpark esetén MTP-1-hez képest, hasonló rendszerkapacitásnál. Emellett DeepSeek nagyobb, 661% és 406% jellegű növekedéseket is jelzett szigorúbb sebességi célok mellett (120 tok/s/felhasználó V4-Flash és 50 tok/s/felhasználó V4-Pro), ezek azonban az aggregált átvitelt mérik olyan környezetben, ahol az MTP-1 közelít az operációs összeomláshoz (many concurrent requests lead to a collapse).
Egyszerűen: az ~85% inkább arra ad választ, hogy a felhasználói élmény mennyivel gyorsabb hasonló körülmények között, míg a 661% és 406% inkább azt mutatja, mennyivel több egyidejű forgalmat bír el a rendszer, mikor a régi architektúra már szűk keresztmetszetbe ütközik.
Miért számít a spekulatív dekódolás?
A nagy modellek tipikusan tokenről tokenre generálnak, ami pontos, de lassú, mert minden új token függ az addigi kontextustól. A spekulatív dekódolás lényege, hogy egy kis vagy könnyű vázmodell több lépésre előre tippel, a nagy modell pedig párhuzamosan ellenőrzi ezeket a tippeket; elfogadott tippek esetén több token is egyszerre haladhat.
A technika gyökerei korábbi munkákig vezethetők vissza (például a 2018-as blockwise parallel decoding és a 2022–2023-as SpecDec, Fast Inference via Speculative Decoding és speculative sampling publikációkig). Az elmúlt években több variáns jelent meg, és a központi metrika nem pusztán a tippelt tokenek száma, hanem az, hogy a célmodell mennyit fogad el ezek közül: csak az elfogadott részek gyorsítanak ténylegesen.
Mit változtat meg DSpark?
DSpark két gyakori problémára koncentrál: a rossz tippekre és a felesleges ellenőrzésekre.
-
Fél-autoregresszív (semi-autoregressive) generálást használ: párhuzamos gerincet kombinál egy könnyített szekvenciális fejjel, így próbál meg gyors maradni, de a helyi token-összefüggéseket jobban figyelembe venni, csökkentve a koherenciavesztést, amelyet a teljesen párhuzamos draftereknél láthatunk.
-
Bizalom-alapú (confidence-scheduled) ellenőrzést alkalmaz: a rendszer becsli, hogy a draft mekkora előtagja valószínűsíthetően átmegy a verifikáción, és a hardver-érzékeny ütemező ennek megfelelően állítja be, mennyit érdemes ellenőrizni adott terhelés mellett. Laza forgalomnál hosszabb előtagokat vizsgál, nagy terhelésnél levágja a gyengébb, alacsonyabb bizalommal rendelkező végleteket.
Ez a rugalmasság csökkenti azt a gyakorlatot, hogy statikus több-tokenes draftok alulhasználják a rendelkezésre álló erőforrást magas egyidejűség mellett.
Offline eredmények más modelleken: Qwen és Gemma
DeepSeek offline tesztekben futtatta a DSparkot Qwen3-4B, Qwen3-8B, Qwen3-14B és Gemma4-12B célmodelleken különböző feladatokban (matematika, kód, chat). Más drafterekkel (DFlash, Eagle3) összehasonlítva a cikk az "accepted length per decoding round" metrikát közli, vagyis átlagosan hány token marad meg egy ellenőrzési kör után.
A Qwen3 modelleken DSpark makro-átlagosan 30.9%, 26.7% és 30.0% javulást ért el Eagle3-hoz képest, és 16.3%, 18.4% és 18.3% javulást DFlash-hez képest. A cikk szerint a nyereségek kiterjedtek a Gemma4-12B modellre is. Ezek az eredmények azt mutatják, hogy a módszer nem kizárólag DeepSeek-V4-re korlátozódik.
A tesztek továbbá aláhúzzák, hogy a munkaterhelés számít: strukturált feladatok (kód, matematika) általában magasabb elfogadott hosszokat hoznak, míg a szabad formájú chatnél az elfogadottság alacsonyabb, tehát a DSpark-szerű módszerek különösen vonzóak lehetnek olyan vállalati alkalmazásoknál, ahol az outputok viszonylag kiszámíthatóbbak.
Hogyan használhatják a vállalatok DSparkot más modellekhez?
A DSpark nem automatikusan "plug-and-play" bármely modellre. Nyílt súlyokkal rendelkező modelleknél (Qwen, Gemma, Llama, Mistral, stb.) a működés egyértelműbb: a vállalatok betaníthatnak vagy finomhangolhatnak DSpark-szerű draft modulokat a saját célmodelljükre, majd integrálhatják a verifikációs ütemezőt az inferencia stackbe.
Ha a modell csak egy külső API-n keresztül érhető el, az ügyfél általában nem fér hozzá a token-verifikációs hurokhoz, logits-hoz, batchelési viselkedéshez vagy az ütemezőhöz, így nem tudja kívülről telepíteni a DSparkot. Ez megerősíti, miért előnyös az open vagy self-hosted infra olyan csapatoknak, amelyek kontrollálni akarják a költséget és a sebességet.
DeepSpec munkafolyamata ezt tükrözi: adat-előkészítés, célmodell-válaszok regenerálása, target cache építése, a draft modell betanítása és a spekulatív dekódolás elfogadottságának kiértékelése. Domain-specifikus használatnál gyakran szükség van további finomhangolásra.
Mit kapnak a fejlesztők a DeepSpec-től?
A DeepSpec gyakorlati lépéseket és eszközöket ad: adat-előkészítést, betanítást és benchmark-kiértékelést, valamint több nyílt modellhez checkpointokat. Ugyanakkor vannak gyakorlati korlátok: a DeepSpec README-ja szerint a Qwen3-4B alap adat-előkészítéshez körülbelül 38 TB target cache tároló szükséges, és az alap script egy node-ot feltételez nyolc GPU-val — így a kiadás elsősorban AI laborok, felhőcsapatok és haladó vállalati infrastruktúrák számára azonnal releváns.
Ennek ellenére fontos, hogy a csapat nyíltan adta át a betanítási pipeline-t: ez több, mint egy kutatási cikk vagy zárt gyártási állítás — gyakorlatilag tervrajzokat ad arra, hogyan reprodukálható, alakítható és értékelhető ez a megközelítés.
Korai közösségi tesztek és korlátok
Fejlesztők már elkezdték kipróbálni a DSparkot. Rafael Caricio egy GitHub PR-ben egy-stream DeepSeek-V4-Flash DSpark benchmarkot közölt: melegített referenciaértékek 26,33 tok/s volt spekuláció nélkül, 39,88 tok/s MTP-1-gyel, és ~60 tok/s DSparkkal — nagyjából 1,5× MTP-1-hez és 2,3× nem-spec dekódoláshoz képest. Egy későbbi commit öt futás átlaga szerint 60,31 tok/s és 1,51× javulás MTP-1-hez képest.
Ugyanakkor a valós többfordulós kódolási munkamenetekben a teljesítmény romolhat, ahogy a draft elfogadottság csökken a növekvő kontextus hatására. Vagyis a DSpark gyorsítást adhat, de az elfogadottság minősége határozza meg a tényleges nyereséget.
Összegzés
A DSpark kiadása azt mutatja, hogy a modell-architektúra megváltoztatása nélküli üzemeltetési optimalizációkban még jelentős teljesítményt tartalékolhatnak az operátorok. Gyorsabb token-generálás alacsonyabb késleltetést jelent a felhasználóknak, nagyobb átvitelt a szolgáltatóknak és jobb gazdaságosságot a skálázó csapatoknak.
DeepSeek kiadása különösen figyelemre méltó, mert egy működésben tesztelt módszert, nyílt kódot, publikus checkpointokat és részletes cikket adott át. A fő újítás nem pusztán több token tippelése, hanem a rendszeres verifikáció szelektív ütemezése: kevesebb pazarlás, több hasznos ellenőrzés. Vállalati szinten a tanulság az, hogy a következő teljesítménynövekedés nem csak a nagyobb modellekből jön majd; sokat számít, hogyan futtatják és optimalizálják azokat a csomópontokat, amelyeket a cégek maguk irányítanak.
