3.2 显存-速度-质量的三角权衡与实测方法论

文档摘要

3.2 显存-速度-质量的三角权衡与实测方法论读者读完这一节，应该能说一句话：INT4 不是「质量换显存」的简单开关，而是把显存、速度、质量三者的约束重新分配了一次；真正的工程决策靠「先定显存上限，再在它框定的方案里用实测选出速度/质量最优」，而不是拍脑袋选一个「最流行」的量化档。上一节我们谈「损失在哪」，这一节谈「怎么选」。无数人卡在第一步：看到一堆量化档位（Q4KM、Q40、Q5KS、IQ4XS……）就晕了，最后随手选一个下载。这一节给你一套先框定约束、再实测取舍的方法论，把「三角权衡」从口号变成可执行的步骤。三角不是等边：哪个角先卡死你？显存、速度、质量三个目标天然互相拉扯。但关键认知是：绝大多数本地部署场景下，先卡死你的是显存，不是质量也不是速度。为什么这么说？

3.2 显存-速度-质量的三角权衡与实测方法论

读者读完这一节，应该能说一句话：INT4 不是「质量换显存」的简单开关，而是把显存、速度、质量三者的约束重新分配了一次；真正的工程决策靠「先定显存上限，再在它框定的方案里用实测选出速度/质量最优」，而不是拍脑袋选一个「最流行」的量化档。

上一节我们谈「损失在哪」，这一节谈「怎么选」。无数人卡在第一步：看到一堆量化档位（Q4_K_M、Q4_0、Q5_K_S、IQ4_XS……）就晕了，最后随手选一个下载。这一节给你一套先框定约束、再实测取舍的方法论，把「三角权衡」从口号变成可执行的步骤。

三角不是等边：哪个角先卡死你？

显存、速度、质量三个目标天然互相拉扯。但关键认知是：绝大多数本地部署场景下，先卡死你的是显存，不是质量也不是速度。

```mermaid graph TD A[你的硬件显存上限] --> B[能装下的最大量化档] B --> C[该档下的推理速度] B --> D[该档下的模型质量] C --> E[是否可接受生成延迟] D --> F[是否通过业务回归] ```

为什么这么说？因为质量在 INT4 主流档位上差距通常不大（尤其大模型的 Q4_K_M 这类成熟档），速度在没有显存瓶颈时往往由其他因素主导。所以第一步永远是「你的显存能装下哪一档」——把显存上限当成硬墙，墙内才是你真正做选择的空间。如果你的显存足够装下 FP16 全量，那本节的权衡就退化成「要不要为速度/显存余量主动降档」，那是幸福的烦恼。

显存账怎么算：别只算权重

很多人以为「INT4 权重是 FP16 的四分之一，显存就降到四分之一」。这是错的，权重只是其中一块。完整账本至少包含四部分：

权重：量化直接受益的部分，INT4 约为 FP16 的 1/4、INT8 的 1/2。这是量化节省的主战场。
KV Cache：随上下文长度和批大小线性增长，长上下文场景能吃掉几 GB 到几十 GB，且量化收益有限（常保留更高精度）。
激活：推理过程中产生的临时张量，取决于实现与批大小，通常远小于权重。
运行时开销：框架、显存碎片、CUDA context 等，几百 MB 到 1~2 GB 不等。

实操建议：用「权重 ×（1 + KV Cache 系数 + 开销系数）」粗估。对 DeepSeek V4 这类大体量模型，若你主要跑中等上下文（8K16K），KV Cache 系数约 0.10.3；若跑 32K+ 长上下文，这个系数会显著放大，此时限制你的可能不是权重而是 KV Cache——这也是为什么长上下文用户有时反而该选「权重稍重但 KV Cache 友好」的方案。

速度的两套逻辑：吞吐与首字延迟

量化对速度的影响不是一句话能讲清的，因为它同时牵动两条不同的指标：

```mermaid graph TB A[量化影响速度] --> B[吞吐 tokens/s 受算力利用主导] A --> C[首字延迟 TTFT 受显存带宽主导] B --> D[INT4 计算密度高但自定义核质量决定收益] C --> E[权重更小加载更快首字更稳] ```

