A.X K2 DSpark vs A.X K2: Cosa ottieni davvero da un modello solo-drafter

La cosa più strana del confronto tra A.X K2 DSpark e A.X K2 è che non si tratta davvero di un confronto. A.X K2 DSpark non può essere usato al posto di A.X K2 — anzi, da solo non può essere usato affatto. È un "checkpoint solo per il drafter" che SK Telecom ha pubblicato silenziosamente su Hugging Face ai primi di agosto, senza alcun annuncio: un modello draft per la decodifica speculativa il cui unico compito è far sì che A.X K2, l'ammiraglia open-weight Mixture-of-Experts da 688 miliardi di parametri dell'azienda, generi token più velocemente, lasciando intatte le sue risposte. Quindi la vera domanda su cui si gioca questo confronto non è "quale è migliore", ma "dovresti eseguire A.X K2 con DSpark o senza?". Ogni elemento di questo articolo è etichettato con la fonte, perché il divario tra ciò che il repository ci dice e ciò che è stato effettivamente misurato è l'intera storia.

Che cos'è in realtà A.X K2 DSpark

La scheda del modello di SK Telecom è insolitamente diretta riguardo allo scopo del modello. A.X K2 DSpark "è un modello bozza di decodifica speculativa DSpark per A.X K2" e "un checkpoint solo per il draft: non ha un uso autonomo ed è pensato per essere caricato da vLLM insieme ad A.X K2 tramite decodifica speculativa." In pratica, significa che lo scarichi, punti una vLLM compatibile sia su di esso che su A.X K2, e i due lavorano come una squadra: DSpark propone token candidati, A.X K2 li verifica e solo i token verificati vengono emessi.

Due dettagli del meccanismo di draft sono conoscibili dal repository. In primo luogo, DSpark propone più token candidati in parallelo invece di scrivere una sequenza di draft un token alla volta, attingendo alle rappresentazioni nascoste di A.X K2 insieme a una leggera modellazione delle dipendenze locali. In secondo luogo, il tutto è costruito per essere senza perdite: ogni candidato viene verificato dal modello target prima di essere accettato, quindi la distribuzione di output di A.X K2 rimane invariata per costruzione.

Il rilascio stesso è un pre-annuncio. La scheda dice che il modello è "attualmente in validazione finale e la sua pubblicazione è prevista entro i prossimi giorni" e che la valutazione è "attualmente in corso" — ogni metrica di throughput, TPOT e lunghezza media accettata sulla scheda è ancora elencata come TBD.

Perché questo "versus" è in realtà "con versus senza"

Poiché A.X K2 DSpark non ha un utilizzo autonomo, non esiste alcuno scenario in cui lo si preferisca ad A.X K2. La scelta è tra A.X K2 da solo e A.X K2 con il modello draft collegato. Per quanto riguarda la qualità dell'output, le due configurazioni sono identiche per costruzione; l'unico parametro che può variare è la velocità di decodifica.

Per la cronaca, ecco cos'è A.X K2: un decoder Mixture-of-Experts da 688B totali e 33B attivi, con 256 esperti più un esperto condiviso (8 attivi per passaggio in avanti), 61 layer, 64 testine di attenzione e un vocabolario di 163.840 token, rilasciato con pesi aperti sotto licenza Apache 2.0 il 29 luglio. È stato pre-addestrato su circa 8,2 trilioni di token nativamente in MXFP8, utilizza la Sparse Gated Attention di SK Telecom per l'efficienza su contesti lunghi e supporta un contesto di 262.144 token (128K nativi estesi a 256K tramite YaRN). SK Telecom riferisce che in media supera A.X K1 di +32,2 punti percentuali su 14 benchmark, con valutazioni su contesti lunghi e agenti in aumento di circa 83,9 punti — tutti dati dichiarati dal fornitore, senza alcun punteggio composito indipendente ancora pubblicato.

DSpark è progettato specificamente per quell'architettura. La scheda indica che è abbinato alla struttura MoE di A.X K2, al layout dell'attenzione e alla configurazione nativa da 256K, e non è validato per nessun altro target. Eredita lo stesso contesto di 262.144 token, quindi eseguirlo non costa nulla in termini di dimensione della finestra.

Leggere la scheda del modello: conoscibile, non ancora confermato

La repo ti dà un quadro chiaro di cos'è il modello e un breve elenco di cose che non ti dice.

Conoscibile oggi:

• È un checkpoint solo per drafter, senza uso autonomo, caricato da vLLM insieme ad A.X K2 tramite decodifica speculativa.

• La licenza è Apache 2.0; i pesi sono liberamente scaricabili e utilizzabili.

