Xing4_0 登陆 SGLang：中国电信下一代 MoE 的第六个 PR，以及首次公布的规模

2026年9月16日，相隔两小时，两大主流开源服务栈不再在名字上各执一词。vLLM在上午提交了“[Model] Add Xing4_0 support”；sgl-project/sglang随后于UTC 10:38提交了“feat: add Xing4_0 model support”；在三个名字并行使用了六周之后，如今两个框架都称之为 Xing4_0。SGLang的这个拉取请求带来了此前任何一个都没有的东西：一个规模。它将该模型描述为 Xing4.0-29B-A4B，一个“29B参数、约4B激活参数的MoE”，并给出了一条启动命令，其中指明了一个检查点路径、262,144 token的上下文以及EAGLE推测解码。这是中国电信尚未发布的MoE，也正是自8月以来XingChen4相关拉取请求一直围绕的那一个，而它至今仍未发布：权重未公开，PR所写的检查点路径在项目之外无人能够解析，没有任何厂商确认过这个名称或这个数字，本文中没有任何内容经过独立核实。取自拉取请求的事实均已如此标注；其余部分则属于历史与推断。今天你真正能调用到的最接近的模型是DeepSeek V4 Flash。

这是一篇“截至目前我们所知”的文章，持续更新，而非推倒重来。它涵盖六周的 PR 踪迹、命名问题如何落定、9 月 16 日的两个 pull request 究竟增加了什么、配置文件如今以真实细节泄露出的架构，以及接下来该关注什么。一句话版本：中国电信的下一代 MoE 已经足够真实，以至于积累了六个服务集成、vLLM 中一行标为 TBA 的表格条目、SGLang 中一条标着“即将推出”的文档条目，以及一个明确给出的参数规模——却仍然不够真实，无法在任何你能访问的地方运行。

信号：六项集成，三个名称，六周

这条线索的开始时间比本文最初报道的版本更早，而它的提交日志仍然是这次泄露中最具揭示性的产物。第一个 vLLM PR 是 #51237，于 2026 年 8 月 6 日以标题“[WIP][Model] 添加即将推出的 XingChen4 模型支持”开启。它的三个提交本身就说明了问题。第一个标题为“添加 TeleChat4 模型支持”。第二个在一个多小时后，是“chore: 回退 telechat4 的过早文档和测试条目”——文档和注册表测试条目因不成熟而被撤回。第三个于 8 月 27 日，是“重命名 xingchen4”。一分钟后，该 PR 被关闭且未合并，又过了十一分钟，#54051以相同的标题、相同的 fork 分支（supported_telechat4）开启，并且只有一个压缩后的提交。在此期间，一个 needs-rebase 标签被加上，所以这读起来像是清理后的关闭再重新打开，而不是改变了主意。所有这些都来自 GitHub 账户 zyp2014，每个提交都由 zhangyp26 <zhangyp26@chinatelecom.com.cn> 编写并签署。

第二个 PR 正是这篇文章最初围绕其构建的那一个，而它现在已经不再处于打开状态。 #54051 于 2026 年 9 月 7 日被其作者本人关闭，未被合并。 不过，它的描述仍然值得引用，因为正是这句话历经每一次重命名和每一次重新打开而留存了下来：

模型权重尚未在 Hugging Face Hub 上公开。此 PR 是为早期代码审查而开启的。一旦权重发布，我将在 tests/models/registry.py 中添加测试条目，更新 docs/models/supported_models.md，并将该 PR 标记为可审查状态。

那句话就是整个故事的轮廓：代码走在了权重前面。下方截图是 #54051 页面在 2026 年 8 月 27 日、也就是它开启当天的样子——一张带日期的快照，之所以留存，是因为它所展示的那个拉取请求此后已被关闭。请把它读作那一刻信号的记录，而不是它当下状态的记录。

随后，在9月16日，这一模式再度重演——一天之内出现了两次。#57135，即“[模型] 添加 Xing4_0 支持”，于当天上午由同一账号 zyp2014 发起，其中唯一的提交如今由另一位中国电信工程师撰写——xiongji <xiongj9@chinatelecom.cn>。共有11个文件发生更改，约1,300处插入，通篇使用了一个新名称，并在同一位置附有同样的提醒：“模型权重尚未在 Hugging Face Hub 上公开。”

