万卡国产训推之后，科大讯飞开始让AI反哺算力

最近几个月，国产 AI 算力开始密集跨过一个新的数量级。

7 月，全国产十万卡 AI 超集群落成；9 月初，无锡国产万卡级智算中心一期 2000 张摩尔线程 MTT S5000 GPU 智算卡已全部投入运行，集群算力需求基本达到满载；国产卡正在进一步向万卡乃至十万卡级训练基础设施迈进。

无锡（惠山）国产智算中心机房内

集群规模越来越大，新的问题也随之而来：这些芯片究竟能发挥出多少实际训练能力？

大模型训练里，卡数增加的同时，系统复杂度也会跟着上升。一块芯片上的算子效率差异，放到数万块芯片上会不断被放大；小规模训练里不太显眼的通信等待，到了万卡集群会变得很可观；节点数量增加、训练周期拉长之后，软硬件故障也会更频繁地进入日常运维。

因此，评价一套算力系统，除了看芯片数量和单卡性能，还要看算子、通信、并行调度、故障恢复以及软件栈之间能不能配合起来。

最近一个新发布的模型引起了我们的注意。

9 月 7 日，科大讯飞正式发布星火 X2.5。该模型采用 MoE 架构，参数规模为 293B-A30B，重点提升代码和智能体能力，同时覆盖 200 余种语言，在语言理解、答题、推理等通用任务上保持优异效果。

其中，万卡规模国产 910B 集群承担了模型的预训练和后训练，线上推理基于国产平台，并配合多步投机解码提升推理效率。值得一提的是，随着代码和工具调用能力增强，星火 X2.5 也开始参与 NPU 算子优化，AI 开始反过来参与底层算力的优化。

通过这次真实的大模型训练，也可以进一步探讨万卡国产算力面临的几个具体工程问题：算子效率、长上下文处理、万卡通信和长周期训练稳定性，以及模型与底层算力之间正在形成怎样的反馈关系。

这次星火 X2.5 的训练优化，也基本围绕这些问题展开。

万卡国产芯片，怎么真正干活？

可以把大模型训练想象成一座超大型工厂。

万卡集群里的芯片，是成千上万名「工人」；显存是存放模型参数、上下文和中间数据的「仓库」；通信网络则是芯片之间交换数据的「运输通道」。当规模扩大到万卡级，计算速度、显存容量、通信效率和系统稳定性，都会直接影响整座「工厂」的效率。

而推理和训练，对这座「工厂」的要求并不相同，这也是「推理适配」和「全国产训推」的关键区别。

推理适配主要解决模型能否在国产芯片上高效部署运行；完整训练还涉及参数持续更新、跨卡同步、数值稳定和长周期故障恢复，因此对整套系统协同提出了更高要求。

科大讯飞技术人员把万卡训练的核心挑战概括为：算得快、装得下、传得顺，以及跑得稳。

先看「算得快」。

对这座工厂来说，芯片数量决定了有多少「工人」，算子效率则影响每个「工人」实际能干多少活。模型训练中的 Attention 等核心计算，最终都要通过算子落到芯片上执行。算子效率高不高，会直接影响芯片真正能够发挥出多少计算能力。

针对星火 X2.5，团队围绕国产关键算子进行了定向优化。科大讯飞相关技术人员表示，其中 Attention 计算算子效率相比基础实现提升 2 倍以上。

单颗芯片算得快还不够。到了万卡规模，另一个问题是「怎么分工」。

训练任务会被拆分到大量计算单元上，如果不同芯片承担的任务量不均衡，就可能出现一部分已经算完、另一部分还在继续运行的情况。规模越大，这种等待越容易被放大，最终拖慢整个训练过程。

针对长序列训练，星火 X2.5 采用结合动态负载均衡的长序列并行方案，让不同计算单元承担的任务更加均衡。科大讯飞相关技术人员表示，该方案使长文本训练效率相对提升 30% 以上。

第二个问题是「装得下」。

模型越大、上下文越长，无论训练还是推理，需要处理和暂存的数据都会增加，「仓库」压力也会随之上升。这里比拼的并不只是显存容量，还包括如何减少长上下文带来的计算和资源开销。

在模型结构层面，为提高长程任务的推理效率，星火 X2.5 引入稀疏注意力机制和跨层共享稀疏注意力索引，进一步减少资源开销。

稀疏注意力的思路，是把更多计算集中到真正需要关注的信息上，减少不必要的计算；跨层共享索引，则让不同计算层复用已经建立的索引，减少重复开销。简单说，就是尽量少做无效计算，也少做重复工作。

第三个问题是「传得顺」。

到了万卡规模，「运输」也会成为瓶颈。大模型训练不是每张卡各算各的，不同芯片之间需要持续交换训练数据和状态。集群越大，通信关系越复杂，一旦数据传输跟不上，前面的计算能力就会被等待时间吃掉。

