很多团队第一次做量化时，会把“位宽减半”直接翻译成“延迟减半”。这在 PPT 上成立，在真实系统里却经常失真。决定部署收益的，不只是算子位宽，还包括数据重排、缓存命中、编译器支持和校准样本质量。
Table of contents
Open Table of contents
先分清哪一段真的受益
量化带来的收益通常落在三个位置：
- 权重体积下降，模型更容易放进片上或近端内存。
- 矩阵计算吞吐提升，前提是硬件对目标位宽真有原生支持。
- 总线搬运成本下降，前提是格式转换没有把时间重新吃回去。
如果你的硬件在输入输出环节仍要大量做 FP32 和 INT8 的往返转换，那么“量化收益”可能只存在于核心算子。
带宽账应该这样算
部署前最好先列一张简单表：
- 每层权重从哪里读取。
- 中间激活会不会溢出到外部内存。
- 前后处理是否和推理共享同一条内存带宽路径。
- 模型切分、多流并发时，带宽峰值落在哪个时间窗。
只有算清这张表，才能判断量化到底是在救系统，还是只是在优化单个 kernel。
校准样本质量经常被低估
工程现场的另一个误区，是拿少量“看起来差不多”的样本去做量化校准。结果是离线指标变化不大，上线后却在极端场景里突然掉精度。对于边缘部署，这个代价往往高于理论上的吞吐收益。
什么情况下不要急着量化
如果项目仍处在模型结构高频变动期，或者底层编译器还不稳定，过早量化会让排障难度成倍上升。更稳妥的做法是先把基线和 profiling 跑稳，再决定要不要做 INT8、INT4，还是先从混合精度开始。
结论
量化值得做，但它是一笔系统账，不是一笔单点算子账。先把带宽、格式转换和校准成本写进预算，再谈位宽收益，团队会少走很多演示驱动的弯路。