两小时二十分钟后，另一个服务栈不再落后于一次重命名。sgl-project/sglang #39793，"feat: add Xing4_0 model support"，从一个名为 support_xing4_0 的分支提交，其唯一一次提交带有与 vLLM 重命名相同的 xiongji 地址。十四个文件、约 1,400 行新增，其中略超一千行属于单个模型文件。这是六周内为该模型提交的第六个集成，也是第一个以 非草稿形式提交的：GitHub 将其列为已开启并可供审查，已请求十位审查者——而它的三次 CI 运行已全部变红。

今天之前，SGLang 这一侧的做法和 vLLM 一样。#33982“feat(model)：添加 TeleChat4 模型支持”由贡献者 PaddyXj 于 2026 年 8 月 7 日打开，并于 8 月 31 日关闭且未合并——同一天#37228“feat：添加 XingChen4 模型支持”取而代之被打开。那一个仍以草稿形式挂在 PaddyXj 名下保持开启，位于一个名为support_xingchen4的分支上，已有三个提交，最后修改于 9 月 8 日。它的检查清单是两个框架中最有意思的东西：模型能在“本地、基于内部权重”加载并生成，已勾选；工具调用，已勾选；推理解析，已勾选——而公共 CI 没有勾选，因为它“受阻于权重发布”。有人有一个检查点。没有人把它发布出来。而且与 vLLM 不同——在 vLLM 中，每次重新提交都会先关闭其前身——SGLang 现在针对同一个模型有两个活跃的拉取请求处于打开状态，且用了两个不同的名称。

六周内六次集成，加起来并不等于同一信号的更强版本；而是另一种信号。六次集成本可以与一个正在迭代的团队相符。六次集成却顶着三个名字——TeleChat4、XingChen4、Xing4_0——这是一个团队在公开地反复调整模型最终发布时要用的名字，而权重却始终不公开。这是未经证实的推断，也是 PR 轨迹如今所显示出的最具后果性的一点。

两个9月的PR究竟新增了什么

vLLM 的拉取请求是对八月工作的重命名，而不是重写。模型文件现在是 vllm/model_executor/models/xing4_0.py，类为 Xing4_0ForCausalLM，且 model_type xing4_0 被映射到 DeepseekV3Config——与 XingChen4 版本所使用的同一个 DeepSeek-V3 配置。它包含的内容：

• 在 vllm/model_executor/models/xing4_0.py 中提供完整的模型实现——类 Xing4_0ForCausalLM，包含前向传播、一个 mHC 适配器，以及一个张量并行的 load_weights() 实现。提交信息指出，同时支持 DSA 和非 DSA 变体，复用共享的 mhc_pre / mhc_post 算子。

• 在 vllm/model_executor/models/registry.py 中注册 Xing4_0ForCausalLM，以便 vLLM 通过名称识别该架构。

• 一个推理解析器（vllm/reasoning/xing4_0_reasoning_parser.py），"用于具备推理能力的变体"，以及一个工具解析器（vllm/tool_parsers/xing4_0_tool_parser.py），用于自动工具调用。

• 在 vllm/config/speculative.py、vllm/transformers_utils/model_arch_config_convertor.py 和 vllm/transformers_utils/config.py 中注册——提交信息中说明，已为投机解码启用与 DeepSeek-V3 兼容的 MTP 头。

• 两个文档文件——真正新增的部分，也是对八月的直接反转。最初的提交包含一个文档和测试条目，但一小时后因时机不成熟而被回退；九月的 PR 重新加入了文档，并标记为 documentation、new-model 和 tool-calling。

