K-EXAONE-2.0-750B-A37B-DSpark: il MoE coreano da 750B di LG sta arrivando su vLLM

Il 9 agosto 2026, una pull request è stata aperta nel repository di vLLM per aggiungere K-EXAONE-2.0-750B-A37B-DSpark — la variante a decodifica speculativa del modello di punta coreano da 750 miliardi di parametri di LG AI Research. Quattro giorni dopo, il 13 agosto, una seconda PR più fondamentale ha reso concreta la fuga di notizie: vLLM ora ha un percorso di configurazione generico DSparkDraftModel, che mappa qualsiasi checkpoint di Hugging Face che dichiari architectures=DSparkDraftModel con model_type=qw​en​3 sul riconosciuto Qw​en3DSparkModel, con un piano di test che serve effettivamente il drafter RadixArk Qw​en​3.8-2.4T-A95B-DSpark tramite il metodo spec dspark. Il K-EXAONE-2.0-750B-A37B base è stato rilasciato il 31 luglio con licenza Apache 2.0, e al lancio vLLM poteva servirlo con il metodo di draft MTP ma non con DSpark — il drafter che LG distribuisce e che afferma valere un'accelerazione della decodifica di 3–5×. DSpark stesso è il metodo di Deep​Seek, lo stesso drafter semi-autoregressivo che gira su Deep​Seek-V4-Pro-DSpark e Deep​Seek-V4-Flash-DSpark, quindi le due PR insieme sono il segnale più chiaro finora che lo stack di decodifica speculativa di Deep​Seek sta diventando il default per i pesi aperti.

Questo è un articolo su ciò che sappiamo finora, non una notizia di lancio. Entrambe le pull request sono aperte e non ancora integrate, il checkpoint DSpark non ha un benchmark indipendente, e il dato sull'accelerazione di LG è una dichiarazione del fornitore. Tutto ciò che segue è etichettato di conseguenza. Ciò che è reale oggi: i pesi sono su Hugging Face, il modello base è stato rilasciato, il decoder speculativo DSpark di vLLM serve già i checkpoint di Deep​Seek e Kim​i, e il percorso di configurazione generico che consentirebbe a un drafter DSpark di terze parti di caricare — il tassello che questa fuga di notizie aspettava — è ora presente in una pull request pubblica, testato ma non ancora rilasciato.

La versione breve

• PR #51558, aperta il 9 agosto 2026, aggiunge K-EXAONE-2.0-750B-A37B-DSpark a vLLM; è aperta e non ha ancora approvazioni.

PR #52197, aperto il 13 agosto 2026, introduce il supporto generico alla configurazione DSparkDraftModel — architectures=DSparkDraftModel con model_type=qwen3, normalizzato a Qwen3DSparkModel — e il suo piano di test esegue il drafter RadixArk Qwen3.8-2.4T-A95B-DSpark con il metodo spec dspark e sette token spec. Anche questo è aperto e non ancora unito.

• DSpark è il drafter della famiglia EAGLE che Deep​Seek ha reso open-source ed è disponibile su Deep​Seek-V4-Pro-DSpark e Deep​Seek-V4-Flash-DSpark; LG è l'adozione di maggior rilievo da parte di un altro laboratorio finora, e il drafter Qw​en​3.8 di RadixArk è un secondo drafter indipendente.

La variante DSpark è il MoE da 750B con 78 strati più cinque strati di draft aggiuntivi; LG afferma che DSpark e MTP forniscono ciascuno un'accelerazione della decodifica di circa 3–5×, pensati per carichi di lavoro agentici a lungo orizzonte.

• Al lancio vLLM supportava MTP per K-EXAONE 2.0 ma non DSpark; la PR specifica del modello e il percorso di configurazione generico rappresentano l'arrivo del supporto per DSpark.

• Nessun provider ospita oggi alcun checkpoint di K-EXAONE 2.0, e ogni benchmark riportato sulla scheda è di LG stessa.

Cosa sono le pull request (e cosa non sono)

