Xing4_0 bereikt SGLang: een zesde PR, en de eerste opgegeven grootte, voor de volgende MoE van China Telecom

Met twee uur verschil op 16 september 2026 waren de twee dominante open-source servingstacks het niet langer oneens over de naam. vLLM diende 's ochtends "[Model] Add Xing4_0 support" in; sgl-project/sglang volgde om 10:38 UTC met "feat: add Xing4_0 model support", en na zes weken waarin drie namen in omloop waren, zeggen beide frameworks nu Xing4_0. De SGLang-pullrequest bevat iets wat geen enkele eerdere pullrequest deed: een grootte. Deze beschrijft het model als Xing4.0-29B-A4B, een "29B-parameter MoE met ~4B geactiveerde parameters", en geeft een startcommando dat een checkpointpad, een context van 262.144 tokens en EAGLE-speculatieve decoding vermeldt. Dit is de nog niet uitgebrachte MoE van China Telecom, dezelfde waar de XingChen4-pullrequests sinds augustus omheen cirkelen, en die is nog steeds niet uitgebracht: de gewichten zijn niet openbaar, het checkpointpad dat de PR noemt, resolvet niet voor wie buiten het project staat, geen enkele leverancier heeft de naam of het getal bevestigd, en niets in dit stuk is onafhankelijk geverifieerd. Feiten die uit pullrequests zijn overgenomen, zijn als zodanig aangeduid; de rest is geschiedenis en gevolgtrekking. Het dichtstbijzijnde model dat je vandaag daadwerkelijk kunt aanroepen, is DeepSeek V4 Flash.

Dit is een stuk over wat we tot nu toe weten, dat actueel wordt gehouden in plaats van telkens opnieuw te beginnen. Het behandelt het PR-traject van zes weken en hoe de naamgevingskwestie is opgelost, wat de twee pull requests van 16 september daadwerkelijk toevoegen, de architectuur die de configuratiebestanden nu tot in detail prijsgeven, en waar je hierna op moet letten. De versie in één zin: de volgende MoE van China Telecom is echt genoeg om zes serving-integraties te hebben verzameld, een tabelrij in vLLM gemarkeerd als TBA, een documentatievermelding in SGLang gemarkeerd als 'binnenkort beschikbaar' en een opgegeven parameteraantal — en nog steeds niet echt genoeg om te draaien op een plek die je kunt bereiken.

Het signaal: zes integraties, drie namen, zes weken

Het spoor begint eerder dan de versie van dit stuk die aanvankelijk werd gerapporteerd, en het commitlogboek ervan is nog steeds het meest onthullende artefact in het lek. De eerste vLLM-PR was #51237, geopend op 6 augustus 2026 onder de titel "[WIP][Model] Ondersteuning toevoegen voor het aankomende XingChen4-model." De drie commits ervan vertellen het verhaal op zichzelf. De eerste heeft als titel "Ondersteuning toevoegen voor het TeleChat4-model." De tweede, iets meer dan een uur later, is "chore: premature documentatie en testvermelding voor telechat4 terugdraaien" — de documentatie en de testvermelding in het register werden weer ingetrokken omdat ze te vroeg waren. De derde, op 27 augustus, is "xingchen4 hernoemen." Een minuut later werd de PR gesloten zonder te mergen, en elf minuten daarna werd #54051 geopend met dezelfde titel, dezelfde fork-branch (supported_telechat4) en één samengevoegde (squashed) commit. In de tussentijd was er een needs-rebase-label toegevoegd, dus dit leest als een sluiten-en-heropenen na opschoning in plaats van een koerswijziging. Alles werd ingediend vanaf het GitHub-account zyp2014, waarbij elke commit is geschreven en ondertekend door zhangyp26 <zhangyp26@chinatelecom.com.cn>.

Die tweede PR is degene waar dit stuk oorspronkelijk omheen was gebouwd, en hij staat niet meer open. #54051 werd op 7 september 2026 door zijn eigen auteur gesloten, zonder te worden samengevoegd.De beschrijving ervan is toch het citeren waard, want het is de zin die elke naamswijziging en elke heropening heeft overleefd:

De modelgewichten zijn nog niet openbaar op Hugging Face Hub. Deze PR is geopend voor vroege code review. Zodra de gewichten zijn vrijgegeven, zal ik een testitem aan tests/models/registry.py toevoegen, docs/models/supported_models.md bijwerken en de PR gereed markeren voor review.

Die zin is de vorm van het hele verhaal: de code loopt voor op de gewichten. De onderstaande schermafbeelding is de #54051-pagina zoals die er op 27 augustus 2026 uitzag, de dag dat die werd geopend — een gedateerde momentopname, bewaard omdat de pull request die erop te zien is inmiddels is gesloten. Lees het als een verslag van het signaal op dat moment, niet van de status nu.

