在机器学习和深度学习的世界里，经常面临一个问题：当试图解决一个问题时，很可能已经有人训练了一个神经网络来解决它。如果有人已经花费了时间和金钱来训练一个模型，为什么还要重新发明轮子呢？
像ONNX模型动物园这样的资源库使得找到下一个顶级模型变得容易。但如果发现一个模型不是想要的格式怎么办？真正需要的是便携式神经网络——这正是ONNX格式所提供的。本系列文章将探讨如何将常见的AI模型格式转换为ONNX格式，然后在应用程序中使用它们。阅读完本系列文章后，将完全理解如何在2020年使用便携式神经网络。
要理解ONNX及其提供的价值，首先必须理解它解决的问题。如果曾经尝试过机器学习算法并创建了一个只有自己使用的模型（从创建模型的同一个项目中），那么还没有遇到机器学习问题。另一方面，如果有当前项目的DevOps责任，并且需要将数据科学团队创建的模型投入生产，那么就已经遇到了机器学习问题。
机器学习问题是由于今天模型必须使用创建模型时使用的语言和框架来提供服务这一事实造成的。例如，当使用Python和Keras创建一个神经网络，并且准备将该模型部署到生产环境中时，运行模型的服务将需要用Python编写，并且需要在生产环境中安装Python和Keras。
在微服务环境中，这听起来可能不是什么大问题——创建一个包含Python和Keras的镜像，将镜像部署到容器中，并通过RESTful API提供预测。然而，也许团队中没有Python专家，或者也许工程工作流程针对一种语言进行了优化，并没有为Python设置很多质量门（静态代码分析、单元测试、端到端测试和安全扫描）。这两种情况在已经标准化为C#或Java的大型企业中非常常见。让不熟悉Python或Keras的工程师部署和维护提供预测的服务并不理想。此外，没有所有适当的质量检查部署服务只会在整个应用程序中引入故障。
理想的解决方案是有一个通用的模型格式，允许所有类型的模型——传统的机器学习模型以及神经网络——从任何语言中使用。
机器学习问题不仅仅是因为缺乏模型在语言之间的互操作性。无论是批处理模式还是实时模式提供模型都可能是计算密集型的。
理想的解决方案是有一个运行时，它可以从每种编程语言访问，并能够以优化底层硬件的方式提供模型。
本文是关于ONNX的七篇文章系列中的第一篇，将探讨ONNX相对于三个流行的框架和三种流行的编程语言的价值。接下来的三篇文章将涵盖从三个流行的神经网络构建框架创建ONNX模型。由于ONNX不提供训练模型的功能，将为每个框架提供一个简短的概述，以便可以选择最适合训练模型的框架。每个框架都需要安装不同的包才能转换为ONNX。这将为每个框架进行介绍。最后，在从每个框架导出模型时，有一些独特的陷阱需要注意。