Xing4_0 erreicht SGLang: Ein sechster PR und die erste angegebene Größe für das nächste MoE von China Telecom

Mit zwei Stunden Abstand, am 16. September 2026, hörten die beiden dominierenden Open-Source-Serving-Stacks auf, sich über den Namen uneinig zu sein. vLLM reichte am Morgen „[Model] Add Xing4_0 support“ ein; sgl-project/sglang folgte um 10:38 UTC mit „feat: add Xing4_0 model support“, und nach sechs Wochen, in denen drei Namen im Spiel waren, sagen beide Frameworks nun Xing4_0. Der SGLang-Pull-Request enthält etwas, das kein früherer hatte: eine Größe. Er beschreibt das Modell als Xing4.0-29B-A4B, ein „29B-Parameter-MoE mit ~4B aktivierten Parametern“, und gibt einen Startbefehl an, der einen Checkpoint-Pfad, einen Kontext von 262.144 Token und EAGLE-Speculative-Decoding nennt. Dies ist das unveröffentlichte MoE von China Telecom, dasselbe, um das die XingChen4-Pull-Requests seit August kreisen, und es bleibt unveröffentlicht: Die Gewichte sind nicht öffentlich, der im PR genannte Checkpoint-Pfad ist für niemanden außerhalb des Projekts auflösbar, kein Anbieter hat den Namen oder die Zahl bestätigt, und nichts in diesem Artikel ist unabhängig verifiziert. Fakten aus Pull-Requests sind als solche gekennzeichnet; der Rest ist Geschichte und Schlussfolgerung. Das nächstgelegene Modell, das Sie heute tatsächlich aufrufen können, ist DeepSeek V4 Flash.

Dies ist ein Was-wir-bisher-wissen-Beitrag, der auf dem Laufenden gehalten statt von vorn begonnen wird. Er behandelt den sechswöchigen PR-Verlauf und wie die Namensfrage geklärt wurde, was die beiden Pull Requests vom 16. September tatsächlich hinzufügen, die Architektur, die die Konfigurationsdateien nun in echter Detailtiefe preisgeben, und worauf als Nächstes zu achten ist. Die Ein-Satz-Version: Das nächste MoE von China Telecom ist real genug, um sechs Serving-Integrationen, eine mit TBA markierte Tabellenzeile in vLLM, einen mit „coming soon“ markierten Docs-Eintrag in SGLang und eine angegebene Parameteranzahl angesammelt zu haben — und dennoch nicht real genug, um irgendwo zu laufen, wo Sie darauf zugreifen können.

Das Signal: sechs Integrationen, drei Namen, sechs Wochen

Die Spur beginnt früher als die zuerst gemeldete Fassung dieses Artikels, und ihr Commit-Log ist nach wie vor das aufschlussreichste Artefakt des Leaks. Der erste vLLM-PR war #51237, eröffnet am 6. August 2026 unter dem Titel „[WIP][Model] Unterstützung für das kommende XingChen4-Modell hinzufügen“. Seine drei Commits erzählen die Geschichte von selbst. Der erste trägt den Titel „Unterstützung für das TeleChat4-Modell hinzufügen“. Der zweite, nur etwas mehr als eine Stunde später, lautet „chore: verfrühte Docs und Testeintrag für telechat4 zurücksetzen“ – die Dokumentation und der Registry-Testeintrag wurden als verfrüht wieder entfernt. Der dritte, am 27. August, lautet „xingchen4 umbenennen“. Eine Minute später wurde der PR ohne Merge geschlossen, und elf Minuten danach #54051 wurde mit demselben Titel, demselben Fork-Branch (supported_telechat4) und einem einzigen Squash-Commit eröffnet. Zwischenzeitlich war ein needs-rebase-Label gesetzt worden, daher liest sich das wie ein Schließen und Wiedereröffnen nach einer Bereinigung und nicht wie eine Meinungsänderung. Alles wurde vom GitHub-Konto zyp2014 eingereicht, wobei jeder Commit von zhangyp26 <zhangyp26@chinatelecom.com.cn> verfasst und mit Sign-off versehen wurde.

Der zweite PR ist derjenige, um den herum dieser Beitrag ursprünglich aufgebaut wurde, und er ist nicht mehr offen. #54051 wurde am 7. September 2026 von seinem eigenen Autor ungemergt geschlossen. Seine Beschreibung ist dennoch zitierenswert, denn sie ist der Satz, der jede Umbenennung und jede Wiedereröffnung überlebt hat:

Die Modellgewichte sind noch nicht öffentlich auf dem Hugging Face Hub. Dieser PR wurde für ein frühes Code-Review eröffnet. Sobald die Gewichte veröffentlicht sind, werde ich einen Testeintrag in tests/models/registry.py hinzufügen, docs/models/supported_models.md aktualisieren und den PR als bereit für die Review markieren.

Dieser Satz ist die Form der gesamten Geschichte: Der Code ist den Gewichten voraus. Der Screenshot unten zeigt die Seite #54051 in dem Zustand, in dem sie am 27. August 2026 stand, dem Tag, an dem sie geöffnet wurde – eine datierte Momentaufnahme, die aufbewahrt wurde, weil der darin gezeigte Pull Request inzwischen geschlossen wurde. Lies sie als Aufzeichnung des Signals von jenem Moment, nicht als Auskunft über ihren heutigen Status.

Dann, am 16. September, wiederholte sich das Muster – zweimal an einem Tag. #57135, „[Modell] Xing4_0-Unterstützung hinzufügen“, wurde an diesem Morgen vom selben Konto, zyp2014, mit einem einzigen Commit geöffnet, der nun von einem anderen China-Telecom-Ingenieur stammte – xiongji <xiongj9@chinatelecom.cn>. Elf Dateien geändert, etwa 1.300 Einfügungen, durchgängig ein neuer Name und derselbe Vorbehalt an derselben Stelle: „Die Modellgewichte sind noch nicht öffentlich auf Hugging Face Hub.“

