本地量化模型显存不足时如何选择上下文长度

本地量化模型显存不足时，优先缩短上下文长度，而不是第一时间把模型换成更低比特。因为显存通常同时被模型权重、KV cache、计算缓冲区和运行余量占用；量化主要影响权重大小，-c 或 --ctx-size 主要影响可容纳的上下文，二者不是同一个开关。

官方地址：https://github.com/ggml-org/llama.cpp/

先把显存分成四笔账

本地推理时最容易混淆的是“模型文件很小”和“运行时显存够用”。模型加载后，权重占用只是第一笔；每个请求还会累积 KV cache，提示词处理和生成过程还需要计算缓冲区，系统本身也不能把显存用到百分之百。

KV cache 保存注意力计算需要重复使用的键和值，随着上下文 token 数增加而增长。一个便于估算的近似式是：

KV 显存 ≈ 2 × 层数 × KV 头数 × 每头维度 × 上下文 token 数 × 每元素字节数 × 序列数

实际占用还会受到滑动窗口、共享 KV、实现方式和对齐策略影响，所以这个式子用来比较趋势，不用来替代启动日志。上下文从 4096 翻到 8192，KV 部分通常也会接近翻倍；权重并不会因为上下文变长而翻倍。

用真实任务给上下文长度设起点

不要从模型宣传的最大上下文倒推显存。先记录一次任务里四个数字：系统提示词 token、用户输入 token、检索或附件展开后的 token，以及希望模型生成的 token。把它们相加，再给工具的上下文上限留出增长空间。

这不是模型能力表，而是配置起点。若最长常见输入只有 2800 token，却把上下文固定成 32768，额外空间会变成 KV cache 和管理开销；如果还要并行服务多个请求，序列数会继续放大这笔成本。

先调上下文和 KV cache，再动量化档位

以 llama.cpp 为例，可以把上下文、KV 缓存类型、GPU 层数和物理批大小分开调。下面只是参数示意，命令没有在本机执行，图示也不是运行截图。

# 先用保守上下文启动，观察模型权重、context 和 compute 的显存账单
llama-server \
  -m ./model-q4_k_m.gguf \
  -c 4096 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  -ngl 99 \
  -ub 512

# 如果仍然紧张，先缩短上下文或降低物理批大小，再比较响应速度与稳定性
llama-server -m ./model-q4_k_m.gguf -c 3072 --cache-type-k q8_0 --cache-type-v q8_0 -ub 256

-ub 影响一次处理的物理 token 批量，通常会影响 prompt 处理阶段的临时缓冲区；它不能替代上下文上限。--cache-type-k 和 --cache-type-v 则是在实现支持时，用不同数据类型存放 KV cache，省显存的同时可能交换一部分速度或精度余量。调参时一次只改一个变量，才能知道是哪一项起了作用。

什么时候才值得换更低比特模型

如果把上下文从 4096 降到 3072 后仍然无法稳定加载，或实际回答质量已经受到 Q4 档位限制，才考虑换量化档位。更低比特通常能显著缩小权重，但会带来质量、速度和算子支持的取舍；更高比特则可能让模型更稳，却挤压 KV cache 的空间。

判断顺序可以固定为：先减少不必要的系统提示词和检索片段，再降低上下文上限；仍不够时减少并发或物理批大小；然后评估 KV cache 类型；最后才在 Q4、Q5、Q8 等档位间选择。对于需要长文档的任务，与其让所有请求共享一个很大的上下文，不如先做分段检索，控制送入模型的 token 数。

用最长常见输入做一次边界检查

最终配置至少要覆盖三种压力：最长的常见输入、目标输出长度和实际并发数。检查时不要只看“能否启动”，还要看生成一段时间后是否出现显存持续上涨、系统换页、速度骤降或第二个请求无法进入。

• 短输入跑通，确认基础启动参数正确。
• 加入真实检索片段，确认上下文没有被悄悄截断。
• 用目标输出长度生成，观察 KV cache 是否达到预期。
• 按目标并发重复请求，确认每个序列的上下文预算没有被平均得过小。

常见问题

把量化从 Q4 换成 Q3 就一定能解决 OOM 吗？

不一定。它主要减少权重占用，KV cache 和计算缓冲区仍可能成为瓶颈；先确认日志中的压力来源。

上下文越大，回答一定越完整吗？

不一定。无关检索内容会增加注意力负担和显存消耗，能覆盖真实任务的最小上下文通常更容易稳定。

为什么单个请求能跑，两个请求就 OOM？

KV cache 通常按序列数增长，并发请求会共享权重但不共享全部上下文状态，所以需要重新计算预算。

能不能只看模型文件大小选显卡？

不能。模型文件主要反映权重，运行时还要为 KV cache、计算缓冲区和系统余量留空间。

显存不足的正确处理不是盲目追逐更大的上下文，而是让上下文预算、KV cache、批处理和量化档位与任务边界匹配。先把真实 token 需求量出来，再逐项调整，通常比直接换一份更低比特模型更可控。