vLLM 文档条目正是读者第一次具体了解到某些东西的地方。在 docs/models/supported_models.md 中，新增的那一行写着 `Xing4_0ForCausalLM` | Xing4_0 | TBA——checkpoint 那一列literally写着 TBA，那无非是用另一种字体写出的同一个“尚未”。而在 docs/features/tool_calling.md 中，在“Xing4_0 Models (xing4_0)”这一标题下，该 PR 记录了该模型的工具调用格式：调用会以 <tool_call>...</tool_call> 块的形式输出，形式要么是 JSON（{"name": ..., "arguments": {...}}），要么是使用 <param_key>...</param_key> 与 <param_value>...</param_value> 的基于标签的形式。这种具体程度是此前的 PR 从未达到的——这是该模型聊天格式的一个实现细节，被写进了一个主流框架的公开文档里，而对应的 checkpoint 却没人能下载。

SGLang 的 PR 更有意思，因为它附带的是实现和配置，而不是一条注册表条目加文档。它的文档行是首次有框架把厂商名称写进自己的文档。在 docs/docs/supported-models/generative_models.mdx 中，新增行列出了 Xing4_0，检查点一列写着 `Xing4_0` （即将推出），描述为：“中国电信的 MoE 模型，采用 MLA 注意力和 mHC（Manifold-constrained Hyper-Connection）残差流；支持原生 MTP 推测解码、工具调用和推理。”vLLM 的那一行写的是 TBA，没有点名任何厂商；SGLang 的则点名了中国电信，并写着即将推出。两者都不是发布日期，而框架文档中的一行也不是产品。

该 PR 描述补上了这个故事的此前每个版本都缺失的那个数字。"这个 PR 增加了对 Xing4.0-29B-A4B（29B 参数 MoE，约 4B 激活参数）的支持。"它还给出了一条启动命令——--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——并声明该配置已在张量并行度 2、262,144 token 上下文以及 EAGLE MTP 投机解码下完成验证，描述中还粘贴了一段推理响应和一次 get_weather 工具调用的记录作为佐证。支撑该验证的权重来自作者本人：该 PR 所写的仓库路径无法公开读取，其指向的 Hugging Face 组织根本没有列出任何公开模型。应把参数规模、上下文长度和那些记录视为附着在私有检查点上的、由 PR 报告的说法，而不是任何人都能复现的实测结果。这一切都仅见于该拉取请求，且未经复现。

推理解析器和工具解析器同时以两个名称出现，其意义与八月时一样。推理解析器的存在，是为了从模型输出中剥离思维标记——即模型在给出最终答案前所输出的内部思维链。专门为该模型构建的解析器意味着，该系列预计会有具备推理能力的变体，就像 TeleChat3 推出了 Thinking editions 一样。工具解析器，加上如今已有文档记录的调用格式，意味着原生函数调用也在预期之内。这两者都不能保证最终产品如何；但二者都是这些 PR 所携带的、关于中国电信目标所在的最强线索。

目前我们所知一览

下面这张记分牌是为本文于2026年8月27日根据当时的 vLLM PR 汇编而成的。这里特意将其保留为一份带有日期的快照，而不是重新绘制，因为三周后它的每一行仍然成立——未发布、权重未公开、DeepSeek 骨干、mHC 残差、两个解析器都包含在内。改变的并不是卡片上的某个数值，而是它周围的一切：它所引用的 vLLM PR 已于9月7日关闭，这项工作于9月16日以新名称重新出现，SGLang 在数小时后也跟随更名，而首次明确给出的参数数量也随之出现。卡片上没有任何内容有误。它只是已经有三周了，而故事已经越过它继续向前。其最后一行的 FlagGems 数据原封不动地沿用到了新的 vLLM PR 中，仍然只是 PR 中报告，仍未被复现。

PR 泄漏的架构

重命名一个文件并不会重命名一个架构，而 9 月 vLLM PR 中的摘要文本就是 8 月的文本，只不过用 Xing4_0 替换了 XingChen4——逐分句一一对应。有两句话承载着信号：

• "Xing4_0 复用了 DeepSeek-V2/V3 主干（MLA 注意力、MoE 模块、可选的 DSA 索引器）。"

它用流形约束的超连接（mHC）取代标准残差连接：残差流被扩展为 num_residual_streams 个并行流，并通过由 Sinkhorn-Knopp 投影生成的、依赖于输入的双随机矩阵进行混合。