尤其在超长序列训练中，序列被拆分到更多计算单元之后，跨卡通信还会进一步增加。

针对这一问题，星火 X2.5 在通用通信优化之外，还针对超长序列带来的通信开销，引入通信压缩、分层通信和计算并行等方式。科大讯飞相关技术人员表示，相关训练效率提升 10%。

其中，通信压缩可以减少需要交换的数据，分层通信则根据不同层级的互联关系组织数据交换；再结合通信掩藏等机制，目的都是尽量降低超长序列训练中的通信开销和等待时间。

最后是「跑得稳」。

工厂规模越大、运行时间越长，设备故障越难完全避免。对于万卡训练来说，真正重要的是能不能尽快发现问题、隔离问题，并把受影响的训练任务恢复起来。

科大讯飞相关技术人员表示，在训练稳定性保障方面，星火 X2.5 结合国产芯片提供的全域异常检测能力，基于对数十万训练任务的问题分析，实现了任务配置训前校验、训中卡死自动检测、失败任务自动重提、历史固定报错节点自动剔除，以及故障时进程级快速恢复和取消任务时的临终 checkpoint 保存，机器有效训练时长超过 97%。

checkpoint 即训练过程中的「存档」。训练运行到一定阶段后保存当前状态，一旦后续出现故障，就可以从较近的状态继续恢复，而不必重新开始。

所以，万卡集群的价值并不只由芯片数量决定，还需要整套训练系统能否长期稳定运行并高效协同。

模型训出来之后，还能做什么？

星火 X2.5 这次重点提升的，是代码和智能体能力。

训练阶段，模型围绕数学、编程、智能体工具调用和指令遵循等任务开展大规模强化学习，并训练不同领域的教师模型，再通过多教师在线策略蒸馏（MOPD），利用学生模型在线生成的轨迹构建针对不同能力的训练信号，将多个教师模型的优势有效整合到统一的发布模型中。

简单说，就是让各有所长的「老师」分别指导，再把这些能力汇总到一个模型中。这些能力在代码任务上的体现比较直观。

此次披露的测试覆盖 Terminal Bench、SWE Pro、SWE Verified、SWE Multilingual、NL2Repo 和 SciCode 等任务。它们关注的内容已经延伸到终端操作、真实代码仓库修改、多语言软件工程和科学编程等场景。

我们来看几个实际演示。

在 Web 前端生成案例中，用户只需要给出自然语言需求，模型就可以结合图像生成等工具完成一个完整网页，从页面布局、视觉设计到滚动动画和交互效果，都包含在同一个任务里。

而在人机交互案例中，模型还需要将视觉识别与角色反馈结合起来。比如，用户要求制作一个可以通过手势与像素风猫咪互动的网页，模型需要完成摄像头调用、视频流处理、手势识别，并将不同动作映射为猫咪的相应反馈，如靠近、击掌、安抚等，同时完成角色动画、交互逻辑和页面调试，最终生成一个可以直接运行的趣味互动 Web 应用。

这些案例的意义不仅在于模型能否生成一个网页，更在于代码能力和智能体能力正在合流：模型先理解任务及约束，再把复杂目标拆解为多个步骤，调用工具执行代码，并根据错误信息或运行结果持续修正。

当这一闭环从网页开发迁移到底层软件领域，模型处理的问题也会从「代码能否正确运行」，延伸到「在保证正确性的前提下，代码能否在真实硬件上跑得更快、更高效」。算子优化正是这类任务的代表。

那么，当模型具备这种「理解—拆解—执行—反馈—修正」的闭环能力后，它能否进一步参与自己所依赖的底层算子和软件栈优化？

这就涉及 NPU 算子优化。

算子优化本身是一项门槛很高的工作。工程师需要理解硬件架构、编程接口、访存方式和性能分析工具。代码能够正确运行之后，还要继续做性能剖测，判断时间主要花在计算、访存还是数据搬运上，哪些实现没有充分利用芯片能力，又应该怎样调整。

为了让星火 X2.5 具备这类能力，科大讯飞在无监督训练阶段，基于 GitCode 上的优质昇腾算子仓库，构建包含 CANN 编程规范和典型高性能实现模式的训练语料，让模型学习昇腾硬件体系下的编程知识；进入后训练阶段，又围绕真实开发场景构建大规模、可验证的算子效率优化任务，让模型直接在真实 NPU 环境中进行开发设计、性能剖测和迭代优化。

可以把这个过程理解成给模型增加了一间「实验室」。

