1. 课程导入
在移动端、嵌入式设备与物联网场景中，深度学习模型的部署长期面临一个"不可能三角"：模型体积要小、推理延迟要低、任务准确率要尽量不损失。传统做法是直接使用训练好的浮点模型（FP32），但一个ResNet-50模型权重就超过98MB，在手机端下载、加载、运行都极为吃力。TFLite量化部署正是为了解决这一矛盾而生的工程化方案——它通过将模型中的权重和激活值从32位浮点数压缩为8位整数（甚至更低精度），在保持任务效果可接受的前提下，显著减小模型体积、降低内存占用、加速推理过程。本章作为整个课程的开篇，将系统梳理TFLite量化的背景动因、核心目标、关键挑战，以及"体积、延迟、准确率"三方平衡的工程判断框架，为后续各章的实操技术打下认知基础。
1.1 为什么需要量化部署：从浮点模型到端侧推理的鸿沟
深度学习模型在训练阶段通常使用32位浮点数（FP32）来保存权重和计算梯度，这是为了保证反向传播的数值稳定性。然而，当模型训练完成、进入部署阶段后，这种高精度的表示方式反而成为负担。以MobileNetV2为例，其FP32权重约14MB，INT8量化后可压缩至3.5MB，体积缩小75%。在移动端场景中，这种差异直接决定了应用能否在用户可接受的等待时间内完成模型下载和加载。
更关键的是推理延迟问题。现代手机CPU（如ARM Cortex-A系列）对INT8整数运算的吞吐量通常是FP32浮点运算的2到4倍，而带有DSP或NPU加速单元的芯片（如高通Hexagon、联发科APU）对INT8的支持更为激进，部分场景下可达到10倍以上的加速。这意味着，同样的模型结构，量化后不仅体积变小，推理速度也可能获得数量级的提升。
然而，量化并非无损操作。将连续分布的浮点数值映射到离散的整数区间，本质上是一个有损压缩过程。对于权重分布均匀、对精度不敏感的模型（如分类任务中的浅层网络），量化后的准确率损失可能小于0.5%；但对于检测、分割等密集预测任务，或者包含BatchNorm层、异常值权重（outlier）的模型，量化带来的精度下降可能达到2%至5%，甚至导致模型失效。
1.2 三方平衡框架：体积、延迟与准确率的工程权衡
在TFLite量化部署中，体积、延迟、准确率三者构成一个相互制约的三角关系。体积影响的是存储和带宽成本，延迟影响的是用户体验和实时性，准确率则直接决定模型能否完成业务目标。工程实践中，我们需要根据具体场景确定优先级：
| 场景类型 | 体积优先级 | 延迟优先级 | 准确率优先级 | 典型量化策略 |
|---|---|---|---|---|
| 移动端图像分类App | 高（需快速下载） | 中（可接受200ms） | 高（用户可感知） | 全INT8量化 + 量化感知训练 |
| 实时视频流检测 | 中 | 极高（需<30ms/帧） | 中（可容忍少量漏检） | INT8 + 部分层保持FP16 |
| 嵌入式语音唤醒 | 极高（Flash<1MB） | 高（需实时响应） | 中（误唤醒可接受） | 动态范围量化 + 权重聚类 |
| 医疗影像辅助诊断 | 低 | 低（离线分析） | 极高（误诊代价大） | 仅权重量化或混合精度 |
判断一个量化方案是否可行，不能只看单一指标。例如，一个模型量化后体积从100MB降到25MB，但准确率从92%掉到85%，在医疗场景中就是不可接受的；而在短视频推荐场景中，如果延迟从80ms降到20ms，准确率下降1%可能完全值得。因此，我们需要建立一套量化评估流程：
- 明确业务约束：确定体积上限（如APK包体<50MB）、延迟上限（如单帧推理<50ms）、准确率下限（如Top-1准确率≥90%）。
- 建立基线：记录FP32模型在目标设备上的体积、延迟和准确率作为对照基准。
- 尝试不同量化方案：从最激进的全INT8量化开始，逐步放宽到混合精度或仅权重量化，记录每个方案的三角指标。
- 绘制权衡曲线：以准确率为横轴、延迟或体积为纵轴，找到满足所有约束的"帕累托最优"点。
- 验证真实场景：在目标设备（而非开发机）上测试实际延迟和内存峰值，因为模拟器与真机差异可能达到30%以上。
1.3 案例拆解：智能相册分类模型的量化选型
某移动应用团队需要将一个图像分类模型部署到Android端，用于自动识别照片中的场景（室内/室外/美食/宠物等10类）。初始模型为EfficientNet-Lite0，FP32权重约4.8MB，在骁龙778G测试机上单帧推理延迟为85ms，Top-1准确率为91.2%。业务要求：APK增量体积不超过3MB，推理延迟低于60ms，准确率不低于89%。
初始分析与约束识别：体积方面，FP32模型4.8MB已超出3MB限制，必须压缩；延迟方面，85ms距离60ms目标有25ms差距；准确率方面，允许下降2.2个百分点。团队决定尝试三种量化方案：
- 方案A：动态范围量化（仅权重INT8）——体积降至1.4MB，延迟降至62ms，准确率90.5%。
- 方案B：全INT8量化（权重+激活）——体积降至1.3MB，延迟降至38ms，准确率88.7%。
- 方案C：全INT8量化 + 量化感知训练（QAT）——体积1.3MB，延迟38ms，准确率90.1%。
分析判断过程：方案A延迟62ms仍略超60ms目标，且体积虽达标但延迟余量不足；方案B准确率88.7%低于89%红线，不可接受；方案C三项指标均满足要求。虽然方案C需要额外进行量化感知训练（约增加2天训练时间），但这是唯一同时满足三方约束的方案。
实际操作步骤：团队使用TensorFlow的QAT API在原有训练脚本基础上添加伪量化节点，使用ImageNet子集微调3个epoch，然后通过TFLite Converter转换为INT8全量化模型。在真机测试中，方案C的延迟为38ms，内存峰值从FP32的210MB降至95MB，APK增量体积1.3MB，准确率90.1%。
风险与代价：QAT训练增加了工程复杂度，且需要维护两套训练流程（浮点预训练+量化微调）。此外，如果后续模型结构更新，需要重新执行QAT流程。团队为此建立了自动化训练流水线，将QAT步骤集成到CI/CD中。
1.4 常见误区与工程红线
在量化部署实践中，工程师常陷入以下误区，导致项目返工或线上事故：