トレーニングのコンセプト

Cloud Machine Learning Engine を使用すると、TensorFlow トレーニング アプリケーションを簡単にクラウドで実行できます。このページでは、この機能について説明するとともに、自身のモデル トレーニングを最大限に活用するために理解する必要がある主要なコンセプトについて説明します。詳細な説明は不要で今すぐトレーニング プロセスを開始したい場合は、初めにトレーニングの基本のガイドに記載されているステップを実行してください。

トレーニングの仕組み

Python と TensorFlow で実装されるトレーニング アプリケーションが、トレーニング プロセスの中核となります。Cloud ML Engine は、このトレーナーをクラウド内のコンピューティング リソース上で実行します。このプロセスの概要を次に示します。

  1. TensorFlow アプリケーションを作成します。このアプリケーションがコンピューティング グラフを定義し、モデルをトレーニングします。トレーニング プロセスではこのアプリケーションに関して Cloud ML Engine からの要件はほとんどないので、ローカルの自分の開発環境で実行するときと同じようにビルドしてください。
  2. トレーニングと検証のデータを取得して、Cloud ML Engine がアクセスできるソースを作成します。そのために Google Cloud Storage や BigTable などの Google Cloud Platform ストレージ サービスにデータを置きますが、格納先となるストレージには Cloud ML Engine に使用するのと同じ Google Cloud Platform プロジェクトが関連付けられているのが一般的です。
  3. アプリケーションを実行する準備ができたら、パッケージ化します。プロジェクトがアクセスできる Google Cloud Storage バケットにこのパッケージを転送する必要があります。gcloud コマンドライン ツールを使用してトレーニング ジョブを実行する場合、これは自動的に行われます。
  4. Cloud ML Engine トレーニング サービスで、ジョブのリソースがセットアップされます。ジョブの設定に基づいて 1 つ以上の仮想マシン(「トレーニング インスタンス」とも呼ばれる)が割り当てられます。各トレーニング インスタンスは、次のようにセットアップされます。
    • ジョブで使用される Cloud ML Engine のバージョンに応じた標準マシンイメージを適用する。
    • トレーナー パッケージをロードし、pip を使用してインストールする。
    • 依存関係として指定されたその他のパッケージ(ある場合)をインストールする。
  5. トレーニング サービスでトレーナーを実行し、トレーニング ジョブの作成時に指定されたコマンドライン引数をトレーナーに渡します。
  6. 実行中のジョブに関する情報を得るには、次の 3 つの方法があります。
    • Stackdriver Logging を使用します。
    • gcloud コマンドライン ツールを使用して、ジョブの詳細を要求するかログのストリーミングを実行します。
    • トレーニング サービスへのステータス リクエストをプログラムで実行します。
  7. トレーナーが正常終了するか、回復不能なエラーが発生すると、Cloud ML Engine はすべてのジョブプロセスを停止してリソースをクリーンアップします。

Cloud ML Engine を使用して分散 TensorFlow ジョブを実行する場合は、複数のマシン(ノード)をトレーニング クラスタとして指定します。トレーニング サービスは、指定されたマシンタイプに応じたリソースを割り当てて、上記のステップ 4 を各マシンに対して実行します。ノード上で実行中のトレーナーを「レプリカ」と呼びます。分散 TensorFlow モデルに従って、トレーニング クラスタ内の各レプリカには、分散トレーニングにおける役割またはタスクが 1 つだけ与えられます。

  • 1 つのレプリカだけが「マスター」と指定されます。このタスクは他のレプリカを管理し、ジョブ全体のステータスを報告することです。前述のリストに示したとおり、トレーニング サービスの実行は「トレーナー」が正常終了するか回復不能なエラーが発生するまで続きます。分散方式の場合、マスター レプリカのステータスによって全体的なジョブ ステータスが示されます。

    シングルプロセス ジョブを実行する場合は、その唯一のレプリカがジョブのマスターとなります。

  • 1 つまたは複数のレプリカを「ワーカー」として指定できます。これらのレプリカは、トレーナーの中で指定された部分の作業を担当します。

  • 1 つまたは複数のレプリカを「パラメータ サーバー」として指定できます。これらのレプリカは、ワーカー間の共有モデル状態を調整します。

