LAST VERIFIED / 最后验证2026-09实测路线以文中标注为准
显存与量化进阶
继 GGUF 量化与显存 之后的进阶篇：搞清"显存到底被谁吃了"，以及量化档位怎么选。
显存的三本账
跑一个模型，显存主要被三块吃掉：
| 账目 | 是什么 | 大小感受 |
|---|---|---|
| 模型权重 | 量化后的模型参数本体 | 固定开销，由量化档位决定 |
| KV Cache | 每个 token 的注意力缓存 | 随上下文长度线性增长，长对话的隐形大户 |
| 激活/临时 | 计算过程的中间结果 | 与批大小、分辨率（画图/视频）相关 |
模型权重：量化后的模型参数本体·固定开销，由量化档位决定
KV Cache：每个 token 的注意力缓存·随上下文长度线性增长，长对话的隐形大户
激活/临时：计算过程的中间结果·与批大小、分辨率（画图/视频）相关
很多人以为"模型能装下就能跑"——错，开个长上下文，KV Cache 可能比模型权重还大。
量化档位怎么选
以 GGUF 系为主流的经验规律：
- Q3 及以下：体积最小，但质量下降可感知，只建议极端硬件受限时用；
- Q4_K_M：均衡之选——绝大多数场景的默认答案；
- Q5_K_M：质量比 Q4 明显提升，体积涨幅可接受，显存富裕一档时优先；
- Q6：接近 Q8 的效果，体积中间态；
- Q8_0：几乎等同原始精度，体积约等于 fp16 的一半。
规律：Q4→Q5 的质量提升最明显，Q6 以上边际收益递减。
⚠️ 避坑：①文件名里带
_K_M是"混合量化"（关键层保精度），比同数字的老式量化好——别只看数字大小； ②量化只省"权重账"，不省 KV Cache——长上下文照样爆显存。
KV Cache：长对话的头号杀手
KV Cache 大小与上下文长度 × 层数 × 注意力头维度成正比。经验账：
- 同模型下，上下文从 4K 拉到 32K，KV Cache 大约翻 8 倍；
- 支持 GQA（分组查询注意力）的模型，KV Cache 比老式 MHA 模型小几倍——选新架构模型有实打实的显存红利；
- 多轮长对话"用着用着变卡/爆显存"，基本都是 KV Cache 涨的。
⚠️ 避坑：显存不足时的参数调整优先级：先降上下文长度（省 KV）→ 再降量化精度的内存占用（如开启 kv 缓存量化）→ 最后才考虑换小模型。
显存-能力速查（经验值，以实际为准）
| 显存 | LLM 可跑范围 | 画图 | 视频 |
|---|---|---|---|
| 8 GB | 7-8B Q4 | SD1.5 / SDXL 轻量 | 小模型 480P 短片段 |
| 12 GB | 7-8B Q5-Q8 / 14B Q4 | SDXL 舒适 / FLUX 量化 | 中小模型 480P |
| 16 GB | 14B Q5+ / 32B Q4 | FLUX 量化舒适 | 中模型 720P 吃力 |
| 24 GB | 32B Q5+ | FLUX 全精度 | 大模型 720P 可跑 |
8 GB：7-8B Q4·SD1.5 / SDXL 轻量·小模型 480P 短片段
12 GB：7-8B Q5-Q8 / 14B Q4·SDXL 舒适 / FLUX 量化·中小模型 480P
16 GB：14B Q5+ / 32B Q4·FLUX 量化舒适·中模型 720P 吃力
24 GB：32B Q5+·FLUX 全精度·大模型 720P 可跑
判断"跑得动"还是"在硬撑"
- 任务管理器看不到全部：NVIDIA 显卡看
nvidia-smi的专用显存占用； - "能启动"不等于"跑得快"：显存不够时系统会偷偷把层丢给内存/CPU（offload），能跑但速度断崖——宁降参数，不硬撑；
- 出现"系统整体卡死"而非报错退出：多半是吃到了共享内存（拿内存当显存用），比 OOM 报错更糟，主动把参数降下来。
⚠️ 避坑：Windows 上"共享 GPU 内存"是陷阱——它显示的数字很大，但那不是真显存，用上了就是性能灾难。
相关
- 量化是什么、Q4/Q8 的对照速查：GGUF 量化与显存
- 环境版本的坑：CUDA 与框架版本匹配