Xing4_0 Reaches SGLang: A Sixth PR, and the First Stated Size, for China Telecom's Next MoE

Two hours apart on September 16, 2026, the two dominant open-source serving stacks stopped disagreeing about the name. vLLM filed "[Model] Add Xing4_0 support" in the morning; sgl-project/sglang followed with "feat: add Xing4_0 model support" at 10:38 UTC, and after six weeks of three names in play, both frameworks now say Xing4_0. The SGLang pull request carries something no earlier one did: a size. It describes the model as Xing4.0-29B-A4B, a "29B-parameter MoE with ~4B activated parameters," and gives a launch command naming a checkpoint path, a 262,144-token context and EAGLE speculative decoding. This is China Telecom's unreleased MoE, the same one the XingChen4 pull requests have been circling since August, and it remains unreleased: the weights are not public, the checkpoint path the PR names does not resolve for anyone outside the project, no vendor has confirmed the name or the number, and nothing in this piece is independently verified. Facts taken from pull requests are labeled as such; the rest is history and inference. The closest model you can actually call today is DeepSeek V4 Flash.

This is a what-we-know-so-far piece, kept current rather than started over. It covers the six-week PR trail and how the naming question resolved, what the two September 16 pull requests actually add, the architecture the config files now leak in real detail, and what to watch for next. The one-sentence version: China Telecom's next MoE is real enough to have accumulated six serving integrations, a table row in vLLM marked TBA, a docs entry in SGLang marked "coming soon" and a stated parameter count — and still not real enough to run anywhere you can reach.

The signal: six integrations, three names, six weeks

The trail starts earlier than the version of this piece first reported, and its commit log is still the most revealing artifact in the leak. The first vLLM PR was #51237, opened on August 6, 2026 under the title "[WIP][Model] Add upcoming XingChen4 model support." Its three commits tell the story by themselves. The first is titled "Add TeleChat4 model support." The second, just over an hour later, is "chore: revert premature docs and test entry for telechat4" — the documentation and the registry test entry were pulled back out as premature. The third, on August 27, is "rename xingchen4." One minute later the PR was closed unmerged, and eleven minutes after that #54051 opened with the same title, the same fork branch (supported_telechat4) and a single squashed commit. A needs-rebase label had gone on in the interim, so this reads as a close-and-reopen after cleanup rather than a change of mind. All of it was filed from the GitHub account zyp2014, with every commit authored and signed off by zhangyp26 <zhangyp26@chinatelecom.com.cn>.

That second PR is the one this piece was originally built around, and it is no longer open. #54051 was closed by its own author on September 7, 2026, unmerged. Its description is worth quoting anyway, because it is the sentence that has survived every rename and every reopen:

• "Model weights are not yet public on Hugging Face Hub. This PR is opened for early code review. Once weights are released, I will add a test entry in tests/models/registry.py, update docs/models/supported_models.md, and mark the PR ready for review."

That sentence is the shape of the entire story: the code is ahead of the weights. The screenshot below is the #54051 page as it stood on August 27, 2026, the day it opened — a dated snapshot, kept because the pull request it shows has since been closed. Read it as a record of the signal at that moment, not of its status now.

Then, on September 16, the pattern repeated — twice in one day. #57135, "[Model] Add Xing4_0 support," opened that morning from the same account, zyp2014, with a single commit now authored by a different China Telecom engineer — xiongji <xiongj9@chinatelecom.cn>. Eleven files changed, roughly 1,300 insertions, a new name throughout, and the same caveat in the same place: "Model weights are not yet public on Hugging Face Hub."

Two hours and twenty minutes later the other serving stack stopped being one rename behind. sgl-project/sglang #39793, "feat: add Xing4_0 model support," opened from a branch called support_xing4_0, and its single commit carries the same xiongji address as the vLLM rename. Fourteen files and about 1,400 insertions, of which just over a thousand are a single model file. It is the sixth integration filed for this model in six weeks, and the first one filed as not a draft: GitHub lists it as open and ready for review, with ten reviewers requested — and all three of its CI runs already red.