Daarna, op 16 september, herhaalde het patroon zich — twee keer op één dag. #57135, "[Model] Ondersteuning voor Xing4_0 toevoegen," werd die ochtend geopend vanaf hetzelfde account, zyp2014, met één enkele commit die nu is geschreven door een andere China Telecom-ingenieur — xiongji <xiongj9@chinatelecom.cn>. Elf bestanden gewijzigd, ongeveer 1.300 toevoegingen, een nieuwe naam in alle bestanden, en dezelfde kanttekening op dezelfde plek: "Modelgewichten zijn nog niet openbaar op Hugging Face Hub."

Twee uur en twintig minuten later was de andere serving-stack niet langer één hernoeming achter. sgl-project/sglang #39793, "feat: add Xing4_0 model support," geopend vanuit een branch genaamd support_xing4_0, en de enkele commit ervan draagt hetzelfde xiongji-adres als de vLLM-hernoeming. Veertien bestanden en ongeveer 1.400 invoegingen, waarvan net iets meer dan duizend in één modelbestand zitten. Het is de zesde integratie die in zes weken voor dit model is ingediend, en de eerste die niet als concept is ingediend: GitHub vermeldt het als open en klaar voor review, met tien aangevraagde reviewers — en alle drie de CI-runs ervan al rood.

De SGLang-kant werkte tot vandaag op dezelfde manier als die van vLLM. #33982, "feat(model): add TeleChat4 model support," werd op 7 augustus 2026 geopend door de bijdrager PaddyXj en op 31 augustus gesloten zonder samenvoeging — dezelfde dag #37228, "feat: add XingChen4 model support," werd in plaats daarvan geopend. Die is nog steeds open als concept onder PaddyXj, op een branch genaamd support_xingchen4, drie commits diep en voor het laatst aangepast op 8 september. De checklist ervan is het meest interessante onderdeel van beide frameworks: model laadt en genereert "lokaal, op interne gewichten" is aangevinkt, tool calling is aangevinkt, reasoning-parsing is aangevinkt — en openbare CI is niet aangevinkt, omdat deze "geblokkeerd door de release van gewichten." Iemand heeft een checkpoint. Niemand heeft het gepubliceerd. En in tegenstelling tot vLLM, waar elke herindiening eerst zijn voorganger sloot, heeft SGLang nu twee actieve pull requests open voor hetzelfde model, onder twee verschillende namen.

Waar zes integraties in zes weken op neerkomen, is niet een sterkere versie van hetzelfde signaal; het is een ander signaal. Zes integraties zouden consistent zijn met een team dat aan het itereren is. Zes integraties onder drie namen — TeleChat4, XingChen4, Xing4_0 — duiden op een team dat in het openbaar itereert op de naam waaronder het model zal uitkomen, terwijl de gewichten privé blijven. Dat is een niet-geverifieerde gevolgtrekking, en het is het meest verstrekkende dat het PR-spoor nu laat zien.

Wat de twee PR's van september nu eigenlijk toevoegen

De vLLM pull request is een hernoeming van het augustuswerk in plaats van een herschrijving ervan. Het modelbestand is nu vllm/model_executor/models/xing4_0.py, de klasse is Xing4_0ForCausalLM, en het model_type xing4_0 is toegewezen aan DeepseekV3Config — dezelfde Deep​Seek-V3-config die de XingChen4-versie gebruikte. Wat het bevat:

• Een volledige modelimplementatie in vllm/model_executor/models/xing4_0.py — klasse Xing4_0ForCausalLM, met forward pass, een mHC-adapter en een tensor-parallelle load_weights()-implementatie. Het commitbericht vermeldt dat zowel DSA- als niet-DSA-varianten worden ondersteund, met hergebruik van de gedeelde mhc_pre / mhc_post-ops.

Registratie van Xing4_0ForCausalLM in vllm/model_executor/models/registry.py, zodat vLLM de architectuur op naam herkent.

• Een reasoning-parser (vllm/reasoning/xing4_0_reasoning_parser.py) "voor varianten die kunnen redeneren", en een tool-parser (vllm/tool_parsers/xing4_0_tool_parser.py) voor automatische toolaanroepen.

• Registratie in vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py en vllm/transformers_utils/config.py — met de commitboodschap waarin staat dat een Deep​Seek-V3-compatibele MTP-head is ingeschakeld voor speculatieve decoding.

• Twee documentatiebestanden — het werkelijk nieuwe deel, en een directe terugdraaiing van augustus. De oorspronkelijke commit bevatte een docs- en testvermelding die een uur later als voortijdig werd teruggedraaid; de PR van september zet de documentatie er weer in en is gelabeld als documentation, new-model en tool-calling.

De vLLM-documentatie-items zijn waar een lezer voor het eerst iets concreets leerde. In docs/models/supported_models.md, luidt de nieuwe rij `Xing4_0ForCausalLM` | Xing4_0 | TBA — de checkpoint-kolom zegt letterlijk TBA, wat hetzelfde "nog niet" is in een ander lettertype. En in docs/features/tool_calling.md, onder de kop "Xing4_0 Models (xing4_0)", documenteert de PR het tool-call-formaat van het model: calls worden uitgegeven binnen <tool_call>...</tool_call>-blokken, als JSON ({"name": ..., "arguments": {...}}) of als een op tags gebaseerde vorm met <param_key>...</param_key> en <param_value>...</param_value>. Dat is een niveau van specificiteit dat de eerdere PR's niet bereikten — een implementatiedetail van het chatformaat van het model, opgeschreven in de openbare documentatie van een groot framework, voor een checkpoint dat niemand kan downloaden.