La PR #51558 di vLLM, "[Model] Add K-EXAONE-2.0-750B-A37B-DSpark," è stata aperta da lkm2835 — lo stesso contributore dietro il precedente supporto a K-EXAONE in vLLM (#50524 per il modello base) e in SGLang (#33648). È una PR fork etichettata con il tag new-model; è stata richiesta la revisione ai code owner di vLLM e non ha ancora ricevuto approvazioni. La descrizione è di tre righe: aggiunge il supporto per il checkpoint DSpark "sviluppato da LG AI Research", collega la scheda del modello su Hugging Face e il report tecnico di K-EXAONE 2.0 (arXiv 2608.04505), e fa riferimento al precedente lavoro in vLLM in #50524.

Il PR del 13 agosto è di natura diversa. #52197, "Support DSpark configs with architectures=DSparkDraftModel + model_type=qw​en​3," aggiunge un livello di normalizzazione generico: un checkpoint draft di Hugging Face che si dichiara DSparkDraftModel su un tipo di modello qw​en​3 viene rimappato a un Qw​en3DSparkModel che lo spec-decoder esistente di vLLM può caricare. Il modello di riferimento nel suo piano di test è RadixArk/Qw​en​3.8-2.4T-A95B-DSpark — uno speculatore DSpark per il target di classe max Qw​en​3.8-2.4T-A95B — servito con il metodo spec dspark e una finestra spec di sette token. Il messaggio del commit è l'intera idea: "architectures=DSparkDraftModel+model_type=qw​en​3." Il punto della modifica è che un drafter DSpark di terze parti dovrebbe essere caricabile tramite configurazione, piuttosto che richiedere codice per modello, che è il modo in cui ogni checkpoint DSpark supportato è cablato oggi. È aperto e non unito, come #51558.

Leggi quello status alla lettera. "Il supporto sta venendo aggiunto" non è "il supporto è disponibile": finché uno dei due PR non verrà unito e distribuito in una release, una build standard di vLLM non caricherà ancora la variante DSpark. La scheda del modello stessa dice che servire K-EXAONE 2.0 con DSpark non è attualmente supportato su vLLM, che usa invece MTP. Questi due PR sono i passaggi che cambiano quella frase — se e quando verranno uniti.

Perché DSpark è la vera storia qui

Il nome del modello fa un bel po' di lavoro. "A37B" significa 37 miliardi di parametri attivi per token. "DSpark" è il drafter di decodifica speculativa che Deep​Seek ha introdotto quest'anno: un modello draft semi-autoregressivo della famiglia EAGLE che propone un blocco di token in un'unica passata e lascia che il modello target li verifichi, così la qualità dell'output resta invariata mentre la generazione diventa più veloce. Deep​Seek lo ha reso open-source e distribuisce il drafter con i propri checkpoint Deep​Seek-V4-Pro-DSpark e Deep​Seek-V4-Flash-DSpark, con speedup riportati dalla community nell'intervallo del 60–85% per Flash e del 57–78% per Pro rispetto a una baseline MTP a token singolo.

Quello che la nuova PR chiarisce è che il supporto a DSpark in vLLM non è mai stato la questione aperta. I documenti stessi di vLLM elencano già i moduli DSpark per i checkpoint di Deep​Seek-V4, Kimi K3 e Gem​ma​4, e il team ha descritto il design in un post tecnico di luglio. È però un'integrazione cablata a mano: un elenco privilegiato di checkpoint, non un percorso che chiunque possa utilizzare. Il checkpoint K-EXAONE semplicemente non è in quell'elenco. #52197 è il tentativo di rendere generico il percorso: una mappatura di configurazione (DSparkDraftModel più qw​en​3) invece di un'altra classe di modello personalizzata, e un drafter di terze parti come caso di test di riferimento anziché un modello Deep​Seek. È per questo che una storia di leak di checkpoint draft è in realtà una storia di infrastruttura.

