一、引言
随着大语言模型参数规模从数十亿跃升至万亿级别，模型"能做什么"已经不是瓶颈，"怎么用得起"成了真正的挑战。部署一个70B参数的Llama 2模型，如果用FP16精度推理，仅加载模型权重就需要约140GB显存——这意味着即使单张H100（80GB）也无法运行，至少需要两张高端GPU。对于大多数企业和开发者来说，这样的硬件门槛几乎是不可承受的。
正因如此，大模型推理优化在过去两年成为AI工程化领域最火热的方向之一。从量化技术到KV Cache优化，从计算图剪裁到服务框架调度，整个行业正在经历一场"让大模型飞入寻常百姓家"的进程。本文将从工程实践的角度，系统梳理大模型推理优化的核心技术路线、各家方案的选型对比，以及实际部署中的经验教训。
二、为什么大模型推理这么"贵"
理解优化方案之前，先要理解算力都消耗在哪里。大模型推理可以分解为两个核心阶段：
2.1 Prefill（预填充）阶段
当用户输入提示词（prompt）时，模型需要并行计算所有输入token的注意力，计算出第一个输出token。这个阶段属于计算密集型——瓶颈在矩阵乘法算力（FLOPs）。批量越大的输入，计算效率越高。
2.2 Decode（解码）阶段
生成第一个token后，模型逐token生成后续内容。每个token生成需要：将当前token的隐藏状态与所有历史token的Key/Value做注意力计算。这个阶段属于访存密集型——瓶颈在于从显存中读取KV Cache的速度。
KV Cache就是这个"历史记录"。假设序列长度为4096、隐层维度为4096，对于70B模型（数十层），KV Cache占用约为：
- 每层：2 × 4096 × 4096 × 2字节（FP16）= 64MB
- 共80层：约5GB
这还只是一个请求的KV Cache。如果服务要同时处理数十个并发请求，KV Cache的显存占用会迅速成为瓶颈。这就是为什么大模型推理既"吃"算力又"吃"显存。
三、量化技术：用精度换效率
量化是目前最成熟、应用最广泛的推理优化手段。它的核心思想很简单：用更少的比特位来表示模型权重和激活值。
3.1 权重量化（Weight-Only Quantization）
只对模型权重进行量化，推理时先将量化权重反量化回FP16再进行计算。
INT8权重量化：
- 模型大小减半（以70B为例：140GB → 70GB）
- 推理速度提升不明显（计算仍是FP16），但可以容纳更大的模型
- 精度损失极小，大部分模型几乎无感
INT4权重量化：
- 模型大小降至原来的1/4（70B：140GB → 35GB）
- 一张A100 80GB可以跑70B模型，甚至单张4090 24GB可跑Qwen 32B
- 精度损失开始变得显著，需要注意校准数据集的选择
主流方案对比：
| 方案 | 精度级别 | 硬件要求 | 精度保留 | 适用场景 |
|---|---|---|---|---|
| GPTQ | 4-bit | 任何GPU | 优秀 | 离线量化的部署场景 |
| AWQ | 4-bit | 任何GPU | 更优 | 对精度敏感的部署场景 |
| GGML/GGUF | 2~8-bit | CPU优先 | 良好 | 本地/边缘设备部署 |
| bitsandbytes | 4/8-bit | NVIDIA GPU | 良好 | 快速原型验证 |
实战经验： 如果追求极致精度保留，推荐AWQ + 校准数据集对齐下游任务。如果目标是尽可能扩大模型规模，GPTQ 4-bit配合分组大小(group size) 128是最稳妥的选择。
3.2 量化感知训练（QAT）
相比训练后量化(PTQ)，QAT在训练过程中模拟量化误差，让模型主动适应低精度表示。通常能获得比PTQ高1~2个百分点的基准分数，缺点是训练成本较高。
一般推荐流程：先用FP16跑完模型训练，再做PTQ快速验证效果，如果精度损失不可接受，再启用QAT微调。
3.3 激活量化
除了权重之外，对激活值(activation)做量化可以进一步提升计算效率。FP8（8位浮点数）是NVIDIA Hopper架构的原生支持格式。在H100上利用FP8做推理，相比FP16在矩阵计算上可获得约2倍的吞吐提升。
不过激活量化比权重量化更"敏感"，因为激活值会因为输入分布不同而大幅波动。实践中需要做动态量化（每token/每层计算scale）或静态量化（用校准数据预计算scale）。
四、KV Cache 优化：让上下文窗口"装得下"
KV Cache优化是提升长序列推理效率的关键。随着上下文窗口从4K扩展到128K甚至1M，KV Cache的显存占用呈线性增长。
4.1 KV Cache量化
对KV Cache做INT8量化，可以将其占用降低一半。KV Cache量化比权重量化更难做，因为精度损失会逐层累积。当前较成熟的方案有：
- KIVI： 对K和V分别量化，K用量化+分组方式压缩，V保持较高精度
- KVQuant： 支持INT2~INT8混合精度量化，根据注意力头的敏感度自适应分配bit数
4.2 Multi-Query Attention (MQA) 与 Grouped-Query Attention (GQA)
原始Transformer论文使用多头注意力(MHA)，KV头数等于Query头数。MQA和GQA大幅减少了KV头的数量：
- MQA：所有Query头共享1个KV头，KV Cache降至1/n（n=头数）
- GQA：中间方案——n个Query头共享1个KV头，平衡了效率与质量
大多数现代模型（Llama 2/3、Mistral、Qwen 2）均已采用GQA。推理框架可以通过这一特性进一步做并行优化。
4.3 PagedAttention 与 vLLM
vLLM是当前最流行的推理服务框架之一，其核心创新PagedAttention借鉴了操作系统虚拟内存的思路：不再为每个请求预分配完整的KV Cache连续空间，而是以"页"(page)为单位按需分配。
效果：
- 显存利用率从60%提升到95%+
- 支持更大的并发数和更长的序列
- 配合连续批处理(Continuous Batching)，吞吐量可达传统方案的数倍
五、计算优化：从算法到算子层面
5.1 Flash Attention
Flash Attention是近年来Transformer推理加速最重要的算法创新。它通过分块计算(tiling)和融合软最大化(fused softmax)技术，将注意力计算的显存占用从O(n²)降至O(n)。在H100上配合FP8使用，Flash Attention-3可以实现理论峰值的60%+利用率。
5.2 算子融合与编译
- 算子融合(Fused Ops)： 将多个连续小算子合并为一个大算子，减少Kernel Launch开销和显存带宽往返。例如LayerNorm + Residual Add一次性完成
- 图优化： 通过TorchScript或专用编译器优化计算图——去除冗余运算、折叠常量表达式、重排执行顺序
- CUDA Graph： 一次编译、多次执行，消除每次推理启动时的GPU Kernel调度开销
5.3 模型剪裁与蒸馏
- 剪裁(Pruning)： 移除不重要的权重连接或注意力头，大幅减少参数数量。结构化剪裁可直接减小模型尺寸，但训练成本高
- 蒸馏(Distillation)： 训练一个小模型($小)去模仿大模型($大)的输出分布。典型如Phi-3系列，用3.8B参数达到7B级别性能
六、服务架构优化：从单机到集群
单个模型的推理优化远远不够，系统级的架构设计决定了实际服务的吞吐和延迟。
6.1 Continuous Batching（连续批处理）
传统批处理在请求不饱和时浪费算力，连续批处理则会在每个推理步骤后检查是否有新请求到达，允许"插队"处理。vLLM和TensorRT-LLM都支持这一机制，在大并发场景下吞吐提升可达10倍。
6.2 前缀缓存（Prefix Caching）
当大量请求共享相同的前缀（如AI Agent的系统提示词相同的很长）时，可以缓存这一部分的KV Cache，后续请求直接复用。在Chatbot、Agent应用中效果显著。
6.3 推测解码（Speculative Decoding）
核心思路：用一个轻量级草稿模型（通常小几十倍）快速生成候选序列，再用大模型一次性验证。如果草稿模型准确率高，推理速度可提升2~3倍而不损失质量。
6.4 部署框架选型对比
| 框架 | 亮点 | 适合场景 | 局限性 |
|---|---|---|---|
| vLLM | PagedAttention，上手简单 | 通用推理服务 | 多机扩展不如TGI |
| TensorRT-LLM | NVIDIA生态深度优化 | 生产级高性能服务 | 学习成本高，模型支持有限 |
| llama.cpp | CPU推理/边缘设备 | 本地/资源受限场景 | GPU利用率较低 |
| SGLang | 前缀缓存+结构化LLM编程 | 复杂推理与Agent场景 | 生态尚在快速发展 |
七、实际部署的避坑指南
7.1 显存估算公式
以INT4量化后的70B模型为例，需要估算三部分显存：
- 模型权重：70B × 0.5字节(4-bit) ≈ 35GB
- KV Cache：batch_size × max_seq_len × layers × hidden_dim × KV_heads_ratio × 2字节
- 中间激活：约等于模型权重使用FP16时的3~8倍（取决于batch size和序列长度）
一个常见陷阱： 很多人在服务端只预留了模型权重的显存，忽略KV Cache和中间激活，导致OOM。
7.2 量化精度验证流程
量化后不是"跑通了就行"，一定要做系统性精度验证：
- 先在标准基准集（MMLU、HumanEval等）上测试量化前后的分数变化
- 再用实际业务数据验证——因为量化对长尾分布的领域知识影响可能被基准集掩盖
- 做端到端的A/B测试——将量化前后的模型放在同一业务管道中盲测
7.3 服务质量(QoS)保障
在实际运营中，最大客户端吞吐量(TPS)和延迟(P99)往往是矛盾的。建议：
- 用请求排队+动态批处理平衡吞吐和延迟
- 设置最大并发数限制，避免所有GPU线程被请求耗尽导致延迟飙升
- 实施降级策略——高负载时切换为小模型或降档量化
八、未来趋势与总结
大模型推理优化正朝着三个方向加速演进：
- 硬件专用化： NVIDIA B200引入FP4精度支持，Groq的LPU为推理场景做极致优化
- 算法与系统协同： 稀疏注意力、状态空间模型(如Mamba)正从根源改变Transformer的推理计算模式
- 自动化调优： AutoQuant、自动搜索最优量化策略和调度参数正在成为标配工具
总结来说，大模型推理优化已经从"能不能跑"的阶段进入"怎么跑得更快更省"的新阶段。对于工程师而言，理解量化、KV Cache优化、计算图优化和服务调度这四个维度，结合实际业务场景做系统级的权衡决策，才是做好大模型部署的关键。没有银弹，但有了工具箱——选对工具、用好工具，就是最优解。