Xing4_0 når SGLang: En sjätte PR, och den första angivna storleken, för China Telecoms nästa MoE

Med två timmars mellanrum den 16 september 2026 slutade de två dominerande serveringsstackarna med öppen källkod att vara oense om namnet. vLLM lämnade in "[Model] Add Xing4_0 support" på morgonen; sgl-project/sglang följde efter med "feat: add Xing4_0 model support" kl. 10:38 UTC, och efter sex veckor med tre namn i spel säger båda ramverken nu Xing4_0. SGLang-pullbegäran innehåller något som ingen tidigare hade: en storlek. Den beskriver modellen som Xing4.0-29B-A4B, en "MoE med 29B parametrar och ~4B aktiverade parametrar", och anger ett startkommando som namnger en kontrollpunktssökväg, en kontext på 262 144 token och EAGLE-spekulativ avkodning. Detta är China Telecoms ännu inte släppta MoE, samma som XingChen4-pullbegärandena har kretsat kring sedan augusti, och den är fortfarande inte släppt: vikterna är inte offentliga, kontrollpunktssökvägen som PR:en anger är inte nåbar för någon utanför projektet, ingen leverantör har bekräftat namnet eller siffran, och inget i den här artikeln är oberoende verifierat. Fakta som hämtats från pullbegäranden är märkta som sådana; resten är historia och slutledning. Den närmaste modellen du faktiskt kan anropa idag är DeepSeek V4 Flash.

Det här är en artikel om vad vi vet så här långt, som hålls uppdaterad i stället för att börja om från början. Den täcker den sex veckor långa PR-kedjan och hur namnfrågan löstes, vad de två pull-requests från den 16 september faktiskt tillför, arkitekturen som konfigurationsfilerna nu läcker i verklig detalj, och vad man bör hålla utkik efter härnäst. Enmeningsversionen: China Telecoms nästa MoE är verklig nog att ha samlat sex serving-integrationer, en tabellrad i vLLM märkt TBA, en dokumentationspost i SGLang märkt "kommer snart" och ett angivet parameterantal – och fortfarande inte verklig nog att köras någonstans du kan komma åt.

Signalen: sex integrationer, tre namn, sex veckor

Spåret börjar tidigare än den version av den här artikeln som först rapporterades, och dess commit-logg är fortfarande den mest avslöjande artefakten i läckan. Den första vLLM-PR:en var #51237, öppnad den 6 augusti 2026 med titeln "[WIP][Model] Add upcoming XingChen4 model support." Dess tre commits berättar historien på egen hand. Den första har titeln "Add TeleChat4 model support." Den andra, drygt en timme senare, är "chore: revert premature docs and test entry for telechat4" — dokumentationen och registrets testpost drogs tillbaka som för tidiga. Den tredje, den 27 augusti, är "rename xingchen4." En minut senare stängdes PR:en utan att ha mergats, och elva minuter efter det #54051 öppnades med samma titel, samma fork-gren (supported_telechat4) och en enda squashad commit. En needs-rebase-etikett hade satts på under tiden, så det här framstår som en stängning och återöppning efter städning snarare än en sinnesändring. Allt lämnades in från GitHub-kontot zyp2014, och varje commit författades och signerades av zhangyp26 <zhangyp26@chinatelecom.com.cn>.

Den där andra PR:en är den som den här artikeln ursprungligen byggdes kring, och den är inte längre öppen. #54051 stängdes av sin egen upphovsman den 7 september 2026, utan att ha mergats. Beskrivningen är ändå värd att citera, eftersom det är meningen som har överlevt varje namnbyte och varje återöppning:

Modellvikterna är ännu inte offentliga på Hugging Face Hub. Denna PR är öppen för tidig kodgranskning. När vikterna har släppts kommer jag att lägga till en testpost i tests/models/registry.py, uppdatera docs/models/supported_models.md och markera PR:n som redo för granskning.

Den meningen är formen på hela berättelsen: koden ligger före vikterna. Skärmbilden nedan är #54051-sidan som den såg ut den 27 augusti 2026, dagen då den öppnades – en daterad ögonblicksbild, bevarad eftersom pull requesten den visar sedan dess har stängts. Läs den som ett dokument över signalen vid det tillfället, inte över dess status nu.

Sedan, den 16 september, upprepades mönstret – två gånger på en dag. #57135, "[Model] Add Xing4_0 support," öppnades den morgonen från samma konto, zyp2014, med en enda commit som nu var författad av en annan ingenjör på China Telecom – xiongji <xiongj9@chinatelecom.cn>. Elva filer ändrades, ungefär 1 300 infogningar, ett nytt namn genomgående, och samma förbehåll på samma plats: "Modellvikterna är ännu inte offentliga på Hugging Face Hub."