• La lunghezza del contesto corrisponde a A.X K2 con 262.144 token.

• Funziona tramite il fork vLLM di SK Telecom (il repository SKT-AI/vllm, branch axk2-v0.23.0) utilizzando un flag --speculative-config.

• Il metodo è documentato in un articolo, "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation" (arXiv:2607.05147, presentato il 6 luglio 2026) — quello stesso articolo è anche la fonte dei numeri di speedup che vedrete citati.

Nessun provider di inferenza lo distribuisce oggi, quindi non c'è un'API ospitata da chiamare.

Non ancora confermato:

• Un annuncio ufficiale — la scheda promette il rilascio pubblico "entro i prossimi giorni."

• Qualsiasi valore di speedup specifico di A.X K2. La valutazione è in corso e ogni metrica di prestazione è TBD.

• Quanto aiuta effettivamente sotto carico, che la scheda segnala come "dipendente dal carico di lavoro".

• Qualsiasi misurazione indipendente di terze parti del modello di draft.

Come DSpark si differenzia dalla decodifica speculativa ordinaria

La decodifica speculativa è un trucco ben collaudato: un piccolo e veloce modello bozza scrive una previsione dei prossimi token, e il modello grande controlla l'intera previsione in un unico passaggio in avanti, accettando il prefisso che supera la verifica prima di compiere un passo correttivo. Se fatto bene, riduce drasticamente la latenza senza perdita di qualità.

Il punto, come lo inquadra il paper DSpark, è che i recenti drafters paralleli — che propongono lunghe sequenze in un'unica passata — soffrono di un "rapido decadimento dell'accettazione" perché i token successivi nella bozza non portano alcuna dipendenza da quelli precedenti, quindi vengono rifiutati molto più spesso. E verificare alla cieca lunghi blocchi spreca capacità di batch su token che probabilmente verranno rifiutati, il che danneggia la produttività proprio nei sistemi di servizio ad alta concorrenza.

DSpark affronta entrambi i problemi:

• Bozza semi-autoregressiva. Accoppia un backbone parallelo con un modulo sequenziale leggero, aggiungendo la modellazione delle dipendenze intra-blocco così che i token di bozza successivi dipendano da quelli precedenti — ed è proprio questo che mitiga il decadimento del suffisso.

• Verifica programmata in base alla confidenza. Anziché verificare una lunghezza di blocco fissa, adatta la lunghezza di verifica a ogni richiesta, basandosi sulle probabilità stimate di sopravvivenza del prefisso e sul profilo di throughput del motore. La verifica diventa sensibile al carico.

I numeri del paper — e ciò che non ti dicono

Ecco il numero che vedrete citato: DSpark "accelera le velocità di generazione per utente dal 60 all'85 percento" a livelli di throughput corrispondenti, rispetto alla baseline di produzione MTP-1. L'articolo riporta anche un sostanziale miglioramento della lunghezza accettata rispetto ai drafters autoregressivi e paralleli all'avanguardia nei benchmark offline, e afferma che previene un grave degrado del throughput in condizioni di interattività rigorose.

Leggi le scritte in piccolo, perché è importante per questo specifico confronto: quel dato del 60–85% è stato misurato nel sistema di serving di DeepSeek-V4 in condizioni di traffico utente reale — non su A.X K2. È un'affermazione sul metodo DSpark implementato sullo stack di un altro modello. La scheda DSpark di A.X K2, al contrario, non ha ancora alcun numero di speedup. Il quadro onesto di questo abbinamento è quindi: output identico per costruzione, e uno speedup che il paper del metodo ritiene plausibile, ma che SK Telecom stessa non ha ancora misurato sul modello per cui è stato costruito questo checkpoint provvisorio.

Cosa serve davvero per eseguirlo

Il prerequisito è la parte che farà desistere la maggior parte delle persone: devi auto-ospitare A.X K2. Non esiste un'API ospitata per il modello target — è open-weight, e servire un MoE con 688B/33B attivi è un impegno infrastrutturale serio. DSpark è rilevante solo per i team che hanno già fatto questo impegno.

Se ne hai, il costo marginale di aggiungere il modello draft è basso:

• Scarica il checkpoint provvisorio Apache 2.0 ed esegui il fork vLLM di SK Telecom (ramo axk2-v0.23.0).

Abilita la decodifica speculativa tramite il flag --speculative-config, puntandolo al checkpoint DSpark.

• Riserva memoria extra per i pesi del draft e accetta che ora sei su un fork del fornitore di vLLM anziché sulla versione stock — una considerazione di manutenzione.

