想象你是一家小餐馆的老板。有客人点名要吃某家米其林三星餐厅的招牌菜——松露炖饭。你只有一口铁锅、几样家常调料。这时你拿到一份用法语写的菜谱，上面写着要用分子料理机，还要精确到 0.1 克。你照着做，必然翻车。于是你请来一位懂行的翻译，把法文誊成中文，把“分子料理机”换成“热水浴”，把“松露”换成“香菇”，把“精确到 0.1 克”改成“一勺盐”。最后端出来的菜，客人尝了尝：嗯，八九分像，上菜还快！——这就是模型转换。AI 训练师用 PyTorch 这些“米其林厨房”做出的大模型，体积大、依赖服务器环境；而手机、门禁、音箱这些“小厨房”资源紧张，跑不动原版。模型转换就是那位翻译：把训练好的模型，进行格式转换、算子映射、精度量化、性能验证，改写压缩成端侧能跑的版本。读完这篇，你也能当那位懂得翻译和改菜的师傅。

岗位关联

掌握模型转换，你才能把训练好的模型真正装进手机、门禁、音箱，让 AI 从云端走进现实——这是边缘智能工程师的入门必修课。

目录
  1. 可视化演示
  2. 转换流程概览
  3. 格式转换
  4. 算子映射
  5. 精度量化
  6. 转换工具链
  7. 兼容性诊断
  8. 性能验证
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示PyTorch到TFLite转换流程、算子映射兼容性检查及精度量化对比三种核心模式，直观呈现移动端模型部署从格式转换到性能优化的完整链路。

本节配有交互动效（进入视口后自动加载，约 3KB）。

模型转换流程 PyTorch模型经导出优化生成TFLite移动端格式 四阶段转换流水线确保格式正确性与最优性能 PT → ONNX → OPT → TFLite 模型转换是移动端部署的必经步骤

转换流程概览

翻译一份米其林菜谱并不只是把法语单词换成中文。真正的难点在于，你的小厨房里没有分子料理机，也没有精确到 0.1 克的电子秤。翻译要做三件事：先把原文完整誊抄一遍，再把每个步骤改写成小厨房能执行的动作，最后亲自试做一道菜，确认味道没跑偏。

模型转换面对的也是同样三件事。训练框架（PyTorch、TensorFlow）产出的模型，本质是一张“计算图”：节点是算子（卷积、激活、归一化），边是张量数据流。而移动端推理引擎（TFLite、NCNN）只认自己的图和算子。把一张 PyTorch 图变成一张 TFLite 图，就是“誊抄 + 改写 + 试做”。

标准流程分三步。第一步导出：把训练好的网络连同权重导出成一种通用的中间表示，最常见的是 ONNX。第二步转换：把中间表示翻译成目标引擎的图格式，途中要做算子映射、常量折叠、算子融合，必要时做量化压缩。第三步验证：用同一批输入分别跑原模型和新模型，比较输出是否一致。只有验证通过，转换才算完成。

这就像翻译完成后必须“试菜”：翻译得再工整，端出来的菜不对味就是失败。所以转换流程的最后一步永远是验证——这也是为什么业内常说“没有验证的转换等于没转”。

∀x∈D,f目标(x)≈f源(x)\forall x \in \mathcal{D},\quad f_{\text{目标}}(x) \approx f_{\text{源}}(x)
这句公式是说“对任意一个输入 x，转换后的模型输出都要和原模型几乎一样”，≈ 表示允许极小的误差，就像翻版菜谱做出来的菜可以差一勺盐，但不能变成另一道菜。
  1. 全称量词符号 ∀ 读作“对任意”，把验证范围拉满到整个数据分布。
    ∀\forall
  2. 输入样本 x来自数据分布 \mathcal{D} 的任意一张输入，比如一张照片或一段语音。
    x∈Dx \in \mathcal{D}
  3. 源模型 f_源训练好的原始模型，对应“米其林原版菜谱”。
    f源f_{\text{源}}
  4. 目标模型 f_目标转换压缩后的端侧模型，对应“小厨房改写版”。
    f目标f_{\text{目标}}
  5. 近似符号说明转换允许浮点误差与量化误差，只要在可接受范围内。
    ≈\approx

