原文はこちら。
https://blogs.oracle.com/developers/introducing-graphpipe
第一に、モデルを提供するAPIに標準がないため、フレームワークで提供されるもので悩まされる可能性があります。これは、Protocol Buffersかもしれませんし、カスタムのJSONかもしれません。あなたのビジネスアプリケーションは、デプロイされたモデルと話すためだけに、特注のクライアントを必要とすることが一般的です。複数のフレームワークを使用している場合はさらに事態が悪化します。複数のフレームワークからモデルのアンサンブルを作成したい場合は、組み合わせるためのカスタムコードを記述する必要があります。
第二に、モデルサーバーの構築は非常に複雑です。デプロイはトレーニングほど注意を払う必要がないため、すぐに使えるソリューションはほとんどありません。例えば、TensorFlow ServingのGPUバージョンを構築してみてください。頭を数日間打ちつける準備をしておくべきでしょう。
最後に、既存のソリューションの多くはパフォーマンスに重点を置いていないため、特定のユースケースではパフォーマンスが不足します。Python-JSON APIを使えば複雑なモデルからtensorデータの束を取得できますが、パフォーマンスが重要なアプリケーションのためにそのデータの束をカットしてはくれません。
この3つの課題を解決するためにGraphPipeを作成しました。ネットワーク経由でtensorデータを送信するための標準的な高性能プロトコルと、あらゆるフレームワークの機械学習モデルを簡単にデプロイおよび照会するクライアントおよびサーバーの簡単な実装を提供します。GraphPipeの効率的なサーバーは、TensorFlow、PyTorch、MXNet、Microsoft Cognitive Toolkit (CNTK)、またはCaffe2で構築されたモデルに対応できます。
モデルが顧客が目にするモバイルアプリケーションやIoTアプリケーションに現れ始めると、悪化する一方です。多くのデバイスはモデルをローカルで実行できるほどの能力はないため、リモートサービスに要求する必要があります。このリモートサービスは、さまざまな機械学習フレームワークのモデルを実行しながら、効率的で安定していなければなりません。
標準があれば、研究者はお望みのツールを使って最良のモデルを構築し、特別なクライアントを使わなくてもユーザーはモデルの予測にアクセスできます。モデルを複数のサーバーにデプロイでき、共通のプロトコルを使ってより大きなアンサンブルに簡単に集約できます。GraphPipeは、ビジネスが機械学習の投資から価値を引き出すために必要なツールを提供します。
GraphPipeは以下のものを包含しています。
![]()
Flatbuffersではメモリコピーなしで基礎となるデータへアクセス可能なので、GraphPipeはデシリアライズ時の性能が特に顕著です。
次に、Python-JSON TensorFlowモデルサーバー、TensorFlow Serving、およびGraphPipe-Go TensorFlowモデルサーバーを使用して、エンドツーエンドのスループットを比較します。いずれの場合も、バックエンドモデルは同じです。に大きなリクエストを1個のスレッドを使用するサーバ、5個のスレッドを使用するサーバに投げています。縦軸の単位は、モデルによって計算された1秒あたりの行です。
![]()
このテストでは、Tensorflow Serving構築の推奨パラメータを使用していることにご注目ください。TensorFlow Servingの推奨ビルド・パラメータではあまり性能が出ませんが、最終的にはGraphPipe実装と同等のパフォーマンスを実現できるコンパイルパラメータを導き出すことができました。言い換えれば、最適化されたTensorFlow ServingはGraphPipeと同様のパフォーマンスを発揮しますが、TensorFlow Servingを最適に実行するためのビルド方法は文書化されておらず、そのビルドも容易ではありません。
https://blogs.oracle.com/developers/introducing-graphpipe
Dead Simple Machine Learning Model Serving
ここ数年で機械学習は急速に進歩し、今日ではどれか一つのフレームワークを使って、オンラインチュートリアルに従い、動作する機械学習モデルを数時間で作成できるようになりました。しかし残念なことに、そのモデルを本番環境に展開する準備ができたとしても、まだ固有の課題に直面します。第一に、モデルを提供するAPIに標準がないため、フレームワークで提供されるもので悩まされる可能性があります。これは、Protocol Buffersかもしれませんし、カスタムのJSONかもしれません。あなたのビジネスアプリケーションは、デプロイされたモデルと話すためだけに、特注のクライアントを必要とすることが一般的です。複数のフレームワークを使用している場合はさらに事態が悪化します。複数のフレームワークからモデルのアンサンブルを作成したい場合は、組み合わせるためのカスタムコードを記述する必要があります。
第二に、モデルサーバーの構築は非常に複雑です。デプロイはトレーニングほど注意を払う必要がないため、すぐに使えるソリューションはほとんどありません。例えば、TensorFlow ServingのGPUバージョンを構築してみてください。頭を数日間打ちつける準備をしておくべきでしょう。
最後に、既存のソリューションの多くはパフォーマンスに重点を置いていないため、特定のユースケースではパフォーマンスが不足します。Python-JSON APIを使えば複雑なモデルからtensorデータの束を取得できますが、パフォーマンスが重要なアプリケーションのためにそのデータの束をカットしてはくれません。
この3つの課題を解決するためにGraphPipeを作成しました。ネットワーク経由でtensorデータを送信するための標準的な高性能プロトコルと、あらゆるフレームワークの機械学習モデルを簡単にデプロイおよび照会するクライアントおよびサーバーの簡単な実装を提供します。GraphPipeの効率的なサーバーは、TensorFlow、PyTorch、MXNet、Microsoft Cognitive Toolkit (CNTK)、またはCaffe2で構築されたモデルに対応できます。
TensorFlowGraphPipeがOracleのGitHubからご利用いただけるようになったことを発表できうれしく思っています。ドキュメンテーション、サンプル、その他の関連コンテンツは、以下にあります。
https://www.tensorflow.org/
PyTorch
https://pytorch.org/
MXNet: A Scalable Deep Learning Framework
http://mxnet.ai/
Microsoft Cognitive Toolkit (CNTK)
https://www.microsoft.com/en-us/cognitive-toolkit/
Caffe2 - A New Lightweight, Modular, and Scalable Deep Learning Framework
https://caffe2.ai/
GraphPipe -- Dead Simple ML Model Serving via a Standard Protocol
https://oracle.github.io/graphpipe
The Business Case
企業組織では、機械学習モデルは個別に訓練され、特注の技術を使用して導入されることがよくありますが、これは機械学習の取り組みから価値を引き出す組織の能力に影響を与えます。ファイナンスグループが作成したモデルをマーケティンググループが使用したい場合、モデルと対話するカスタムクライアントを作成する必要があります。モデルに人気が出て営業グループも利用したいと思った場合、カスタムクライアントが負荷に耐えられない可能性があります。モデルが顧客が目にするモバイルアプリケーションやIoTアプリケーションに現れ始めると、悪化する一方です。多くのデバイスはモデルをローカルで実行できるほどの能力はないため、リモートサービスに要求する必要があります。このリモートサービスは、さまざまな機械学習フレームワークのモデルを実行しながら、効率的で安定していなければなりません。
標準があれば、研究者はお望みのツールを使って最良のモデルを構築し、特別なクライアントを使わなくてもユーザーはモデルの予測にアクセスできます。モデルを複数のサーバーにデプロイでき、共通のプロトコルを使ってより大きなアンサンブルに簡単に集約できます。GraphPipeは、ビジネスが機械学習の投資から価値を引き出すために必要なツールを提供します。
Implementation Details
GraphPipeは、リモートプロセス間の機械学習データの送信を簡素化し、標準化するために設計された効率的なネットワークプロトコルです。現在、深層学習アーキテクチャのコンポーネント間でtensorのようなデータの伝送方法に対する支配的な標準は存在しません。そのため、開発者にとっては、非常に非効率なJSONや、大規模で複雑なソフトウェアであるTensorFlowに付いてくるTensorFlow ServingのProtocol Buffersのようなプロトコルを使うことが一般的です。GraphPipeは、効率のよいバイナリのメモリマップフォーマットでありながら、シンプルかつ依存関係を少なくするように設計されています。GraphPipeは以下のものを包含しています。
- FlatBuffers定義のセット
- FlatBuffers定義に従って一貫してモデルを提供するためのガイドライン
- TensorFlow、ONNX、およびCaffe2からモデルを提供するサンプル
ONNX
https://onnx.ai/ - GraphPipeを使って提供されるモデルを照会するためのクライアントライブラリ
Performance
まず、カスタムujson APIを使うPython、TensorFlow Servingの予測リクエストを使用するProtocol Buffers、およびGraphPipeリモートリクエストでの、浮動小数点tensorデータのシリアライズ、デシリアライズの速度を比較します。リクエストは約1,900万の浮動小数点値（128個の224x224x3イメージで構成）で構成され、レスポンスは約320万の浮動小数点値（128の7x7x512畳み込み出力で構成）です。 縦軸の単位は秒です。
Flatbuffersではメモリコピーなしで基礎となるデータへアクセス可能なので、GraphPipeはデシリアライズ時の性能が特に顕著です。
次に、Python-JSON TensorFlowモデルサーバー、TensorFlow Serving、およびGraphPipe-Go TensorFlowモデルサーバーを使用して、エンドツーエンドのスループットを比較します。いずれの場合も、バックエンドモデルは同じです。に大きなリクエストを1個のスレッドを使用するサーバ、5個のスレッドを使用するサーバに投げています。縦軸の単位は、モデルによって計算された1秒あたりの行です。
このテストでは、Tensorflow Serving構築の推奨パラメータを使用していることにご注目ください。TensorFlow Servingの推奨ビルド・パラメータではあまり性能が出ませんが、最終的にはGraphPipe実装と同等のパフォーマンスを実現できるコンパイルパラメータを導き出すことができました。言い換えれば、最適化されたTensorFlow ServingはGraphPipeと同様のパフォーマンスを発揮しますが、TensorFlow Servingを最適に実行するためのビルド方法は文書化されておらず、そのビルドも容易ではありません。
Where Do I Get it?
ドキュメントやサンプルは以下の場所にたくさんあります。GraphPipe -- Dead Simple ML Model Serving via a Standard ProtocolGraphPipeのFlatBuffersの仕様はPythonやGoの仕様を実装するサーバと共にGitHub上にあります。
https://oracle.github.io/graphpipe
GraphPipe - Dead Simple ML Model Serving via a Standard ProtocolPython、Go、Java（これはまもなくリリース予定）のクライアント、ローカルのTensorFlowグラフの中にリモートモデルを含めることができるTensorFlowプラグインも提供します。
https://github.com/oracle/graphpipe
GraphPipe for python
https://github.com/oracle/graphpipe-py
GraphPipe for Go
https://github.com/oracle/graphpipe-go
GraphPipe for Java （2018/08/16現在リンクはまだ有効ではありません）
https://github.com/oracle/graphpipe-java
GraphPipe helpers for TensorFlow
https://github.com/oracle/graphpipe-tf-py