Xing4_0 arriva su SGLang: una sesta PR, e la prima dimensione dichiarata, per il prossimo MoE di China Telecom

A due ore di distanza il 16 settembre 2026, i due stack di serving open-source dominanti hanno smesso di essere in disaccordo sul nome. vLLM ha presentato "[Model] Add Xing4_0 support" al mattino; sgl-project/sglang ha fatto seguito con "feat: add Xing4_0 model support" alle 10:38 UTC e, dopo sei settimane in cui erano in gioco tre nomi, entrambi i framework ora dicono Xing4_0. La pull request di SGLang contiene qualcosa che nessuna precedente aveva: una dimensione. Descrive il modello come Xing4.0-29B-A4B, un "MoE da 29B parametri con circa 4B parametri attivati", e fornisce un comando di avvio che indica un percorso di checkpoint, un contesto di 262.144 token e il decoding speculativo EAGLE. Questo è il MoE non ancora rilasciato di China Telecom, lo stesso attorno a cui ruotano le pull request di XingChen4 da agosto, e resta non rilasciato: i pesi non sono pubblici, il percorso di checkpoint indicato nella PR non si risolve per nessuno al di fuori del progetto, nessun fornitore ha confermato il nome o il numero, e nulla in questo articolo è verificato in modo indipendente. I fatti tratti dalle pull request sono etichettati come tali; il resto è storia e inferenza. Il modello più vicino che potete effettivamente chiamare oggi è DeepSeek V4 Flash.

Questo è un pezzo su ciò che sappiamo finora, tenuto aggiornato invece di ricominciare da capo. Copre il percorso di PR di sei settimane e come si è risolta la questione del nome, cosa aggiungono effettivamente le due pull request del 16 settembre, l'architettura che i file di configurazione ora fanno trapelare in dettaglio concreto, e cosa tenere d'occhio in seguito. La versione in una frase: il prossimo MoE di China Telecom è abbastanza reale da aver accumulato sei integrazioni di serving, una riga di tabella in vLLM contrassegnata TBA, una voce di documentazione in SGLang contrassegnata "prossimamente" e un numero di parametri dichiarato — e ancora non abbastanza reale da poter essere eseguito ovunque tu possa accedere.

Il segnale: sei integrazioni, tre nomi, sei settimane

La pista inizia prima della versione di questo articolo riportata inizialmente, e il suo log dei commit è ancora l'artefatto più rivelatore nel leak. La prima PR di vLLM è stata #51237, aperta il 6 agosto 2026 con il titolo "[WIP][Model] Aggiungi supporto per il prossimo modello XingChen4". I suoi tre commit raccontano la vicenda da soli. Il primo è intitolato "Aggiungi supporto per il modello TeleChat4". Il secondo, poco più di un'ora dopo, è "chore: revert di documentazione e voce di test premature per telechat4" — la documentazione e la voce di test del registro sono state ritirate perché premature. Il terzo, il 27 agosto, è "rinomina xingchen4". Un minuto dopo la PR è stata chiusa senza essere unita, e undici minuti dopo #54051 è stata aperta con lo stesso titolo, lo stesso ramo fork (supported_telechat4) e un unico commit squashed. Nel frattempo era stata applicata un'etichetta needs-rebase, quindi si legge come una chiusura e riapertura dopo la pulizia piuttosto che un ripensamento. Tutto è stato presentato dall'account GitHub zyp2014, con ogni commit creato e firmato da zhangyp26 <zhangyp26@chinatelecom.com.cn>.

Quella seconda PR è quella su cui questo pezzo è stato originariamente costruito, e non è più aperta. #54051 è stata chiusa dal suo stesso autore il 7 settembre 2026, senza essere stata unita. Vale comunque la pena citare la sua descrizione, perché è la frase che è sopravvissuta a ogni rinomina e a ogni riapertura:

I pesi del modello non sono ancora pubblici su Hugging Face Hub. Questa PR è aperta per una revisione anticipata del codice. Una volta rilasciati i pesi, aggiungerò una voce di test in tests/models/registry.py, aggiornerò docs/models/supported_models.md e segnerò la PR come pronta per la revisione.

Quella frase è la forma dell'intera storia: il codice è avanti rispetto ai pesi. Lo screenshot qui sotto è la pagina #54051 così com'era il 27 agosto 2026, il giorno in cui è stata aperta — un'istantanea datata, conservata perché la pull request che mostra è stata chiusa nel frattempo. Leggilo come testimonianza del segnale in quel momento, non del suo stato attuale.

Poi, il 16 settembre, lo schema si è ripetuto — due volte in un solo giorno. #57135, "[Model] Add Xing4_0 support," è stato aperto quella mattina dallo stesso account, zyp2014, con un singolo commit ora attribuito a un altro ingegnere di China Telecom — xiongji <xiongj9@chinatelecom.cn>. Undici file modificati, circa 1.300 inserimenti, un nuovo nome ovunque, e la stessa avvertenza nello stesso punto: "I pesi del modello non sono ancora pubblici su Hugging Face Hub."