Zwei Stunden und zwanzig Minuten später lag der andere Serving-Stack nicht mehr um eine Umbenennung zurück. sgl-project/sglang #39793, „feat: Unterstützung für das Modell Xing4_0 hinzufügen“, wurde eröffnet aus einem Branch namens support_xing4_0, und sein einzelner Commit trägt dieselbe xiongji-Adresse wie die vLLM-Umbenennung. Vierzehn Dateien und etwa 1.400 Einfügungen, von denen etwas mehr als tausend auf eine einzige Modelldatei entfallen. Es ist die sechste Integration, die für dieses Modell innerhalb von sechs Wochen eingereicht wurde, und die erste, die nicht als Entwurf eingereicht wurde: GitHub listet sie als offen und bereit zur Überprüfung, mit zehn angeforderten Reviewern — und alle drei ihrer CI-Läufe sind bereits rot.

Bis heute lief die SGLang-Seite so, wie es die von vLLM tat. #33982, „feat(model): add TeleChat4 model support“, wurde am 7. August 2026 vom Contributor PaddyXj geöffnet und am 31. August ohne Merge geschlossen — am selben Tag, an dem #37228, „feat: add XingChen4 model support“, an seiner Stelle geöffnet wurde. Dieser ist weiterhin als Draft unter PaddyXj offen, auf einem Branch namens support_xingchen4, mit drei Commits und zuletzt am 8. September bearbeitet. Seine Checkliste ist das Interessanteste in beiden Frameworks: Das Modell lädt und generiert „lokal, auf internen Gewichten“ ist angehakt, Tool-Calling ist angehakt, Reasoning-Parsing ist angehakt — und öffentliche CI ist nicht angehakt, weil sie „durch die Veröffentlichung der Gewichte blockiert“ ist. Jemand hat einen Checkpoint. Niemand hat ihn veröffentlicht. Und anders als bei vLLM, wo jede erneute Einreichung zuerst ihren Vorgänger schloss, hat SGLang jetzt zwei offene Pull Requests für dasselbe Modell, unter zwei verschiedenen Namen.

Was sechs Integrationen in sechs Wochen ergeben, ist keine stärkere Version desselben Signals; es ist ein anderes. Sechs Integrationen wären mit einem Team vereinbar, das iteriert. Sechs Integrationen unter drei Namen – TeleChat4, XingChen4, Xing4_0 – sind ein Team, das öffentlich am Namen iteriert, unter dem das Modell erscheinen soll, während die Gewichte privat bleiben. Das ist eine nicht verifizierte Schlussfolgerung, und sie ist das folgenreichste, was die PR-Spur nun zeigt.

Was die beiden September-PRs tatsächlich hinzufügen

Der vLLM-Pull-Request ist eher eine Umbenennung der August-Arbeit als eine Neufassung davon. Die Modelldatei ist jetzt vllm/model_executor/models/xing4_0.py, die Klasse ist Xing4_0ForCausalLM, und der model_type xing4_0 ist DeepseekV3Config zugeordnet – dieselbe DeepSeek-V3-Konfiguration, die die XingChen4-Version verwendet hat. Was er mit sich bringt:

• Eine vollständige Modellimplementierung in vllm/model_executor/models/xing4_0.py — Klasse Xing4_0ForCausalLM, mit Forward-Pass, einem mHC-Adapter und einer tensorparallelen load_weights()-Implementierung. Die Commit-Nachricht vermerkt, dass sowohl DSA- als auch Nicht-DSA-Varianten unterstützt werden, wobei die gemeinsamen mhc_pre / mhc_post-Operationen wiederverwendet werden.

• Registrierung von Xing4_0ForCausalLM in vllm/model_executor/models/registry.py, damit vLLM die Architektur anhand des Namens kennt.

• Einen Reasoning-Parser (vllm/reasoning/xing4_0_reasoning_parser.py) „für reasoning-fähige Varianten“ und einen Tool-Parser (vllm/tool_parsers/xing4_0_tool_parser.py) für automatisches Tool-Calling.

• Registrierung in vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py und vllm/transformers_utils/config.py — mit der Commit-Nachricht, die besagt, dass ein Deep​Seek-V3-kompatibler MTP-Head für die spekulative Dekodierung aktiviert ist.

• Zwei Dokumentationsdateien – der wirklich neue Teil und eine direkte Umkehrung des August. Der ursprüngliche Commit enthielt einen Doku- und Test-Eintrag, der eine Stunde später als verfrüht zurückgenommen wurde; der September-PR fügt die Dokumentation wieder ein und ist mit documentation, new-model und tool-calling gekennzeichnet.

Die vLLM-Dokumentationseinträge sind der Ort, an dem ein Leser zum ersten Mal etwas Konkretes erfuhr. In docs/models/supported_models.md steht in der neuen Zeile `Xing4_0ForCausalLM` | Xing4_0 | TBA — in der Checkpoint-Spalte steht buchstäblich TBA, was dasselbe „noch nicht“ in einer anderen Schriftart ist. Und in docs/features/tool_calling.md dokumentiert der PR unter der Überschrift „Xing4_0 Models (xing4_0)“ das Tool-Aufruf-Format des Modells: Aufrufe werden in <tool_call>...</tool_call>-Blöcken ausgegeben, entweder als JSON ({"name": ..., "arguments": {...}}) oder als tagbasierte Form mit <param_key>...</param_key> und <param_value>...</param_value>. Das ist ein Maß an Spezifität, das die früheren PRs nicht erreicht haben — ein Implementierungsdetail des Chat-Formats des Modells, niedergeschrieben in der öffentlichen Dokumentation eines großen Frameworks, für einen Checkpoint, den niemand herunterladen kann.

