A DeepSeek nyílt forráskódúvá tette a DSparkot, egy új keretrendszert, amely akár 85%-kal gyorsíthatja az LLM következtetést.

Még akkor is, amikor a geopolitikai beszélgetés az MI körül egyre feszültebbé válik az Egyesült Államok kormányának lépései miatt, amelyek a legújabb Anthropic és OpenAI modellek korlátozására irányulnak, a kínai nyílt forráskódú kedvenc, a DeepSeek újra visszatért egy újabb nyílt kiadással, amely ismét megváltoztathatja a globális MI fejlesztést. A hétvégén a cég kiadta a DSparkot, egy új, MIT-licencelt rendszert, amely arra lett tervezve, hogy a nagy nyelvi modellek gyorsabban válaszoljanak anélkül, hogy megváltoztatnák, amit az alapmodell mondani próbál. A legegyszerűbb módja ennek megértésének az, hogy a legtöbb MI chatbot úgy ír, mint valaki, aki egy folyót keresztül lépdel egy-egy lépéskövön. Választanak egy kis szövegrészletet, majd a következőt, majd a következőt. A DSpark ad a rendszernek egy előfutót, amely néhány lépéssel előrébb jár, megpróbálja kikalkulálni a valószínű útvonalat, és lehetővé teszi a nagyobb modell számára, hogy gyorsan ellenőrizze, mely lépések biztonságosak. Amikor a találgatások jók, a modell gyorsabban tud haladni. Amikor a találgatások gyengék, a DSpark próbál nem időt pazarolni azok ellenőrzésére. A DeepSeek egy műszaki papírral, modellellenőrzési pontokkal és a DeepSpec kódalappal publikálta a munkát, amely a spekulatív dekódoló rendszerek képzésére és értékelésére szolgál. A kiadás elérhető a DeepSeek nyilvános GitHub és Hugging Face oldalain, mindkettő a megengedő, barátságos, elterjedt MIT licenc alatt, lehetővé téve az új technika széleskörű használatát fejlesztők, kutatók és kereskedelmi vállalatok számára, akik tanulmányozni vagy alkalmazni szeretnék az megközelítést. A rendszer egyike a legdrágább problémáknak az MI alkalmazásában: nagy modellek gyors kiszolgálása valódi felhasználók számára, miközben a hardvert eléggé hatékonyan használva a gazdasági szempontok is működjenek. Ez fontos a fogyasztói chatbotok, kódoló asszisztensek, ügynökségi munkafolyamatok és vállalati MI rendszerek esetében, ahol a felhasználók hosszú válaszokat várnak el, hogy gyorsan érkezzenek, ne pedig szónként kígyózzanak ki. A DeepSeek a DSparkot saját legújabb határvonal nyílt modelljén, a DeepSeek-V4-en alkalmazza. Különösen a DeepSeek az új DSpark keretrendszert a DeepSeek-V4-Flash-on használta, amely már sebességoptimalizált, 284 milliárd paraméteres keverék-szakértői modellel rendelkezik, 13 milliárd aktív paraméterrel, és a DeepSeek-V4-Pro-val, amely egy alaposabb és erősebb, 1,6 trillió paraméteres modell, 49 milliárd aktív paraméterrel (mindkettő támogatja az egy millió tokenes kontextusablakokat). De a szélesebb jelentés az, hogy a DSpark koncepcionálisan nem korlátozódik a DeepSeek-V4-re. A DeepSeek saját tesztjei és kiadott ellenőrzési pontjai más nyílt modellek családjainak lefedését is tartalmazzák, beleértve az Alibaba nyílt súlyait, a Qwent, és a Google nyílt súlyait, a Gemmát. Ez azt jelenti, hogy a vállalati csapatok, amelyek nyílt súlyú modelleket futtatnak, elvileg DSpark-stílusú vázlatmoduleket képezhetnek vagy finomíthatják saját célmodelljeikhez. Ez nem olyan kapcsoló, amit bármelyik API ügyfél kívülről kapcsolhat, de ez egy módszer, amely más modellekhez is eljuthat, amikor az üzemeltető kontrollálja a súlyokat és a kiszolgáló réteget. A tokenek generálásának sebességéről szóló elképesztő növekedések Az élő DeepSeek-termelési tesztek során a DSpark 51%-kal javította a komplex áteresztőképességet a DeepSeek-V4-Flash esetén egy 80 token/másodperces felhasználói szolgáltatási célnál, és 52%-kal a DeepSeek-V4-Pro esetében egy 35 token/másodperces célértéknél. Az azonos rendszerkapacitás mellett a DeepSeek 60%-os és 85%-os felhasználói generálási sebességnövekedést tett közzé a V4-Flash esetében és 57%-os és 78%-os növekedést a V4-Pro esetében a korábbi MTP-1 termelési alapvonalhoz képest. A különböző sebességi állítások különböző dolgokat mérnek. A V4-Flash 60%-tól 85%-ig terjedő szám és a V4-Pro 57%-tól 78%-ig terjedő szám azt írja le, hogy mennyivel gyorsabban kapják az egyes felhasználók a generált tokeneket, amikor a DeepSeek a DSparkot az MTP-1-hez hasonlítja az azonos gyakorlati rendszerkapacitás mellett. Ezek a tisztább „generálási sebesség” számadatok. A DeepSeek sokkal nagyobb, 661%-os és 406%-os növekedéseket is jelent, de ezek az átfogó áteresztőképességet mérik nagyon szigorú sebességi célok mellett: 120 token/másodperc felhasználónként a V4-Flash esetén és 50 token/másodperc felhasználónként a V4-Pro esetében. Ezen a célvonala mentén a DeepSeek azt mondja, hogy a régebbi MTP-1 alapvonal közelít egy működési sziklához, tehát csak kis számú párhuzamos kérés futtatása érhető el, miközben fenntartják ezt a szintű válaszadási képességet. A DSpark elkerüli a fokozott összeomlást, ezért a teljes rendszer kimenetének százalékos eltérése sokkal nagyobbá válik. Egyszerűen fogalmazva: a 85%-os szám közelebb van ahhoz, hogy „mennyire gyorsabbnak tűnik az utazás egy felhasználó számára” az összehasonlítható körülmények között, míg a 661%-os és 406%-os számok közelebb állnak ahhoz, hogy „mennyi forgalmat bír el még mindig az út”, amikor a régi rendszer már egy szűk keresztmetszet.