格式转换

菜谱誊抄要选对“本子”。你可以把法文菜谱原样抄成日文、中文，但每家出版社的排版格式不同：有的用表格，有的用编号列表。更聪明的做法是，先统一抄成一种“标准排版”，再分发给各个出版社。

模型格式同理。PyTorch 的 .pt/.pth 文件是 Python 序列化格式，里面是张量加结构信息，脱离 Python 环境就没法读。TFLite 用 FlatBuffer，NCNN 用 .param + .bin 组合。这些格式互不兼容，所以业界先用 ONNX 作“标准排版”——这是微软联合多方推出的开放图格式，各家引擎都能导入。

典型路径有两条。PyTorch → ONNX：用 torch.onnx.export 导出 .onnx 文件，可配置 opset 版本与动态维度。ONNX → TFLite：先转成 TensorFlow SavedModel，再用 TFLiteConverter 产出 .tflite；或 ONNX → NCNN：用 onnx2ncnn 工具直接解析 .onnx，输出 .param（网络结构）和 .bin（权重）。这些格式的差异直接影响文件体积与加载速度。

选对“本子”很重要：就像菜谱排版决定厨师翻页顺不顺手，模型格式决定引擎加载快不快、算子好不好映射。所以转换永远先从格式转换开始，而不是直接改后缀。

size=Nparam×b\text{size} = N_{\text{param}} \times b
模型文件大小等于参数个数乘以每个参数占用的字节数。FP32 每参数 4 字节，INT8 每参数 1 字节，所以光格式层面 INT8 就是 FP32 的 1/4。
  1. 参数量N_param 表示模型权重总数，比如卷积核里所有数值的个数。
    NparamN_{\text{param}}
  2. 每参数字节数b 是单个权重的存储宽度，FP32 占 4 字节，INT8 占 1 字节。
    b∈{4,1}b \in \{4, 1\}
  3. 总体积相乘得到文件大小，量化与稀疏可以理解为降低 b 或 N_param。
    Nparam×bN_{\text{param}} \times b

算子映射

翻译菜谱最头疼的是“这道菜的做法本地厨房做不到”。分子料理的温度控制、真空低温慢煮，都要换成铁锅、蒸锅能实现的替代手法。改写时还不能破坏菜品的味道结构——这就是算子映射的日常。

算子（Operator）是计算图的基本单元，如卷积（Conv）、批归一化（BatchNorm）、激活（ReLU）、全连接（Linear）。源框架里的每个算子，都要在目标引擎的算子库中找到“等价做法”。找得到，直接映射；找不到，就要用几个算子的组合去等价替换；能数学简化的，就融合掉。

最常见的优化是算子融合。TFLite 和 NCNN 都支持把 Conv+BN+ReLU 融合成一个算子，减少计算和内存访问。BN 在推理时是一个线性变换，可以拆开解析、再折叠进卷积权重里：

融合就像把“撒盐、腌十分钟、大火爆炒”合并成“调味爆炒”一个动作：少洗一次锅，少一次出错的机会。映射与融合做得越好，端侧的菜就越快地端上桌。

y=γ⋅x−μσ2+ϵ+β=w′x+b′,w′=γσ2+ϵ,b′=β−γμσ2+ϵy = \gamma \cdot \frac{x - \mu}{\sqrt{\sigma^2 + \epsilon}} + \beta = w'x + b',\quad w' = \frac{\gamma}{\sqrt{\sigma^2 + \epsilon}},\quad b' = \beta - \frac{\gamma\mu}{\sqrt{\sigma^2 + \epsilon}}
BN 折叠：批归一化在推理时只是“缩放加平移”，可以把它整体折叠进上一层的卷积权重里，运行时就少算一层，速度更快。
  1. 平均值与方差μ 和 σ² 是训练时统计的批数据均值与方差，推理时是固定值。
    μ,σ2\mu, \sigma^2
  2. 防零常数ε 是避免除零的小常数，比如 1e-5。
    ϵ\epsilon
  3. 缩放与偏移γ 和 β 是可学习的参数，控制归一化后的尺度与位置。
    γ,β\gamma, \beta
  4. 等效权重w' 和 b' 是把 BN 的变换合并后的新卷积权重与偏置，这就是“融合”的数学本质。
    w′=γσ2+ϵ,b′=β−γμσ2+ϵw' = \frac{\gamma}{\sqrt{\sigma^2 + \epsilon}},\quad b' = \beta - \frac{\gamma\mu}{\sqrt{\sigma^2 + \epsilon}}