De SGLang-PR is interessanter, want die levert een implementatie en een config mee in plaats van een registry-entry plus documentatie. De rij in de documentatie is de eerste keer dat een framework de naam van de leverancier in zijn eigen docs opneemt. In docs/docs/supported-models/generative_models.mdx, vermeldt de nieuwe rij Xing4_0, waarbij in de checkpoint-kolom `Xing4_0` staat (binnenkort beschikbaar) en een beschrijving: "het MoE-model van China Telecom met MLA-attentie en mHC (Manifold-constrained Hyper-Connection)-reststromen; ondersteunt native MTP-speculatieve decoding, tool calling en redeneren." De rij van vLLM zei TBA en noemde geen leverancier; die van SGLang noemt China Telecom en zegt binnenkort beschikbaar. Geen van beide is een releasedatum, en een rij in de docs van een framework is geen product.

De PR-beschrijving voegt het getal toe dat elke eerdere versie van dit verhaal miste. "Deze PR voegt ondersteuning toe voor Xing4.0-29B-A4B (MoE met 29B parameters en ~4B geactiveerde parameters)." Deze geeft ook een startcommando — --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 — en stelt dat de configuratie is geverifieerd bij tensorparallelisme 2, een context van 262.144 tokens en EAGLE MTP-speculatieve decoding, waarbij transcripten van een reasoning-antwoord en een get_weather-toolaanroep in de beschrijving zijn geplakt als bewijs. De gewichten achter die verificatie zijn van de auteur zelf: het repositorypad dat de PR noemt, is niet openbaar leesbaar, en de Hugging Face-organisatie waarnaar het verwijst, vermeldt helemaal geen openbare modellen. Beschouw de grootte, de contextlengte en de transcripten als in de PR gerapporteerde beweringen die aan een privé-checkpoint zijn gekoppeld, niet als metingen die iedereen kan herhalen. Dit alles is volgens de pull request en niet gereproduceerd.

Dat de reasoning- en toolparsers onder beide namen verschijnen, is om dezelfde reden van belang als in augustus. Een reasoning-parser bestaat om denkmarkeringen uit de uitvoer van een model te verwijderen — de interne chain-of-thought die een model vóór zijn uiteindelijke antwoord produceert. Een parser die speciaal voor dit model is gebouwd, betekent dat er van de familie varianten met reasoning-capaciteiten worden verwacht, net zoals TeleChat3 Thinking-edities uitbracht. De toolparser, plus het nu gedocumenteerde aanroepformaat, betekent dat native function calling ook wordt verwacht. Geen van beide is een garantie over het eindproduct; beide zijn de sterkste aanwijzingen die de PR's bevatten over waar China Telecom op mikt.

Wat we tot nu toe weten, in één oogopslag

Het onderstaande scorebord is het exemplaar dat voor dit stuk op 27 augustus 2026 is samengesteld, op basis van de vLLM-PR zoals die er destijds voor stond. Het wordt hier bewust bewaard als een gedateerde momentopname in plaats van opnieuw getekend te worden, omdat elke regel ervan drie weken later nog altijd klopt — niet uitgebracht, gewichten niet openbaar, Deep​Seek-backbone, mHC-residu, beide parsers inbegrepen. Wat is veranderd, is niet een waarde op de kaart, maar alles eromheen: de vLLM-PR waarnaar het verwijst, werd op 7 september gesloten, het werk dook op 16 september onder een nieuwe naam weer op, SGLang volgde de naamswijziging uren later en het eerste opgegeven parameteraantal kwam daarmee mee. Niets op de kaart is fout. Het is simpelweg drie weken oud, en het verhaal is er inmiddels aan voorbijgegaan. De FlagGems-cijfers in de laatste rij ervan zijn ongewijzigd overgenomen in de nieuwe vLLM-PR, nog steeds in de PR gerapporteerd en nog steeds niet gereproduceerd.

De architectuur die de PR's lekken

Het hernoemen van een bestand hernoemt geen architectuur, en de samenvattingstekst in de vLLM-PR van september is de tekst van augustus met Xing4_0 in plaats van XingChen4 — clausule voor clausule. Twee zinnen dragen het signaal:

• "Xing4_0 hergebruikt de Deep​Seek-V2/V3-backbone (MLA-attentie, MoE-blok, optionele DSA-indexeerder)."

Het vervangt de standaard residuverbinding door Manifold-constrained Hyper-Connections (mHC): de residustroom wordt uitgebreid naar num_residual_streams parallelle stromen die worden gemengd door invoerafhankelijke, dubbel-stochastische matrices die worden geproduceerd via Sinkhorn-Knopp-projectie.

