星火 X2.5：纯血国产端侧小巨人，4B 本地真干活

原文链接：星火 X2.5：纯血国产端侧小巨人，4B 本地真干活

【欢迎关注作者微信公众号【独码侠】，第一时间获取最新好文和AI日报。👇】

本文在本地一台 Mac 上部署星火 X2.5-4B / 1.7B，把它们接进真实 Agent 客户端，跑完 12 项「真干活」任务。文中所有截图与数据均来自本地实测，可复现。

引入

一台本地的 Mac 笔记本，靠一个 4B 参数的小模型，硬是干完了过去只有大模型才兜得住的活。2026 年 9 月 1 日，科大讯飞全资子公司词元星火开源了星火 X2.5-4B 与 1.7B 两款端侧通用模型，并把「原生支持最长 100 万 token 上下文」首次带到了端侧。

本以为只能做文本补全，结果一上 Agent 榜单就对着大一两圈的对手秀了肌肉——τ³-bench、MCP-Atlas、BrowseComp、IFBench 等核心榜单全面越级（具体分数见第一节榜单表，4B 官方 thinking 模式）。

一、榜单先声夺人

榜单	4B 官方	1.7B 官方	同尺寸定位
τ³-bench（多步工具）	30.4	20.1	越级
MCP-Atlas（MCP 协议）	54.6	23.4	同档最高
BrowseComp（自主检索）	40.9	29.7	领先
IFBench（指令遵循）	75.0	66.3	领先
SWE-Bench Verified	41.6	28.3	越级

榜单数字来源：词元星火官方模型卡（thinking 模式，采样 temperature=1.0 / top_p=0.95），与 DataLearnerAI、ModelScope 镜像交叉核对一致。

在智能体、工具调用、真实任务完成率这些硬指标上，它实现了「越级打怪」。其中 1.7B 在 MCP-Atlas 拿下同级最高分（见上表）。

二、端侧 AI 跨越「好用」门槛

过去大模型故事几乎全在云端：参数越堆越大，离用户越远。想用先联网、数据交出。可现实里大批机器碰不到云——内网办公电脑、工厂终端、车机、音箱。

端侧模型的尴尬一直卡在「只会动嘴、动不了手」：你扔一叠报表说「帮我整理」，它大概率回一段「整理建议」。星火 X2.5 冲的就是这件事。BF16 下 4B 权重约 8GB、1.7B 约 3.4GB；4bit 量化可再砍一半。4B 进笔记本/工作站，1.7B 进手机/车机。

三、本地部署保姆级教程

完整命令见配套《星火 X2.5-4B / 1.7B 本地部署与运行手册》。关键三步：

1. 取权重：ollama pull SparkLLM/Spark-X2.5-4B 与 -1.7B（注意：官方 Ollama 运行时不支持 spark2_5 架构，只能下载、不能推理）。
2. 起引擎：克隆词元星火 llama.cpp 分支，cmake -DGGML_METAL=ON 构建，产物 llama-server。
3. 开服务：4B 起在 :8080、1.7B 起在 :8081，均为 OpenAI 兼容端点；或一键 bash start_spark_servers.sh。

实测修正：官方宣称原生 1M 上下文，但本机单实例 4B（BF16，约 8GB 权重）默认以 64K 上下文启动即可覆盖绝大多数任务；实测可稳定拉到 128K（131072），A1/B1/B2/C1/C2/D1 等重负载任务均在本机跑通，A2 这类超 64K 的大输入需以 ≥128K 上下文启动方可不溢出。1.7B 用 -c 49152。

图 1｜本地 llama-server 启动日志（4B，BF16），/v1/models 健康检查返回模型就绪。

四、接入本地 Agent

把 Agent 的端点指向本地即可（采样 temperature=1.0, top_p=0.95, top_k=-1）：

• Hermes Agent / 通用 OpenAI 兼容客户端：直连 http://localhost:8080/v1。
• Claude Code：设 ANTHROPIC_BASE_URL=http://localhost:8080（不带 /v1）、ANTHROPIC_MODEL=spark-x2.5-4b，服务端须带 --alias spark-x2.5-4b（llama-server 原生讲 Anthropic 协议，直连即可）。

实测踩坑（值得点一句）：本 fork 的 /v1/responses 仅实现 function 类工具，会丢弃 Codex 原生的 namespace（文件）/ web_search 工具类型，导致 Codex 无法驱动文件与 Shell 操作、只能空回复后退场。因此原设计归 Codex 的文件类任务（A2/B2/C2/D1）改用 Claude Code（Anthropic /v1/messages 协议，tool_use 正常）完成；结构化输出类（E1/E2/F1/F2）用 Hermes Agent（OpenAI chat/function）。无论换哪个客户端，模型都是本地 spark-x2.5，测的是「本地模型能否真干活」。

