科大讯飞把星火X2.5放出来的时候圈子里讨论最多的就是两个数字293B和30B。一个总参数规模2930亿一个激活参数只有300亿中间用MoE架构串起来再叠上“全国产平台训练”这个身份标签这套组合拳确实戳中了不少人的关注点。先说个结论这不是一次常规的版本迭代而是国产大模型在架构路线和训练体系上交出的一份答卷。293B-A30B意味着讯飞选择了和稠密模型完全不同的玩法通过MoE的稀疏激活机制用300亿激活参数去驱动一个接近3000亿参数的模型。这种“参数很多、每次只用一部分”的思路正是当前大模型在算力受限条件下冲效果上限的主流解法之一。这篇文章我想从工程和实战角度把它拆开聊MoE架构的核心逻辑是什么293B-A30B这个数字到底该怎么读全国产平台训练背后的技术难点有哪些以及这个模型的发布对做应用和做算法的人分别意味着什么。不管你是做模型训练、做推理部署还是单纯关注国产大模型技术栈这篇文章应该都能给你一些参考。1. 先拆清楚293B-A30B 和 MoE 到底是什么1.1 一个公式看懂 293B-A30B很多人第一次看到“293B-A30B”会有点懵两个数字到底什么关系。用大白话说293B2930亿是模型的总参数量包含了所有专家模块的全部参数A30B300亿是实际推理或训练时每个token激活并参与计算的参数量。打个比方一家公司总共雇了2930个员工总参数但日常处理一个客户需求只需要调动其中300个对口的人激活参数。剩下的人不是白养而是在处理不同类型需求时被分批调用。把2930亿参数全部塞进显存但每次只算其中300亿这就是MoE模型的本质逻辑。这个比例其实很有讲究。从公开信息看星火X2.5的激活参数占比大约在10%左右在主流MoE模型中算是比较常见的设定。对比来看DeepSeek-V3是671B总参数、37B激活参数激活占比约5.5%Qwen2.5-MoE是14.3B总参数、2.7B激活参数激活占比约18%。星火X2.5选择10%这个档位说明它在“专家多样性”和“单token计算量”之间取了平衡——专家分得够细每个专家可以更专精同时每个token的推理计算量也没有失控。1.2 MoE 的本质让稀疏机制替你省钱MoE的全称是Mixture of Experts混合专家模型。传统Transformer模型是稠密模型不管输入什么内容所有的参数都会参与计算。而MoE模型在Transformer结构的某些层里把原来的全连接网络FFN替换成了一组并行的“专家网络”每个专家本质上是一个独立的FFN模块。关键机制在于路由每个输入token会经过一个路由网络Router路由网络根据token的特征给它打分选出最合适的几个专家通常是top-1或top-2然后只把token送进这几个专家里计算。其他专家对这个token来说就是“围观群众”不参与计算。这个设计的直接好处就是省算力。理论上293B参数的稠密模型跑一个token需要算293B次浮点运算而MoE模型只激活30B参数单token计算量直接少了一个数量级。这就好比以前一个全科医生接诊所有病症现在换成30个专科医生坐诊虽然医院养了一堆专家很贵但每个病人只需要找对应的那两三个人看整体效率反而上去了。“养参数”很贵但“用参数”很便宜这就是MoE的核心经济账。1.3 为什么说“A30B”比“293B”更关键做模型选型或者推理部署的时候决定你GPU显存够不够用的很大程度是激活参数A30B和KV Cache而不是总参数。总参数决定模型文件的体积激活参数决定单次推理的计算量和吞吐上限。我实测过一些MoE模型以这个档位为例FP16精度下光权重文件就要占用约586GB显存293B × 2字节这已经超出了一张主流80GB显卡的承载能力必须用多卡张量并行才能装下。但推理时每个token只过30B参数单卡的计算压力反而接近一个30B稠密模型只是需要额外的显存来存其他专家的权重。所以“A30B”才是衡量实际运行成本的指标。这也是为什么所有MoE模型宣传时都会特别强调激活参数——它直接决定了你部署这个模型需要几张卡、跑一次推理大概什么速度。30B激活参数意味着单Token推理的计算量和跑一个30B级别的稠密模型基本处于同一水平但模型的上限能力却可以朝着290B级别的稠密模型看齐。这是MoE架构真正的魅力所在。2. MoE 架构的门道路由、专家分工与负载平衡2.1 从“一个模型干所有活”到“一堆专家各管一摊”Transformer里的FFN层前馈网络承担着大部分“知识存储”功能可以把它理解成模型的记忆中枢。稠密模型只有一个FFN所有知识不分领域地堆在里面维度越高知识容量越大但每次推理都得把这个大FFN从头到尾算一遍谁来了都一样。MoE的思路是把一个大FFN拆成几十个小FFN每个小FFN就是一个专家。星火X2.5的293B总参数大概率就是若干层MoE层加起来的结果。每个专家经过差异化训练后会自发形成某种“分工倾向”有的专家擅长处理数学推理有的擅长处理代码语法有的偏向中文语境理解。这种分工不是人工指定的是训练过程中涌现出来的。路由网络会学到什么样的token风格应该优先丢给哪几个专家。学过路由机制的人都知道这种“自发分工”有时会产生不均衡——这和现实中的团队协作一模一样如果分工不均个别专家忙到死其他专家闲到长草模型效果和训练效率都会崩。2.2 路由机制每个 token 怎么选专家路由机制是MoE的核心技术细节。最常用的做法是在Transformer层里加一个轻量的线性层作为Router输入token的隐藏表示输出每个专家的得分然后取top-k个专家。星火X2.5大概率采用的是top-2路由具体数量需要看技术报告确认也就是每个token激活2个专家。这是当前大模型MoE最主流的配置比top-1更稳定又不会让计算量翻倍。为什么top-2比top-1更稳定因为单个专家对某些特征明显的token可能判断得足够清晰但对模棱两可的token只选一个专家容易选错选两个相当于给路由上了份保险让两个专家各从不同角度处理同一个token最后把结果加权融合。路由权重本身也是参数在训练过程中和模型其他部分一起被优化。这带来一个有趣的结果路由网络不是简单地按“领域”分发token它学到的是一种更抽象的分发规律有时候连研究者都很难直观解释某个专家到底擅长什么。这属于正常现象不必过度解读。2.3 负载不均衡怎么办辅助损失与专家容量实际训练MoE时路由经常出现“偏科”问题——少数几个专家吃掉绝大多数token其他专家几乎学不到东西。这会导致两头都亏热门专家过拟合且计算成为瓶颈冷门专家欠拟合形同虚设整体效果上不去。解决思路基本靠两招。第一招是辅助损失也叫负载均衡损失它计算各个专家被分配到的token比例和均匀分布的差异把这个差异作为惩罚项加进总损失里。比例越不均惩罚越大模型会被迫学到一个更均衡的路由策略。第二招是专家容量限制每个专家每轮最多只能处理一定数量的token超过上限的token会被当作溢出处理通过残差连接跳过当前层直接送到下一层。容量限制在推理阶段也很有用可以让专家计算严格对齐硬件的并行能力避免某个专家的计算把整卡拖住。这两招在实际使用时要小心平衡。辅助损失的权重设太高会让路由强行均匀化牺牲了“专业分工”的表达能力权重设太低负载不均衡又会重来。业内常见的辅助损失系数在0.01这个量级具体需要根据训练曲线实测调整没有一刀切的公式。2.4 训练 MoE 的显存和算力账训练MoE和训练同等总参数的稠密模型显存压力其实没有想象中那么大。因为显存占用主要看总参数计算量主要看激活参数。训练293B总参数的MoE你需要先装下293B参数的权重加上优化器状态Adam优化器通常每个参数要额外8-16字节、梯度、KV Cache和激活值。粗略估算一下如果采用3D并行数据并行张量并行流水线并行在多卡集群上跑配合序列并行和重计算FP16精度下的显存需求大约是权重586GB梯度586GB优化器状态fp32主权重586GB 动量586GB 方差586GB激活值若干整体在2.5TB到3TB左右的总显存规模这是把显存压缩到极限的粗算。要让训练跑得舒服一些基本需要10到20张80GB显卡打底实际集群规模只会更大。这还没算通信开销。MoE天然是“All-to-All通信”的大户因为每个token可能被路由到任意一台机器上的任意专家跨节点通信量远高于稠密模型。这也是为什么MoE被认为是“通信密集型”架构网络带宽不够的话GPU再强也白搭。全栈国产平台的训练难度很大一部分就藏在这个通信环节里。3. 全国产平台训练这件事工程上有多硬核3.1 要在国产平台上跨过哪些坎“全国产平台训练”这八个字听起来很提气真正做到却要趟不少坑。所谓全国产不只是芯片国产而是从底层AI芯片、加速库、通信库、训练框架到上层的并行策略和精度调优整个技术栈都不能依赖外部闭源组件。也就是说那些在主流平台上开箱即用的东西在国产平台上大概率要自己动手适配一遍。首先是芯片层。国产AI芯片在算子生态和社区积累上和主流GPU还有差距有些算子要么没实现要么实现得不如主流平台高效。ReLU、LayerNorm、矩阵乘法这些基础算子还好但MoE里频繁使用的TopK路由、Dispatch/Combine把token按路由结果发往不同专家再收集回来这类定制算子就未必有现成的高性能版本了。其次是框架层。虽然当前主流开源训练框架可以跑在国产芯片上但“能跑”和“高效”是两回事。实际调优中经常要做算子融合、通信原语替换、显存分配策略调整这些都需要深入框架源码甚至芯片底层文档去改非常考验团队的底层功底。3.2 训练框架与通信库的适配细节MoE训练的通信模式比常规稠密模型复杂具体表现在两个方面All-to-All通信和负载均衡感知。All-to-All通信就是字面意思每张卡都得跟其他所有卡交换数据。某个token在A卡上被计算出了路由结果它要去的专家可能存放在Z卡上那就得把token的隐藏状态从A卡传到Z卡。这个过程如果通信库不高效整个训练吞吐会被通信等待拖垮。在国产平台上通信库的实现精度和高低性能直接决定了MoE训练的规模上限。我在现有实践中遇到过类似的情况同一套MoE配置换一个通信实现训练吞吐能差出30%到50%。排查到最后往往不是算力问题而是通信调度的问题。跨节点通信时网卡中断、缓存未命中、拓扑感知路由这几项稍不合理整体的吞吐就上不去。所以在国产平台上训MoE第一优先级是先把通信压测做透而不是急着把模型规模做大。3.3 稳定性千卡/万卡规模下的容错策略大模型训练跑在几百上千张卡上最怕的就是“跑着跑着挂一张卡”。稠密模型挂卡还能勉强忍受MoE模型的All-to-All通信让任何一张卡的故障都会迅速影响整个集群——某张卡挂了恰好去向它的通信全部失败整个训练任务直接卡死。实际训练中必须在框架层面做好容错设计。一种常见做法是周期性保存checkpoint并在检测到节点故障后自动重启、回滚到最近的checkpoint。听起来简单但工程上要考虑的点很细checkpoint多久保存一次保存过程中会不会阻塞训练故障恢复后通信拓扑如何重建每张卡上缓存的中间状态是否一致此外MoE的负载不均还会造成算力“空洞”——某些专家计算量过大拖慢整体步进时间某些专家闲置造成算力浪费。这个问题在国产平台上更明显因为硬件资源更紧张容不得浪费。实践中我们会在训练中加入实时的专家负载监控面板一旦发现某专家负载长时间偏高就动态调整路由策略或增加对应专家的副本数。这种基础设施性质的工程能力往往是决定训练成败的关键。3.4 对齐与精度混合精度训练的本地化调优大模型训练普遍使用混合精度FP16或BF16计算FP32做权重更新。国产AI芯片在FP16/BF16的算子实现细节上各有不同同样的模型在不同芯片上的最佳精度配置可能完全不同。MoE模型对精度变化更加敏感。路由网络是一个比较“脆”的模块它输出的token-to-expert分配结果本质上是一组离散选择精度不足时路由的打分排序容易抖动同一个token在不同训练步可能被路由到不同专家导致训练不稳定。这就好比团队主管每次分配任务的标准各不相同队员永远不知道接手的活是什么整个团队就乱了。实际调优时要注意几点第一路由模块和专家输出的关键计算环节尽量保持更高精度如FP32累加第二通信环节的梯度聚合需要考虑精度损失第三Loss曲线出现异常震荡时先检查路由部分的数值范围再做全模型精度调整。大规模训练里细节决定成败这句话一点不虚。4. 星火 X2.5 带来的实际变化与应用想象4.1 从模型能力看这个架构吃到了哪些红利选择MoE架构最直接的收益就是“同等计算成本下塞进了更多参数”。300亿激活参数逼出了2930亿总参数的潜力这让模型的知识容量和复杂模式表达能力比以往稠密版本更有底气。具体到能力上MoE架构对提升多任务并行能力尤其有帮助。稠密模型所有任务都在同一套参数里竞争空间可能出现“学代码忘了数学”的跷跷板效应。MoE模型通过专家分工不同能力的知识被分散到不同专家中互相干扰更小。这就像一个团队里有专门负责数学的人、有专门负责代码的人各司其职整体作战能力自然更强。对讯飞而言星火在教育、医疗、办公等垂直领域有大量应用场景这些场景往往需要同时应对专业问答、推理、文本生成等多种任务MoE架构的天然分工优势刚好对得上。4.2 理性看待跑分MoE 模型评估不能只看榜单每次有新的MoE模型发布总能看到一些榜单和数据对比。但评估MoE模型要格外谨慎因为它的“benchmark表现”和“实际体验”之间可能存在不小的落差。MoE模型的评测得分高度依赖任务类型。对于专业知识密集型任务MoE有明显优势——总参数量大专家多存储的知识面更广但对于强推理任务比如数学证明、复杂逻辑链效果则更多取决于路由机制和专家间协作的质量参数量大并不等于推理能力强300亿激活参数本质上仍然是30B模型在做推断只是它可调用的“知识文档”更丰富。所以看星火X2.5的评测数据时建议关注它在垂直领域的表现以及在实际业务场景中的体验。榜单是方向参考不是真理。4.3 对应用开发者的实际影响对做上层应用的开发者来说星火X2.5发布带来的最大信号是国产MoE模型的API调用成本有望进一步走低。MoE的激活参数只有30B意味着服务商提供的单次推理算力成本远低于一个293B稠密模型的成本相应地API定价就有更多下降空间。另外MoE模型在处理长文档、多轮对话等长上下文场景时KV Cache的占用也会随激活参数的相对紧凑而更有余地应用侧可以尝试更长的上下文窗口而不至于把显存撑爆。如果你是做RAG检索增强生成或Agent类应用的MoE模型的“多专家分工”特性在适配多领域工具调用方面会有一定优势。不同工具的使用规范可能被不同专家重点学习路由机制会自动把工具调用类问题分发给对应专家处理这在应用层是一种潜在的体验优化红利值得实测验证。5. 常见问题与避坑参考5.1 显存占用怎么估算部署至少要几张卡很多人在部署前关心的问题就是我手里的卡到底行不行。以星火X2.5为例权重文件在FP16下约586GB如果你用FP8量化则减半到约293GB。但部署不只是权重还要算上KV Cache、计算图中间结果和通信缓冲。按工程实践来看部署一个293B总参数的MoE模型用8张80GB显卡做张量并行是相对舒服的起步配置8×80640GB总显存刚好覆盖权重加基础开销但留给KV Cache的空间比较有限建议搭配量化使用。如果想同时支撑较高并发需要把显存抬到12~16张卡的规模或者引入更激进的量化方案。这里有个容易踩的坑MoE模型的显存占用和并发之间是非线性关系。因为虽然单个token只激活30B参数但每个请求的KV Cache还是要按模型的注意力层维度存请求多了KV Cache照样暴涨。实际规划时一定按“权重显存 平均请求长度 × 并发数 × KV Cache大小”来核算不能只盯着激活参数算。5.2 训练稳定性的几个排查方向如果你在自己的集群上训练MoE模型遇到过Loss突然飙高或训练崩掉的情况建议按这个顺序排查。第一看路由负载。用日志工具统计每个专家的token接收量如果某个专家接收量突然归零或突增很可能路由出了问题。第二看辅助损失数值如果负载均衡损失在训练后期不降反升说明路由策略在震荡需要调整辅助损失的权重。第三看通信延迟All-to-All耗时如果逐步累积一般不是网络硬件坏了而是路由策略让某些专家负载过高通信热点集中在特定节点。第四看数值范围路由打分出现NaN或Inf大概率是前面层的精度问题需要回退到更高精度的计算路径。5.3 想在本地尝试 MoE 模型有什么建议很多关注大模型的朋友想在自己机器上试MoE模型我的建议是别直接挑战293B这个量级先从开源的小MoE模型入手。比如有些几十亿参数的开源MoE模型在单张24GB显卡上就能跑起来体验一下“总参数很大但激活参数小”的推理感受是完全够用的。重点体验两个东西一是MoE模型在同样显存下和同等激活参数的稠密模型相比回答的丰富度和知识广度是否有明显提升二是路由机制的实际效果找一些跨领域的问题去测感受模型是否在数学、代码、常识之间顺畅切换。跑通了小模型再去评估要不要在更大规模的MoE上投入资源思路会更清晰。5.4 给团队的选型建议业内不少团队在评估是否使用MoE架构我的建议是不要为了MoE而MoE。如果团队算力和工程能力有限继续用稠密模型把垂直场景打磨透可能是性价比更高的选择。MoE的优势要在大规模算力和大规模数据的前提下才能充分兑现小团队训MoE很容易陷入“专家负载不均调不回来、集群通信压测做不透”的困境。如果决定用MoE请优先确保团队具备三点能力集群通信调优能力、训练稳定性保障能力、数据并行和专家并行的工程整合能力。这三样缺一MoE给你带来的就只是参数量上的虚荣感实际训练效率可能反而不如稠密模型。写在最后从星火X2.5这次发布能看到MoE架构已经从“圈内人才研究的黑科技”逐步变成大模型产品化的常规选项全国产平台训练更是把技术栈自主这件事从口号变成了工程实践。我接触过一些在国产算力平台上做训练的团队很理解这份成绩的重量——通信适配、算子补全、容错设计每一个环节都需要研究人员和工程师沉下心去磨。我个人在实际操作中的体会是MoE模型就像一个庞大的专家智库参数是知识储备路由是调度机制。真正决定智库价值的不只是里面有多少书更在于每次提问时能否快速找到最合适的那几本。从这个角度看星火X2.5迈出的这一步不只是参数规模的升级更是对“如何让知识被更高效地调用”这个问题的一次积极探索。后续这个架构在真实业务场景里能跑出什么成绩比发布时刻的纸面数据更值得期待。