The SGLang side before today ran the way vLLM's did. #33982, "feat(model): add TeleChat4 model support," was opened on August 7, 2026 by the contributor PaddyXj and closed unmerged on August 31 — the same day #37228, "feat: add XingChen4 model support," opened in its place. That one is still open as a draft under PaddyXj, on a branch called support_xingchen4, three commits deep and last touched on September 8. Its checklist is the most interesting thing in either framework: model loads and generates "locally, on internal weights" is ticked, tool calling is ticked, reasoning parsing is ticked — and public CI is not, because it is "blocked on weights release." Someone has a checkpoint. Nobody has published it. And unlike vLLM, where every refile closed its predecessor first, SGLang now has two live pull requests open for the same model, under two different names.

What six integrations in six weeks add up to is not a stronger version of the same signal; it is a different one. Six integrations would be consistent with a team iterating. Six integrations under three names — TeleChat4, XingChen4, Xing4_0 — is a team iterating on the name the model will ship under, in public, while the weights stay private. That is unverified inference, and it is the most consequential thing the PR trail now shows.

What the two September PRs actually add

The vLLM pull request is a rename of the August work rather than a rewrite of it. The model file is now vllm/model_executor/models/xing4_0.py, the class is Xing4_0ForCausalLM, and the model_type xing4_0 is mapped to DeepseekV3Config — the same Deep​Seek-V3 config the XingChen4 version used. What it carries:

• A full model implementation in vllm/model_executor/models/xing4_0.py — class Xing4_0ForCausalLM, with forward pass, an mHC adapter, and a tensor-parallel load_weights() implementation. The commit message notes both DSA and non-DSA variants are supported, reusing the shared mhc_pre / mhc_post ops.

• Registration of Xing4_0ForCausalLM in vllm/model_executor/models/registry.py, so vLLM knows the architecture by name.

• A reasoning parser (vllm/reasoning/xing4_0_reasoning_parser.py) "for reasoning-capable variants," and a tool parser (vllm/tool_parsers/xing4_0_tool_parser.py) for automatic tool calling.

• Registration in vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py and vllm/transformers_utils/config.py — with the commit message stating that a Deep​Seek-V3-compatible MTP head is enabled for speculative decoding.

• Two documentation files — the genuinely new part, and a direct reversal of August. The original commit carried a docs and test entry that was reverted an hour later as premature; the September PR puts the documentation back in and is labeled documentation, new-model and tool-calling.

The vLLM docs entries are where a reader first learned something concrete. In docs/models/supported_models.md, the new row reads `Xing4_0ForCausalLM` | Xing4_0 | TBA — the checkpoint column literally says TBA, which is the same "not yet" in a different font. And in docs/features/tool_calling.md, under the heading "Xing4_0 Models (xing4_0)", the PR documents the model's tool-call format: calls are emitted inside <tool_call>...</tool_call> blocks, as either JSON ({"name": ..., "arguments": {...}}) or a tag-based form using <param_key>...</param_key> and <param_value>...</param_value>. That is a level of specificity the earlier PRs did not reach — an implementation detail of the model's chat format, written down in a major framework's public documentation, for a checkpoint nobody can download.

The SGLang PR is more interesting, because it ships an implementation and a config rather than a registry entry plus docs. Its documentation row is the first time a framework has put the vendor's name in its own docs. In docs/docs/supported-models/generative_models.mdx, the new row lists Xing4_0, with the checkpoint column reading `Xing4_0` (coming soon) and a description: "China Telecom's MoE model with MLA attention and mHC (Manifold-constrained Hyper-Connection) residual streams; supports native MTP speculative decoding, tool calling, and reasoning." vLLM's row said TBA and named no vendor; SGLang's names China Telecom and says coming soon. Neither is a release date, and a row in a framework's docs is not a product.