Der SGLang-PR ist interessanter, weil er eine Implementierung und eine Konfiguration mitbringt statt eines Registry-Eintrags plus Docs. Seine Dokumentationszeile ist das erste Mal, dass ein Framework den Namen des Anbieters in seine eigenen Docs aufnimmt. In docs/docs/supported-models/generative_models.mdx enthält die neue Zeile Xing4_0, wobei in der Checkpoint-Spalte `Xing4_0` (demnächst verfügbar) steht und eine Beschreibung: "China Telecoms MoE-Modell mit MLA-Attention und mHC-(Manifold-constrained Hyper-Connection)-Residual-Streams; unterstützt natives MTP-Speculative-Decoding, Tool-Calling und Reasoning." In der Zeile von vLLM stand TBA, und es wurde kein Anbieter genannt; die von SGLang nennt China Telecom und gibt demnächst verfügbar an. Keines von beiden ist ein Veröffentlichungsdatum, und eine Zeile in den Docs eines Frameworks ist kein Produkt.

Die PR-Beschreibung ergänzt die Zahl, die in jeder vorherigen Version dieser Geschichte fehlte. „Dieser PR fügt Unterstützung für Xing4.0-29B-A4B hinzu (29B-Parameter-MoE mit ~4B aktivierten Parametern).“ Sie nennt außerdem einen Startbefehl — --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 — und gibt an, dass die Konfiguration mit Tensor-Parallelität 2, einem Kontext von 262.144 Token und EAGLE-MTP-Spekulativdecodierung verifiziert wurde, wobei Transkripte einer Reasoning-Antwort und eines get_weather-Tool-Aufrufs als Beleg in die Beschreibung eingefügt wurden. Die Gewichte hinter dieser Verifizierung sind die eigenen des Autors: Der im PR genannte Repository-Pfad ist nicht öffentlich lesbar, und die Hugging-Face-Organisation, auf die er verweist, führt überhaupt keine öffentlichen Modelle auf. Betrachten Sie die Größe, die Kontextlänge und die Transkripte als vom PR gemeldete Behauptungen, die an einen privaten Checkpoint geknüpft sind, nicht als Messungen, die irgendjemand wiederholen kann. All dies stammt aus dem Pull Request und ist nicht reproduziert.

Dass Reasoning- und Tool-Parser unter beiden Namen auftauchen, ist aus demselben Grund wichtig wie im August. Ein Reasoning-Parser existiert, um Denk-Marker aus der Ausgabe eines Modells zu entfernen – die interne Gedankenkette, die ein Modell vor seiner finalen Antwort ausgibt. Ein eigens für dieses Modell gebauter Parser bedeutet, dass die Familie voraussichtlich reasoning-fähige Varianten haben wird, so wie TeleChat3 Thinking-Editionen veröffentlicht hat. Der Tool-Parser plus das nun dokumentierte Call-Format bedeutet, dass auch natives Function Calling zu erwarten ist. Keines von beiden ist eine Garantie für das Endprodukt; beide sind die stärksten Hinweise, die die PRs darauf geben, worauf China Telecom abzielt.

Was wir bisher wissen, auf einen Blick

Die unten stehende Ergebnistafel ist diejenige, die für diesen Beitrag am 27. August 2026 aus dem vLLM-PR in seinem damaligen Stand zusammengestellt wurde. Sie wird hier bewusst als datierter Schnappschuss belassen, statt neu gezeichnet zu werden, weil jede ihrer Zeilen auch drei Wochen später noch zutrifft — unveröffentlicht, Gewichte nicht öffentlich, DeepSeek-Backbone, mHC-Residual, beide Parser enthalten. Geändert hat sich nicht ein Wert auf der Tafel, sondern alles um sie herum: Der vLLM-PR, den sie zitiert, wurde am 7. September geschlossen, die Arbeit tauchte am 16. September unter neuem Namen wieder auf, SGLang folgte der Umbenennung Stunden später, und die erste angegebene Parameterzahl kam mit ihr. Nichts auf der Tafel ist falsch. Sie ist einfach drei Wochen alt, und die Geschichte ist über sie hinweggegangen. Die FlagGems-Zahlen in ihrer letzten Zeile wurden unverändert in den neuen vLLM-PR übernommen, weiterhin nur im PR angegeben und weiterhin nicht reproduziert.

Die Architektur, die die PRs durchsickern lassen.

Das Umbenennen einer Datei benennt keine Architektur um, und der Zusammenfassungstext im vLLM-PR vom September ist der August-Text, bei dem XingChen4 durch Xing4_0 ersetzt wurde – Klausel für Klausel. Zwei Sätze tragen das Signal:

• "Xing4_0 verwendet das Deep​Seek-V2/V3-Backbone wieder (MLA-Attention, MoE-Block, optionaler DSA-Indexer)."

Es ersetzt die standardmäßige Residualverbindung durch mannigfaltigkeitsbeschränkte Hyper-Verbindungen (mHC): Der Residualstrom wird auf num_residual_streams parallele Ströme erweitert, die durch eingabeabhängige, doppelt-stochastische Matrizen gemischt werden; diese werden mittels Sinkhorn-Knopp-Projektion erzeugt.

