星火 X2.5 文档分析实测：四个档位读同一份日志，最慢的确实质量最高

摘要：本文用同一份真实 llama.cpp 运行日志，实测星火 X2.5 系列 1.7B 与 4B 两个尺寸、F16 与 Q4 两种精度共四档模型的文档读取、分析与总结能力。日志里埋着三处坑：抬头与正文参数矛盾、「512Ex」被误读为上下文长度、注释主语易被误解。结果显示，四档都能产出结构完整的初稿摘要，但只有最慢的 4B-F16 看出日志抬头有问题，且四款都未走到「判定材料不可信」这一步；同时发现思考 token 花得多并不等于想得明白。结论是：星火 X2.5 做文档分析够用，但只能当「初稿生成器」，不能当「终稿」。

星火 X2.5 文档分析实测：四个档位读同一份日志，最慢的确实质量最高

Spark-X2.5 能力实测第 1 期 · 文档读取、分析与总结机器：R9-7900 + RTX 3070 8G + 64G ｜ 引擎：llama.cpp（XHToken fork） 推理引擎私信【星火】会自动回复下载链接。2026端侧模型确实在崛起，但是小模型到底能干什么？我想实际测一下，就从星火X2.5系列开始，还会继续挑一些出来测试，大家也可以留言或者私信想看哪些？我可以择期安排。

一、全网都在聊它多强，我想知道它能干啥

星火 X2.5 开源很多天了，官方跑分表被转了一圈——τ³-bench 30.4、BrowseComp 40.9、AIME 2026 90.7，数字确实亮眼。

但我翻了一圈，发现一件事：这些分全是厂商自报的，到今天没有一份独立复测。Artificial Analysis 没收录，没有 arena 榜，社区里也没有人贴出可复现的测试日志。海外那边的评价很克制，原话是"promising, open, andentirely unverified"（有前景、开源、但完全未经证实）。

跑分表能告诉你它考了多少分，但回答不了最实际的问题：这玩意儿到底能干什么活？

所以我挑了端侧小模型最可能被派去干的活，也是最考验真本事的一件——读文档。

丢一份日志、一份合同、一份手册进去，让它提取信息、做分析、给总结。这件事的难点不在于"读不读得完"，而在于文档本身往往是脏的：抬头和正文对不上、单位混着写、注释是反的、数字要自己换算。

这些坑，跑分榜上一个都测不出来。

我拿了一份真实的 llama.cpp 运行日志去考这四档模型。

先说清楚：这不是我埋的陷阱题。这份日志是我早前跑另一个模型时留下的，它本来就长这样——开头有一段工具箱的固定抬头，和这次实际跑的东西对不上。这种"抬头和内容不一致"，在真实日志里太常见了。

题目只有一句话：

你好 帮我提取下日志信息 进行总结和分析

四档各测三次，每次都单开会话，每次都重新读一遍这份日志。

二、四个档位选手

这次把 1.7B 和 4B 两个尺寸、F16 和 Q4 两种精度都拉了出来，凑成四档一起测：

模型

体积

上下文

生成速度

答一轮要多久

上下文是 llama-server 按模型自动配的，四档不一样，所以速度只看量级、不横比。速度篇我会单开一篇讲。Q4 是压过的版本，F16 是原精度。t/s 就是每秒往外吐多少字。

三、文档分析的难点：这份日志里有三处坑

坑 1：抬头写着 111GB，正文只有 4096 上下文

日志抬头是这个：

Qwen4-Flash-Next Toolbox  (Q4_K_M / 111GB / 512Ex)

而正文里实际加载的是另一个模型，配置是 n_ctx_slot = 4096（每槽 4096 上下文）、4 个槽、生成速度 5 t/s。

一个 111GB 的模型，不会只配 4096 上下文，也不可能在 12 线程上跑出 5 t/s。抬头和正文是矛盾的。

坑 2：「512Ex」不是 512 上下文

Ex 是 experts 的缩写，指的是 MoE 架构里的专家数量，跟上下文长度没有半点关系。

坑 3：那句注释，主语不是你想的那个

日志里有一行：

NOTE: -ngl 0 forces pure CPU (auto wastes VRAM and runs slower on this model).

括号里说"会浪费显存、跑得更慢"的是 auto 模式，这是在解释「为什么要强制纯 CPU」。而不是在说「纯 CPU 会浪费显存」。

四、四档模型的文档分析与总结结果：谁掉进去了

我按六个维度打了分，✅ 是过了，⚠️ 是有问题，❌ 是错了：

具体错在哪

1.7B-Q4 把 144680 毫秒算成了 1.45 小时。实际是 144.68 秒，两分半钟。它在报告里写"约 1.45 小时处理 1024 token"，还顺手推出"1.37 小时/千 token"——差了 36 倍。