精度量化

米其林菜谱写“盐 1.2 克，高汤 37.5 毫升”，小厨房的厨师手里只有一把盐、一勺高汤。写得太精确反而没法执行。于是菜谱改写时把分量粗略化——这就是量化：把精细的浮点世界，压缩成粗糙但够用的整数世界。

模型默认用 FP32（32 位浮点）存权重和激活，一个数占 4 字节，范围巨大。移动端内存小、算力弱，要换成 INT8（8 位整数），一个数只占 1 字节，计算更快、更省电。代价是精度损失：毕竟 40 亿个浮点值要挤进 256 个整数档位。

量化分两类。训练后量化（PTQ）：模型训练完成后直接转换，用一小批数据统计每层数值范围，然后做缩放映射，简单快速但可能掉点；量化感知训练（QAT）：在训练时就模拟量化误差，让权重适应“被归入档位”这件事，精度保持更好但需要重新训练。

量化就像菜谱改写成“一把盐”——味道微变，但省料省时。只要精度损失在 1%~2% 以内，客人和用户都尝不出来。

q=round(rs)+z,s=rmax⁡−rmin⁡qmax⁡−qmin⁡,z=qmin⁡−round(rmin⁡s)q = \mathrm{round}\left(\frac{r}{s}\right) + z,\quad s = \frac{r_{\max} - r_{\min}}{q_{\max} - q_{\min}},\quad z = q_{\min} - \mathrm{round}\left(\frac{r_{\min}}{s}\right)
r≈(q−z)×sr \approx (q - z) \times s
r 是原来的浮点值，q 是量化后的整数。s 像“每一格代表多少”，z 是“零点偏移”。反量化把整数还原成浮点近似值，推理过程中会反复发生。
  1. 原始浮点值r 是权重或激活中的真实数值，比如 0.7321。
    rr
  2. 缩放系数s 是浮点范围除以整数范围，决定“一个整数档位代表多少浮点”。
    s=rmax⁡−rmin⁡qmax⁡−qmin⁡s = \frac{r_{\max} - r_{\min}}{q_{\max} - q_{\min}}
  3. 零点偏移z 确保浮点 0 在量化域里有精确对应的整数，避免 padding 和 ReLU 输出失真。
    z=qmin⁡−round(rmin⁡s)z = q_{\min} - \mathrm{round}\left(\frac{r_{\min}}{s}\right)
  4. 取整round() 把除法结果四舍五入到最近整数，同时要用 clamp 限制在 [q_min, q_max] 内。
    round(rs)+z\mathrm{round}\left(\frac{r}{s}\right) + z
  5. 反量化还原(q - z) × s 是量化逆变换，把整数输出还原成浮点供后续层使用。
    (q−z)×s(q - z) \times s

转换工具链

那位懂行的翻译不是只靠脑子干活，他手边有词典、术语表、排版模板和校对软件。模型转换也一样，靠一条成熟的工具链把“复制—改写—校对”自动化。

工具链按“先导出、再简化、后转换”的顺序接起来。导出环节最常用 torch.onnx.export，它把 nn.Module 连同权重一次性写进 .onnx 文件。之后常用 onnx-simplifier 做“润色”：折叠常量、去掉冗余 reshape、规整冗余的算子。最后才是真正的“翻译”：TFLiteConverter 或 onnx2ncnn 把中间图转成目标格式。

工具链的参数直接影响结果。opset 版本决定算子语法版本，要选源框架和目标引擎都支持的公共版本；动态轴配置决定哪些维度做成可变的；量化配置（如 representative dataset）决定 PTQ 的分位数统计。工具链可以像公式那样组合表达：

