TF和PyTorch都不够好！甲骨文开源GraphPipe机器学习

机器学习虽然在过去几年取得了重大进展，也出现了很多相关的框架，但因为缺乏事实上的标准，在重用和整合机器学习模型时通常涉及大量的定制化工作，而且在性能方面也存在不足。

虽然在过去几年取得了重大进展，也出现了很多相关的框架，但因为缺乏事实上的标准，在重用和整合机器学习模型时通常涉及大量的定制化工作，而且在性能方面也存在不足。甲骨文开源的 GraphPipe 旨在解决这些问题，让机器学习变得更加简单，使企业更容易从任何框架部署和查询机器学习模型。

GraphPipe：超级简单的机器学习模型服务

在过去几年中，机器学习取得了快速进展。现如今，你可以从众多框架中挑出一个，根据一些在线教程在几个小时之内就能得到一个机器学习模型。然而，当你准备将该模型部署到生产环境中时，仍然需要面临几个独特的挑战。

首先，现在还没有出现与模型服务 API 相关的标准，因此你很可能会卡在框架为你提供的某些东西上，比如 protobuf 或自定义 JSON。你的业务应用通常需要使用定制的客户端才能与部署好的模型进行通信。如果你使用了多个框架，那就更糟了。如果要使用多个框架创建模型集合，则必须编写自定义代码来组合它们。

其次，自己构建模型服务器可能会非常复杂。人们对模型部署的关注远远少于模型训练，因此开箱即用的解决方案非常罕见。例如，如果你要尝试构建 GPU 版本 TensorFlow 服务，那么等待你的将是痛苦不堪的日子。

最后，很多现有的解决方案并不关注性能，因此对于某些场景而言，它们存在不足。通过 python-JSON API 从复杂的模型中获取一堆张量数据并不能解决性能关键型应用的性能问题。

为此，我们创建了 GraphPipe 来解决这三个挑战。GraphPipe 提供了一种标准的高性能协议，用于通过网络传输张量数据，以及简单的客户端和服务器实现，让机器学习模型的部署和查询都变得轻而易举。GraphPipe 的服务器可以为 TensorFlow、PyTorch、mxnet、CNTK 或 caffe2 的内置模型提供服务。我们很高兴地宣布，GraphPipe 已经发布在 Oracle 的 GitHub 代码库中。用户可以在 https://oracle.github.io/graphpipe 上找到文档、示例和其他相关内容。

使用 GraphPipe 前后对比

在调查机器学习模型服务的现状时，我们发现：

模型服务网络协议与底层模型实现相关联。例如，如果你有一个 Tensorflow 模型，就需要使用 Tensorflow 的 protobuf 服务器来执行远程推理。
另一方面，Pytorch 和 Caffe2 并没有提供有效的模型服务器，而是依靠 mxnet-model-server 等工具进行远程推理。mxnet-model-server 是用 python 开发的，它提供了一个部支持批处理的 JSON API。虽然这对于简单的场景很管用，但并不适用于后端的基础设施。
ONNX 通过标准化模型格式而不是协议格式来解决供应商耦合问题。这很管用，但极具挑战性，因为并非所有后端模型格式都具有完全等效的操作。这意味着简单的转换并不总是有效的，有时候甚至需要重写整个模型。
对于希望精心维护基础设施的运营商而言，无论模型怎样实现，为客户端与机器学习模型之间的通信制定标准方法都很重要。

换句话说，没有 GraphPipe 服务模型的日子不好过：

我们发布的代码提供了：

基于 flatbuffer 的极简主义机器学习传输规范；
适用于 Tensorflow、Caffe2 和 ONNX 的简单高效的参考模型服务器。
高效的 Go 语言、Python 和 Java 客户端实现。

使用这些工具，通信得以简化，服务变得更加简单：

商业案例

