星火X2.5把百万上下文塞进端侧

科大讯飞旗下词元星火今天正式发布并开源星火 X2.5-4B 与星火 X2.5-1.7B，两款端侧通用大模型均宣称原生支持最长 100 万 Token 上下文窗口。按照官方口径，这是目前端侧模型中唯一达到 1M 上下文量级的产品，也是这次更新最值得关注、同时最需要经过社区验证的能力。

**星火 X2.5 是科大讯飞面向端侧设备和边缘计算场景推出的一组开源通用语言模型。**首批开放的两个版本分别为 40 亿参数和 17 亿参数，重点优化智能体、代码、数学、通用理解与指令遵循能力，模型权重已经上线 Hugging Face 和 GitHub。

这次发布真正有差异化的地方不是参数规模，而是科大讯飞试图把过去主要属于云端大模型的百万级上下文带到本地设备。4B 和 1.7B 在今天已经算不上稀缺规格，但如果 1M 上下文能在工作站、车载计算平台、机器人和高端边缘设备上稳定落地，它会直接改变端侧模型处理长文档、设备日志和连续任务的方式。

两款模型有什么区别

**星火 X2.5-4B 面向能力优先的本地应用，星火 X2.5-1.7B 则更强调资源占用、响应速度和设备控制。**官方暂未在公开材料中给出完整的显存需求、量化后体积、长上下文吞吐量及统一基准测试成绩，因此开发者当前不能只根据参数量判断实际部署成本。

| 项目 | 星火 X2.5-4B | 星火 X2.5-1.7B | |---|---:|---:| | 参数规模 | 40 亿 | 17 亿 | | 最大上下文 | 100 万 Token | 100 万 Token | | 模型定位 | 端侧通用、办公分析、代码与智能体 | 轻量端侧、智能家居、机器人与控制任务 | | 训练数据规模 | 约 20 万亿 Token | 约 20 万亿 Token，官方未说明两者具体数据配比是否相同 | | 注意力设计 | 混合注意力架构 | 混合注意力架构 | | 已公布代表性结果 | 可完成数据分析到双语报告交付的流程案例 | Domux 控制指令端到端正确率 90.3% | | 已公布响应数据 | 未公布统一端侧延迟 | Domux 平均响应时间 0.85 秒 | | 推理框架 | vLLM、SGLang、llama.cpp | vLLM、SGLang、llama.cpp | | 快速部署工具 | Ollama、LM Studio | Ollama、LM Studio | | 硬件平台 | 英伟达、华为、海光、后摩 | 英伟达、华为、海光、后摩 | | 权重获取 | Hugging Face、GitHub | Hugging Face、GitHub | | 云端体验 | 讯飞星辰 MaaS 平台限时免费 | 讯飞星辰 MaaS 平台限时免费 |

**MaaS 是将模型能力、托管推理和调用接口封装为在线服务的模型即服务平台。**对于暂时没有匹配硬件的开发者，在线平台适合先验证模型能力；但对于端侧模型而言，真正关键的指标仍然是本地部署后的首 Token 延迟、生成速度、峰值内存和长文本稳定性，而这些数据目前还不完整。

100万Token不等于手机里随便塞一本图书馆

**上下文窗口是模型在一次推理任务中能够读取和关联的 Token 总量。**100 万 Token 粗略对应数十万至上百万个中英文字符，具体换算会受到语言、分词器、代码比例和文档格式影响，因此不能简单等同于固定字数。

**百万上下文的实际价值在于减少切片、检索和跨轮信息丢失，而不是单纯追求输入长度纪录。**传统 32K 或 128K 模型处理大型售后手册时，通常需要先把文档切成小块，再通过检索增强生成找到相关段落；如果规则分散在保修、耗材、维修责任和例外条款多个章节，检索阶段漏掉其中一条，最终判断就可能出错。

科大讯飞给出的售后案例体现了长上下文最直接的用途：用户可以导入完整售后手册，再询问“购买 10 天后设备故障且使用过第三方耗材”这类包含时间、故障原因和免责条件的问题。模型需要同时关联退换期限、第三方耗材政策和故障认定规则，并在用户继续补充条件后保留此前情境。

**长上下文能够降低知识工程门槛，但不能自动消除幻觉和规则冲突。**即使整本手册都被放进窗口，模型仍可能忽略中间段落、错误理解例外条款，或者在两个相互矛盾的规定之间做出不稳定选择；对售后、法律和医疗等高风险场景，引用原文、输出证据位置和设置规则校验仍然必要。

百万上下文在端侧落地的最大问题也不是模型文件大小，而是推理过程中的内存和计算开销。Transformer 在生成时通常要保存历史 Token 对应的 Key-Value Cache，也就是 KV Cache；上下文越长，这部分缓存通常越大，注意力计算的延迟也会随之增加。