每一条都对应着实实在在的东西。MLA 是多头潜在注意力（Multi-head Latent Attention），即 DeepSeek 在 V2 中引入的压缩注意力方案，它让 KV 缓存得以保持很小；MoE 是混合专家路由，它能在保持庞大参数量的同时只占用很小的激活开销。可选的 DSA 索引器是 V3.2 系列的 DeepSeek 稀疏注意力机制——一个轻量级的打分模块，负责挑选出要关注的 top-k 词元，从而把注意力成本从随上下文长度的平方级降到大致线性级。而 mHC 那句才是重头戏：该模型采用了 DeepSeek 自己在这一代才引入的残差架构。

SGLang PR 是第一个公布这个东西的形态、而非描述它的。它的配置文件 python/sglang/srt/configs/xing4_0.py 声明了 40 个隐藏层、3,584 的隐藏维度和 131,072 个 token 的词表；MLA 具有 KV LoRA 秩 512、查询 LoRA 秩 768，跨 32 个头；以及一个稀疏 MoE，包含 64 个路由专家加 1 个共享专家、top-4 路由、sigmoid 打分、2.0 的路由缩放因子和 noaux_tc 专家选择。mHC 字段也很明确：hc_mult 4、20 次 Sinkhorn-Knopp 迭代、h_res 钳制在正负 30，以及 rope_theta 为 10,000、最大位置嵌入为 262,144。根据该 pull request，这些是一个尚未发布的集成中的默认值——配置文件是意图声明，而不是模型卡，PR 描述中的 29B-A4B 数字并未在任何公开信息中由它们推导得出。

有一个字段比其他所有字段都更有价值，因为这是该模型第一个明显不再是对 Deep​Seek 的复制的地方。SGLang 配置设置了 hc_contract_for_draft，它会在最终 norm 之前把 mHC 流重新合并回模型自身的 hidden size，并将 那个收缩后的张量馈送给 Eagle draft head。Deep​Seek V4 则改为馈入 mHC 展平后的 n 倍 hidden_size 张量。配置注释明确说明了这一点，而这类细节只有在实现真正针对真实 checkpoint 打磨成型之后才会浮现——这正是早先那个 SGLang PR 的检查清单声称拥有、却没有公开的东西。

mHC 的数学正是两个技术栈在实现上分道扬镳、在假设上达成一致之处。vLLM 的 PR 指出，它“与 vllm.model_executor.layers.mhc 中的共享算子相匹配，因此没有引入私有内核”——该模块之所以存在，是因为 vLLM 已经为 DeepSeek V4 支持 mHC，所以新增这个模型的增量成本很小。SGLang 则走另一条路抵达同一处：它的 mHC 模块使用注册为 torch 自定义算子的融合 TileLang 内核，而该 PR 扩展了现有的 mhc_pre split-K 内核，使其在原本已处理的两种尺寸之外，还能接受 hc_hidden_size 14,336。它还针对这一架构关闭了 DeepGEMM 的 tf32_hc_prenorm_gemm 路径，因为该路径是原始 C 扩展，torch.compile 无法追踪；mHC 转而落到 TileLang 内核上。两个框架的实际优势相同：如果你今天在 vLLM 或 SGLang 上服务 DeepSeek V4，那么将来用于服务中国电信下一代 MoE 的机制其实已经装好了。

mHC，这一切的核心DeepSeek技巧

流形约束超连接值得深入剖析，因为它是这个模型最有趣的一点——而且它不是中国电信的发明。它是 Deep​Seek 的。

故事始于 2024 年 Kimi 团队提出的 Hyper-Connections。标准 Transformer 在每一层保留一条残差流：输入被加到该层的输出上，为梯度提供一条干净的路径，并让网络学习残差校正。Hyper-Connections 将那单条流替换为多条并行流，这些流在每一层由学习到的矩阵进行混合，为模型提供信息传播的更丰富路径。问题在于稳定性：无约束的混合矩阵会破坏使残差连接可训练的恒等映射性质，而在万亿参数规模下，训练损失会变得不稳定。