The PR description adds the number every previous version of this story lacked. "This PR adds support for Xing4.0-29B-A4B (29B-parameter MoE with ~4B activated parameters)." It also gives a launch command — --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 — and states the configuration was verified at tensor parallelism 2, a 262,144-token context and EAGLE MTP speculative decoding, with transcripts of a reasoning response and a get_weather tool call pasted into the description as evidence. The weights behind that verification are the author's own: the repository path the PR names is not publicly readable, and the Hugging Face organisation it points at lists no public models at all. Treat the size, the context length and the transcripts as PR-reported claims attached to a private checkpoint, not as measurements anyone can repeat. All of it is per the pull request and unreproduced.

The reasoning and tool parsers appearing under both names matters for the same reason it did in August. A reasoning parser exists to strip thinking markers from a model's output — the internal chain-of-thought a model emits before its final answer. A parser purpose-built for this model means the family is expected to have reasoning-capable variants, the same way TeleChat3 shipped Thinking editions. The tool parser, plus the now-documented call format, means native function calling is expected too. Neither is a guarantee about the final product; both are the strongest hints the PRs carry about what China Telecom is aiming at.

What we know so far, at a glance

The scoreboard below is the one compiled for this piece on August 27, 2026, from the vLLM PR as it then stood. It is kept here deliberately as a dated snapshot rather than redrawn, because every line of it is still true three weeks later — unreleased, weights not public, Deep​Seek backbone, mHC residual, both parsers included. What has changed is not a value on the card but everything around it: the vLLM PR it cites was closed on September 7, the work reappeared under a new name on September 16, SGLang followed the rename hours later and the first stated parameter count arrived with it. Nothing on the card is wrong. It is simply three weeks old, and the story has moved past it. The FlagGems figures in its last row carried over into the new vLLM PR unchanged, still PR-reported and still unreproduced.

The architecture the PRs leak

Renaming a file does not rename an architecture, and the summary text in the September vLLM PR is the August text with Xing4_0 substituted for XingChen4 — clause for clause. Two sentences carry the signal:

• "Xing4_0 reuses the Deep​Seek-V2/V3 backbone (MLA attention, MoE block, optional DSA indexer)."

• "It replaces the standard residual connection with Manifold-constrained Hyper-Connections (mHC): the residual stream is expanded into num_residual_streams parallel streams mixed by input-dependent, doubly-stochastic matrices produced via Sinkhorn-Knopp projection."

Each clause maps to something concrete. MLA is Multi-head Latent Attention, the compressed-attention scheme Deep​Seek introduced in V2 that lets the KV cache stay small; MoE is mixture-of-experts routing, which keeps a large parameter count with a small active footprint. The optional DSA indexer is the Deep​Seek Sparse Attention mechanism from the V3.2 line — a lightweight scoring module that picks the top-k tokens to attend to, cutting attention cost from quadratic to roughly linear in context length. And the mHC sentence is the headline: this model adopts the residual architecture Deep​Seek itself only introduced this generation.

The SGLang PR is the first to publish the shape of the thing rather than describe it. Its config file, python/sglang/srt/configs/xing4_0.py, declares 40 hidden layers, a hidden size of 3,584 and a vocabulary of 131,072 tokens; MLA with a KV LoRA rank of 512 and a query LoRA rank of 768 across 32 heads; and a sparse MoE with 64 routed experts plus one shared expert, top-4 routing, sigmoid scoring, a routed scaling factor of 2.0 and noaux_tc expert selection. The mHC fields are explicit too: hc_mult 4, twenty Sinkhorn-Knopp iterations, an h_res clamp at plus or minus 30, and a rope_theta of 10,000 with a maximum position embedding of 262,144. These are the default values in an integration that has not shipped, per the pull request — a config file is a statement of intent, not a model card, and the 29B-A4B figure in the PR description is not derived from them anywhere in public.