Due ore e venti minuti dopo, l'altro stack di serving non era più indietro di una rinomina. sgl-project/sglang #39793, "feat: add Xing4_0 model support", aperta da un ramo chiamato support_xing4_0, e il suo unico commit porta lo stesso indirizzo xiongji della rinomina vLLM. Quattordici file e circa 1.400 inserimenti, di cui poco più di mille sono un singolo file di modello. È la sesta integrazione presentata per questo modello in sei settimane, e la prima presentata non come bozza: GitHub la elenca come aperta e pronta per la revisione, con dieci revisori richiesti — e tutte e tre le sue esecuzioni CI già rosse.

Il lato SGLang, prima di oggi, funzionava come quello di vLLM. #33982, "feat(model): aggiunto supporto al modello TeleChat4", è stato aperto il 7 agosto 2026 dal contributore PaddyXj e chiuso senza essere unito il 31 agosto — lo stesso giorno in cui #37228, "feat: aggiunto supporto al modello XingChen4", è stato aperto al suo posto. Quella pull request è ancora aperta come bozza a nome di PaddyXj, su un branch chiamato support_xingchen4, con tre commit e l'ultima modifica risalente all'8 settembre. La sua checklist è la cosa più interessante in entrambi i framework: la voce "il modello si carica e genera in locale, su pesi interni" è spuntata, la chiamata agli strumenti è spuntata, il parsing del ragionamento è spuntato — e la CI pubblica no, perché è "bloccata dal rilascio dei pesi". Qualcuno ha un checkpoint. Nessuno l'ha pubblicato. E a differenza di vLLM, dove ogni nuova ripresentazione chiudeva prima il suo predecessore, SGLang ora ha due pull request attualmente aperte per lo stesso modello, con due nomi diversi.

Ciò a cui equivalgono sei integrazioni in sei settimane non è una versione più forte dello stesso segnale; è un segnale diverso. Sei integrazioni sarebbero coerenti con un team che itera. Sei integrazioni sotto tre nomi — TeleChat4, XingChen4, Xing4_0 — sono un team che itera sul nome sotto cui il modello sarà rilasciato, in pubblico, mentre i pesi restano privati. Questa è un'inferenza non verificata, ed è la cosa più densa di conseguenze che la traccia delle PR ora mostra.

Cosa aggiungono davvero i due PR di settembre

La pull request di vLLM è una rinomina del lavoro di agosto più che una sua riscrittura. Il file del modello ora è vllm/model_executor/models/xing4_0.py, la classe è Xing4_0ForCausalLM, e il model_type xing4_0 è mappato su DeepseekV3Config — la stessa configurazione DeepSeek-V3 usata dalla versione XingChen4. Cosa contiene:

• Un'implementazione completa del modello in vllm/model_executor/models/xing4_0.py — classe Xing4_0ForCausalLM, con forward pass, un adattatore mHC e un'implementazione tensor-parallel di load_weights(). Il messaggio di commit nota che sono supportate sia le varianti DSA sia quelle non-DSA, riutilizzando le operazioni condivise mhc_pre / mhc_post.

• Registrazione di Xing4_0ForCausalLM in vllm/model_executor/models/registry.py, così che vLLM riconosca l'architettura per nome.

• Un parser di reasoning (vllm/reasoning/xing4_0_reasoning_parser.py) "per varianti capaci di reasoning," e un parser di strumenti (vllm/tool_parsers/xing4_0_tool_parser.py) per la chiamata automatica degli strumenti.

• Registrazione in vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py e vllm/transformers_utils/config.py — con il messaggio di commit che dichiara che un head MTP compatibile con Deep​Seek-V3 è abilitato per la decodifica speculativa.

• Due file di documentazione — la parte realmente nuova e un'inversione diretta rispetto ad agosto. Il commit originale includeva una voce di documentazione e test che è stata annullata un'ora dopo in quanto prematura; la PR di settembre reintroduce la documentazione ed è etichettata come documentazione, nuovo modello e tool-calling.

Le voci della documentazione di vLLM sono il punto in cui un lettore ha appreso per la prima volta qualcosa di concreto. In docs/models/supported_models.md, la nuova riga recita `Xing4_0ForCausalLM` | Xing4_0 | TBA — la colonna del checkpoint dice letteralmente TBA, che è lo stesso "non ancora" in un carattere diverso. E in docs/features/tool_calling.md, sotto l'intestazione "Xing4_0 Models (xing4_0)", la PR documenta il formato di chiamata agli strumenti del modello: le chiamate vengono emesse all'interno di blocchi <tool_call>...</tool_call>, come JSON ({"name": ..., "arguments": {...}}) o come una forma basata su tag che utilizza <param_key>...</param_key> e <param_value>...</param_value>. Questo è un livello di specificità che le PR precedenti non hanno raggiunto — un dettaglio implementativo del formato di chat del modello, scritto nella documentazione pubblica di un framework importante, per un checkpoint che nessuno può scaricare.