Jede Klausel entspricht etwas Konkretem. MLA steht für Multi-head Latent Attention, das komprimierte Attention-Schema, das DeepSeek in V2 eingeführt hat und das den KV-Cache klein hält; MoE ist Mixture-of-Experts-Routing, das eine große Parameteranzahl bei geringem aktivem Fußabdruck beibehält. Der optionale DSA-Indexer ist der DeepSeek Sparse Attention-Mechanismus aus der V3.2-Linie — ein leichtgewichtiges Scoring-Modul, das die Top-k-Token auswählt, die beachtet werden sollen, und damit die Attention-Kosten von quadratisch auf ungefähr linear mit der Kontextlänge senkt. Und der mHC-Satz ist die Schlagzeile: Dieses Modell übernimmt die Residualarchitektur, die DeepSeek selbst erst in dieser Generation eingeführt hat.

Der SGLang-PR ist der erste, der die Form der Sache veröffentlicht, statt sie zu beschreiben. Seine Konfigurationsdatei python/sglang/srt/configs/xing4_0.py deklariert 40 Hidden Layers, eine Hidden Size von 3.584 und ein Vokabular von 131.072 Tokens; MLA mit einem KV-LoRA-Rang von 512 und einem Query-LoRA-Rang von 768 über 32 Heads; sowie ein sparse MoE mit 64 gerouteten Experten plus einem geteilten Experten, Top-4-Routing, Sigmoid-Scoring, einem gerouteten Skalierungsfaktor von 2,0 und noaux_tc-Expertenauswahl. Die mHC-Felder sind ebenfalls explizit: hc_mult 4, zwanzig Sinkhorn-Knopp-Iterationen, ein h_res-Clamp bei plus oder minus 30 und ein rope_theta von 10.000 mit einem maximalen Positions-Embedding von 262.144. Dies sind die Standardwerte in einer Integration, die noch nicht ausgeliefert wurde, dem Pull Request zufolge — eine Konfigurationsdatei ist eine Absichtserklärung, keine Modellkarte, und die 29B-A4B-Angabe in der PR-Beschreibung wird nirgends öffentlich aus ihnen abgeleitet.

Ein Feld ist mehr wert als alle übrigen, denn es ist die erste Stelle, an der dieses Modell sichtbar aufhört, eine Kopie von Deep​Seek zu sein. Die SGLang-Konfiguration setzt hc_contract_for_draft, wodurch die mHC-Ströme wieder auf die eigene Hidden-Size des Modells zurückgeführt werden, bevor die abschließende Norm erfolgt, und diesen kontrahierten Tensor dem Eagle-Draft-Head zuführt. DeepSeek V4 führt stattdessen den mHC-flachgelegten n-mal-hidden_size-Tensor zu. Der Kommentar in der Konfiguration sagt das ausdrücklich, und es ist die Art von Detail, die erst zutage tritt, wenn eine Implementierung gegen einen echten Checkpoint geformt wurde – was die Checkliste des früheren SGLang-PR für sich beansprucht, ohne sie zu veröffentlichen.

Die mHC-Mathematik ist der Punkt, an dem die beiden Stacks in der Implementierung auseinandergehen und in der Annahme übereinstimmen. Die vLLM-PR merkt an, dass sie „mit den gemeinsamen Ops in vllm.model_executor.layers.mhc übereinstimmt, sodass keine privaten Kernel eingeführt werden“ — dieses Modul existiert, weil vLLM mHC für DeepSeek V4 bereits unterstützt, sodass der inkrementelle Aufwand für das Hinzufügen dieses Modells gering ist. SGLang erreicht denselben Punkt auf einem anderen Weg: Sein mHC-Modul verwendet fusionierte TileLang-Kernel, die als benutzerdefinierte Torch-Ops registriert sind, und die PR erweitert den vorhandenen mhc_pre-Split-K-Kernel, um hc_hidden_size 14.336 neben den beiden Größen zu akzeptieren, die er bereits verarbeitete. Außerdem wird der tf32_hc_prenorm_gemm-Pfad von DeepGEMM für diese Architektur deaktiviert, weil dieser Pfad eine reine C-Erweiterung ist, die torch.compile nicht verfolgen kann; mHC fällt stattdessen auf den TileLang-Kernel zurück. Der praktische Vorteil ist in beiden Frameworks derselbe: Wenn Sie DeepSeek V4 heute auf vLLM oder SGLang bedienen, ist die Maschinerie, die das nächste MoE von China Telecom bedienen wird, bereits installiert.

mHC, der DeepSeek-Trick, um den sich alles dreht

Es lohnt sich, Manifold-constrained Hyper-Connections auseinanderzunehmen, denn sie sind das mit Abstand Interessanteste an diesem Modell – und sie sind nicht die Erfindung von China Telecom. Sie sind die von Deep​Seek.

Die Geschichte beginnt mit Hyper-Connections, die 2024 vom Kimi-Team vorgeschlagen wurden. Ein Standard-Transformer behält einen einzigen Residual-Stream pro Schicht bei: Die Eingabe wird zur Ausgabe der Schicht addiert, was den Gradienten einen sauberen Pfad gibt und das Netzwerk eine Residuenkorrektur lernen lässt. Hyper-Connections ersetzt diesen einzelnen Stream durch mehrere parallele Streams, die in jeder Schicht durch gelernte Matrizen gemischt werden, wodurch das Modell einen viel reicheren Pfad für den Informationsfluss erhält. Der Haken ist die Stabilität: Uneingeschränkte Mischmatrizen brechen die Identitätsabbildungseigenschaft, die Residualverbindungen trainierbar macht, und bei Billionen-Parameter-Skala wird der Trainingsverlust instabil.

