不是从零起步的人，多半是被模型体积和推理延迟逼到墙角，才回头来啃这块硬骨头。onnx格式本身只是一个中间表示，真正决定部署效果的是你在这个中间层上做了什么优化。FP16转换和INT8量化这两招，一个负责降精度省显存，一个负责压到整数级别换速度，用好了，你手里的模型从拖泥带水变成轻装上阵，但用不好，精度崩了、算子不支持、速度反而变慢——这些坑我都替你们踩过一遍。
今天这篇东西不铺概念，直接按我实际做部署优化的路径来：先讲清楚到底什么时候该用FP16、什么时候该上INT8，再分别拆解两种操作的核心原理、完整实操步骤和参数细节，最后把我踩过的坑和排查思路全部摊开。内容面向正在做模型部署的工程同学，以及刚接触onnx推理优化、想少走弯路的新手。
1. 先想清楚再动手：FP16与INT8到底解决什么问题
很多人一上来就冲，觉得只要是量化就一定提速、一定省内存，结果改完发现精度下降，甚至延迟不降反升。我建议你先花十分钟想清楚：你的模型到底被什么卡住了？
1.1 三个瓶颈分清楚：显存、延迟、还是带宽
部署一个onnx模型，最常见的三个瓶颈分别是显存占用过高、单次推理延迟太长、以及并发场景下的吞吐量上不去。这三个问题对应的优化策略是不一样的。
如果你的显卡显存不够，模型加载后连一个batch都跑不动，那FP16转换是最直接的解法——权重和激活值全部减半，显存占用直接打对折。如果你的CPU推理延迟压不下来，那INT8量化往往是更优的选择，尤其是在支持整数指令集的CPU上，量化模型能把矩阵乘法的计算密度拉上去几个档次。但要注意，如果你的模型已经在GPU上跑Tensor Core指令，FP16可能比INT8更合适，因为Tensor Core对半精度的支持非常成熟，而INT8在部分GPU上的加速效果反而不如FP16明显。
1.2 两种方案的核心权衡：精度损失与适用硬件
FP16的本质是保留浮点数语义，但把精度从32位砍到16位，它损失的只是尾数位数，动态范围其实还在。INT8则更进一步，直接把浮点数映射到整数区间，权重和激活值都变成8位整数，计算复杂度大幅下降，但精度损失要靠校准过程来弥补。
我实测下来的经验数据大致是这样（不同模型差异较大，仅供参考）：FP16转换通常能把模型体积缩小约50%，准确率损失控制在0.1%以内，在支持FP16加速的GPU上延迟能降低20%到40%。INT8量化在CPU上的体积可以压缩到原来的25%左右，延迟经常能降低50%以上，但精度损失一般在0.5%到2%之间，如果模型本身分布敏感、某些层动态范围极大，精度崩坏也不是没可能。
选型之前先查一下你的目标部署硬件支持哪些算子加速：CPU上有无VNNI或AVX512，GPU有无Tensor Core，这些信息直接决定你用FP16还是INT8。
1.3 适合的组合策略：FP16与INT8不是互斥的
还有一种常见误区是把FP16和INT8当成两条完全独立的路线。实际上，在部分场景下是可以叠加使用的。比如先做INT8量化，再把某些计算密集但数值敏感的子图单独切成FP16子图，用混合精度策略跑。不过这种组合方式调试成本高，初期不建议尝试，先把单一路线跑通再说。
2. FP16转换实操：原理、工具与关键参数
这一节直接进入FP16转换的操作层面。工具选型我推荐用onnx官方的转换工具链，稳定性最好，兼容性也最广。
2.1 FP16的数学底子：为什么体积减半还能稳住精度
FP16之所以能把体积砍半而不引起大面积精度崩坏，核心原因在于神经网络的权重和激活值绝大多数都落在较小的数值范围内。FP32用1位符号、8位指数、23位尾数表示数字；FP16则用1位符号、5位指数、10位尾数。它的最大表示范围是65504，最小正常数是约6.1e-5，还有更小的subnormal值可以表示到约5.96e-8。
多数模型的权重分布通常集中在-1到1之间，激活值经过BatchNorm或LayerNorm后也基本钳制在差不多范围内，FP16完全可以覆盖。只有需要表示极小梯度或极大中间值的场景才可能出问题，这也是为什么转换后必须做精度验证。
2.2 转换前的检查清单：版本与算子兼容性
动手转换前，先做三件事：
- 确认你的onnx模型版本在1.9以上，低于这个版本部分算子可能不支持FP16映射。
- 用推理引擎的检查工具查看模型中是否有潜在的不兼容算子，比如部分自定义算子、部分旧版本的NonMaxSuppression实现，这些可能是转换过程中的拦路虎。
- 准备验证集和精度对比脚本，在转换前先记录FP32模型的基准指标。
2.3 转换命令与参数详解
FP16转换不是简单的数据位替换，工具会遍历计算图，在需要的地方插入Cast节点，把算子输入从FP32切成FP16，算子输出再按需转回FP32。实际操作时，我会用以下方式调用转换接口：
from onnxconverter_common import float16 model = load_model("model.onnx") model_fp16 = float16.convert_float_to_float16( model, keep_io_types=True, disable_shape_infer=False, op_block_list=["LayerNormalization"], ) save_model(model_fp16, "model_fp16.onnx")参数说明：
keep_io_types=True：保持模型的输入和输出数据类型为FP32。这个参数我强烈建议设置为True，因为外部调用方通常不希望你改变输入输出类型，否则得同步修改前后端代码，容易引发连锁问题。disable_shape_infer=False：让工具重新推导形状信息。如果模型是从旧框架导出的，形状信息可能不准确，推导一遍能避免后续推理报错。op_block_list：指定跳过转换的算子列表。哪些算子要加进去？我经验是：LayerNorm在FP16下偶尔会出现数值不稳，建议保留在FP32；还有部分实现较老的Softmax、LogSoftmax算子，如果转换后精度异常，也建议加进这个列表逐层排查。
2.4 转换后的模型体积与算子分布验证
转换完成后，别急着部署。先用脚本检查一下模型体积和算子分布：
python -m onnxruntime.tools.make_dynamic_shape_fixed # 可选然后打开模型结构，手工验证一下关键节点是否都被Cast节点正确包裹。特别是那些数值敏感的算子，比如ReduceMean、Exp、Sigmoid，确认它们在FP16路径上没有丢失精度。
有次我转换一个包含大量Small模型（模拟项目X）时，最终体积从原本的110MB缩到55MB，但某个残差块的输出在FP16路径上出现了一定的数值偏差。逐层查后发现是残差连接处的加法节点在进行FP16累加造成的，解决方案是把该节点block掉，让它在FP32下计算，问题才解决。
3. INT8量化实操：校准方法、粒度选择与算子支持
相比FP16转换这种大体上“一步到位”的操作，INT8量化要复杂得多，里面的讲究全在细节里。
3.1 极简量化数学：Scale、ZeroPoint 与对称非对称
INT8量化的本质是寻找一个映射函数，把浮点数区间映射到[-128, 127]或[0, 255]的整数区间。最核心的两个参数是Scale（缩放因子）和ZeroPoint（零点偏移）。
对称量化的ZeroPoint固定为0，公式为 q = round(clip(x / scale, -127, 127))，适合权重这类分布基本对称的张量。非对称量化增加了ZeroPoint，公式为 q = round(x / scale + zero_point)，适合激活值这种分布往往偏向某一侧的张量。
我见过不少新手在量化时直接用对称量化处理所有张量，结果激活值的量化误差明显偏大。合理做法是：权重用对称量化，激活值用非对称量化，两者结合通常是最稳的组合。
3.2 动态量化与静态量化的适用场景
INT8量化又分成动态量化和静态量化，两者差异很大。
动态量化在推理时才根据实际激活值动态计算Scale和ZeroPoint，因此不需要校准数据，实施成本低。缺点是运行时多了一步动态范围计算，在部分硬件上反而拖慢速度。我用它处理过一个文本分类模型，体积减小明显，精度几乎无损，但延迟只降低了20%左右，低于预期。
静态量化则需要提前用校准集跑一遍模型，统计每个张量的激活值分布，并固定Scale和ZeroPoint。这样做的好处是推理时省去了动态计算，速度更快，缺点是需要额外准备校准数据和校准流程。绝大多数生产环境我用静态量化。
3.3 校准集怎么选：数量、分布与覆盖度
静态量化的精度上限，取决于校准集是否能够真实反映推理时可能遇到的数据分布。我用一条硬性标准：校准集必须从真实业务数据中抽样，绝对不能只用公开数据集或测试集。数量上，我一般至少准备500到1000张样本，类别覆盖要均衡，难度分布要接近线上真实数据。
另一个非常容易被忽略的点：校准集和验证集绝对不能有交集。如果校准集“见过”了验证集的分布，测出来的精度结论就是虚高的，上线后真实表现会很惨。
3.4 实际量化脚本与常见API参数
以onnx推理框架的量化工具为例，我日常会这么写：
from quant import quantize_static, QuantType calibration_data = load_calibration_dataset(...) quantize_static( input_model_path="model.onnx", output_model_path="model_int8.onnx", calibration_data_reader=calibration_data, quant_format=QuantType.QDQ, per_channel=True, activation_type=QuantType.QUInt8, weight_type=QuantType.QInt8, extra_options={...} )几个关键参数细说：
per_channel=True：按输出通道分别计算Scale和ZeroPoint。per-channel量化精度更高，但权重体积会增加一点，因为每个通道都要存一组scale参数。遇到网络较大时，先用per-tensor跑一遍看精度，不够再切per-channel，逐级尝试，别一上来就上最复杂的配置。activation_type=QUInt8：激活值多数情况下用无符号整数更合适，因为ReLU后的激活值都是非负的。全网络无ReLU或存在Sigmoid输出时，用有符号整数反而更好。quant_format=QDQ：QDQ格式（Quantize-Dequantize）在兼容性和可调试性上更好，当前主流推理引擎对这个格式的算子融合支持也最成熟。另一个QuantType.QOperator格式兼容性差一些，尽量不用。
3.5 算子支持矩阵：能量化的和不能量化的
不同算子对INT8量化的支持度差异很大，这里列一个我常用到的支持矩阵：
| 算子类别 | 代表算子 | 静态量化支持 | 说明 |
|---|---|---|---|
| 矩阵乘 | MatMul、Gemm | 支持良好 | 量化收益最大，几乎必选 |
| 卷积 | Conv、ConvTranspose | 支持良好 | CPU和GPU均收益明显 |
| 激活 | Relu、Clip | 支持一般 | 常被融合，单独量化意义不大 |
| 归一化 | BatchNorm、LayerNorm | 部分支持 | LayerNorm量化后精度波动大，需重点验证 |
| 池化 | AveragePool、MaxPool | 支持一般 | MaxPool量化收益甚微 |
| 拼接 | Concat | 支持一般 | 需前后张量尺度一致，否则误差叠加 |
| 动态形状 | NonMaxSuppression、RoiAlign | 基本不支持 | 建议保留FP32子图 |
如果你的模型里动态形状算子占比不低，强行整体量化会触发大量子图回退，最终性能收益大打折扣。这种情况我建议先做子图切分，只量化计算密集的稳定区域，把动态形状部分留在原精度。
4. 实测数据：我在一个图像分类模型上的完整对比
数据比任何天花乱坠的概念都有说服力。我拿一个之前做的图像分类模型（模拟项目X）做了一次完整的FP16与INT8对比，模型基础结构类似于ResNet类骨架，训练集规模约10万张图，单次卷积操作占比超过70%。
4.1 测试环境与基准配置
测试CPU用的是支持AVX512的主流服务器型号，GPU用了一块消费级显卡（为做对照），ONNX Runtime版本统一，线程数固定，批大小固定为1。模型基准是FP32版本：体积约92MB，CPU单次推理耗时约48ms，GPU单次推理耗时约9ms，Top-1准确率88.6%。
4.2 转换结果对比：体积、延迟与精度
| 模型版本 | 体积 | CPU延迟 | GPU延迟 | Top-1准确率 | 精度损失 |
|---|---|---|---|---|---|
| FP32（基准） | 92MB | 48ms | 9ms | 88.6% | 0 |
| FP16 | 46MB | 61ms（反而变慢） | 5.5ms | 88.5% | 0.1% |
| INT8 动态量化 | 26MB | 36ms | 8.2ms | 88.1% | 0.5% |
| INT8 静态量化（per-channel） | 25MB | 18ms | 7.8ms | 87.9% | 0.7% |
FP16在GPU上的加速效果非常明显（9ms降到5.5ms），但在CPU上反而变慢了，这一点极其反直觉，原因后面细讲。INT8静态量化在CPU上的收益最大（48ms降到18ms，提升约2.6倍），GPU上的收益反而不大，这主要受限于当前GPU的整数指令吞吐能力。
4.3 校准方法对比：MinMax、Percentile 与 MSE
同样是静态量化，校准方法选得对不对，直接影响精度。我在这同一个模型上测了三种校准方式：
| 校准方法 | Top-1准确率 | 精度损失 | 说明 |
|---|---|---|---|
| MinMax | 86.9% | 1.7% | 受离群点影响大，最粗糙 |
| Percentile（99.99%） | 87.7% | 0.9% | 剔除极端值，更接近真实分布 |
| MSE（最小化量化误差） | 87.9% | 0.7% | 综合表现最好，推荐首选 |
MinMax方法最大的问题是被离群点牵着鼻子走。激活值分布如果有一个极端大的尖峰，整个量化区间被拉宽，普通数值的量化精度反而下降。Percentile方法能剔除一定比例的极端值，在大多数场景下就够用。MSE方法虽然计算量更大一点，但因为它在每个候选Scale上做穷举搜索，找到的Scale对精度损失最小，所以我默认会用MSE，如果模型较大跑不动，再退到Percentile。
5. 落地过程中最常踩的坑与排查思路
前面说的都是流程，这里才是真正吃过亏之后想留下来的东西。
5.1 CPU上的FP16“越转越慢”的根因
我在CPU上跑FP16模型时，延迟从48ms涨到了61ms，一开始以为是转换工具的锅，结果逐层分析之后发现根因很清晰：CPU没有原生的FP16计算加速指令时，向量化计算单元对FP16数据会先转成FP32再算，多了一道转换开销。有些实现里，权重还是FP16的，激活值要反复在FP16和FP32之间切换，开销反而比纯FP32大。
这个坑的教训是：FP16不是无脑套用的优化手段，它只有在原生支持FP16计算（比如GPU上的Tensor Core，以及特定AI加速卡）时才值得使用。在纯CPU场景，优先考虑INT8。
5.2 转换后输出出现NaN或Inf：动态范围失守
FP16的另一类问题在数值本身。某个模拟项目在FP16转换后，前向传播跑到第三层就全成了NaN。逐算子排查之后发现，罪魁祸首是一个计算数值较大的中间张量，超过了FP16的最大表示范围65504。
这类问题定位起来说难也难，说简单也简单：把FP16模型和FP32模型的每一层输出都拉出来做逐层对比，找到第一个出现明显偏差的层，基本就是问题所在。解决办法不是改模型结构，而是把这个特定算子的FP16转换block掉，让它留在FP32精度下计算，通常就能绕过。
5.3 INT8量化后精度崩了：先查校准数据
INT8量化后如果精度掉得离谱（超过2%），我第一个怀疑的不是量化方法，而是校准数据。有次某开发者分享的模型精度从88%掉到了81%，我让他把校准集拉出来看，发现里的数据和线上真实分布完全对不上，类别分布严重失衡。换成从真实业务日志里抽样的500张图之后，精度一口气拉回到86%以上。
5.4 算子融合失效导致性能不升反降
量化后延迟不降反升的另一个常见原因是算子融合失效。量化模型依赖推理引擎把Quantize、Dequantize、Conv、Clip等一系列操作融合成高效率的核函数。如果某个中间环节（比如一个不受支持的激活函数）打断了融合链条，性能就会大幅回退。
遇到这种情况，我会把量化模型的完整算子列表拉出来，对照支持矩阵逐项排查，看是否有“该融合但未融合”的节点。一个低成本的解决路径是调整网络结构，把这几个影响融合的算子替换掉，比如把自定义激活换成Relu或Clip。
5.5 QDQ格式下的精度验证不能只看端到端指标
奸诈的地方在于：端到端准确率看着差不多，但局部输出的误差已经被放大了。我在一个目标检测模型上遇到过这种情况，整体mAP掉了不到1%，但某个层级的特征图输出最大绝对值误差竟然到了1.2。这类问题如果不排查，极有可能在后续的多模型级联场景里被累积放大。
所以验证时除了端到端指标，我建议再拉一遍逐层输出对比，统计每层的余弦相似度和最大绝对误差，一旦发现某层异常，直接对该层做精度回退。
6. 转换后的有效性验证与日常监控
优化做完不是终点，上线后的监控同样重要。以下是我在实践中沉淀下来的一套验证体系。
6.1 三层验证体系：端到端、逐层、分布对比
第一层是端到端验证，用验证集跑Top-1/Top-5准确率、mAP或你业务自己的核心指标。第二层是逐层输出对比，用校准集里的样本跑一遍FP32和量化模型，比较每个中间层输出的余弦相似度和最大绝对误差。第三层是输出分布对比，统计模型输出的概率分布直方图，看看量化后是否出现整体偏移或双峰。
我在生产环境中把这三层全部自动化了。任何一个模型版本上线前，必须提交一份包含这三项内容的验证报告，超过阈值（比如最大绝对误差大于0.5）就禁止发布。
6.2 灰度发布与快速回滚机制
推理服务上线时，我习惯采用流量灰度策略：先让5%到10%的流量打到新版本模型上，对比业务指标和误差监控，持续观察一段时间后再逐步放大流量。一旦发现指标异常，立即切回旧版本。
关键点是：模型文件版本必须和推理引擎版本绑定记录，不能只记录模型文件本身。有些问题只在特定版本引擎上出现，模型回退时如果引擎不跟着回退，问题依旧。
6.3 混合精度动态选择：一个值得关注的进阶方向
最后说一个进阶思路。如果你的线上负载波动比较大，完全可以把FP16模型和INT8模型同时部署，根据当前机器的实时负载动态路由。高峰时段切到INT8保证吞吐，空闲时段切到FP16保证精度上限。我在一个内部API服务里就是这样做的，整体机器成本降了约30%。
要注意的是，两个模型版本共享同一份预处理和后处理逻辑，切换时只换推理部分，这样路由逻辑简单干净，不会引入额外复杂度。
最后再分享一个实操体会：onnx模型的FP16和INT8优化，本质上是一场工程平衡术——显存、延迟、精度、成本，四件事很难同时做到最优。每次动手前，先把你的核心约束列出来，它是显存不够，还是延迟超时，抑或是吞吐不足？列清楚了再决定路线。我见过太多团队在优化路上迷失方向，归根结底不是工具不行，而是没想清楚自己到底要被什么指标。这个项目后续如果大家有兴趣，我可以再单独写一篇算子级debug的实战记录，把逐层输出对比怎么自动化、怎么快速定位异常层的具体脚本都放出来。