DeepSeek 的贡献——于 2025 年 12 月以 mHC 论文形式发表，随后被用于 DeepSeek V4——是将混合矩阵约束为双随机矩阵：非负，且每行与每列之和均为 1，并在训练期间通过 Sinkhorn-Knopp 投影加以强制。双随机矩阵的谱半径恰好为 1，因此信号在穿过数百层时不会被指数级放大或衰减。正是这一界限保证了大规模训练时的稳定性，而该投影的成本足够低，DeepSeek 报告在四条残差流的情况下训练开销仅约为 6.7%。于 2026 年 4 月 24 日发布的 DeepSeek V4 是其旗舰级应用，据报告在数学推理任务上提升约 15%，并额外支持 100 万 token 的上下文。

那么，这些 PR 稿说白了是在讲：中国电信的下一代模型采用了 Deep​Seek 经过验证的主干结构和 Deep​Seek 最新的残差机制，而不是从零开始发明其中任何一项。这是一个务实的选择，也暗含着一个微妙的确认——继 Deep​Seek 自己之后，第二个采用 mHC 的主要实验室相信这一招已经可以投入生产。

这些 PR 在 mHC 方面尚未完成，未完成事项也坦诚地说明了这一点。在 vLLM 的各 PR 中，作者指出 checkpoint 偏置（bias_pre、bias_post、bias_res）以及 h_res clamp 目前要么已被合入，要么被省略，而审阅者对公式等价性的确认是“主要的正确性问题”。还有一个自定义 transpose 算子，用于让张量对 TileLang 内核保持 C 连续——它和其他所有东西一起被重命名，从 _xingchen4_transpose_contiguous 改成 _xing4_0_transpose_contiguous——以及一个硬性限制：当 num_residual_streams 大于 1 时，mHC 模式不支持流水线并行，而张量并行是支持的。对于草稿来说，这些都不令人意外，但它仍是八月时那个未完成的边缘，这本身就很有信息量：六周的重命名并没有推动正确性问题，而最新 SGLang PR 上三次红色的 CI 运行，是同一个故事换了一种颜色。SGLang 配置确实确定下来的是流数量。当 hc_mult 设为 4、隐藏大小为 3,584 时，内核补丁中的 14,336 正好就是四条流——内核注释也明明白白地这么说。这篇文章最初发布时，这种解读还只是从一个光秃秃的数字推断出来的；现在它已经写进配置文件里了。

加速角度：又是 FlagGems

第二条线索将这一模型与中国电信同北京智源人工智能研究院的现有关系联系起来，而它也是唯一一条历经每一次更名仍完好无损的线索。该 vLLM PR 通过 USE_FLAGOS 环境标志启用可选的 FlagOS/FlagGems 加速，该标志默认禁用，并为 MoE、attention、softmax 和 top-k 换上热路径内核。据称的收益来自 PR 作者在 H100 上针对高并发长提示工作负载（输入 token 超过 1 万，并发数为 10）的基准测试：首个 token 时间最多降低 19.87%，每个输出 token 的时间最多降低 26.32%，其他工作负载则没有变化。这些数字由 PR 报告且未经复现，而且它们是在该标志默认关闭的情况下得出的。

值得记录的是，这次更名触及的东西少得可怜。9 月的 vLLM PR 带着同样的数字、同样范围狭窄的说明——该标志只存在于模型文件内——以及同样安装 flagtree 和 flag-gems 的指令。数字没有变，因为代码没有变；变的只是标签。SGLang 的拉取请求则完全没有 FlagGems 这条线——它们转而走 TileLang 和 DeepGEMM 路线——这使得这场争论关乎谁拥有服务层的优化，而不是关于模型本身。

这是一则延续性的故事。截至 2026 年 4 月，TeleChat3-36B-Thinking 是首个被独立移植到 FlagOS（BAAI 开源 AI 软件栈）的大模型。无论这个模型最终以什么形态发布，延续这一脉络——在其自身的 vLLM 集成中采用 FlagGems 内核——都表明该实验室的国产栈战略已延伸至服务层，而不仅是训练。

命名问题，以及它源自的家族