图 2｜Claude Code 接入本地端点的配置示意（base_url 指向 localhost:8080，模型名与服务端 alias 一致）。

五、实测（接进 Agent 真干活）

模型分工：A1–E2 九项重 Agent 负载（代码生成/长文档审查/多步工具调用/Bug 修复/跨章推理）统一用 4B 跑，正是「越级打怪」的主战场；1.7B 专设 F 系列轻量/边缘任务（批量分类、字段抽取、边缘守门员），呼应「千万台国产设备在等一个能跑的模型」。

客户端分工：文件/工具类任务用 Claude Code（Anthropic 协议）；结构化输出类用 Hermes Agent。全部为本地模型，零联网。

测试环境：Apple M1 Pro（10 核 CPU + 16 核 GPU，32GB 统一内存），macOS；4B 以 BF16 运行、约 8GB 权重常驻单实例。下表耗时、吞吐、上下文上限等性能指标均在此环境测得，供复现对照。下表为各任务本地实测汇总（耗时来自评测日志 elapsed）。

任务	模型	客户端	关键结果	耗时
A1 生命游戏	4B	Claude Code	单文件 HTML 可运行	~7 min
A2 订单清洗	4B	Claude Code	73 异常 / 漏重复单号	~25 min
B1 差异审查	4B	Claude Code	4 类暗雷全中 / 13 差异	~10 min
B2 跨章问答	4B	Claude Code	3 章关联 / 结论正确	~5 min
C1 MCP 调用	4B	Claude Code	参数零错 / 告警已发	~3 min
C2 多文件改动	4B	Claude Code	5 passed / 已提交	~33 min
D1 Bug 修复	4B	Claude Code	1 passed 转绿	~5 min
E1 约束 YAML	4B	Hermes	全约束满足	~13 s
E2 数学推理	4B	Hermes	答案正确	~14 s
F1 工单分类	1.7B	Hermes	意图 80% / 整条 65.7%	~19 s
F2 字段抽取	1.7B	Hermes	整条 70% / 情感 100%	~14 s
F3 边缘守门员	1.7B	Claude Code	漏判 OR 条件 / 0 告警	~77 s

5.1 康威生命游戏（A1，4B / Claude Code）

一句提示词让 Claude Code（后端 spark-x2.5-4b）直接生成单文件 HTML：预置滑翔机、空格暂停/继续、点击切换细胞、实时显示代数与存活数、边界环绕。

图 3｜一句提示词一次性写出 342 行单文件 HTML，无任何外部库。

图 4｜生成的 HTML 双击即可在浏览器打开运行（单文件、纯 Canvas + 原生 JS）。实测从发令到交付约 7 分钟（含思考链）。

5.2 电商订单流水清洗（A2，4B / Claude Code）

给一张埋雷订单表，模型自己写脚本、自己跑、自己出报告。输入 77 行订单，埋了 8 类异常（金额不平 ×5、手机号非法 ×4、号段省份不符 ×3、未来时间 ×4、重复订单号 ×3、数量≤0 ×3、优惠券超金额 ×4、时间格式混用 ×6，共 32 处）。

4B 自写 clean_and_analyze.py（规则引擎），跑出 cleaned_order_data.csv 与《电商订单流水清洗与异常分析报告》，共标出异常 73 处。按报告「二、异常检测明细」分类如下：

异常类型（规则）	检出数	实测说明
优惠券金额超出合理范围（>100）	66	券额 > 100 元，最大 2280 元
实付金额显著低于估算金额	4	实付 0 元 vs 估算 147~1385 元
数量为 0	3	ORD00065~67，qty = 0
重复订单行（按整行内容匹配）	0（实漏 3 行）	ORD00010 占 4 行且内容不同，未识别
合计	73	与报告「异常总数 73」一致

实测局限：脚本的「重复」判定用整行完全匹配，对「同订单号不同内容」的重复订单未能识别——ORD00010 在结果中仍占 4 行（券额分别 665 / 170 / 1783 / 1214 元），报告却写「重复行：0」。此外报告「四、结论」列举了日期格式、字段缺失、手机号、物流矛盾等类别，但「二、异常检测明细」实际只落地了上述 3 类规则——结论覆盖度与规则实现存在落差，复杂规则工程的完整覆盖度对 4B 仍显吃力，提示此类任务宜把判定规则拆细或辅以人工复核。另外本机以 64K 上下文启动服务时，A2 初跑因输入达 65.7K token 触发长度溢出中断，需以 ≥128K 上下文启动方能稳定跑完。