有了工具链，你就像那位带着专业词典的翻译，不必每次从零誊抄菜谱；但工具也会出错，所以下一节“兼容性诊断”就是你的校对环节。

NCNN=onnx2ncnn(simplify(export(PyTorch 模型)))\text{NCNN} = \text{onnx2ncnn}\left(\text{simplify}\left(\text{export}\left(\text{PyTorch 模型}\right)\right)\right)
这串嵌套公式表示“从右往左执行”：先导出、再简化、最后转换，每一步的输出喂给下一步。
  1. 导出函数export 把 PyTorch 模型结构加权重写成标准 ONNX 文件。
    export(PyTorch 模型)\text{export}\left(\text{PyTorch 模型}\right)
  2. 简化函数simplify 对 ONNX 做常量折叠与结构整理，去除冗余算子。
    simplify(⋅)\text{simplify}(\cdot)
  3. 转换函数onnx2ncnn 把简化后的 ONNX 解析成 NCNN 的 .param 与 .bin。
    onnx2ncnn(⋅)\text{onnx2ncnn}(\cdot)
  4. 嵌套组合函数从右到左执行，形成“导出→简化→转换”的流水线。
    onnx2ncnn(simplify(export(⋅)))\text{onnx2ncnn}\left(\text{simplify}\left(\text{export}\left(\cdot\right)\right)\right)

兼容性诊断

翻译稿交回来，你逐行对照原文检查，发现问题五花八门：有的食材本地根本买不到，有的步骤前后矛盾，有的分量明显抄错了。诊断兼容性就是“逐行校对”。

转换中最常遇到三类问题。第一，算子不支持：比如 PyTorch 的 nn.AdaptiveAvgPool2d 在 NCNN 里没有直接实现，或自定义算子只存在于源框架。第二，形状不一致：导出时没固定动态维度，输入宽高在静态图引擎里解析失败。第三，精度异常：量化后输出 NaN 或乱码，往往是范围统计没做好。

排查手段是“逐层比对”：把源模型和目标模型的每一层输出都取出来，逐层比较数值差，用 L2 范数量化偏差，快速定位第一个“严重跑偏”的层——这层就是问题源头。常用 onnxruntime 先验证 ONNX 本身能跑，再用二分法逐层隔离：

逐层比对就像品菜师把两道菜按“前菜、主菜、甜点”拆开对比：先锁定是哪一道跑偏，再回到菜谱找原因。兼容性问题通常都能这样定位修复。

εi=∥yi源−yi目标∥2\varepsilon_i = \left\| y_i^{\text{源}} - y_i^{\text{目标}} \right\|_2
把源模型和目标模型在第 i 层的输出向量相减，再求欧几里得长度。偏差突然变大的一层，就是需要手工排查和修复的位置。
  1. 层下标i 表示第 i 层（如第 3 个卷积层）。
    ii
  2. 源输出y_i^源 是源模型在第 i 层产出的特征图向量。
    yi源y_i^{\text{源}}
  3. 目标输出y_i^目标 是转换后模型在第 i 层产出的对应向量。
    yi目标y_i^{\text{目标}}
  4. L2 范数||·||_2 计算向量差的长短，数值越大代表这一层偏差越严重。
    ∥⋅∥2\left\| \cdot \right\|_2

性能验证

翻译结束、试菜通过，还不能直接上菜单——客人会问：这道菜上得快吗？成本高吗？分量足吗？性能验证回答的正是这三个问题。

验证有四个核心指标。精度：在测试集上对比 FP32 原模型和 INT8 转换模型的准确率差。延迟：在目标真机或 ARM 环境上循环推理多次，取平均耗时。体积：转换后文件大小是否满足安装包预算。稳定性：多次运行结果是否一致、内存峰值是否过高。

精度与延迟之间需要权衡：量化让体积变小、延迟变低，但精度会掉。工程上前置一个“精度损失预算”，比如要求掉点不超过 1%，再决定量化策略：

试菜合格，菜谱才能印进菜单；验证通过，模型才能随 App 发版。量化、工具链、诊断的每一步，最终都靠这一关来验收。