Elke clausule verwijst naar iets concreets. MLA is Multi-head Latent Attention, het gecomprimeerde-aandachtsmechanisme dat DeepSeek in V2 introduceerde en dat de KV-cache klein houdt; MoE is mixture-of-experts-routing, waarbij een groot aantal parameters wordt gecombineerd met een kleine actieve voetafdruk. De optionele DSA-indexer is het DeepSeek Sparse Attention-mechanisme uit de V3.2-lijn — een lichtgewicht scoremodule die de top-k tokens selecteert om aandacht aan te besteden, waardoor de aandachtskosten van kwadratisch naar ongeveer lineair in de contextlengte gaan. En de mHC-zin is de hoofdmoot: dit model past de residuele architectuur toe die DeepSeek zelf pas in deze generatie introduceerde.

De SGLang-PR is de eerste die de vorm van het ding publiceert in plaats van die te beschrijven. Het configuratiebestand, python/sglang/srt/configs/xing4_0.py, declareert 40 verborgen lagen, een verborgen grootte van 3.584 en een vocabulaire van 131.072 tokens; MLA met een KV-LoRA-rang van 512 en een query-LoRA-rang van 768 over 32 heads; en een sparse MoE met 64 routed experts plus één gedeelde expert, top-4-routing, sigmoid-scoring, een routed scaling factor van 2,0 en noaux_tc-expertselectie. De mHC-velden zijn ook expliciet: hc_mult 4, twintig Sinkhorn-Knopp-iteraties, een h_res-clamp op plus of min 30, en een rope_theta van 10.000 met een maximale positie-embedding van 262.144. Dit zijn de standaardwaarden in een integratie die nog niet is uitgebracht, volgens de pull request — een configuratiebestand is een intentieverklaring, geen modelkaart, en het 29B-A4B-getal in de PR-beschrijving wordt nergens publiekelijk daaruit afgeleid.

Eén veld is meer waard dan de rest, omdat het de eerste plek is waar dit model zichtbaar ophoudt een kopie van DeepSeek te zijn. De SGLang-config stelt hc_contract_for_draft in, dat de mHC-stromen weer samenvoegt tot de eigen hidden size van het model vóór de finale norm en die samengevoegde tensor naar de Eagle draft head voert. DeepSeek V4 voert in plaats daarvan de mHC-flattened n-times-hidden_size-tensor in. De opmerking in de config zegt dit expliciet, en het is het soort detail dat pas opduikt zodra een implementatie tegen een echte checkpoint is gevormd — wat de checklist van de eerdere SGLang-PR beweert te hebben, zonder die te publiceren.

De mHC-wiskunde is het punt waarop de twee stacks qua implementatie uiteenlopen en qua aanname overeenkomen. De vLLM-PR merkt op dat het “overeenkomt met de gedeelde ops in vllm.model_executor.layers.mhc, dus er worden geen private kernels geïntroduceerd” — die module bestaat omdat vLLM al mHC voor DeepSeek V4 ondersteunt, dus de extra kosten van het toevoegen van dit model zijn klein. SGLang bereikt dezelfde plek via een andere weg: de mHC-module ervan gebruikt gefuseerde TileLang-kernels die als torch custom ops zijn geregistreerd, en de PR breidt de bestaande mhc_pre split-K-kernel uit om hc_hidden_size 14,336 te accepteren naast de twee groottes die de kernel al aankon. Het schakelt ook het tf32_hc_prenorm_gemm-pad van DeepGEMM uit voor deze architectuur, omdat dat pad een raw C-extensie is die torch.compile niet kan traceren; in plaats daarvan valt mHC terug op de TileLang-kernel. Het praktische voordeel is in beide frameworks hetzelfde: als je DeepSeek V4 vandaag op vLLM of SGLang draait, is de machinerie die de volgende MoE van China Telecom zal bedienen al geïnstalleerd.

mHC, de DeepSeek-truc waar alles om draait

Manifold-constrained Hyper-Connections verdient het om nader te worden bekeken, want het is het allerinteressantste aan dit model — en het is niet de uitvinding van China Telecom. Het is die van Deep​Seek.

Het verhaal begint met Hyper-Connections, voorgesteld door het Ki​mi-team in 2024. Een standaard Transformer houdt één residuele stream per laag bij: de invoer wordt opgeteld bij de uitvoer van de laag, waardoor gradiënten een schoon pad krijgen en het netwerk een residuele correctie kan leren. Hyper-Connections vervangt die enkele stream door meerdere parallelle streams die op elke laag door geleerde matrices worden gemengd, waardoor het model een veel rijkere route krijgt waarlangs informatie zich kan verplaatsen. Het addertje onder het gras is stabiliteit: onbeperkte mengmatrices breken de identiteitsafbeeldingseigenschap die residuele verbindingen trainbaar maakt, en op schaal van biljoen parameters wordt het trainingsverlies onstabiel.