代表的な例

ここまでの説明の中で、機械学習サービスが処理に介入したり処理を制御したりすると思われたかもしれませんが、Cloud ML Engine はそうではありません。トレーニング サービスは、ユーザーが作成するトレーナーにできる限り影響を与えないように設計されています。つまり、TensorFlow コードを書くときは、求めているモデルが得られるように書くことに集中すればよいのであり、決められた構造の中に収める必要はありません。基本的には Cloud ML Engine がアプリケーションの実装を認識することはなく、関心を持つこともありません。

トレーニング サービスは、トレーナーのアーキテクチャに関してほとんど制限を設けてはいませんが、従うべき指針がないというわけではありません。たいていの機械学習トレーナーには、以下の作業が必要です。

  • トレーニング データと評価データを取得する方法を用意する。
  • 複数のデータ インスタンスをバッチ処理する。
  • 評価データを使用してモデルの精度(正しい値を予測する頻度)をテストする。
  • プロセス中に一定間隔でチェックポイントを出力し、モデルの進行状況のスナップショットをとる方法を用意する。
  • トレーナーが完了したときにトレーニング済みモデルをエクスポートする方法を用意する。

トレーナーのパッケージ化

これまでに Python パッケージを作ったことがない場合は、難しいプロセスに思えるかもしれませんが、gcloud コマンドライン ツールを使用してこの作業を自動的に行うことができます。ここでは、その一部について説明します。詳細な手順については、パッケージ化の方法の説明をご覧ください。

依存関係

トレーナーが持つ可能性のある依存関係には、標準依存関係とカスタム依存関係の 2 種類があります。標準依存関係とは、インポートされるパッケージであり、Python Package Index(PyPI)から入手可能です。これらは既知のライブラリであり、単純な pip コマンドでインストールできます。カスタム依存関係とは一般に、自分または組織内の他の人が開発した他のパッケージです。両方の種類の使用方法を次に示します。

標準依存関係を含める

パッケージの標準依存関係を、setup.py スクリプトの一部として指定できます。Cloud ML Engine トレーニング サービスは、ジョブ用に割り当てたトレーニング インスタンス上に pip を使用してトレーナー パッケージをインストールします。pip install を実行するときに、setup.py スクリプトで指定された依存関係がすべてインストールされます。

カスタム依存関係を含める

トレーナーのカスタム依存関係を指定するには、そのパスをジョブ設定の一部として渡します。トレーナー パッケージと同様に、追加するカスタム依存関係は Google Cloud Storage の場所に存在している必要があります。また、カスタム依存関係のインストールにも pip が使用されるので、カスタム依存関係自身の標準依存関係を setup.py スクリプトの中で指定しておくことができます。

クラウド トレーニングのパラメータ

トレーニング ジョブを作成するときに指定するパラメータには、ジョブ設定パラメータとトレーニング アプリケーション パラメータの 2 種類があります。このセクションでは、これらのタイプのパラメータを、両方説明します。

パラメータの形式

トレーニング サービスにパラメータを渡すには、JSON リクエスト文字列の中で Job リソースのメンバーを設定します。トレーニング パラメータは、TrainingInput オブジェクトの中で定義されています。gcloud コマンドライン ツールを使用してトレーニング ジョブを作成する場合、よく使用されるトレーニング パラメータは gcloud ml-engine jobs submit training コマンドのフラグとして定義されています。残りのパラメータは、YAML 設定ファイルとして渡すことができます。このファイルは、config.yaml という名前を付けることが慣例となっており、Job リソースの JSON 表現の構造がそのまま反映されます。設定ファイルへのパスは、--config 引数で gcloud ml-engine jobs submit training に渡す必要があります。したがって、設定ファイルへのパスが config.yaml の場合は --config=config.yaml と設定します。

ジョブ設定パラメータ

Cloud ML Engine トレーニング サービスは、クラウド内のリソースを設定し、処理クラスタ内の各ノード上でトレーナー アプリケーションをデプロイするための情報を必要とします。

ジョブ ID