ΔAcc=AccFP32−AccINT8\Delta \text{Acc} = \text{Acc}_{\text{FP32}} - \text{Acc}_{\text{INT8}}
原模型准确率减去量化模型准确率，得到的差值就是量化付出的代价；一般要求控制在 1%~2% 以内才允许发版。
  1. 原模型准确率Acc_FP32 是未量化的浮点模型在测试集上的准确率。
    AccFP32\text{Acc}_{\text{FP32}}
  2. 量化模型准确率Acc_INT8 是量化到 INT8 后同一测试集上的准确率。
    AccINT8\text{Acc}_{\text{INT8}}
  3. 损失差值两者相减得到精度损失，若超过预算，就要改用 QAT 或混合精度。
    ΔAcc\Delta \text{Acc}

AI 应用场景

手机端拍照识花 App 部署

阶段：模型部署与端侧推理优化

解决的问题：传统做法是把图片传云端识别，有 300ms 网络延迟、弱网不可用、用户隐私泄露三重痛点。直接把 PyTorch 模型塞进手机又不可行——手机没有对应运行时。用“PyTorch→ONNX→TFLite + INT8 量化”的转换链路，模型从 45MB 压到 11MB，单帧从 800ms 降到 120ms，全程离线运行。

具体案例：某识花应用把 MobileNetV3 分类模型做端侧部署，量化后准确率仅降 0.8%，弱网环境下依然秒开。

安防门禁 NCNN 检测模型适配

阶段：模型适配与算子兼容性修复

解决的问题：检测模型里有 AdaptiveAvgPool 和若干自定义算子，onnx2ncnn 直接报错，就像翻译稿里“本地买不到松露”。用 onnx-simplifier 简化、把 AdaptiveAvgPool 换成等价的 GlobalAvgPool、固定输入尺寸后，转换成功并解决了形状不一致问题。

具体案例：人脸检测模型在瑞芯微 RK3588 上用 NCNN 部署，修完算子兼容问题后 FPS 从 8 提到 25，功耗下降 40%。

语音唤醒词模型的量化感知训练

阶段：模型量化与精度保持

解决的问题：唤醒词模型体积小、对精度敏感，直接用训练后量化（PTQ）掉点严重——就像“一把盐”毁了一锅汤。改用量化感知训练（QAT），在训练时就加入伪量化节点，让模型提前适应 INT8 世界，精度损失大幅收窄。

具体案例：某智能音箱唤醒词模型，PTQ 后准确率从 96.1% 掉到 89%，换成 QAT 后只掉到 95.6%，符合发版预算。

Python 演示

python46 行
import torchimport torch.nn as nn  class TinyCNN(nn.Module):    def __init__(self):        super().__init__()        self.conv1 = nn.Conv2d(1, 8, 3, padding=1)        self.bn = nn.BatchNorm2d(8)        self.relu = nn.ReLU()        self.fc = nn.Linear(8 * 8 * 8, 10)     def forward(self, x):        x = self.relu(self.bn(self.conv1(x)))        x = x.view(x.size(0), -1)        return self.fc(x)  def quantize(weight, qmin=-128, qmax=127):    scale = (weight.max() - weight.min()) / (qmax - qmin)    zero = qmin - weight.min() / scale    q = torch.round(weight / scale + zero).clamp(qmin, qmax)    deq = (q - zero) * scale    return q, deq  def main():    model = TinyCNN()    model.eval()    dummy = torch.randn(1, 1, 8, 8)    torch.onnx.export(model, dummy, "tiny.onnx", opset_version=13)    n_params = sum(p.numel() for p in model.parameters())    print("params:", n_params)    print("fp32 size(MB):", round(n_params * 4 / 1e6, 3))    print("int8 size(MB):", round(n_params * 1 / 1e6, 3))    for name, p in model.named_parameters():        q, deq = quantize(p.data)        err = ((p.data - deq).abs().mean() / p.data.abs().mean()).item()        print("quant err", name, round(err, 4))    with torch.no_grad():        out = model(dummy)        print("output shape:", list(out.shape))  if __name__ == "__main__":    main()
目的：一键完成 PyTorch→ONNX 导出、FP32/INT8 体积估算和权重量化误差模拟，体验转换链路的核心三步。
  1. torch.onnx.export(model, dummy, "tiny.onnx", opset_version=13)把网络结构和权重写成标准 ONNX 文件，opset 指定算子语法版本。
  2. n_params = sum(p.numel() for p in model.parameters())统计模型总参数量，作为体积计算的基数。
  3. print("int8 size(MB):", round(n_params * 1 / 1e6, 3))按每参数 1 字节估算 INT8 体积，对比 FP32 的 1/4 效果。
  4. scale = (weight.max() - weight.min()) / (qmax - qmin)计算量化缩放系数 s，即“一个整数档位代表多少浮点”。
  5. q = torch.round(weight / scale + zero).clamp(qmin, qmax)浮点权重映射成 INT8 整数，并截断到合法范围。
  6. deq = (q - zero) * scale反量化还原，用于计算量化误差，验证“一把盐”的代价有多大。

