量化翻车现场：IQ3_XS / IQ3_S / NVFP4 / INT4 到底怎么选才不糊

【免费下载链接】StrataQwen3.8-Flash-Next on any consumer hardware: one-click install for Windows / Linux. Strata inference engine, OpenAI/Anthropic API on localhost, optional image input.项目地址: https://gitcode.com/gh_mirrors/strata11/Strata

社区里最近流传着一套 "游戏显卡跑千亿参数模型" 的本地推理叙事：12 GB 显存 + 64 GB 内存就能把 1250 亿参数的 Qwen3.8-Flash-Next 跑起来，IQ3_S 还能保持"接近满血"的精度。但在实际动手之后，越来越多的人在量化选型这一步踩坑——同样的模型，有人 IQ3_S 跑到 53 tokens/s 稳定输出，有人换了 Coder 版在中文对话里直接开始复读；有人上了 4-bit KV Cache 省出一大截显存，长文档任务的困惑度却悄悄涨了 12%。"选哪一档量化"从来不是一个位宽数字的单选题，它同时由内存容量、上下文长度、任务类型和引擎的存储分层共同决定。本文结合 Strata 引擎的真实源码与实测数据，把 IQ3_XS、IQ3_S、NVFP4 与各类 INT4 方案的位宽、成本和翻车点一次讲清楚，并给出可落地的选型顺序。

一、先对齐概念：这四种"量化"根本不是同一层的东西

在讨论"谁比谁糊"之前，必须区分两类量化：权重量化（模型参数本身的压缩）和KV Cache 量化（运行时缓存压缩）。前者决定模型装不装得下，后者决定长上下文时还能剩多少空间给专家缓存。Strata 的仓库里两者都有清晰的分层证据。

权重侧，Strata 主推的是 llama.cpp 系的 i-quant 格式族。打开 include/strata/artifact/gguf_reader.hpp，可以看到引擎为每一种 GGUF 类型登记了精确的块几何信息（每块元素数与字节数），这是计算"每权重比特数"（bits per weight, bpw）的最可靠来源：

注意 Q2_0 在这里不是常见的 2-bit 整数量化，而是 18 字节块装 64 个权重的三值（ternary）编码，这一点在 include/strata/artifact/dequant.hpp 的注释里写得很明确："42 = Q2_0, the PrismML ternary 2-bit encoding this engine targets"。而 IQ3_XXS 与 IQ3_S 的 3 字节多出来的那 0.38 bpw，正是决定"糊不糊"的关键差异——IQ3_S 多付出的那一点空间换回了"在发布测试集上与未量化模型对齐"的官方结论。

NVFP4 则完全是另一条技术线：它是 NVIDIA 的 4-bit 浮点格式（带分组缩放），在 gguf_reader.hpp 的类型表里以类型 40 出现。社区在 RTX 5090 笔记本上用 NVFP4 fork 实测 Qwen3.8-Flash-Next，decode 达 112.7 tokens/s，4K 上下文 prefill 提升约 15%——但要注意，这是 fork 分支的结果，主仓库只在 draft-vocab 的测量注记里顺带提过一笔（docs/DETAILS.md），生产路径并不默认携带该格式的完整支持。至于 INT4，Strata 仓库里真正对应的形态是KV Cache 的 q4_0（见下文）以及实验性的 Unsloth UD-Q4_K_XL 权重包，而非某个统一的"INT4 格式"。

二、吞吐对比：位宽越低越快，但瓶颈不止在显存

先看 Strata 官方在 RTX 5070（12 GB）+ 64 GB RAM 平台上用引擎 0.1.26 实测的数据（docs/MODELS.md、docs/DETAILS.md）：

一组对比数据能直观说明"量化省钱但也要命"：IQ3_S 的专家有 50 GB，在 64 GB 机器上 262K 上下文会让内存见底，所以 docs/DETAILS.md 明确写"IQ3_XXS / IQ3_S 在 64 GB 上推荐最多 128K 上下文"。而 Q2_0 的专家只有约 34 GB，可以一路跑到 262K 满上下文。

