一个真实的噩梦

2025年，一家中型AI公司做了一个决定：把模型从PyTorch迁移到TensorFlow，因为他们的推理平台只支持TensorFlow。他们以为这是"几周的工作"。

结果呢？三个月后，迁移仍然没有完成。模型精度下降了2.3个百分点，某些边缘情况的行为完全不一致。最终，他们放弃迁移，转而重写推理平台来支持PyTorch。

这是一个价值200万美元的教训。

AI模型的"巴别塔"

AI模型格式的碎片化已经到了令人发指的程度。以下是2026年主流的模型格式：

  • PyTorch (.pt, .pth)：研究社区的标准格式
  • TensorFlow (.pb, SavedModel)：工业部署的主流格式
  • ONNX (.onnx)：跨框架的中间表示格式
  • Core ML (.mlmodel)：苹果生态的格式
  • TensorRT (.engine)：NVIDIA推理优化的格式
  • OpenVINO (.xml + .bin)：Intel推理优化的格式
  • GGUF (.gguf)：llama.cpp的量化格式
  • SafeTensors (.safetensors)：HuggingFace的安全格式

每一种格式都有自己的算子支持范围、精度特性和优化策略。当一个模型从PyTorch转换为ONNX，再转换为TensorRT，每一步都可能丢失精度、引入bug或产生不支持的算子。

ONNX：跨框架互操作的希望？

ONNX（Open Neural Network Exchange）是解决互操作性问题的最有希望的尝试。它的目标是成为AI模型的"通用语言"——你可以在PyTorch中训练，导出为ONNX，然后在任何支持ONNX的推理引擎上运行。

但ONNX的理想和现实之间有差距：

问题一：算子覆盖不完整。 当你使用了一个PyTorch中独有的算子（比如某个自定义的attention实现），ONNX导出器可能不支持，导致导出失败或产生不正确的行为。

问题二：版本兼容性。 ONNX的算子集（opset）在不断更新。你用opset 18导出的模型，在一个只支持opset 15的推理引擎上可能跑不通。

问题三：调试困难。 当ONNX模型的行为与原始模型不一致时，定位问题极其困难。你需要在多个层之间对比数值，而且错误往往是累积性的。

实测数据： 我们测试了50个HuggingFace上的模型转换为ONNX。结果：42个成功转换，其中11个在转换后精度下降了超过1%。8个完全无法转换。

正在兴起的互操作性标准

除了ONNX，行业也在探索其他路径：

MLIR（Multi-Level Intermediate Representation）： LLVM生态中的多级中间表示，Google和多家公司正在推动将其作为AI编译器的统一IR。相比ONNX，MLIR更加灵活，支持自定义算子，但复杂度也更高。

WebNN： W3C正在制定的Web神经网络API标准，旨在让AI模型在浏览器中跨平台运行。对于Web端的AI应用，这是一个值得关注的标准。

IREE： Google推出的基于MLIR的端到端编译器，目标是将AI模型编译到各种硬件平台上。

中国在做什么？

中国在AI互操作性标准方面也在积极布局。2024年，中国信通院发布了《人工智能框架互操作性》系列标准，旨在解决国产AI框架（如PaddlePaddle、MindSpore）与主流框架之间的互操作问题。这是系统性解决AI模型碎片化的重要尝试。

工程实践建议

在互操作性标准成熟之前，你可以采取以下策略：

  1. 从项目初期就考虑部署格式。 不要等到训练完成后再想怎么部署。
  2. 限制算子使用范围。 尽量使用ONNX支持的算子，避免使用框架特有的高级API。
  3. 建立模型转换测试流水线。 每次转换后自动运行精度测试，对比转换前后的输出。
  4. 考虑使用SafeTensors。 至少它的格式是开放的、安全的，不会执行任意代码。

写在最后

AI互操作性的问题本质上不是技术问题，而是生态问题。每个框架都有自己的护城河——锁定用户的最好方式就是让他们很难迁移。只有当行业形成共识，AI互操作性标准才能真正落地。在这之前，每一个AI工程师都需要学会在碎片化的格式丛林中生存。

你在模型迁移中遇到过哪些坑？欢迎在评论区分享。