llama.cpp 量化格式选择与上下文长度配置

在 llama.cpp 里，量化格式和上下文长度解决的是两类不同的资源问题：Q4_K_M、Q5_K_M、Q6_K、Q8_0 主要改变模型权重的占用与精度取舍；--ctx-size 决定一次请求能容纳多少提示词、历史消息和生成空间，并会影响 KV cache 的内存压力。实际配置建议先选能装进设备的量化档位，再按请求长度逐步增加上下文，而不是一开始把两个参数都拉到最大。

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

先把权重占用和上下文容量拆开

一个 GGUF 模型文件装载后，量化格式影响的是权重本体；上下文长度则影响推理过程中保存的注意力状态。前者更像“模型能否装下”，后者更像“单个请求能走多远”。因此，换成更低位宽的文件不等于可以无限扩大上下文，扩大上下文也不等于能弥补过度量化带来的质量损失。

可以先做一个粗略判断：设备内存减去系统、后端和运行时开销后，剩余空间要同时容纳模型权重、KV cache 和工作区。量化档位只解决第一项；当提示词变长或并发序列增加时，KV cache 仍可能成为新的瓶颈。

量化格式要按内存与质量目标选择

llama.cpp 的量化选项包含传统 Q 格式和 K/I 量化族。日常本地推理可以把候选范围先收敛到下面几档，之后再用自己的任务样本比较，而不是只看文件名里的数字：

一个实用顺序是：先确认目标模型的 GGUF 文件能稳定装载，再以 Q4_K_M 作为基线；如果代码生成、工具调用或专业术语任务出现可重复的质量损失，并且还有内存余量，就换 Q5_K_M 或 Q6_K。比较时固定提示词、采样参数和上下文长度，只替换量化文件，结论才有意义。

上下文长度要按请求预算配置

--ctx-size 的值应该覆盖一次请求的输入和输出预算，而不是盲目追求模型宣传的最大上下文。可以把预算写成：历史消息 + 当前提示 + 预留输出 + 少量安全余量。长文问答需要更多输入空间，短指令任务则不必为用不到的 token 长期支付 KV cache 成本。

llama.cpp 的服务参数中，-c 或 --ctx-size 用于设置提示词上下文大小，设置为 0 时由模型配置决定。落地时建议从 4096 或 8192 这类可控档位开始，确认请求不会截断且内存稳定后，再按 2 倍递增；如果同时提高并发序列，还要重新观察峰值占用。

用一条启动命令固定第一版配置

下面的命令只展示配置入口，模型文件名和设备层数按实际环境替换。代码中的注释说明参数职责，不代表已经在本机执行过：

# 以 Q4_K_M 模型作为内存友好的基线
MODEL="./models/model-q4_k_m.gguf"

# 先用 4096 token 上下文跑通单路请求，再根据峰值占用调整
./llama-server \
  -m "$MODEL" \
  --ctx-size 4096 \
  --n-gpu-layers 99 \
  --host 127.0.0.1 \
  --port 8080

排查时把变量分开：模型加载失败优先检查 GGUF 文件、后端和量化档位；启动后很快内存上涨或请求变慢，优先降低上下文、减少并发或调整批处理参数；输出质量异常，则固定上下文与采样参数后比较相邻量化档位。不要一次同时更换模型、量化和上下文，否则无法知道是哪一项造成变化。

相关问题

Q4_K_M 一定比 Q5_K_M 快吗？

不一定。Q4_K_M 通常权重更小、内存带宽压力更低，但实际速度还受后端、批大小、上下文长度和硬件支持影响，应使用同一组输入做对照。

把 --ctx-size 调大能提升回答质量吗？

只有当原配置确实截断了必要上下文时才有帮助。上下文已经够用时，继续增大只会增加 KV cache 压力，并可能降低吞吐。

应该先换量化格式还是先调上下文？

模型装不下时先处理量化；模型能装下但长请求被截断时先处理上下文。两项都需要调整时，一次只改一个变量并保留同一组评测样本。