4B-Q4 把第一个任务的数据，安到了第二个任务头上。第一个任务确实是 144680 毫秒 / 1024 token，但它把这个数字填进了第二个任务的表格里，而第二个任务实际是 50686 毫秒 / 281 token。

三款都把「512Ex」当成了上下文长度。1.7B-F16 写得更远，直接记成"512Ex 显存"。

而 4B-F16 是唯一指出抬头有问题的。它在报告里写：

日志标题配置：显示为 Q4_K_M / 111GB / 512Ex，但实际运行参数中 n_ctx_slot = 4096，以实际运行参数为准。

它还发现了另一处：第一个任务的 prompt 处理，前 197 个 token 用了 52 秒（3.78 t/s），后 713 个 token 用了 87 秒（8.19 t/s）——同一段处理，速度差了一倍多。它给的结论是"需排查是否存在 token 统计口径、阶段划分或异常处理开销问题"。

这个观察，另外三款一份都没提。

但要说句公道话

4B-F16也没有走完最后一步。它说"以实际运行参数为准"，但没有继续往下推——抬头和正文对不上，意味着这份日志的抬头不可信。四款里走到"发现矛盾"这一步的只有它，走到"判定这份材料有问题"的，一款都没有。

所以严格讲，这不是"一个考了满分、三个不及格"，而是四款集体差了最后一公里。

五、两个反直觉的发现

发现一：最慢的那个，读得最明白

4B-F16 生成速度是 9.4–12.8 t/s，比最快的 1.7B-Q4（169 t/s）慢了十几倍。答一轮要 5 到 31 分钟，而 1.7B-Q4 只要十几秒。

但它是四款里唯一看出日志有问题的。

它答一轮要 5 到 31 分钟，而 1.7B-Q4 只要十几秒——因为它写了多得多的思考内容：4B-F16 单轮生成 8683–17924 个 token，1.7B-Q4 只有 2001–2723 个。

而四档里唯一看出矛盾的，恰恰是想得最多的那一档。至于为什么它愿意想这么多——是 4B 尺寸带来的，还是 F16 精度带来的，这一轮测不出来，我不下结论。但结论本身很直接——

读得慢的，可能是在读；读得快的，可能只是在抄。

发现二：想得越久，不等于想得越明白

这条更反直觉。

4B-F16 第一轮想了 12 分钟，拿到了它三轮里最好的答案——就是上面那两份发现。

第三轮它想了整整 28 分钟，生成了 17924 个 token（是第一轮的两倍），答案反而退化了。又写回了"111GB 显存占用""纯 CPU 浪费显存"这些第一轮已经避开的说法。

同一款模型、同一道题，多花一倍的思考量，结果更差。

4B-Q4 也一样：第一轮想了 13805 个 token（2 分 43 秒），第二轮只用了 2800 个（31 秒），两份答案我看不出质量差别。

思考 token 花得多，不等于想明白了，它只是想得久。思考预算在小模型上是不可控的——同一道题，它可能花 2800，也可能花 13805，而产出质量并不跟着涨。

六、那星火 X2.5 到底能干啥

先给一个直接回答：做文档分析和总结，它够用，但只能当"初稿生成器"，不能当"终稿"。

具体说，基于这轮四档同题实测——

能干的：把一份几十页的文档读进去，给你一份结构完整、要点齐全的初稿摘要。这一层四档都能做，4B-Q4 的表格甚至可以直接拿去用。

干不了的：判断材料本身可不可信。四档里没有一款会主动告诉你"这份文档自相矛盾"，它们默认你给的东西是对的。

要留意的：数字换算、任务归属这类细活会出错，快档尤其明显，而且不会标出来——报告看起来一样工整。

如果要拿它干文档分析和总结的活，我的五条建议：

七、下期继续测：它还能干啥

这一期只测了一个能力维度——文档读取、分析与总结。给一份脏日志，看它能不能读明白。

后面我会用同样的路子，一个维度一篇，继续往下测：

• 长文档：官方主打的 1M 上下文，实际上真能塞进去多少？

• 代码与工具调用：官方跑分砸得最狠的 Agent 能力，本地跑是什么样？

• 中文创作：写东西这件事，它比同尺寸模型强还是弱？

同样的机器、同样的四档模型、同样留可复现的日志。官方跑分表有人转，但"它到底能干啥"这个问题，得有人一个一个测过来才知道。

你想先看哪个，评论区告诉我。

测试环境：R9-7900 12C/24T · RTX 3070 8G · 64G · Windows · CUDA 13.3.1 · llama.cpp XHToken fork所有数据来自本机运行日志，可复现。

需要推理引擎的，关注GZH后发送【星火】获取引擎链接。

#讯飞星火 #spark #X2.5 #本地部署 #测试