DeepSeeks bijdrage, gepubliceerd als het mHC-paper in december 2025 en vervolgens gebruikt in DeepSeek V4, bestond erin de mengmatrices te beperken tot dubbel stochastisch — niet-negatief, waarbij rijen en kolommen elk tot één optellen — afgedwongen door Sinkhorn-Knopp-projectie tijdens de training. Een dubbel stochastische matrix heeft een spectrale straal van precies één, zodat signalen niet exponentieel versterkt of verzwakt kunnen worden wanneer ze door honderden lagen gaan. Die grens is wat de training op schaal stabiel houdt, en de projectie is goedkoop genoeg dat DeepSeek slechts ongeveer 6,7% trainings-overhead rapporteerde bij vier residual streams. DeepSeek V4, uitgebracht op 24 april 2026, is de belangrijkste toepassing ervan, met een gerapporteerde winst van ongeveer 15% op wiskundige redeneertaken en daarbovenop een context van 1 miljoen tokens.

Dus wat deze PR's in gewone bewoordingen zeggen, is: het volgende model van China Telecom neemt de bewezen backbone van Deep​Seek en het nieuwste residualmechanisme van Deep​Seek over, in plaats van een van beide vanaf nul te bedenken. Dat is een pragmatische keuze, en er schuilt een subtiele bevestiging in — het tweede grote lab na Deep​Seek zelf dat mHC adopteert, gelooft dat de truc productieklaar is.

De PR's zijn niet af met mHC, en de openstaande punten zijn daar eerlijk over. In de vLLM-PR's merkt de auteur op dat de checkpoint-biases (bias_pre, bias_post, bias_res) en een h_res-clamp op dit moment samengevoegd of weggelaten zijn, en dat bevestiging door de reviewer van formule-equivalentie "de belangrijkste correctheidsvraag" is. Er is ook een aangepaste transpose-operatie die een tensor C-contiguous houdt voor een TileLang-kernel — hernoemd samen met al het andere, van _xingchen4_transpose_contiguous naar _xing4_0_transpose_contiguous — en een harde beperking: pipeline-parallellisme wordt niet ondersteund in mHC-modus wanneer num_residual_streams groter is dan één, terwijl tensor-parallellisme wel wordt ondersteund. Niets hiervan is verrassend voor een concept, maar het is hetzelfde onafgemaakte punt als in augustus, wat op zichzelf informatie is: zes weken van hernoemingen hebben de correctheidsvraag niet verplaatst, en de drie rode CI-runs op de nieuwste SGLang-PR zijn hetzelfde verhaal in een andere kleur. Wat de SGLang-configuratie wel beslecht, is het aantal streams. Met hc_mult op 4 en een hidden size van 3.584 is de 14.336 in de kernel-patch precies vier streams — en de kernel-comment zegt dat met zoveel woorden. Die lezing was een gevolgtrekking uit een kaal getal toen dit stuk voor het eerst verscheen; nu staat het opgeschreven in een configuratiebestand.

De versnellingshoek: FlagGems, opnieuw

Een tweede draad verbindt dit model met de bestaande relatie van China Telecom met de Beijing Academy of Artificial Intelligence, en het is de enige draad die elke hernoeming intact heeft overleefd. De vLLM-PR maakt optionele FlagOS/FlagGems-versnelling mogelijk achter een USE_FLAGOS-omgevingsflag, standaard uitgeschakeld, waarbij hot-path-kernels worden ingezet voor MoE, attention, softmax en top-k. De geclaimde winst, op basis van de H100-benchmark van de PR-auteur op een workload met hoge gelijktijdigheid en lange prompts (meer dan 10K invoertokens, gelijktijdigheid 10): tot 19,87% lagere time-to-first-token en tot 26,32% lagere time-per-output-token, terwijl andere workloads neutraal blijven. Die cijfers zijn door de PR gerapporteerd en niet gereproduceerd, en ze gaan gepaard met de flag die standaard uit staat.

Wat het waard is om op te tekenen, is hoe weinig de hernoeming heeft aangeraakt. De vLLM-PR van september bevat dezelfde cijfers, dezelfde beperkte scopenotitie dat de flag alleen in het modelbestand zit, en dezelfde instructie om flagtree en flag-gems te installeren. De cijfers veranderden niet omdat de code niet veranderde; alleen het label veranderde. De SGLang-pullrequests bevatten helemaal geen FlagGems-thread — ze nemen in plaats daarvan de TileLang- en DeepGEMM-route — wat dit tot een argument maakt over wie de optimalisatie van de servinglaag in handen heeft, niet over het model.

Dit is een continuïteitsverhaal. TeleChat3-36B-Thinking was in april 2026 het eerste grote model dat onafhankelijk naar FlagOS werd geporteerd, de open-source AI-softwarestack van BAAI. In welke vorm dit model ook wordt uitgebracht: het doortrekken van die lijn — met FlagGems-kernels in de eigen vLLM-integratie — wijst erop dat de strategie van het lab voor een binnenlandse stack zich uitstrekt tot in de servinglaag, niet alleen tot training.

De naamgevingskwestie, en de familie waaruit die voortkomt

