星火 X2.6 发布,配套开源 4B 端侧模型
讯飞发布国产算力训练的星火 X2.6,采用 293B-A30B MoE 架构,支持 1M 上下文,限时输入、输出价格分别为每百万 tokens 0.9 元和 3.6 元。同步发布的开源 X2.6-4B 提供三档推理模式,官方称代码与智能体能力提升,但素材未给出具体评测数据。
AI 深度解读
讯飞星火 X2.6 把代码、智能体和端云协同放在了同一次发布中。它最想强调的是:基于全国产算力,既能训练面向复杂任务的云端模型,也能提供可在设备端运行的开源小模型。
对程序员来说,值得关注的是 1M 上下文、X2.6-4B 端侧模型,以及公布的调用价格。但发布会宣称的能力突破,距离真实项目里的稳定表现还有多远,这篇报道提供的证据并不充分。
国产算力的突破,具体指什么
据 IT之家报道,科大讯飞在 10 月 22 日举行的全球 1024 开发者节上发布了星火 X2.6。云端模型采用 293B-A30B 参数的 MoE(混合专家)架构,上下文长度扩展至 1M。
MoE 可以理解为把模型分成多个专家,每次处理输入时调用其中一部分。293B-A30B 通常表示总参数约 293B、每次激活约 30B。总参数量和单次参与计算的参数量,需要分开看。

发布会的技术重点,是国产芯片上的长程任务训练。任务越长,中间需要保存和搬运的数据越多,显存带宽就越容易成为限制。讯飞称,其适配国产平台的长程任务动态并行训练技术,解决了显存带宽限制导致的混合训练效率低下问题。
报道还提到两项推理侧改进:基于国产异构算力的分布式推理,以及复用已有计算结果、减少重复计算。
这里必须打个问号。原文相关段落存在重复,而且在介绍推理技术时又写成解决「训不快」的问题,没有交代具体机制、测试条件或提升幅度。仅凭这些描述,无法判断训练和推理分别获得了多大收益。
刘庆峰还表示,只有星火采用全国产算力训练,其他模型都在 N 卡上训练,且星火尺寸最小。这是发布方的说法,报道没有提供完整比较范围,不能直接当作行业事实引用。
云端与端侧,程序员能得到哪些东西
云端 X2.6 的公开信息,主要落在长上下文、代码、智能体和安全策略上。官方称代码与智能体能力达到业界一流水平,并支持按任务场景自定义安全策略。
1M 上下文对代码任务有吸引力:理论上可以一次提供更多项目文件、文档和日志。但能放进去多少内容,与能否准确理解文件关系、完成修改,是两件需要分别验证的事。
限时推理价格为:
| 计费项目 | 每百万 tokens 价格 |
|---|---|
| 输入 | 0.9 元 |
| 输入缓存命中 | 0.08 元 |
| 输出 | 3.6 元 |
缓存命中的输入价格明显更低,重复携带相同上下文的任务值得关注。不过,报道没有说明缓存命中规则、保存时间和限时价格的截止日期,不能据此直接估算长期成本。
端侧发布的是开源模型星火 X2.6-4B。官方称,它相较 X2.5-4B,在代码、智能体、长文本和多语言能力上都有提升,并新增三档推理模式。

官方还称,自研推理框架的效率较 ollama 有所提升,推理定价限时免费。但报道没有给出三档模式的具体区别,也没有列出硬件配置、量化方式、速度和内存占用。开源许可、部署要求,以及免费定价对应哪种服务,同样没说清。
作为前代产品,X2.5-4B 自 9 月 1 日开源后,下载量据称已进入全球端侧模型前四。下载量能反映关注度,但排名的数据来源、统计平台和时间范围没有交代。
X2.6 系列现已在讯飞星火官网开放试用,并首发端云一体协同架构。至于任务如何在端侧与云端之间分配、哪些数据需要上传,原文没有展开。
我的判断
我认可这次发布把算力适配、模型能力和端侧部署放在一起讨论。对有国产硬件要求的团队,模型能否在目标设备上高效运行,确实会直接影响选型。
但标题中的「首次」和「突破」,目前主要由发布方陈述支撑。报道没有提供可核验的代码任务成绩、智能体成功率或训练效率对照,不能替它背书。
1M 上下文、4B 参数和低价,都只是选型入口,真实任务完成率才决定使用价值。
同样,端云协同也未必天然优于直接调用云端 API 或完全本地部署。它是否值得采用,取决于任务分配、数据传输和失败回退的实现。原文没有给出这些细节,也没有对照实验,目前更适合视为一个待验证的产品方向。
能拿来做什么
- 试用云端 X2.6 时,可以挑一个熟悉的前端或 Node 项目,让它完成跨文件修改,并记录测试通过情况、遗漏和人工修复量,检验代码能力是否适合自己的工作。
- 评估 1M 上下文时,可以比较「提供整个项目」与「只提供相关文件」两种方式,观察答案质量、耗时和费用,避免把上下文长度直接等同于理解能力。
- 考虑部署 X2.6-4B 时,先确认许可和硬件要求,再在同一设备、相同输入与输出长度下比较其自研框架和 ollama,同时测试三档推理模式。
- 评估端云协同时,先确认任务分配方式、上传的数据范围和云端不可用时的处理方式,再判断它是否适合团队现有流程。