模型交付的三道关：导出、三端验证与加密授权

把一个训练好的模型交给客户跑起来，中间隔着三道关。跳过任何一道，都会在客户现场连本带利地还回来。

训练完成只是半成品

训练产出的是框架私有的权重文件：它依赖训练时的框架版本、模型定义代码与预处理逻辑。客户的系统是另一个世界：可能是 Go 写的流媒体服务、Java 的业务后端、安卓的端上 App。从"我的环境里能跑"到"你的环境里也能跑出一样 results"，中间就是这三道关。

第一道关：导出

导出是把权重固化为通用格式：ONNX 适配 Go/Java/Android 等通过 ONNX Runtime 推理的环境，TorchScript 供 Python 系统以 torch.jit.load 直载。三个必须盯住的细节：

• 固定输入尺寸：端侧消费方大多不支持动态尺寸，导出即锁定（如 1×3×64×64 或 1×3×640×640），并写进元数据；
• 输出形态契约：分类模型输出 logits 还是 softmax 概率？类别顺序如何排列？必须与消费方白纸黑字约定并写入 meta，口头约定等于没有约定；
• 工具链版本锁定：训练与导出使用同一版本的工具链（我们锁定 ultralytics==8.3.253），不同版本的算子行为差异会导致"同一份权重、两种输出"。

一个真实教训：某次导出把 softmax 固化进了 TorchScript，而消费方按契约再调一次 softmax，等于概率被"压缩两次"，全部样本的判别方向失真。这类错误靠肉眼看不出来的，靠的是下一道关。

第二道关：三端一致性验证

做法：准备一批验证图片，Python 侧先跑出基准输出；再把模型与同样的图喂给 Go 推理端与 Java 推理端，逐张、逐个输出值对比。全部一致，模型才被标记为可发布；任何一张图不一致，交付流程终止、回头排查。验证报告（每张图的对比结果、MD5、环境版本）随交付包一起给客户。这道关把"训练与线上预处理不一致""导出算子行为差异""输出契约违背"三类问题全部拦在出厂前。它不能提升模型精度，但它保证客户拿到的模型和你在验证集上测的是同一个模型。

第三道关：加密与授权

明文权重文件等于可以随意转发的资产。我们的交付形态：模型文件经 AES-256-GCM 加密为交付包；客户持有的 License Key 通过 HKDF 派生解密密钥，运行时内存解密加载、权重不落盘；License 绑定有效期，可吊销、有下载计数。文件被拷走，没有 Key 也无法使用；授权到期，模型自然停用。对"把模型当商品卖"的商业模式来说，这道关是商业闭环本身。

交付报告里有什么

• 模型元数据：类别表及顺序、输入尺寸与预处理契约、输出形态；
• 验证集精度指标与三端一致性对比结果（逐张）；
• 交付包 MD5 与 SHA256、导出环境版本；
• License 信息：绑定对象、有效期、吊销方式。

交付前检查清单

1. 输入/输出契约与消费方书面确认？
2. 三端一致性验证全部通过？
3. 验证集指标达标（而不仅是训练指标）？
4. 交付包加密 + License 签发完成？
5. 版本号与 MD5 已登记，可追溯？

延伸阅读：TorchScript 与 ONNX 怎么选、License 授权体系详解。