大模型推理优化全攻略：KV Cache、量化、投机解码与连续批处理
2026/7/3大约 18 分钟
大模型推理优化全攻略：KV Cache、量化、投机解码与连续批处理
推理是模型上线后最贵的环节。一个未经优化的 70B 模型推理服务，成本可能比优化后高出 5-10 倍。本文系统梳理大模型推理优化的四大核心技术，带你从原理到实践全面掌握。
一、推理优化的全局视角
大模型推理的核心瓶颈是 内存带宽，而非计算能力。理解这一点是所有优化的起点。
推理瓶颈分析：
┌─────────────────────────────────────────────────────────────┐
│ 推理过程两阶段 │
│ │
│ 阶段1: Prefill（预填充） │
│ ┌──────────────────────────────────────────┐ │
│ │ 输入所有 prompt tokens → 并行计算 │ │
│ │ 特点: 计算密集型 (compute-bound) │ │
│ │ 速度: 较快（可并行） │ │
│ └──────────────────────────────────────────┘ │
│ ↓ │
│ 阶段2: Decode（自回归解码） │
│ ┌──────────────────────────────────────────┐ │
│ │ 逐个 token 生成 → 串行计算 │ │
│ │ 特点: 内存带宽密集型 (memory-bound) │ │
│ │ 速度: 较慢（不可并行） │ │
│ │ 瓶颈: 每步都要读取全部 KV Cache │ │
│ └──────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘推理优化的四大方向：
| 优化方向 | 核心思想 | 代表技术 | 加速比 |
|---|---|---|---|
| KV Cache 优化 | 减少重复计算，优化缓存管理 | PagedAttention | 2-4x |
| 模型量化 | 降低参数精度，减少内存占用 | GPTQ、AWQ | 2-3x |
| 投机解码 | 用小模型预测，大模型验证 | Speculative Decoding | 1.5-3x |
| 连续批处理 | 动态调度请求，提高 GPU 利用率 | Continuous Batching | 5-10x |
二、KV Cache 原理与优化
2.1 为什么需要 KV Cache？
Transformer 的自注意力机制中，每个新 token 的生成都需要与之前所有 token 计算注意力。如果不缓存，第 N 步需要重新计算前 N-1 个 token 的 Key 和 Value，复杂度为 O(N²)。
没有 KV Cache:
Step 1: 计算 Q1, K1, V1 → Attention(Q1, K1, V1)
Step 2: 计算 Q2, K1,K2, V1,V2 → Attention(Q2, K1:K2, V1:V2)
Step 3: 计算 Q3, K1,K2,K3, V1,V2,V3 → Attention(Q3, K1:K3, V1:V3)
...每步都要重新计算之前所有 token 的 K 和 V
有 KV Cache:
Step 1: 计算 Q1, K1, V1 → 存入 Cache → Attention(Q1, K1, V1)
Step 2: 计算 Q2, K2, V2 → 存入 Cache → Attention(Q2, K1:K2, V1:V2)
↑ 来自cache ↑ 来自cache
Step 3: 计算 Q3, K3, V3 → 存入 Cache → Attention(Q3, K1:K3, V1:V3)
↑ 全部来自cache
每步只需计算当前 token 的 Q, K, V，其余从缓存读取2.2 KV Cache 内存计算
精确计算 KV Cache 的内存占用：
def calc_kv_cache_memory(
num_layers: int, # 层数
num_heads: int, # KV 头数（GQA 可能少于 Q 头数）
head_dim: int, # 每个头的维度
seq_length: int, # 序列长度
batch_size: int, # 批次大小
dtype_bytes: int = 2 # 每个参数的字节数（FP16=2, FP32=4, INT8=1）
) -> dict:
"""
计算 KV Cache 的内存占用
KV Cache 大小 = 2 (K和V) × num_layers × num_heads × head_dim × seq_length × batch_size × dtype_bytes
"""
# 单个样本的 KV Cache 大小（字节）
kv_per_sample = 2 * num_layers * num_heads * head_dim * seq_length * dtype_bytes
# 批次总大小
total_bytes = kv_per_sample * batch_size
return {
"per_sample_mb": kv_per_sample / (1024**2),
"total_mb": total_bytes / (1024**2),
"total_gb": total_bytes / (1024**3),
"formula": f"2 × {num_layers} × {num_heads} × {head_dim} × {seq_length} × {batch_size} × {dtype_bytes}"
}
# 示例：Llama-2-70B 的 KV Cache
# 架构: 80 layers, 64 KV heads (GQA, 8 groups), head_dim=128
result = calc_kv_cache_memory(
num_layers=80,
num_heads=64, # GQA 下 KV 头数
head_dim=128,
seq_length=4096, # 上下文长度
batch_size=1,
dtype_bytes=2 # FP16
)
print(f"Llama-2-70B 单样本 KV Cache: {result['per_sample_mb']:.1f} MB")
# 输出: 5120.0 MB ≈ 5 GB（仅一个样本！）
# 批次为 32 时
result_batch = calc_kv_cache_memory(
num_layers=80, num_heads=64, head_dim=128,
seq_length=4096, batch_size=32, dtype_bytes=2
)
print(f"Llama-2-70B batch=32 KV Cache: {result_batch['total_gb']:.1f} GB")
# 输出: 160 GB（远超单卡显存！）这个例子揭示了推理的核心矛盾：模型参数 + KV Cache 一起，很容易超出显存容量。
2.3 PagedAttention：vLLM 的核心创新
传统做法中，每个请求的 KV Cache 预先分配连续内存，导致大量碎片和浪费。vLLM 的 PagedAttention 借鉴操作系统的虚拟内存机制：
传统 KV Cache 分配:
┌──────────────────────────────────────────────┐
│ Request 1: [████████████████░░░░░░░░░░░░] │ 预分配 max_seq_len
│ Request 2: [██████░░░░░░░░░░░░░░░░░░░░░░] │ 预分配 max_seq_len
│ Request 3: [██████████████████████░░░░░░░] │ 预分配 max_seq_len
│ │
│ ░ = 浪费的空间（内部碎片 + 外部碎片） │
└──────────────────────────────────────────────┘
浪费率: 60%-80%
PagedAttention:
┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐
│ Blk │ Blk │ Blk │ Blk │ Blk │ Blk │ Blk │ Blk │
│ R1 │ R1 │ R1 │ R2 │ R2 │ R3 │ R3 │ R3 │
│ p0 │ p1 │ p2 │ p0 │ p1 │ p0 │ p1 │ p2 │
└─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘
│ │ │ │ │ │ │ │
R1: Block0→Block1→Block2 R2: Block0→Block1 R3: Block0→Block1→Block2
每个 Block 固定大小（如 16 tokens），按需分配
浪费率: < 4%（仅最后一个 Block 的尾部）# vLLM PagedAttention 使用示例
from vllm import LLM, SamplingParams
# vLLM 自动使用 PagedAttention
llm = LLM(
model="meta-llama/Llama-2-7b-chat-hf",
# PagedAttention 相关参数
block_size=16, # 每个内存块的 token 数
gpu_memory_utilization=0.9, # GPU 显存使用率
max_num_seqs=256, # 最大并发序列数
swap_space=4, # CPU 交换空间 (GB)
enable_prefix_caching=True, # 前缀缓存（共享系统提示）
)
# 批量推理（vLLM 会自动使用连续批处理）
prompts = [
"Hello, my name is",
"The capital of France is",
"Python is a programming language",
] * 100 # 300 个请求
sampling_params = SamplingParams(
temperature=0.8,
max_tokens=100,
)
outputs = llm.generate(prompts, sampling_params)2.4 前缀缓存（Prefix Caching）
多个请求共享相同前缀（如系统提示）时，可以复用 KV Cache：
# 场景：客服系统中，所有请求都有相同的系统提示
system_prompt = "你是一个专业的客服助手，负责回答用户关于产品的问题。请保持礼貌和专业。"
# 这个 prompt 有约 200 tokens，如果每次都重新计算 KV Cache 是巨大浪费
# vLLM 的 enable_prefix_caching=True 会自动处理
# 但如果你用自己的推理框架，需要手动实现：
import hashlib
from collections import OrderedDict
class PrefixKVCache:
"""前缀 KV Cache 管理器"""
def __init__(self, max_entries: int = 100):
self.cache: OrderedDict[str, dict] = OrderedDict()
self.max_entries = max_entries
def get_prefix_hash(self, token_ids: list[int]) -> str:
"""计算 token 序列的哈希"""
return hashlib.md5(bytes(token_ids)).hexdigest()
def get(self, token_ids: list[int]) -> dict | None:
"""查找前缀缓存"""
prefix_hash = self.get_prefix_hash(token_ids)
if prefix_hash in self.cache:
self.cache.move_to_end(prefix_hash)
return self.cache[prefix_hash]
return None
def put(self, token_ids: list[int], kv_cache: dict):
"""存入前缀缓存"""
prefix_hash = self.get_prefix_hash(token_ids)
self.cache[prefix_hash] = kv_cache
self.cache.move_to_end(prefix_hash)
# LRU 淘汰
if len(self.cache) > self.max_entries:
self.cache.popitem(last=False)三、模型量化：GPTQ、AWQ 与 SmoothQuant
3.1 量化基础
量化的核心思想：将 FP16（16位浮点）参数压缩到 INT8 甚至 INT4，以 2-4 倍减少内存占用和带宽需求。
量化精度对比:
FP16: ┌──────────────┐ 2 bytes/参数
│ 1 | 01010 | 10│ 符号|指数|尾数
└──────────────┘
INT8: ┌────────┐ 1 byte/参数
│01010101│ 256 个离散值
└────────┘
INT4: ┌──┐ 0.5 byte/参数
│01│ 16 个离散值
└──┘
精度损失: FP16 < INT8 < INT4
速度提升: FP16 < INT8 < INT4
内存节省: 1x 2x 4x3.2 三种主流量化方案
┌──────────────┬──────────────┬──────────────┬──────────────┐
│ │ GPTQ │ AWQ │ SmoothQuant │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ 量化方式 │ 训练后量化 │ 训练后量化 │ 训练后量化 │
│ 核心思想 │ 逐层最小化 │ 保护"重要" │ 平滑激活值 │
│ │ 输出误差 │ 权重通道 │ 的异常值 │
│ 量化精度 │ INT4/INT8 │ INT4 │ INT8 │
│ 推理速度 │ 快 │ 最快 │ 快 │
│ 精度损失 │ 中等 │ 最小 │ 小 │
│ 适用场景 │ 通用 │ 推理优先 │ 激活值异常 │
│ │ │ │ 的模型 │
│ 硬件支持 │ GPU/CPU │ GPU 优化 │ GPU/CPU │
└──────────────┴──────────────┴──────────────┴──────────────┘3.3 GPTQ 原理与实战
GPTQ（Generalized Post-Training Quantization）的核心思想是：逐层将权重量化为 INT4，同时最小化量化前后该层输出的差异。
# GPTQ 量化流程
from transformers import AutoModelForCausalLM, AutoTokenizer
from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig
# 1. 准备校准数据
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-chat-hf")
calibration_texts = [
"The quick brown fox jumps over the lazy dog.",
"Machine learning is a subset of artificial intelligence.",
"Python is one of the most popular programming languages.",
# ... 需要约 128-256 条多样化文本
] * 10
calibration_data = [
tokenizer(text, return_tensors="pt") for text in calibration_texts
]
# 2. 配置量化参数
quantize_config = BaseQuantizeConfig(
bits=4, # 量化位数: 4 或 8
group_size=128, # 分组大小（越小精度越高，速度越慢）
desc_act=False, # 是否按激活值降序排列权重
)
# 3. 执行量化（需要 GPU，约 10-30 分钟）
model = AutoGPTQForCausalLM.from_pretrained(
"meta-llama/Llama-2-7b-chat-hf",
quantize_config,
)
model.quantize(calibration_data)
# 4. 保存量化模型
model.save_quantized("./llama-2-7b-gptq-4bit")
# 5. 加载量化模型推理
from vllm import LLM
# vLLM 原生支持 GPTQ 量化模型
llm = LLM(
model="./llama-2-7b-gptq-4bit",
quantization="gptq",
dtype="float16",
)3.4 AWQ 原理与实战
AWQ（Activation-aware Weight Quantization）的核心发现：不是所有权重都同等重要，那些与较大激活值对应的权重通道更重要，保护这些通道可以显著减少量化损失。
# AWQ 量化
from transformers import AutoModelForCausalLM, AutoTokenizer
from awq import AutoAWQForCausalLM
# 1. 加载模型
model_path = "meta-llama/Llama-2-7b-chat-hf"
quant_path = "./llama-2-7b-awq-4bit"
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)
# 2. 准备校准数据
calibration_data = [
"Artificial intelligence is transforming industries.",
"The weather today is sunny with a gentle breeze.",
# ...
]
# 3. 配置并执行量化
quant_config = {
"zero_point": True, # 使用零点（对称/非对称量化）
"q_group_size": 128, # 分组大小
"w_bit": 4, # 权重位数
"version": "GEMM", # GEMM 适合 GPU，GEMV 适合 CPU
}
model.quantize(
tokenizer,
quant_config=quant_config,
calib_data=calibration_data,
)
# 4. 保存
model.save_quantized(quant_path)
# 5. 用 vLLM 加载 AWQ 模型
from vllm import LLM
llm = LLM(
model=quant_path,
quantization="awq",
dtype="float16",
)3.5 量化效果实测对比
import time
import torch
from transformers import AutoModelForCausalLM
def benchmark_model(model_path, quantization=None, num_runs=50):
"""模型推理基准测试"""
from vllm import LLM, SamplingParams
kwargs = {"model": model_path}
if quantization:
kwargs["quantization"] = quantization
llm = LLM(**kwargs)
prompts = ["Hello, tell me a story about"] * num_runs
sampling_params = SamplingParams(max_tokens=128, temperature=0)
start = time.time()
outputs = llm.generate(prompts, sampling_params)
elapsed = time.time() - start
total_tokens = sum(len(o.outputs[0].token_ids) for o in outputs)
return {
"total_time_s": elapsed,
"tokens_per_second": total_tokens / elapsed,
"avg_latency_ms": (elapsed / num_runs) * 1000,
}
# 对比测试（示意结果，实际取决于硬件）
print("FP16:", benchmark_model("meta-llama/Llama-2-7b-chat-hf"))
# {'tokens_per_second': 2500, 'avg_latency_ms': 51}
print("GPTQ INT4:", benchmark_model("./llama-2-7b-gptq-4bit", "gptq"))
# {'tokens_per_second': 3800, 'avg_latency_ms': 33}
print("AWQ INT4:", benchmark_model("./llama-2-7b-awq-4bit", "awq"))
# {'tokens_per_second': 4200, 'avg_latency_ms': 30}3.6 量化选择决策树
┌──────────────┐
│ 需要量化吗？ │
└──────┬───────┘
│
┌────────────┴────────────┐
│ 显存够用且延迟可接受？ │
└────────────┬────────────┘
是 │ 否
┌────────────┘ └────────────┐
│ 不需要量化 │
│ │
│ ┌───────────────▼──────────────┐
│ │ 模型激活值有严重异常值吗？ │
│ └───────────────┬──────────────┘
│ 是 │ 否
│ ┌──────────────┘ └──────────────┐
│ │ │
│ ▼ ▼
│ 使用 SmoothQuant 推理速度优先？
│ (INT8, 平滑异常值) ┌──────┴──────┐
│ 是 │ 否 │
│ ▼ ▼
│ AWQ GPTQ
│ (INT4, (INT4,
│ 最快) 通用)
└──────────────────────────────────────────────────────四、投机解码（Speculative Decoding）
4.1 核心思想
投机解码用一个小模型（Draft Model）快速"猜测"多个 token，再用大模型（Target Model）并行验证。如果猜对了，一步生成多个 token；猜错了，丢弃错误部分，回退到正常解码。
标准自回归解码:
Token: [1] → [2] → [3] → [4] → [5] → [6] → [7]
时间: t1 t2 t3 t4 t5 t6 t7
每步1个token，串行执行
投机解码:
Draft Model 快速生成: [2'] [3'] [4'] [5'] (1步并行生成4个候选)
│
Target Model 验证: ┌─────────────────────┐
│ [2']✓ [3']✓ [4']✓ [5']✗│ (1步并行验证4个)
└─────────────────────┘
│
结果: [2] [3] [4] ← 保留正确的
[5] → 大模型重新生成
接受 3 个 token，拒绝第 4 个
加速比: 理论上从 7 步减少到 3 步（Draft 1步 + 验证 1步 + 重新生成 1步）4.2 数学原理
投机解码的核心是 拒绝采样（Rejection Sampling），保证输出分布与原始大模型完全一致：
import torch
import torch.nn.functional as F
def speculative_decode(
target_model, # 大模型（目标）
draft_model, # 小模型（草稿）
input_ids, # 当前输入
num_draft_tokens=4, # 草稿生成数量
max_new_tokens=128
):
"""投机解码实现"""
generated = input_ids.clone()
while generated.shape[1] < input_ids.shape[1] + max_new_tokens:
# 1. Draft Model 快速生成 num_draft_tokens 个候选 token
draft_tokens = []
draft_probs = []
draft_input = generated.clone()
for _ in range(num_draft_tokens):
with torch.no_grad():
draft_logits = draft_model(draft_input).logits[:, -1, :]
draft_prob = F.softmax(draft_logits, dim=-1)
draft_token = torch.multinomial(draft_prob, num_samples=1)
draft_tokens.append(draft_token)
draft_probs.append(draft_prob)
draft_input = torch.cat([draft_input, draft_token], dim=1)
draft_tokens = torch.cat(draft_tokens, dim=1) # [1, num_draft_tokens]
# 2. Target Model 并行验证
with torch.no_grad():
# 一次前向传播验证所有候选 token
target_input = torch.cat([generated, draft_tokens], dim=1)
target_logits = target_model(target_input).logits[:, -(num_draft_tokens + 1):-1, :]
target_probs = F.softmax(target_logits, dim=-1)
# 3. 接受/拒绝判断
accepted_count = 0
for i in range(num_draft_tokens):
draft_token = draft_tokens[0, i].item()
target_prob = target_probs[0, i, draft_token].item()
draft_prob = draft_probs[i][0, draft_token].item()
# 拒绝采样：以 min(1, p_target/p_draft) 的概率接受
accept_prob = min(1.0, target_prob / max(draft_prob, 1e-10))
if torch.rand(1).item() < accept_prob:
# 接受这个 token
generated = torch.cat([generated, draft_tokens[:, i:i+1]], dim=1)
accepted_count += 1
else:
# 拒绝，从调整后的分布中采样一个新 token
adjusted_prob = target_probs[0, i] - draft_probs[i][0]
adjusted_prob = F.relu(adjusted_prob)
adjusted_prob = adjusted_prob / adjusted_prob.sum()
new_token = torch.multinomial(adjusted_prob, num_samples=1)
generated = torch.cat([generated, new_token], dim=1)
break
# 如果所有候选都被接受，从最后一个 target prob 采样
if accepted_count == num_draft_tokens:
last_prob = target_probs[0, -1]
bonus_token = torch.multinomial(last_prob, num_samples=1)
generated = torch.cat([generated, bonus_token], dim=1)
return generated4.3 实际效果与适用场景
# vLLM 中的投机解码（需要 vLLM >= 0.4.0）
from vllm import LLM, SamplingParams
# 使用投机解码
llm = LLM(
model="meta-llama/Meta-Llama-3-70B-Instruct", # Target 大模型
speculative_model="meta-llama/Meta-Llama-3-8B-Instruct", # Draft 小模型
num_speculative_tokens=5, # 每次投机5个token
use_v2_block_manager=True,
)
sampling_params = SamplingParams(temperature=0.7, max_tokens=200)
output = llm.generate(["Explain quantum computing in simple terms."], sampling_params)投机解码的加速效果取决于 接受率（Acceptance Rate）：
接受率 vs 加速比:
接受率 | 加速比 | 说明
--------|---------|---------------------------
90% | 3.5x | 草稿模型与目标模型非常接近
70% | 2.0x | 常见场景
50% | 1.3x | 草稿模型偏弱，加速有限
30% | 0.8x | 比不用还慢（验证开销 > 节省）
提高接受率的关键:
1. Draft 模型与 Target 模型同源（如 Llama-3-8B + Llama-3-70B）
2. 适当减少 num_speculative_tokens（3-5 通常最佳）
3. 温度越低，接受率越高（贪心解码时最高）五、连续批处理（Continuous Batching）
5.1 静态批处理的问题
静态批处理（Static Batching）:
时间 →
Req1: [████████████████████] (20 tokens) 完成
Req2: [████████████████████████████████████] (40 tokens) 完成
Req3: [████████████] (12 tokens) 完成
Req4: [██████████████████████████████████████████████] (55 tokens) 完成
问题：Req3 在 t=12 时就完成了，但要等最长的 Req4(55 tokens) 完成后才能处理下一批
GPU 在 Req1/Req2/Req3 完成后处于低利用率状态
连续批处理（Continuous Batching）:
时间 →
Req1: [████████████████████] ✅ 新Req5: [████████████]
Req2: [████████████████████████████████████] ✅ 新Req6: [████████]
Req3: [████████████] ✅ 新Req5续: [████] 新Req7: [████████████]
Req4: [██████████████████████████████████████████████] ✅
请求完成后立即释放槽位，新请求立即插入
GPU 始终保持高利用率5.2 连续批处理的实现要点
# 连续批处理的核心逻辑（伪代码展示原理）
class ContinuousBatcher:
"""连续批处理器"""
def __init__(self, model, max_batch_size: int = 32, max_seq_len: int = 4096):
self.model = model
self.max_batch_size = max_batch_size
self.max_seq_len = max_seq_len
self.active_requests: list[Request] = []
self.waiting_queue: list[Request] = []
def add_request(self, request: Request):
"""添加新请求"""
self.waiting_queue.append(request)
def step(self):
"""执行一步批处理"""
# 1. 从等待队列中补充请求到活跃批次
while (
len(self.active_requests) < self.max_batch_size
and self.waiting_queue
):
req = self.waiting_queue.pop(0)
self.active_requests.append(req)
if not self.active_requests:
return
# 2. 准备批次输入（padding 到相同长度，或使用 attention mask）
batch_tokens = [req.current_tokens for req in self.active_requests]
# 3. 模型前向传播（所有活跃请求一起）
with torch.no_grad():
logits = self.model.forward_batch(batch_tokens)
# 4. 为每个请求采样下一个 token
completed = []
for i, req in enumerate(self.active_requests):
next_token = self.sample(logits[i], req.temperature)
req.append_token(next_token)
# 检查是否完成（EOS 或达到 max_tokens）
if next_token == self.tokenizer.eos_token_id or req.is_done():
completed.append(req)
# 5. 移除已完成的请求（关键：不等整个批次完成）
for req in completed:
self.active_requests.remove(req)
req.set_result()
# 6. 立即可以接受新请求（下一轮 step 时补充）5.3 vLLM 连续批处理实战
# vLLM 自动使用连续批处理，支持流式输出
from vllm import LLM, SamplingParams
llm = LLM(
model="meta-llama/Meta-Llama-3-8B-Instruct",
max_num_seqs=64, # 最大并发序列数
max_num_batched_tokens=8192, # 单次批处理最大 token 数
gpu_memory_utilization=0.9,
)
# 模拟真实场景：不同长度的请求
prompts = [
("What is 1+1?", 10), # 短回复
("Write a poem.", 200), # 长回复
("Hello", 5), # 极短回复
("Explain quantum physics.", 500), # 超长回复
] * 50 # 200 个请求
# 为每个请求设置不同的 max_tokens
sampling_params_list = [
SamplingParams(max_tokens=max_tok, temperature=0.7)
for _, max_tok in prompts
]
prompts_text = [p for p, _ in prompts]
# vLLM 自动处理连续批处理
outputs = llm.generate(prompts_text, sampling_params_list)
# 按完成时间排序（短请求先完成）
for output in sorted(outputs, key=lambda x: x.metrics.finish_time):
print(f"完成: {output.metrics.finish_time:.2f}s, "
f"tokens: {len(output.outputs[0].token_ids)}")六、推理框架对比
6.1 vLLM vs TGI vs TensorRT-LLM
┌─────────────┬──────────────┬──────────────┬──────────────┐
│ 特性 │ vLLM │ TGI │ TensorRT-LLM │
├─────────────┼──────────────┼──────────────┼──────────────┤
│ 开发者 │ UC Berkeley │ HuggingFace │ NVIDIA │
│ 易用性 │ ★★★★★ │ ★★★★☆ │ ★★☆☆☆ │
│ 性能 │ ★★★★☆ │ ★★★☆☆ │ ★★★★★ │
│ 模型支持 │ 广泛 │ 广泛 │ NVIDIA 优化 │
│ 量化支持 │ GPTQ/AWQ │ GPTQ │ INT8/INT4 FP8│
│ 分布式推理 │ ✅ Tensor并行 │ ✅ │ ✅ │
│ 连续批处理 │ ✅ │ ✅ │ ✅ │
│ 投机解码 │ ✅ │ ❌ │ ✅ │
│ 前缀缓存 │ ✅ │ ✅ │ ✅ │
│ 部署复杂度 │ 低(pip安装) │ 中(Docker) │ 高(编译) │
│ 社区活跃度 │ 高 │ 高 │ 中 │
│ 适用场景 │ 通用首选 │ HF 生态用户 │ 极致性能 │
└─────────────┴──────────────┴──────────────┴──────────────┘6.2 基准测试
# 统一基准测试脚本
import subprocess
import json
import time
def benchmark_vllm(model_path, num_prompts=200, max_tokens=128):
"""vLLM 基准测试"""
code = f"""
import time
from vllm import LLM, SamplingParams
llm = LLM(model="{model_path}", gpu_memory_utilization=0.9)
prompts = ["Hello, tell me a story."] * {num_prompts}
sp = SamplingParams(max_tokens={max_tokens}, temperature=0)
start = time.time()
outputs = llm.generate(prompts, sp)
elapsed = time.time() - start
total_tokens = sum(len(o.outputs[0].token_ids) for o in outputs)
print(json.dumps({{
"throughput": total_tokens / elapsed,
"avg_latency": elapsed / {num_prompts},
"total_time": elapsed
}}))
"""
result = subprocess.run(["python", "-c", code], capture_output=True, text=True)
return json.loads(result.stdout.strip().split('\n')[-1])
def benchmark_tgi(model_path, num_prompts=200, max_tokens=128):
"""TGI 基准测试（需要先启动 TGI 服务）"""
import requests
url = "http://localhost:8080/generate"
prompts = ["Hello, tell me a story."] * num_prompts
start = time.time()
for prompt in prompts:
requests.post(url, json={
"inputs": prompt,
"parameters": {"max_new_tokens": max_tokens, "temperature": 0}
})
elapsed = time.time() - start
return {
"throughput": (num_prompts * max_tokens) / elapsed,
"avg_latency": elapsed / num_prompts,
"total_time": elapsed
}6.3 选择建议
# 决策矩阵
def choose_inference_framework(
model_size: str, # "7B", "13B", "70B"
hardware: str, # "A10", "A100", "H100", "consumer"
latency_requirement: str, # "low", "medium", "high"
team_expertise: str, # "junior", "senior", "expert"
budget: str # "low", "medium", "high"
) -> str:
"""选择推理框架"""
# 简单决策逻辑
if hardware == "H100" and budget == "high" and team_expertise == "expert":
return "TensorRT-LLM（极致性能，H100 + FP8 是杀手锏）"
if model_size == "70B" and hardware in ["A100", "H100"]:
return "vLLM（多卡张量并行，社区支持好）"
if hardware == "consumer" or hardware == "A10":
return "vLLM（量化支持好，显存友好）"
if team_expertise == "junior":
return "vLLM（pip install 即用，文档完善）"
return "vLLM（通用首选，大部分场景最优解）"七、完整优化效果叠加
优化效果叠加（以 Llama-2-70B 为例）:
┌──────────────────┐
│ 原始 FP16 │
│ 吞吐: 50 tok/s │
│ 显存: 140 GB │
└────────┬─────────┘
│
┌────────▼─────────┐
│ + KV Cache │ ← 基础（不加无法推理）
│ 吞吐: 200 tok/s │
│ 显存: 145 GB │
└────────┬─────────┘
│
┌────────▼─────────┐
│ + AWQ INT4 量化 │ ← 4x 显存节省
│ 吞吐: 500 tok/s │
│ 显存: 40 GB │
└────────┬─────────┘
│
┌────────▼─────────┐
│ + 连续批处理 │ ← 5-10x 吞吐
│ 吞吐: 3000 tok/s │
│ 显存: 45 GB │
└────────┬─────────┘
│
┌────────▼─────────┐
│ + 投机解码 │ ← 1.5-2x 延迟降低
│ 吞吐: 5000 tok/s │
│ 显存: 50 GB │
└────────┬─────────┘
│
┌────────▼─────────┐
│ + 前缀缓存 │ ← 共享前缀场景额外 2x
│ 吞吐: 8000 tok/s │
│ 显存: 50 GB │
└──────────────────┘
最终: 从 50 tok/s → 8000 tok/s (160x)
从 140 GB → 50 GB (2.8x 节省)八、面试要点
Q1: KV Cache 的内存占用如何计算？
答：KV Cache 大小 = 2 × num_layers × num_kv_heads × head_dim × seq_length × batch_size × dtype_bytes。例如 Llama-2-70B（80层，64个KV头，head_dim=128），在 FP16、序列长度4096、batch=1 时，KV Cache 约 5GB。GQA（Grouped Query Attention）通过减少 KV 头数来降低 KV Cache 大小。
Q2: GPTQ 和 AWQ 的区别是什么？
答：GPTQ 通过逐层最小化量化前后的输出误差来量化权重，使用校准数据集计算量化参数。AWQ 发现并非所有权重都重要——与较大激活值对应的权重通道更重要，通过保护这些"显著通道"来减少量化损失。实践中 AWQ 通常比 GPTQ 推理速度更快（因为 AWQ 对 GPU 更友好），精度损失更小，但 GPTQ 更通用，支持更多模型和硬件。
Q3: 投机解码为什么能加速？
答：标准自回归解码每次前向传播只生成1个token，但计算量与序列长度成正比，GPU 利用率很低。投机解码让小模型快速生成多个候选token，大模型一次前向传播同时验证所有候选——由于验证多个token的计算量与生成一个token几乎相同（都是一次前向传播），所以当候选被接受时等于"免费"生成了多个token。
Q4: 连续批处理相比静态批处理有什么优势？
答：静态批处理要等整个批次中所有请求都完成才能处理下一批，短请求要等长请求，GPU 利用率低。连续批处理在任意请求完成时立即释放槽位并插入新请求，GPU 始终保持高利用率。在混合长度请求场景下，连续批处理可将吞吐提升 5-10 倍。
Q5: vLLM 和 TensorRT-LLM 怎么选？
答：vLLM 是通用首选——易用（pip install）、模型支持广、社区活跃、支持 GPTQ/AWQ 量化。TensorRT-LLM 在 NVIDIA 硬件上有极致性能，特别是 FP8 量化在 H100 上优势明显，但部署复杂（需要编译引擎）、模型支持有限、灵活性低。如果团队有 NVIDIA 专属硬件且追求极致性能，选 TensorRT-LLM；否则选 vLLM。
九、避坑指南
坑1: 量化后模型质量断崖下降
# ❌ 直接用最激进的量化
model = load_model("llama-70b", quantization="int4", group_size=32)
# 在代码生成、数学推理等任务上精度严重下降
# ✅ 分步量化，评估后再上线
# 1. 先用 INT8 量化，评估精度损失
# 2. 如果 INT8 可接受，尝试 GPTQ INT4 with group_size=128
# 3. 量化后必须在业务评测集上验证，不只是跑 MMLU
# 4. 代码/数学任务对量化敏感，对话任务相对鲁棒坑2: 投机解码用了不兼容的模型对
# ❌ 不同系列的模型做 Draft-Target 对
target = "Qwen2-72B"
draft = "Llama-3-8B" # 不同架构、不同tokenizer
# 接受率极低，甚至可能输出乱码
# ✅ 同系列、同tokenizer的模型对
target = "Qwen/Qwen2.5-72B-Instruct"
draft = "Qwen/Qwen2.5-1.5B-Instruct" # 同系列，接受率高坑3: 连续批处理中变长序列导致 OOM
# 连续批处理时，如果一个请求生成了超长序列，
# 可能导致 KV Cache 超出显存
# ✅ 设置严格的安全边界
llm = LLM(
model="...",
max_num_seqs=64,
max_num_batched_tokens=8192, # 单次最大token数
max_seq_len=4096, # 单序列最大长度
gpu_memory_utilization=0.9, # 保留10%安全边界
enforce_eager=True, # 内存紧张时关闭CUDA Graph
)坑4: 忽略 Prefill 阶段的优化
# 大部分人只关注 Decode 阶段的优化（KV Cache、量化等）
# 但 Prefill 阶段（处理输入prompt）在长输入时也很慢
# ✅ Prefill 优化策略:
# 1. 使用 Chunked Prefill（将长prompt分块处理）
# 2. 启用 Prefix Caching（共享系统提示的KV Cache）
# 3. 在 TGI 中使用 --max-batch-prefill-tokens 控制prefill批次
llm = LLM(
model="...",
enable_prefix_caching=True, # 前缀缓存
max_num_batched_tokens=8192, # 包含prefill和decode的总token限制
)坑5: 量化模型在不同框架上行为不一致
# 同一个 GPTQ 量化模型在 transformers 和 vLLM 上的结果可能不同
# 因为不同框架的量化实现细节有差异
# ✅ 统一推理框架，并在切换框架时重新评估
# 不要假设量化模型在不同框架上行为完全一致
# 特别是 INT4 量化，数值精度敏感十、总结
推理优化是大模型生产部署的关键环节。核心要点：
- KV Cache 是基础：理解其内存计算，使用 PagedAttention 管理内存
- 量化是性价比最高的优化：AWQ INT4 在大多数场景下是最优选择
- 投机解码适合低延迟场景：同系列大小模型配对，接受率 > 50% 才有意义
- 连续批处理是吞吐核心：几乎所有生产场景都应启用
- 框架选择以 vLLM 为首选：除非有极致性能需求且具备 NVIDIA 专属硬件
优化是一条没有终点的路——新的方法（如 FP8 量化、Medusa 投机解码、 disaggregated prefill/decode）不断涌现。掌握这些基础原理，才能快速评估和应用新技术。