1. INT8推理概述

大家好，欢迎来到《INT8推理单元实战调优指南》的第一章。

说实话，INT8量化这个话题，这几年在AI芯片部署圈子里，热度一直没降过。我最早接触它是在2018年，当时为了把一个视觉模型塞进嵌入式设备，折腾了整整两周。后来我才明白，量化这件事，说白了就是一场「精度换性能」的博弈。你玩得好，模型跑得飞快，精度损失几乎看不出来；玩不好，模型直接崩掉，输出一堆乱码。

1.1 量化基础概念：从FP32到INT8

先聊聊最基础的东西。量化，就是把连续的浮点数（比如FP32）映射到离散的整数（比如INT8）上。你想想看，FP32有32个比特位来表达一个数，而INT8只有8个。这中间的压缩比是4:1。

具体怎么映射？核心公式其实很简单：

Q = round( (R - zero_point) / scale )

其中：

• R 是原始的浮点数值
• Q 是量化后的整数值
• scale 是缩放因子（步长）
• zero_point 是零点偏移

反量化就是反过来：

R = Q * scale + zero_point

嗯，这里要注意。scale和zero_point怎么选，直接决定了你的量化精度。我个人习惯用「对称量化」来处理权重，用「非对称量化」来处理激活值。为什么？因为权重分布通常是对称的，而激活值往往偏向正数。我在项目中遇到过，如果强行用对称量化去处理ReLU后的激活值，那有一半的量化区间就浪费了，精度损失会很明显。

1.2 为什么需要INT8？

这个问题，我经常被刚入行的同事问到。答案其实很直接：快和省。

咱们来算一笔账：

数据类型	内存占用	计算吞吐量（相对FP32）	功耗（相对FP32）
FP32	4字节	1x	1x
FP16	2字节	2x	~0.5x
INT8	1字节	4x	~0.25x

看到没？INT8的内存占用只有FP32的四分之一。这意味着什么？意味着你的模型可以塞进更小的缓存里，减少对DDR的访问。我做过一个测试，在某个边缘设备上，把ResNet-50从FP32换成INT8，推理延迟从120ms降到了35ms。这可不是简单的4倍关系，因为内存带宽瓶颈被大幅缓解了。

另外，很多现代AI芯片（比如NVIDIA的Tensor Core、华为的达芬奇架构）都内置了INT8计算单元。这些单元专门为整数运算做了优化，吞吐量远高于浮点单元。你想想看，如果不用INT8，这些硬件资源就白白浪费了。

1.3 精度与性能的权衡

这里我要泼一盆冷水。INT8不是万能的。精度损失是真实存在的，尤其是在小模型和低比特量化场景下。

为什么会这样？因为量化本质上是一个有损压缩过程。你丢掉的那部分信息，在某些敏感的任务上（比如目标检测的小物体、语义分割的边缘细节）会暴露出来。

我曾经在一个行人检测项目上吃过亏。模型量化后，整体mAP只掉了0.5%，看起来不错对吧？但仔细一分析，发现模型对远处小行人的召回率从85%直接掉到了62%。这就是典型的「精度分布不均匀」问题——量化误差被集中在了某些特定区域。

怎么权衡？我建议从三个维度来评估：

• 任务敏感度：分类任务通常对量化不敏感，检测和分割任务要小心。
• 模型大小：大模型（比如百层以上的ResNet）量化后精度损失通常更小，因为冗余参数多。
• 部署约束：如果延迟要求是10ms以内，那INT8几乎是唯一选择；如果延迟要求是100ms，FP16可能更稳妥。

1.4 典型应用场景

INT8量化现在几乎无处不在。我列几个最常见的场景：

1. 云端推理：比如NVIDIA的TensorRT，对BERT、ResNet等模型做INT8量化后，吞吐量能提升3-5倍。适合高并发、低延迟要求的在线服务。
2. 边缘计算：手机、摄像头、无人机等设备，内存和算力都有限。INT8量化是让模型跑起来的必要条件。我做过一个手机端的超分模型，量化后从跑不动变成了30fps。
3. 自动驾驶：这个场景对延迟极其敏感。感知模型（比如点云检测）通常要求10ms以内完成推理。INT8量化几乎是标配。
4. 语音和NLP：虽然语音模型对量化更敏感，但通过混合精度（部分层用FP16，部分层用INT8）也能取得不错的效果。

嗯，这里要补充一句。不是所有场景都适合INT8。比如科学计算、高精度金融模型，这些场景对精度的要求远高于性能，那就老老实实用FP32甚至FP64。

1.5 本章知识体系

为了让大家更直观地理解本章内容，我画了一张结构图。它展示了INT8推理的核心逻辑：从量化基础出发，到为什么需要它，再到精度与性能的权衡，最后落到实际应用场景。

这张图把本章的四个核心模块串起来了。你可以看到，量化基础是地基，为什么需要INT8是驱动力，精度与性能权衡是决策依据，应用场景是最终落脚点。后面的章节，我们会沿着这个结构一步步深入。