Tot 16 september was de naamgevingskwestie een bijzaak. Nu is ze bijna afgesloten, en het bewijs zit nog steeds allemaal in branchnamen en achtergebleven strings in plaats van in verklaringen — maar de twee frameworks zijn vanuit dezelfde richting op hetzelfde antwoord uitgekomen.

• De commitberichten, in volgorde: "TeleChat4-modelondersteuning toevoegen," dan "chore: voortijdige documentatie en testvermelding voor telechat4 terugdraaien," dan — drie weken later en één minuut voordat de PR werd gesloten — "xingchen4 hernoemen." Een commit waarvan het hele doel de hernoeming was.

• De fork vertakt zich. De eerste twee vLLM-PR's, #51237 en #54051, werden afgesplitst van zyp2014:supported_telechat4. De derde, #57135, is zyp2014:support_xing4_0. De branch werd hernoemd in dezelfde beweging waarin ook het model werd hernoemd — en de SGLang-kant heeft nu het identieke pad in drie stappen bewandeld, van support_telechat4 via support_xingchen4 naar support_xing4_0.

• De bodytekst van #51237, die zei dat de FlagGems-versnelling "voor TeleChat4" was, terwijl exact dezelfde alinea het model XingChen4 noemde. De twee namen botsten al in de eigen samenvatting van de auteur op 6 augustus.

• De hernoeming per bestand aan beide zijden. In vLLM betrof het xingchen4.py naar xing4_0.py en XingChen4ForCausalLM naar Xing4_0ForCausalLM; in SGLang is het xingchen4.py naar xing4_0.py en XingChen4Config naar Xing4_0Config, op een branch die tegelijkertijd van naam veranderde. Geen van beide PR's liet de oude naam ergens in de eigen diff achter.

Dus er zijn drie namen in het spel geweest binnen twee frameworks, en het patroon is consistent met één enkel model dat wordt hernoemd naarmate het zijn uiteindelijke publieke naam nadert, wat die ook mag zijn. "Xing4_0" leest natuurlijk als Xingchen 4.0 — de modelfamilie heeft in het Chinees de merknaam 星辰 (Xingchen) — maar dat is nog steeds een gevolgtrekking uit de string, niet iets wat welk persbericht dan ook met zoveel woorden beweert. Het zou net zo goed kunnen dat TeleChat4 en XingChen4 siblingmodellen in dezelfde generatie zijn in plaats van één model onder twee namen, hoewel de gedeelde fork, de gedeelde architectuurparagraaf, de gedeelde FlagGems-cijfers, de gedeelde openstaande punten en nu een gedeelde hernoeming dat moeilijker maken om vol te houden. Niemand heeft de relatie bevestigd en China Telecom heeft geen commentaar gegeven. Wat is veranderd, is dat de hernoeming niet langer de keuze van één contributor is: twee onafhankelijke servingprojecten, onderhouden door verschillende mensen, hebben beide hun integratie binnen een dag na elkaar opnieuw gelabeld naar dezelfde derde naam.

De familie zelf is het waard om in het oog te houden, want die verklaart het pragmatisme. De openbare releases tot nu toe zijn onder de merknaam TeleChat uitgebracht:

• TeleChat-7B en TeleChat-12B, in januari 2024 als open source uitgebracht met een corpus van 1 biljoen tokens.

• TeleChat2-115B (september 2024), aangeprezen als het eerste volledig binnenlandse open model met een biljoen parameters, plus de 35B-, 7B- en 3B-varianten.

• TeleChat2-39B-A12B (maart 2025), de eerste MoE van de familie.

• TeleChat3-105B-A4.7-Thinking (december 2025), een fijnmazige MoE met 105B totale en 4.7B actieve parameters, getraind op 15 biljoen tokens, naast de dichte TeleChat3-36B en later TeleChat3-Coder-36B-Thinking.

Als het cijfer 29B-A4B standhoudt, zou dit model zowel qua totale als qua actieve parameters onder TeleChat3-105B-A4.7-Thinking liggen — een kleiner, goedkoper zustermodel in plaats van een vervangend vlaggenschip. Dat is een interpretatie, geen feit; geen van beide PR's zegt op welk niveau het model is gericht. Het merk Xingchen is waar het bedrijf zijn AI-inspanningen onderbrengt: het Xingchen AGI Lab werd in maart 2026 formeel opgericht in Peking, voortbouwend op dezelfde modelfamilie, en China Telecom beschrijft zijn "三全"-systeem (volledig modaal, volledig formaat, volledig binnenlands) als een systeem dat semantische, spraak-, visie- en multimodale modellen van 1B tot 1T+ parameters omvat. Een hernoeming van TeleChat naar Xingchen is precies wat een lab doet wanneer het wil dat de modelfamilie het merk van het lab draagt in plaats van het merk van de productlijn.

Wat we nog niet weten

Voor een model dat zo vroeg is, is de eerlijke lijst nog steeds langer dan de bekende lijst, hoewel die deze week op twee plekken is ingekrompen:

