双 22GB 显卡如何选择 27B 模型量化

“27B 模型用 4 位量化，大概只要 13.5 GB”是一个很容易让部署计划出错的估算。27B × 4 bit ÷ 8 确实得到约 13.5 GB，但那只是纯权重的理论下限。模型文件还可能包含混合精度张量、量化元数据、词表和视觉相关部分；推理时又要为 KV Cache、运行缓冲区和草稿模型留空间。我这次使用的 Qwen3.8-27B Q4_K_M GGUF 主文件约 19 GB。

先分清三个选择

第一是权重精度。FP16/BF16 的 27B 参数只按参数计算就约 54 GB，超过我两张卡合计 44 GB 的显存；4 位权重能显著减小文件与显存占用。第二是文件格式：GGUF 是 llama.cpp 常用的模型容器，Q4_K_M 是其中一种量化类型。第三是运行时缓存精度：KV Cache 的 Q8_0 或 Q5_1 与主模型的 Q4_K_M 是独立设置，改缓存参数不会修改主模型文件。

我的服务器是双 RTX 2080 Ti 22GB，带 NVLink。两个 22GB 不能简单想象成一块无条件共享的 44GB 显卡：还要选择按层分配还是张量并行，并观察每张卡各自的显存余量。最终采用 Q4_K_M 主模型、llama.cpp CUDA、双卡张量切分，给长上下文和 MTP 草稿模型留出空间。这是针对当时硬件和软件版本的选择，不是所有机器的通用最优解。

KV Cache 为什么要单独规划

生成每个新 token 时，推理引擎要保留历史注意力计算所需的 Key 和 Value。上下文越长、并发越多，这部分开销越大。我的部署先在 128K 上下文使用 K/V 均为 Q8_0 验证；升到 256K 并加入图像投影文件时，主模型缓存改为 K=Q8_0、V=Q5_1，草稿模型仍保持 Q8_0/Q8_0。这一组合在实机完成了预分配及基础功能检查。

为什么优先压缩 V？K 会直接参与注意力权重计算，过低精度可能影响长文本定位。Q8_0/Q5_1 是在显存与质量之间的一次谨慎取舍，仍需拿长文检索和代码任务与高精度配置对照。缓存量化主要是节省容量，不能直接当成加速开关。

我采用的验证顺序

1. 用不开投机解码的配置测基础回答和显存，确定主模型、切分方式与缓存能稳定运行。
2. 保持问题、采样设置和输出长度相同，再加入 MTP，比较速度和草稿接受率。
3. 把上下文从 128K 提到 256K，同时检查主模型、草稿模型和视觉组件是否仍能装入两张卡。
4. 用真实任务检查回答质量，尤其是长文中间信息、代码修改和图片输入。

在我的单次 128K 验收中，基础张量切分约 41.55 token/s，MTP 约 63.96 token/s；到 256K、Q8_0/Q5_1 并加载图像组件后，另一次 MTP 测得约 54.08 token/s。这些数字的提示词、草稿接受率和配置并不完全相同，只能说明各次配置可运行，不能据此给出严格的“上下文翻倍导致速度下降多少”的结论。

对有限显存的本地部署，我的经验是先选能完整跑通任务的格式，再优化速度。量化选型最终应回答三个问题：装不装得下、任务质量是否可接受、真实工作流是否顺畅。

资料：Qwen GGUF 仓库 · llama.cpp 项目