One field is worth more than the rest, because it is the first place this model visibly stops being a copy of Deep​Seek. The SGLang config sets hc_contract_for_draft, which merges the mHC streams back down to the model's own hidden size before the final norm and feeds that contracted tensor to the Eagle draft head. DeepSeek V4 feeds the mHC-flattened n-times-hidden_size tensor instead. The config comment says so explicitly, and it is the kind of detail that only turns up once an implementation has been shaped against a real checkpoint — which is what the earlier SGLang PR's checklist claims to have, without publishing it.

The mHC math is where the two stacks diverge in implementation and agree in assumption. The vLLM PR notes that it "matches the shared ops in vllm.model_executor.layers.mhc, so no private kernels are introduced" — that module exists because vLLM already supports mHC for DeepSeek V4, so the incremental cost of adding this model is small. SGLang reaches the same place by a different road: its mHC module uses fused TileLang kernels registered as torch custom ops, and the PR extends the existing mhc_pre split-K kernel to accept hc_hidden_size 14,336 alongside the two sizes it already handled. It also switches off DeepGEMM's tf32_hc_prenorm_gemm path for this architecture, because that path is a raw C extension torch.compile cannot trace; mHC falls through to the TileLang kernel instead. The practical edge is the same in both frameworks: if you serve DeepSeek V4 on vLLM or SGLang today, the machinery that will serve China Telecom's next MoE is already installed.

mHC, the Deep​Seek trick at the center of it all

Manifold-constrained Hyper-Connections is worth unpacking, because it is the single most interesting thing about this model — and it is not China Telecom's invention. It is Deep​Seek's.

The story starts with Hyper-Connections, proposed by the Ki​mi team in 2024. A standard Transformer keeps one residual stream per layer: the input is added to the layer's output, giving gradients a clean path and letting the network learn a residual correction. Hyper-Connections replaces that single stream with several parallel streams that are mixed by learned matrices at each layer, giving the model a much richer path for information to travel. The catch is stability: unconstrained mixing matrices break the identity-mapping property that makes residual connections trainable, and at trillion-parameter scale the training loss goes unstable.

Deep​Seek's contribution, published as the mHC paper in December 2025 and then used in DeepSeek V4, was to constrain the mixing matrices to be doubly stochastic — non-negative, with rows and columns each summing to one — enforced by Sinkhorn-Knopp projection during training. A doubly stochastic matrix has a spectral radius of exactly one, so signals cannot be amplified or attenuated exponentially as they pass through hundreds of layers. That bound is what keeps training stable at scale, and the projection is cheap enough that Deep​Seek reported only about 6.7% training overhead at four residual streams. DeepSeek V4, released April 24, 2026, is the flagship use of it, with a reported gain of roughly 15% on math-reasoning tasks and a 1M-token context on top.

So what these PRs are saying, in plain terms, is: China Telecom's next model takes Deep​Seek's proven backbone and Deep​Seek's newest residual mechanism rather than inventing either from scratch. That is a pragmatic choice, and it carries a subtle confirmation — the second major lab after Deep​Seek itself to adopt mHC believes the trick is production-ready.

The PRs are not finished with mHC, and the open items are honest about it. Across the vLLM PRs the author notes that the checkpoint biases (bias_pre, bias_post, bias_res) and an h_res clamp are currently merged or omitted, and that reviewer confirmation of formula equivalence is "the main correctness question." There is also a custom transpose op that keeps a tensor C-contiguous for a TileLang kernel — renamed alongside everything else, from _xingchen4_transpose_contiguous to _xing4_0_transpose_contiguous — and a hard limitation: pipeline parallelism is unsupported in mHC mode when num_residual_streams is greater than one, while tensor parallelism is supported. None of this is surprising for a draft, but it is the same unfinished edge it was in August, which is itself informative: six weeks of renames have not moved the correctness question, and the three red CI runs on the newest SGLang PR are the same story in a different colour. What the SGLang config does settle is the stream count. With hc_mult set to 4 and a hidden size of 3,584, the 14,336 in the kernel patch is exactly four streams — and the kernel comment says so in as many words. That reading was inference from a bare number when this piece first ran; it is now written down in a config file.