模型先写出一版代码，在真实芯片上运行，拿到性能结果，再根据结果继续修改。下一轮重新编译、重新测试，直到找到更合适的实现方式。不过，这并不意味着模型可以在没有任何条件的情况下独立完成底层系统开发。在当前实践中，任务目标、初始代码、硬件环境和评估脚本仍然需要预先设置。模型的作用，是在这些条件下进行多轮工具调用和方案探索，提高部分算子开发与优化环节的自动化程度。

DSA 细粒度稀疏注意力算子，是这次披露的一个具体例子。

DSA 面向长上下文场景，通过集中计算关键部分来减少计算量。不过，稀疏计算也会带来更零散的数据访问，数据搬运效率会成为新的影响因素。

在仅提供基础版 Ascend C 实现、任务描述和评估脚本的情况下，星火 X2.5 在昇腾 910B 设备上进行了多轮自主优化。科大讯飞相关技术人员表示，模型通过约 1600 次工具调用探索不同性能方案，最终相比 torch_npu 实现获得 3.5 倍加速。

一次万卡训练，能留下什么？

大模型训练结束后，最直观的产物是一组模型参数。

但从星火 X2.5 这次训练可以看到，国产训推的价值正在向多个层面延伸：训练经验可以进一步沉淀为平台能力，既有优化方法正在向不同国产硬件环境迁移，模型本身也开始参与底层算子调优。这些变化共同影响着万卡集群能否从基础设施投入，转化为持续产出模型能力的训练系统。

大模型持续更新，Attention、MoE、长上下文和智能体强化学习不断对算子性能、显存带宽、集群通信、并行调度和故障恢复提出新要求。每一次完整训练，实际上也是对底层软硬件体系的一次压力测试。

如果优化后的算子、通信策略和恢复机制能够被固化进训练平台，后续模型就不必重复完成相同的适配工作。工程团队也可以把更多资源投入新的模型结构、训练方法和应用任务。

这种积累的价值会随着训练次数增加而放大：一次项目中的临时优化，有机会逐步转化为能够被后续模型复用的平台能力。

进一步的问题，是这些能力能否从单一硬件环境迁移到更多国产平台。

不同国产 AI 芯片在计算架构、编程接口、通信方式和性能分析工具上存在差异，迁移时仍需要重新处理算子实现、并行策略和工具链衔接。科大讯飞表示，除昇腾外，团队也在寒武纪 MLU590、中科海光 BW1000 等国产芯片上开展大模型训练效率的适配和优化。

因此，可以进一步关注更换硬件后需要调整多少代码、既有并行策略能够保留到什么程度，以及迁移后的性能表现。迁移成本越低，既有训练能力覆盖更多国产平台的难度就越小，针对单个项目形成的优化经验也更容易沉淀为可复用的通用方法。

与此同时，模型本身也开始进入这套工程循环。

星火 X2.5 已具备在真实 NPU 环境中进行开发设计、性能剖测和迭代优化的能力。前文提到的 DSA 案例，也体现了这种「生成—运行—反馈—优化」闭环在算子性能调优中的实际效果。

这说明，模型已经能够在真实 NPU 环境中通过多轮工具调用持续探索更优实现，能力边界也由代码生成进一步延伸到了实际性能调优。随着这一过程逐步成熟，模型在底层软硬件优化中的参与程度正在进一步加深。

于是，一条反馈链逐渐清晰：国产算力训练大模型 → 模型获得代码和工具调用能力 → 模型参与 NPU 算子优化 → 优化经验进一步沉淀为工程能力 → 反哺后续模型训推。

这套循环既影响当前训练效率，也影响后续迭代速度。算子、通信和调度优化可以减少计算与等待时间，故障恢复机制可以提高有效训练时长；经过验证的代码、性能数据和优化方法，也可以进一步沉淀为后续训练可复用的工程资产。

结语

回到科大讯飞这家公司，星火 X2.5 展示的不只是一次模型训练，而是训练、推理和底层算力适配之间正在形成更紧密的技术联系。完成国产算力万卡训练是其中一个重要节点，而这些环节正在逐渐形成一套彼此衔接的技术体系。

随着这些优化不断被验证和固化，这套体系也有望沉淀出一套可复用的工程能力。算子优化、分布式训练、故障恢复、软硬件适配和工具链建设，都可以继续服务后续模型迭代。随着工程体系逐步成熟，新模型的训练、迁移和部署成本，也有望进一步下降。

科大讯飞的另一个特点，在于教育、医疗、企业服务等长期积累的行业场景能够持续提供真实需求和反馈。业务提出新的问题，模型随之迭代，底层系统再根据训练和推理结果持续优化，由此形成从应用需求到模型升级、再回到业务落地的循环。

当这一循环稳定运转时，全国产训推对科大讯飞而言，就不只是一次技术路线选择，而会逐步沉淀为长期的工程优势。

文章来自于微信公众号 “机器之心”，作者 “机器之心”