在9月16日之前，命名问题还只是题外话。如今它已几近尘埃落定，而证据仍然全在分支名称和遗留字符串中，而不是在声明里——但这两个框架已从同一方向趋同于同一个答案。

• 提交信息按顺序依次为：“添加 TeleChat4 模型支持”，接着是“chore：回退 telechat4 的过早文档和测试条目”，然后——三周之后，也就是该 PR 关闭前一分钟——“重命名 xingchen4”。一个全部目的就是这次重命名的提交。

• 这个 fork 产生了分支。前两个 vLLM PR，#51237 和 #54051，是从 zyp2014:supported_telechat4 切出来的。第三个 #57135，是 zyp2014:support_xing4_0。分支是在重命名模型的同一次操作中被重命名的——而 SGLang 这边如今也已分三步走过了完全相同的路径，从 support_telechat4 经 support_xingchen4 到 support_xing4_0。

• #51237 的正文称 FlagGems 加速是“为 TeleChat4”而做的，可同一段落里又把该模型称作 XingChen4。早在作者 8 月 6 日自己写的摘要中，这两个名称就已经撞在了一起。

• 两边都是逐文件重命名。在 vLLM 中，是将 xingchen4.py 重命名为 xing4_0.py，并将 XingChen4ForCausalLM 重命名为 Xing4_0ForCausalLM；在 SGLang 中，则是将 xingchen4.py 重命名为 xing4_0.py，并将 XingChen4Config 重命名为 Xing4_0Config，而且所在分支也随之改了名。两个 PR 的 diff 中都没有在任何地方留下旧名称。

所以，三个名称一直在两个框架中同时使用，而这种模式与同一个模型在逐渐接近其最终公开名称时被改名的情况相符。“Xing4_0”自然读作 Xingchen 4.0——该模型家族在中文里以星辰（Xingchen）为品牌——但这仍然只是从字符串作出的推断，并非任何公关稿明确说明的内容。同样也可能是，TeleChat4 和 XingChen4 是同一代中的兄弟模型，而不是同一个模型的两个名称；不过，共享的 fork、共享的架构段落、相同的 FlagGems 数据、相同的未决事项，以及如今共享的改名，让这种说法更难成立。没有人证实二者之间的关系，中国电信也未予置评。变化在于，这次改名不再只是某一位贡献者的选择：两个独立、由不同人员维护的推理服务项目，都在相隔不到一天的时间里，将各自的集成重新标记为同一个第三名称。

这个系列本身值得持续关注，因为它解释了这种务实做法。到目前为止，公开发布的版本都以 TeleChat 为品牌：

• TeleChat-7B 和 TeleChat-12B，于 2024 年 1 月开源，语料库包含 1 万亿个 token。

• TeleChat2-115B（2024年9月），号称首个完全国产的万亿参数开源模型，另有35B、7B和3B同系列版本。

• TeleChat2-39B-A12B（2025年3月），该系列首款MoE模型。

• TeleChat3-105B-A4.7-Thinking（2025年12月），一种细粒度MoE模型，总参数量为105B、激活参数量为4.7B，在15万亿token上完成训练，与密集模型TeleChat3-36B及后续的TeleChat3-Coder-36B-Thinking一同推出。

如果 29B-A4B 这一数字成立，那么该模型在总参数量和激活参数量上都将低于 TeleChat3-105B-A4.7-Thinking——是一个更小、更便宜的兄弟型号，而非取代性的旗舰。这是一种解读，而非事实；两份 PR 中都没有说明该模型瞄准的是哪个层级。星辰品牌是该公司投入 AI 力量的地方：星辰 AGI 实验室于 2026 年 3 月在北京正式成立，基于同一模型系列打造，而中国电信将其“三全”（全模态、全尺寸、全国产）体系描述为涵盖语义、语音、视觉和多模态模型，参数规模从 1B 到 1T+。从 TeleChat 更名为星辰，正是一个实验室希望模型系列承载实验室品牌、而非产品线品牌时会做的事。

我们仍然不知道的事