DeepSeeks Beitrag, im Dezember 2025 als mHC-Paper veröffentlicht und anschließend in DeepSeek V4 verwendet, bestand darin, die Mischmatrizen auf doppelt stochastisch zu beschränken – nichtnegativ, wobei die Summe jeder Zeile und jeder Spalte eins ist –, erzwungen durch Sinkhorn-Knopp-Projektion während des Trainings. Eine doppelt stochastische Matrix hat einen Spektralradius von genau eins, sodass Signale beim Durchlaufen von Hunderten von Schichten nicht exponentiell verstärkt oder abgeschwächt werden können. Diese Schranke hält das Training im großen Maßstab stabil, und die Projektion ist so günstig, dass DeepSeek bei vier Residual-Streams nur etwa 6,7 % Trainings-Overhead berichtete. DeepSeek V4, veröffentlicht am 24. April 2026, ist die Flaggschiff-Anwendung davon, mit einem berichteten Leistungszuwachs von rund 15 % bei Mathematik-Reasoning-Aufgaben und obendrein einem Kontext von 1 Mio. Token.

Was diese PRs also in einfachen Worten sagen, ist: China Telecoms nächstes Modell übernimmt Deep​Seeks bewährtes Rückgrat und Deep​Seeks neuesten Residualmechanismus, statt eines der beiden von Grund auf neu zu erfinden. Das ist eine pragmatische Entscheidung, und sie trägt eine subtile Bestätigung in sich – das zweite große Labor nach Deep​Seek selbst, das mHC übernimmt, glaubt, dass der Trick produktionsreif ist.

Die PRs sind mit mHC noch nicht fertig, und die offenen Punkte geben das ehrlich zu. In den vLLM-PRs merkt der Autor an, dass die Checkpoint-Biases (bias_pre, bias_post, bias_res) und ein h_res-Clamp derzeit zusammengeführt oder ausgelassen werden, und dass die Bestätigung der Formeläquivalenz durch Reviewer „die zentrale Korrektheitsfrage“ ist. Außerdem gibt es eine benutzerdefinierte Transpose-Op, die einen Tensor für einen TileLang-Kernel C-contiguous hält – zusammen mit allem anderen umbenannt, von _xingchen4_transpose_contiguous zu _xing4_0_transpose_contiguous –, und eine harte Einschränkung: Pipeline-Parallelität wird im mHC-Modus nicht unterstützt, wenn num_residual_streams größer als eins ist, während Tensor-Parallelität unterstützt wird. Nichts davon ist für einen Entwurf überraschend, aber es ist dieselbe unfertige Stelle wie im August, was selbst aufschlussreich ist: Sechs Wochen voller Umbenennungen haben die Korrektheitsfrage nicht bewegt, und die drei roten CI-Läufe im neuesten SGLang-PR sind dieselbe Geschichte in einer anderen Farbe. Was die SGLang-Konfiguration tatsächlich klärt, ist die Anzahl der Streams. Mit hc_mult auf 4 gesetzt und einer Hidden Size von 3.584 sind die 14.336 im Kernel-Patch genau vier Streams – und der Kernel-Kommentar sagt das mit genau diesen Worten. Diese Lesart war eine Schlussfolgerung aus einer bloßen Zahl, als dieser Beitrag zuerst erschien; jetzt ist sie in einer Config-Datei festgehalten.

Der Beschleunigungswinkel: FlagGems, wieder.

Ein zweiter Faden verbindet dieses Modell mit der bestehenden Beziehung von China Telecom zur Beijing Academy of Artificial Intelligence, und es ist der eine Faden, der jede Umbenennung unversehrt überstanden hat. Der vLLM-PR ermöglicht eine optionale FlagOS/FlagGems-Beschleunigung hinter einem USE_FLAGOS-Umgebungsflag, standardmäßig deaktiviert, und setzt dabei Hot-Path-Kernel für MoE, Attention, Softmax und Top-k ein. Der behauptete Nutzen, aus dem H100-Benchmark des PR-Autors auf einer hochgradig nebenläufigen Long-Prompt-Workload (über 10K Input-Tokens, Nebenläufigkeit 10): bis zu 19,87 % kürzere Time-to-First-Token und bis zu 26,32 % kürzere Time-per-Output-Token, wobei andere Workloads neutral bleiben. Diese Zahlen sind im PR angegeben und nicht reproduziert, und sie gehen mit einem standardmäßig deaktivierten Flag einher.

Bemerkenswert ist, wie wenig die Umbenennung verändert hat. Der vLLM-PR vom September enthält dieselben Zahlen, dieselbe eng gefasste Anmerkung zum Geltungsbereich, dass das Flag nur innerhalb der Modelldatei lebt, und dieselbe Anweisung, flagtree und flag-gems zu installieren. Die Zahlen haben sich nicht geändert, weil sich der Code nicht geändert hat; nur die Bezeichnung hat sich geändert. Die SGLang-Pull-Requests enthalten überhaupt keinen FlagGems-Thread – sie nehmen stattdessen die TileLang- und DeepGEMM-Route –, was dies zu einer Auseinandersetzung darüber macht, wer die Optimierung der Serving-Schicht besitzt – und nicht zu einer über das Modell.

Dies ist eine Fortsetzungsgeschichte. TeleChat3-36B-Thinking war Stand April 2026 das erste große Modell, das unabhängig auf FlagOS portiert wurde, den quelloffenen KI-Software-Stack von BAAI. In welcher Form auch immer dieses Modell ausgeliefert wird – die Fortsetzung dieses Fadens, mit FlagGems-Kernels innerhalb seiner eigenen vLLM-Integration, zeigt, dass die Domestic-Stack-Strategie des Labors bis in die Serving-Schicht reicht, nicht nur auf das Training.

Die Namensfrage und die Familie, aus der sie stammt

