8.1 模型压缩：量化、剪枝与蒸馏
核心问题： 如何在尽量少损失效果的前提下，降低模型显存、延迟和部署成本？
在线 Notebook
对应的交互式版本可在 Google Colab 打开，统一使用方式见 第0章说明。
为什么需要压缩
LLM 的生产瓶颈通常不是“能不能跑”，而是“能不能稳定、便宜、低延迟地跑”。
主要成本来自：
- 参数占用显存
- KV cache 占用显存
- 每个 token 的矩阵计算
- 并发请求带来的峰值资源需求
量化、剪枝和蒸馏都是压缩手段，但解决的问题不同：
- 量化主要降低数值精度和显存占用。
- 剪枝主要删除权重、通道、注意力头或网络结构中的冗余部分。
- 蒸馏主要把大模型能力迁移到小模型。
量化
量化把 FP16/BF16 权重转换为 INT8、INT4 等低精度表示。
| 方法 | 思路 | 适用场景 | 主要风险 |
|---|---|---|---|
| PTQ | 训练后直接量化 | 快速部署、低成本试验 | 长尾任务精度下降 |
| QAT | 量化感知训练 | 对精度要求更高 | 训练成本更高 |
| GPTQ/AWQ | 面向 LLM 的权重量化 | 本地推理、边缘部署 | 硬件和框架适配复杂 |
量化不是免费午餐。低 bit 数会降低显存和带宽压力，但也可能让数学、代码、长上下文或小众领域任务退化。
剪枝与稀疏化
剪枝通过移除模型中贡献较低的参数或结构，让模型变小或计算更少。它常和“稀疏化”一起讨论：剪枝制造稀疏结构，推理框架和硬件负责把稀疏结构转化为真实加速。
常见类型：
| 方法 | 思路 | 优点 | 主要风险 |
|---|---|---|---|
| 非结构化剪枝 | 删除单个权重，形成稀疏矩阵 | 理论压缩率高 | 普通硬件上不一定加速 |
| 结构化剪枝 | 删除通道、层、注意力头或 FFN 维度 | 更容易获得真实加速 | 容易破坏模型能力 |
| 半结构化稀疏 | 例如固定比例的 N:M 稀疏 | 更容易匹配特定硬件 | 依赖硬件和推理框架支持 |
在 LLM 部署里，剪枝通常不是默认首选。原因是：
- 量化更通用，工具链更成熟，部署收益更容易兑现。
- 非结构化稀疏如果没有硬件加速，可能只减少参数量，不减少实际延迟。
- 结构化剪枝会改变网络容量，容易导致长尾任务、推理能力或领域能力退化。
- 剪枝后通常还需要校准、继续训练或任务微调，否则质量回退不可控。
因此，剪枝更适合在明确约束下使用：目标硬件支持稀疏加速、业务任务边界清楚、有可靠评估集，并且可以接受重新校准或微调成本。
蒸馏
蒸馏用大模型生成或标注训练数据，让小模型学习大模型的行为。
text
大模型
↓ 生成高质量样本 / 打分 / 解释
训练数据
↓ 微调小模型
小模型蒸馏适合：
- 任务范围明确
- 输出格式稳定
- 线上成本敏感
- 可以接受小模型只覆盖部分能力
不适合：
- 任务开放且变化快
- 需要大模型完整推理能力
- 缺少可靠评估集
选择原则
| 目标 | 优先方案 |
|---|---|
| 快速降低显存 | PTQ / INT8 |
| 本地低成本部署 | INT4 / GGUF / AWQ |
| 目标硬件支持稀疏加速 | 结构化剪枝 / 半结构化稀疏 |
| 保持业务任务效果 | QAT 或任务评估驱动的量化 |
| 用小模型替代大模型 | 蒸馏 + 任务微调 |
上线前必须用业务评估集验证，而不是只看通用 Benchmark。
本节小结
- 量化降低数值精度，主要换取显存和速度收益
- 剪枝删除冗余参数或结构，但真实收益依赖硬件、框架和后续校准
- 蒸馏迁移大模型行为，主要换取更小模型和更低推理成本
- 压缩会改变模型行为，必须用业务评估集验证
- 生产系统里，量化收益要和硬件、推理框架、并发模式一起评估
下一节： 8.2 推理优化