5.3 双版技术方案差异审查（B1，4B / Claude Code）

两份约 8000 字技术方案接进 Claude Code，找改动痕迹。埋了 4 类暗雷（SLA 降级、安全约束删除、责任不对等、组件闭源化）。

模型产出对比报告，先给总览：它从 46 行差异中归出 8 类改动并逐类标注风险：

类别	数量	风险	核心性质
一、总体目标与可用性指标	1 处	高	核心目标变更，影响架构约束
二、高可用与容灾设计	4 处	高	多活／灾备／演练／容量冗余全面收窄
三、安全合规设计	1 处	高	安全约束删除，风险敞口扩大
四、第三方供应商对接 SLA	1 处	高	甲方责任条款收紧，供应商责任不对称
五、关键技术选型（分布式事务）	1 处	高	开源 Seata → 闭源商业组件
六、关键设计原则与选型总则	2 处	高	选型原则反转、审计条款弱化
七、性能与容量规划	2 处	中	冗余倍数与压测频次下调
八、风险与后续规划	2 处	中	风险描述随上游变更联动

4 类暗雷全部命中，其中可用性这条抓得最狠：A 版「核心交易链路全年可用性 ≥ 99.99%（不可用 ≤ 52.6 分钟）」被 B 版改为「≥ 99.5%（不可用 ≈ 1.83 天）」，并被直指放宽动因为「成本优化」；容灾架构也从「双机房多活、RPO≈0」退化为「同城双活 + 异地异步灾备、RPO≈5 分钟」，库存域同时失去双活保障。报告结论：B 版属以成本优化/供应商谈判为驱动的系统性降级修订，建议评审前复核高风险项，不可直接以 B 版为基线。

实测局限：报告自述「4 类改动、13 处核心差异，7 处高风险、2 处中风险」，但上表逐类相加实为 14 处、高风险 10 处——统计口径并不自洽。4B 抓全了关键改动，但长报告的自我统计一致性仍显薄弱，提示让模型同时产出「结论」与「逐条明细」时，应以明细为权威、结论由其汇总，避免口径漂移，如实指出。

5.4 差旅制度跨章节问答（B2，4B / Claude Code）

把一份 11 章、约 4200 字的《差旅与费用管理制度》整本塞进 4B 上下文，只问一句：员工海外出差期间因天气改签两次机票且单程超标，改签费与超标部分能否报销？——正确答案必须同时关联「机票改签、超标审批、海外出差补贴」三个不相邻章节，只看任何一章都会答错。

图 5｜Claude Code（spark-x2.5-4b）读完整本手册后先给结论：改签费可报（须属不可抗力、凭承运方证明）；超标部分须事前特批，否则个人承担。

图 6｜模型分「机票改签 / 超标准批 / 海外出差补贴」三部分逐章列依据（落到第三、九、十章具体条款），并汇总成判断表，全程约 5 分 16 秒。三个章节全部关联到位，结论与人工按手册逐条比对一致。

5.5 工具调用（验证 MCP-Atlas，C1，4B / Claude Code）

本地起极简 MCP Server，让 Agent 多步调用工具改配置并发告警：读 config/app.conf → 把 max_retry 由 3 改为 5 写回 → 列出 logs 目录 → 调 send_alert 推送。

图 7｜工具调用全部命中、参数零错误、顺序正确，最终 app.conf 已改且告警「配置已更新：重试次数=5」已发。实测耗时约 3 分 14 秒。

5.6 仓库内多文件改动 + 自测（C2，4B / Claude Code）

给一个带 pytest 的 CLI 工具集，要求新增 csv_to_json 子命令（支持 --delimiter / --output）+ 单测 + 跑通测试 + 提交。

图 8｜跨多文件编辑（commands.py 实现、cli.py 注册、tests/ 新增）、自跑 pytest 5 passed、git commit（未 push）。实测耗时约 33 分钟（含沙箱环境调试）。

5.7 真实小仓库 Bug 修复（D1，4B / Claude Code）

一个小库 group_by_extension 有真实 bug：扩展名分组区分大小写，.jpg/.JPG 被错误分开。要求定位根因、最小改动修复、使测试转绿。

