オーケストレーション

Gemini Enterprise Agent Platform トレーニング クラスタに関心をお持ちの場合は、営業担当者にお問い合わせください。

Gemini Enterprise Agent Platform トレーニング クラスタは、クラスタのジョブの管理とスケジューリングのオーケストレーターとして Simple Linux Utility for Resource Management（Slurm）を使用します。

Slurm は、スケーラビリティとフォールト トレランスで知られる、広く使用されているオープンソースのクラスタ管理およびジョブ スケジューリング システムです。

Slurm の主な機能

  • Slurm は、特定のジョブが定義された期間に独占的に使用する一連のコンピューティング ノードを割り当てます。これにより、ジョブは実行に必要なリソースに干渉なしで専用アクセスできるようになります。
  • Slurm は、ジョブの送信と実行からモニタリングと完了まで、ジョブのライフサイクル全体を管理するためのフレームワークを提供します。このシステムは、割り当てられたノードのセットで実行される並列ジョブを処理するように特別に設計されています。
  • Slurm は、高度な優先度設定エンジンを使用してコンピューティング リソースへのアクセスを仲介し、保留中のジョブのキューを維持します。このシステムは、ジョブサイズ、ユーザーの優先度、待ち時間などの要素を考慮して、クラスタ全体で公平かつ効率的なリソース使用率を確保します。

基本的なクラスタ構成

ジョブを実行する前に、Slurm クラスタの基本的な構造を定義する必要があります。このセクションでは、コンピューティング ノードをパーティションに整理する方法、専用のログイン ノードプールを指定する方法、ユーザーの共有ホーム ディレクトリを構成する方法など、重要な構成設定について詳しく説明します。

パーティション

パーティションはノードを論理セットにグループ化します。これは、さまざまなマシンタイプやアクセス階層の管理に役立ちます。これらは、slurm_spec のパーティショ フィールド内のリストとして定義されます。

各パーティション オブジェクトには、次の必須フィールドがあります。

  • id: パーティションの固有識別子。
  • node_pool_ids: このパーティションに属する 1 つ以上のノードプールの ID を含むリスト。

次に例を示します。

"partitions": [
  {
    "id": "a4",
    "node_pool_ids": [ "a4" ]
  }
]

--partition なしで送信されたジョブは、デフォルトのパーティションで実行されます。デフォルトのパーティションを指定するには、slurm_spec の default_partition_id をパーティションの 1 つの id に設定します。設定しない場合、リストの最初のパーティションがデフォルトになります。

ログインノード

ログイン ノードプールは、ユーザーがクラスタを操作するための主要なエントリ ポイントとして機能する専用ノードを提供します。login_node_pool_id フィールドは、このプールの固有識別子を指定します。

例:

"login_node_pool_id": "login"

ホーム ディレクトリのストレージ

home_directory_storage フィールドは、クラスタ内のすべてのノードの /home ディレクトリとしてマウントされる Filestore インスタンスを指定します。これにより、すべてのユーザーに共有の永続的なホーム ディレクトリが提供されます。

この値には、Filestore インスタンスの完全なリソース名を指定する必要があります。

例:

"home_directory_storage": "projects/PROJECT_ID/locations/REGION-ZONE/instances/FILESTORE_INSTANCE_NAME"

高度な Slurm 構成

Gemini Enterprise Agent Platform トレーニング クラスタを使用すると、slurm.conf パラメータを設定し、実行中のクラスタで変更できます。Slurm 構成マップをご覧ください。

アカウンティング、プリエンプション、優先度

Slurm アカウンティングはすべてのクラスタで有効になっているため、CPU 時間やメモリなどのジョブごとのリソース使用量を追跡できます。クラスタ仕様の例に示すように、config を使用してアカウンティングの制限を適用し、ジョブの優先度を重み付けし、プリエンプションを有効にすることもできます。これらの仕組みについては、アカウンティング、多要素優先度プラグイン、プリエンプションに関する Slurm のドキュメントをご覧ください。

プロローグ スクリプトとエピローグ スクリプト

次のフィールドを使用して、各ジョブの開始時（プロローグ）と終了時（エピローグ）に自動的に実行されるカスタム Bash スクリプトを構成できます。

  • prolog_bash_scripts: 文字列のリスト。各文字列には、ジョブの開始前に実行される Bash スクリプトの完全な内容が含まれています。
  • epilog_bash_scripts: 文字列のリスト。各文字列には、ジョブの完了後に実行される Bash スクリプトの完全な内容が含まれています。