双卡场景的数据更有意思。社区在双 RTX 3090 + EPYC 7453 上的原生实测（bench/results/2026-09-29-rtx3090-epyc-milan/matrix.md）：IQ3_XXS 双卡 32K 的 decode 中位数 96.7 tok/s，IQ3_S 双卡则到 106.3 tok/s——位宽更高的 IQ3_S 反而更快。原因是：MoE 模型的吞吐瓶颈不是纯粹的计算位宽，而是"显存里能塞进多少个专家"。IQ3_S 更宽的位宽在多卡分摊后让更多专家驻留 GPU，减少了 CPU 侧的计算负担。这打破了很多人的直觉：在 MoE + 分层存储的架构里，选型不能只看 bpw 一个数。

NVFP4 的 112.7 tok/s 看起来很诱人，但它的前提是 5090 级的大显存（几乎全模型驻留 GPU），且只有 fork 分支支持。对于大多数 12-16 GB 显存用户，这个数字没有参考意义。

三、决策表：按内存、任务与上下文三轴选型

把 docs/MODELS.md 的官方建议整理成可直接照抄的选型表：

按内存容量：

按任务类型：

• 纯代码 / agent 场景：Coder 的 SWE-bench Verified 达到满血模型的 91.3%，LiveCodeBench 98.7%，且吞吐不输 IQ3_XXS——代价见下文"翻车案例"。
• 中文 / 多语言通用场景：必须选全专家模型（Q2_0 / IQ2_XS / IQ3_S）。Coder 砍掉了每层 512 个专家中的 256 个，CJK 能力显著退化。
• 质量优先：IQ3_S 是唯一官方盖章"与满血模型对齐"的档位。
• 速度优先 / 极长上下文：Q2_0。只有它能在 64 GB 内存下跑满 262K，且 decode 最快。

按上下文长度：8K-64K 用 IQ3_XXS 无压力；64K 以上开启 KV streaming（默认从 64K 起，KV 常驻 RAM、VRAM 只留注意力要读的部分）；128K 以上基本只有 Q2_0 / IQ2_XS 在 64 GB 内存下可行。需要 393K+ 超长上下文时还要叠加实验性 rope scaling（实测 yarn 在 293K 处比 linear/none 的每 token 负对数似然低 0.18 nats，docs/DETAILS.md）。

四、实测翻车案例：这些坑都有源码和 issue 佐证

翻车一：Coder 的中文复读机（issue #438）。Coder 砍掉一半专家后，中文与 CJK 输出"came out wrong or looping"——英文正常、中文循环。README 的原话是："Weaker outside code, including Chinese and other CJK text (#438)"。这正是"按速度选型"翻车的典型案例：32 GB 用户为了跑得动选了 Coder，结果一开口就糊。

翻车二：4-bit KV Cache 的隐蔽精度税。很多教程让你无脑--kv q4_0，但 bench/results/2026-09-27-kv-q4/README.md 的实测非常诚实：q4_0 的 KV 单元从 int8 的 1,056 字节压到 576 字节（省约 45%），128K 上下文 decode 提升约 4%——但长文档任务的困惑度+8%（1K）到 +12%（8K），KL 散度是 int8 的 2.6-4.2 倍；int8 与 fp16 在统计上不可区分，而 q4_0 的成本是真实存在的。仓库的结论是：int8 保持默认，q4_0 只是可选项。好消息是 needle 检索测试 5/5 通过——"能检索到"不等于"不糊"，这正是长文档场景最需要警惕的量化盲区。

翻车三：低内存 + 高位宽 = 隐形 SSD 陷阱。IQ3_XXS 在 32 GB RAM 的机器上只能走 mapped 低内存模式：专家从 GGUF 文件直接映射，GPU 装不下的部分每次推理都要从 SSD 读。文档明确警告"with a small one, most experts come from the SSD and it is much slower"。同理，实验性的 UD-Q4_K_XL（111 GB 下载、71.7 GiB 专家）在 64 GB 机器上只有 7-8.5 tok/s——比全驻留的 IQ3_S 慢六倍（docs/UNSLOTH_Q4.md）。"4-bit = 快"是最常见的幻觉：位宽只决定装得下多少，装不下的部分全由存储带宽买单。