La PR di SGLang è più interessante, perché include un'implementazione e una configurazione anziché una voce di registro più della documentazione. La sua riga di documentazione è la prima volta che un framework inserisce il nome del fornitore nella propria documentazione. In docs/docs/supported-models/generative_models.mdx, la nuova riga elenca Xing4_0, con la colonna del checkpoint che riporta `Xing4_0` (prossimamente) e una descrizione: "Il modello MoE di China Telecom con attenzione MLA e flussi residui mHC (Manifold-constrained Hyper-Connection); supporta il decoding speculativo MTP nativo, il tool calling e il reasoning." La riga di vLLM diceva TBA e non nominava alcun fornitore; quella di SGLang nomina China Telecom e dice prossimamente. Nessuna delle due è una data di rilascio, e una riga nella documentazione di un framework non è un prodotto.

La descrizione della PR aggiunge il numero che mancava a ogni versione precedente di questa storia. "Questa PR aggiunge il supporto per Xing4.0-29B-A4B (MoE da 29B parametri con ~4B parametri attivati)." Fornisce anche un comando di avvio — --model-path XingChen-AGI/Xing4.0-29B-A4B --trust-remote-code --tp-size 2 --context-length 262144 --reasoning-parser xing4_0 --tool-call-parser xing4_0 --speculative-algorithm EAGLE — e afferma che la configurazione è stata verificata con parallelismo tensoriale 2, un contesto di 262.144 token e decodifica speculativa EAGLE MTP, con trascrizioni di una risposta di ragionamento e una chiamata allo strumento get_weather incollate nella descrizione come prova. I pesi alla base di quella verifica sono dell'autore stesso: il percorso del repository che la PR nomina non è accessibile pubblicamente, e l'organizzazione Hugging Face a cui punta non elenca alcun modello pubblico. Considera la dimensione, la lunghezza del contesto e le trascrizioni come affermazioni riportate dalla PR collegate a un checkpoint privato, non come misurazioni che chiunque può ripetere. Tutto ciò è secondo quanto riportato nella pull request e non riprodotto.

La comparsa dei parser di reasoning e di tool sotto entrambi i nomi è importante per la stessa ragione per cui lo era in agosto. Un parser di reasoning esiste per rimuovere i marcatori di pensiero dall'output di un modello — la catena di pensiero interna che un modello emette prima della sua risposta finale. Un parser progettato appositamente per questo modello significa che ci si aspetta che la famiglia abbia varianti capaci di reasoning, allo stesso modo in cui TeleChat3 ha distribuito edizioni Thinking. Il parser di tool, insieme al formato di chiamata ora documentato, significa che ci si aspetta anche il function calling nativo. Nessuno dei due è una garanzia sul prodotto finale; entrambi sono gli indizi più forti che le PR contengono su ciò a cui punta China Telecom.

Quello che sappiamo finora, in sintesi

Il tabellone riportato di seguito è quello compilato per questo articolo il 27 agosto 2026, dalla PR di vLLM così come si presentava allora. È conservato qui deliberatamente come istantanea datata anziché ridisegnato, perché ogni sua riga è ancora vera tre settimane dopo — non rilasciato, pesi non pubblici, backbone DeepSeek, residuo mHC, entrambi i parser inclusi. Ciò che è cambiato non è un valore sulla scheda, ma tutto ciò che la circonda: la PR di vLLM che cita è stata chiusa il 7 settembre, il lavoro è riapparso con un nuovo nome il 16 settembre, SGLang ha seguito la rinomina poche ore dopo e con essa è arrivato il primo conteggio dei parametri dichiarato. Nulla sulla scheda è sbagliato. È semplicemente vecchia di tre settimane, e la storia è andata oltre. Le cifre di FlagGems nella sua ultima riga sono passate invariate nella nuova PR di vLLM, ancora riportate dalla PR e ancora non riprodotte.

L'architettura che le PR fanno trapelare.

Rinominare un file non rinomina un'architettura, e il testo di riepilogo nella PR vLLM di settembre è il testo di agosto con Xing4_0 sostituito a XingChen4 — clausola per clausola. Due frasi portano il segnale:

• "Xing4_0 riutilizza il backbone di DeepSeek-V2/V3 (attenzione MLA, blocco MoE, indicizzatore DSA opzionale)."

Sostituisce la connessione residua standard con Iper-connessioni vincolate alla varietà (mHC): il flusso residuo viene espanso in num_residual_streams flussi paralleli miscelati da matrici doppiamente stocastiche dipendenti dall'input, prodotte tramite proiezione di Sinkhorn-Knopp.