• Geen releasedatum. Vijf van de zes integraties zijn concepten die zijn geopend voor vroege codereview, precies omdat de gewichten niet openbaar zijn. De zesde, SGLang #39793, staat open voor review in plaats van als concept — maar deze is niet samengevoegd, alle drie de CI-runs falen en er is een reviewer nodig om deze goed te keuren. Er is geen aangekondigde planning.

• Een parameteraantal, maar slechts een beweerd aantal. Elke eerdere versie van dit stuk vermeldde de MoE-configuratie als niet bekendgemaakt. De SGLang-PR verandert dat op papier: Xing4.0-29B-A4B, 29B totaal, ongeveer 4B actief. Het cijfer komt uit een pull request, is aan geen enkele openbare checkpoint gekoppeld, wordt door geen enkel configuratiebestand bevestigd en is door niemand buiten het project gereproduceerd. Behandel het als een verklaarde intentie, niet als een specificatie.

• Geen benchmarkcijfers, hetzij door de leverancier gerapporteerd, hetzij anderszins, en geen onafhankelijke scores. De verificatietranscripten in de SGLang-PR laten zien dat het model een redeneerprompt beantwoordt en een goed gevormde toolaanroep produceert; ze tonen evenmin iets over hoe goed het daarin presteert.

• Geen prijsinformatie en geen bevestigde licentie. Elke eerdere TeleChat-release is Apache-2.0, wat bemoedigend is, maar voor deze is geen licentie vermeld.

• Geen openbare gewichten — bevestigd, niet aangenomen. Met ingang van 16 september 2026 is het Hugging Face-pad dat de SGLang-PR noemt niet openbaar leesbaar, en de organisatie waarnaar het verwijst vermeldt geen openbare modellen; de nieuwste openbare vermelding in de familie is TeleChat3-Coder-36B-Thinking van januari. De tabel met ondersteunde modellen van vLLM vermeldt TBA in de checkpointkolom, die van SGLang zegt 'binnenkort beschikbaar', en beide SGLang-PR's hebben een falende openbare CI.

• Geen officieel bericht van China Telecom — geen aankondiging, geen modelgewichten, geen bevestiging van de naam of de omvang. Let goed op de asymmetrie: de SGLang-documentatieregel schrijft het model toe aan China Telecom, maar dat is de beschrijving van een bijdrager in een pull request, geen verklaring van het bedrijf, en de nieuwste PR-beschrijving laat de naam van de leverancier helemaal weg. Zes integraties die voor dit model worden gebouwd, zijn het sterkste bewijs tot nu toe dat het echt bestaat, maar integraties worden gesloten en codenamen veranderen; twee zijn er al gesloten. Niets is bevestigd totdat het lab het zegt.

De juiste interpretatie van dit alles is geen scepticisme over het model; het is een accuraat beeld van een vroeg signaal. Wat vandaag bestaat, is een echt engineering-artefact — zes ervan, verspreid over twee frameworks — met een echte architectuur en, voor het eerst, een aangegeven vorm die eraan is verbonden. Wat nog niet bestaat, is iets dat je kunt downloaden, aanroepen of benchmarken.

Het dichtstbijzijnde dat je vandaag kunt draaien

Dit model kan nergens worden geserveerd — niet via een API, niet lokaal, omdat de gewichten niet openbaar zijn. Het dichtstbijzijnde model dat een lezer vandaag daadwerkelijk kan aanroepen en dat hetzelfde architecturale DNA deelt, is DeepSeek V4 Flash, dat hetzelfde mHC-residuele schema bovenop MLA en MoE gebruikt, en het is de referentie-implementatie waarvoor de gedeelde mHC-modules in beide frameworks zijn gebouwd. OrcaRouters modelpagina voor deepseek/deepseek-v4-flash vermeldt een context van 1M tokens, een maximale output van 384K en een lijstprijs van $0,15 per miljoen inputtokens en $0,29 per miljoen outputtokens — dezelfde cijfers die DeepSeek zelf publiceert, doorgegeven met 0% markup, dus een prijswijziging van een leverancier is hier dezelfde dag live. Eén API-sleutel dekt de catalogus, waardoor het vergelijken ervan met de rest van de reasoning-tier een routeringsregel wordt in plaats van een nieuwe integratie.

Dat is ook het praktische antwoord op "hoe probeer ik dit model uit zodra het uitkomt." Een gloednieuw, onbewezen checkpoint is precies waar automatische failover zijn nut bewijst: routeer een fractie van het verkeer erheen, houd een bewezen model als fallback, en laat de routeringslaag de beslissing nemen in plaats van een productiepad te verwedden op gedrag op dag één. Een 29B MoE met ruwweg 4B actieve parameters, als dat is wat er komt, is iets goedkoops om tegen een frontier-model te routeren, precies omdat zo weinig ervan per token activeert. Als de naam weer verandert tussen nu en de release — en de afgelopen zes weken suggereren dat dat zou kunnen — dan is de routeringsregel wat je herschrijft, niet de integratie.

Veelgestelde vragen

Waarom is de vLLM-PR gesloten?