Två timmar och tjugo minuter senare slutade den andra serving-stacken att ligga en namnändring efter. sgl-project/sglang #39793, "feat: lägg till stöd för Xing4_0-modellen," öppnades från en gren som heter support_xing4_0, och dess enda commit bär samma xiongji-adress som vLLM-namnändringen. Fjorton filer och omkring 1 400 tillägg, varav drygt tusen är en enda modellfil. Det är den sjätte integrationen som lämnats in för den här modellen under sex veckor, och den första som lämnats in som inte är ett utkast: GitHub listar den som öppen och redo för granskning, med tio granskare begärda — och alla dess tre CI-körningar är redan röda.

SGLang-sidan gick före i dag till på samma sätt som vLLM:s. #33982, "feat(model): add TeleChat4 model support", öppnades den 7 augusti 2026 av bidragsgivaren PaddyXj och stängdes utan att ha slagits samman den 31 augusti – samma dag som #37228, "feat: add XingChen4 model support", öppnades i dess ställe. Den är fortfarande öppen som utkast under PaddyXj, på en gren som heter support_xingchen4, tre commits djup och senast rörd den 8 september. Dess checklista är det mest intressanta i endera ramverket: att modellen laddas och genererar "lokalt, på interna vikter" är ikryssat, verktygsanrop är ikryssat, resonemangstolkning är ikryssad – och offentlig CI är inte det, eftersom den är "blockerad i väntan på viktutsläpp". Någon har en checkpoint. Ingen har publicerat den. Och till skillnad från vLLM, där varje ny inlämning först stängde sin föregångare, har SGLang nu två aktiva pull requests öppna för samma modell, under två olika namn.

Det som sex integrationer på sex veckor summerar till är inte en starkare version av samma signal; det är en annan. Sex integrationer skulle vara förenligt med ett team som itererar. Sex integrationer under tre namn — TeleChat4, XingChen4, Xing4_0 — är ett team som itererar kring namnet modellen kommer att släppas under, offentligt, medan vikterna förblir privata. Det är en overifierad slutledning, och det är det mest konsekvensrika som PR-spåret nu visar.

Vad de två september-PR:erna faktiskt tillför

vLLM-pullbegäran är en namnändring av augustiarbetet snarare än en omskrivning av det. Modellfilen är nu vllm/model_executor/models/xing4_0.py, klassen är Xing4_0ForCausalLM, och model_type xing4_0 mappas till DeepseekV3Config — samma DeepSeek-V3-konfiguration som XingChen4-versionen använde. Vad den innehåller:

• En fullständig modellimplementering i vllm/model_executor/models/xing4_0.py — klassen Xing4_0ForCausalLM, med forward-pass, en mHC-adapter och en tensor-parallell load_weights()-implementering. Commit-meddelandet noterar att både DSA- och icke-DSA-varianter stöds, och återanvänder de delade mhc_pre / mhc_post-oparna.

• Registrering av Xing4_0ForCausalLM i vllm/model_executor/models/registry.py, så att vLLM känner igen arkitekturen vid namn.

• En resonemangsparser (vllm/reasoning/xing4_0_reasoning_parser.py) "för varianter med resonemangsförmåga," och en verktygsparser (vllm/tool_parsers/xing4_0_tool_parser.py) för automatiskt verktygsanrop.

• Registrering i vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py och vllm/transformers_utils/config.py — med commit-meddelandet som anger att ett DeepSeek-V3-kompatibelt MTP-huvud är aktiverat för spekulativ avkodning.

• Två dokumentationsfiler – den genuint nya delen, och en direkt reversering av augusti. Den ursprungliga commiten innehöll en dokumentations- och testpost som reverterades en timme senare som förhastad; september-PR:en lägger tillbaka dokumentationen och är märkt documentation, new-model och tool-calling.

vLLM-dokumentationens poster är där en läsare först fick veta något konkret. I docs/models/supported_models.md lyder den nya raden `Xing4_0ForCausalLM` | Xing4_0 | TBA — checkpoint-kolumnen säger bokstavligen TBA, vilket är samma "inte ännu" i ett annat typsnitt. Och i docs/features/tool_calling.md, under rubriken "Xing4_0 Models (xing4_0)", dokumenterar PR:en modellens verktygsanropsformat: anrop skickas inuti <tool_call>...</tool_call>-block, antingen som JSON ({"name": ..., "arguments": {...}}) eller i en tagg-baserad form med <param_key>...</param_key> och <param_value>...</param_value>. Det är en detaljnivå som de tidigare PR:erna inte nådde — en implementeringsdetalj i modellens chattformat, nedskriven i ett stort ramverks offentliga dokumentation, för en checkpoint som ingen kan ladda ner.