Ogni clausola corrisponde a qualcosa di concreto. MLA sta per Multi-head Latent Attention, lo schema di attenzione compressa che Deep​Seek ha introdotto nella V2 e che permette alla KV cache di rimanere piccola; MoE è il routing mixture-of-experts, che mantiene un numero elevato di parametri con un'impronta attiva ridotta. L'indexer DSA opzionale è il meccanismo Deep​Seek Sparse Attention della linea V3.2 — un modulo di scoring leggero che seleziona i top-k token a cui prestare attenzione, riducendo il costo dell'attenzione da quadratico a circa lineare nella lunghezza del contesto. E la frase su mHC è il titolo di punta: questo modello adotta l'architettura residuale che Deep​Seek stessa ha introdotto solo in questa generazione.

La PR di SGLang è la prima a pubblicare la forma della cosa invece di descriverla. Il suo file di configurazione, python/sglang/srt/configs/xing4_0.py, dichiara 40 strati nascosti, una dimensione nascosta di 3.584 e un vocabolario di 131.072 token; MLA con un rango LoRA KV di 512 e un rango LoRA di query di 768 su 32 teste; e un MoE sparso con 64 esperti instradati più un esperto condiviso, instradamento top-4, punteggio sigmoide, un fattore di scala degli instradati di 2,0 e selezione degli esperti noaux_tc. Anche i campi mHC sono espliciti: hc_mult 4, venti iterazioni di Sinkhorn-Knopp, un clamp di h_res a più o meno 30, e un rope_theta di 10.000 con un position embedding massimo di 262.144. Questi sono i valori predefiniti in un'integrazione che non è stata rilasciata, secondo la pull request — un file di configurazione è una dichiarazione di intenti, non una model card, e la cifra 29B-A4B nella descrizione della PR non è derivata da essi in alcuna fonte pubblica.

Un campo vale più di tutti gli altri, perché è il primo punto in cui questo modello smette visibilmente di essere una copia di Deep​Seek. La configurazione SGLang imposta hc_contract_for_draft, che riunisce i flussi mHC riportandoli alla dimensione nascosta propria del modello prima della norm finale e alimentaquel tensore contratto alla testa di draft Eagle. DeepSeek V4 alimenta invece il tensore mHC appiattito n-times-hidden_size. Il commento nella configurazione lo dice esplicitamente, ed è il tipo di dettaglio che salta fuori solo quando un'implementazione è stata modellata su un checkpoint reale — cosa che la checklist della precedente PR di SGLang sostiene di avere, senza pubblicarla.

La matematica mHC è dove i due stack divergono nell'implementazione e concordano nel presupposto. La PR di vLLM osserva che "corrisponde alle operazioni condivise in vllm.model_executor.layers.mhc, quindi non vengono introdotti kernel privati" — quel modulo esiste perché vLLM supporta già mHC per DeepSeek V4, quindi il costo incrementale di aggiungere questo modello è piccolo. SGLang raggiunge lo stesso punto per una strada diversa: il suo modulo mHC utilizza kernel TileLang fusi registrati come ops personalizzate di torch, e la PR estende il kernel mhc_pre split-K esistente per accettare hc_hidden_size 14.336 accanto alle due dimensioni che già gestiva. Inoltre disattiva il percorso tf32_hc_prenorm_gemm di DeepGEMM per questa architettura, perché quel percorso è un'estensione C grezza che torch.compile non può tracciare; mHC ricade invece sul kernel TileLang. Il vantaggio pratico è lo stesso in entrambi i framework: se oggi servi DeepSeek V4 su vLLM o SGLang, il meccanismo che servirà il prossimo MoE di China Telecom è già installato.

mHC, il trucco di Deep​Seek al centro di tutto

Vale la pena approfondire Manifold-constrained Hyper-Connections, perché è la cosa più interessante in assoluto di questo modello — e non è un'invenzione di China Telecom. È di Deep​Seek.

La storia inizia con Hyper-Connections, proposte dal team Kimi nel 2024. Un Transformer standard mantiene un flusso residuo per livello: l'input viene aggiunto all'output del livello, offrendo ai gradienti un percorso pulito e permettendo alla rete di apprendere una correzione residua. Hyper-Connections sostituisce quel singolo flusso con diversi flussi paralleli che vengono mescolati da matrici apprese a ogni livello, offrendo al modello un percorso molto più ricco lungo cui le informazioni possono viaggiare. Il problema è la stabilità: matrici di mescolamento non vincolate rompono la proprietà di mappatura identitaria che rende addestrabili le connessioni residue, e su scala di mille miliardi di parametri la perdita di addestramento diventa instabile.