トレーニング ジョブの名前は次のルールに従う必要があります。

  • Google Cloud Platform プロジェクト内で一意にする必要がある。
  • 使用できるのは英大文字と小文字、数字、アンダースコアのみ。
  • 先頭は文字にする必要がある。
  • 長さは 128 文字以下にする必要がある。

ジョブ名の付け方は自由です。実行するジョブの数があまり多くない場合は、名前の付け方が重要になることはそれほどありません。多数のジョブを実行する場合は、後で長いリストからジョブ ID を見つける必要があるため、ジョブを区別しやすいようにジョブ ID を付けることをおすすめします。

一般的な方法の 1 つは、同じモデルに関連付けられているすべてのジョブに同じ基本名を付けて、それに日付と時刻の文字列を付加するというものです。このような規則にすると、ジョブのリストを名前で並べ替えるのが簡単になります。同じモデルのすべてのジョブがまとめて昇順で表示されるからです。

スケール階層

トレーニング ジョブを実行するマシンの数とタイプを Cloud ML Engine に伝える必要があります。そのプロセスを簡単にするために、「スケール階層」と呼ばれるクラスタ仕様があらかじめいくつか定義されており、その中から選択できるようになっています。Google は、お客様からのフィードバックやクラウド リソースの可用性に基づいて、さまざまなジョブのスケール階層の設定を徐々に最適化していきます。各スケール階層は、特定のタイプのジョブへの適性という観点から定義されます。一般的に、より高度なスケール階層ほど、多くのマシンがクラスタに割り当てられ、各仮想マシンの仕様はより強力になります。スケール階層の複雑さが増すと、トレーニング ジョブの時間あたりコスト(トレーニング ユニットの数で表す)も増加します。ジョブのコストを計算するには、価格設定ページをご覧ください。

スケール階層を指定するには、ジョブ設定の TrainingInput オブジェクトに追加します。gcloud コマンドを使用してトレーニング ジョブを送信すると、以下で定義されているのと同じ識別子を使用できます。

スケール階層の定義は以下のとおりです。

Cloud ML Engine のスケール階層
BASIC

単一ワーカー インスタンス。Cloud ML Engine の使い方を学習するときや、小さいデータセットを使用して新しいモデルを実験するときに適しています。

Compute Engine のマシンタイプ: n1-standard-4

STANDARD_1

1 つのマスター インスタンス、4 つのワーカー、3 つのパラメータ サーバー。

Compute Engine のマシンタイプ、マスター: n1-highcpu-8、ワーカー: n1-highcpu-8、パラメータ サーバー: n1-standard-4

PREMIUM_1

1 つのマスター インスタンス、19 のワーカー、11 のパラメータ サーバー。

Compute Engine のマシンタイプ、マスター: n1-highcpu-16、ワーカー: n1-highcpu-16、パラメータ サーバー: n1-highmem-8

BASIC_GPU

1 つの NVIDIA Tesla K80 GPU を備えた 1 つのワーカー インスタンス。グラフィック プロセッシング ユニット(GPU)の詳細については、GPU でのトレーニングに関するセクションをご覧ください。

Compute Engine のマシンタイプ: n1-standard-8(k80 GPU×1)

CUSTOM CUSTOM 階層はあらかじめ設定された階層ではなく、独自のクラスタ仕様を使用するための階層です。この階層を使用するときは、処理クラスタを設定するための値を、下記のガイドラインに沿って設定します。
  • マスターノードに使用するマシンのタイプを指定するために TrainingInput.masterType を設定する必要があります。これが唯一の必須の設定です。以下で説明するマシンタイプをご覧ください。
  • 使用するワーカーの数を指定するために、TrainingInput.workerCount を設定することができます。ワーカーを 1 つ以上指定する場合は、ワーカーノードに使用するマシンのタイプを指定するための TrainingInput.workerType も指定する必要があります。
  • 使用するパラメータ サーバーの数を指定するために TrainingInput.parameterServerCount を設定することができます。パラメータ サーバーを 1 つ以上指定する場合は、パラメータ サーバーに使用するマシンのタイプを指定するための TrainingInput.parameterServerType も設定する必要があります。

カスタム スケール階層のマシンタイプ

