讯飞星火 X2.5:293B 只激活 30B,全栈国产算力

关键词:星火 X2.5、科大讯飞、MoE、国产算力、昇腾、端侧大模型、Agent


目录


一、9 月 7 日:训推全流程都放在了国产算力上

9 月 7 日,科大讯飞正式发布星火 X2.5 大模型。模型采用 MoE 架构,参数规模 293B-A30B,重点提升代码与智能体能力,数学、理解等通用能力持续增强,目前已上线讯飞开放平台。

同一天还有两个动作:多语言版本 Spark-X2.5 在讯飞星辰 MaaS 平台上线,支持 200 余种语言;而在 9 月 1 日,讯飞全资子公司词元星火已经先行开源了 X2.5-4B 与 1.7B 两款端侧模型。端侧先行、旗舰压后,是这个发布节奏里刻意安排的顺序。

这条消息里最值得琢磨的不是参数,而是那句「基于全国产算力完成全流程训练及推理」。过去一年,国产大模型在训练侧使用国产芯片的案例已经不少,但把推理侧也一并放进来、并且同时开源端侧版本的并不多。训练和推理都跑通,意味着这条链路不再只是"能训出来",而是"能持续对外服务"。

把视角拉远一点看,这件事的分量在于它回答了一个更硬的问题:在没有最先进海外加速卡的前提下,一个 2930 亿参数的旗舰模型能不能被完整训出来、并且以可接受的成本对外提供? 讯飞这次给出的答案至少在工程上是成立的。

为什么这个问题值得单独拎出来说?因为对一个要长期运营的 AI 服务来说,算力供给的确定性比峰值性能更关键。采购受外部因素影响而中断,模型再强也服务不了;反过来,哪怕单卡性能差一截,只要集群规模能线性堆上去、软件栈能把效率榨出来,整条链路就是可控的。全栈国产换来的不是"性能领先",而是供给侧的确定性——这个价值在政企、金融、能源这类有明确合规要求的场景里,往往比几个百分点的 benchmark 分数更值钱。

还有一层容易被忽略的:训推同构能省掉一整类工程麻烦。训练在 A 平台、推理搬到 B 平台,意味着精度对齐、算子兼容、性能调优这些活要重做一遍,长链条任务里最容易在这种迁移环节冒出难以复现的 bug。训推全流程放在同一套栈上,至少把这类风险从根上削掉了。


二、293B-A30B:这个配置是为国产算力设计的

先解释这组数字。293B 是总参数量,A30B 是每次推理实际激活的参数量——激活比约十分之一

图一:MoE 架构与激活比

在这里插入图片描述

(图一:全部专家权重决定显存占用,被选中的专家决定算力开销;激活比约 1/10)

这个设计的取舍很清晰:

  • 293B 决定能力上限。参数总量够大,模型才有足够的知识容量和表达能力。
  • 30B 决定单次推理的算力开销。每次前向只走被路由选中的一小部分专家,实际计算量接近一个中等规模模型。

换句话说,它的推理成本不像一个 2930 亿参数的模型,更像一个 300 亿参数的模型。这正是"能在国产算力上以可接受成本对外服务"的关键——如果按稠密架构训 293B 并全量激活,在国产集群上的服务成本会难看得多。

支撑这套训练的,是讯飞与昇腾自 2022 年起共建的万卡级算力平台「飞星一号、飞星二号」。据华为计算方面的披露,双方通过联合攻关把大模型在昇腾基础软硬件上的训练效率从最初的 30%~50% 提升到 85%~95%;2025 年进一步攻克了长思维链强化学习和 MoE 模型全链路训练的效率难题,相关训练效率达到业界产品的 90% 以上。

这组数字比模型参数更值得记住——国产算力的可用性从来不是"能不能跑"的问题,而是"跑得多高效"的问题。从 30% 到 85% 以上,是三年工程攻坚换来的。