K-EXAONE-2.0-750B-A37B-DSpark mantiene i 78 layer del modello base e aggiunge cinque layer draft DSpark, e la scheda del modello di LG afferma che sia DSpark che MTP accelerano la generazione di circa 3–5× — i suoi stessi numeri, pensati per "carichi di lavoro a lungo orizzonte come i compiti agentici", dove la latenza di decodifica è il collo di bottiglia. Ne conseguono due cose. Primo, la decodifica speculativa sta diventando una funzionalità di prima classe dei modelli di frontiera aperti, piuttosto che un trucco di serving che si aggiunge a posteriori. Secondo, è lo stack di draft di Deep​Seek a diventare il default — ed è esattamente il motivo per cui un modello di punta sovrano sostenuto dal governo coreano che lo include conta al di là della solita notizia del "nuovo modello".

Il modello alla base della PR

K-EXAONE-2.0-750B-A37B-DSpark è una variante di K-EXAONE 2.0, il successore della linea K-EXAONE da 236B di LG e il più grande modello foundation nativo della Corea del Sud, sviluppato nell'ambito del programma di IA sovrana del governo. Il modello base — 750B di parametri totali, 37B attivi, Mixture-of-Experts con 256 esperti e 8 attivi per token, una finestra di contesto di 262.144 token, dieci lingue, Apache 2.0 — è stato pubblicato su Hugging Face il 31 luglio 2026, ottenuto tramite upcycling dal predecessore da 236B piuttosto che addestrato da zero.

Le medie dei benchmark di LG (24 benchmark, 70.1 complessivo) mostrano la forma attesa per un modello sovrano coreano: forti risultati dichiarati nel retrieval a contesto lungo, nella sicurezza sociale coreana e nel coding agentico, insieme a cifre che restano indietro rispetto a Qw​en​3.5 di Alibaba sul ragionamento generale (83.5 vs 89.8 su MMLU-Pro, per esempio). Nessuno di questi risultati è ancora stato verificato in modo indipendente. La variante DSpark non cambia nessuno di questi punteggi — è un artefatto di serving, un modo più veloce per eseguire lo stesso modello — ed è esattamente per questo che sta emergendo nelle pull request dei framework di inferenza piuttosto che in un annuncio.

La realtà del serving dietro un MoE da 750B

È qui che il supporto DSpark fa davvero la differenza. K-EXAONE-2.0-750B-A37B-DSpark è un checkpoint da 751 miliardi di parametri in BF16/F32, e le indicazioni di LG prevedono un minimo di due nodi con otto GPU NVIDIA H200 ciascuno (16 GPU in totale, tensor-parallel 16). A quella scala, il throughput di decodifica è tutto — token al secondo e costo di un lungo turno agentico — ed è esattamente ciò che la decodifica speculativa affronta. Un'accelerazione della decodifica di 3–5×, se regge al di fuori dell'ambiente di test di LG, è la differenza tra un cluster H200 economicamente sostenibile e uno che non lo è. LG documenta inoltre un problema di collasso della generazione sulle GPU B200 che richiede il workaround --disable-prefill-cuda-graph finché non viene risolto — un promemoria che questo è serving all'avanguardia, non una soluzione chiavi in mano.

Quanto costa, e come potresti provarlo davvero

Oggi nessuna API serve K-EXAONE 2.0. La scheda Hugging Face per la variante DSpark riporta ancora "questo modello non è distribuito da alcun provider di inferenza", e un footprint di 16×H200 significa che può essere servito da un'API ospitata solo quando qualcuno con quell'hardware decide di ospitarlo. Questo è il vero punto di attrito: la frontiera dei pesi aperti è sempre più un problema di serving, non di disponibilità.

Quando un provider lo adotta, l'accelerazione dovuta alla decodifica speculativa si rifletterà sul prezzo per token, e il costo di passaggio per provarlo dovrebbe essere quasi nullo se la tua applicazione è già agnostica rispetto al modello. Su OrcaRouter — un endpoint compatibile con Open​AI che copre oltre 200 modelli, con i prezzi di listino dei provider applicati senza alcun ricarico — un modello che arriva su un qualsiasi provider a monte diventa una modifica di routing anziché una re-integrazione, e il failover automatico fa sì che un nuovissimo MoE da 750B che si rivela lento o instabile venga sostituito da un modello noto e affidabile senza alcun incidente. Per essere chiari: oggi OrcaRouter non ospita K-EXAONE-2.0-750B-A37B-DSpark, e non lo fa nemmeno nessun'altra API che siamo riusciti a trovare. Il senso del livello di routing è essere già predisposti per il giorno in cui uno di essi lo farà.