自分のモデルでトレーニングを行うために使用する処理クラスタを、より細かく調整したい場合は、スケール階層を CUSTOM に設定し、使用するパラメータ サーバーの台数とワーカーの数の値を、それぞれに使用するマシンのタイプと合わせて設定します。マスター ワーカー、パラメータ サーバー、ワーカーのそれぞれに異なるマシンタイプを指定できますが、同じタイプのインスタンスに異なるマシンタイプを使用することはできません。たとえば、large_model というマシンタイプをパラメータ サーバーに使用できますが、あるパラメータ サーバーには large_model を使用し、それ以外には complex_model_m を使用するということはできません。スケール階層と同様に、指定できるマシンタイプの値は Cloud ML Engine API の中で、TrainingInput オブジェクトの定義の一部として定義されています。

以下はマシンタイプの定義です。

Cloud ML Engine のマシンタイプ
standard

基本的なマシン構成。小~中規模のデータセットを使用する単純なモデルのトレーニングに適しています。

Compute Engine のマシンタイプ: n1-standard-4

large_model

大容量メモリを備えたマシン。特に、モデルが大きい(多数の隠れ層がある、または非常に多くのノードを持つ層がある)ときのパラメータ サーバーに適しています。

Compute Engine のマシンタイプ: n1-highmem-8

complex_model_s

standard タイプのマシンで適切に処理できるレベルよりも多くのコンピューティングをモデルが必要としている場合に、クラスタのマスターやワーカーに適しています。

Compute Engine のマシンタイプ: n1-highcpu-8

complex_model_m

complex_model_s の約 2 倍のコア数と約 2 倍のメモリ容量を備えたマシン。

Compute Engine のマシンタイプ: n1-highcpu-16

complex_model_l

complex_model_m の約 2 倍のコア数と約 2 倍のメモリ容量を備えたマシン。

Compute Engine のマシンタイプ: n1-highcpu-32

standard_gpu

standard タイプと同等のマシンで、NVIDIA Tesla K80 GPU 1 個が追加されています。

Compute Engine のマシンタイプ: n1-standard-8(k80 GPU×1)

complex_model_m_gpu

complex_model_m と同等のマシンで、NVIDIA Tesla K80 GPU 4 個が追加されています。

Compute Engine のマシンタイプ: n1-standard-16-k80x4

complex_model_l_gpu

complex_model_l と同等のマシンで、NVIDIA Tesla K80 GPU 8 個が追加されています。

Compute Engine のマシンタイプ: n1-standard-32-k80x8

standard_p100

standard タイプと同等のマシンで、NVIDIA Tesla P100 GPU 1 個が追加されています。。これらの GPU の利用可能性は、ベータ版の段階にあります。

Compute Engine のマシンタイプ: n1-standard-8-p100x1

complex_model_m_p100

complex_model_m と同等のマシンで、NVIDIA Tesla P100 GPU 4 個が追加されています。これらの GPU の利用可能性は、ベータ版の段階にあります。

Compute Engine のマシンタイプ: n1-standard-16-p100x4

グラフィック プロセッシング ユニット(GPU)の詳細については、GPU でのトレーニングに関するセクションをご覧ください。

マシンタイプの比較

マシンタイプの具体的な仕様は随時変更される可能性がありますが、相対的な能力を比較することは可能です。次の表では、各マシンタイプを T シャツのサイズにたとえて表しています。

マシンタイプ CPU GPU メモリ
standard XS - M
large_model S - XL
complex_model_s S - S
complex_model_m M - M
complex_model_l L - L
standard_gpu XS 1(K80) M
complex_model_m_gpu M 4(K80) M
complex_model_l_gpu L 8(K80) L
standard_p100(ベータ版) XS 1(P100) M
complex_model_m_p100(ベータ版) M 4(P100) M

サイズが 1 つ大きくなるたびに、能力は約 2 倍になります。サイズは小さい順に XS、S、M、L、XL があります。

パッケージの URI

トレーナーを Cloud ML Engine で実行できるようにするには、Python パッケージの形にして Google Cloud Storage のバケットにコピーする必要があります。パッケージの URI を、パッケージ URI リストの要素の 1 つとしてトレーニング サービスに渡してください。Cloud Storage 上の場所を表す URI の形式は次のとおりです。

