星火X2.6押注端云Agent

讯飞星火 X2.6 今日发布，重点不只是模型升级

讯飞星火 X2.6 于今天（2026 年 10 月 22 日）下午在科大讯飞全球 1024 开发者节正式发布，核心更新集中在代码生成、长程智能体、1M 上下文和端云协同四个方向。按照科大讯飞公布的信息，旗舰模型采用 293B-A30B 的 MoE 架构，即总参数规模为 2930 亿、单次推理激活约 300 亿参数，并且基于全国产算力完成训练。

端云一体模型是同时部署云端大模型和端侧小模型，并根据任务复杂度、数据敏感度与设备性能动态分配计算的模型系统。它不是简单地在手机或电脑里塞一个小模型，而是让本地模型处理隐私数据、简单操作和即时交互，再把复杂推理、长上下文分析或高难度代码任务交给云端模型。

这次发布还有一款面向本地部署的 讯飞星火 X2.6-4B。该模型拥有约 40 亿参数，主打代码、智能体、长文本和多语言能力，并提供三档推理模式；科大讯飞称，它在自研推理框架下的运行效率高于 Ollama，但截至发布当日，官方尚未披露统一硬件、量化精度、首 Token 延迟和每秒生成 Token 数等完整对照数据。

一张表看懂星火 X2.6 的关键变化

星火 X2.6 的升级主线是把 X2.5 已经确立的 Coding 与 Agent 方向继续向长程任务推进。这里的长程任务，是需要模型连续执行多轮规划、工具调用、结果校验和错误恢复，并在较长时间内保持目标一致性的复杂任务。

| 项目 | 星火 X2.5 旗舰模型 | 星火 X2.6 旗舰模型 | 星火 X2.6-4B 端侧模型 | |---|---:|---:|---:| | 模型定位 | 云端基座模型 | 云端旗舰模型、端云协同中枢 | 本地运行、端侧 Agent | | 架构 | MoE | 293B-A30B MoE | 约 4B 参数的小模型 | | 总参数量 | 293B | 293B | 4B | | 激活参数量 | 约 30B | 约 30B | 未公布稀疏激活设计，按端侧模型定位理解 | | 上下文长度 | 旗舰版公开信息为 256K | 1M | 强调长文本能力，发布信息未给出本次具体上限 | | 重点能力 | Coding、Agent、工具调用 | 代码、长程 Agent、1M 上下文、安全策略 | 代码、Agent、长文本、多语言 | | 算力路线 | 全国产算力 | 全国产算力 | 面向国产及通用端侧设备部署 | | 开放方式 | 云端服务 | 官网试用及模型服务 | 开源发布 | | 推理价格 | 依历史产品方案而定 | 输入 0.9 元、缓存输入 0.08 元、输出 3.6 元 / 百万 tokens，均为限时价格 | 限时免费 |

这张表里最值得注意的不是 293B，因为星火 X2.5 已经采用相同量级的 MoE 架构，而是上下文从 256K 扩大到 1M，以及训练目标从一般的代码和工具调用进一步转向长程 Agent。换句话说，X2.6 更像一次训练方法和系统工程升级，而不是依靠堆参数完成的代际切换。

293B-A30B MoE，目标是在能力和成本之间找平衡

MoE 是 Mixture of Experts 的缩写，即混合专家模型，它把参数分成多个专家模块，每次只激活与当前输入相关的一部分参数。星火 X2.6 的 293B-A30B 表示模型总参数量达到 2930 亿，但处理一个 Token 时只调用约 300 亿参数，理论上可以用接近中型稠密模型的计算成本，获得更大参数池带来的知识容量和任务分工能力。

稀疏激活并不会自动带来更快的实际推理速度。MoE 需要在不同设备和专家节点之间传输中间结果，如果芯片互联、显存带宽或路由调度效率不足，节省下来的矩阵计算可能被通信开销抵消，这也是国产算力集群训练大规模 MoE 时最棘手的问题之一。

科大讯飞本次强调的技术突破，正是针对国产芯片显存带宽与集群通信条件设计长程任务动态并行训练。动态并行训练可以理解为：系统不再给所有样本分配完全相同的计算路径，而是根据序列长度、任务阶段和专家负载动态调整数据、张量、流水线与专家并行方式，减少长短样本混合时的设备等待和显存浪费。

这项能力对 1M 上下文尤其重要。百万 Token 输入不是把 256K 序列简单放大四倍，因为注意力缓存、样本长度差异、专家路由和跨节点通信都会同步增加压力；即使模型采用高效注意力机制，超长序列也会显著推高显存占用和首 Token 延迟。

全国产算力训练，是 X2.6 最有区分度的标签