The acceleration angle: FlagGems, again

A second thread ties this model to China Telecom's existing relationship with the Beijing Academy of Artificial Intelligence, and it is the one thread that has survived every rename intact. The vLLM PR enables optional FlagOS/FlagGems acceleration behind a USE_FLAGOS environment flag, disabled by default, swapping in hot-path kernels for MoE, attention, softmax and top-k. The claimed payoff, from the PR author's H100 benchmark on a high-concurrency long-prompt workload (10K-plus input tokens, concurrency 10): up to 19.87% lower time-to-first-token and up to 26.32% lower time-per-output-token, with other workloads neutral. Those numbers are PR-reported and unreproduced, and they come with the flag off by default.

What is worth recording is how little the rename touched. The September vLLM PR carries the same figures, the same narrow scope note about the flag living only inside the model file, and the same instruction to install flagtree and flag-gems. The numbers did not change because the code did not change; only the label did. The SGLang pull requests carry no FlagGems thread at all — they take the TileLang and DeepGEMM route instead — which makes this an argument about who owns the serving layer's optimisation, not about the model.

This is a continuity story. TeleChat3-36B-Thinking was, as of April 2026, the first large model independently ported to FlagOS, the BAAI open-source AI software stack. Whatever this model ships as, continuing that thread — with FlagGems kernels inside its own vLLM integration — says the lab's domestic-stack strategy extends into the serving layer, not just training.

The naming question, and the family it comes from

Until September 16 the naming question was a side note. It is now nearly closed, and the evidence is still all in branch names and leftover strings rather than statements — but the two frameworks have converged on the same answer from the same direction.

• The commit messages, in order: "Add TeleChat4 model support," then "chore: revert premature docs and test entry for telechat4," then — three weeks later and one minute before the PR was closed — "rename xingchen4." A commit whose entire purpose was the rename.

• The fork branches. The first two vLLM PRs, #51237 and #54051, were cut from zyp2014:supported_telechat4. The third, #57135, is zyp2014:support_xing4_0. The branch was renamed in the same move that renamed the model — and the SGLang side has now walked the identical path in three steps, from support_telechat4 through support_xingchen4 to support_xing4_0.

• The body text of #51237, which said the FlagGems acceleration was "for TeleChat4" while the very same paragraph called the model XingChen4. The two names were already colliding in the author's own summary on August 6.

• The file-for-file rename on both sides. In vLLM it was xingchen4.py to xing4_0.py and XingChen4ForCausalLM to Xing4_0ForCausalLM; in SGLang it is xingchen4.py to xing4_0.py and XingChen4Config to Xing4_0Config, on a branch that changed name with it. Neither PR left the old name behind anywhere in its diff.

So three names have been in play across two frameworks, and the pattern is consistent with a single model being renamed as it approaches whatever its public name will be. "Xing4_0" reads naturally as Xingchen 4.0 — the model's family is branded 星辰 (Xingchen) in Chinese — but that is still inference from the string, not something any PR states outright. It could equally be that TeleChat4 and XingChen4 are siblings in the same generation rather than one model under two names, though the shared fork, shared architecture paragraph, shared FlagGems numbers, shared open items and now a shared rename make that harder to argue. Nobody has confirmed the relationship and China Telecom has not commented. What has changed is that the rename is no longer one contributor's choice: two independent serving projects, maintained by different people, have both relabelled their integration to the same third name within a day of each other.

The family itself is worth keeping in view, because it explains the pragmatism. The public releases so far have been branded TeleChat:

• TeleChat-7B and TeleChat-12B, open-sourced January 2024 with a 1-trillion-token corpus.