对于这么早期的模型而言，诚实的清单仍然比已知的清单更长，不过本周它已在两个方面有所收窄：

• 没有发布日期。六个集成中有五个是以草稿形式开放，用于早期代码审查，原因正是权重尚未公开。第六个是 SGLang #39793，它以可供审查的形式开放而非草稿——但它尚未合并，其三次 CI 运行全部失败，并且需要一位审查者批准。目前没有公布任何时间表。

• 一个参数数量，但只是个声称的数字。本文此前的每一个版本都将 MoE 配置列为未披露。SGLang 的那个 PR 在纸面上改变了这一点：Xing4.0-29B-A4B，总计 29B，约 4B 激活。这个数字来自一个拉取请求，没有挂靠任何公开检查点，没有任何配置文件加以佐证，项目之外也无人复现。把它当作一种声明的意图，而非一份规格说明。

• 没有基准测试数值，无论是厂商报告的还是其他来源的，也没有独立评分。SGLang PR 中的验证记录显示，模型回答了一个推理提示，并发出了一次格式良好的工具调用；这些记录同样没有说明它在这两项上表现如何。

• 没有定价，也没有已确认的许可证。此前每一个 TeleChat 版本都是 Apache-2.0，这令人鼓舞，但这一版本尚未声明任何许可证。

• 没有公开权重——这是经过确认的，而非假设。截至 2026 年 9 月 16 日，SGLang PR 所提及的 Hugging Face 路径无法公开访问，其指向的组织也未列出任何公开模型；该系列最新的公开条目是 1 月的 TeleChat3-Coder-36B-Thinking。vLLM 的受支持模型表在检查点一栏标注为 TBA，SGLang 的则写着"即将推出"，且两个 SGLang PR 的公开 CI 均处于失败状态。

• 中国电信尚未发布官方消息——没有公告，没有权重，也没有确认名称或规模。请仔细注意这种不对称性：SGLang 文档那一行将该模型归为中国电信，但那是贡献者在拉取请求中的描述，并非公司声明，而最新的 PR 描述则完全略去了厂商名称。已有六个集成在为此模型开发，这是迄今最有力的证据，表明它确实存在，但集成会被关闭，代号也会更改；已经有两个如此了。在实验室正式表态之前，一切都未获确认。

对这一切的正确解读，并不是对模型持怀疑态度；而是对早期信号的准确描绘。今天存在的是真实的工程产物——共有六个，分布在两个框架中——它们有真实的架构，而且首次附有一个明确说明的形态。目前尚不存在的，是任何可供下载、调用或基准测试的东西。

如今你能运行的最接近的东西

该模型无法在任何地方提供服务——既不能通过 API，也不能在本地运行，因为其权重并未公开。如今读者实际能调用、且与其架构基因最接近的模型是 DeepSeek V4 Flash，它在 MLA 和 MoE 之上使用相同的 mHC 残差方案，并且它正是两个框架中共享 mHC 模块所为之构建的参考实现。OrcaRouter 的 deepseek/deepseek-v4-flash 模型页面列出了 100 万 token 上下文、384K 最大输出，以及每百万输入 token 0.15 美元、每百万输出 token 0.29 美元的标价——与 DeepSeek 自己公布的数字相同，以 0% 加价原样传递，因此供应商价格一变，这里当天就会生效。一个 API 密钥即可覆盖整个目录，这使得将其与推理层级的其余模型进行比较，成为一条路由规则，而不是一次新的集成。

这也是“当这个模型发布时，我该如何试用它”的实用答案。一个全新、未经证实的检查点，恰恰是自动故障转移体现价值的地方：把一小部分流量路由给它，保留一个经过验证的模型作为回退，让路由层来做决定，而不是把生产路径押在它第一天的表现上。一个 29B MoE，约有 4B 活跃参数——如果最终出现的是这个——把它和前沿模型放在一起做路由分流，成本很低，正因为每个 token 激活的参数量如此之少。如果从现在到发布之间名字再次改变——过去六周的情况表明这有可能——那么你要重写的是路由规则，而不是集成。

常见问题

为什么 vLLM 的 PR 被关闭了？