常见误区

误区我以为模型导出成 ONNX 之后就万事大吉，手机一定能跑，出问题就是手机太旧或者内存不够。

正解ONNX 只是“通用抄本”，目标引擎还要把里面的每个算子翻译成自己能执行的指令。ONNX 里包含的算子目标引擎未必认识；必须再做一次算子映射与兼容性检查，转换后还要在真机上验证。就像“标准排版”的菜谱，小厨房照样可能缺食材、缺厨具。

为何常见：因为 ONNX 是开放标准，容易误以为“标准 = 万能”，忽略了端侧引擎各自为政的实现差异。

误区量化把 FP32 变成 INT8 就像 zip 压缩，解压后数据一个比特都不差，模型效果不该有任何变化。

正解量化不是无损压缩，而是把 40 亿个浮点值硬塞进 256 个整数档位，必然引入信息损失，等价于“把精确到克改成一把盐”。模型精度通常会掉 0.5%~2%，要用 PTQ/QAT 和精度验证把损失控制在可接受范围。

为何常见：zip 压缩给了大家“压缩无色差”的直觉，误把有损量化类比成无损压缩；且部署工具常只宣传体积变小，不提精度代价。

误区我看 .pt 改成 .tflite 文件就变小了，以为转换就是换文件格式、改个后缀的事。

正解转换是对计算图的重写：算子逐个映射、常量折叠、算子融合、图优化、量化。后缀只是结果文件的标识，真正发生的是“菜谱从法文翻成中文并改成小厨房做法”的深度改写。

为何常见：文件扩展名给人“格式即内容”的错觉，看不到内部图结构的变化；图形界面拖拽转换也强化了“点一下就完事”的印象。

误区导出 ONNX 时我总把 opset_version 调到最新，认为版本新就代表功能强、兼容好。

正解opset 决定算子语法和特性版本。目标引擎往往只支持到某个 opset 区间，版本过高会让转换失败；应选“源框架导出能力 ∩ 目标引擎支持范围”的公共版本，并查阅引擎文档。

为何常见：软件版本“越新越好”的普遍心态；教程常只演示最新版本，忽略端侧工具的滞后性。

面试题

Q1. 模型转换最主要的目标是什么？

单选题 · easy

  • A.让模型适配目标端侧运行时← 正确答案
  • B.提升模型在云端的吞吐能力
  • C.把训练数据打包到手机本地
  • D.让多个框架共用同一份数据

答案：A。模型转换就像翻译菜谱，核心是让手机、门禁这类“小厨房”能看懂并执行模型。B 是云端优化目标，C 是数据隐私问题，D 是框架兼容问题，都不是转换的第一目的。

Q2. ONNX 在转换链路中扮演什么角色？

单选题 · easy

  • A.移动端的最终推理引擎
  • B.标准化的中间交换格式← 正确答案
  • C.训练模型的权重保存格式
  • D.量化后的模型压缩格式

