LLM 推理加速全攻略：vLLM、TensorRT-LLM 与量化技术实战

导语：训练出一个好模型只完成了一半，如何让它在生产环境中跑得快、跑得稳、成本可控，是另一半工程挑战。大语言模型推理优化是一门横跨硬件架构、系统软件和模型压缩的综合工程学。本文系统梳理 2025-2026 年主流的推理加速技术：PagedAttention、连续批处理、量化（GPTQ/AWQ/GGUF）、推测解码，以及主流推理框架选型，帮助你将推理成本降低 5-10×。

一、LLM 推理的性能瓶颈

1.1 推理的两个阶段

LLM 推理分为两个截然不同的计算阶段：

Prefill（预填充）阶段：

一次性处理所有输入 token（Prompt）
计算密集型（Compute-Bound），受限于 GPU 计算能力
并行度高，可以高效利用 GPU

Decode（解码）阶段：

自回归逐 token 生成
内存带宽密集型（Memory-Bound），受限于显存带宽
每步只生成 1 个 token，GPU 利用率极低（通常 < 10%）

关键洞察：LLM 推理的主要瓶颈在 Decode 阶段，是内存带宽而非计算能力的限制。

1.2 显存使用分析

以 Llama-3 8B（FP16）为例：

复制代码

模型权重：16 GB（固定）
KV Cache：2 × 32 × 32 × 128 × seq_len × batch_size × 2 bytes
         ≈ 0.5 MB/token/请求

示例：1024 tokens × 16 并发请求 = 8 GB KV Cache

两大显存压力：

模型权重占用大量显存（固定）
KV Cache 随序列长度和批大小动态增长，管理不当极易 OOM

二、PagedAttention：KV Cache 管理的革命

2.1 传统 KV Cache 的问题

传统实现为每个请求预分配连续显存（最大序列长度）：

复制代码

请求1（实际256 tokens）: 预分配 2048 tokens 显存 → 浪费 87.5%
请求2（实际1800 tokens）: 预分配 2048 tokens 显存 → 利用率 87.5%
请求3（等待中）: 因显存不足无法加载

这导致：

内存碎片：连续内存分配难以复用
低并发：显存利用率通常 < 40%，直接限制了吞吐量

2.2 PagedAttention：类 OS 虚拟内存管理

vLLM 提出的 PagedAttention 将 KV Cache 组织为固定大小的"页"（Page），类似操作系统的虚拟内存：

复制代码

传统方式：
[请求1-KV: 2048 blocks] [请求2-KV: 2048 blocks] ...（大量空洞）

PagedAttention：
物理显存: [Page0][Page1][Page2][Page3][Page4][Page5][Page6]...
逻辑映射:
  请求1 → Page0, Page3, Page5（非连续物理页，逻辑连续）
  请求2 → Page1, Page4（动态按需分配）
  请求3 → Page2, Page6（随时可以加入）

好处：

显存利用率从 40% 提升到 95%+
支持 Prefix Sharing（共享相同前缀的 KV Cache，如 System Prompt）
实现 Copy-on-Write，支持 Beam Search 等解码策略

2.3 vLLM 快速上手

python 复制代码

from vllm import LLM, SamplingParams

# 初始化推理引擎
llm = LLM(
    model="meta-llama/Meta-Llama-3.1-8B-Instruct",
    tensor_parallel_size=2,          # 2 张 GPU 张量并行
    gpu_memory_utilization=0.90,     # 使用 90% GPU 显存
    max_model_len=8192,              # 最大支持序列长度
    quantization="awq",              # 使用 AWQ 量化（可选）
    dtype="bfloat16"
)

sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.9,
    max_tokens=512,
    stop=["<|eot_id|>"]
)

# 批量推理（vLLM 自动组织 continuous batching）
prompts = [
    "请解释什么是 Transformer 架构",
    "写一段 Python 排序代码",
    # ... 更多请求
]

outputs = llm.generate(prompts, sampling_params)
for output in outputs:
    print(output.outputs[0].text)

OpenAI 兼容 API 服务部署：

bash 复制代码