在企业中，机器学习模型通常是单独训练并使用定制技术进行部署，这会影响企业从机器学习中获取价值的能力。如果市场部门想要使用财务部门生成的模型，他们将不得不编写自定义客户端来与模型进行交互。如果这些模型变得越来越受欢迎，比如销售部门也想使用它们，那么自定义部署可能会因为负载过大而崩溃。

当模型开始出现在面向客户的移动和物联网应用中时，情况会变得更加糟糕。很多设备的配置不足以在本地运行模型，必须向远程服务发出请求。远程服务在基于各种机器学习框架运行模型时必须确保高效和稳定。

通过制定标准可以让研究人员使用他们想要的任何工具来构建最佳的模型，并确保用户可以在不需要编写定制代码的情况下访问模型。模型可以跨多个服务器部署，并通过通用协议形成更大的集群。GraphPipe 为企业提供了这些工具，帮助他们从机器学习的投资中获取价值。

实现细节

GraphPipe 是一种高效的网络协议，旨在简化和标准化远程进程之间的机器学习数据传输。目前，在深度学习架构中，对于如何在组件之间传输张量数据并没有主导的标准。因此，开发人员通常使用非常低效的 JSON 协议，或 TensorFlow 服务的 protobuf，但它背着 TensorFlow 的沉重包袱，因为 TensorFlow 是一个庞大而复杂的软件。GraphPipe 致力于提高二进制内存映射格式的效率，同时保持对外部只有简单和轻量级的依赖。

GraphPipe 提供了：

一组 flatbuffer 定义；
让模型与 flatbuffer 定义保持一致的指南；
从 TensorFlow、ONNX 和 caffe2 服务模型的示例；
用于查询模型的客户端库。

本质上，GraphPipe 请求类似于 TensorFlow 服务的预测请求，只是使用 flatbuffer 作为消息格式。flatbuffer 类似于谷歌的 protobuf，只是它在反序列化期间会避免内存复制。flatbuffer 定义的请求消息中包含了输入张量、输入名称和输出名称。GraphPipe 远程模型接收请求消息，并为每个请求的输出名称返回一个张量。远程模型还必须提供有关输入和输出的类型和结构的元数据。

性能评估

首先，我们对 Python、protobuf 和 GraphPipe 在浮点数张量数据的序列化和反序列化方面的速度进行比较，其中 Python 使用了自定义的 ujson API，protobuf 使用了 TensorFlow 服务的预测请求，GraphPipe 使用了远程请求。请求中包含了大约 1900 万个浮点值（由 128 个 224x224x3 的图像组成），响应中包含大约 320 万个浮点值（由 128 个 7x7x512 卷积输出组成）。左边的单位为秒。

Graphpipe 在反序列化方面表现突出，因为 flatbuffer 可以在不进行内存拷贝的情况下访问底层数据。

其次，我们使用 Python-JSON TensorFlow 模型服务器、TensorFlow 服务和 GraphPipe-go TensorFlow 模型服务器来比较端到端的吞吐量。对于每种情况，后端模型都是相同的。先是使用 1 个线程向服务器发出大量请求，然后再使用 5 个线程发出请求。左侧的单位是模型每秒计算的行数。

请注意，这个测试使用了推荐的参数来构建 Tensorflow 服务。尽管 TensorFlow 服务的推荐构建参数表现不佳，但我们最后发现可以使用编译参数来达到可与 GraphPipe 相媲美的性能。换句话说，经过优化的 TensorFlow 服务与 GraphPipe 的性能类似，但通过优化 TensorFlow 服务以达到最佳性能并未成为通用的实践，而且也并不容易实现。

如何使用 GraphPipe？

你可以在 https://oracle.github.io/graphpipe 找到大量文档和示例。你还可以在 Oracle 的 Github 目录下找到 GraphPipe flatbuffer 的规范，以及用 Python 和 Go 实现的服务器。我们还提供基于 Python、Go 和 Jave（开发中）实现的客户端，以及允许在本地 TensorFlow 图中包含远程模型的 TensorFlow 插件。