SGLang-PR:en är mer intressant, eftersom den levererar en implementation och en konfiguration snarare än en registerpost plus dokumentation. Dess dokumentationsrad är första gången ett ramverk har satt leverantörens namn i sin egen dokumentation. I docs/docs/supported-models/generative_models.mdx, listar den nya raden Xing4_0, där checkpoint-kolumnen anger `Xing4_0` (kommer snart) och en beskrivning: "China Telecoms MoE-modell med MLA-attention och mHC (Manifold-constrained Hyper-Connection)-restströmmar; stöder inbyggd MTP-spekulativ avkodning, verktygsanrop och resonemang." vLLM:s rad angav TBA och nämnde ingen leverantör; SGLangs nämner China Telecom och säger att det kommer snart. Ingen av dem är ett releasedatum, och en rad i ett ramverks dokumentation är inte en produkt.

PR-beskrivningen lägger till siffran som varje tidigare version av den här historien saknade. "Den här PR:en lägger till stöd för Xing4.0-29B-A4B (29B-parameters MoE med cirka 4B aktiverade parametrar)." Den ger också ett startkommando — --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 — och anger att konfigurationen verifierades vid tensor-parallellism 2, ett kontextfönster på 262 144 tokens och EAGLE MTP-spekulativ avkodning, med utskrifter av ett resonemangssvar och ett anrop till verktyget get_weather inklistrade i beskrivningen som bevis. Vikterna bakom den verifieringen är författarens egna: sökvägen till förvaret som PR:en anger är inte offentligt läsbar, och den Hugging Face-organisation som den pekar på listar inga publika modeller alls. Betrakta storleken, kontextlängden och utskrifterna som PR-rapporterade påståenden kopplade till en privat checkpoint, inte som mätningar som någon kan upprepa. Allt detta är enligt pull requesten och inte reproducerat.

Att resonemangs- och verktygsparsrarna dyker upp under båda namnen spelar roll av samma skäl som i augusti. En resonemangsparser finns till för att ta bort tankemarkörer från en modells utdata – den interna tankekedja som en modell avger före sitt slutliga svar. En parser som är specialbyggd för den här modellen innebär att familjen förväntas ha varianter med resonemangsförmåga, på samma sätt som TeleChat3 släppte Thinking-utgåvor. Verktygsparsern, tillsammans med det nu dokumenterade anropsformatet, innebär att inbyggt funktionsanrop också förväntas. Ingen av dem är en garanti för slutprodukten; båda är de starkaste ledtrådarna som PR:erna bär på om vad China Telecom siktar på.

Vad vi vet hittills, i ett ögonkast.

Resultattavlan nedan är den som sammanställdes för den här artikeln den 27 augusti 2026, utifrån vLLM-PR:en så som den såg ut då. Den hålls medvetet kvar här som en daterad ögonblicksbild i stället för att ritas om, eftersom varje rad i den fortfarande är sann tre veckor senare – ej släppt, vikterna inte offentliga, DeepSeek-backbone, mHC-residual, båda parsrarna inkluderade. Det som har förändrats är inte ett värde på kortet utan allt runt omkring det: vLLM-PR:en som den citerar stängdes den 7 september, arbetet dök upp igen under ett nytt namn den 16 september, SGLang följde namnbytet timmar senare och det första angivna antalet parametrar kom med det. Ingenting på kortet är fel. Det är helt enkelt tre veckor gammalt, och historien har gått förbi det. FlagGems-siffrorna i dess sista rad fördes över till den nya vLLM-PR:en oförändrade, fortfarande PR-rapporterade och fortfarande oreproducerade.

Den arkitektur som PR:erna läcker

Att byta namn på en fil byter inte namn på en arkitektur, och sammanfattningstexten i september-PR:en för vLLM är augustitexten med Xing4_0 i stället för XingChen4 — sats för sats. Två meningar bär signalen:

• "Xing4_0 återanvänder stommen från DeepSeek-V2/V3 (MLA-attention, MoE-block, valfri DSA-indexerare)."

Den ersätter den standardmässiga residualkopplingen med Manifold-constrained Hyper-Connections (mHC): residualströmmen expanderas till num_residual_streams parallella strömmar som blandas av indataberoende, dubbelt stokastiska matriser som genereras via Sinkhorn-Knopp-projektion.