Il contributo di DeepSeek, pubblicato come paper mHC nel dicembre 2025 e poi utilizzato in DeepSeek V4, è stato quello di vincolare le matrici di miscelazione a essere doppiamente stocastiche — non negative, con righe e colonne che sommano ciascuna a uno — imposto dalla proiezione di Sinkhorn-Knopp durante l'addestramento. Una matrice doppiamente stocastica ha un raggio spettrale esattamente pari a uno, quindi i segnali non possono essere amplificati o attenuati esponenzialmente mentre attraversano centinaia di strati. Questo limite è ciò che mantiene stabile l'addestramento su larga scala, e la proiezione è abbastanza economica che DeepSeek ha riportato solo circa il 6,7% di sovraccarico di addestramento con quattro flussi residui. DeepSeek V4, rilasciato il 24 aprile 2026, è l'uso di punta di questa tecnologia, con un guadagno riportato di circa il 15% su compiti di ragionamento matematico e un contesto di 1M token in aggiunta.

Quindi, in parole semplici, ciò che dicono queste PR è: il prossimo modello di China Telecom prende il backbone collaudato di DeepSeek e il meccanismo residuale più recente di DeepSeek, invece di inventare da zero l'uno o l'altro. È una scelta pragmatica, e porta con sé una sottile conferma: il secondo grande laboratorio dopo DeepSeek stesso ad adottare mHC ritiene che il trucco sia pronto per la produzione.

Le PR non hanno ancora finito con mHC, e i punti aperti lo ammettono onestamente. Nelle PR di vLLM, l'autore osserva che i bias del checkpoint (bias_pre, bias_post, bias_res) e un clamp di h_res sono attualmente integrati o omessi, e che la conferma da parte dei revisori dell'equivalenza delle formule è «la principale questione di correttezza». C'è anche un'operazione di trasposizione personalizzata che mantiene un tensore C-contiguo per un kernel TileLang — rinominata insieme a tutto il resto, da _xingchen4_transpose_contiguous a _xing4_0_transpose_contiguous — e una limitazione rigida: il parallelismo pipeline non è supportato in modalità mHC quando num_residual_streams è maggiore di uno, mentre il parallelismo tensoriale è supportato. Niente di tutto ciò è sorprendente per una bozza, ma è lo stesso punto incompiuto di agosto, il che è di per sé informativo: sei settimane di rinominazioni non hanno spostato la questione della correttezza, e le tre esecuzioni CI rosse sulla PR più recente di SGLang sono la stessa storia in un colore diverso. Ciò che la configurazione di SGLang riesce a stabilire è il numero di stream. Con hc_mult impostato a 4 e una dimensione nascosta di 3.584, il 14.336 nella patch del kernel corrisponde esattamente a quattro stream — e il commento del kernel lo dice a chiare lettere. Quella lettura era un'inferenza da un semplice numero quando questo articolo è uscito per la prima volta; ora è scritta in un file di configurazione.

L'angolo di accelerazione: FlagGems, ancora.

Un secondo filo lega questo modello alla relazione già esistente di China Telecom con la Beijing Academy of Artificial Intelligence, ed è l'unico filo sopravvissuto intatto a ogni ridenominazione. La PR di vLLM abilita l'accelerazione opzionale FlagOS/FlagGems dietro un flag di ambiente USE_FLAGOS, disabilitato per impostazione predefinita, sostituendo i kernel del percorso caldo per MoE, attention, softmax e top-k. Il vantaggio dichiarato, dal benchmark H100 dell'autore della PR su un carico di lavoro con prompt lunghi e alta concorrenza (oltre 10K token di input, concorrenza 10): fino al 19,87% in meno di tempo al primo token e fino al 26,32% in meno di tempo per token di output, con altri carichi di lavoro neutri. Questi numeri sono riportati dalla PR e non riprodotti, e arrivano con il flag disattivato per impostazione predefinita.

Ciò che vale la pena registrare è quanto poco la rinomina abbia toccato. La PR vLLM di settembre riporta le stesse cifre, la stessa nota di ambito ristretto secondo cui il flag esiste solo all'interno del file del modello, e la stessa istruzione di installare flagtree e flag-gems. I numeri non sono cambiati perché il codice non è cambiato; è cambiata solo l'etichetta. Le pull request di SGLang non contengono alcun thread FlagGems — seguono invece la via TileLang e DeepGEMM — il che rende questa una discussione su chi possiede l'ottimizzazione del livello di serving, non sul modello.

Questa è una storia di continuità. Ad aprile 2026, TeleChat3-36B-Thinking era il primo grande modello portato in modo indipendente su FlagOS, lo stack software AI open source di BAAI. Qualunque sia la veste con cui questo modello verrà distribuito, proseguire quel filo — con i kernel FlagGems all’interno della sua integrazione vLLM — indica che la strategia di stack domestico del laboratorio si estende al livello di serving, non solo all’addestramento.

La questione della denominazione, e la famiglia da cui proviene

