推理框架核心技术栈：模型压缩与运行时优化
大家好，我是你们的老朋友。今天咱们来聊聊推理框架里最硬核的那部分——模型压缩和运行时优化。说实话，这部分内容我当年刚接触时也觉得头大，但后来在项目中踩过几次坑，才真正理解了它们的价值。
模型压缩说白了就是给大模型「瘦身」。你想想看，一个几百亿参数的模型，直接部署到生产环境，显存根本扛不住。我见过太多团队，模型精度很高，但一上线就OOM，那叫一个尴尬。
量化：把浮点数变成整数
量化是最常用的压缩手段。它的核心思想很简单：用更少的比特数来表示模型参数。
关键概念：FP32 → INT8，模型体积直接缩小4倍，推理速度提升2-4倍。
我个人习惯把量化分成两种：
- 训练后量化（PTQ）：模型训练完再做量化，简单粗暴。我在项目中遇到过，PTQ对大部分模型效果不错，但小模型容易掉精度。
- 量化感知训练（QAT）：训练时就模拟量化过程，精度更高，但训练成本也高。我建议对精度敏感的场景用QAT。
避坑指南：我曾经在一个语音识别项目里，直接用PTQ把模型压到INT8，结果准确率掉了5个点。后来换成QAT，只掉了0.3个点。所以啊，别图省事，该用QAT就用。
剪枝：砍掉不重要的连接
剪枝就是去掉模型中不重要的参数。你想想看，大模型里很多权重其实接近于0，留着它们干嘛？
剪枝分两种：
- 非结构化剪枝：把单个权重置为0，稀疏度高，但硬件不友好。说白了就是，GPU对这种稀疏矩阵支持很差，加速效果有限。
- 结构化剪枝：整行整列地砍掉，硬件友好，但精度损失可能更大。我建议优先考虑结构化剪枝，毕竟部署时省心。
注意：剪枝和量化可以组合使用。我做过一个实验：先剪枝50%，再量化到INT8，模型体积缩小了8倍，精度只掉了1%。但顺序很重要——先剪枝后量化，效果更好。
蒸馏：大模型教小模型
知识蒸馏，说白了就是让一个大模型（教师）教一个小模型（学生）。学生模型学到的不是原始数据，而是教师模型的「知识」。这招在工业界特别实用。
我记得有一次，客户要求模型延迟低于10ms，但大模型根本做不到。后来我们用蒸馏，把7B的模型压缩到1.5B，延迟降到了8ms，精度只差了2%。客户很满意。
推理引擎：TensorRT-LLM、vLLM、TGI
模型压缩完了，还得有好的引擎来跑。目前主流的有三个：
| 引擎 | 特点 | 适用场景 |
|---|---|---|
| TensorRT-LLM | NVIDIA亲儿子，优化最极致 | 高端GPU，追求极致性能 |
| vLLM | 开源，PagedAttention加持 | 通用场景，显存利用率高 |
| TGI | HuggingFace出品，生态好 | 快速原型，与HF模型无缝对接 |
我个人习惯：如果是生产环境，用TensorRT-LLM；如果是快速验证，用vLLM或TGI。你想想看，TensorRT-LLM的优化确实猛，但配置起来也麻烦。vLLM开箱即用，性能也不差。
运行时优化：PagedAttention与Continuous Batching
这部分是推理框架的「内功」。模型压缩和引擎选好了，运行时优化不到位，照样白搭。
PagedAttention：这是vLLM的核心创新。它把KV Cache分页管理，就像操作系统的虚拟内存一样。为什么要这么做？因为大模型的KV Cache太占显存了，而且存在大量碎片。PagedAttention能减少碎片，提高显存利用率。
关键数据：PagedAttention可以让显存利用率从40%提升到95%以上。我在一个长文本生成任务中，原来显存不够用，用了PagedAttention后，同样的显存能处理2倍长的序列。
Continuous Batching：传统的批处理是等一批请求都到了再一起处理。Continuous Batching则是动态调度——有请求来了就加入，处理完了就退出。说白了就是，不让GPU闲着。
我记得有一次，我们做在线服务，用Continuous Batching后，吞吐量提升了3倍。但要注意，它要求请求长度不能差异太大，否则会有「拖后腿」的问题。
知识体系总览
下面这张图，是我自己整理的推理框架核心技术栈。你可以把它当作一个「地图」，方便快速定位问题。
这张图展示了三个层次的关系：模型压缩是「减重」，推理引擎是「载体」，运行时优化是「加速器」。三者缺一不可。
我的建议：刚开始做推理优化时，别想着一步到位。先做量化，看看效果；不够再剪枝；还不行就上蒸馏。运行时优化方面，优先用PagedAttention，它带来的收益最明显。
好了，这一章的内容就到这里。记住，模型压缩和运行时优化是推理框架的「双轮驱动」，缺一不可。下一章我们会深入讲TensorRT-LLM的具体用法，到时候见。