不过 MoE 也不是白拿的好处,它把问题从"算力"搬到了"显存和通信"上,这一点在国产算力上尤其明显:

  • 显存压力按总参数算。293B 的权重一份都省不掉,全部得常驻在集群显存里。所以 MoE 省的是计算量,不是存储量——部署时要按 293B 准备显存,而不是按 30B。
  • 专家路由带来跨卡通信。路由把不同 token 分给不同专家,而专家通常分散在多张卡上,这就多出一步 all-to-all 的数据交换。集群规模越大,这步的开销越敏感,对互联带宽的要求也越高。
  • 负载均衡是门手艺活。如果路由把大部分 token 都推给少数几个"热门专家",那几张卡会跑满、其余的闲着,实际吞吐反而上不去。训练时得靠辅助损失之类的手段去约束路由分布。

理解了这三条,就能明白为什么"293B-A30B + 万卡国产集群"是一个相互咬合的设计:MoE 把单次计算量压到国产单卡能承受的范围,而集群规模与互联能力决定了 293B 的权重能不能放得下、路由通信能不能扛得住。 单独拿其中任何一条出来看都说明不了问题。


三、端侧先行:4B/1.7B 开源,100 万 Token 怎么做到

9 月 1 日开源的 X2.5-4B 和 1.7B,打出的旗号是「端侧模型中首个原生支持最长 100 万 Token 上下文」。这两款模型以 Apache 2.0 许可开源,权重已上线 Hugging Face、ModelScope、GitHub。

这里要先澄清一个容易混淆的点:100 万 Token 是端侧 4B/1.7B 的能力,旗舰版 X2.5 支持的是 256K 上下文。两者不是一回事,看报道时容易看串。

那么 4B 的小模型是怎么吃下 100 万 Token 的?答案是混合注意力机制

图二:端侧混合注意力机制

在这里插入图片描述

(图二:每 4 层为一组,1 层全注意力建宏观联系、3 层滑动窗口看局部细节;跑满 100 万 Token 时显存占用约为传统方案的 1/4)

具体结构是:36 层,每 4 层由 1 个全注意力层 + 3 个滑动窗口注意力层(滑窗 512) 组成,配合 GQA 分组查询注意力(4 个 KV 头、16 个注意力头)。全注意力层负责通读全文建立宏观联系,滑窗层只关注局部细节——这个分工把长序列的计算开销压了下来,官方称跑满 100 万 Token 时显存占用仅为传统全局注意力模型的四分之一

对端侧场景来说,这个数字是决定性的。端侧设备的显存就那么多,如果 100 万 Token 一塞进去就爆显存,那"长上下文"只是纸面参数。

另一个技术点是后训练用的 MOPD(多教师在线策略蒸馏):由多个单科专家大模型当老师,实时指导小模型逐步完成工具调用、错误检查与重试,从而获得复杂智能体任务能力。这解释了为什么 4B 模型在工具调用类基准上能有不错的表现——它的 Agent 能力是从更强的模型那里"蒸馏"出来的行为,而不是自己摸索出来的。

部署层面也做得比较实在:硬件覆盖英伟达、华为昇腾、海光、后摩;推理框架支持 vLLM、SGLang、llama.cpp;Ollama、LM Studio 可一键拉起。昇腾侧在 Atlas 800 A2/A3、Atlas 300 系列提供 BF16/INT8,Atlas 850E 超节点支持到 FP8。


四、代码与智能体:官方成绩与一手实测的落差

官方把这次升级的重点放在代码与智能体上。端侧 4B 在公开评测表中给出了一组不错的数字(thinking 模式):

基准得分类型
SWE-Bench Pro44.4代码
SWE-bench Multilingual53.3代码
SWE-Bench Verified41.6代码
τ³-bench30.4多轮工具调用
MCP-Atlas54.6MCP 工具调用
BFCL-V465.1工具调用
AIME 202690.7竞赛数学
高考 2026(满分 150)133.4数学
GPQA67.4专家级知识
BrowseComp40.9自主信息检索

官方称 X2.5-4B 在 τ³-bench、MCP-Atlas、SWE-Bench Pro、AIME 2026、HMMT 等 12 项基准上为同级别模型最高,部分项目得分超过参数规模更大的模型。

这组数字需要打一个折扣看:它们均为官方自报,截至发稿未经第三方独立复测。 这在大模型发布里是常态,不是讯飞独有的问题,但引用时应当留出余地。