答案：B。ONNX 是“通用抄本”——先去中心化地统一格式，再分发给 TFLite、NCNN 等引擎。它不是引擎本身，也不只是权重文件，更不是量化格式，而是中间表示。

Q3. FP32 模型转成 INT8 后，体积大约变为原来的多少？

单选题 · easy

  • A.缩小到原来的四分之一← 正确答案
  • B.模型体积完全保持不变
  • C.扩大到了原来的四倍
  • D.缩小为原来的八分之一

答案：A。FP32 每个参数 4 字节，INT8 每参数 1 字节，所以体积是原来的 1/4。这是量化最直观的收益，也是面试里最常见的送分题。

Q4. 把 BatchNorm 融合进卷积层，属于哪种算子处理方式？

单选题 · mid

  • A.线性映射到目标引擎算子
  • B.数学等价变换后合并算子← 正确答案
  • C.直接丢弃然后重构数据
  • D.保留原算子不做任何处理

答案：B。BN 推理时是线性变换，通过数学展开可以折叠进卷积权重，形成“调味爆炒”式融合算子。A 是普通映射，C、D 都会破坏网络结构或放弃优化收益。

Q5. 训练后量化（PTQ）与量化感知训练（QAT）的主要区别是什么？

单选题 · mid

  • A.PTQ 无需训练而 QAT 需重训← 正确答案
  • B.QAT 精度通常优于 PTQ 精度
  • C.PTQ 只能在云端 GPU 上执行
  • D.QAT 与 PTQ 的精度没有差别

答案：A。PTQ 是拿现成模型直接统计范围转 INT8，快但易掉点；QAT 在训练中就模拟量化误差，精度通常更好但要重训，所以 A 是核心区别，B 是结果并非定义。

Q6. onnx2ncnn 转换遇到不支持算子时，推荐的正确做法是？

单选题 · hard

  • A.用等价算子组合替换后重转← 正确答案
  • B.自动忽略该层并继续执行
  • C.直接修改源模型的权重
  • D.提交工单等待引擎更新

答案：A。遇到“本地买不到松露”，就换香菇——用等价算子组合改写网络，比如把 AdaptiveAvgPool 换成 GlobalAvgPool。忽略层会破坏模型，改权重不解决算子缺失，等更新不可控。

Q7. 量化公式 q = round(r/s) + z 中，零点偏移 z 的作用是什么？

单选题 · mid

  • A.让浮点零映射到整数零点← 正确答案
  • B.提高缩放系数的计算精度
  • C.控制量化位数的整体上限
  • D.消除所有非线性激活误差

答案：A。z 是浮点 0 在整数域的对齐偏移，避免 padding、ReLU 输出在量化后失真。它不改变缩放精度、不控制位数上限，也无法消除激活误差。

Q8. 模型转换完成后，必须验证哪些指标？

多选题 · mid

  • A.转换后的输出精度对比← 正确答案
  • B.端到端平均推理延迟← 正确答案
  • C.模型文件的体积变化← 正确答案
  • D.训练时数据集的增强方式

答案：ABC。转换闭环要回答“味道对不对、上菜快不快、分量足不足”，对应精度、延迟、体积。数据增强是训练阶段的事，与转换验证无关。

Q9. 以下哪些是模型转换失败的常见原因？

多选题 · hard

  • A.目标引擎缺少对应算子实现← 正确答案
  • B.动态尺寸未在导出时固定← 正确答案
  • C.训练轮次设置得不够多
  • D.中间格式版本之间不兼容← 正确答案

答案：ABD。算子缺失、动态维度、格式版本不兼容都是转换链路上的典型故障。训练轮次只影响原模型精度，不会让转换本身失败。

Q10. 关于量化，下列说法正确的有哪些？

多选题 · extreme

  • A.权重与激活均可量化处理← 正确答案
  • B.体积约缩至原始四分之一← 正确答案
  • C.量化后推理精度必然提升
  • D.零点用于对齐浮点零值← 正确答案

答案：ABD。量化不仅压权重，激活张量也会量化以提速省电；INT8 体积是 FP32 的 1/4；零点 z 专门对齐浮点 0。C 说反了——量化是有损过程，精度可能下降而非必然提升。