Varje sats motsvarar något konkret. MLA är Multi-head Latent Attention, den komprimerade attention-metod som DeepSeek introducerade i V2 och som låter KV-cachen förbli liten; MoE är mixture-of-experts-routing, som håller ett stort parameterantal med ett litet aktivt fotavtryck. Den valfria DSA-indexeraren är DeepSeek Sparse Attention-mekanismen från V3.2-linjen – en lättviktig poängsättningsmodul som väljer ut de top-k-token som ska uppmärksammas, vilket minskar uppmärksamhetskostnaden från kvadratisk till ungefär linjär med avseende på kontextlängden. Och mHC-meningen är huvudnyheten: den här modellen anammar den residualarkitektur som DeepSeek själv först introducerade i den här generationen.

SGLang-PR:en är den första som publicerar själva formen på saken i stället för att beskriva den. Dess konfigurationsfil, python/sglang/srt/configs/xing4_0.py, anger 40 dolda lager, en dold storlek på 3 584 och en vokabulär på 131 072 tokens; MLA med en KV LoRA-rank på 512 och en query LoRA-rank på 768 över 32 huvuden; och en gles MoE med 64 routade experter plus en delad expert, top-4-routing, sigmoid-scoring, en routad skalningsfaktor på 2,0 och noaux_tc-expertval. mHC-fälten är också explicita: hc_mult 4, tjugo Sinkhorn-Knopp-iterationer, en h_res-klämning vid plus eller minus 30, och en rope_theta på 10 000 med en maximal positionsinbäddning på 262 144. Dessa är standardvärdena i en integration som inte har släppts, enligt pull requesten — en konfigurationsfil är en avsiktsförklaring, inte ett modellkort, och siffran 29B-A4B i PR-beskrivningen härleds inte från dem någonstans offentligt.

Ett fält är värt mer än resten, eftersom det är den första platsen där den här modellen synligt slutar vara en kopia av DeepSeek. SGLang-konfigurationen anger hc_contract_for_draft, som slår samman mHC-strömmarna tillbaka ned till modellens egen dolda storlek före den slutliga normen och matar den kontraherade tensorn till Eagle-draft-huvudet. DeepSeek V4 matar i stället den mHC-tillplattade n-times-hidden_size-tensorn. Konfigurationskommentaren säger det uttryckligen, och det är den typ av detalj som bara dyker upp när en implementation har formats mot en verklig checkpoint — vilket den tidigare SGLang-PR:s checklista påstår sig ha, utan att publicera den.

mHC-matematiken är där de två stackarna går isär i implementeringen och möts i antagandet. vLLM-PR:en noterar att den "matchar de delade operationerna i vllm.model_executor.layers.mhc, så inga privata kärnor introduceras" – den modulen finns eftersom vLLM redan stöder mHC för DeepSeek V4, så marginalkostnaden för att lägga till den här modellen är liten. SGLang når samma plats via en annan väg: dess mHC-modul använder fusionerade TileLang-kärnor registrerade som anpassade torch-operationer, och PR:en utökar den befintliga mhc_pre split-K-kärnan till att acceptera hc_hidden_size 14 336 tillsammans med de två storlekar som den redan hanterade. Den stänger också av DeepGEMM:s tf32_hc_prenorm_gemm-väg för den här arkitekturen, eftersom den vägen är ett rå C-tillägg som torch.compile inte kan spåra; mHC faller i stället igenom till TileLang-kärnan. Den praktiska fördelen är densamma i båda ramverken: om du kör DeepSeek V4 på vLLM eller SGLang i dag, är maskineriet som kommer att köra China Telecoms nästa MoE redan installerat.

mHC, DeepSeek-tricket i centrum av allt

Manifold-constrained Hyper-Connections förtjänar att benas ut, eftersom det är det enskilt mest intressanta med den här modellen — och det är inte China Telecoms uppfinning. Det är Deep​Seeks.

Berättelsen börjar med Hyper-Connections, som föreslogs av Kimi-teamet 2024. En vanlig Transformer har en residualström per lager: indata adderas till lagrets utdata, vilket ger gradienterna en ren väg och låter nätverket lära sig en residualkorrigering. Hyper-Connections ersätter den enda strömmen med flera parallella strömmar som blandas av inlärda matriser i varje lager, vilket ger modellen en mycket rikare väg för information att färdas. Haken är stabiliteten: obegränsade blandningsmatriser bryter identitetsavbildningsegenskapen som gör residualkopplingar träningsbara, och i skalan med biljoner parametrar blir träningsförlusten instabil.