全国产算力训练是指模型的核心预训练、后训练和相关集群计算建立在国产 AI 芯片与国产计算平台上，而非依赖英伟达 GPU 集群。科大讯飞董事长刘庆峰在发布会上表示，星火是目前主要模型中唯一完全使用全国产算力训练的产品，并称科大讯飞采用的模型尺寸更小；这一说法来自企业发布会口径，仍需要更完整的训练报告和第三方结果支撑横向比较。

国产算力上的真正难点并不是让训练任务成功启动，而是让大规模训练长期保持高利用率。大模型训练常以数千张加速卡连续运行数周甚至数月，任何通信阻塞、算子不兼容、显存碎片或节点故障都会放大为巨额计算损失，因此软件栈和调度系统的重要性不低于芯片本身的峰值算力。

科大讯飞公布的两项推理侧创新也围绕这一瓶颈展开。第一项是基于国产异构算力的分布式推理技术，通过把不同计算阶段调度到更适合的国产设备上，缓解单一芯片在显存容量和带宽上的限制；第二项是面向国产设备的结果复用技术，让部分中间结果不必重复计算。

结果复用最直接的类比是给模型建立计算缓存。对于代码仓库分析、长文档问答或 Agent 多轮执行，相同的系统提示词、文件内容和历史轨迹会被反复读取，如果每轮都从头计算，成本和延迟都会线性累积；复用已有中间结果，可以把算力集中到本轮新增内容上。

不过，发布会对上述技术尚未提供充分的工程指标。开发者真正需要看到的是，在指定国产芯片型号、节点数量、输入长度和并发条件下，X2.6 的训练有效算力利用率、首 Token 延迟、吞吐量、缓存命中率及故障恢复时间，而不只是“解决瓶颈”或“效率提升”的定性描述。

1M 上下文服务的不是“塞进更多文字”，而是长程 Agent

1M 上下文是指模型单次任务理论上可以接收约 100 万个 Token 的输入与历史记录。按照文本语言、代码密度和分词方式不同，100 万 Token 大致可以容纳数十万至上百万汉字，或者一个中等规模代码仓库的大量核心文件。

超长上下文对代码 Agent 的价值高于普通聊天。一个真正参与软件开发的 Agent，需要同时理解需求文档、目录结构、多个源代码文件、测试日志、依赖配置和此前的修改记录，而传统 32K 或 128K 上下文往往迫使系统频繁裁剪内容，导致模型忘记早期约束或重复读取文件。

长上下文也不等于模型能够有效利用全部信息。模型可能支持输入 1M Token，却无法准确召回序列中部的关键约束；也可能在短上下文测试中表现出色，但执行几十步工具调用后出现目标漂移，因此需要结合长文本检索、跨文件代码修改和长程任务成功率等指标判断真实能力。

智能体是能够围绕目标自主规划步骤、调用外部工具、读取执行结果并继续行动的模型系统。与普通聊天机器人相比，Agent 的核心不是回答得更长，而是把“理解问题—制定计划—操作工具—检查结果—纠正错误”组成闭环。

X2.6 瞄准长程 Agent，意味着评估标准也应从单轮答案质量转向最终任务完成率。比如修复一个跨文件 Bug，模型写出正确补丁只是第一步，它还需要执行测试、定位失败用例、调整实现、避免破坏其他模块，并在多轮修改后交付可合并的结果。

端侧 4B 模型承担的是执行层，而不是替代云端旗舰模型

星火 X2.6-4B 是一款面向个人电脑、智能终端和行业设备部署的小参数模型。4B 规模通常更容易在消费级 GPU、部分高内存 PC 或经过量化的移动设备上运行，优势是数据不必离开本地、交互延迟可控，并且不会为每一次简单调用支付云端推理成本。

端侧模型最适合处理高频、低风险和隐私敏感任务。文件分类、离线摘要、界面操作、设备控制、简单代码补全和本地知识库检索，都不一定需要调用 293B 级别的云端模型；当任务涉及复杂架构设计、跨仓库代码理解或长链推理时，再把经过脱敏的必要上下文交给云端。

三档推理模式意味着开发者可以在速度、资源占用与推理深度之间切换。尽管官方尚未公布三档模式的具体命名和计算预算，但这类设计通常会分别适配即时问答、平衡模式和复杂推理，从而避免所有任务都使用相同的生成长度和思考成本。

X2.6-4B 的意义还在于补齐端云协同中的本地决策节点。没有可用的小模型，所谓端云协同往往只是“本地采集数据、云端完成一切”；有了具备工具调用与 Agent 能力的 4B 模型，本地设备才有机会先判断任务、调用本机工具，并决定哪些步骤需要云端接管。

科大讯飞披露，星火 X2.5-4B 自 2026 年 9 月 1 日开源以来，下载量已经进入全球端侧模型前四。这个排名说明其传播速度较快，但下载量不代表持续使用量，也不能直接证明模型效果；开发者仍应关注许可证、量化版本、硬件兼容性、内存占用和实际任务成功率。