Fino al 16 settembre la questione del nome era una nota marginale. Ora è quasi chiusa, e le prove sono ancora tutte in nomi di branch e stringhe residue piuttosto che in dichiarazioni — ma i due framework sono giunti alla stessa risposta dalla stessa direzione.

• I messaggi di commit, in ordine: "Aggiungi supporto al modello TeleChat4", poi "chore: annulla documentazione e voce di test premature per telechat4", poi — tre settimane dopo e un minuto prima che la PR fosse chiusa — "rinomina xingchen4". Un commit il cui intero scopo era la rinomina.

• Il fork si dirama. Le prime due PR di vLLM, #51237 e #54051, sono state create a partire da zyp2014:supported_telechat4. La terza, #57135, è zyp2014:support_xing4_0. Il ramo è stato rinominato nello stesso passaggio che ha rinominato il modello — e il lato SGLang ha ora percorso lo stesso identico cammino in tre passi, da support_telechat4 passando per support_xingchen4 fino a support_xing4_0.

• Il testo del corpo di #51237, che diceva che l'accelerazione FlagGems era "per TeleChat4" mentre lo stesso identico paragrafo chiamava il modello XingChen4. I due nomi erano già in collisione nel riepilogo dello stesso autore del 6 agosto.

• La rinomina file per file su entrambi i lati. In vLLM è stato xingchen4.py in xing4_0.py e XingChen4ForCausalLM in Xing4_0ForCausalLM; in SGLang è xingchen4.py in xing4_0.py e XingChen4Config in Xing4_0Config, su un branch che ha cambiato nome insieme a essa. Nessuna delle due PR ha lasciato il vecchio nome da nessuna parte nel proprio diff.

Dunque tre nomi sono entrati in gioco in due framework, e lo schema è coerente con un unico modello che viene ribattezzato mentre si avvicina a quello che sarà il suo nome pubblico. "Xing4_0" si legge naturalmente come Xingchen 4.0 — la famiglia del modello è marchiata 星辰 (Xingchen) in cinese — ma si tratta comunque di un'inferenza dalla stringa, non di qualcosa che un comunicato stampa affermi apertamente. Potrebbe altrettanto essere che TeleChat4 e XingChen4 siano fratelli della stessa generazione anziché un unico modello sotto due nomi, sebbene il fork condiviso, il paragrafo sull'architettura condiviso, i numeri FlagGems condivisi, gli elementi aperti condivisi e ora una rinomina condivisa rendano più difficile sostenerlo. Nessuno ha confermato la relazione e China Telecom non ha commentato. Ciò che è cambiato è che la rinomina non è più una scelta di un singolo contributore: due progetti di serving indipendenti, mantenuti da persone diverse, hanno entrambi rietichettato la propria integrazione con lo stesso terzo nome a distanza di un giorno l'uno dall'altro.

Vale la pena tenere d'occhio la famiglia stessa, perché spiega il pragmatismo. Le release pubbliche finora sono state marchiate TeleChat:

TeleChat-7B e TeleChat-12B, resi open source a gennaio 2024 con un corpus di 1 trilione di token.

• TeleChat2-115B (settembre 2024), presentato come il primo modello aperto da mille miliardi di parametri interamente nazionale, oltre ai fratelli 35B, 7B e 3B.

• TeleChat2-39B-A12B (marzo 2025), il primo MoE della famiglia.

• TeleChat3-105B-A4.7-Thinking (dicembre 2025), un MoE a grana fine con 105B di parametri totali e 4,7B attivi, addestrato su 15 trilioni di token, insieme al denso TeleChat3-36B e al successivo TeleChat3-Coder-36B-Thinking.

Se il dato 29B-A4B regge, questo modello si collocherebbe sotto TeleChat3-105B-A4.7-Thinking sia per i parametri totali sia per quelli attivi — un fratello minore, più economico, anziché un modello di punta sostitutivo. Questa è un'interpretazione, non un fatto; nulla in nessuno dei due comunicati stampa dice a quale fascia sia destinato il modello. Il marchio Xingchen è dove l'azienda concentra i suoi sforzi nell'IA: lo Xingchen AGI Lab è stato formalmente istituito a Pechino nel marzo 2026, basandosi sulla stessa famiglia di modelli, e China Telecom descrive il suo sistema "三全" (omnimodale, di tutte le dimensioni, completamente nazionale) come esteso a modelli semantici, vocali, visivi e multimodali da 1B a oltre 1T di parametri. Un cambio di nome da TeleChat a Xingchen è esattamente ciò che fa un laboratorio quando vuole che la famiglia di modelli porti il marchio del laboratorio anziché il marchio della linea di prodotto.

Quello che ancora non sappiamo

Per un modello così precoce, la lista onesta è ancora più lunga di quella nota, anche se questa settimana si è ridotta in due punti:

• Nessuna data di rilascio. Cinque delle sei integrazioni sono bozze aperte per una prima revisione del codice, proprio perché i pesi non sono pubblici. La sesta, SGLang #39793, è aperta per la revisione anziché essere una bozza — ma non è stata unita, tutte e tre le sue esecuzioni CI stanno fallendo e necessita che un revisore la approvi. Non è stato annunciato alcun calendario.

• Un conteggio dei parametri, ma solo uno dichiarato. Ogni versione precedente di questo pezzo elencava la configurazione MoE come non divulgata. Il PR di SGLang cambia ciò sulla carta: Xing4.0-29B-A4B, 29B totali, circa 4B attivi. La cifra proviene da una pull request, non è allegata ad alcun checkpoint pubblico, non è corroborata da alcun file di configurazione e non è stata riprodotta da nessuno al di fuori del progetto. Trattala come un'intenzione dichiarata, non come una specifica.

• Nessun numero di benchmark, riportato dal fornitore o in altro modo, e nessun punteggio indipendente. Le trascrizioni di verifica nella PR di SGLang mostrano il modello che risponde a un prompt di ragionamento ed emette una chiamata a uno strumento ben formata; non mostrano nulla su quanto bene se la cavi in nessuno dei due casi.

• Nessun prezzo e nessuna licenza confermata. Ogni precedente versione di TeleChat è Apache-2.0, il che è incoraggiante, ma per questa non è stata dichiarata alcuna licenza.

• Nessun peso pubblico — confermato anziché presunto. Al 16 settembre 2026, il percorso Hugging Face indicato dalla PR di SGLang non è pubblicamente leggibile e l'organizzazione a cui punta non elenca alcun modello pubblico; la voce pubblica più recente della famiglia è TeleChat3-Coder-36B-Thinking di gennaio. La tabella dei modelli supportati di vLLM riporta TBA nella colonna del checkpoint, quella di SGLang dice "prossimamente", ed entrambe le PR di SGLang hanno una CI pubblica che fallisce.

• Nessuna dichiarazione ufficiale da China Telecom — nessun annuncio, nessun peso, nessuna conferma del nome o della dimensione. Nota attentamente l'asimmetria: la riga della documentazione di SGLang attribuisce il modello a China Telecom, ma quella è la descrizione di un contributore all'interno di una pull request, non una dichiarazione aziendale, e la descrizione della PR più recente elimina completamente il nome del fornitore. Sei integrazioni in costruzione per questo modello sono la prova più forte finora che sia reale, ma le integrazioni vengono chiuse e i nomi in codice cambiano; due lo sono già state. Nulla è confermato finché il laboratorio non lo dice.

La lettura corretta di tutto questo non è lo scetticismo nei confronti del modello; è un quadro accurato di un segnale precoce. Ciò che esiste oggi è un vero artefatto ingegneristico — sei di essi, distribuiti su due framework — con un’architettura reale e, per la prima volta, una forma dichiarata annessa. Ciò che non esiste ancora è qualcosa che si possa scaricare, chiamare o sottoporre a benchmark.

La cosa più vicina che puoi eseguire oggi

Questo modello non è servibile da nessuna parte — né tramite un'API, né in locale, perché i pesi non sono pubblici. Il modello più vicino che un lettore può effettivamente chiamare oggi e che ne condivide il DNA architetturale è DeepSeek V4 Flash, che usa lo stesso schema residuo mHC sopra MLA e MoE, ed è l'implementazione di riferimento per cui sono stati costruiti i moduli mHC condivisi in entrambi i framework. La pagina del modello di OrcaRouter per deepseek/deepseek-v4-flash elenca un contesto di 1M token, un output massimo di 384K e un prezzo di listino di $0,15 per milione di token di input e $0,29 per milione di output — le stesse cifre pubblicate da DeepSeek stessa, riportate con 0% di ricarico, quindi una variazione di prezzo del fornitore si riflette qui lo stesso giorno. Una chiave API copre il catalogo, il che rende il confronto con il resto del tier di reasoning una regola di routing anziché una nuova integrazione.

Questa è anche la risposta pratica a "come faccio a provare questo modello quando sarà rilasciato". Un checkpoint nuovo di zecca e non collaudato è esattamente il caso in cui il failover automatico si ripaga: instrada una frazione di traffico verso di esso, mantieni un modello collaudato come fallback e lascia che sia il livello di routing a prendere la decisione, invece di scommettere un percorso di produzione sul comportamento del primo giorno. Un MoE da 29B con circa 4B parametri attivi, se è questo che arriverà, è una cosa economica da instradare rispetto a un modello di frontiera proprio perché se ne attiva così poco per token. Se il nome cambierà ancora tra ora e il rilascio — e le ultime sei settimane suggeriscono che potrebbe — la regola di routing è quella che riscrivi, non l'integrazione.

Domande frequenti

Perché la PR di vLLM è stata chiusa?