DeepSeeks bidrag, publicerat som mHC-artikeln i december 2025 och sedan använt i DeepSeek V4, var att begränsa blandningsmatriserna till att vara dubbelt stokastiska — icke-negativa, med rader och kolumner som vardera summerar till ett — vilket upprätthölls genom Sinkhorn-Knopp-projektion under träningen. En dubbelt stokastisk matris har spektralradie exakt ett, så signaler kan inte förstärkas eller dämpas exponentiellt när de passerar genom hundratals lager. Den gränsen är det som håller träningen stabil i stor skala, och projektionen är tillräckligt billig för att DeepSeek rapporterade endast omkring 6,7 % träningsöverhead vid fyra residualströmmar. DeepSeek V4, släppt den 24 april 2026, är den främsta användningen av detta, med en rapporterad förbättring på ungefär 15 % på matematiska resonemangsuppgifter och en kontext på 1M token ovanpå det.

Så vad dessa PR-meddelanden säger, i klartext, är: China Telecoms nästa modell tar DeepSeeks beprövade stomme och DeepSeeks nyaste residualmekanism i stället för att uppfinna någon av dem från grunden. Det är ett pragmatiskt val, och det bär på en subtil bekräftelse – det andra stora labbet efter DeepSeek självt som adopterar mHC anser att knepet är produktionsklart.

PR:arna är inte färdiga med mHC, och de öppna punkterna är uppriktiga om det. I vLLM-PR:arna noterar författaren att checkpoint-biaserna (bias_pre, bias_post, bias_res) och en h_res-clamp för närvarande är sammanslagna eller utelämnade, och att granskarens bekräftelse av formelekvivalens är "den huvudsakliga korrekthetsfrågan". Det finns också en anpassad transpose-op som håller en tensor C-kontinuerlig för en TileLang-kärna – omdöpt tillsammans med allt annat, från _xingchen4_transpose_contiguous till _xing4_0_transpose_contiguous – och en hård begränsning: pipeline-parallellism stöds inte i mHC-läge när num_residual_streams är större än ett, medan tensor-parallellism stöds. Inget av detta är förvånande för ett utkast, men det är samma oavslutade kant som i augusti, vilket i sig är informativt: sex veckor av namnbyten har inte fört korrekthetsfrågan framåt, och de tre röda CI-körningarna på den nyaste SGLang-PR:en är samma historia i en annan färg. Vad SGLang-konfigurationen faktiskt fastställer är antalet strömmar. Med hc_mult satt till 4 och en hidden size på 3 584 är 14 336 i kärnpatchen exakt fyra strömmar – och kärnkommentaren säger det rent ut. Den tolkningen var en slutledning från enbart en siffra när den här artikeln först publicerades; nu står den nedskriven i en konfigurationsfil.

Accelerationsvinkeln: FlagGems, igen

En andra tråd knyter denna modell till China Telecoms befintliga relation med Beijing Academy of Artificial Intelligence, och det är den enda tråden som har överlevt varje namnbyte intakt. vLLM-PR:en möjliggör valfri FlagOS/FlagGems-acceleration bakom en USE_FLAGOS-miljöflagga, avstängd som standard, och byter in kärnor för heta kodvägar för MoE, attention, softmax och top-k. Den påstådda vinsten, från PR-författarens H100-benchmark på en arbetsbelastning med hög samtidighet och långa promptar (över 10 000 indatatoken, samtidighet 10): upp till 19,87 % kortare tid till första token och upp till 26,32 % kortare tid per utdatatoken, medan andra arbetsbelastningar är neutrala. Dessa siffror är PR-rapporterade och inte reproducerade, och de kommer med flaggan avstängd som standard.

Det som är värt att notera är hur lite namnbytet påverkade. September-PR:en för vLLM innehåller samma siffror, samma snäva omfångsnotis om att flaggan bara finns i modellfilen, och samma instruktion att installera flagtree och flag-gems. Siffrorna ändrades inte eftersom koden inte ändrades; bara etiketten gjorde det. SGLang-pullförfrågningarna innehåller ingen FlagGems-tråd alls – de tar i stället TileLang- och DeepGEMM-vägen – vilket gör detta till en argumentation om vem som äger optimeringen av serveringslagret, inte om modellen.

Det här är en historia om kontinuitet. TeleChat3-36B-Thinking var, i april 2026, den första stora modellen som oberoende porterades till FlagOS, BAAI:s AI-programvarustack med öppen källkod. Oavsett vad den här modellen levereras som, säger en fortsättning på den tråden – med FlagGems-kärnor i dess egen vLLM-integration – att labbets strategi för inhemsk stack sträcker sig in i serveringslagret, inte bara träning.