Miért fontos a spekulatív dekódolás Az LLM-ek általában egy tokenet generálnak egyszerre. Egy token lehet egy szó, egy szó része, írásjel vagy más kis szövegrészlet. Minden új token az eddig már létrehozott szövegtől függ, így a modellnek folyamatosan meg kell állnia, ellenőriznie kell a teljes kontextust és ki kell választania a következő darabot. Ez pontos, de lassú. Olyan, mint ha egy idősebb szerkesztő minden szót jóváhagy, mielőtt a szerző a következőre léphetne. Az editor lehet kiváló, de a folyamat szűk keresztmetszetet okoz. A spekulatív dekódolás, amelyet a korai Transformer korszakban fejlesztettek ki, próbálja megoldani ezt a szűk keresztmetszetet. Ahelyett, hogy a nagy modellt kérnék arra, hogy minden tokenet egyesével hozzon létre, a rendszer egy kisebb vagy könnyebb vázlat összetevőt használ arra, hogy javasoljon több valószínű következő tokent. A nagy modell ezután párhuzamosan ellenőrzi azt a találgatásokat. Ha a vázlat helyesen tippelt, a rendszer több tokent is előrehalad egyszerre. Ha a vázlat rossz jóslatot tett, a rendszer elutasítja a rossz tokent és mindent, ami utána következik, hozzáad egy javított tokent és újra próbálkozik. A lényeg a sebesség, anélkül hogy megváltoztatná a nagyobb modell szándékos kimenetét. A standard spekulatív dekódolási beállításban a vázlatmodell nem helyettesíti a célmodellt. Inkább egy olyan asszisztens szerepét tölti be, aki előkészít egy durva következő mondatot a senior szerkesztő számára, hogy jóváhagyja vagy elutasítsa. Az ötlet nem a semmiből bukkant fel a mai nagy nyelvi modellekkel. Egy kulcsfontosságú elődjét 2018-ban Mitchell Stern, Noam Shazeer és Jakob Uszkoreit javasolták blokkparalel dekódolásra mély autoregresszív modellek esetén. Módszerük több jövőbeni lépést jósolt párhuzamosan, majd a főmodell által validált leghosszabb prefixet tartotta meg. Ez a tanulmány megalapozta a vázlat-és-ellenőrzés intuícióját a későbbi spekulatív dekódolási munkák mögött. A kutatási vonal 2022-ben vált egyértelműbbé. Heming Xia, Tao Ge és társszerzők bevezették a SpecDec-et, egy vázlat- és-ellenőrzés megközelítést a sorozat-generáláshoz. Ugyanebben az évben Yaniv Leviathan, Matan Kalman és Yossi Matias közzétették a „Gyors Inferencia Transformers által Spekulatív Dekódolás révén” című értekezést, amely segített meghatározni a technika modern verzióját a transformer-alapú nyelvi modellek számára. A DeepMind kutatói 2023-ban egy szorosan kapcsolódó módszert mutattak be, amelyet spekulatív mintázásnak neveztek. Ezek a 2022 és 2023 közötti tanulmányok a legvilágosabb ősök a spekulatív dekódolás jelenlegi LLM inferálási munkáiban történő megvitatásában: egy gyorsabb vázlati folyamat javasolja a tokeneket, és a nagyobb célmodell érvényesíti őket olyan módon, amely megőrzi a célmodell kimeneti eloszlását. Azóta a terület gyorsan fejlődött több variánson, beleértve a külön vázlatmodelleket, többlet-token előrejelző fejeket, fába alapozott érvényesítést, funkciószintű módszereket, mint például az EAGLE, ön-speculációt, Medusa-stílusú extra fejeket és párhuzamos/blokkos vázlatolókat, mint a DFlash. A kulcsfontosságú mutató nem az, hogy hány tokenment vázlatmodell tud találgatni. Hanem az, hogy hány jövendölését fogadja el a nagyobb modell. A hosszú spekulatív blokkok csak akkor segítenek, ha a javasolt tokenek közül elég sok túlél az érvényesítés során. Ellenkező esetben a rendszer azzal költi a számítási teljesítményt, hogy olyan találgatásokat ellenőriz, amelyeket el kell dobnia. Ez a DSpark kontextusa. A spekulatív dekódolás már egy megalapozott inferálási technika a DeepSeek kiadása előtt, támogatásával a főbb kiszolgáló rétegekben és több versengő kutatási megközelítésben. De ez még mindig nem egy megoldott probléma. A sebességnövelések erősen függenek a vázlatmodelltől, a munkaterheléstől, a kiszolgáló beállítástól és a jelenlegi forgalomszinttől. A DSpark hozzájárulása, hogy javítja a kölcsönös kompromisszum mindkét oldalát: próbálkozik összetett token blokkok vázlatait kialakítani, majd csak azon blokkok részeit ellenőrzi, amelyek valóban megtérülnek a tényleges kiszolgáló feltételek mellett. Mit változtat meg a DSpark A DSpark két összefüggő problémát kezel: a rossz találgatásokat és az időpazarló ellenőrzéseket. Először is a rendszer azt használja, amit a DeepSeek féli-autoregresszív generációnak nevez. Egyszerűbben fogalmazva, ez azt jelenti, hogy a DSpark próbálja ötvözni a sebességet a kicsivel több sorozat-tudattal. Egy teljesen párhuzamos vázlatoló több tokent tud találgatni egyszerre, ami gyors, de későbbi találgatásai kevésbé koherensek lehetnek, mivel minden pozíciót túl függetlenül jósolnak meg. Egy tisztán lépésről lépésre haladó vázlatoló jobban tudja követni, hogy egy token hogyan vezet a következőhöz, de elveszti a sebesség előnyének nagy részét. A DSpark próbálja megőrizni a legjobb tulajdonságait mindkettőnek. A munka nagy részére párhuzamos hátteret használ, majd hozzáad egy könnyű sorozatos fejet, amely lehetővé teszi a vázlat számára, hogy figyelembe vegye a közeli tokengromok viszonyait. A cikk példájában egy párhuzamos vázlatológia összezavarhat olyan valószínű mondatrész végét, mint az „érthető” és a „nincs probléma”, furcsa kombinációkat hozva létre, mert túl elkülönítve találgat pozíciókat. A DSpark sorozatos összetevője segít a rendszernek a későbbi tokenek illesztésében a korábbiakhoz. Másodszor, a DSpark hozzáadja a bizalmi ütemezést az érvényesítéshez. Ahelyett, hogy mindig arra kérné a cél modellt, hogy ellenőrizze ugyanannyi vázlat tokent, a DSpark azt becsüli, hogy a vázlat melyik prefixe valószínű, hogy túléli. A hardverrel tudatos ütemező ezt követően módosítja, hogy a vázlat mennyire hosszú legyen ellenőrizve, mind a modell bizalmára, mind a jelenlegi kiszolgáló terhelésre alapozva. Egy egyszerű analógia: ha egy étterem csendes, a séf jobban át tudja nézni a preparált chef munkáját. Amikor a konyha nagyon forgalmas, a séf csak az előkészületek azon ételeire fordít figyelmet, amelyek valószínűleg készen állnak. A DSpark hasonló elképzelést alkalmaz az MI kiszolgálásában. Könnyebb forgalom esetén a rendszer megengedheti magának, hogy hosszabb vázlatprefixeket ellenőrizzen. Nagyobb forgalom esetén levágja az alacsony bizalmú hátsó találgatásokat, mielőtt azok elfoglalják az egyes kapacitását, amelyet más felhasználók számára is felhasználhatnak. A DeepSeek ezt egy gyakori termelési kompromisszum megoldásaként keretezi. A statikus több-tokenes vázlatolás vonzónak tűnhet, de a nagy kapacitású ügynökségek miatt gátolhatja az áteresztőképességet, mivel a rendszer folyamatosan olyan tokenek ellenőrzésével foglalkozik, amelyeket valószínűleg el fognak utasítani. A DSpark ütemezője rugalmasá teszi az érvényesítési keretet, nem pedig feszesen fixált. Offline eredmények: jobb vázlatelfogadás a Qwen és Gemma esetében A DeepSeek offline tesztelte a DSparkot a Qwen3-4B, Qwen3-8B, Qwen3-14B és Gemma4-12B célmodellek esetében matematikai, kódolási és chat benchmarkokon. Ezen a teszt során a csapat a DSparkot hasonlította össze a DFlashel, egy párhuzamos vázlatolóval, és az Eagle3-mal, egy autoregresszív vázlatolóval. A tanulmányban a sikeres hosszú vázlatkörönkénti járások jelentési mértéke szerepel, amely azt méri, hogy átlagosan hány token élte túl az érvényesítést. A három Qwen3 modellméret közül a DSpark a makro-átlagos elfogadott hosszt az Eagle3-hoz képest 30,9%, 26,7% és 30,0%-kal javította. A DFlash-hez képest 16,3%, 18,4% és 18,3%-os elfogadási hosszal javított. A dokumentum azt is mondja, hogy a nyereségek általánosítódnak a Gemma4-12B-re. Ez támogatja Daniel Han fejlesztő által felvetett pontot, aki az X-en hangsúlyozta, hogy a DeepSeek a DSpark működését mutatta be a DeepSeek saját V4 modelljein túl, beleértve a Gemmát és a Qwent. Han-t a közösségi reakciók sorában lehetne szerepeltetni, nem mint az igény egyedüli bizonyítékát. Az erősebb támogatás a DeepSeek saját referenciaértékeitől és kiadott ellenőrzési pontjaitól származik. Az offline eredmények közlik, hogy miért fontos a munkaterhelés. A struktúrált feladatok, mint a matematikai és kódolási feladatok általában magasabb elfogadási hosszakat mutatnak, mint a nyitott végű chat. Ez intuitívan értelmes: egy kód befejezési vagy matematikai lépés gyakran kevesebb ésszerű következő lépést tartalmaz, mint egy szabadformájú beszélgetés. A vállalatok számára ez azt jelenti, hogy a DSpark-stílusú módszerek különösen vonzóak lehetnek a kódoló asszisztensek, adatelemző ügynökök, struktúrált munkafolyamat-automatizálás és más környezetek számára, ahol a kibocsátások előrejelzhetőbb mintákat követnek. Hogyan alkalmazhatják a vállalatok a DSparkot a DeepSeek-V4 nélkül Az egyik legfontosabb kérdés, hogy a DSpark egy DeepSeek-kizárólagos optimalizálás vagy egy szélesebb módszer-e, amely más modellekre is alkalmazható. A válasz: szélesebb módszer, de nem automatikus csatlakoztatás. A nyílt súlyú modellek esetében az útviszonyok viszonylag világosak. Egy vállalat, amely a Qwent, Gemmát, Llamát, Mistralt, Granitot, Command-jellegű nyílt súlyokat vagy más modelleket futtat, amelyeket saját maguk üzemeltethetnek, képezhet vagy finomíthat egy DSpark-stílusú vázlatmodult a célmodellel szemben. A csapat ezután saját munkaterhelésén mérheti az elfogadást, és integrálhatja az érvényesítési ütemezőt az inferálási rétegébe. Ez különbözik attól, hogy csupán a DeepSeek DSpark modulját tölti le, és csatlakoztatja azt bármely modellhez. A spekulatív dekódolás az összhangra épít a vázlatmodul és a célmodell között. A vázlatnak meg kell tanulnia, hogy a célmodell mit valószínű, hogy elfogad. A DeepSeek-V4 képezett vázlatoló nem lesz automatikusan a megfelelő vázlatoló egy másik modellhez, különösen, ha azt egy vállalat belső adataira finomították vagy más érvelési viselkedésre konfigurálták. A DeepSpec munkafolyamata tükrözi ezt. A folyamat adatok előkészítéséből, célnoki modellek válaszainak regenerálásából, célcache építéséből, vázlatmodell képzésből és spekulatív dekódoló akceptálás értékeléséből áll. Domain-specifikus használat esetén a vázlatmodellekhez további finomhangolásra lehet szükség, különösen, ha a célmodell gondolkodási vagy érvelő üzemmódban működik. A birtokolt modellek esetében a válasz attól függ, hogy a vállalat mit irányít. Ha egy vállalat a modell súlyait és a kiszolgáló réteget birtokolja vagy teljes mértékben üzemelteti, elméletileg képes lenne egy DSpark-stílusú vázlatoló képezni és telepíteni. Ha a modellt csak egy extern vendég API-n keresztül látják el, az ügyfél nem tud közvetlenül DSparkot hozzáadni kívülről. Az API szolgáltató implementálhat hasonló optimalizációkat belsőleg, de az ügyfél általában nem férhet hozzá a token-érvényesítési hurokhoz, logitokhoz, csoportos viselkedéshez vagy ütemezőhöz, amely szükséges a DSpark működéséhez. Ez a megkülönböztetés fontos a vállalati vásárlók számára. A DSpark megerősíti a nyílt vagy saját gazdálkodású MI infrastruktúra szükségességét, mert az előrehaladott csapatok számára újabb előnyöket biztosít a sebesség és a költség javításához. De azt is megmutatja, hogy miért válik a modell kiszolgálása egy specializált diszciplínává. Az érték nem csak a modell kiválasztásában rejlik, hanem abban is, hogy milyen intelligensen hajtják végre azt a modellt, amelyet a vállalatok már birtokolnak. Mit kapnak a fejlesztők a DeepSpectól A fejlesztők számára a DeepSpec egy konkrét megvalósítási utat kínál a spekulatív dekódoló vázlatmodellek képzésére és értékelésére. Tartalmaz adat-előkészítési, képzési és benchmark értékelési lépéseket, számos nyílt modell családhoz kiadott ellenőrzési pontokkal együtt. Ez a kiadás nemcsak a DeepSeek-V4 DSpark-kal történő futtatásához hasznos, hanem a kutatók és infrastruktúra csoportok számára is, akik tanulmányozzák, hogyan lehet gyorsabb dekódolást hozzáadni más nyílt modellekhez. Vannak valós telepítési figyelmeztetések. A DeepSpec saját README-je azt mondja, hogy az alapértelmezett Qwen3-4B adat-előkészítési beállítás körülbelül 38 TB céltárhelyet igényelhet, és az alapértelmezett szkriptek egyetlen csomópontot és nyolc GPU-t feltételeznek. Ez a kiadás az AI laborok, felhőcsapatok és bonyolult vállalati AI infrastruktúra csoportok számára azonnal relevánsabbá válik, mint a közönséges alkalmazásfejlesztők számára. Mégis, a tanulási pipeline kiadása fontos. Sok inferálási optimalizálás csupán papírok, homályos benchmarkok vagy zártkörű termelési állítás formájában jelenik meg. A DeepSpec a fejlesztők számára valami közelebb álló kékprintet ad: nem kész vállalati termék, hanem módot kínál a módszer reprodukálására, alkalmazására és értékelésére. Korai közösségi tesztelés A kiadás máris gyors fejlesztői figyelmet vonzott. Rafael Caricio fejlesztő közzétett egy GitHub pull requestet, amely egyértelmű áramkörű DeepSeek-V4-Flash DSpark munkáját dokumentálva, jegyzett benchmark-horgonyokat mutatott be 26,33 token/másodperc sebességgel spekulatív dekódolás nélkül, 39,88 token/másodperc sebességgel az MTP-1-nél, és körülbelül 60 token/másodperc a DSpark-kal - körülbelül 1,5x MTP-1-hez képest és 2,3x a nem spekulatív dekódoláshoz képest. A kést a következő bejegyzés a threadben egy öt alkalommal mért átlagot rögzít, 60,31 token/másodperc sebességgel, 1,51x nyereséggel MTP-1-hez képest és 2,29x a nem spekulatív dekódoláshoz képest. Ugyanaz a munka egy fontos gyakorlati határról is utal: a valós multi-kör kódolási ülések során a teljesítmény csökkenhet, ahogy a vázlatelfogadás csökken a növekvő kontextussal. Más szavakkal, a DSpark gyorsabbá teheti a dekódolást, de az elfogadás minősége még mindig meghatározza, hogy a rendszer mennyi sebességet realizál. Ez hasznos valóságbeli ellenőrzés. A DSpark nem varázslat. Még mindig függ attól, hogy mennyire kiszámítható a következő tokenek és mennyire jól tartja a vázlat előre az irányt a célmodellel. De a korai megvalósítási munkák azt sugallják, hogy a DeepSeek állításai nem csupán tudományosak. A fejlesztők már tesztelik a módszert gyakorlati kiszolgáló környezetekben, és a nyereségeket közelítik a cikkben vázolt egy áramkörű várakozásokhoz. Az összefoglalás A DSpark megmutatja, mennyi teljesítmény áll még rendelkezésre az inferálási rétegben, még akkor is, ha az alapmodell architektúrája változatlan marad. Ahogy az MI vállalatok versenyeznek a modell minőségéért, kontextus hosszúsága és árképzése, a dekódolási hatékonyság egy másik fő csatatérré válik. A gyorsabb generálás alacsonyabb késleltetést jelent a felhasználók számára, nagyobb áteresztőképességet a szolgáltatók számára és jobb gazdasági szempontokat a nagy léptékben az open modellek kiszolgálásában. A DeepSeek kiadása figyelemre méltó, mert ötvözi a termelési tesztelt módszert, a nyílt kódot, a nyilvános ellenőrzési pontokat és a részletes papírt. A fő innováció nem csupán a több tokennek a szövegezése. A cél a rendszer szelektivitásának növelése, hogy mely spekulatív munka érdemes az érvényesítésre. A vállalati csapatok számára a szélesebb tanulság az, hogy a következő hullám az MI teljesítmény növekedéséből nem csupán a nagyobb modellekből fog fakadni. Az is a már meglévő modellek intelligensebb futtatásából fog származni — különösen, amikor ezek a vállalatok elegendő részesedéssel rendelkeznek ahhoz, hogy a modellt hangolják, egy kompatibilis vázlatmodult képezzenek és optimalizálják a szolgáltatási motort a valós munkaterhelések körül.