# 启动 vLLM 服务
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Meta-Llama-3.1-8B-Instruct \
    --tensor-parallel-size 2 \
    --gpu-memory-utilization 0.9 \
    --max-model-len 8192 \
    --port 8000

# 调用方式与 OpenAI API 完全兼容
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "meta-llama/Meta-Llama-3.1-8B-Instruct", "messages": [{"role": "user", "content": "Hello"}]}'

三、连续批处理（Continuous Batching）

3.1 传统批处理的问题

Static Batching（静态批处理）：

复制代码

Batch 开始 → 等待 Batch 内所有请求完成 → 处理下一批
问题：短请求完成后，GPU 空转等待长请求 → GPU 利用率低

3.2 Continuous Batching

vLLM 的连续批处理允许在 batch 运行中途动态插入新请求、移除已完成的请求：

复制代码

时间步 1: [请求A(第1个token), 请求B(第1个token), 请求C(第1个token)]
时间步 2: [请求A(第2个token), 请求B(第2个token), 请求C(第2个token)]
时间步 3: [请求A(第3个token), 请求B完成→移出, 请求C(第3个token), 新请求D加入]
时间步 4: [请求A(第4个token), 请求C(第4个token), 请求D(第2个token)]

效果：GPU 利用率从 30-40% 提升到 70-90%，吞吐量提升 3-5×。

四、量化技术：让模型变小变快

4.1 量化基础

量化格式	精度	相比 FP16 显存节省	速度变化	质量损失
FP16	基线	0%	基线	基线
INT8	8-bit	50%	+10-30%	<1%
GPTQ（INT4）	4-bit	75%	+30-50%	1-3%
AWQ（INT4）	4-bit	75%	+30-50%	<1%
GGUF Q4_K_M	~4.5-bit	~70%	视 CPU	1-2%

4.2 GPTQ：训练后量化

GPTQ（Generative Pre-Trained Transformer Quantization）是一种权重量化方法，基于海森矩阵近似的 2/3/4-bit 量化：

bash 复制代码

# 使用 AutoGPTQ 量化
pip install auto-gptq optimum

python -c "
from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig

quantize_config = BaseQuantizeConfig(
    bits=4,                  # 量化位数
    group_size=128,          # 量化粒度（更小的 group 质量更好但更慢）
    desc_act=False,          # 是否按激活值排序（影响精度/速度）
)

model = AutoGPTQForCausalLM.from_pretrained(
    'meta-llama/Meta-Llama-3.1-8B',
    quantize_config=quantize_config
)

# 需要标定数据（通常 128 条样本足够）
model.quantize(calibration_dataset)
model.save_quantized('./llama3-8b-gptq-4bit')
"

4.3 AWQ：激活感知量化

AWQ（Activation-aware Weight Quantization）：观察到少数权重通道对激活值影响极大（"显著权重"），量化时对这些通道进行保护：

python 复制代码

# 使用 llm-awq 量化
from awq import AutoAWQForCausalLM

model = AutoAWQForCausalLM.from_pretrained("meta-llama/Meta-Llama-3.1-8B")
quant_config = {
    "zero_point": True,
    "q_group_size": 128,
    "w_bit": 4,
    "version": "GEMM"          # GEMM 推理速度更快，GEMV 精度更高
}

model.quantize(tokenizer, quant_config=quant_config)
model.save_quantized("./llama3-8b-awq-4bit")

AWQ vs GPTQ：

质量：AWQ 通常略优于 GPTQ（尤其 4-bit）
速度：AWQ 在推理时速度更快
量化时间：AWQ 更快（不需要复杂的海森矩阵计算）

4.4 GGUF（llama.cpp 格式）

GGUF 是 llama.cpp 项目使用的量化格式，专为 CPU 推理和消费级硬件优化：

复制代码

Q4_K_M：4-bit 量化，中等质量，最常用
Q5_K_M：5-bit 量化，质量更好，显存略多
Q8_0：8-bit 量化，接近原始质量，显存较大

bash 复制代码

# 使用 Ollama 运行 GGUF 模型（最简单的方式）
ollama pull llama3.1:8b-instruct-q4_K_M
ollama run llama3.1:8b-instruct-q4_K_M "解释 Transformer 架构"