我们能看到关闭这件事，却看不到原因。#54051 于 2026 年 9 月 7 日被其作者本人关闭，未经合并，而这项工作在九天后以新名称 #57135 再次出现。更早的一个 vLLM PR，#51237，也在同一天被关闭并以相同标题重新提交，因此关闭并重新提交是这位作者的一贯模式，而不是出问题的迹象——但 PR 正文没有说明原因，我们也不会凭空编造一个。

Xing4_0 什么时候发布？

没有日期。六个集成中有五个是作为草稿提交、用于早期代码审查的，作者自己的计划是添加测试条目、更新文档，并且只有在权重发布之后才把 PR 标记为就绪。SGLang 较早的那份清单最清楚地说明了现状：“模型可加载并生成（本地，使用内部权重）”已勾选，而公共 CI 则“因权重发布而受阻”。较新的 SGLang PR 被标记为可供审查，而非草稿，这与其说是状态上的变化，不如说是姿态上的变化——它尚未合并，其 CI 是红的，而文档中一行写着“即将推出”的内容并不等于发布。

Xing4_0 和 XingChen4 是同一个模型吗？

几乎可以肯定是的，而这些 PR 让核查变得很容易：相同的 fork 谱系、相同的架构段落、相同的 FlagGems 基准测试数据、相同的未决事项，以及两个框架中逐文件的重命名——从 xingchen4.py 改为 xing4_0.py，连配置类也包括在内，分支也相应改名。这是同一项工作换了新名字，而截至 9 月 16 日，vLLM 和 SGLang 都已采用那个名字。没有任何 PR 说明的是，最终发布的 checkpoint 会带哪个名字。

这是 DeepSeek 模型吗？

不是。这是中国电信的模型，出自星辰 AGI 实验室。它与 DeepSeek 的关联是架构层面的：它复用了 DeepSeek-V2/V3 的骨干，以及 DeepSeek 在 V4 中提出并发布的 mHC 残差方案。采用别人的架构，并不等于两个项目就有关联。

接下来看什么

这些 PR 仍然给出了一份具体的清单，而 9 月 16 日的那一对又给它加了两项。第一，权重：每位作者都说过，他们的工作要等 Hugging Face，因此一个公开仓库的出现才是关键事件——而 SGLang 的 PR 现在给出了要盯的确切路径，XingChen-AGI/Xing4.0-29B-A4B，目前它对任何人都无法解析。第二，PR 本身：vLLM 的那个需要确认 mHC 偏置公式、添加 registry 测试条目并让 CI 通过；SGLang 的 #39793 需要修复其三个失败的运行，并让十位被请求的评审者签字通过，而更早的 #37228 仍需要它的测试条目、MTP 加速基准以及不受阻塞的 CI。第三，本周新增：SGLang 是否会像 vLLM 一直会在重新提交前关闭前身那样，为了 #39793 而关闭 #37228。为一个未发布的模型维护两个活跃集成，这种状态没人能维持太久，而哪一个存活下来，能说明这件事实际上有多接近。第四，数字：已发布的检查点是否匹配 29B-A4B 的形态、64 专家 MoE 以及配置和 PR 描述现在所声称的 262,144 token 上下文。第五，第三个 vLLM PR 是否比它的两个前身存活得更久，它们分别在 21 天和 11 天后被关闭且未合并。还要留意，推理解析器是否在描述一个单独的 Thinking 变体，就像 TeleChat3 发布了一个那样。

在其中之一发生之前，就把这个模型当作它本来的样子来对待：一份来自一家严肃实验室、规格明确的计划，被当场撞见正在筹备其服务基础设施——如今已同时出现在两大主流开源服务栈中，用一个两者都已采用的名称，以及一个只有它自己的拉取请求才说明的规模。仅凭架构本身就值得追踪：这是继 DeepSeek 自身之后，mHC 的第二次重大采用，而这家实验室的上一代已经是基于国产芯片训练的细粒度 MoE。当权重发布时，它能在 vLLM 还是 SGLang 中运行将不再是问题。两个服务栈都已经把代码写了三遍，用了三个不同的名称。