大模型推理性能优化：量化、KV Cache与连续批处理落地

大模型推理性能决定线上服务的延迟与吞吐，也直接决定算力成本。把参数量几十亿的LLM部署到线上，真正的瓶颈往往不在模型本身，而在显存带宽、显存容量和调度方式。本文围绕量化、KV Cache、连续批处理三个方向，给出可落地的大模型部署优化方案，附带框架选型建议。

大模型推理的瓶颈在哪里

大模型生成是逐token自回归，一次生成一个token。这里有两类瓶颈：

一是显存带宽。每生成一个token，都要把全部权重从显存读一遍，权重越大带宽消耗越大，推理速度被带宽卡死，而不是算力。二是显存容量：权重、激活值、KV Cache三部分都要占显存。部署前先用公式粗算：

权重显存 = 参数量 × 每参数字节数
7B模型 FP16 约14GB，INT8 约7GB，INT4 约3.5GB

KV Cache = 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 批次数 × 2字节

估算结果超出可用显存，就要从量化或调度入手。

模型量化：INT8与INT4降低显存占用

量化把权重从FP16压缩到8bit或4bit。INT8基本无感，INT4需要校准集，量化后质量略有下降。生产环境常用GPTQ、AWQ生成4bit模型再加载，开发调试时可用bitsandbytes快速加载：

from transformers import AutoModelForCausalLM, BitsAndBytesConfig

quant_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype="float16",
)
model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen2.5-7B-Instruct",
    quantization_config=quant_config,
)

量化后要关注两点：KV Cache仍是原始精度；低bit模型在长上下文、代码生成类任务上可能有精度损失，上线前准备一组评测样本验证。

KV Cache优化：从显存大头到可复用资源

KV Cache随序列长度线性增长，长上下文场景下是显存第一消耗大户。优化手段：

1. 限制最大长度：按业务实际设置max_len，超长文本先摘要再推理。
2. 分页注意力：vLLM的PagedAttention按页分配KV，消除碎片化，显存利用率明显提升。
3. 前缀缓存：多轮会话或固定system prompt命中后直接复用前缀KV，重复计算大幅减少。

以vLLM为例，开前缀缓存只需一个参数：

vllm serve Qwen/Qwen2.5-7B-Instruct   --gpu-memory-utilization 0.9   --max-model-len 32768   --enable-prefix-caching

连续批处理：吞吐提升的核心手段

朴素部署方式是等一个批次全部生成完再接收下一批，早结束的请求空等，GPU大量空闲。连续批处理（continuous batching）在token级别动态调度：任一个序列生成完立刻让出位置，新请求随时插入。vLLM、SGLang、TensorRT-LLM都实现了该机制，吞吐通常比transformers直接部署高数倍。

投机解码与Prefill/Decode分离

投机解码（draft decoding）用一个小模型先草稿多个token，大模型一次验证，把多次串行解码变成一次并行，延迟下降明显。Prefill和Decode分离（如chunked prefill）则避免一条长Prompt阻塞整批小请求，适合多用户混合负载。

推理框架选型与部署建议

常用方案对比：

vLLM：吞吐高、生态全、OpenAI兼容接口，适合多数生产场景。
SGLang：radix cache与多模态路由支持好，Agent类应用友好。
TensorRT-LLM：性能压榨最彻底，但编译和调试成本高。

实际部署建议：先用INT4量化把权重显存降下来，再开连续批处理提升吞吐，最后加前缀缓存消化多轮对话重复计算。三步走完，单卡吞吐普遍提升2-4倍。

量化与优化后的验证清单

1. 评测集对比量化前后输出质量，尤其是代码、数学类任务。
2. 压测：固定并发、测延迟P50/P99和每秒请求数。
3. 显存监控：观察KV Cache峰值，超限触发降级。
4. 流式场景：确认客户端能处理分块输出。

大模型部署优化的方向是明确的：显存省出来，带宽用满，调度不停。把这三件事做到位，比盲目上更大显存更划算。