Cosa stiamo guardando

• Le due PR da unire. #51558 (specifico del modello) e #52197 (configurazione generica) sono entrambe aperte senza approvazioni. Il merge e il rilascio sono ciò che trasforma il "supporto DSpark" da pull request a flag che puoi effettivamente passare.

• L'ambito del percorso generico. Se la #52197 viene integrata, qualsiasi DSparkDraftModel tipizzato qwen3 su Hugging Face diventa caricabile tramite configurazione — la differenza tra DSpark come lista di checkpoint approvati e DSpark come standard aperto.

• Un primo punteggio indipendente. Ogni benchmark sulla scheda è gestito da LG. Il primo punto dati di Artificial Analysis o arena su un MoE coreano da 750B sarà il primo numero non pubblicato dal fornitore.

• DSpark oltre Deep​Seek. LG e RadixArk sono ora due productizer indipendenti del metodo di draft di Deep​Seek, e il percorso generico vLLM è un terzo segnale che lo stack si sta consolidando.

• Serving quantizzato. LG distribuisce checkpoint FP8 e NVFP4 del modello base; una variante DSpark quantizzata che richiede meno GPU cambierebbe le dinamiche economiche più velocemente di qualsiasi benchmark.

Domande frequenti

K-EXAONE-2.0-750B-A37B-DSpark è stato rilasciato?

I pesi sono su Hugging Face con licenza Apache 2.0, ma questa non è una storia di lancio: il supporto vLLM consiste in due pull request aperte e non ancora integrate (#51558 e #52197), il dato sullo speedup proviene da LG stessa, e nessun provider ospita il modello. Ciò che «confermato» significa qui è il percorso di serving — il supporto generico per la configurazione di DSparkDraftModel ora esiste in una PR pubblica con un piano di test eseguibile — non che una build vLLM rilasciata possa già servire il modello.

Qual è la differenza tra K-EXAONE-2.0-750B-A37B e la variante DSpark?

I 78 layer del modello base più cinque layer draft DSpark per la decodifica speculativa — gli stessi pesi sottostanti, gli stessi benchmark e un artefatto di serving più rapido da decodificare, piuttosto che un modello diverso.

È DSpark di LG o di DeepSeek?

DSpark è il metodo di decodifica speculativa open-source di Deep​Seek, disponibile anche su Deep​Seek-V4-Pro-DSpark e Deep​Seek-V4-Flash-DSpark; LG è finora l'adozione di maggior rilievo, e il Qw​en​3.8-2.4T-A95B-DSpark di RadixArk è un secondo drafter indipendente costruito sullo stesso metodo. La scheda del modello di LG dichiara lo stesso range di accelerazione di 3–5×.

Posso eseguire K-EXAONE-2.0-750B-A37B-DSpark sul mio hardware oggi?

Solo tramite self-hosting: le indicazioni di LG richiedono un minimo di sedici GPU NVIDIA H200, e le release standard di vLLM, SGLang e Transformers necessitano ancora di fork non uniti o del percorso di configurazione generica in sospeso per riconoscere l'architettura. Il supporto per DSparkDraftModel in #52197 è la cosa più vicina a un percorso condiviso, ma è ancora una pull request aperta.

Ciò che rende questo degno di attenzione non sono le pull request in sé — ma ciò che segnalano. Una nave ammiraglia sovrana coreana da 750 miliardi di parametri, con licenza Apache-2.0, ha scelto di distribuire lo stack di decodifica speculativa di Deep​Seek, una società di inferenza indipendente ha costruito un drafter DSpark per un Qw​en​3.8 di classe max, e vLLM sta rispondendo con un percorso di configurazione generico invece di una patch per modello. È così che i modelli aperti di frontiera diventano reali — non nel momento in cui i pesi vengono rilasciati, ma nel momento in cui i drafter vengono integrati.