# 或直接使用 llama.cpp
./main -m models/llama3-8b-q4_k_m.gguf \
       -n 512 \
       -t 8 \              # CPU 线程数
       --gpu-layers 32 \   # 卸载到 GPU 的层数（混合 CPU/GPU）
       -p "解释 Transformer 架构"

五、推测解码（Speculative Decoding）

5.1 原理

推测解码利用一个小型"草稿模型"（Draft Model）快速生成多个候选 token，再用大型"验证模型"（Target Model）并行验证：

复制代码

标准解码：
  大模型生成 t5 → 大模型生成 t6 → 大模型生成 t7 → ... （串行，每步 ~50ms）

推测解码：
  小草稿模型：t5', t6', t7', t8' （快速生成 4 个候选，~5ms）
  大模型：并行验证 [t5', t6', t7', t8'] → 接受前3个，拒绝第4个（单步，~50ms）
  净效果：50ms 完成了 3-4 个 token 的生成

加速比取决于：草稿模型的"接受率"（acceptance rate），通常为 70-85%。

5.2 实现

python 复制代码

# vLLM 内置推测解码支持
llm = LLM(
    model="meta-llama/Meta-Llama-3.1-70B-Instruct",   # 目标大模型
    speculative_model="meta-llama/Meta-Llama-3.1-8B",  # 草稿小模型
    num_speculative_tokens=5,   # 每次推测 5 个候选 token
    speculative_draft_tensor_parallel_size=1,
    tensor_parallel_size=4
)

六、框架选型指南

框架	最适合场景	优势	局限
vLLM	高吞吐服务部署	PagedAttention，高并发，OpenAI API 兼容	首次加载慢
TGI（HF）	HuggingFace 生态集成	与 transformers 无缝兼容	功能略少于 vLLM
TensorRT-LLM	NVIDIA GPU 极致优化	NVIDIA 生态最快，FP8 原生支持	仅 NVIDIA，部署复杂
llama.cpp/Ollama	本地 CPU/小 GPU 部署	跨平台，消费级硬件可用	并发能力弱
MLC-LLM	移动端/边缘设备	跨平台编译，支持手机	功能相对简单
LMDeploy	国产模型（InternLM等）	对国产模型优化好	生态相对小

七、推理成本优化实战建议

选合适大小的模型：7B 满足需求就不用 70B
量化是必选项：生产环境 AWQ INT4 是最佳平衡点
Prefix Caching：开启 vLLM 的 prefix_caching 功能，相同 System Prompt 不重复计算
合理设置 max_model_len：不要设太大，KV Cache 显存按此分配
监控 token/s 和显存利用率：这是推理服务的核心指标

八、总结

优化方向	技术	典型收益
KV Cache 管理	PagedAttention	显存利用率 40% → 90%+
批处理效率	Continuous Batching	吞吐量 3-5×
模型压缩	AWQ/GPTQ 4-bit	显存 75%，质量损失 <1%
解码加速	推测解码	延迟降低 2-3×
计算优化	Flash Attention	GPU 利用率大幅提升

推理优化是一个系统工程，没有单一银弹。根据你的场景（高并发 vs 低延迟 vs 低成本）组合以上技术，才能实现最优的性价比。

参考文献

Kwon, W., et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP. https://arxiv.org/abs/2309.06180
Yu, G., et al. (2022). Orca: A Distributed Serving System for Transformer-Based Generative Models (Continuous Batching). OSDI. https://www.usenix.org/conference/osdi22/presentation/yu
Frantar, E., et al. (2022). GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. ICLR 2023. https://arxiv.org/abs/2210.17323
Lin, J., et al. (2023). AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. https://arxiv.org/abs/2306.00978
Leviathan, Y., et al. (2023). Fast Inference from Transformers via Speculative Decoding. ICML. https://arxiv.org/abs/2211.17192
vLLM 官方文档. https://docs.vllm.ai
TGI（Text Generation Inference）文档. https://huggingface.co/docs/text-generation-inference
llama.cpp GitHub. https://github.com/ggerganov/llama.cpp