更值得参考的是第三方的一手实测。有媒体在发布当天把旗舰版接入 DeepSeek Harness 做了几组测试:

  • HTML 枪战游戏:首版有玩家没敌人,反馈后修复,两轮合计 17 分 30 秒交付,累计 Token 约 238.8 万(其中缓存读取 227.9 万)。最终成品支持移动射击、换弹、分波次敌人,可玩性较高。
  • AIMO 数学参考题:正确解答。
  • 穿越小说写作:能抓住爽文的冲突与逆袭节奏。
  • 网页前端:框架搭起来了,但排版和产品质感一般。
  • 3D 创作(鹈鹕骑自行车):多次运行失败,最终未能交付。

图三:定价与一手实测

在这里插入图片描述

(图三:左为 API 定价,右为第三方实测的成败分布;底部是需要留意的落差)

这张实测成绩单比 benchmark 更有信息量:模型在指令清晰、有明确验证信号的任务上表现稳定(游戏、数学题),但在需要长链条自主生成的创作类任务上会翻车(3D 多次失败未交付)。这个分布不是偶然——长程自主执行本来就是当下 Agent 研究的普遍短板,一些公开的基准测试里,模型作为"调度者"跑长任务的成功率也只在两成到三成徘徊。所以这更像是行业共性,而不是某一家模型的问题。

判断口径可以记一条:看一个模型的 Agent 能力,别只看它能不能跑通,要看它在第几轮开始跑偏。 指令越开放、验证信号越弱,跑偏得越早。上面的 3D 创作任务正是"没有任何中间反馈可依据"的典型,失败最集中的地方也就在这里。

顺带一提,1.7B 在智能家居控制场景的实测数据挺亮眼:Domux 测试集上控制指令端到端执行正确率 90.3%,平均响应 0.85 秒。这种"小而专"的落地路径,可能比旗舰刷榜更符合端侧模型的真实价值。


五、价格与获取:限时 5 折,正式定价没时间表

旗舰版 X2.5 的 API 定价(每百万 Token):

项目限时 5 折原价
输入1.6 元3.2 元
缓存命中输入0.24 元0.48 元
输出6 元12 元

换算下来,输出价格按当前汇率约合不到 1 美元/百万 Token——即使按原价 12 元算,也明显低于同级别海外前沿模型的定价。缓存命中价低至 0.24 元,对长对话、多轮 Agent 这类重复读上下文的场景很友好。

获取渠道有四条:讯飞开放平台与星辰 MaaS 走 API(OpenAI 兼容接口);Hugging Face / ModelScope / GitHub 下端侧权重;昇腾 NPU 可直接拉官方 Docker 镜像;本地用 Ollama / LM Studio 或 vLLM、SGLang 部署。端侧模型还支持用 LLaMA-Factory 做增量微调。

但要留个心眼:「限时 5 折」和端侧 API 的「限时免费」,官方都没有给出结束时间表和转正后的正式定价。对企业做长期成本核算来说,这是个不确定项——按折扣价做预算,转正后可能要重新算一遍。

平台提供的是 OpenAI 兼容接口,已有一套 OpenAI 调用代码的话,改动量通常在两三行。结构示意(具体 base_url 与模型名以开放平台控制台显示为准):

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_KEY",
    base_url="https://spark-api-open.xf-yun.com/v2",  # 以控制台显示为准
)

resp = client.chat.completions.create(
    model="x2.5",                 # 旗舰版;端侧用 x2.5-4b / x2.5-1.7b
    messages=[
        {"role": "system", "content": "你是代码助手,只输出可运行代码,不要解释。"},
        {"role": "user", "content": "读取目录下所有 csv,合并后输出缺失率最高的 5 列。"},
    ],
    max_tokens=2048,
)
print(resp.choices[0].message.content)

顺手算一笔账。缓存命中价之所以值得关注,是因为 Agent 循环里每一轮都会把前面的上下文重放一遍——这部分走的是缓存读取,单价 0.24 元/百万,和输出价 6 元差了 25 倍:

# 一个 20 轮 Agent 任务的粗略成本(限时价,单位:元)
INPUT, CACHED, OUTPUT = 3.2 / 1e6 * 0.5, 0.48 / 1e6 * 0.5, 12 / 1e6 * 0.5
ctx, out = 32_000, 1_200          # 每轮上下文 32K,输出 1.2K
cost = 20 * (ctx * CACHED + out * OUTPUT) + ctx * INPUT   # 首轮按未命中
print(f"20 轮合计 ≈ {cost:.3f} 元")   # 实测约 0.35 元
# 若缓存完全没生效,同样一轮是 20 * (ctx*INPUT + out*OUTPUT) ≈ 1.17 元,贵 3.3 倍