Namnfrågan, och familjen den kommer från

Fram till den 16 september var namnfrågan en sidnot. Nu är den nästan avgjord, och bevisen finns fortfarande helt och hållet i grennamn och kvarlämnade strängar snarare än i uttalanden – men de två ramverken har konvergerat på samma svar från samma håll.

• Commit-meddelandena, i ordning: "Lägg till stöd för TeleChat4-modellen," sedan "chore: återställ för tidig dokumentation och testpost för telechat4," sedan — tre veckor senare och en minut innan PR:en stängdes — "byt namn på xingchen4." En commit vars enda syfte var namnbytet.

• Forken förgrenar sig. De två första vLLM-PR:erna, #51237 och #54051, skapades från zyp2014:supported_telechat4. Den tredje, #57135, är zyp2014:support_xing4_0. Grenen döptes om i samma drag som modellen döptes om — och SGLang-sidan har nu gått exakt samma väg i tre steg, från support_telechat4 via support_xingchen4 till support_xing4_0.

• Brödtexten i #51237, som sade att FlagGems-accelerationen var "för TeleChat4", medan samma stycke kallade modellen för XingChen4. De två namnen krockade redan i författarens egen sammanfattning den 6 augusti.

• Fil-för-fil-omdöpningen på båda sidor. I vLLM var det xingchen4.py till xing4_0.py och XingChen4ForCausalLM till Xing4_0ForCausalLM; i SGLang är det xingchen4.py till xing4_0.py och XingChen4Config till Xing4_0Config, på en gren som också bytte namn. Ingen av PR:erna lämnade det gamla namnet kvar någonstans i sin diff.

Så tre namn har varit i spel i två ramverk, och mönstret stämmer med att en enda modell byter namn när den närmar sig vad dess offentliga namn än kommer att bli. "Xing4_0" läses naturligt som Xingchen 4.0 – modellens familj är varumärkt 星辰 (Xingchen) på kinesiska – men det är fortfarande en slutledning från strängen, inte något som något PR-material säger rakt ut. Det skulle lika gärna kunna vara att TeleChat4 och XingChen4 är syskon i samma generation snarare än en modell under två namn, även om den delade forken, det delade arkitekturavsnittet, de delade FlagGems-siffrorna, de delade öppna punkterna och nu ett delat namnbyte gör det svårare att hävda. Ingen har bekräftat relationen och China Telecom har inte kommenterat. Det som har förändrats är att namnbytet inte längre är en enskild bidragsgivares val: två oberoende servingprojekt, underhållna av olika personer, har båda märkt om sin integration till samma tredje namn inom loppet av en dag från varandra.

Familjen i sig är värd att hålla i åtanke, eftersom den förklarar pragmatismen. De offentliga utgåvorna hittills har fått varumärket TeleChat:

TeleChat-7B och TeleChat-12B, öppen källkod i januari 2024 med en korpus på 1 biljon tokens.

• TeleChat2-115B (september 2024), som beskrivs som den första helt inhemska öppna modellen med en biljon parametrar, plus syskonmodellerna 35B, 7B och 3B.

• TeleChat2-39B-A12B (mars 2025), familjens första MoE.

• TeleChat3-105B-A4.7-Thinking (december 2025), en finkornig MoE med totalt 105B och 4,7B aktiva parametrar, tränad på 15 biljoner tokens, tillsammans med den täta TeleChat3-36B och senare TeleChat3-Coder-36B-Thinking.

Om siffran 29B-A4B håller skulle den här modellen ligga under TeleChat3-105B-A4.7-Thinking i både totala och aktiva parametrar – en mindre, billigare syskonmodell snarare än ett ersättande flaggskepp. Det är en tolkning, inte ett faktum; inget i någon av de båda PR-texterna säger vilken nivå modellen riktar sig till. Xingchen-varumärket är där företaget lägger sin AI-satsning: Xingchen AGI Lab grundades formellt i Peking i mars 2026 med utgångspunkt i samma modellfamilj, och China Telecom beskriver sitt "三全"-system (fullmodal, fullstorlek, helt inhemsk) som spänner över semantiska, tal-, bild- och multimodala modeller från 1B till 1T+ parametrar. Ett namnbyte från TeleChat till Xingchen är precis vad ett labb gör när det vill att modellfamiljen ska bära labbets varumärke snarare än produktlinjens varumärke.

Det vi fortfarande inte vet

För en modell så här tidigt är den ärliga listan fortfarande längre än den kända listan, även om den har krympt på två punkter den här veckan:

• Inget releasedatum. Fem av de sex integrationerna är utkast som öppnats för tidig kodgranskning, just eftersom vikterna inte är offentliga. Den sjätte, SGLang #39793, är öppen för granskning i stället för utkast – men den är inte mergad, alla tre av dess CI-körningar misslyckas och den behöver en granskare som godkänner den. Det finns ingen annonserad tidsplan.

• Ett parameterantal, men bara ett påstått sådant. Varje tidigare version av den här texten angav MoE-konfigurationen som ej offentliggjord. SGLang-PR:en ändrar på det på pappret: Xing4.0-29B-A4B, 29B totalt, ungefär 4B aktiva. Siffran kommer från en pull request, är inte kopplad till någon offentlig checkpoint, bekräftas inte av någon konfigurationsfil och har inte reproducerats av någon utanför projektet. Behandla den som en uttalad avsikt, inte som en specifikation.

• Inga benchmark-siffror, vare sig leverantörsrapporterade eller andra, och inga oberoende resultat. Verifieringstranskripten i SGLang-PR:en visar att modellen besvarar en resonemangsprompt och avger ett välformat verktygsanrop; de visar ingenting om hur bra den är på något av dem.

• Inget pris, och ingen bekräftad licens. Varje tidigare TeleChat-version är Apache-2.0, vilket är hoppingivande, men ingen licens har angetts för den här.

• Inga offentliga vikter – bekräftat snarare än antaget. Sedan den 16 september 2026 är Hugging Face-sökvägen som SGLang-PR:en namnger inte offentligt läsbar, och organisationen den pekar på listar inga offentliga modeller; den nyaste offentliga posten i familjen är TeleChat3-Coder-36B-Thinking från januari. vLLM:s tabell över modeller som stöds säger TBA i checkpoint-kolumnen, SGLang:s säger "kommer snart", och båda SGLang-PR:erna har misslyckad offentlig CI.

• Inget officiellt besked från China Telecom – inget tillkännagivande, inga vikter, ingen bekräftelse av namnet eller storleken. Notera asymmetrin noga: raden i SGLang-dokumentationen tillskriver China Telecom modellen, men det är en bidragsgivares beskrivning i en pull request, inte ett företagsuttalande, och den senaste PR-beskrivningen utelämnar leverantörens namn helt och hållet. Att sex integrationer byggs för den här modellen är det starkaste beviset hittills på att den är verklig, men integrationer stängs och kodnamn ändras; två har redan stängts. Inget är bekräftat förrän labbet säger det.

Det rätta sättet att läsa allt detta är inte skepsis mot modellen; det är en korrekt bild av en tidig signal. Det som finns idag är en verklig ingenjörskonstruktion – sex stycken, fördelade över två ramverk – med en verklig arkitektur och, för första gången, en angiven form fäst vid sig. Det som ännu inte finns är något du kan ladda ner, anropa eller benchmarka.

Det närmaste du kan köra idag

Den här modellen kan inte köras någonstans – inte via ett API, inte lokalt, eftersom vikterna inte är offentliga. Den närmaste modellen en läsare faktiskt kan anropa idag som delar dess arkitektoniska DNA är DeepSeek V4 Flash, som använder samma mHC-residualschema ovanpå MLA och MoE, och det är referensimplementationen som de delade mHC-modulerna i båda ramverken byggdes för. OrcaRouters modellsida för deepseek/deepseek-v4-flash listar en kontext på 1M tokens, en maximal utdata på 384K och listpriser på $0,15 per miljon indata-tokens och $0,29 per miljon utdata – samma siffror som Deep​Seek själva publicerar, vidarebefordrade med 0 % påslag, så en leverantörsprisändring är live här samma dag. En API-nyckel täcker katalogen, vilket gör jämförelsen mot resten av reasoning-nivån till en routingregel snarare än en ny integration.

Det är också det praktiska svaret på "hur testar jag den här modellen när den släpps". En helt ny, obeprövad checkpoint är precis där automatisk failover gör nytta: routa en del av trafiken till den, behåll en beprövad modell som fallback och låt routningslagret fatta beslutet i stället för att satsa en produktionsväg på beteendet från dag ett. En 29B MoE med ungefär 4B aktiva parametrar, om det är vad som kommer, är billig att routa mot en frontiermodell just eftersom så lite av den aktiveras per token. Om namnet ändras igen mellan nu och lansering – och de senaste sex veckorna tyder på att det kan hända – är det routingregeln du skriver om, inte integrationen.

Vanliga frågor

Varför stängdes vLLM-PR:en?