We kunnen de sluiting zien, niet de reden. #54051 werd op 7 september 2026 door de auteur zelf gesloten zonder te zijn samengevoegd, en het werk dook negen dagen later weer op als #57135 onder een nieuwe naam. Een eerdere vLLM-PR, #51237, werd dezelfde dag gesloten en opnieuw ingediend onder dezelfde titel, dus sluiten en opnieuw indienen is een patroon van deze auteur in plaats van een teken van problemen — maar de PR-beschrijvingen vermelden geen reden en we gaan er geen verzinnen.

Wanneer wordt Xing4_0 uitgebracht?

Er is geen datum. Vijf van de zes integraties zijn concepten die zijn geopend voor vroege code review, en de eigen plannen van de auteurs zijn om testvermeldingen toe te voegen, documentatie bij te werken en de PR's pas als klaar te markeren zodra de gewichten zijn vrijgegeven. De oudere checklist van SGLang is de duidelijkste weergave van de stand van zaken: "Model laadt en genereert (lokaal, op interne gewichten)" is aangevinkt, en publieke CI is "geblokkeerd in afwachting van de vrijgave van gewichten." De nieuwere SGLang-PR is ingediend als klaar voor review in plaats van als concept, wat een verandering in houding is, niet in status — hij is niet samengevoegd, zijn CI is rood, en een documentatieregel met "binnenkort beschikbaar" is geen lancering.

Is Xing4_0 hetzelfde model als XingChen4?

Vrijwel zeker ja, en de PR's maken het gemakkelijk om te controleren: dezelfde fork-afstamming, dezelfde architectuurparagraaf, dezelfde benchmarkcijfers van FlagGems, dezelfde openstaande punten, en een hernoeming per bestand in beide frameworks — xingchen4.py naar xing4_0.py, inclusief de config-klasse, op branches die overeenkomstig zijn hernoemd. Het is hetzelfde werk onder een nieuwe naam, en sinds 16 september hebben zowel vLLM als SGLang die naam overgenomen. Wat geen enkele PR vermeldt, is welke naam een uitgebrachte checkpoint zal dragen.

Is dit een Deep​Seek-model?

Nee. Het is het model van China Telecom, van het Xingchen AGI Lab. De DeepSeek-connectie is architecturaal: het hergebruikt de DeepSeek-V2/V3-backbone en het mHC-residuele schema dat DeepSeek voorstelde en in V4 uitbracht. Het overnemen van iemands architectuur is niet hetzelfde als dat de twee projecten verwant zijn.

Wat nu te kijken

De PR's geven nog steeds een concrete checklist, en het paar van 16 september voegde er twee items aan toe. Ten eerste, de gewichten: elke auteur heeft gezegd dat hun werk wacht op Hugging Face, dus het verschijnen van een publieke repository is de dragende gebeurtenis — en de SGLang-PR geeft je nu het exacte pad om in de gaten te houden, XingChen-AGI/Xing4.0-29B-A4B, dat momenteel voor niemand resolveert. Ten tweede, de PR's zelf: die van vLLM vereist dat de mHC-biasformules worden bevestigd, dat de registry-testentry wordt toegevoegd en dat zijn CI groen is; SGLang's #39793 vereist dat zijn drie rode runs worden gerepareerd en dat zijn tien gevraagde reviewers goedkeuren, terwijl de oudere #37228 nog steeds zijn testentry, zijn MTP-versnellingsbenchmark en een niet-geblokkeerde CI nodig heeft. Ten derde, en nieuw deze week: of SGLang #37228 sluit ten gunste van #39793, zoals vLLM altijd een voorganger heeft gesloten voordat het opnieuw indient. Twee live integraties voor één onuitgebracht model is een toestand die niemand lang volhoudt, en welke ervan overleeft, zegt iets over hoe dichtbij dit werkelijk is. Ten vierde, de cijfers: of een vrijgegeven checkpoint overeenkomt met de 29B-A4B-vorm, de MoE met 64 experts en de context van 262,144 tokens die de config en de PR-beschrijving nu beweren. Ten vijfde, of de derde vLLM-PR langer overleeft dan zijn twee voorgangers, die respectievelijk 21 en 11 dagen standhielden voordat ze werden gesloten zonder te mergen. En let op of de reasoning-parsers een aparte Thinking-variant beschrijven, zoals TeleChat3 er een uitbracht.

Totdat een van die dingen gebeurt, behandel dit model als wat het is: een goed gespecificeerd plan van een serieus lab, betrapt op het voorbereiden van zijn serving-infrastructuur — nu in beide grote open-source servingstacks, onder een naam die beide hebben overgenomen en een omvang die alleen zijn eigen pull request vermeldt. Alleen al de architectuur maakt het de moeite waard om te volgen: het is de tweede grote adoptie van mHC na DeepSeek zelf, van een lab waarvan de vorige generatie al een fijnmazige MoE was die op binnenlandse chips was getraind. Zodra de gewichten vrijkomen, zal er geen twijfel over bestaan of het in vLLM of SGLang draait. Beide stacks hebben de code maar liefst drie keer geschreven, onder drie verschillende namen.