これは、一意のジョブ環境を設定したり、自動クリーンアップ タスクを実行したりする場合に便利です。

クラスタ仕様の例

次の例は、トレーニング クラスタを作成するための JSON 構成を示しています。この仕様は、独自のニーズに合わせて調整できます。

{
  // ... other cluster configurations ...
  "orchestratorSpec": {
    "slurmSpec": {
      "partitions": [
        {
          "id": "a4",
          "node_pool_ids": ["a4"]
        }
      ],
      "login_node_pool_id": "login",
      "home_directory_storage": "projects/PROJECT_ID/locations/REGION-ZONE/instances/FILESTORE_INSTANCE_ID",
      "config": {
        "AccountingStorageEnforce": "associations,limits,qos",
        "PriorityType": "priority/multifactor",
        "PriorityWeightAge": "1000",
        "PriorityWeightFairshare": "10000",
        "PreemptType": "preempt/partition_prio",
        "PreemptMode": "REQUEUE",
        "PreemptExemptTime": "00:10:00"
      },
      "prolog_bash_scripts": [
        "#!/bin/bash\necho 'First prolog script running'",
        "#!/bin/bash\necho 'Second prolog script running'"
      ],
      "epilog_bash_scripts": [
        "#!/bin/bash\necho 'Epilog script running'"
      ]
      // ... other Slurm settings ...
    }
  }
}

クラスタの管理と運用

実行中のクラスタの管理

選択したアカウンティングとプリエンプションの設定でクラスタを作成したら、Slurm のコマンドライン ツールを使用してユーザー アカウントを管理し、ジョブ スケジューリングをモニタリングできます。

sacctmgr を使用したアカウント管理

sacctmgr コマンドは、Slurm データベースでユーザーとアカウントの情報を管理するための主なツールです。たとえば、アカウントに新しいユーザーを追加して、パーティションへのアクセス権を付与するには、次のコマンドを実行します。

sudo sacctmgr add User Accounts=<account> Partition=<partition> <user>

sacctmgr オプションの完全なリストについては、Slurm アカウンティングの公式ドキュメントをご覧ください。

ジョブの優先度を確認する

キュー内の各ジョブの優先度コンポーネントを確認するには、sprio ユーティリティを使用します。これは、特定のジョブが他のジョブよりも先に実行されるようにスケジュールされている理由を理解するのに役立ちます。

詳細な使用方法については、sprio ユーティリティのドキュメントをご覧ください。

プリエンプションの例

Slurm の公式ドキュメントには、さまざまなプリエンプション戦略の動作例がいくつか記載されています。これらは、Slurm プリエンプション ページで確認できます。

次のステップ

以降では、ML ライフサイクルの最終ステップである、トレーニング済みモデルの管理、デプロイ、モニタリングに焦点を当てます。

  • 推論用にモデルをデプロイする: トレーニング済みモデルを Gemini Enterprise Agent Platform エンドポイントにデプロイして、オンライン推論リクエストを大規模に処理します。
  • モデルのライフサイクルを管理する: Gemini Enterprise Agent Platform Model Registry を使用して、モデルのバージョン管理、比較、管理を行います。トレーニングが成功すると、新しいモデルを自動的に登録するようにパイプラインを構成できます。
  • パイプラインの実行とモデルのパフォーマンスをモニタリングします。
    • パイプライン モニタリング: パイプライン実行の実行グラフ、アーティファクト、パフォーマンスを追跡して、問題をデバッグし、オーケストレーションを最適化します。
    • モデル モニタリング: デプロイ後、モデルの予測パフォーマンスのドリフトと異常を検出するようにモニタリングを設定します。これにより、モデルの精度を長期にわたって維持できます。
  • 費用を最適化してクラスタのライフサイクルを管理する: 自動化されたパイプラインを使用する場合は、実行頻度を考慮してクラスタのライフサイクルを管理します。
    • 実行頻度が低い場合は、最後のパイプライン ステップを追加してクラスタを削除し、費用を節約します。通常、これには削除関数を呼び出すカスタム パイプライン コンポーネントの作成が含まれます。
    • 頻繁に実行する場合は、クラスタをアクティブなままにして、ジョブの起動時間を短縮します。