gs://bucket_name/path/to/package.tar.gz

作成したパッケージは、単一文字列ではなく、パッケージ URI リストの 1 要素として表します。他のパッケージも依存関係として指定できるようにするためです。この中で指定される URI はそれぞれ、別のパッケージへのパスであり、パッケージの形式は tarball(* .tar.gz)または wheel です。トレーニング サービスは、トレーニング ジョブ用に割り当てたすべての仮想マシンに pip install を使用して各パッケージをインストールします。

Python モジュール

トレーナー パッケージには、複数のモジュール(Python ファイル)を入れることができます。その場合、どのモジュールの中にアプリケーションのエントリ ポイントがあるかを指定する必要があります。トレーニング サービスは Python を起動し、デベロッパーがローカルで実行する場合と同様にそのモジュールを実行します。

トレーナー アプリケーションから Python のパッケージを作成するときに、名前空間を作成します。たとえば、作成するパッケージの名前が my_trainer で、メイン モジュールの名前が task.py である場合、そのパッケージの名前に my_trainer.task を指定します。

ハイパーパラメータ

ハイパーパラメータ調整を使用する場合は、トレーニング ジョブの作成時に設定詳細を含める必要があります。ハイパーパラメータ調整の説明については、この機能の概要をご覧ください。設定と使用の説明は、その入門ガイドに記載されています。

リージョン

Google Cloud Platform では、ゾーンに分割されたリージョンを使用して、物理的なコンピューティング リソースの地理的なロケーションを定義します。Cloud ML Engine でトレーニング ジョブを実行するときに、どのリージョンで実行するかを指定します。

トレーニングのデータセットを Google Cloud Storage に格納する場合は、使用するバケットと同じリージョンでトレーニング ジョブを実行する必要があります。データバケットとは異なるリージョンでジョブを実行する必要がある場合は、ジョブの実行に時間がかかることがあります。

モデル トレーニングやオンライン / バッチ予測など、Cloud ML Engine サービスの利用可能なリージョンを確認するには、リージョン ガイドをお読みください。

job-dir を共通の出力ディレクトリとして使用

Cloud ML Engine は入力と出力に介入しませんが、ジョブの出力ディレクトリを指定する仕組みが用意されています。デベロッパーは、ジョブの設定時にジョブ ディレクトリを設定することができ、これを設定した場合 Cloud ML Engine トレーニング サービスは次の処理を行います。

  • ジョブの実行前に問題を修正できるように、ディレクトリを検証する。
  • ディレクトリ パスをコマンドライン引数 --job-dir としてアプリケーションに渡す。

この機能を使用する場合は、アプリケーションで --job-dir 引数のアカウントを確認する必要があります。他のパラメータを解析するときにこの引数の値を取得し、トレーナーの出力を保存するときにその値を使用します。以下のアプリケーション パラメータのセクションをご覧ください。

ランタイム バージョン

サポートされる Cloud ML Engine ランタイム バージョンのうち、どれをトレーニング ジョブの実行に使用するかを指定できます。ランタイム バージョンを指定すると、割り当てられたトレーニング インスタンスにインストールされる TensorFlow やその他の Python パッケージのバージョンが決まります。特に理由がない限り、トレーニング サービスのデフォルトのバージョンを使用してください。これが常に最新の安定したバージョンです。

トレーニング アプリケーションのパラメータ

クラウドでアプリケーションを実行するときにデータを渡すには、メイン モジュールのコマンドライン引数を指定します。引数のリストを組み立てて、トレーニング設定の中で指定します。

トレーニング サービスは、引数を次の形式の文字列のリストとして受け取ります。

['--my_first_arg', 'first_arg_value', '--my_second_arg', 'second_arg_value']

このリストのメンバーには、トレーナーをコマンドラインから起動する場合に入力する各式を同じ順番で指定してください。

gcloud コマンドライン ツールを使用してトレーニング ジョブを実行するときは、コマンドラインでアプリケーションを実行するときと同じように引数を指定します。すべての gcloud 固有の引数の後で、空の -- 引数を指定し、さらにすべての独自の引数(USER_ARGS とも呼ばれています)を指定します。

