星火 X2.5 长输入实测：它能读完 249 行纪要，却数不清 2000 行日志
Spark-X2.5 能力实测第 7 期 · 长输入与多步流水线
机器：R9-7900 + RTX 3070 8G + 64G ｜ 引擎：llama.cpp（XHToken fork）
第 1 期我答应过要测"长文档"。这期就来还这个账。
结论有点反直觉：读长文它不虚，真正要命的是"一边读长文一边数数"。
一、"长"这件事，拆成三种难度
很多人一说"长上下文"，脑子里只有一个数字——能塞多少 token。但真拿它干活，会发现"长"至少分三档难度：
|
低 |
读长文、做摘要 |
把一份长会议记录提炼成要点 |
|
中 |
读长文、还要产出多个东西 |
提炼待办 + 给每个人各写一封提醒邮件 |
|
高 |
读长文、还要精确统计 |
从几千行日志里数出某个错误出现几次 |
这期我三档各出一道题，让 1.7B 和 4B（都用 Q4 量化版）各跑两轮。
二、三道题
题 1 · 长纪要提炼：一份 249 行的会议转写稿（自动转写、没校对，带大量口语废话和跑题），让它提炼决议、待办、风险，并把关键数字抄对。
题 2 · 纪要转待办 + 催办邮件：从纪要里提取待办写进 todo.md，再给每位负责人生成一封提醒邮件——要产出多个文件。
题 3 · 长日志根因定位：一份两千多行的应用日志，混着 5 个服务的正常与异常记录，让它定位①故障服务名 ②故障时间窗 ③最主要的错误码 ④这个错误码一共出现多少次。
第 3 题我特意强调了："请用工具统计，不要目测。"
三、结果：两档在"最难的那题"上一起栽了
|
长纪要提炼 |
低 |
2/2 |
2/2 |
|
纪要转待办 + 催办邮件 |
中 |
2/2 |
1/2 |
|
长日志根因定位 |
高 |
1/2 |
0/2 |
|
合计 |
2/3 |
1/3 |
四、反直觉的第一件事：长纪要，两档都不虚
我原本以为"长"会先从长度上把 1.7B 压垮。结果完全相反——
249 行的会议转写稿，1.7B 和 4B 都是 2/2 全过。
而且1.7B 只用 2 次工具调用、97 秒就完成了：4 位负责人的待办全提取、关键数字（注册转化率 +5%、预算 65 万）全抄对，还主动写了一句"本总结仅依据原文讨论内容，未新增信息"。
反观 4B，第二轮花了550 秒（比第一轮慢 6 倍），做的活一样。
所以：长上下文理解，不是小模型的短板。只要任务是"读进来 → 写成一份东西"，它的注意力是够用的。这推翻了我对"1.7B 读不了长文"的预判。
五、反直觉的第二件事：要了命的是"统计"
真正的分水岭在第三题——要在两千多行里数出某个错误码出现了多少次。
这一题：
-
4B：1/2（一轮过，一轮崩）
-
1.7B：0/2（两轮全崩）
为什么"读长文"没问题，"读长文 + 数数"就崩？
因为这两件事的能力要求完全不同：
-
提炼摘要是"理解"——模型擅长；
-
精确计数是"把长文件交给代码去数"——这要求模型主动想到"我不该用眼睛数，我该写一行命令"。
而两档模型的第一反应，都是"先把整个文件读进来看看"。
六、两种失败，都不是"算错"，是"没走到算"
这期最有价值的部分，是把两轮失败的命令序列翻出来看——它们的失败方式完全不同，但都不是"算错了答案"。
失败 A（4B 第一轮）：全量读取陷阱
4B 第一轮其实是这么干的：先列目录 → 试着读文件 → 然后反复用命令把整个两千行日志读进来→ 读到输出被截断 → 又去折腾字符编码 → 反复折腾……
它把全部时间花在"怎么把这份大文件完整读进来"上，从没想过"我只需要把 E5032 筛出来数一下"。结果 600 秒用尽，一个交付文件都没写出来。
同一个模型、同一道题，第二轮换了个思路：不去全量读，直接用命令过滤 + 计数（把符合条件的行筛出来数）——115 秒，过了。
同一颗脑子，一次崩一次过，差别只在它当轮选了哪条路。
失败 B（1.7B 第二轮）：解释器寻找死循环
1.7B 这一轮更极端：25 次工具调用、949 秒，从头到尾没有做出一次有效的日志分析。
它的命令序列是这样的：
试 python –version → 失败
看 node –version / 找 python → 失败
写一个 Node 脚本去分析日志 → 跑不起来，失败
翻遍安装目录找解释器 → 继续失败
它自己给出的旁白很说明问题：
"Node is available (no Python). I'll write a Node.js analysis script to…"
——它先试 Python，命令失败，就判定"这台机器没有 Python"，转而写了 Node 脚本；结果 Node 实际也调不通；于是它掉进了"找解释器 → 写脚本 → 跑失败 → 再找解释器"的死循环，二十多次调用全部消耗在"找工具"上，一次日志分析都还没开始。
对比 4B：4B 全程用系统自带的命令行工具完成统计，压根没依赖 Python/Node，所以绕开了这个坑。
七、这期最该知道的一件事：可用性是概率
把上面两个失败放一起，会得到一个很朴素的结论：
同一个模型、同一道题，两轮结果可以完全相反。
-
4B：第一轮崩（600 秒超时），第二轮过（115 秒）；
-
1.7B 的"纪要转待办"：第一轮过，第二轮崩（把题目里的格式模板 <负责人>:<事项> 原样抄了三遍，一个字都没填）。
所以"我试了一次能用"这句话，在端侧小模型上基本没有信息量。它的稳定边界是模糊的——成败有时取决于它当轮"摸到"的第一条路是不是对的那条。
对你有两个直接含义：
要它干关键活，多跑几遍，取多数（我这边定的是"多次里至少过半"）。
能预先告诉它"该怎么干"，就别让它自己摸索——比如明确写"用命令过滤和计数，不要整份读取"。
八、那到底怎么用它读长文件
能干的：把长文档读进来、理解、写成一份摘要或待办——这个两档都能做，1.7B 甚至更快。
要留意的：一旦任务里出现"从长文件里精确数出某个东西"，两档都会开始摇。这不是它们算得不准，是它们很可能会选错工具路线（要么整份读，要么找脚本环境找到死）。
给你的四条建议：
读长文、写摘要，1.7B 够用且更快——别被"长"字吓到。
"统计长文件"的活，在提示词里直接指定方法："用 grep / 过滤命令计数，不要读取整个文件"。
它的第一个瓶颈往往是"环境"，不是"智力"——这类活要么提前把可用的解释器/命令准备好，要么让它用系统自带命令。
一题多跑几遍。 同一道题崩一次过一次，太常见了。
九、下期预告
第 6 期里，"配置差异对比"那道题，1.7B 反超了 4B——当时我说"留到下一期解释"。
下期就是它：我做一个对照实验——同一道题、同一个模型，只换一个变量（精度），看它到底伤了什么。结论我先放一半：量化伤的不是脑子，是手。
测试环境：R9-7900 12C/24T · RTX 3070 8G · 64G · Windows · CUDA 13.3.1 · llama.cpp XHToken fork素材说明：长纪要 / 长日志为程序化生成的合成语料（含真实噪声特征：口语插入语、跑题、多服务混合日志、干扰数字），任务结构与真实业务一致。判分口径：读模型落盘产物与真值比对；多数决（两轮需两轮全过）。全部数据来自本机运行日志，可复现。