这个量级的意义在于:多轮 Agent 不再是"跑一次心疼一次"的开销,可以放心让它重试、反思、多走几步——而这恰恰是长链条任务里提升成功率的唯一已知有效手段。反过来,如果缓存机制没生效,同样一轮会从约 0.35 元涨到约 1.17 元(三倍多),跑上一整天量就上来了。所以接入后第一件事是确认缓存命中率有没有真正跑起来——这是折扣之外,另一个真正决定账单的地方。


六、全栈国产的代价与收益:三个还没闭合的口子

冷静看这次发布,有三处值得保留意见。

第一,官方 benchmark 尚未经过第三方独立复测。 这不是质疑数据造假——大模型发布时自报成绩是行业惯例——而是指出引用姿势:把 44.4、90.7、133.4 这些数字直接当作"已验证的排名"来传播是不严谨的。真正能说明问题的是第三方复现和真实业务里的表现,这两样都还需要时间。

第二,"100 万 Token"的宣传语境需要小心。 这个能力属于端侧 4B/1.7B,旗舰版是 256K。两者差了四倍,而且端侧的 100 万是在混合注意力的特定结构下实现的,跑到极限长度时的实际效果(信息保留率、召回准确度)官方没有给出长上下文专项的细化数据。选型时按"旗舰 256K、端侧 1M"来理解,不要串。

第三,长期成本与稳定性还没被验证。 限时折扣没有时间表;更关键的是,当旗舰模型的全流程都跑在国产算力上,规模化调用时的成本与稳定性能不能撑住,这个答案要等 API 转正、跑过一段真实流量之后才看得出来。训练效率从 30% 提到 85% 以上是好消息,但训练效率和线上服务的单位成本是两件事。

还有个不算口子、但值得观察的点:从第三方实测看,模型在长链条自主生成任务上仍会失败(3D 创作多次未交付)。这与全行业在长程 Agent 控制上的普遍短板一致,短期内不要指望靠换模型解决。


给你的落点:什么场景值得试

把上面这些拆完,可以给几个直接的判断。

值得试的场景:

  • 数据不出域的端侧长文档处理。4B 模型 + 100 万 Token + Apache 2.0,这个组合指向很明确:财务、审计、法务这类对数据安全要求高、又需要通读长材料的行业。官方给的样例是断网条件下比对两份八千余字的商业合同、找出风险条款并分档——这类任务比刷榜更能体现端侧 1M 的价值。
  • 成本敏感的高频调用。输出 6 元/百万 Token(限时)、缓存命中 0.24 元,对多轮对话和 Agent 循环这类"反复重放上下文"的负载很划算。
  • 智能家居、车载、IoT 等低算力终端。1.7B 在 Domux 上 90.3% 正确率、0.85 秒响应,说明小模型在受控场景里已经能干活。
  • 需要国产化替代合规的项目。全栈国产这条链路,对有明确合规要求的政企客户是硬指标。

先别急的场景:

  • 把 benchmark 数字直接当选型依据。官方自报、未经复测,等第三方结果。
  • 长链条自主创作类任务。实测中 3D 创作多次失败未交付,这类任务目前还需要人工介入兜底。
  • 按折扣价做长期预算。转正时间未定,成本模型要留出上浮空间。

一个更宏观的判断:这次发布真正的信号不是"又一个国产大模型",而是国产算力链路已经能支撑旗舰模型的完整生命周期。从"能训"到"能训且能服务",中间隔着的是三年把训练效率从 30% 推到 85% 以上的工程苦活。这条路走通了,后面同类模型的发布成本会低很多。

#星火X2.5 #科大讯飞 #国产算力 #昇腾 #MoE #端侧大模型 #Agent

Logo

鲲鹏昇腾开发者社区是面向全社会开放的“联接全球计算开发者,聚合华为+生态”的社区,内容涵盖鲲鹏、昇腾资源,帮助开发者快速获取所需的知识、经验、软件、工具、算力,支撑开发者易学、好用、成功,成为核心开发者。

更多推荐