**KV Cache 是模型为避免重复计算历史注意力状态而保留的一组中间数据。**它的占用取决于层数、KV 头数量、每个头的维度、数据精度、批量大小以及上下文长度，因此“4B 模型能放进内存”并不意味着“4B 模型的 100 万 Token 上下文也能放进同一块内存”。

以常见模型结构做理论说明，如果每个 Token 的 KV 状态合计占用 32KB，那么 100 万 Token 仅缓存就需要约 32GB；如果通过分组查询注意力、低精度缓存或状态压缩降到每 Token 4KB，仍需要约 4GB。这并不是星火 X2.5 的实测数字，而是说明上下文长度与设备内存之间的数量级关系，实际结果必须以官方配置和社区测试为准。

混合注意力是百万上下文的关键，但细节决定体验

**混合注意力是一种在同一模型中组合多种注意力或序列建模机制的架构设计。**它通常不会让每一层、每一个 Token 都执行成本最高的全局注意力，而是结合局部窗口、稀疏连接、分组查询或其他高效序列机制，以降低长文本推理的计算量和缓存压力。

科大讯飞确认两款模型采用混合注意力架构，但截至 9 月 1 日，公开报道尚未完整披露每层注意力配置、KV Cache 精度、位置编码外推方案，以及 1M 长度下的预填充速度。对于开发者而言，这些细节比“支持 1M”本身更能决定产品是否可用。

**原生支持 100 万 Token 应当意味着模型在训练或长上下文扩展阶段针对该长度进行过优化，而不是只修改配置文件中的最大长度。**不过，能成功接收 100 万 Token、能在长文中准确找回信息、能完成跨章节推理，以及能在合理时间内返回答案，是四个不同层次的问题。

评价这项能力至少需要观察以下指标：

• **长文本召回率：**关键信息放在开头、中间和结尾时，模型能否稳定找到；
• **多证据推理：**答案依赖多个远距离段落时，模型能否完成组合判断；
• **预填充速度：**首次读取几十万或 100 万 Token 需要多长时间；
• **峰值内存：**模型权重、KV Cache 和推理框架合计占用多少内存；
• **生成延迟：**长上下文加载完成后，每秒能够输出多少 Token；
• **有效上下文：**标称 1M 窗口中真正保持可用准确率的范围有多大；
• **量化损失：**4-bit 或 8-bit 部署是否明显削弱长距离信息召回。

**目前“端侧唯一百万 Token 模型”更适合被视为官方产品定位，而不是已经完成第三方横评的行业结论。**模型刚刚开源，社区还需要在不同硬件、不同量化方式和真实 1M 输入下复现结果，尤其要区分服务器级边缘设备与普通笔记本、手机之间巨大的算力差异。

1.7B更像设备控制器，4B更像本地工作助手

**星火 X2.5-1.7B 的主要吸引力是把自然语言理解和设备执行压进更低的参数预算。**官方公布的 Domux 智能家居测试结果显示，其控制指令端到端执行正确率为 90.3%，平均响应时间为 0.85 秒，这组数据至少说明模型目标并非只做聊天，而是进入指令解析、设备选择和动作执行链路。

Domux 场景中的“端到端正确率”比单纯意图识别更接近真实产品体验，因为一句“晚上十点后如果客厅没人，就把空调调到节能模式”可能同时涉及时间条件、空间状态、设备属性和自动化规则。模型不仅要听懂用户，还要输出设备系统能够执行的结构化动作。

**0.85 秒响应时间已经进入智能家居可以接受的交互区间，但测试硬件和统计口径仍然重要。**如果这一数字包含完整的语义理解、规划和设备控制，它具有较强参考价值；如果只统计模型生成阶段，实际产品延迟还要叠加语音识别、网络通信、设备唤醒和执行反馈。

星火 X2.5-4B 的定位则更接近本地办公与轻量智能体。官方案例显示，它可以从原始数据分析一路完成双语报告交付，这意味着模型需要连续执行数据理解、任务拆解、内容生成、翻译和格式整理，而不是只完成一次问答。

**智能体是能够围绕目标规划步骤、调用工具并根据执行结果继续行动的模型系统。**端侧智能体的优势是数据不必频繁离开本地设备，网络不可用时也能维持部分能力；它的短板则是小参数模型在复杂规划、工具选择和错误恢复上的稳定性通常不如大型云端模型。

国产算力训练与多平台适配同样值得看

**全国产算力训练是指模型训练流程主要在国产计算芯片、服务器和配套软件栈上完成。**科大讯飞称，两款模型基于全国产算力平台完成全流程训练，并使用约 20 万亿 Token 的多样化数据进行预训练，这一数据量对于 1.7B 和 4B 模型来说相当激进。

20 万亿 Token 并不直接等于更高能力，因为训练数据质量、去重比例、课程安排和后训练方法同样关键。对小模型而言，大规模训练数据的价值在于提高参数利用率，让有限容量覆盖更多语言、代码和任务模式；风险则是如果数据重复或噪声过高，继续堆叠 Token 的边际收益会迅速下降。