• TeleChat2-115B (September 2024), billed as the first fully-domestic trillion-parameter open model, plus the 35B, 7B and 3B siblings.

• TeleChat2-39B-A12B (March 2025), the family's first MoE.

• TeleChat3-105B-A4.7-Thinking (December 2025), a fine-grained MoE with 105B total and 4.7B active parameters, trained on 15 trillion tokens, alongside the dense TeleChat3-36B and later TeleChat3-Coder-36B-Thinking.

If the 29B-A4B figure holds, this model would sit below TeleChat3-105B-A4.7-Thinking in both total and active parameters — a smaller, cheaper sibling rather than a replacement flagship. That is a reading, not a fact; nothing in either PR says what tier the model is aimed at. The Xingchen brand is where the company puts its AI effort: the Xingchen AGI Lab was formally established in Beijing in March 2026, building on the same model family, and China Telecom describes its "三全" (full-modal, full-size, fully domestic) system as spanning semantic, speech, vision and multimodal models from 1B to 1T+ parameters. A rename from TeleChat to Xingchen is exactly what a lab does when it wants the model family to carry the brand of the lab rather than the brand of the product line.

What we still don't know

For a model this early, the honest list is still longer than the known list, though it has narrowed in two places this week:

• No release date. Five of the six integrations are drafts opened for early code review, precisely because the weights are not public. The sixth, SGLang #39793, is open for review rather than draft — but it is unmerged, all three of its CI runs are failing and it needs a reviewer to approve it. There is no announced schedule.

• A parameter count, but only a claimed one. Every previous version of this piece listed the MoE configuration as undisclosed. The SGLang PR changes that on paper: Xing4.0-29B-A4B, 29B total, roughly 4B active. The figure comes from a pull request, is attached to no public checkpoint, is corroborated by no config file and has been reproduced by nobody outside the project. Treat it as a stated intent, not a specification.

• No benchmark numbers, vendor-reported or otherwise, and no independent scores. The verification transcripts in the SGLang PR show the model answering a reasoning prompt and emitting a well-formed tool call; they show nothing about how well it does either.

• No pricing, and no confirmed license. Every prior TeleChat release is Apache-2.0, which is encouraging, but no license has been stated for this one.

• No public weights — confirmed rather than assumed. As of September 16, 2026 the Hugging Face path the SGLang PR names is not publicly readable and the organisation it points at lists no public models; the newest public entry in the family is TeleChat3-Coder-36B-Thinking from January. vLLM's supported-models table says TBA in the checkpoint column, SGLang's says "coming soon," and both SGLang PRs have failing public CI.

• No official word from China Telecom — no announcement, no weights, no confirmation of the name or the size. Note the asymmetry carefully: the SGLang documentation row attributes the model to China Telecom, but that is a contributor's description inside a pull request, not a company statement, and the newest PR description drops the vendor's name entirely. Six integrations building for this model is the strongest evidence yet that it is real, but integrations get closed and codenames change; two already have been. Nothing is confirmed until the lab says so.

The right reading of all of this is not skepticism about the model; it is an accurate picture of an early signal. What exists today is a real engineering artifact — six of them, across two frameworks — with a real architecture and, for the first time, a stated shape attached. What does not exist yet is anything you can download, call, or benchmark.

The closest thing you can run today

This model is not servable anywhere — not through an API, not locally, because the weights are not public. The closest model a reader can actually call today that shares its architectural DNA is DeepSeek V4 Flash, which uses the same mHC residual scheme on top of MLA and MoE, and it is the reference implementation the shared mHC modules in both frameworks were built for. OrcaRouter's model page for deepseek/deepseek-v4-flash lists a 1M-token context, a 384K maximum output and list pricing of $0.15 per million input tokens and $0.29 per million output — the same figures Deep​Seek itself publishes, passed through with 0% markup, so a vendor price change is live here the same day. One API key covers the catalogue, which makes comparing it against the rest of the reasoning tier a routing rule rather than a new integration.

