顺带说一句代价：UD-IQ4_XS 是全线更慢——同负载下 prefill 慢 29%、decode 慢 16%，而 3-bit 这边稳定后基本不读盘。所以「4-bit 一定比 3-bit 聪明」这个直觉，这次实测里只在一个角落成立。

总览（一眼看完）

两件事值得先记住：① 差距最大、也最贴近日常重活的几项（推理/数学、代码、长上下文、速度）全是 IQ3_S 赢；② 4-bit 唯一的优势项来自单轮 BFCL，±5pp 里含噪声。

免责声明

数据只代表我这台机器、当前 ROCm 栈与引擎版本，不建议外推到别的卡或别的量化。两个模型互斥加载（59GiB 内存只够一个常驻）、同一台机器、同一份引擎、同参数、同题序（同 seed）串行跑。

§1 环境与被测对象

两边完全相同的运行参数：256K 原生上下文、KV int8、KV 常驻 pinned RAM 32K、MTP 投机 --spec 4、服务端 reasoning_effort=none（关思考）、功耗墙 210W、dpm=auto。差别只在加载模式：IQ3_S 跑 low-RAM（mmap 专家 + RAM 副本），UD-IQ4_XS 跑 RAM 预算模式（预算 31GiB，其余按需从文件读）。

测法一句话：三套基准都打同一个 OpenAI 兼容端点、只换 model-id；速度直接取引擎日志（prompt N tokens ... in X ms (P tok/s), M generated in Z ms (D tok/s)），prefill 与 decode 分开统计，累计 4700+ 次请求、约 240 万输出 token。

§2 能力对比

2.1 LiveBench（80 题，10 任务 × 8 题，逐题配对）—— IQ3_S 全线领先的一栏

逐题配对：IQ3_S 独对 7 题、UD-IQ4_XS 独对 0 题 → McNemar 双尾 p = 0.0156（显著）。
也就是说这 8 分不是采样噪声：UD-IQ4_XS 连一道 IQ3_S 答错的题都没捞回来，输的全是自己答错的。而它输得最惨的正是最需要长链推理的那几项——奥赛数学 −33.9、代码生成 −12.5、语言推理 −12.5。

2.2 BeyondBench（ICLR 2026 抗污染推理，29 个共有 medium/hard 任务）—— 打平，但 IQ3_S 微微在前

逐样本配对（同 seed → 同一批题，630 个样本）：IQ3_S 78.3% vs 77.3%，IQ3_S 独对 16、UD-IQ4_XS 独对 7 → p = 0.0931（不显著，但方向是 IQ3_S）。

差距集中在几个「算法味最重」的题上，其余 24 项逐题完全相同：

两边同为 0 分的 5 项：algebraic_sequence、complex_pattern、geometric_sequence、prime_sequence、tower_hanoi——这两个量化在这几题上都不会做。

2.3 BFCL V4（工具调用，核心 7 类 = 1390 条）—— 4-bit 唯一翻盘的地方

这是 UD-IQ4_XS 唯一的加分栏，值得记下：它在"并行调用"和"该不该调用"上更稳（+13.5 / +10），Java 那 +19 也很醒目。但请注意这是单轮结果（BFCL 惯例就是单轮），±5pp 里含噪声；而且同栏里 Python 简单调用它反而差 4.8pp——它不是全面更会调工具，是"某些子项上更稳、某些子项上更容易写歪"。

2.4 三套合起来看：能力画像

看这一栏的结论很清楚：IQ3_S 赢在"需要真思考"的题目上，而且赢面更大；UD-IQ4_XS 赢在"要不要动手、要不要一次动手多个"的调用判断上。

2.5 比分数更有意思的现象：4-bit 话更多、分更低

同一批题下，UD-IQ4_XS 的输出总量比 IQ3_S 多 56%（147 万 vs 94.4 万 token），但分更低。翻答案能看到原因：

• 它的答案有效部分明显更短，好几条尾部是推理打转——原话像 Let's re-read the composite part carefully. / No, I used 18 for ... 这种来回自我怀疑；
• 多条答案直接撞上 12000 token 上限被截断（奥赛题里 IQ3_S 的答案长度接近它的 1.6 倍，反而全须全尾）；
• 它不是"不会"，而是更容易想岔了之后在原地绕——这在需要一次改对、或者红线约束明确的活上代价很大。

§3 速度对比

3.1 同负载引擎侧数据（这才是可比的口径）

• prefill（读 prompt）慢 29%、decode（生成）慢 16%——全程一边倒
• 投机接受率 88% vs 87%，差距不是投机造成的，是模型本身的算力/内存路径
• 换算成体感：用 4-bit 的代价是每个 prompt 多等约 29%、每个 token 多等约 16%；它这话还更多，实际墙钟差距更大

3.2 各自单独测的场景数字（不同题面，供参考）

3.3 为什么慢：驻留结构不一样（引擎自报）

UD-IQ4_XS 的读盘行为实测很具体：首次加载读 25.9 GB；一条 16.9K token 的长 prompt 触发 14.5 GB 读盘（prefill 会把冷专家全拉进来）；但纯聊天/长输出只增 177 MB。所以它是**「短对话几乎不啃盘、长文档读取狂啃盘」**——这正好解释了为什么它的 prefill 掉得比 decode 更狠（−29% vs −16%）：prompt 越长大文件读取越吃亏。而长文档、长会话恰恰是日常最容易碰到的场景。

§4 结论：IQ3_S 更值得留在机器上；4-bit 的价值在一个窄场景

我自己的取舍：留 IQ3_S。 我的活是高约束的代码改造（改一个既有 Rust 内核、红线模块零 diff、默认构建要逐位不变），改错一次整批作废，风险在"改对了没有"而不在"工具调用格式对不对"；再加长会话里 prefill 快 29-42% 是实打实的墙钟收益。4-bit 那边我唯一会考虑换过去的场景：如果你的日常主要是 agent 式活（读文件、查数据、串工具为主，推理深度要求不高），那它在并行调用与"该不该调用"上的稳定性可能值那 20-30% 的速度损失——但这属于"按你的活来定"，不是它的能力全面更好。

§5 读这些数时要注意的（影响解读，不是操作指南）

1. 4-bit 的唯一优势项来自单轮 BFCL（±5pp 含噪声），也是本次最难复现的一项；相比之下 LiveBench 与 BeyondBench 都是逐题配对的，可信度更高，而这两套的结果都偏向 IQ3_S。
2. BeyondBench 有 6 个 hard 任务被框架自身卡住（题目生成器 24 分钟 0/8，或在某些规模参数下 0 秒零样本）→ 这些任务两边一起跳过，是框架问题不是模型问题。
3. BeyondBench easy 档已饱和（两边都基本满分）→ 有区分度的只有 medium/hard；本次对比只在 29 个共有任务上做。
4. 别只看准确率：UD-IQ4_XS 的低分一部分来自答案被 12000 token 上限截断和推理打转，所以除了 accuracy 还要看答案长度与截断率。
5. LiveBench 的公开题库只到 2024-11-25（2025 之后的 release 官方不公开），所以想找"更新鲜的题"得换基准，不是换 release。
6. 这个 4-bit 打包用 --compat-bf16，官方自己测过同文件困惑度比 llama.cpp 高 6-9%（修法未进当版）——跟上面"4-bit 在推理题上反而更差"方向一致，但不是因果证明。

数据来源：本机自定义基准流程采集的引擎日志 + 逐题判分明细。三套基准合计 4700+ 次请求、约 240 万输出 token；两个模型同题同参、逐题配对检验。