一个 29B 的模型，每步只动用 4B
9 月 17 日，中电信人工智能科技有限公司开源了新一代星辰大模型 Xing4.0-29B-A4B。它是星辰系列（早期名为 TeleChat）的第四代，权重已经放在 Hugging Face 上，官方对它的定位是「面向智能体时代的轻量级代码智能体大模型」，主要能力指向复杂任务理解、任务规划、工具调用与自主执行。
规格表里值得先看的是激活比例。总参数 29B，每个 token 只激活 4B。
这个比例对应的是 MoE 架构下的常规做法：用较大的总参数撑住知识容量，用较小的激活量压住推理成本。具体配置是 64 个路由专家加 1 个共享专家，每 token 选中 4 个；网络共 40 层，隐藏维度 3584，稠密中间层 9216，专家中间层 1024；注意力用 MLA，原生支持 256K 上下文，可扩展至 512K。
这些配置组合起来指向的使用场景很具体：多步规划、工具调用与长链推理。共享专家的存在是为了兜住那些不适合丢给任何一个路由专家的通用能力，属于这类架构里的常见折中——它保证模型在路由判断出错时不至于完全跑偏，代价是每个 token 都要为它付一份计算。
96% 的吞吐提升从哪里来
比架构更能说明问题的是训练侧。官方称，Xing4.0-29B-A4B 是这个参数规模上全程在昇腾 NPU 平台与 MindSpore 框架上完成训练的模型，训练底层做了五类协同优化：mHC 特性适配与 Ascend C 融合算子开发、细粒度 MoE 通信优化、选择性重计算、DVM 自动图算子融合，以及 Ascend C 的 mHC 融合算子。
这些优化合起来带来的结果是：相比开箱性能，整体训练吞吐提升约 96%。
这个数字的写法本身值得留意。它以「开箱性能」为基线，而不是以别家硬件为基线。换句话说，它度量的是「同一套国产软硬件栈，在做过针对性适配与没做过之间差多少」。五类优化里有四类直接落在通信与算子上，说明在这个规模上，瓶颈不在单卡算力，而在专家之间的通信开销、显存占用，以及算子调用的调度效率。
把它换算成采购语言就是另一回事了：如果一家企业拿到的是一套需要自己适配的软硬件组合，那接近一倍的吞吐差距就是集成成本的一部分，而不是性能差异。
跑分要按项目分开看
官方公布的评测覆盖了几类差别很大的任务。
把 SWE-bench Verified 的 75.0 与 AIME2026 的 90.0 放在同一张表里并不合适——前者衡量的是在真实仓库里修缺陷，后者衡量的数学推理。两者都需要长链推理，但出错后的代价完全不同：前者错一次是一次失败的提交，后者错一次只是一个错答案。
真正值得关注的对照是 Terminal-Bench 2.1 的 57.5。终端任务是最接近「智能体实际干活」的基准之一：它要求模型在真实 Shell 里完成多步操作，容错空间小。官方给出的说法是这个成绩高于对比的 Gemma4-26B-A4B，并自述整体表现与 Qwen3.6-35B-A3B 大致相当。这是厂商口径，本文没有找到第三方独立复现记录。
生态适配比跑分更能说明定位
发布材料里另有一段容易被跳过：这个模型在微调侧支持 LLaMA-Factory 与 MindFormers，在推理部署侧支持 SGLang、vLLM 与 KTransformers，并针对 OpenCode、Claude Code、OpenClaw 与 Hermes 等智能体框架做了定向适配与格式对齐。
这条信息的含义比跑分更明确。它说明发布方的预期不是「用户换到自己的 harness」，而是「把自己的模型塞进用户已经在用的 harness」。对一个后来者来说，这是更现实的路径：智能体框架的迁移成本高，模型的替换成本相对低。凡是要说服团队同时换模型和换框架的方案，落地阻力都会大一个量级。
但这条路径也有它的天花板。适配意味着对齐别人的工具调用格式、上下文组织方式与提示词习惯，而这些接口由框架方定义、且会随版本变化。适配清单越长，维护面越大。
下载量揭示的另一半现实
同日公开的一场访谈里，有一段比技术参数更能说明市场位置的内容。
中电信人工智能公司副总经理杨戈给出的对照是：Hugging Face 上国内下载量靠前的那一批模型月下载量在 30 万到 50 万之间，而自家约 3 万，差一个量级；他同时表示「还在牌桌上」。他还提到，公司自 2023 年 11 月成立以来从头部互联网公司引入多位人才，目前 1200 多人中九成以上为社会化招聘，平均年龄 30 岁出头；首轮增资由国家人工智能基金领投。
关于办公场景，他的判断是各平台差距在收窄——在 WorkBuddy、豆包工作与千问办公同时争夺入口的情况下，他认为自家相对领先的只剩模型的执行性能与 Token 消耗，而「安全可控」是 TeleAgent 相对难以被复制的部分。这段自述里承认的部分，比强调的部分更有信息量。
把它和模型开源合起来看，能看出一次分层：模型层用开源换技术信誉与生态接入，产品层用一个不易复制的属性（这里是安全可控）去守企业客户。两条线的目标不同，不能用模型的下载量去评价产品，反过来也一样。
选型时可以问的三个问题
其一，你的智能体框架有没有被官方点到名。适配清单里有的框架，工具调用格式与上下文组织通常已经被对齐过；不在清单里的，兼容要自己补。
其二，256K 上下文是标称还是可用。长上下文的实际体验取决于推理引擎的显存管理与注意力实现，而不是规格表上的数字。验证方式只有一个：拿自己的长文档跑一遍。
其三，国产栈的「开箱与优化后」差距会不会变成你的成本。96% 这个数字的基线是开箱性能，说明未适配状态下可用吞吐只有优化后的约一半。对自建推理集群的团队，这是一笔需要提前算进去的账。
需要标注的边界
这篇稿件的技术参数全部来自模型卡、官方发布材料与公开访谈，跑分为厂商自报，尚无第三方独立评测。96% 的训练吞吐提升是官方口径，对照基线是同一套栈的开箱性能，具体测试条件与复现方法未同步公开。
另外，一个模型在发布当天的成绩与它三个月后的表现不是同一件事。智能体任务对模型的稳定性、工具调用格式的容错度与长上下文的一致性都更敏感，这些指标往往需要几轮真实使用才会暴露。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。