翻车四：多卡分层不是免费的。双卡自动分层在 32K 上下文下实测 IQ3_XXS / IQ3_S 都选择了 K=24 分割，但固定 K=18 时启动阶段上传稠密权重直接 OOM（bench/results/2026-09-29-rtx3090-epyc-milan/README.md）。多卡加速的收益（1.3-1.6 倍）建立在正确分层参数之上，手动拍脑袋的分层值可能连启动都过不去。

翻车五：别用"能跑"代替"不糊"。IQ3_S / IQ3_XXS 在 3090 上的 needle 测试 3/3 通过、双轮对话缓存复用正常——但这些正确性检查只能证明检索与缓存没坏。仓库里真正的精度对照手段是教师强迫（teacher-forced）对比：tools/kv_precision_compare.py用同一段文本对比不同配置的 top-1 一致率与 KL 散度，KV q4_0 的翻车正是被这种方法抓出来的。跑通 ≠ 不糊，必须用可量化的对照。

五、"先跑通再调优"的量化落地顺序

结合以上事实，正确的落地顺序应该是"先跑通、再验证、最后优化"四步：

1. 跑通：用安装器默认推荐。Strata 的 setup 会根据你的 RAM 自动推荐档位（README.md 的"Which model should I pick?"表）。不确定就选IQ2_XS——它在 48-64 GB 全场景可用、吞吐接近 Q2_0、质量明显更好，是风险最低的起点。

2. 验证：跑一组基准问题 + 任务代表样本。代码任务用 Coder 自带验证；中文/多语言任务务必先跑几轮母语对话（避开 #438 的坑）；长文档任务用 needle 测试 + 困惑度对照。仓库提供了现成的工具：tools/needle_bench.py 做检索测试，kv_precision_compare.py类工具做精度对照。

3. 升档：确认质量满意后，再逐级尝试更低位宽或更省显存的选项。64 GB 用户从 IQ2_XS 起步 → IQ3_XXS → IQ3_S（质量上限），而不是一上来就顶着内存极限选最大档。上下文目标超过 128K 时主动降档回 Q2_0 / IQ2_XS，而不是硬扛 OOM。

4. 优化：用可逆参数而非换模型来提速。优先做这几件事，全部有实测依据：

   • --calibrate：让引擎在你机器上实测--pcie-frac、--spec-min-p、--pool-workers三个参数（约 5-10 分钟，只在快 3% 以上时保留）；
   • 确认--prefill auto（0.1.13 起 prompt 处理约快一倍）与 KV streaming（64K+ 默认开启）；
   • 只有显存确实不够时，才考虑--kv q4_0（记住长文档 +8-12% 困惑度的代价）或 K8V4 混合缓存（KV 内存再省 23%，docs/DETAILS.md）；
   • 用--stats和GET /metrics观察expert tiers，判断瓶颈到底在 GPU、RAM 还是 SSD——如果大量 blob 来自文件，问题不是量化位宽，而是内存预算。

六、结论

回到标题的问题：IQ3_XS / IQ3_S / NVFP4 / INT4 怎么选才不糊？答案藏在三个维度里：内存决定你能装哪档（IQ3_S 是质量天花板，但 54.8 GB 的胃口只有 96 GB 机器能从容喂饱）、任务决定你必须保哪一路（中文/多语言必须全专家模型，Coder 的省空间是有明确代价的）、上下文决定你能不能上高位宽（64 GB 下 128K 是 IQ3 系列的安全线）。NVFP4 属于大显存 + fork 分支的特定场景，INT4 则要先分清是权重侧（UD-Q4_K_XL 的 SSD 陷阱）还是缓存侧（q4_0 的长文档精度税）。Strata 仓库里每一档位都有实测数字、每一处取舍都有 issue 与基准文件背书——选型的正确姿势不是追逐最低位宽，而是先跑通、再验证、后优化，让"不糊"成为可测量的指标，而不是一句感觉。

【免费下载链接】StrataQwen3.8-Flash-Next on any consumer hardware: one-click install for Windows / Linux. Strata inference engine, OpenAI/Anthropic API on localhost, optional image input.项目地址: https://gitcode.com/gh_mirrors/strata11/Strata