Spark3 Leak: i modelli piccoli da 1.7B e 4B di iFLYTEK sono in fase di integrazione in vLLM

Spark3 non ha pesi pubblici, nessuna model card, nessun annuncio — eppure questa settimana è stata aperta una pull request nel motore di inferenza vLLM che descrive due modelli, Spark3-1.7B e Spark3-4B, con notevole dettaglio. La pull request #53373 nel repository vLLM, "[Model] Add Spark3 Model," aggiunge il supporto nativo all'architettura Spark3: attenzione a finestra scorrevole, un budget di pensiero controllabile con quattro livelli, contesto nativo da un milione di token su entrambe le dimensioni, e un ID modello che punta a iFLYTEK. Nulla di tutto ciò è confermato dal fornitore, e nulla è stato pubblicato. Questo è un articolo "cosa sappiamo finora": la pull request è reale, e tutto ciò che si dice che i modelli facciano non è verificato finché iFLYTEK — o chiunque pubblichi Spark3 — non rilascia effettivamente i pesi.

La fuga di notizie: una pull request che si legge come un foglio di specifiche

Il segnale è una PR vLLM aperta, inviata da un utente GitHub chiamato KnightYao (un contributor con sede a Hefei che indica l'Università di Scienza e Tecnologia della Cina), e al 23 agosto 2026 non è stata ancora unita. Un maintainer di vLLM ha richiesto modifiche il 22 agosto con la nota "hold for discussions." La PR è precoce e contestata, il che è normale per questo tipo di integrazione — ed è anche insolitamente dettagliata per una PR di framework riguardante un modello che nessuno al di fuori del laboratorio può scaricare.

Il diff tocca otto file. Aggiunge un'implementazione di Spark3ForCausalLM nel model executor di vLLM, uno Spark3Config nativo registrato nei registri di configurazione e dei modelli di vLLM, il supporto per l'attenzione a finestra scorrevole e l'attenzione completa, oltre al gating dell'output dell'attenzione per testa, il caricamento dei pesi con parallelismo su tensor e pipeline e un parser di strumenti XML Spark3, affinché le chiamate agli strumenti del modello possano essere decodificate in modo strutturato. Aggiunge inoltre una riga alla documentazione dei modelli supportati di vLLM, che elenca il checkpoint come XHToken/Spark3-1.7B. La descrizione afferma addirittura che l'integrazione è stata sottoposta a benchmark: 500 richieste concorrenti, successo al 100%, circa 106 richieste al secondo e 13,5K token di output al secondo sulla configurazione di test dell'autore. Si tratta di numeri auto-dichiarati dalla persona che ha scritto la PR, non di un benchmark indipendente, e vanno interpretati esattamente in questo modo.

Perché iFLYTEK è la capogruppo ovvia — ma non confermata —

Niente nella PR nomina il fornitore. Ma l'ID del checkpoint che registra, XHToken/Spark3-1.7B, si trova sotto l'organizzazione XHToken su Hugging Face, e quell'organizzazione è di iFLYTEK: la pagina dell'organizzazione la elenca come azienda, collega a opensource.iflytek.com e attualmente mostra zero modelli pubblici e zero dataset pubblici. "XH" è l'abbreviazione naturale di 星火 (Xinghuo, "Spark"), la famiglia di modelli di iFLYTEK. Aggiungi la posizione dell'autore, Hefei — iFLYTEK ha sede a Hefei — e l'inferenza è circa quanto di più forte si possa ottenere prima che il fornitore la confermi.

È in linea con il recente modello di comportamento di iFLYTEK. Lo Spark X2 dell'azienda, rilasciato a febbraio 2026, era esplicitamente pensato per casi d'uso in ambito educativo, medico, automobilistico e per agenti, e la sua linea SparkAuto-EMM di modelli on-device è disponibile in dimensioni ridotte che vanno da 0,5B fino a 7B. Due giorni prima che questo comunicato stampa venisse alla luce, durante la conferenza sui risultati intermedi del 21 agosto, iFLYTEK ha dichiarato che era in arrivo un nuovo modello di punta di uso generale costruito interamente su infrastruttura di calcolo domestica, con una versione per fasi prevista "entro la fine di agosto" e un lancio completo in occasione del 1024 Developer Day di ottobre. Se Spark3-1.7B e Spark3-4B facciano parte di quel rilascio per fasi o di un percorso separato incentrato sull'edge computing è una questione aperta a cui il comunicato non risponde.

Quello che i modelli si dice siano

Le affermazioni della PR, tutte non verificate:

• Due dimensioni. Spark3-1.7B e Spark3-4B. Entrambi sono descritti come design orientati all'efficienza, utilizzando l'attenzione a finestra scorrevole piuttosto che un layout di attenzione densa e completa.

• Contesto nativo da 1 milione di token su entrambi. Non è una promessa di modalità estesa — la PR dice che il contesto è nativo dell'architettura, il che metterebbe un milione di token su un modello abbastanza piccolo da essere plausibile su una singola GPU.

• Un budget di pensiero a quattro livelli. Il ragionamento può essere impostato su nessuno, basso, medio o alto, un design con pensiero commutabile che consente a un'applicazione di bilanciare la profondità di ragionamento con latenza e costo per chiamata.

• Oltre 200 lingue e solidità negli esami cinesi. Il comunicato stampa afferma prestazioni elevate nel rispondere a domande per K-12 e Gaokao — un tratto distintivo di iFLYTEK, data l'attività educativa dell'azienda — e copertura multilingue in oltre 200 lingue.

• Orientamento alla programmazione e agli agenti.Affermazioni di forte generazione di codice, utilizzo di strumenti, esecuzione multi-step e ragionamento su contesti lunghi per le sue dimensioni, supportate dal parser XML per strumenti incluso nella stessa PR.

La cosa degna di nota è il contesto nativo da 1M su un modello da 1.7B.

La lunghezza del contesto è il punto in cui i piccoli modelli sono rimasti bloccati. Nel panorama attuale dei pesi aperti, un modello da 1,7B–4B viene tipicamente distribuito con una finestra nativa da 32K–256K: i checkpoint piccoli di Qwen3 sono nativi a 32K, con 131K tramite rope scaling, e anche il miglioramento di Qwen3.5 con nativi 256K sulle varianti piccole è un passo recente. Il contesto da milioni di token finora è stata una caratteristica dei modelli grandi: i checkpoint con contesto da 1M di GLM hanno centinaia di miliardi di parametri. Se Spark3 offre davvero una finestra nativa da 1M su un modello da 4B, sarebbe una specifica davvero insolita, e l'architettura di attenzione a finestra scorrevole è proprio il modo per renderla economica in termini di memoria. L'avvertenza che va accanto a questo: un numero headline di 1M nativo è facile da scrivere in un comunicato stampa e difficile da rendere utile nella pratica. La qualità del contesto lungo — il modello riesce davvero a trovare e usare un fatto risalente a 700K token indietro — è una questione separata da quanti token entrano nella finestra, e non esiste ancora una valutazione indipendente.

Il budget di pensiero controllabile è importante per lo stesso motivo. Quattro livelli di ragionamento (nessuno / basso / medio / alto) sono un design a pensiero commutabile nello spirito della modalità di pensiero on/off di Qwe​n3, ma più ricco: invece di una scelta binaria, un'applicazione può scegliere un livello per richiesta — nessun pensiero per una traduzione, alto per un turno di agente multi-step — e pagare solo per il ragionamento di cui ha bisogno. Per un carico di lavoro agentico o batch, questa è esattamente la manopola che trasforma un piccolo modello "capace ma costoso" in uno a costi gestiti.

La ricetta post-addestramento si adatta a uno schema del 2026.

La PR dice che Spark3 è stato post-addestrato con "Scaled Reinforcement Learning e MOPD". MOPD — Multi-Teacher On-Policy Distillation — è una tecnica reale e attuale, descritta in un paper arXiv (2606.30406): addestrare insegnanti RL specializzati per dominio in parallelo, per poi distillarli di nuovo in un unico studente sui rollout dello studente stesso, minimizzando la reverse KL per token rispetto all'insegnante giusto per ogni prompt. È la ricetta del 2026 che permette a un singolo modello di ereditare capacità matematiche, di coding e di agente senza che una run RL combatta contro un'altra, ed è stata pubblicamente accreditata nel post-addestramento di modelli come MiMo Flash V2, DeepSeek V4 e Nemotron 3 Ultra. Il fatto che Spark3 citi la stessa ricetta lo colloca in quella generazione — modelli piccoli, tecniche di post-addestramento di frontiera. Significa anche che le "forti affermazioni su coding e agente" hanno un meccanismo plausibile dietro di sé. Plausibile non è la stessa cosa di dimostrato: le affermazioni restano riportate dal vendor finché non compaiono i pesi e non vengono eseguite valutazioni indipendenti.

Ciò che è genuinamente sconosciuto

Quasi tutto ciò che ha un calendario sopra:

• Data di rilascio. Nessun peso su Hugging Face, nessun annuncio, nessuna tempistica. L'organizzazione XHToken è vuota oggi.

• Conferma del fornitore. iFLYTEK non ha detto nulla su Spark3. Il link dell'organizzazione XHToken è una prova forte, non una dichiarazione ufficiale.

• Che si tratti del flagship a fasi. La versione a fasi "fine agosto" del nuovo flagship di iFLYTEK potrebbe essere questa — o non correlata. Il comunicato stampa non fornisce alcuna data.

• Prezzi e licenza. Non viene divulgato nulla. La famiglia Spark di iFLYTEK è stata storicamente in gran parte servita via API piuttosto che con pesi aperti, quindi se Spark3-1.7B e Spark3-4B siano checkpoint aperti o un target di servizio interno è una questione aperta.

• Ogni benchmark. I dati di throughput nella PR sono il test di serving dell'autore stesso, non una valutazione indipendente, e nessun leaderboard ha valutato il modello perché non esiste alcun modello disponibile pubblicamente.

Cosa guardare

L'organizzazione XHToken Hugging Face è il canale di rilascio da tenere d'occhio. Se il modello è reale, i suoi pesi — o almeno una scheda del modello — dovrebbero apparire lì, e il passaggio dell'organizzazione da zero a un repository pubblico è il segnale più importante. Alcune cose da verificare nel momento in cui ciò accade:

• Il numero di contesto. 1M è nativo, oppure è esteso tramite RoPE con un compromesso sulla qualità? La PR dice che è nativo; sono le model card a stabilirlo.

• L'API del budget di pensiero. Come i quattro livelli di ragionamento vengono esposti — come parametro di campionamento, campo di chat-template o variante separata del modello — determina quanto sia facile usarli davvero.

• La licenza. I pesi aperti renderebbero Spark3 il primo modello sub-5B con contesto nativo da 1M disponibile per l'auto-hosting; un lancio solo API lo renderebbe un tipo diverso di prodotto.

• Calendario degli annunci di iFLYTEK. Il flagship in fasi è promesso entro fine agosto e il lancio completo al 1024 Developer Day di ottobre. Se Spark3 fa parte di uno dei due, la descrizione ufficiale dirà ciò che il comunicato stampa lascia in sospeso.

• Se la PR viene mergiata. Il supporto a vLLM conta come segnale di qualità e come infrastruttura: il primo runtime con supporto nativo a Spark3 rende il modello eseguibile in produzione il giorno stesso in cui arrivano i pesi.

Cosa dovrebbe fare uno sviluppatore adesso

Niente. Non c'è nessun modello da chiamare, nessun peso da scaricare, nessuna chiave API da fornire — qualsiasi strumento che oggi afferma di servire Spark3 sta servendo qualcos'altro. Quello che puoi fare è decidere come lo valuterai il giorno in cui apparirà, perché questo è un modello con una promessa molto verificabile: un 1.7B o 4B che legge un milione di token e ragiona a quattro profondità è o una categoria genuinamente nuova di modelli di piccole dimensioni o una storia da scheda tecnica, e la differenza è misurabile in un pomeriggio sul tuo carico di lavoro.

È anche lì che un livello di routing dimostra il suo valore. Su OrcaRouter, un modello non è un contratto a cui ti impegni; è una voce in un catalogo a cui accedi tramite un'unica API, e i prezzi di listino dei provider vengono trasferiti senza alcun ricarico — così quando un nuovo modello appare nel catalogo di un provider, il suo prezzo reale è attivo dalla nostra parte lo stesso giorno, e provarlo non richiede una seconda integrazione né una rinegoziazione. Per un modello così poco collaudato come Spark3, lo schema sensato è lo stesso che useresti per qualsiasi fuga promettente: metterlo dietro un failover automatico nella DSL di routing, lasciare che una parte del traffico lo colpisca, e tenere un modello collaudato dall'altra parte della regola, così che una valutazione negativa, una sorpresa di licenza o un risultato deludente sul contesto lungo siano un cambio di routing piuttosto che un incidente. Una chiave, un endpoint, oltre 200 modelli — e quando Spark3-1.7B o Spark3-4B saranno effettivamente eseguibili, il pass-through e il failover si applicheranno a loro come a qualsiasi altro modello.

Il riassunto onesto è una frase, non un verdetto: una PR di framework scritta questa settimana sostiene che iFLYTEK ha due modelli piccoli con contesto nativo di un milione di token e un budget di ragionamento a quattro livelli, e nessuna prova è stata pubblicata a sostegno di tutto ciò. Tenete d'occhio l'organizzazione XHToken, tenete d'occhio la promessa di fine agosto di iFLYTEK, e quando i pesi saranno reali, metteteli attraverso una regola di routing con failover prima di scommettere un percorso di produzione su di essi. Questo è l'intero manuale per un leak: credi all'infrastruttura, verifica il modello e mantieni basso il costo di uscita.