对于部署在 NVIDIA Hopper 架构上的 TensorRT-LLM 推理任务，源文的测试与分析倾向于优先评估纯 FP8 路径。原因是 FP8 可覆盖部分 GEMM、FMHA 与 KV Cache 场景，并在文中所述测试条件下同时表现出较好的精度保持和性能潜力。INT8 并非不能使用，但 INT8 SmoothQuant、INT8 weight-only 与 INT8 KV Cache 的组合需要针对模型、算子和精度目标分别验证，不能仅依据数据类型选择。
FP8 与 INT8 的核心差异
源文讨论的 FP8 基于 NVIDIA Hopper 架构，并指出 TensorRT-LLM 支持 E4M3 格式。相较以 FP16、TF32 等 16 位格式作为输入，FP8 可减少数据传输位宽；在适配的 Tensor Core 路径上，8 位 GEMM 也具备更高吞吐的条件。FP8 不是将 FP16 数据直接转换为 8 位值，而是需要借助量化过程计算 Scaling Factor，使激活值和权重按量化参数参与计算。
INT8 同样可降低数据表示位宽，但其实际表现取决于量化策略。在源文列举的精度对比中，纯 FP8 的精度保持优于若干 INT8 方案；尤其当 Attention 与 KV Cache 也纳入低精度路径时，INT8 方案可能出现更明显的精度损失。该结论来自文中实验，不应直接外推至所有模型、数据集、GPU 或 TensorRT-LLM 版本。
| 比较维度 | FP8 | INT8 |
|---|---|---|
| 源文重点格式或策略 | E4M3、FP8 GEMM、FP8 KV Cache、FP8 FMHA | INT8 SmoothQuant、INT8 weight-only、INT8 KV Cache |
| GEMM 路径 | 可利用 FP8 Tensor Core 进行计算 | 需结合具体量化方案与软件实现评估 |
| Attention 场景 | FMHA 的 batch GEMM 可使用 FP8；软最大值仍需较高精度处理 | 源文指出 INT8 FMHA 的精度下降较明显 |
| KV Cache | 可用于降低存储位宽，源文认为精度更具鲁棒性 | 可量化 KV Cache，但须重点核验精度与转换开销 |
为什么 Attention 与 KV Cache 需要单独判断
Transformer 推理并不是单一 GEMM 工作负载。源文将量化关注点放在四类 GEMM、Multi-Head Attention 和 KV Cache。对于 context phase，Fused Multi-Head Attention（FMHA）中的 batch GEMM 可采用 FP8 Tensor Core 计算；其中 softmax 属于累加过程，仍需要以 FP32 处理。若 FMHA 后紧接 FP8 的 projection GEMM，FP8 输出可减少一次额外量化。
generation phase 的 Masked Multi-Head Attention（MMHA）与 context phase 不同。源文认为其 batch GEMM 的形状使计算密集度较低，因此将该部分改为 FP8 的直接收益有限；但 KV Cache 可使用 FP8 存储以节省显存。源文还指出，在其未开启 XQA 的 MMHA 观察中，INT8 KV Cache 的数值转换可能形成瓶颈，而 FP8 路径的受限程度较轻。实际项目仍需以目标序列长度、并发规模、batch size 和引擎配置复测。
文中性能与精度结论应如何使用
源文报告，在其 FP8 与 FP16 对比中，部分场景获得约 1.5 至 1.7 倍性能提升；在某款 GPU 上运行 Llama2 7B 时，输入序列增大后，开启 FP8 FMHA 的加速效果更明显。文中还以 MMLU 的 78 个子数据集评估量化精度，并在 CNNDaily 数据集上讨论校准耗时。这些数字适合作为评估假设，而不是采购承诺或通用基准。
性能结果会受 GPU 型号、Hopper 支持情况、模型结构、上下文长度、请求分布、并行配置、插件选择及软件版本影响。源文提到 H20 的 FP8 与 INT8 峰值算力相同，但测试中 FP8 仍更快，并将原因归因于 Hopper 特性及软件实现优先级。是否适用于目标环境，应以带日期的 NVIDIA 官方产品文档、完整软件版本组合和本项目压测结果确认。
使用 ModelOpt 与 TensorRT-LLM 的评估路径
- 从 FP16 基线开始，定义模型、上下文长度、并发、首 token 延迟与后续 token 吞吐等验收指标。
- 使用 NVIDIA TensorRT Model Optimizer（ModelOpt）进行 PTQ 校准，准备与实际业务分布相符的校准数据，并生成量化所需的 Scaling Factor。
- 生成 model_config 与对应权重文件，再由 TensorRT-LLM 构建 engine。源文指出，推理时的 Tensor Parallelism 与 Pipeline Parallelism 可与训练配置不同，但实际可行性需要结合完整模型配置验证。
- 分别测试 FP16 基线、纯 FP8、候选 INT8 方案，以及是否启用 FP8 KV Cache 和 FP8 context FMHA 的组合。
- 以任务精度、首 token 时延、生成吞吐、显存占用与稳定性共同决策；不要仅以单个吞吐指标判定方案优劣。
调试与上线边界
量化异常应先定位到 tensor 级别。源文建议注册需要输出的 tensor，构建 engine 后打开 debug model 进行打印。若 GEMM 输出异常，可检查不同 Hugging Face 模型权重的通道布局是否一致；若 Attention 输出异常，则应检查所使用 Attention plugin 的参数配置。
此外，量化精度高度依赖校准数据。源文提到在其 CNNDaily 测试中使用 512 条数据进行 FP8 校准，但这不构成其他模型或业务的通用样本量建议。应通过项目数据覆盖真实输入长度、语言、领域内容和异常输入，并保留 FP16 回退方案与可重复的精度回归测试。
常见问题
FP8 是否一定比 INT8 更快、更准确？
不一定。源文在特定 Hopper、模型和软件实现条件下观察到 FP8 在速度与精度之间更有优势，但结果会随硬件、模型、算子覆盖范围及 TensorRT-LLM 配置变化。应在目标部署环境中使用相同请求分布进行对比测试。
是否应该将所有算子和 KV Cache 都改为 FP8？
不应默认如此。源文指出，FP8 对 context phase 的 FMHA 和部分 GEMM 有价值，而 generation phase 的 MMHA 直接使用 FP8 的收益可能有限。KV Cache 是否量化还需权衡显存压力、精度目标与实际转换开销。
结论
在源文覆盖的 TensorRT-LLM 低精度推理场景中，FP8 是值得优先纳入验证的候选方案，尤其适用于具备 Hopper 支持、希望兼顾 GEMM 性能与量化精度的部署。INT8 仍可作为对照路径或特定约束下的选择，但应通过完整 SKU/BOM、带日期的官方文档以及项目级精度和性能测试确认最终配置。
围绕“TensorRT-LLM 低精度推理对比：FP8 与 INT8 的速度、精度及评估路径”继续了解 采购与选型问答。
WeChat
Profile