gcloud ml-engine jobs submit training job123 \
    --package-path=gs://bucket/path/to/package.tar.gz \
    --module-name=trainer.task \
    --job-dir=gs://bucket/path/to/dir \
    --region=us-central1 \
    -- \
    --user_first_arg=first_arg_value \
    --user_second_arg=second_arg_value

注:

  • 空の -- 引数は、アプリケーションに渡す gcloud 固有の引数の最後と、USER_ARGS の開始を示します。
  • --module-name--runtime-version--job-dir などの Cloud ML Engine 固有の引数は、空の -- 引数の前に指定する必要があります。Cloud ML Engine サービスが、これらの引数を解釈します。
  • Cloud ML Engine が --job-dir 引数を使用してパスを検証するため、--job-dir 引数を指定する場合は、空の -- 引数の前に指定する必要があります。
  • --job-dir 引数が指定されている場合、アプリケーションはこれも処理する必要があります。--job-dir が空の -- 引数の前に来ている場合でも、コマンドライン引数としてアプリケーションに渡されます。

入力データ

どの機械学習モデルも、最初に既知のデータが必要です。Cloud ML Engine で実行されるトレーナーで使用できるデータに関する制限事項は、次の 2 つだけです。

  • 読み取って TensorFlow コードに渡せるデータ形式であること。
  • コードからアクセスできる場所にあること。データの格納先には、Google Cloud Platform のストレージまたはビッグデータのサービスを使用するのが一般的です。

出力データ

一般的に、トレーナーはデータを出力します。トレーニング中のチェックポイントと、トレーニング完了時に保存されるモデルです。必要に応じて、その他のデータをアプリケーションで出力することができます。入力データと同様に、出力も、トレーニング ジョブと同じ Google Cloud Platform プロジェクトの Google Cloud Storage バケットに保存するのが最も簡単です。

VM の再起動に対して復元性のあるトレーニング ジョブの構築

Google Cloud VM は、時々再起動される可能性があります。モデル チェックポイントを定期的に保存し、最新のチェックポイントを復元するようにジョブを構成することによって、トレーニング ジョブがこれらの再起動に対して復元性があることを確実にする必要があります。

通常、モデル チェックポイントは、gcloud ml-engine jobs submit training コマンドの --job-dir 引数で指定した Cloud Storage パスに保存します。

TensorFlow Estimator API がチェックポイント機能を実装します。モデルが Estimator にラップされている場合は、VM の再起動イベントについて心配する必要はありません。

TensorFlow Estimator にモデルをラップすることができず、トレーニング ジョブに再起動イベントに対する復元性を持たせたい場合は、チェックポイントの保存と復元機能をモデルに書き込む必要があります。TensorFlow は、tf.train モジュールで次の有用なリソースを提供します。

GPU を使用するトレーニング

Cloud ML Engine でトレーニング ジョブを実行するときに、GPU(グラフィック プロセッシング ユニット)を使用することができます。GPU は、大量の数学的演算を高速に実行するように設計されています。テンソルデータに対して実行する演算の種類によっては、CPU コアを持つマシンを追加するよりも GPU を使用するほうが効果的です。

トレーニング ジョブの実行に関する他の多くの側面と同様に、Cloud ML Engine トレーニング サービスには、GPU を使用するための特別なインターフェースはありません。GPU 対応のマシンを指定してジョブを実行すると、自動的に GPU が割り当てられます。トレーナーのコードの中で TensorFlow 演算を GPU に割り当ててください。GPU アクセス可能なマシンタイプを特定のタスクタイプ用に指定すると、そのタスクタイプに割り当てられた各インスタンスはまったく同じように設定されます(これは通常の動作です)。トレーナー コードの単一レプリカが各マシン上で実行されます。

モデルによっては、GPU で実行するメリットがないこともあります。GPU をおすすめするのは、大規模で複雑なモデルで多数の数学的演算を行う場合です。この場合も、GPU の効果があるかどうかをテストするために、少数のサンプルデータでトレーニングを実行してください。

トレーニング ジョブに GPU を使用する方法をご覧ください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud Machine Learning Engine(Cloud ML Engine)