图 9｜根因定位：ext 取自原始大小写未归一；最小修复仅加一处 .lower()，pytest 1 passed 转绿。实测耗时约 5 分 30 秒。

5.8 结构化 YAML 输出（E1，4B / Hermes Agent）

一条多层嵌套指令：输出受约束 YAML（owner 枚举、ISO 日期、checks 数组、score 均值≥60、末尾中文 summary≤40 字）。

实测 13 秒返回，模型输出原文如下：

| report:
  owner: alice
  generated_at: 2026-09-13
checks:
  - name: build
    passed: true
    score: 92
  - name: unit_tests
    passed: true
    score: 85
  - name: lint
    passed: false
    score: 64
  - name: security_scan
    passed: true
    score: 78

summary: 四项检查通过三项，均分79.75，状态良好

约束	要求	实测	判定
owner	枚举内取值	alice	✅
generated_at	ISO 日期	2026-09-13	✅
checks	数组、score 为整数	4 项：92 / 85 / 64 / 78	✅
score 均值	≥ 60	(92+85+64+78)/4 = 79.75	✅
summary	中文 ≤ 40 字	21 字	✅

四项检查里 lint 被如实判为 passed: false（64 分），模型没有为了"好看"把它改成通过——如实标注失败项比凑齐约束更有价值。

5.9 数学逐步推理（E2，4B / Hermes Agent）

两题：E2-1 函数极值与单调区间；E2-2 竞赛风格概率与计数。

实测 14 秒，模型给出了完整推导（以下为其输出原文要点）：

E2-1　设 f(x) = ln x + a x² + b x，在 x=1 处取极值且 f(1) = −1/2：

• 求导得 f'(x) = 1/x + 2ax + b
• 由 f(1) 得 a + b = −1/2 …①；由 f'(1) = 0 得 1 + 2a + b = 0 …②
• ②−① ⇒ a = −1/2，代回 ⇒ b = 0
• 此时 f'(x) = 1/x − x = (1−x²)/x，因 x>0，符号只看 1−x²
• 结论：a = −1/2，b = 0；增区间 (0,1)、减区间 (1,+∞)，x=1 为极大值点，极大值 f(1) = −1/2

E2-2　10 球（5 红 5 蓝）不放回取 2 个：

• 总取法 C(10,2) = 45；同色 = C(5,2) + C(5,2) = 10 + 10 = 20
• P(同色) = 20/45 = 4/9，已是最简 ⇒ m=4，n=9 ⇒ m + n = 13

两题都做了回代/交叉验证：E2-1 把 a、b 代回原式确认 f'(1)=0 与 f(1)=−1/2 同时成立；E2-2 另算异色概率 25/45 = 5/9，用 1−5/9 = 4/9 反证。会自查是这一步最值得记的点。

5.10 客服工单意图分类（F1，1.7B / Hermes Agent）

35 条混合客户消息，1.7B 逐条输出 JSON（意图/紧急度/是否人工），与人工标注比对。

19 秒跑完 35 条，全部为合法 JSON，输出形如：

| {"意图类别":"咨询","紧急程度":"低","是否需要人工":false}
{"意图类别":"退换货","紧急程度":"中","是否需要人工":true}

维度	准确率
意图	80.0%
紧急程度	88.6%
是否需要人工	77.1%
整条完全匹配	65.7%

模型预测分布：意图为 咨询 12 / 报修 8 / 退换货 6 / 投诉 6 / 其他 3；紧急程度 中 18 / 低 10 / 高 7；判为需人工 29 条、无需人工 6 条。三个字段全对才计入「整条匹配」，所以整条 65.7% 明显低于任一单维准确率——多字段联合输出时误差会叠加，这是 1.7B 做结构化抽取的真实水位。

5.11 自由文本字段抽取（F2，1.7B / Hermes Agent）

20 条非结构化用户反馈，1.7B 抽商品名/价格/情感/是否有图/问题类型。

14 秒完成，20 条全部合法 JSON，抽取样例（原文）：

| {"product": "XX耳机", "price": 99, "sentiment": "中性", "has_image": false, "issue_type": "物流"}
{"product": "冰箱", "price": 3299, "sentiment": "正面", "has_image": false, "issue_type": "无"}
{"product": "裙子", "price": 159, "sentiment": "正面", "has_image": true, "issue_type": "无"}

字段	准确率
商品名	90.0%
价格	90.0%
情感	100%
是否有图	100%
问题类型	90.0%
整条完全匹配	70.0%