价格足够激进，缓存输入尤其便宜

星火 X2.6 当前公布的是限时推理价格，而不是承诺长期维持的正式价格。具体费用如下：

| 计费项目 | 限时价格 | 相对普通输入价格 | |---|---:|---:| | 普通输入 | 0.9 元 / 百万 tokens | 100% | | 缓存命中输入 | 0.08 元 / 百万 tokens | 约 8.9% | | 模型输出 | 3.6 元 / 百万 tokens | 普通输入的 4 倍 | | X2.6-4B 端侧推理 | 限时免费 | 本地硬件成本另计 |

缓存命中价格比普通输入低约 91.1%，这对长文档和 Agent 应用比普通聊天更有吸引力。一个 Agent 如果每轮都携带几十万 Token 的代码仓库索引、系统提示和任务历史，缓存能否命中会直接决定应用成本是否可控。

输出价格是普通输入价格的 4 倍，因此开发者仍需限制无效长回答和重复推理。对于代码 Agent，更合理的产品设计是让模型输出结构化计划、补丁或工具参数，而不是每一步都生成大段解释；对于文档分析，则应尽量复用固定材料的前缀缓存。

限时价格也意味着采购方不能直接用当前数字推算长期成本。企业在评估时至少需要确认活动结束日期、阶梯计费规则、缓存有效期、并发限制、服务等级协议和私有化部署费用，否则低 Token 单价未必等于低总体拥有成本。

代码与 Agent “业界一流”，目前还缺第三方跑分坐实

科大讯飞将 X2.6 的代码和智能体能力定位为业界一流水平，但本次公开信息没有给出足够完整的统一榜单成绩。发布当日可确认的是能力方向、模型架构、上下文规模和价格，而不是它已经在所有代码及 Agent 基准上领先同级竞品。

代码模型至少需要接受三类测试。第一类是 HumanEval、MBPP 等函数级生成测试，第二类是 SWE-bench 一类真实软件仓库修复任务，第三类是企业内部代码库中的跨文件理解、测试生成和增量修改；只公布其中一类，无法说明模型适合完整的软件工程流程。

Agent 模型还需要测试长程任务中的稳定性。开发者应重点查看工具调用格式正确率、任务完成率、平均执行步骤、错误恢复率、Token 消耗和超时比例，而不是只比较模型在静态问答榜单上的得分。

X2.6-4B 也需要与同尺寸开源模型在相同条件下比较。合理的评测环境应固定量化精度、上下文长度、推理框架、批处理大小和硬件型号，同时报告每秒生成 Token 数、峰值内存和任务准确率；仅比较自研框架与 Ollama 的速度，而不披露版本和参数，参考价值有限。

判断：这是一场系统工程升级，而不是参数竞赛

星火 X2.6 最重要的产品判断，是科大讯飞开始把模型、国产算力、推理框架和端侧部署作为同一个系统交付。293B-A30B 的参数结构本身并不新鲜，但如果它能在国产芯片上稳定训练、在云端支撑百万上下文，又让 4B 模型承担本地 Agent，那么这条路线比单纯刷新榜单更接近企业真实需求。

端云协同对教育、医疗、汽车和政企场景尤其实际。这些行业既要求模型理解复杂材料，又不愿把全部录音、病历、业务文档或车内数据持续上传云端，本地模型先处理敏感信息、云端模型负责高难推理，是一条兼顾合规与效果的折中路线。

X2.6 当前最大的短板是公开验证信息仍然不足。官方需要补充代码基准、Agent 长程任务、1M 上下文有效召回、国产集群吞吐以及 4B 模型端侧速度，否则“能力突破”更多仍是发布会结论，开发者难以判断它在具体场景中能否替代现有方案。

开发者现阶段最值得做的不是立即迁移全部业务，而是选择真实任务进行小规模验证。建议优先测试一个跨文件代码修改任务、一个包含多轮工具调用的 Agent 流程，以及一个超长文档问答任务，同时记录成功率、延迟、Token 成本和人工接管次数。

总体来看，星火 X2.6 是一次方向明确的升级：云端旗舰模型负责复杂推理和百万上下文，4B 开源模型负责本地感知与执行，国产算力和缓存技术则负责把这套系统真正跑起来。它是否能跻身代码与 Agent 的第一梯队，最终不会由 293B 参数或 1M 上下文决定，而要看真实软件工程任务能否稳定完成。

参考来源

• IT之家：讯飞星火 X2.6 端云一体大模型发布 — 汇总 2026 年 10 月 22 日发布会信息，包括模型架构、国产算力、上下文长度、端侧模型及限时价格。