TensorFlow Serving 1.0リリースの詳細がGoogle I/Oで公開

Googleは先月のGoogle I/O 2017で、TensorFlow Servingの最初のメジャーリリースを発表した。Noah Fiedel氏がいくつかの新機能と、今後のプロジェクトのビジョンに関する洞察を詳しく説明している。

TF Serving 1.0にはいくつかのバッチオプション、ライフサイクル管理のためのモデルマネージャ、複数のモデルバージョンの並列実行、サブタスクのサポート、プラグイン可能で呼び出し可能なモデルストレージのためのデータソース定義の標準化などが含まれている。

Fiedel氏の講演の背景にあるものは、特に移植性や再現性、弾力性などの重要な非機能要件において、ソフトウェアエンジニアリングの最先端に比べていまだ10～20年の遅れがあるのみならず、時に漠然としているデータ科学とデータエンジニアリングの世界である。しかしモデルの再現性と移植性、構成やメタデータなどは現在も標準化の途上にあるため、ソフトウェアエンジニアリングに登場したベストプラクティスのいくつかについては、マシンラーニングのユビキタスな業界標準には至っていないのが実情だ。

TensorFlow Servingはこれらの課題に対処するとともに、将来的にはそのコアプログラミングモデルとプラットフォームの一部として標準化を提供することが期待されている。

Fiedel氏が示したTensorFlowコミュニティにおける大きな課題のひとつが、ディスク外へのモデルの移動とサービスからの呼び出しの実現であり、再現可能なパイプラインの一環としてそれを行なうことだ。TF Servingを使用することで、複数バージョンのモデルの同時実行が実現し、スタンドアロンのCI/CDツーリングを別途用意しなくても、変更内容の取り消しが可能になる。

TensorFlow Serving 1.0はTensorFlowの全リリースのマイナーバージョンの基準になるリリースで、debianのパッケージとして管理され、apt-get経由で提供される予定だ。

TensorFlow Servingには３つの主要コンポーネントがある。まず最初に、標準的なsave-and-exportフォーマットでのTensorFlowモデルのセーブとロードをサポートする、C++ライブラリのセットがある。第２のコンポーネントは、他のMLプラットフォームとの高水準な相互運用性を提供する汎用的な設定駆動型コアプラットフォームだが、詳細は説明されていない。コアプラットフォームパッケージには、最も妥当と思われる(best-guess)デフォルト設定と実績のあるプラクティス、さらにホストサービスを含んだ、実行可能なバイナリが同梱されている。そして最後が、Cloud MLを通じて提供される商用オプションだ。

コアプラットフォームで重視されたのは、低レイテンシの要求および応答時間と共に、コンピューティング時間の配分の最適化である。TF Servingはミニバッチ処理を実装することにより、GPU/TPU用別々のスレッドプールとCPUバウンドタスクを使用して、ラウンドトリップ呼び出しの低減と、より効率的なリソース割り当てを実現している。

ライブラリは、リード・コピー・アップデートパターンの利用、サーバ起動時のモデルローディングの高速化、さらには特定の時間においてモデルが実行されているグラフ上の位置を追跡可能にするための、参照カウンタ付きポインタによるポインタのフォールトトレランス性の提供などによって、ハイパフォーマンス用に最適化されている。

モデルローディングと推論サービスは、別々のスレッドプールを通じて非ブロッキング処理される。キューを備えたミニバッチ処理は、TF Servingの重要なコンセプトだ。非同期要求は一括してミニバッチ処理された上で、単一のTF Sessionに投入され、Managerがプロセス要求をコーディネートする。推論要求もまた、レイテンシ低減のためにミニバッチ処理される。要求の処理は、クライアント要求を特定するポインタであるServableHandleを使って実装されている。

新たにSavedModel形式が導入されたのに伴って、SessionBundleモデル形式は廃止された。TF Serving 1.0では、トレーニングされたモデルを実行可能なプロセッサアーキテクチャに関する情報を保持する、MetaGraphの概念が導入されている。MetaGraphにはモデルのボキャブラリ、エンベッデイング、トレーニングウェイトなどのパラメータが格納される。SavedModelオブジェクトはMetaGraphで構成され、移植および呼び出しの可能なアーティファクトとして設計されている。SavedModelによる抽象化は、トレーニングやサービス、オフライン評価に使用可能で、新たに用意されたコマンドラインインターフェースによって実行できる。SignatureDefはSavedModelのコンポーネントで、グラフ内のレイヤに注釈ないし特性を付加するために使用される。

データのSourceライブラリにはAPIが、モデル形式にはSourceAdapterが用意されている。SourceモジュールはSavedModel用にローダを生成し、必要なRAM容量を推測する。ソースAPIは、モデルからデータをロードするManagerモジュールにメタデータを送信する。一般的なコードパターンをインジェクションに使用する設定ファイルにカプセル化することによって、新しいServerCoreでは、定型的なコード行(LOC)を300程度から100まで削減した、とFiedel氏は説明している。

新しくなった推論APIでは、一般的なユースケース用に、再利用可能なコンポーネントがいくつか提供されている。 設定とサービスを予測するPredict、回帰モデル用のRegress、分類アルゴリズムのClassify、RegressとClassify APIを組み合わせたMulti-inferenceなどがある。

推論のマルチスレッド化もサポートされた。マルチスレッド推論は、コンカレントな同一要求の存在への対処を試みるマシンラーニングにおいて喫緊の研究課題であると同時に、不正確ないし反復的な要求と認識されるものを除去することにより、ミニバッチの効率向上に利用できる可能性もある。大量で処理時間を要する入力ボリュームを生成する不正確なアクティビティ要因に対する回復力は、リソース消費とデータ品質に対する負のカスケード効果の防止に有効だ。

Googleでは、デフォルト設定でgRPC機能を利用したいGCPユーザ用に調整された、静的バイナリの使用を推奨している。その他にDockerイメージと、使用を始めるためのK8チュートリアルも用意されている。