• Ricordate l'avvertenza dell'articolo stesso secondo cui la verifica non è gratuita: in condizioni di elevata concorrenza, una verifica imprudente consuma la capacità del batch, che è esattamente la modalità di errore che la verifica programmata in base alla confidenza è progettata per gestire.

Un'altra cosa che vale la pena sapere: Hugging Face segnala che i download "non vengono tracciati per questo modello", quindi non c'è alcun segnale pubblico su quanti team lo abbiano effettivamente provato.

Chi dovrebbe scegliere cosa

Esegui la versione standard di A.X K2 se una qualsiasi di queste condizioni ti descrive:

Utilizzi vLLM standard e non vuoi un secondo checkpoint o un fork del vendor nel percorso.

I tuoi carichi di lavoro sono vincolati dalla produttività ma non dalla latenza, e gli utenti tollerano di attendere generazioni lunghe.

Preferiresti aspettare la versione ufficiale e le prime misurazioni indipendenti.

Esegui A.X K2 con DSpark se sei tu:

• Se auto-ospiti A.X K2 e la latenza di generazione o il throughput dei token è ciò che causa problemi.

• I carichi di lavoro a contesto lungo e agentici costringono gli utenti ad attendere output lunghi — il regime per cui è stato progettato il decoding speculativo.

Sei a tuo agio nell'eseguire un componente pre-annuncio il cui svantaggio è limitato: nel peggiore dei casi non aiuta e non può cambiare la qualità dell'output.

Non scegliete nessuno dei due se non fate affatto self-hosting di un MoE da 688B. La sovranità e i punti di forza nella lingua coreana di A.X K2 vi raggiungono solo se lo eseguite, e molti team accederanno invece ai modelli open di frontiera tramite un catalogo hosted. È qui che mantenere l'integrazione agnostica rispetto al modello ripaga: l'endpoint compatibile con OpenAI di OrcaRouter copre oltre 200 modelli al prezzo di listino del provider, con margine 0%, failover automatico e un DSL di routing per comporre più modelli in un'unica chiamata. (Né A.X K2 né A.X K2 DSpark sono ospitati oggi da nessuna parte — incluso su OrcaRouter — quindi questo riguarda il resto del vostro stack, non il routing di questa coppia.) L'approccio resta comunque valido: provate un modello non collaudato su una frazione del traffico e andate automaticamente in failover, piuttosto che scommettere su di esso un percorso di produzione.

Cosa guardare dopo

Il quadro è semplice: la repo è reale, il metodo è documentato, le misurazioni no. Le tre cose da tenere d'occhio sono la promessa release pubblica (la scheda dice "entro i prossimi giorni"), i primi numeri di throughput o latenza specifici per A.X K2 una volta conclusa la valutazione di SK Telecom, e se qualche provider di inferenza adotta la coppia — che è ciò che renderebbe DSpark rilevante per i team che non fanno self-hosting.

Domande frequenti

Può A.X K2 DSpark sostituire A.X K2?

No. È un checkpoint esclusivamente per il drafter, senza uso autonomo — esiste per rendere più veloce la decodifica di A.X K2, non per essere un'alternativa ad esso. Non puoi eseguire A.X K2 DSpark senza A.X K2.

DSpark cambia la qualità dell'output di A.X K2?

No, per costruzione. Ogni token candidato viene verificato da A.X K2 prima di essere accettato, quindi la distribuzione dell'output rimane invariata — la scheda descrive l'approccio come senza perdita.

Devo auto-ospitare A.X K2 per usare DSpark?

Sì. DSpark viene caricato da vLLM insieme ad A.X K2, quindi non c'è nessun target per cui debba generare bozze, a meno che tu non stia eseguendo il target 688B. Oggi non esiste un'API ospitata per nessuno dei due modelli.

DSpark funziona con altri modelli?

SK Telecom l'ha progettato per l'architettura MoE, la struttura di attenzione e il contesto di 256K di A.X K2, e non l'ha validato rispetto ad alcun altro target.

Il verdetto

A.X K2 DSpark contro A.X K2 è un "versus" in cui la risposta onesta è "entrambi." Se usi già A.X K2 e gli utenti aspettano generazioni lunghe, il modello draft è un esperimento gratuito e a basso rischio: pesi Apache 2.0, nel peggiore dei casi nessun speedup e nessuna possibile regressione di qualità per costruzione. Se non hai vincoli di latenza — o non stai affatto hostando un MoE da 688B — puoi tranquillamente ignorarlo finché i numeri di valutazione di SK Telecom non arrivano e la release pubblica promessa non rende ufficiale il modello. Quello che non dovresti fare è scambiare il 60–85% del paper per una misurazione di questo modello: in questo momento, tutto ciò che è specifico di DSpark in A.X K2 è ancora tutto da definire.