Bis zum 16. September war die Namensfrage eine Randnotiz. Jetzt ist sie beinahe geklärt, und die Belege stecken noch immer ausschließlich in Branch-Namen und übrig gebliebenen Strings statt in Statements – doch die beiden Frameworks sind aus derselben Richtung zur selben Antwort gelangt.

• Die Commit-Nachrichten, in dieser Reihenfolge: „TeleChat4-Modellunterstützung hinzufügen“, dann „chore: vorzeitige Doku- und Test-Einträge für telechat4 rückgängig machen“, dann – drei Wochen später und eine Minute, bevor der PR geschlossen wurde – „xingchen4 umbenennen“. Ein Commit, dessen einziger Zweck die Umbenennung war.

• Die Fork-Branches. Die ersten beiden vLLM-PRs, #51237 und #54051, wurden von zyp2014:supported_telechat4 abgezweigt. Der dritte, #57135, ist zyp2014:support_xing4_0. Der Branch wurde in derselben Aktion umbenannt, in der auch das Modell umbenannt wurde — und die SGLang-Seite hat nun denselben Weg in drei Schritten zurückgelegt, von support_telechat4 über support_xingchen4 bis support_xing4_0.

• Der Fließtext von #51237, in dem es hieß, die FlagGems-Beschleunigung sei „für TeleChat4“ gewesen, während genau derselbe Absatz das Modell XingChen4 nannte. Die beiden Namen kollidierten bereits in der eigenen Zusammenfassung des Autors vom 6. August.

• Die Umbenennung Datei für Datei auf beiden Seiten. In vLLM war es xingchen4.py zu xing4_0.py und XingChen4ForCausalLM zu Xing4_0ForCausalLM; in SGLang ist es xingchen4.py zu xing4_0.py und XingChen4Config zu Xing4_0Config, auf einem Branch, der zusammen damit umbenannt wurde. Keiner der beiden PRs ließ den alten Namen irgendwo in seinem Diff zurück.

Also waren drei Namen über zwei Frameworks hinweg im Spiel, und das Muster passt zu einem einzelnen Modell, das umbenannt wird, während es sich dem nähert, was auch immer sein öffentlicher Name sein wird. „Xing4_0“ liest sich ganz natürlich als Xingchen 4.0 – die Modellfamilie trägt auf Chinesisch den Markennamen 星辰 (Xingchen) –, aber das ist weiterhin eine Schlussfolgerung aus der Zeichenkette, nicht etwas, das irgendeine PR-Mitteilung ausdrücklich sagt. Es könnte genauso gut sein, dass TeleChat4 und XingChen4 Geschwister in derselben Generation sind, statt dass es sich um ein Modell unter zwei Namen handelt, obwohl der gemeinsame Fork, der gemeinsame Architekturabsatz, die gemeinsamen FlagGems-Zahlen, die gemeinsamen offenen Punkte und nun eine gemeinsame Umbenennung es schwerer machen, das zu argumentieren. Niemand hat die Beziehung bestätigt, und China Telecom hat sich nicht geäußert. Was sich geändert hat, ist, dass die Umbenennung nicht mehr die Wahl eines einzelnen Mitwirkenden ist: Zwei unabhängige Serving-Projekte, die von unterschiedlichen Personen gepflegt werden, haben beide mit höchstens einem Tag Abstand ihre Integration auf denselben dritten Namen umbenannt.

Es lohnt sich, die Familie selbst im Blick zu behalten, denn sie erklärt den Pragmatismus. Die bisherigen öffentlichen Releases wurden unter der Marke TeleChat veröffentlicht:

• TeleChat-7B und TeleChat-12B, im Januar 2024 als Open Source veröffentlicht, mit einem Korpus von 1 Billion Token.

• TeleChat2-115B (September 2024), angepriesen als das erste vollständig inländische offene Modell mit einer Billion Parametern, dazu die Geschwistermodelle mit 35B, 7B und 3B.

• TeleChat2-39B-A12B (März 2025), das erste MoE der Familie.

• TeleChat3-105B-A4.7-Thinking (Dezember 2025), ein feingranulares MoE mit insgesamt 105B und 4,7B aktiven Parametern, trainiert auf 15 Billionen Tokens, zusammen mit dem dichten TeleChat3-36B und dem späteren TeleChat3-Coder-36B-Thinking.

Wenn die Zahl 29B-A4B stimmt, läge dieses Modell sowohl bei den Gesamt- als auch bei den aktiven Parametern unter TeleChat3-105B-A4.7-Thinking – ein kleineres, günstigeres Geschwistermodell statt ein Ersatz-Flaggschiff. Das ist eine Lesart, keine Tatsache; in keinem der beiden PRs steht, auf welche Leistungsklasse das Modell abzielt. Die Marke Xingchen ist der Bereich, in dem das Unternehmen seine KI-Anstrengungen bündelt: Das Xingchen AGI Lab wurde im März 2026 offiziell in Peking gegründet, baut auf derselben Modellfamilie auf, und China Telecom beschreibt sein „三全"-System (vollmodal, alle Größen, vollständig inländisch) als Spanne von semantischen, Sprach-, Vision- und multimodalen Modellen von 1B bis 1T+ Parametern. Eine Umbenennung von TeleChat zu Xingchen ist genau das, was ein Labor tut, wenn es möchte, dass die Modellfamilie die Marke des Labors trägt statt die Marke der Produktlinie.

Was wir noch nicht wissen

Für ein so frühes Modell ist die ehrliche Liste noch immer länger als die bekannte Liste, obwohl sie sich diese Woche an zwei Stellen verkleinert hat:

• Kein Veröffentlichungsdatum. Fünf der sechs Integrationen sind Entwürfe, die für eine frühe Code-Überprüfung geöffnet wurden, gerade weil die Gewichte nicht öffentlich sind. Die sechste, SGLang #39793, ist zur Überprüfung freigegeben statt als Entwurf – doch sie ist nicht zusammengeführt, alle drei ihrer CI-Läufe schlagen fehl, und sie braucht eine prüfende Person, die sie genehmigt. Es gibt keinen angekündigten Zeitplan.

• Eine Parameteranzahl, aber nur eine behauptete. Jede frühere Version dieses Textes führte die MoE-Konfiguration als nicht offengelegt auf. Der SGLang-PR ändert das auf dem Papier: Xing4.0-29B-A4B, insgesamt 29B, rund 4B aktiv. Die Zahl stammt aus einem Pull Request, ist mit keinem öffentlichen Checkpoint verknüpft, wird durch keine Konfigurationsdatei bestätigt und wurde von niemandem außerhalb des Projekts reproduziert. Behandle sie als erklärte Absicht, nicht als Spezifikation.

• Keine Benchmark-Zahlen, weder vom Anbieter gemeldet noch anderweitig, und keine unabhängigen Ergebnisse. Die Verifizierungsprotokolle im SGLang-PR zeigen, dass das Modell eine Reasoning-Aufforderung beantwortet und einen wohlgeformten Tool-Aufruf ausgibt; sie zeigen auch nichts darüber, wie gut es dabei abschneidet.

• Keine Preisangabe und keine bestätigte Lizenz. Jede frühere TeleChat-Version ist Apache-2.0, was ermutigend ist, aber für diese wurde keine Lizenz angegeben.

• Keine öffentlichen Gewichte — bestätigt statt angenommen. Mit Stand vom 16. September 2026 ist der im SGLang-PR genannte Hugging-Face-Pfad nicht öffentlich einsehbar, und die Organisation, auf die er verweist, führt keine öffentlichen Modelle auf; der neueste öffentliche Eintrag in der Familie ist TeleChat3-Coder-36B-Thinking vom Januar. Die Tabelle der unterstützten Modelle von vLLM nennt TBA in der Checkpoint-Spalte, die von SGLang „demnächst“, und bei beiden SGLang-PRs schlägt die öffentliche CI fehl.

• Kein offizielles Wort von China Telecom – keine Ankündigung, keine Gewichte, keine Bestätigung des Namens oder der Größe. Beachten Sie die Asymmetrie genau: Die SGLang-Dokumentationszeile schreibt das Modell China Telecom zu, aber das ist die Beschreibung eines Mitwirkenden in einem Pull Request, keine Unternehmenserklärung, und die neueste PR-Beschreibung lässt den Namen des Anbieters vollständig weg. Sechs Integrationen, die für dieses Modell gebaut werden, sind der bislang stärkste Beweis dafür, dass es real ist, aber Integrationen werden geschlossen und Codenamen ändern sich; zwei wurden bereits geschlossen. Nichts ist bestätigt, bis das Labor es sagt.

Die richtige Lesart all dessen ist nicht Skepsis gegenüber dem Modell; sie ist ein präzises Bild eines frühen Signals. Was heute existiert, ist ein echtes Engineering-Artefakt – sechs davon, über zwei Frameworks hinweg – mit einer echten Architektur und, zum ersten Mal, einer angegebenen Form, die daran geknüpft ist. Was noch nicht existiert, ist irgendetwas, das man herunterladen, aufrufen oder benchmarken kann.

Das Nächste, was Sie heute ausführen können

Dieses Modell ist nirgends bereitstellbar — weder über eine API noch lokal, weil die Gewichte nicht öffentlich sind. Das nächstliegende Modell, das ein Leser heute tatsächlich aufrufen kann und das seine architektonische DNA teilt, ist DeepSeek V4 Flash, das dasselbe mHC-Residualschema auf MLA und MoE aufsetzt, und es ist die Referenzimplementierung, für die die gemeinsam genutzten mHC-Module in beiden Frameworks entwickelt wurden. OrcaRouters Modellseite für deepseek/deepseek-v4-flash listet einen Kontext von 1 Mio. Token, eine maximale Ausgabe von 384K und Listenpreise von 0,15 $ pro Million Eingabe-Token und 0,29 $ pro Million Ausgabe-Token auf — dieselben Werte, die Deep​Seek selbst veröffentlicht, mit 0 % Aufschlag weitergegeben, sodass eine Preisänderung eines Anbieters hier noch am selben Tag live ist. Ein API-Schlüssel deckt den Katalog ab, was den Vergleich mit dem Rest der Reasoning-Stufe zu einer Routing-Regel statt zu einer neuen Integration macht.

Das ist auch die praktische Antwort auf die Frage „Wie probiere ich dieses Modell aus, wenn es erscheint?“ Ein brandneuer, unerprobter Checkpoint ist genau der Punkt, an dem sich automatisches Failover bezahlt macht: Leite einen Bruchteil des Traffics dorthin, behalte ein bewährtes Modell als Fallback und lass die Routing-Schicht die Entscheidung treffen, anstatt einen Produktionspfad auf das Verhalten am ersten Tag zu verwetten. Ein 29B-MoE mit ungefähr 4B aktiven Parametern, falls es so kommt, lässt sich günstig gegen ein Frontier-Modell routen, gerade weil pro Token so wenig davon aktiviert wird. Wenn sich der Name zwischen jetzt und dem Release erneut ändert – und die letzten sechs Wochen legen nahe, dass es passieren könnte –, dann ist die Routing-Regel das, was du umschreibst, nicht die Integration.

Häufig gestellte Fragen

