北京
本地大模型圈子里，隔三差五就有人问：“Q4 量化跑工具调用到底安不安全？”得到的答案几乎全是道听途说——有人用某个模型跑了几百小时就说没问题，然后推到所有场景。我烦透了这种靠感觉拍胸脯的讨论，干脆自己搭了个基准测试，叫 QuantCall，专门盯着量化带来的退化是不是真能靠统计说话，而不是用眼睛看两个置信区间碰没碰上。
测试全程跑在我自己那台老笔记本上，一张 RTX 3050，显存只有 4096 MiB。所以你别嫌我选的模型小——0.6B 到 1.7B 参数——这正是这档硬件上真实在用的东西。基准用了 BFCL v4 的 T1 简单/多重调用和 T6 无关任务，每类抽 200 样本，跑 3 个随机种子，贪心解码，温度设 0。看的指标也不花哨：模式有效性（SVR）、工具选择准确率（TSA）、参数正确性（AC）、拒答准确率，外加一个加权综合分 FCR。
头号结论很干脆：模型家族比模型大小更能预测量化的坑有多深。Qwen3‑1.7B 的 fp16 原版权重根本塞不进 4GB 卡的可用上下文——把长度设到 4096 或者 2048 就直接 CUDA 内存溢出，只有 512 能加载，但这个长度根本吞不下 BFCL 的工具模式提示。所以 Q8_0 是它公开的降级基线，没藏着掖着。而真正值得咂摸的是两件事：Qwen3‑0.6B 一路扛到 Q4_K_M 都没出现显著的模式有效性滑坡，只有 AC 和 FCR 在最低的量化档位上才掉；反过来，Llama‑3.2‑1B 的模式有效性从 Q8_0 起就脆得像薯片，而 Q8_0 可是很多人默认认为“基本无损”的档位。它的绝对 AC 也从头烂到尾，老爱吐出带引号的字符串数字，比如 “10” 而不是 10，被正确的 JSON 模式校验一枪毙掉。
同样标成 1B 和 0.6B 的部署量，一上量化就完全不是一回事了。而且任务越难，差距越大——T1+T6 是 BFCL 最简单的层级，只涉及单次调用或者根本不需要调用。我又额外跑了 T2 并行调用和 T3 ToolACE 真实目录，在 fp16 和 Q4_K_M 下一对比，Llama 在并行和 ToolACE 这类任务上的模式有效性崩盘幅度，大约是简单单次调用场景的 5 倍。只测简单层级，你恰恰会低估对 Agent 最致命的失败模式。
我还专门记下两个阴性结果。用 GBNF 约束解码强行规定输出必须符合模式，居然于事无补——先修掉一个挡了正常拒答的真实语法 bug 之后，给 Qwen3 加上语法约束也没有在 SVR 或 AC 上测得明显提升，反而每轮推理多花了 6% 到 86% 的墙上时间，实实在在的成本，换来零可测收益。服务后端也没能独立于量化之外做出什么改变：Qwen3‑0.6B 在 llama‑cpp 的 GGUF 和 transformers 的 bf16 两种部署下，只要精度对齐，SVR、AC、FCR 就区分不出来，说明前面那些退化全是量化本身的效果，跟推理引擎无关。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
