DeepSeek V4 Flash 本地量化对比：IQ3_XXS 与 Q2_K_XL

/research/dsv4-iq3-vs-q2xl-agent-evaluation.md

在单台 DGX Spark 上，使用相同推理配置，对 DeepSeek-V4-Flash-0731 的两种 GGUF 量化版本进行了 Agent 能力测试。结果很明确：如果主要运行复杂终端 Agent，IQ3_XXS 更值得保留；Q2_K_XL 的价值主要是节省约 7–8 GiB 内存，为更长上下文或其他常驻服务让出空间。

测试日期：2026-08-06 测试设备：DGX Spark，121.63 GiB 统一内存对比版本：Unsloth UD-IQ3_XXS 与 UD-Q2_K_XL

测试方法

测试不是普通问答，也没有使用 LLM Judge。两种量化运行在同一硬件和同一版本的 llama.cpp 上，采用相同配置，并由 benchmark 自带测试器判定最终产物是否通过。

项目	固定条件
基础模型	DeepSeek-V4-Flash-0731
推理框架	llama.cpp，同一 commit
Context	131,072 tokens
K/V cache	Q8_0 / Q8_0
并发	1 slot，严格串行
GPU offload	全部层
Temperature	0
Agent 工具	单一真实终端工具
Agent 最大轮数	20
单项任务上限	1,800 秒
判分方式	Terminal-Bench 官方测试、BFCL V4 官方 evaluator

评测由两部分组成：

Terminal-Bench Core 0.1.1 固定五题：考察长程规划、代码修复、文件取证、逆向分析和真实命令执行。
BFCL V4 固定四题：考察正常多轮调用、长上下文，以及缺少函数或必需参数时的停止策略。

这是一组规模较小、但难度较高的本机选型测试，不是 Terminal-Bench 或 BFCL 完整榜单成绩，也不应外推为模型的通用能力百分比。

模型与资源占用

对比项	IQ3_XXS	Q2_K_XL	差异
权重体积	约 97.05 GiB	约 90.18 GiB	Q2 少约 6.87 GiB
量化信息	3.0625 bpw	Q2_K Medium	IQ3 精度更高
稳态 MemAvailable	约 17–19 GiB	约 25–26 GiB	Q2 多约 7–8 GiB
已验证配置	131K Context、Q8 KV	131K Context、Q8 KV	相同

Q2_K_XL 的资源优势真实存在，但它换来的不是本轮可见的 Agent 能力提升，而是更多内存余量。若机器还要同时承载其他模型，或确实需要把 Context 扩展到 262K 以上，Q2 才更有吸引力。

Terminal-Bench：IQ3 在最难任务上拉开差距

总分

量化版本	通过	总数	成功率
IQ3_XXS	3	5	60%
Q2_K_XL	2	5	40%

逐题结果

任务	主要能力	IQ3_XXS	Q2_K_XL	观察
Blind Maze	长程规划、交互探索、算法实现	通过	失败	IQ3 完整探索并精确还原 10 个未知迷宫；Q2 的工具参数 JSON 损坏
SWE-bench Langcodes	真实仓库 Bug 修复	通过	通过	两者都修复了 `__hash__` 与 `__eq__` 不一致问题
New Encrypt Command	工具发现、参数选择、文件操作	通过	通过	两者都正确使用最安全的加密方式
SQLite DB Truncate	损坏数据库恢复、严格 JSON	失败	失败	两者都未恢复到官方要求的数据集
Write Compressor	逆向、约束满足、二进制处理	失败	失败	两者都未生成满足大小与内容约束的压缩文件

唯一出现胜负差异的是难度最高、轨迹最长的 Blind Maze。IQ3 在约 21.6 分钟内完成 10 个未知迷宫的探索与精确建图，并通过全部官方检查；Q2 在向终端工具传递多行 Python 时生成了未闭合的 JSON 字符串，请求中止。

原始错误为：

Failed to parse tool call arguments as JSON
parse error at line 1, column 278
invalid string: missing closing quote

这类失败对真实 Agent 很关键。复杂 shell 参数、内嵌代码和长工具轨迹，恰好是终端 Agent 的常见工作负载。IQ3 的优势不是多答对了一道短题，而是在更接近真实工作的长程任务中维持了工具调用可靠性。

BFCL V4：正常调用相当，异常停止都不可靠

量化版本	Base	Long Context	Missing Function	Missing Parameter	总分
IQ3_XXS	通过	通过	30 分钟超时	30 分钟超时	2/4，50%
Q2_K_XL	通过	通过	官方判错	30 分钟超时	2/4，50%

BFCL 没有拉开两种量化的总分，但暴露了一个共同问题：两者都能处理正常多轮和长上下文工具链，却不善于识别“现有工具无法完成任务”或“必需参数尚未提供”。典型表现包括：

持续重复调用工具；
单轮推进 10–16 个 step；
生成接近 16K tokens 的单次输出；
没有及时停止、解释缺失条件或向用户追问参数。

因此，这部分结果更像是对 Agent harness 的警告，而不是量化版本的胜负：生产环境应设置工具循环上限、completion 上限、重复调用检测和明确的参数缺失策略。

综合对比

维度	IQ3_XXS	Q2_K_XL	判断
Terminal-Bench	3/5，60%	2/5，40%	IQ3 胜
BFCL V4	2/4，50%	2/4，50%	平局
九题机械合并	5/9，55.6%	4/9，44.4%	仅作本机选型参考
复杂长程 Agent	成功完成最难任务	工具 JSON 中途损坏	IQ3 更可靠
正常多轮工具调用	通过	通过	相当
缺失工具/参数处理	不可靠	不可靠	都需 harness 保护
内存余量	约 17–19 GiB	约 25–26 GiB	Q2 胜
更长 Context 潜力	较低	较高	Q2 更适合容量优先场景

时间和 token 没有直接列为速度排名。IQ3 五题合计耗时更长、token 更多，主要因为它继续完成了 Blind Maze；Q2 在该题约 799 秒时提前失败。成功路径与失败路径长度不同，不能据此宣称 Q2 解码更快。

结论

默认选择：IQ3_XXS。

理由有三点：

IQ3 赢下了唯一产生明确差异的任务，而且这道题最接近真实终端 Agent 的长程工作负载。
Q2 没有任何任务独赢，节省内存并未在本轮转化为能力优势。
IQ3 在 131K Context、Q8 KV、单 slot 配置下仍保有约 17–19 GiB 可用内存，作为单模型 Agent 服务已经具备可接受的安全余量。

Q2_K_XL 并非没有价值，但适用目标不同。 当部署目标是更长 Context、同时保留其他常驻服务，或任务以普通问答和短工具调用为主时，Q2 多出的约 7–8 GiB 内存更有意义。若核心需求是复杂 coding Agent、长工具参数和多轮自我修复，当前证据更支持 IQ3。

还应注意，两种量化都需要更严格的 Agent 运行保护。模型精度不能替代执行层控制；工具循环、重复调用、JSON 解析失败和参数缺失，最终都应由 harness 设定明确边界。

复现边界

组件	版本
Terminal-Bench	`d28711d0da2675d0bb1d56de45ae5df6082438a3`
Gorilla / BFCL	`6ea57973c7a6097fd7c5915698c54c17c5b1b6c8`
llama.cpp	`c8e03ce8122b7af76f836d53efde6df1ce5ec437`

所有候选 Terminal-Bench 任务均先通过官方 Oracle 自测。早期自拟题因区分度不足且发现判分预期错误，整轮作废，没有计入上述结果。