That is also the practical answer to "how do I try this model when it ships." A brand-new, unproven checkpoint is exactly where automatic failover earns its keep: route a fraction of traffic to it, keep a proven model as the fallback, and let the routing layer make the decision instead of betting a production path on day-one behavior. A 29B MoE with roughly 4B active parameters, if that is what arrives, is a cheap thing to route against a frontier model precisely because so little of it activates per token. If the name changes again between now and release — and the last six weeks suggest it might — the routing rule is what you rewrite, not the integration.

Frequently asked questions

Why did the vLLM PR get closed?

We can see the closure, not the reason. #54051 was closed by its own author on September 7, 2026 without being merged, and the work reappeared nine days later as #57135 under a new name. An earlier vLLM PR, #51237, was closed and refiled the same day under the same title, so closing and refiling is this author's pattern rather than a sign of trouble — but the PR bodies do not state a reason and we are not going to invent one.

When will Xing4_0 be released?

There is no date. Five of the six integrations are drafts opened for early code review, and the authors' own plans are to add test entries, update docs and mark the PRs ready only once weights are released. SGLang's older checklist is the clearest statement of where things stand: "Model loads & generates (locally, on internal weights)" is ticked, and public CI is "blocked on weights release." The newer SGLang PR is filed as ready for review rather than draft, which is a change in posture rather than a change in status — it is unmerged, its CI is red, and a docs row reading "coming soon" is not a launch.

Is Xing4_0 the same model as XingChen4?

Almost certainly yes, and the PRs make it easy to check: same fork lineage, same architecture paragraph, same FlagGems benchmark figures, same open items, and a file-for-file rename in both frameworks — xingchen4.py to xing4_0.py, config class included, on branches renamed to match. It is the same work wearing a new name, and as of September 16 both vLLM and SGLang have adopted that name. What no PR states is which name a released checkpoint will carry.

Is this a Deep​Seek model?

No. It is China Telecom's model, from the Xingchen AGI Lab. The Deep​Seek connection is architectural: it reuses the Deep​Seek-V2/V3 backbone and the mHC residual scheme Deep​Seek proposed and shipped in V4. Adopting someone's architecture is not the same as the two projects being related.

What to watch next

The PRs still give a concrete checklist, and the September 16 pair added two items to it. First, the weights: every author has said their work waits on Hugging Face, so a public repository appearing is the load-bearing event — and the SGLang PR now gives you the exact path to watch, XingChen-AGI/Xing4.0-29B-A4B, which currently resolves for nobody. Second, the PRs themselves: vLLM's needs the mHC bias formulas confirmed, the registry test entry added and its CI green; SGLang's #39793 needs its three red runs fixed and its ten requested reviewers to sign off, while the older #37228 still needs its test entry, its MTP-speedup benchmark and an unblocked CI. Third, and new this week: whether SGLang closes #37228 in favour of #39793 the way vLLM has always closed a predecessor before refiling. Two live integrations for one unreleased model is a state nobody maintains for long, and which one survives says something about how close this actually is. Fourth, the numbers: whether a released checkpoint matches the 29B-A4B shape, the 64-expert MoE and the 262,144-token context that the config and PR description now assert. Fifth, whether the third vLLM PR survives longer than its two predecessors, which lasted 21 and 11 days respectively before being closed unmerged. And watch whether the reasoning parsers are describing a separate Thinking variant the way TeleChat3 shipped one.

Until one of those happens, treat this model as what it is: a well-specified plan from a serious lab, caught in the act of preparing its serving infrastructure — now in both major open-source serving stacks, under a name both of them have adopted and a size only its own pull request states. The architecture alone makes it worth tracking: it is the second major adoption of mHC after Deep​Seek itself, from a lab whose previous generation was already a fine-grained MoE trained on domestic chips. When the weights drop, there will be no question whether it runs in vLLM or SGLang. Both stacks have written the code three times over, under three different names.