96% 的含义:一颗 29B 全栈国产训练模型拆开看
中国电信开源星辰 Xing4.0-29B-A4B——29B 总参数、每 token 激活 4B、原生 256K 上下文,全程在昇腾 910C 与 MindSpore 上训练。为什么"训练吞吐提升约 96%"这个内部对比数字,比九项跑分更值得拆解?本文从规格、架构、训练栈、基准口径和边界五个角度,拆开这颗国产训练样本。
为什么一颗 29B 模型值得单独写一篇
开源社区里每周都有新权重。29B 这个体量,放进 2026 年的大模型发布流水线里,甚至算不上"大"——前面还排着一堆 600B 起步、动辄万亿参数的旗舰。所以当中国电信人工智能科技有限公司(中电信人工智能研究院)把星辰 Xing4.0-29B-A4B 推上 GitHub、Hugging Face、魔搭、Gitee 和魔乐时,真正值得拿出来写的不是它的体量,而是它的训练路径:
它是这个参数量级里,第一个全程跑在昇腾 NPU 平台 + MindSpore 框架上完成训练的模型。
这句话的限定语很重要。"这个参数量级"和"全程"两个条件,把这个模型和过去两年里那些"推理侧国产化"的案例区分开了。把已经训练好的权重搬上国产芯片跑起来,和从数据到算子到并行策略全部在国产栈上完成一次完整训练,中间隔着的不是一代硬件,而是一整套软件生态的成熟度。
顺带一提,官方仓库的措辞比媒体通稿克制得多。模型卡写的是"the first model of this scale trained entirely on the Ascend NPU platform with the MindSpore framework",而不是笼统的"首个国产训练大模型"。这种限定是诚实的,也是我们后面讨论边界时需要保留的口径。
主要来源:
- GitHub 仓库:XingChen-AGI/Xing4.0-29B-A4B
- Hugging Face 模型卡:XingChen-AGI/Xing4.0-29B-A4B
- 前代技术报告:Training Report of TeleChat3-MoE (arXiv:2512.24157)
规格:29B 总参数、4B 激活、256K 上下文
先把硬指标摆出来,这些都是模型卡里逐项列明的字段:
| 字段 | 数值 |
|---|---|
| 总参数 | 29B |
| 每 token 激活参数 | 4B |
| 层数 | 40 |
| Hidden Size | 3584 |
| Dense FFN 中间维 | 9216 |
| Expert FFN 中间维 | 1024 |
| 注意力类型 | MLA(Multi-head Latent Attention) |
| 路由专家数 | 64 |
| 每 token 激活专家数 | 4 |
| 共享专家数 | 1 |
| 上下文长度 | 256K,可扩展至 512K |
| 开源协议 | Apache-2.0 |
把这几个数字连起来读,能读出很明确的设计取舍。
4% 的激活比例。 29B 的盘子里每次只点亮 4B,稀疏度接近 14:1。64 个路由专家选 4 个,再加 1 个共享专家——这是典型的"大容量、小激活"路线,目的是让显存占用和推理成本停留在 4B 级别模型的量级,同时把知识容量撑到 29B。对部署方来说,这个组合的吸引力在于:它是少数能塞进消费级显卡显存、又能在长上下文任务上不掉链子的配置。
MLA 而不是标准 MHA。 MLA 通过低秩压缩把 KV Cache 压下来,这是长上下文推理成本的关键变量。256K 的原生上下文如果配标准注意力,KV Cache 会把显存吃干净;换成 MLA 之后,长上下文的推理才具备工程可行性。
256K 原生、512K 可扩展。 官方没有说明 512K 的扩展方式(是位置插值还是别的),这一点后面会放进"待核验"清单。
架构上的三个缩写:mHC、MLA、MTP
官方对架构的描述只有一句话:"built on the mHC + MLA + MTP architecture"。三个缩写里,MLA 是成熟的公开概念,MTP(Multi-Token Prediction)在近两年的开源模型里也已经常见,但 mHC 的展开形式,模型卡和仓库 README 都没有给出。
这里不做猜测。能确认的只有两件事:
一是官方对这套架构的定位——面向智能体场景,支撑多步规划、工具调用和复杂推理链,重点是"长上下文下的任务连贯性与执行稳定性"。这也解释了为什么 29B 这个体量要配 256K 上下文:Agent 任务的上下文膨胀速度远超普通对话,一轮工具调用链叠上文件内容和历史轨迹,很容易突破普通模型的窗口。
二是官方在 README 末尾专门写了一段致谢:
Special thanks to the DeepSeek team. Drawing on the design wisdom of their model architecture brought significant stability and efficiency to our training process.
"借鉴其模型架构的设计思路"——这句话放在开源仓库里是相当直白的表述。结合 Xing4.0 与同期 DeepSeek 开源模型共享的稀疏注意力、MLA、mHC 连接等特征,可以合理判断这条架构路线正在被国内多个团队共同推向工程成熟。(这一段是观察,不是官方结论。)
关键数字不是跑分,而是 96%
官方 Highlights 里列了四条,第三条是:
Through multi-level co-optimization — including fine-grained MoE communication optimization, selective recomputation, DVM automatic graph-operator fusion, and Ascend C mHC fused operators — overall training throughput was improved by approximately 96% over out-of-the-box performance.
我把这个数字单独拎出来,是因为它和其他三条的性质不同。
跑分衡量的是模型能力,96% 衡量的是软件栈的挖潜能力。同一批硬件,不动一颗芯片,只在框架层、通信层、算子层做适配和融合,把训练吞吐拉高了将近一倍——这才是国产算力最稀缺的部分。硬件可以堆,但把硬件效能榨出来的工程能力,需要一轮一轮的调优积累。
四项优化手段,指向的是四个不同层次的问题:
| 优化项 | 所在层次 | 针对的瓶颈 |
|---|---|---|
| 细粒度 MoE 通信优化 | 分布式通信 | 专家并行下的 all-to-all 通信开销 |
| 选择性重计算 | 显存与计算 | 激活值显存压力换回来的计算重放 |
| DVM 自动图算融合 | 图编译 | 算子启动开销与访存冗余 |
| Ascend C mHC 融合算子 | 算子内核 | 特定结构的算子效率 |
这四项里的任何一项,都不是"改个参数"级别的调整。做过多卡训练的人会知道,MoE 的专家并行通信是最容易把集群效率拖垮的地方——路由不均衡会让部分卡空转,通信与计算不重叠会让算力等数据。而"自动图算融合"和"自定义融合算子",本质是把框架没能覆盖的优化空间,用手写内核补回来。
但必须说清楚:96% 是相对"开箱状态"的内部对比。 它比较的是同一套硬件上"优化前 vs 优化后",不是"国产硬件 vs 国际硬件",也没有第三方复现。这两个口径经常被混着引用,导致这个数字被误读成"国产芯片追平国际水平"。它真正的含义要窄得多,也扎实得多:这套软件栈有一倍的余量可以被挖出来,而且已经挖出来了一部分。
训练栈不是一次性的:从 TeleChat3 到 Xing4.0
Xing4.0 不是一个孤立的产物。它的前代技术报告《Training Report of TeleChat3-MoE》在 2025 年 12 月提交到 arXiv,描述的是一个参数量从 105B 覆盖到超过 1 万亿的 MoE 系列,端到端在昇腾 NPU 集群上训练。那份报告的重点,恰好就是"训练基础设施"本身:
- 算子级与端到端数值精度验证:确保不同硬件平台、不同分布式并行策略之间结果一致。这一点看起来枯燥,但它是"训练能不能迁移到新硬件"的前置条件——数值对不齐,任何调优结果都不可信。
- 交错流水线调度:减少流水线气泡。
- 面向长序列的 attention-aware 数据调度:让数据排布匹配注意力计算的负载特征。
- 专家并行的分层重叠通信:把通信藏进计算里。
- 基于解析估计与整数线性规划的并行策略搜索:用数学规划代替手工试错来找张量并行、流水并行、数据并行、专家并行的组合。
- 集群级优化:解决大规模训练中的主机侧与设备侧瓶颈。
报告给出的结论是:这些基础设施改进在数千设备的集群上带来了显著的吞吐提升与近线性扩展。
把这份报告和 Xing4.0 的 Highlights 放在一起看,脉络就清楚了:Xing4.0 不是某个团队突然做出来的一次性成果,而是一条从 2025 年延续到 2026 年的技术线在第 N 次迭代后的产物。 数值对齐、并行策略搜索、通信重叠这些能力一旦建成,是可以复用到下一个模型、下一个集群规模上的——这是基础设施和"单次调优"最大的区别。
九项基准:75.0 和 57.5 处在什么位置
官方给了三模型对照表,对比对象是同量级的 Gemma4-26B-A4B 与 Qwen3.6-35B-A3B:
| 基准 | Xing4.0-29B-A4B | Gemma4-26B-A4B | Qwen3.6-35B-A3B |
|---|---|---|---|
| IFBench | 69.67 | 72.67 | 65.50 |
| AIME2026 | 90.00 | 88.30 | 92.70 |
| AA.LCR | 61.00 | 66.00 | 62.00 |
| Tau3-Bench | 64.63 | 58.90 | 67.20 |
| Claw-Eval | 76.55 | 71.49 | 74.54 |
| SWE-bench Verified | 75.00 | 53.00 | 76.00 |
| Terminal-Bench 2.1 | 57.50 | 30.00 | 51.50 |
| SWE-bench Multilingual | 66.00 | 51.00 | 67.20 |
| DeepresearchBII | 60.80 | 39.30 | 59.70 |
分项看,这张表讲了一个不太均匀的故事:
- 编程 Agent 是强项。 SWE-bench Verified 75.0,几乎贴住 Qwen3.6-35B-A3B 的 76.0,同时把 Gemma4-26B-A4B 的 53.0 拉开 22 分;Terminal-Bench 2.1 的 57.5 反超 Qwen 的 51.5。
- 通用 Agent 与检索同样靠前。 Claw-Eval 76.55、DeepresearchBII 60.80 都是三个模型里的最高值。
- 数学与指令遵循不是强项。 AIME2026 的 90.0 低于 Qwen 的 92.70;IFBench 的 69.67 明显落后 Gemma4 的 72.67;AA.LCR 的 61.00 也只排在中间。
这个分布和官方给自己的定位完全吻合:面向复杂工程任务的轻量代码智能体基座。它不是要做一个全面领先的通用模型,而是把资源集中在"多步骤规划 + 工具调用 + 长上下文执行"这条狭窄但价值明确的赛道上。对照它 29B/4B 的体量,这个取舍是清醒的。
同时也要注意评测口径。模型卡脚注里写得很细:SWE-bench Verified 用 SWE-agent harness,temperature=1.0,210K 上下文窗口;Terminal-Bench 2.1 用 terminus-2,24 小时超时,取 3 次运行的平均值;Tau3-Bench 报告的是 4 次运行的 pass^1 平均值。这些口径是自报的,没有第三方复现,跨模型对比时要把这一点记在心上——不同 harness、不同上下文预算、不同重试次数,足以让同一组分数产生可观偏移。
开源的不只是权重
如果说规格和跑分决定"能不能用",那么围绕它的工程配套决定"好不好用"。这次放出来的东西,比一份权重文件要完整:
| 环节 | 支持情况 |
|---|---|
| 微调 | LLaMA-Factory、MindFormers |
| 推理部署 | vLLM、SGLang、KTransformers |
| Agent 框架 | OpenCode、Claude Code、OpenClaw、Hermes |
| 多芯片部署 | 通过 BAAI FlagOS 完成多芯片平台适配,支持跨架构一键部署 |
| 训练硬件适配 | Ascend Atlas 800T A3 集群,MindSpore + MindFormers 分布式训练与评测 |
| 文档 | LLaMA-Factory 微调指南、MindFormers 训练指南、FlagOS 算子集成指南 |
几个细节值得单独说。
KTransformers 在列表里,分量不轻。 vLLM 和 SGLang 是当前主流的高吞吐推理框架,但 KTransformers 走的是 GPU/CPU 异构路线,专门为"在有限显存上跑 MoE"。官方 README 里给了一条 --kt-num-gpu-experts 24 的启动示例——把 64 个专家里的 24 个放 GPU、其余放 CPU 和内存。这意味着 29B 的模型可以在一块消费级显卡上跑起来。"可控"和"便宜"这两个词,对私有化部署的团队来说,往往比跑分高两分更重要。
FlagOS 的介入方式很具体。 通过 FlagOS 把 mHC 的 Triton-Ascend 融合算子集成进 MindFormers,并完成了单节点 16 卡的训练验证。这比"支持国产芯片"这种笼统表述有价值得多——它给出的是一条可复现的算子集成路径,第三方团队可以沿着这条路做自己的适配。
推理侧已经对齐了主流 API 习惯。 官方同时给了 OpenAI 兼容接口的调用示例、Transformers 的原生加载示例,以及 vLLM / SGLang / KTransformers 三套启动命令行,连 reasoning parser 和 tool call parser 的名称(xing4)都标好了。对要把它接进 Agent 流水线的团队来说,这些细节省掉的是几天的摸索。
需要泼的冷水
按惯例,把边界写清楚。
一、所有基准都是自报的。 九项分数出自官方模型卡,评测脚本、随机种子、失败样本的判定标准未公开,没有第三方独立复现。跨厂商对比时,这些分数只能作为参考坐标,不能当成定论。
二、"训练吞吐提升 96%"是内部口径。 基线是"开箱状态",即未做针对性优化时的框架默认表现。这个数字无法用来做跨硬件平台的效率比较,也无法推断国产集群在国际同类集群中的相对位置。
三、"首个全栈国产训练"需要更细的界定。 官方措辞限定在"this scale"(这个参数量级)和"Ascend NPU + MindSpore",这是准确的。但训练数据的清洗环节、评测环节是否也完全运行在国产栈上,公开信息里没有交代。从"能用"到"能训"的跨越是真实的,但"全栈"这个词的边界,需要等更完整的技术报告来划定。
四、29B 的能力上限是客观存在的。 它不可能对标千亿级旗舰模型。官方自己的定位也很清楚——"够用、可控、便宜"。把它当成一个可以私有化部署的中文基座,而不是一个要冲榜的旗舰,预期才不会落空。
五、512K 扩展方式未披露。 原生 256K 是明确写死的配置,但"可扩展至 512K"具体走的是位置插值、YaRN 一类的频率调整,还是别的路线,模型卡没有说明,也没有对应长度的评测数据。
放到更大的背景里:这条线上不止一颗模型
把视线从单个模型移开。2026 年 6 月,深圳河套学院 AI 训练平台项目团队联合哈尔滨工业大学(深圳)、深圳市大数据研究院、华为 GTS 等单位,在千卡级昇腾 910C 集群上完成了 DeepSeek-V4-Pro(1.6 万亿参数级 MoE)的全参数后训练:
- 持续 1500 步以上稳定迭代,全程无迭代跳过、无 NaN 异常;
- 关键训练算子效率较初始版本提升约 14%;
- MFU 最高 34.9%,稳定超过 30%;
- 单步训练稳定在 27 秒。
这是"业界首个由第三方机构基于国产算力集群完成的万亿级 MoE 全参数后训练工程实践"。把它和 Xing4.0 摆在同一条时间线上,一个模式就浮现出来了:2026 年,"国产算力能训练"这件事正在从单点验证变成多点重复。 一个是 29B 量级的全流程训练并开源,一个是万亿级模型的后训练工程化交付,参与者包括运营商研究院、高校、地方研究机构和设备厂商——不是某一家在证明什么,而是不同角色在同一套技术栈上各自跑通了一遍。
技术路线的验证,从来不是靠一次发布会完成的,而是靠第二家、第三家团队在同样的路上跑出接近的结果。
观察
回到那个 96%。
它是这份发布里最不"性感"的数字——不是 SOTA,不是新架构,不是刷新什么榜单。但它指向的问题,恰恰是过去两年国产算力叙事里最容易被跳过的那一段:芯片能不能跑模型,和芯片能不能被用出效率,是两件事。
29B/4B 的体量决定了 Xing4.0 不会成为某个榜单的统治者。它更实际的价值在另外几处:给做 Agent 产品的团队多了一个 Apache-2.0 的、可以单机私有化部署的基座选项;给做国产化适配的团队留下一条可复现的算子集成路径;也给行业提供了一份"训练吞吐能在同一批硬件上翻近一倍"的工程样本。
至于那 96% 的含金量,判断标准很简单:看它能不能被下一颗模型复用。 如果数值对齐、通信重叠、算子融合这些能力真的沉淀成了基础设施,那么下一个模型的开箱起点,就不会再是这次对比里的"开箱状态"。
(内容由AI生成,仅供参考)