トレーニングした機械学習モデルをクラウドでホストし、AI Platform Prediction を使用して新しいデータのターゲット値を推定できます。このページでは、モデルのホスティングと予測について説明し、プロジェクトで留意すべき考慮事項を紹介します。
仕組み
AI Platform Prediction では、クラウド内のコンピューティング リソースを管理してモデルを実行します。ユーザーはモデルからの予測をリクエストして、予測されたターゲット値を取得できます。クラウドで予測を行うための準備プロセスを次に示します。
AI Platform Prediction にデプロイ可能なアーティファクトとしてモデルをエクスポートします。
AI Platform でモデルリソースを作成し、保存したモデルからモデル バージョンを作成します。
カスタム予測ルーチンをデプロイする場合は、予測時に実行するコードも指定します。
予測に使用する入力データをフォーマットし、オンライン予測またはバッチ予測をリクエストします。
オンライン予測を使用する場合、予測サービスは保存済みモデルを実行し、リクエストされた予測を呼び出しのレスポンス メッセージとして返します。
- モデル バージョンは、モデルの作成時に指定したリージョンにデプロイされています。
- 一般に、定期的に使用するモデル バージョンで予測が行われるよう準備されていますが、常にそうなる保証はありません。
バッチ予測は TensorFlow モデルでのみサポートされます。バッチ予測を使用する場合のプロセスはもう少し複雑になります。
予測サービスは、ジョブを実行するためのリソースを割り当てます。これには、1 つ以上の予測ノードが含まれます。
サービスは、割り当てた各ノードで TensorFlow グラフを復元します。
予測サービスは、割り当てたノード全体に入力データを分散します。
各ノードはグラフを実行し、指定された Cloud Storage の場所に予測を保存します。
すべての入力データが処理されると、予測サービスはジョブをシャットダウンし、割り当てていたリソースを解放します。
モデルのデプロイ
AI Platform Prediction でモデルをホストすれば、クラウド内のモデルから予測を取得できます。保存したモデルをホスティングするプロセスをデプロイといいます。予測サービスでは、モデルを大規模に実行するために必要なインフラストラクチャを管理し、オンラインおよびバッチ予測リクエストにそれを使用できるようにします。このセクションでは、モデルのデプロイについて説明します。
モデルとバージョンについて
AI Platform Prediction は、「モデル」と「バージョン」と呼ばれるリソースを使用して、トレーニング済みのモデルを編成します。モデルとは、機械学習ソリューションのことです。たとえば、米国の国勢調査の機械学習モデルに関するすべての作業を含めるには、census というモデルを作成します。census という名前で作成するエンティティは、機械学習モデルを実際に実装するコンテナで、バージョンと呼ばれます。
機械学習モデルの開発は反復的なプロセスです。そのため、AI Platform Prediction のリソース パラダイムは、各機械学習モデルの複数のバージョンが作成されることを前提に設定されています。この「モデル」と「バージョン」という用語が混乱を招くことがありますが、AI Platform Prediction のモデルリソースは、それ自体が機械学習モデルなのではありません。AI Platform Prediction では、モデルとは機械学習モデルの複数のバージョンを格納するコンテナを指します。
バージョンには何が含まれるか
AI Platform Prediction にモデル バージョンとしてデプロイする「モデル」は、ホストされたフレームワーク、TensorFlow、scikit-learn、XGBoost のいずれかを使用したトレーニングで作成された 1 つ以上のアーティファクトで構成されています。クラウドで AI Platform Training を使用したトレーニング、または他の場所のトレーニングのいずれでもかまいません。
また、カスタム予測ルーチンをデプロイして、予測リクエストを処理するための追加のトレーニング アーティファクトとコードとともに、モデル バージョンを指定することもできます。
バージョン間のバリエーション
1 つのモデルリソースに対して、任意のバージョンを作成できます。つまり、バージョン間で機械学習モデルを完全に変更しても、同じモデルリソースをそのまま使用できます。モデルは、状況にかなうように任意に使用できる構成ツールにすぎません。
本番環境にバージョンを設定した後は特に、モデル バージョン間で入力と出力が同じになるようにするのが一般的です。それにより、モデルまわりに構築したその他のアプリケーション構造を変更する必要なく、バージョンを切り替えることができます。また、新しいバージョンを既存のデータで簡単にテストすることもできます。
デフォルトのバージョン
モデルのバージョンが 1 つでもあれば、そのモデルにはデフォルトのバージョンが存在します。デフォルトは、最初のバージョンの作成時に設定されます。モデル名だけを指定して予測をリクエストした場合、AI Platform Prediction ではそのモデルのデフォルトのバージョンが使用されます。
留意すべき点は、サービスでデフォルトのバージョンが自動的に設定されるのは、最初のバージョンを作成するときだけです。後続のバージョンを手動でデフォルトにするには projects.models.versions.setDefault を呼び出します。これは gcloud ai-platform versions set-default として公開されているほか、Google Cloud Console の [モデルの詳細] ページにある [バージョン] リストのオプションとしても表示されています（[モデルの詳細] ページに移動するには、[モデル] ページのモデルリストで対象モデルをクリックします）。これにより、たとえば、安定したデフォルトのバージョンを本番環境で予測に使用しながら、新しいバージョンのテスト用に別のモデルリソースを作成せずにテストを行うことができます。
モデルとバージョンの命名
モデル名とバージョン名は次のようにする必要があります。
- 文字（大文字と小文字を併用、大文字と小文字は区別される）、数字、およびアンダースコアのみ。
- 文字から始まる。
- 128 文字以下。
- 特定のプロジェクト（モデルの場合）またはモデル（バージョンの場合）内で一意である。
これらの技術的な要件以外に名前のルールはありませんが、ここにいくつかのおすすめの方法を示します。
- モデル名はわかりやすく、区別しやすくする必要があります。ログやレポートで、多数の名前のリストから見つけなければならない場合があるためです。
- バージョン名は短くシンプルにしておくのがベストです。たとえば、リソースのリストで「2017_01_29T13_54_58」よりも「v1」を識別する方が簡単です。
モデルとバージョンの制限
1 つの Google Cloud プロジェクトで作成できるモデルとバージョンの数については、リソースの割り当てをご覧ください。
モデルのデプロイ パラメータ
AI Platform Prediction には、モデル バージョンを作成するための情報が必要です。ユーザーが構成できるオプションもいくつかあります。このセクションでは、両方のタイプのパラメータについて説明します。これらのパラメータは Version オブジェクトで定義するか、利便性を考えて gcloud ai-platform versions create コマンドに追加します。
- バージョン名
- 新しいバージョンの名前。モデル内の他のバージョン名との間で一意にしてください。
- 説明
- バージョンの説明を指定できます。現時点では、API を使用してバージョン情報を取得した場合にのみ説明が表示されます。Google Cloud CLI や Google Cloud コンソールを使用した場合、説明は表示されません。
- デプロイ URI
- SavedModel が格納されている Cloud Storage の場所の URI を指定する必要があります。AI Platform Prediction は、この場所からモデルを取得してデプロイします。このパラメータは
gcloud ai-platform versions createコマンドで--originと呼ばれます。カスタム予測ルーチン（ベータ版）をデプロイする場合は、SavedModel を指定するだけでなく、モデル バージョンで予測のために使用するアーティファクトを格納した Cloud Storage ディレクトリの URI も指定できます。 - ランタイム バージョン
- AI Platform Prediction は、サポートされている別のバージョンが指定されない限り、最新の安定したランタイム バージョンを使用してモデル バージョンをデプロイします。ランタイム バージョンは、予測サービスがモデルを実行するために使用する TensorFlow のバージョンを主に決定します。バッチ予測ジョブを実行する場合、割り当てられたランタイム バージョンをオーバーライドするオプションがあります。オンライン予測では、モデル バージョンのデプロイ時に設定されたランタイム バージョンが使用されます。
- 手動スケーリング
対象のモデル バージョン用として実行状態を維持する予測ノードの数を指定できます。詳細については、スケーリングのセクションをご覧ください。
- ステージング バケット
モデルをデプロイするために Google Cloud CLI を使用する場合、ローカル コンピュータにある SavedModel を使用できます。このツールは、AI Platform Prediction にデプロイする前に指定した Cloud Storage の場所にステージングします。
予測前に行うグラフの変更
主にトレーニングの段階で利用された TensorFlow 演算が、計算グラフに含まれている場合があります。モデルをトレーニングしたら、最終バージョンをエクスポートする前に、グラフからそれらの演算を削除できます。
トレーニング アプリケーションの開発ページに示されているアドバイスの多くは、予測操作を対象としたものです。トレーニングの大部分が完了し、バージョンのデプロイを開始する準備が整ったときにモデルに加える変更もアドバイスの一部に含まれています。
予測の取得
デプロイ済みのモデル バージョンに新しいデータを送信して、予測を取得できます。以下のセクションでは、予測に際して考慮すべき重要な事項について説明します。
バッチ予測 vs オンライン予測
オンライン予測とバッチ予測の違いをご覧ください。
予測ノードとリソース割り当てについて
AI Platform Prediction は、「ノード時間」内で予測に消費された処理量を測定します。このセクションでは、これらのノードと、さまざまな種類の予測にノードがどのように割り当てられるかを説明します。
ノードは、仮想マシン（VM）のように考えるのが最も簡単です。ただし、従来の VM とは実装の仕組みが異なります。似ている点としては、ノードごとに一定量の処理能力とメモリがプロビジョニングされます。また、モデルを実行して予測を取得するために必要なオペレーティング システムのイメージと一連のソフトウェア構成があります。
オンライン予測とバッチ予測は、分散処理でノードを実行するため、特定のリクエストまたはジョブで複数のノードを同時に使用できます。時間単位が採用されており、ノードの総使用量に対して分単位で課金されます。たとえば、2 つのノードを 10 分間実行した場合、1 つのノードを 20 分間実行する場合と同じ料金が請求されます。オンライン予測とバッチ予測では、ノードの割り当てが異なります。これにより、料金に大きな影響を及ぼす可能性があります。
バッチ予測のノード割り当て
バッチ予測サービスは、ジョブの所要時間を最小限に抑えるように、使用するノードの数をスケーリングします。そのために、サービスは次の処理を行います。
ジョブの開始時にジョブを処理するためのノードを割り当てます。
効率を最適化するために、ジョブ中にノード数をスケーリングします。各ノードは起動に時間がかかるため、サービスは割り当てるノード数を必要最小限にとどめて経過時間を短縮し、起動時間の増加を相殺します。
ジョブが完了するとすぐにノードをシャットダウンします。
使用するノードの最大数を指定して、バッチ予測ジョブのスケーリングに影響を与えることができます。サービスで使用される最大ノード数を要求したくなるものですが、ノードの使用量には AI Platform Prediction の割り当てポリシーが適用されます。特にプロジェクトを他のユーザーと共有し、ジョブ（トレーニングと予測の両方）を同時に実行する可能性がある場合は、そのジョブに割り当てるノード数を制限することをおすすめします。
オンライン予測のノード割り当て
オンライン予測サービスでは、レイテンシを増大させずにリクエストを処理できるように、使用するノード数をスケーリングします。そのために、サービスは次の処理を行います。
予測リクエストがない状態が続く場合は、予測リクエストが実行されてからノードを割り当てる。
リクエスト トラフィックに応じてノード数をスケーリングし、トラフィック増加時にノードを追加し、リクエストが減ったらノードを削除する。
処理するリクエストがない場合でも、少なくとも 1 つのノードが数分間リクエストを処理できる状態にしておく。これにより、サービスですぐに予測を行うことができます。
モデル バージョンが予測リクエストを受信しない状態で数分間経過したら、ノード数をゼロにスケールダウンする。
サービスがゼロにスケールダウンされるか、トラフィックが急増すると、リクエストを処理するノードの初期化に時間がかかります（数秒から数分）。初期化の時間はモデル バージョンのサイズによって異なります。このため、クライアント側のタイムアウトにより、新しいノードが初期化されるか、この期間のレイテンシが増加するまで、リクエストが破棄される可能性があります。
常に迅速に処理されるようにするには、モデル バージョンで minNodes オプションを設定し、サービスで処理に確保しておく最小限のノード数を指定できます。この設定では、予測が処理されない場合でもノードの料金が発生するため、コストが増加する可能性があります。
自動スケーリングの制限
AI Platform Prediction のオンライン予測の自動スケーリングは、費用を最小限に抑えながらさまざまな頻度の予測リクエストの処理に役立ちます。しかし、それはすべての状況に最適とは限りません。このサービスで、リクエスト トラフィックの急増に追いつけるほど高速にノードをオンラインにすることができない場合があります。トラフィックが定期的に急増する場合や、アプリケーションが確実な低レイテンシを必要とする場合は、手動スケーリングを検討することをおすすめします。
手動スケーリングの使用
トラフィックに関係なく実行し続けるノードの数を指定することで、モデル バージョンに対するオンライン予測のスケーリングに影響を与えることができます。ノード数を手動で設定した場合、サービスは自動スケーリングしなくなります。つまり、指定した数のノードが常に準備完了状態に置かれ、そのノード数に対して継続的に課金されることになります。モデルが受信するリクエストの数が絶えず変動し、自動スケーリングで追いつけないような場合を除き、これは避けるべきです。projects.models.versions.create に渡す Version オブジェクトで manualScaling を設定することで、使用するノードの数を設定します。
マルチゾーン スケーリング
お使いのバージョンで Compute Engine（N1）マシンタイプを使用していて、autoScaling.minNodes または manualScaling.nodes を 2 以上に設定している場合（自動スケーリングと手動スケーリングのどちらを使用しているかにより異なります）、予測ノードは同じリージョン内の複数のゾーンで実行されます。これにより、いずれかのゾーンでサービスが停止しても、継続的可用性が確保されます。
予測の入力データ
予測を取得するために使用するデータは、トレーニングに使用したデータと同じ形式をとる新しいデータです。オンライン予測とバッチ予測はどちらも同じデータ（モデルの機能）を使用しますが、使用する予測の種類とインターフェースによって異なる形式が必要です。これらの形式を次の表にまとめます。各形式については、後述のセクションで詳しく説明します。
| 予測の種類とインターフェース | サポートされている入力形式 |
|---|---|
| バッチ予測、API 呼び出し | JSON インスタンス文字列を含むテキスト ファイルまたは TFRecord ファイル（圧縮可能） |
| バッチ予測、gcloud CLI | JSON インスタンス文字列を含むテキスト ファイルまたは TFRecord ファイル（圧縮可能） |
| オンライン予測、API 呼び出し | JSON リクエスト メッセージ |
| オンライン予測、gcloud CLI | JSON インスタンス文字列を含むテキスト ファイルまたは CSV ファイル |
インスタンス JSON 文字列
オンライン予測とバッチ予測の両方の基本形式は、インスタンス データのテンソルのリストです。これらは、トレーニング アプリケーションで入力を構成した方法に応じて、値のプレーンリストまたは JSON オブジェクトのメンバーのいずれかになります。
次の例は、入力テンソルとインスタンス キーを示しています。
{"values": [1, 2, 3, 4], "key": 1}
次の規則に従う限り、JSON 文字列の構成は複雑になってもかまいません。
インスタンス データの最上位レベルは、Key-Value ペアの辞書である JSON オブジェクトでなければならない。
インスタンス オブジェクト内の個々の値は、文字列、数字、またはリスト。 JSON オブジェクトを埋め込むことはできません。
リストには、同じ型（他のリストも含む）のアイテムのみが含まれている必要があります。文字列と数値を混在させることはできない。
次の文字列（読みやすいように書式設定されています）は、ラベルとイメージを含むオブジェクトを示しています。このイメージは 8 ビット整数の 3 次元配列で表されています。
{
"tag": "beach",
"image": [
[
[138, 30, 66],
[130, 20, 56],
...
],
[
[126, 38, 61],
[122, 24, 57],
...
],
...
]
}
モデルが単一の入力だけを受け取る場合、JSON オブジェクトでラップする必要はありません。たとえば、4 つの値が含まれる 1 つのテンソル（この例ではベクトル）を送信する場合、次のようにフォーマットする必要はありません。
{"values": [1, 2, 3, 4]}
各インスタンスをリストとしてフォーマットするだけです。
[1, 2, 3, 4]
予測入力でのバイナリデータ
バイナリデータは、JSON がサポートする UTF-8 エンコード文字列としてフォーマットできません。入力にバイナリデータがある場合は、base64 エンコーディングで表す必要があります。次の特殊なフォーマットが必要です。
エンコードされた文字列は、
b64という 1 つのキーを持つ JSON オブジェクトとしてフォーマットする必要があります。次の Python の例では、base64 ライブラリを使用して生の JPEG データのバッファをエンコードし、インスタンスを作成しています。{"image_bytes":{"b64": base64.b64encode(jpeg_data)}}TensorFlow モデルのコードでは、入力 / 出力テンソルのエイリアスの名前を「_bytes」で終わらせる必要があります。
オンライン予測の入力データ
オンライン予測の入力インスタンスは、予測リクエストのメッセージ本文として渡します。リクエストとレスポンスの本文のフォーマットについては、予測リクエストの詳細をご覧ください。
簡単に説明すると、各インスタンスをリスト内のアイテムにし、リストメンバーに instances という名前を付けます。したがって、先述の簡単なデータ インスタンス JSON の例は次のようになります。
{"instances": [{"values": [1, 2, 3, 4], "key": 1}]}
gcloud ai-platform projects predict を使ってオンライン予測をリクエストする場合、バッチ予測で使用する場合と同じ形式のファイルを渡します。
バッチ予測の入力データ
バッチ予測の入力データは、前述の JSON インスタンス データの行を含む 1 つまたは複数のテキスト ファイルとして渡します。入力ファイルには、単純な JSON 構文以外の列ヘッダーやその他の形式は含まれません。
{"image": [0.0, 0.0, ... ], "key": 0}
{"image": [0.0, 0.0, ... ], "key": 1}
{"image": [0.0, 0.0, ... ], "key": 2}
インスタンス キー
AI Platform Prediction は、分散処理を使用してバッチ予測ジョブを行います。つまり、データは仮想マシンの任意のクラスタに分散され、予測できない順序で処理されます。返される予測と入力インスタンスを照合できるようにするには、インスタンス キーを定義しておく必要があります。インスタンス キーは、すべてのインスタンスが持つ値であり、一連のデータのインスタンス間で一意です。最も簡単なキーはインデックス番号です。
トレーニング アプリケーションで変化しなかったグラフからキーを渡すことをおすすめします。データにまだインスタンス キーがない場合は、データの前処理の一部として追加できます。
ランタイム バージョン
AI Platform Prediction の新しいバージョンがリリースされると、古いバージョンで開発されたモデルはサポートされなくなる可能性があります。特に、効果的なモデル バージョンに達した後、変更を加えない状態が長期間続いた場合はこの問題に該当します。AI Platform Prediction バージョニング ポリシーを確認し、モデル バージョンのトレーニングに使用する AI Platform ランタイム バージョンを理解しておいてください。
ランタイム バージョンと予測
モデル バージョンを作成するときに、サポートされている AI Platform Prediction ランタイム バージョンを指定する必要があります。これにより、モデル バージョンのデフォルトの設定が確立されます。
バッチ予測ジョブを開始するときに、使用するランタイム バージョンを指定できます。これは、AI Platform Prediction にデプロイされていないモデルを使用して予測を取得する場合に対応するためです。デプロイされたモデルの場合、ジョブ リクエストでそのモデルのデフォルトのランタイム バージョンを使用します。別のランタイム バージョンを使用すると、予期しないエラーが発生する可能性があります。
オンライン予測では、AI Platform Prediction 以外のモデルにリクエストできません。そのため、リクエストでデフォルトのランタイム バージョンをオーバーライドするオプションはありません。
モデル バージョンに設定されたデフォルトのランタイム バージョンは変更できません。モデル バージョンに対して別のランタイム バージョンを指定するには、最初に使用したのと同じトレーニング アーティファクトを使用して新しいバージョンをデプロイします。
リージョンと予測
Google Cloud では、ゾーンに分割されたリージョンを使用して、物理的なコンピューティング リソースの地理的なロケーションを定義します。AI Platform Prediction を使用して予測のモデルをデプロイする場合は、予測を行うデフォルトのリージョンを指定します。
バッチ予測ジョブを開始する際に、ジョブを行うリージョンを指定して、デフォルトのリージョンを上書きできます。オンライン予測は、常にモデルに指定されたデフォルトのリージョンで処理されます。
モデル トレーニングやオンライン / バッチ予測など、AI Platform Prediction サービスの利用可能なリージョンを確認するには、リージョン ガイドをご覧ください。
予測のロギング
バッチ予測を行うと、Cloud Logging で表示できるジョブログが生成されます。オンライン予測のリクエストでも、モデルの作成時にログを生成するように構成しておけばログを取得できます。このオプションは AI Platform Prediction でモデルリソースを作成するときに指定する必要があり、モデルのすべてのバージョンでオンライン予測のログを生成するか、またはまったく生成しないかのいずれかを選択します。
モデルにオンライン予測のロギングを設定するには、projects.models.create でモデルを作成するときに使用するモデルリソースで onlinePredictionLogging を true（Python では True）に設定します。Google Cloud CLI を使用してモデルを作成する場合は、gcloud ai-platform models create を実行するときに --enable-logging フラグを指定します。
デプロイされていないモデルからの予測の取得
AI Platform Prediction サービスにデプロイしていないモデルを使用して、バッチ予測をリクエストできます。モデルまたはバージョン名を指定する代わりに、実行するモデルが格納されている Cloud Storage の場所の URI を使用できます。
デプロイされていないモデルには、デフォルトのランタイム バージョンが設定されていないため、ジョブのリクエストで明示的に設定する必要があります。
他のすべての点で、デプロイされていないモデルを使用したバッチ予測ジョブは、他のバッチジョブと同様に動作します。
モデルのテスト
AI Platform Prediction 予測サービスを使用して本番環境のモデルをホストできますが、このサービスはモデルのテストにも使用できます。従来、モデルのテストは、機械学習ソリューションのデプロイを準備する前のステップでした。テストパスの目的は、実際の状況で使用される方法に近い環境でモデルをテストすることです。
前述したように、予測サービスには、1 つのモデルの複数のバージョンを同時にデプロイできます。つまり、必要に応じてモデルの複数のリビジョンを用意して、一度にテストできます。また、次のリビジョンをテストしながら、モデルの本番環境バージョンを容易にデプロイすることもできます。機械学習アプリケーションの開発の大半がそうであるように、新しいデータの可用性が制限要因となることがあります。そのためデベロッパーは、手持ちのデータを分割し、テストに使用する新しいデータを収集するための戦略を開発する必要があります。