Warum wurde der vLLM-PR geschlossen?

Wir sehen die Schließung, nicht den Grund. #54051 wurde am 7. September 2026 vom eigenen Autor geschlossen, ohne zusammengeführt zu werden, und die Arbeit tauchte neun Tage später als #57135 unter neuem Namen wieder auf. Ein früherer vLLM-PR, #51237, wurde am selben Tag unter demselben Titel geschlossen und erneut eingereicht, das Schließen und erneute Einreichen ist also das Muster dieses Autors und kein Zeichen von Problemen – aber die PR-Texte nennen keinen Grund, und wir werden keinen erfinden.

Wann wird Xing4_0 veröffentlicht?

Es gibt kein Datum. Fünf der sechs Integrationen sind Entwürfe, die für ein frühes Code-Review geöffnet wurden, und die Autoren selbst planen, Testeinträge hinzuzufügen, die Doku zu aktualisieren und die PRs erst dann als bereit zu markieren, wenn die Gewichte veröffentlicht sind. SGLangs ältere Checkliste ist die klarste Aussage darüber, wo die Dinge stehen: „Modell lädt & generiert (lokal, mit internen Gewichten)“ ist angehakt, und die öffentliche CI ist „blockiert bis zur Veröffentlichung der Gewichte“. Der neuere SGLang-PR ist als bereit zum Review eingereicht statt als Entwurf, was eher eine Änderung der Haltung als des Status ist – er ist nicht gemergt, seine CI ist rot, und eine Dokumentationszeile mit „in Kürze“ ist kein Launch.

Ist Xing4_0 dasselbe Modell wie XingChen4?

Mit ziemlicher Sicherheit ja, und die PRs machen es leicht, das zu überprüfen: dieselbe Fork-Abstammung, derselbe Architektur-Absatz, dieselben FlagGems-Benchmark-Zahlen, dieselben offenen Punkte und eine Datei-für-Datei-Umbenennung in beiden Frameworks – xingchen4.py zu xing4_0.py, einschließlich der Config-Klasse, auf Branches, die passend umbenannt wurden. Es ist dieselbe Arbeit unter einem neuen Namen, und seit dem 16. September haben sowohl vLLM als auch SGLang diesen Namen übernommen. Was kein PR angibt, ist, welchen Namen ein veröffentlichter Checkpoint tragen wird.

Ist das ein Deep​Seek-Modell?

Nein. Es ist das Modell von China Telecom, aus dem Xingchen AGI Lab. Die DeepSeek-Verbindung ist architektonischer Natur: Es verwendet das DeepSeek-V2/V3-Backbone und das mHC-Residualschema wieder, das DeepSeek vorgeschlagen und in V4 ausgeliefert hat. Die Architektur eines anderen zu übernehmen ist nicht dasselbe, wie wenn die beiden Projekte etwas miteinander zu tun haben.

Was als Nächstes ansehen

Die PRs liefern weiterhin eine konkrete Checkliste, und das Paar vom 16. September hat zwei Punkte hinzugefügt. Erstens die Gewichte: Jeder Autor hat gesagt, dass seine Arbeit auf Hugging Face wartet, dass also ein öffentliches Repository auftaucht, ist das entscheidende Ereignis – und der SGLang-PR gibt dir jetzt den genauen Pfad, den du beobachten musst, XingChen-AGI/Xing4.0-29B-A4B, der derzeit für niemanden auflöst. Zweitens die PRs selbst: vLLMs braucht, dass die mHC-Bias-Formeln bestätigt, der Registry-Testeintrag hinzugefügt und seine CI grün ist; SGLangs #39793 braucht, dass seine drei roten Läufe behoben werden und seine zehn angeforderten Reviewer zustimmen, während das ältere #37228 noch seinen Testeintrag, seinen MTP-Speedup-Benchmark und eine nicht blockierte CI braucht. Drittens, und diese Woche neu: ob SGLang #37228 zugunsten von #39793 schließt, so wie vLLM immer einen Vorgänger geschlossen hat, bevor es neu einreichte. Zwei aktive Integrationen für ein unveröffentlichtes Modell sind ein Zustand, den niemand lange aufrechterhält, und welche überlebt, sagt etwas darüber aus, wie nah das wirklich ist. Viertens die Zahlen: ob ein veröffentlichter Checkpoint der 29B-A4B-Form entspricht, dem 64-Experten-MoE und dem 262.144-Token-Kontext, die die Konfiguration und die PR-Beschreibung jetzt behaupten. Fünftens, ob der dritte vLLM-PR länger überlebt als seine beiden Vorgänger, die 21 bzw. 11 Tage hielten, bevor sie ungemergt geschlossen wurden. Und achte darauf, ob die Reasoning-Parser eine separate Thinking-Variante beschreiben, so wie TeleChat3 eine ausgeliefert hat.

Bis eines davon eintritt, behandle dieses Modell als das, was es ist: einen gut spezifizierten Plan aus einem seriösen Labor, dabei ertappt, wie es seine Serving-Infrastruktur vorbereitet — jetzt in beiden großen Open-Source-Serving-Stacks, unter einem Namen, den beide übernommen haben, und einer Größe, die nur sein eigener Pull Request angibt. Schon die Architektur allein macht es verfolgenswert: Es ist die zweite große Übernahme von mHC nach DeepSeek selbst, von einem Labor, dessen vorherige Generation bereits ein feingranularer MoE war, trainiert auf heimischen Chips. Sobald die Gewichte veröffentlicht werden, wird sich nicht mehr die Frage stellen, ob es in vLLM oder SGLang läuft. Beide Stacks haben den Code dreimal geschrieben, unter drei verschiedenen Namen.