Vi kan se stängningen, inte orsaken. #54051 stängdes av sin egen författare den 7 september 2026 utan att ha blivit sammanslagen, och arbetet dök upp igen nio dagar senare som #57135 under ett nytt namn. En tidigare vLLM-PR, #51237, stängdes och lämnades in på nytt samma dag under samma titel, så att stänga och lämna in på nytt är den här författarens mönster snarare än ett tecken på problem — men PR-brödtexterna uppger ingen orsak och vi kommer inte att hitta på en.

När släpps Xing4_0?

Det finns inget datum. Fem av de sex integrationerna är utkast som öppnats för tidig kodgranskning, och författarnas egna planer är att lägga till testposter, uppdatera dokumentationen och markera PR:erna som redo först när vikterna har släppts. SGLangs äldre checklista är den tydligaste beskrivningen av läget: "Modellen laddas och genererar (lokalt, på interna vikter)" är ikryssad, och den offentliga CI:n är "blockerad i väntan på att vikterna släpps". Den nyare SGLang-PR:en är inlämnad som redo för granskning i stället för utkast, vilket är en förändring i hållning snarare än i status – den är inte sammanslagen, dess CI är röd, och en dokumentationsrad med texten "kommer snart" är inte en lansering.

Är Xing4_0 samma modell som XingChen4?

Nästan säkert ja, och PR:erna gör det enkelt att kontrollera: samma fork-härstamning, samma arkitekturavsnitt, samma benchmarksiffror för FlagGems, samma öppna punkter och en namnändring fil för fil i båda ramverken – xingchen4.py till xing4_0.py, inklusive config-klassen, på grenar som döpts om för att matcha. Det är samma arbete under ett nytt namn, och sedan den 16 september har både vLLM och SGLang antagit det namnet. Vad ingen PR säger är vilket namn en släppt checkpoint kommer att bära.

Är detta en Deep​Seek-modell?

Nej. Det är China Telecoms modell, från Xingchen AGI Lab. Deep​Seek-kopplingen är arkitektonisk: den återanvänder Deep​Seek-V2/V3-stommen och mHC-residualschemat som Deep​Seek föreslog och släppte i V4. Att anamma någons arkitektur är inte samma sak som att de två projekten är relaterade.

Vad du ska titta på härnäst

PR:erna ger fortfarande en konkret checklista, och paret från den 16 september lade till två punkter i den. För det första, vikterna: varje författare har sagt att deras arbete väntar på Hugging Face, så ett offentligt arkiv som dyker upp är den bärande händelsen – och SGLang-PR:en ger dig nu den exakta sökvägen att bevaka, XingChen-AGI/Xing4.0-29B-A4B, som för närvarande inte går att slå upp för någon. För det andra, själva PR:erna: vLLMs behöver få mHC-biasformlerna bekräftade, registrets testpost tillagd och sin CI grön; SGLangs #39793 behöver få sina tre röda körningar åtgärdade och sina tio begärda granskare att ge sitt godkännande, medan den äldre #37228 fortfarande behöver sin testpost, sitt MTP-speedup-benchmark och en oblockerad CI. För det tredje, och nytt den här veckan: huruvida SGLang stänger #37228 till förmån för #39793 på samma sätt som vLLM alltid har stängt en föregångare innan den lämnats in på nytt. Två aktiva integrationer för en och samma ännu inte släppta modell är ett tillstånd som ingen upprätthåller länge, och vilken av dem som överlever säger något om hur nära detta egentligen är. För det fjärde, siffrorna: huruvida en släppt checkpoint matchar 29B-A4B-formen, MoE:n med 64 experter och kontexten på 262 144 token som konfigurationen och PR-beskrivningen nu gör gällande. För det femte, huruvida den tredje vLLM-PR:en överlever längre än sina två föregångare, som varade i 21 respektive 11 dagar innan de stängdes utan att ha mergats. Och håll utkik efter om reasoning-parsrarna beskriver en separat Thinking-variant på samma sätt som TeleChat3 släppte en.

Till dess att ett av dem inträffar, behandla den här modellen som vad den är: en välspecificerad plan från ett seriöst labb, tagen på bar gärning med att förbereda sin serveringsinfrastruktur — nu i båda de stora serveringsstackarna med öppen källkod, under ett namn som båda har antagit och en storlek som bara dess egen pull request anger. Arkitekturen i sig gör den värd att följa: det är den andra stora användningen av mHC efter Deep​Seek själva, från ett labb vars tidigare generation redan var en finkornig MoE tränad på inhemska chip. När vikterna släpps kommer det inte att råda någon tvekan om huruvida den körs i vLLM eller SGLang. Båda stackarna har skrivit koden tre gånger om, under tre olika namn.