情感与是否有图两项达到 100%，说明 1.7B 对显式信号的判断很稳；商品名/价格/问题类型三项各 90%，失分主要来自口语化表述（如"那个充东西的"）。另有 2 条输出 product: "" + price: 0 的空值占位，未强行编造商品名——遇到不确定时留空而非幻觉，对下游入库是更安全的行为。

5.12 边缘"守门员"轻量工具调用（F3，1.7B / Claude Code）

复用 MCP Server，1.7B 读取 logs/ 下三个日志文件，规则是「含 ERROR 或 关键词[宕机/数据泄露/越权]时调 send_alert 推送，其余忽略，且不得修改任何文件」。

三个日志的真实内容与模型的判定如下：

日志文件	实际 ERROR 行	模型判定
error-2026-09-01.log	数据库连接池耗尽，拒绝新连接／已自动扩容连接池至 64／定时任务 scheduler 心跳丢失（3 条）	Ignored（判为 "no keyword match"）
app-2026-09-01.log	重试耗尽，请求失败 order_id=ORD00012（1 条）	Ignored（同上）
app-2026-09-02.log	无 ERROR	Ignored
合计	4 条 ERROR	实际推送 0 条告警

误读点非常具体：模型完整读出了这些 ERROR 行、也逐字复述了规则原文，却在每一行后追加「no keyword match」再判忽略——把「ERROR 或 关键词」当成了「ERROR 且 关键词」。它的结论文案是 "No log file contains ERROR-level alerts matching the keywords"，结果该触发的 4 条告警一条没发。

不过它也守住了另一条约束："No changes were made — I only read the files"——只读不动手执行得完全正确，坏的只是复合逻辑的拆解。这是 1.7B 在复合逻辑指令上暴露的真实局限，提示边缘守门类任务宜把「或/且」类条件拆成单条原子判断，如实记录。

5.13 4B vs 1.7B 对照结论

4B 在「重、长、多步」任务上明显更稳更全：代码生成（A1）、长文档差异审查（B1）、跨章推理（B2）、多文件改动+自测（C2）、真实 Bug 修复（D1）均一次跑通；A2 这类复杂规则工程虽能自写脚本跑出报告，但异常覆盖度有缺口。

1.7B 在「轻、快、批量」任务上性价比突出：F1/F2 秒级吞吐、JSON 全合法，情感/是否有图达到 100%，适合边缘高并发；但在复合逻辑指令（F3）上仍显吃力——这和官方榜单「4B 越级、1.7B 同档领先」的趋势一致：4B 扛重活，1.7B 跑轻活，各司其职。

六、它怎么做到的

• 混合注意力：每 3 层滑动窗口（SWA）+1 层全注意力。看得全又不必每层拉满算力，同样 1M 上下文显存仅传统全局注意力的 1/4。
• MOPD 多教师在线策略蒸馏：不教答案、只教走法。小模型先上手解题，老师傅全程督战纠路线（读需求、挑工具、填参数、查报错）。

七、千万台国产设备，在等一个能跑的模型

跑分和性能只是第一关。真正决定 AI 能不能大规模落地的，是它能不能顺畅地活在真实的行业设备里。

• 信创倒计时：按*******，到 2027 年底前后，央企国企须完成信息化系统信创替代（芯片、操作系统、中间件、基础软件 100% 替换）。券商测算政企信创市场空间达数千亿乃至万亿级，仅党政口径 2025–2027 的 PC 替换需求就在千万台量级，2026/2027 是集中交付节点。
• 合规红线：今年 8 月施行的《网络数据安全风险评估办法》规定，采用 AI 大模型等新技术须纳入动态安全评估。「这份数据要不要发给云端」已不是成本问题，而是合规问题——这正是端侧「数据一个字节不出机」的刚需来源。
• 为什么是它：① 算力自主（国产算力训、国产硬件跑得动）；② 兼容性强（vLLM/SGLang/llama.cpp，Ollama、LM Studio 几分钟跑起来）；③ 极致开源（Apache-2.0，免费商用、微调无需开源）。

八、结语

行业过去总问「模型有多聪明」，端侧该问「能适配多少台设备」。星火 X2.5 用全国产算力训练、Apache-2.0 开源、兼容 vLLM/SGLang/llama.cpp/Ollama，把「装得进、真能干」的引擎递到了那千万台断网机器面前。本文 12 项任务均在断网 Mac 本地实测，截图与数据均可复现。

【欢迎访问我的个人博客主页，这里有我的精选文章和AI大模型日报专栏。👇）