第一章：精度问题全景图
为什么TensorRT-LLM会出现精度损失？
这个问题，我几乎每次给新团队做推理优化培训时都会被问到。说实话，精度损失这事儿，就像程序员的“中年危机”——迟早会遇到，关键是你怎么应对。
1.1 精度损失的根源：从FP32到FP8的“缩水”之旅
先讲个最直观的例子。你想想看，一个FP32的浮点数，用32位来表示。换成FP16，只有16位。再狠一点，INT8只有8位。这就像用一张高清照片，不断压缩成低分辨率版本——信息必然丢失。
我在项目中遇到过最典型的场景：一个70B的LLaMA模型，FP32推理时PPL（困惑度）是5.2。换成FP16后，PPL变成了5.3。嗯，0.1的差距，看起来不大对吧？但换成INT8后，PPL直接跳到6.8。这就是精度损失的“非线性放大”效应。
核心结论：精度损失不是线性的。FP16到INT8的跳跃，往往比FP32到FP16的损失大一个数量级。
1.2 常见场景：哪些操作最容易“翻车”
我习惯把精度损失场景分成三类。每一类我都踩过坑，分享给你。
场景一：激活值量化
说白了，就是模型中间层的输出值。这些值分布很不均匀——有的层输出范围在[-1, 1]，有的层能到[-100, 100]。你用同一个量化尺度去处理，肯定出问题。
我记得有一次，一个BERT模型在INT8下准确率掉了3%。排查了两天，最后发现是第6层Transformer的激活值分布特别“胖”，量化后信息全丢了。
场景二：权重与激活的联合量化
这个更隐蔽。权重本身可能分布很好，但一旦和激活值相乘，结果就炸了。我称之为“乘法放大效应”。
- 权重分布窄 + 激活分布窄：安全，损失小
- 权重分布窄 + 激活分布宽：中等风险
- 权重分布宽 + 激活分布宽：高风险，几乎必出问题
场景三：KV Cache量化
这个我特别想强调。KV Cache是自回归生成中的“记忆体”。你量化它，相当于让模型“记性变差”。
我曾经在部署一个对话模型时，发现长文本生成时回答质量急剧下降。排查后发现，KV Cache从FP16降到INT8后，模型“忘记”了前面30%的上下文信息。
1.3 影响范围：精度损失到底有多“痛”
不同任务对精度损失的容忍度完全不同。我整理了一个表格，方便你快速判断。
| 任务类型 | FP16损失容忍度 | INT8损失容忍度 | 典型表现 |
|---|---|---|---|
| 文本分类 | 高（<0.5%准确率下降） | 中（1-2%准确率下降） | 边界样本误分类 |
| 文本生成 | 中（PPL上升<0.5） | 低（PPL上升>2） | 重复、逻辑断裂 |
| 代码生成 | 高（语法正确率>99%） | 低（语法错误率上升5%） | 变量名错误、括号不匹配 |
| 数学推理 | 中（准确率下降<1%） | 低（准确率下降>5%） | 计算步骤遗漏 |
我的经验：如果你做的是对话或代码生成，INT8量化前一定要做长文本测试。短文本看不出来，长文本一测就露馅。
1.4 精度损失的知识体系
下面这张图，是我自己总结的精度损失排查框架。每次遇到问题，我都会先对照这张图定位。
1.5 避坑指南：我踩过的三个大坑
最后，分享几个我亲身经历的血泪教训。
坑一：我曾经在量化一个130B模型时，只测了10个样本就上线了。结果线上PPL飙升了3.0。后来发现，那10个样本全是短文本，而线上流量中长文本占了60%。
教训：测试集一定要覆盖真实场景的分布。短文本、长文本、代码、数学题，一个都不能少。
坑二：有一次我优化一个对话模型，FP16推理速度已经很快了。但我非要压到INT8，结果速度没提升多少，回答质量反而下降了。
教训：不是所有模型都需要INT8。如果FP16已经满足延迟要求，就别折腾了。精度损失不是“必须承受的代价”，而是“可以避免的风险”。
我的建议：每次做量化前，先问自己三个问题：
- 这个模型对精度有多敏感？（文本分类？还是数学推理？）
- 我的硬件支持什么精度？（A100的FP8和H100的FP8不一样）
- 我的用户能接受多少损失？（内部工具？还是面向客户的产品？）
想清楚这三个问题，再动手。能省你至少一周的排查时间。
嗯，第一章就到这里。精度损失这事儿，说白了就是“压缩必有代价”。但好消息是，大部分损失都是可预测、可排查、可修复的。后面的章节，我会带你一步步深入每个场景的具体排查方法。
公众号:蓝海资料掘金营，微信deep3321