首字延迟（TTFT）：从提交请求到第一个 token 的时间，主要受显存带宽影响——权重越小，从显存搬到计算单元越快，首字越稳。INT4 在这方面几乎稳赢。
吞吐（tokens/s）：持续生成速度，受计算利用率主导。INT4 计算密度更高（同样算力处理更多数据），但前提是推理引擎有高质量的 INT4 内核。如果引擎的 INT4 路径没优化好，反而可能比 FP16 还慢。所以「量化一定更快」是误区，必须实测。

这就引出一条重要经验：同样的 INT4 文件，在不同引擎上速度可能差出一倍。选引擎和选量化档同样重要。

质量档位的真实梯度：不是越新越细越好

社区里量化档位命名让人眼花，但质量梯度有个大体规律（以 GGUF 系 k-quants 为例）：

```mermaid graph LR A[Q2_K] -->|质量最低| B[Q3_K] B --> C[Q4_0 / Q4_K_S] C --> D[Q4_K_M] D --> E[Q5_K_S / Q5_K_M] E --> F[Q6_K / Q8_0] F -->|接近无损| G[FP16] ```

经验法则：

Q4_K_M 是「质量/体积」的甜点区，对大多数大模型是默认推荐起点，质量损失小、体积可控。
Q5_K_M 在质量敏感场景（代码、推理）值得多花那点显存。
Q8_0 通常已接近 FP16 质量，但体积翻倍，除非你显存宽裕且对质量极其挑剔，否则性价比一般。
极低位（Q2/Q3）除非显存极度紧张，否则不推荐——质量损失会不成比例放大。

注意：更细的量化（如 IQ4_XS 这类重要性矩阵量化）在某些模型上能比同体积的传统档更优，但这是模型/版本相关的，必须实测，不能盲信命名里的「XS 更先进」。

实测方法论：把三角摊开，用同一把尺子比

空谈权衡没用，给你一套可复用的实测流程：

```mermaid graph TD A[确定显存硬上限] --> B[列出该上限内能装下的 2~3 个档] B --> C[同一测试集: PPL对比] C --> D[同一业务 prompt: 回归对比] D --> E[同一引擎: 吞吐/首字延迟对比] E --> F[选质量达标且速度最优者] ```

具体步骤：

定墙：先算你硬件的显存上限下能装哪几档（通常选 2~3 个相邻档，比如 Q4_K_M 与 Q5_K_M，或 INT4 与 INT5 混合）。
框质量：用同一测试集测 PPL，再用你的真实业务 prompt 做回归（前一节清单）。先筛掉「质量不达标」的档，哪怕它再快也不要。
比速度：在同一引擎、同一上下文长度、同一批输入下测吞吐与首字延迟。换引擎重测会破坏可比性。
做决策：在质量达标者里选速度最优；若速度都达标，选体积小（留显存余量、支持更长上下文）的那个。

这套方法的精髓是：先用量化把显存墙「推远」，再用实测在墙内选最优，而不是在显存不足的前提下硬跑大档、频繁 OOM。

一个被忽视的第四维：可复现与升级成本

除显存/速度/质量外，还有个隐性成本值得提一嘴——维护与升级。不同量化格式对不同引擎、不同前端（网页/命令行/桌面客户端）的兼容度不同。选一个「你所有常用工具都原生支持」的档，长期维护成本远低于选一个「理论更优但每次都要折腾环境」的档。对多数个人用户，GGUF（配合成熟引擎）的兼容性优势，常常比那零点几个点的 PPL 差距更值钱。

给你的决策清单

我的显存硬上限是多少？预算里是否包含 KV Cache 与运行时开销？
在该上限内，我能装下哪 2~3 个相邻量化档？
同一测试集 + 同一业务 prompt 下，哪些档通过了质量回归？
这些达标档在同一引擎下的吞吐/首字延迟孰优？
我所有常用工具是否原生支持选中的格式（避免长期折腾）？

小结

INT4 的本质是「重新分配显存—速度—质量的约束」：显存通常是先卡死你的墙，速度受引擎 INT4 内核质量左右，质量在主流档位差距有限但长尾/长上下文敏感。决策的正确姿势是先定显存墙、再在墙内用同一把尺子实测选优，而非盲选流行档。至此第3章两节已把「损失在哪」与「怎么选」讲透，下一章我们进入实战，把这一切落到 DeepSeek V4 的真实部署流程上。