Vediamo la chiusura, non il motivo. La #54051 è stata chiusa dal suo stesso autore il 7 settembre 2026 senza essere stata unita, e il lavoro è ricomparso nove giorni dopo come #57135 con un nuovo nome. Una precedente PR di vLLM, la #51237, è stata chiusa e ripresentata lo stesso giorno con lo stesso titolo, quindi chiudere e ripresentare è la consuetudine di questo autore più che un segnale di problemi — ma i testi delle PR non indicano un motivo e non abbiamo intenzione di inventarne uno.

Quando sarà rilasciato Xing4_0?

Non c'è una data. Cinque delle sei integrazioni sono bozze aperte per una revisione del codice preliminare, e i piani degli stessi autori sono di aggiungere voci di test, aggiornare la documentazione e contrassegnare le PR come pronte solo una volta che i pesi saranno rilasciati. La vecchia checklist di SGLang è la dichiarazione più chiara della situazione attuale: "Il modello si carica e genera (localmente, su pesi interni)" è spuntato, e la CI pubblica è "bloccata dal rilascio dei pesi". La PR più recente di SGLang è presentata come pronta per la revisione anziché come bozza, il che è un cambiamento di atteggiamento piuttosto che di stato — non è ancora unita, la sua CI è rossa, e una riga della documentazione che dice "prossimamente" non è un lancio.

Xing4_0 è lo stesso modello di XingChen4?

Quasi certamente sì, e le PR rendono facile verificarlo: stessa discendenza del fork, stesso paragrafo sull'architettura, stesse cifre di benchmark di FlagGems, stessi punti aperti e una rinomina file per file in entrambi i framework — da xingchen4.py a xing4_0.py, inclusa la classe di configurazione, su branch rinominati di conseguenza. È lo stesso lavoro che indossa un nuovo nome, e al 16 settembre sia vLLM sia SGLang hanno adottato quel nome. Ciò che nessuna PR dichiara è quale nome porterà un checkpoint rilasciato.

Questo è un modello Deep​Seek?

No. È il modello di China Telecom, dello Xingchen AGI Lab. Il legame con Deep​Seek è architetturale: riutilizza il backbone Deep​Seek-V2/V3 e lo schema residuo mHC che Deep​Seek ha proposto e rilasciato nella V4. Adottare l'architettura di qualcun altro non significa che i due progetti siano collegati.

Cosa guardare dopo

Le PR forniscono ancora una checklist concreta, e la coppia del 16 settembre vi ha aggiunto due voci. Primo, i pesi: ogni autore ha detto che il proprio lavoro attende su Hugging Face, quindi la comparsa di un repository pubblico è l'evento portante — e la PR di SGLang ora fornisce il percorso esatto da tenere d'occhio, XingChen-AGI/Xing4.0-29B-A4B, che al momento non risolve per nessuno. Secondo, le PR stesse: quella di vLLM ha bisogno che le formule del bias mHC siano confermate, che la voce di test del registry sia aggiunta e che la sua CI sia verde; la #39793 di SGLang ha bisogno che le sue tre esecuzioni rosse siano sistemate e che i dieci revisori richiesti diano l'approvazione, mentre la più vecchia #37228 necessita ancora della sua voce di test, del suo benchmark di accelerazione MTP e di una CI sbloccata. Terzo, e novità di questa settimana: se SGLang chiude #37228 a favore di #39793, come vLLM ha sempre chiuso una PR precedente prima di ripresentarne una. Due integrazioni attive per un unico modello non ancora rilasciato sono una condizione che nessuno mantiene a lungo, e quale sopravvive dice qualcosa su quanto ci si sia davvero vicini. Quarto, i numeri: se un checkpoint rilasciato corrisponde alla forma 29B-A4B, al MoE a 64 esperti e al contesto di 262.144 token che la configurazione e la descrizione della PR ora dichiarano. Quinto, se la terza PR di vLLM sopravvive più a lungo delle sue due precedenti, durate rispettivamente 21 e 11 giorni prima di essere chiuse senza merge. E tenete d'occhio se i parser di reasoning descrivono una variante Thinking separata, come TeleChat3 ne ha rilasciata una.

Finché non accade una di queste cose, considera questo modello per quello che è: un piano ben specificato di un laboratorio serio, colto sul fatto mentre prepara la sua infrastruttura di serving — ora in entrambi i principali stack di serving open source, sotto un nome che entrambi hanno adottato e una dimensione che solo la sua pull request indica. Solo l'architettura lo rende qualcosa che vale la pena monitorare: è la seconda grande adozione di mHC dopo DeepSeek stesso, da parte di un laboratorio la cui generazione precedente era già un MoE a grana fine addestrato su chip nazionali. Quando i pesi saranno rilasciati, non ci sarà alcun dubbio se girerà in vLLM o SGLang. Entrambi gli stack hanno scritto il codice tre volte, sotto tre nomi diversi.