北京
深夜两点，一位安卓工程师翻开最新的模型部署文档，打算把实验室里跑得不错的语音识别模型塞进测试机。应用一启动就卡死，系统直接弹出 ANR（应用无响应）提示。不是内存没清，也不是线程冲突，只是 1 亿参数的模型在 float32 下权重就吞掉约 400MB RAM，加上系统服务挤占，连加载都没完成就被系统杀掉了。
他转而尝试标准的训练后量化，把浮点权重映射到 8 位整数。模型体积果然小了 4 倍，推理延迟也降了，但测试时的准确率却像踩了悬崖，一夜回到解放前。这就是经常被提到的“量化悬崖”——训练后量化带来的突然且毁灭性的精度塌方。正反双方在圈子里争执不休，一方说 PTQ 简单易用，另一方坚信 QAT 才是移动端交付的根基。事情真就这么水火不容吗？
正方观点站得很稳：量化感知训练（Quantization‑Aware Training，QAT）不是在训完模型之后再压缩，而是把量化当作训练中的正则化手段。深度学习模型在反向传播时依赖极微小的梯度调整权重，这些梯度值小到可以忽略任何截断。如果训练过程根本不知道未来会被压到 256 个离散整数值，那训练好的连续权重被强行塞进 int8 桶里，就会产生量化噪声，精度塌方也就难免。QAT 让模型从一开始就学习对量化噪声鲁棒的权重，等于说“你未来要被我压缩，现在就要学会在这种受限世界里好好表现”。
反方同样有底牌：后训练量化（Post‑Training Quantization，PTQ）不需要重新训练，流程短、成本低。不少开发者手头的模型已经在云端跑得顺风顺水，直接用 PTQ 压缩就能上端，多数场景下精度损失可控。还有观点指出，量化感知训练要介入训练循环，对于已经迭代数十版的大模型来说，改动训练管线无异于推倒重来，时间、算力都是真金白银。
裁判的结论要回到硬件运行的物理现实。移动端的 NPU 提供了 SIMD 指令和专门的乘累加单元，整型运算远远快过浮点乘法。单从推理速度看，无论是 PTQ 还是 QAT，用上 int8 都能享受硬件加速。但差别就藏在“量化噪声”对模型最终行为的影响上。一旦需要做设备端的文本生成、实时翻译或者语音指令识别，哪怕几个百分点的精度损失都会直接影响产品体验。这时候，PTQ 那种“先优化连续值再塞进离散桶”的做法，就像用大锤雕大理石，形状勉强能看，表面全是崩边；而 QAT 在训练时就插入了伪量化节点，模拟量化误差，迫使模型参数收敛到对离散化不敏感的解上。
安卓生态也已经开始给 QAT 铺路。AICore 和 Gemini Nano 等端侧推理框架正在把量化感知训练的模型作为一等公民，配合 Kotlin 2.x 可以搭建出生产级流水线。从训练脚本里插入量化模拟器，到导出成 TFLite 格式再跑在安卓 NPU 上，链路已经相对成熟。工程师要看的不再是“该不该用 QAT”，而是“在哪些任务上值得为 QAT 付出训练成本”。
回到那位深夜踩坑的工程师。他把模型重新送入量化感知训练的管线，让模型在 float32 精度下带着“即将会被压缩”的预期完成最后一轮调参。同款手机上，新版模型不但跑通了，首字延迟和整句准确率都稳定到了可发布的水平。所谓的量化悬崖不见了，因为从训练起，这座山就不复存在。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
