コンピューティング インスタンスとクラスタの構成を確認する

このドキュメントでは、Compute Engine インスタンスとクラスタを作成する前に考慮すべき AI Hypercomputer の構成について説明します。 利用可能な構成を確認することで、ワークロードのパフォーマンスを最適化し、ダウンタイムとパフォーマンスの問題を最小限に抑えることができます。

コンピューティング インスタンスとクラスタの作成の構成要素

ワークロードを実行するコンピューティング インスタンスとクラスタを作成する前に、使用する構成を検討してください。

  1. プロビジョニング モデル

  2. クラスタ デプロイツール

  3. 予約にバインドされたプロビジョニング モデルを使用する場合は、次の要素も考慮する必要があります。

プロビジョニング モデル

コンピューティング インスタンスまたはクラスタの作成に選択した 消費オプションに基づいて、次のいずれかのプロビジョニング モデルを使用して、インスタンスの作成に必要なリソースを取得できます。

  • 予約バインド: 将来の日付と期間でリソースを割引価格で予約できます。予約期間の開始時に、予約済みリソースを使用してインスタンスまたはクラスタを作成できます。予約期間中は、予約したリソースに排他的にアクセスできます。

  • Flex Start: 割引リソースを最大 7 日間リクエストできます。 Compute Engine は、リクエストされたリソースが使用可能になるとすぐに、そのプロビジョニングをベスト エフォートでスケジュールします。リクエストした期間中、取得したリソースに排他的にアクセスできます。

  • Spot: 可用性に基づいて、大幅に 割引されたリソースをすぐに取得できます。ただし、Compute Engine は容量を再利用するために、作成したインスタンスを任意のタイミングで停止または削除する場合があります。

予約にバインドされたプロビジョニング モデル

予約にバインドされたプロビジョニング モデルでは、作成したコンピューティング インスタンスが以前に予約した容量にリンクされます。容量を予約すると、Compute Engine は空の予約を作成します。予約の開始時間になると、次の処理が行われます。

  • Compute Engine は、予約したインスタンス数を予約に追加します。予約終了時間まで、予約した容量に排他的にアクセスできます。

  • Google Cloud では、容量を使用するかどうかにかかわらず、予約期間の終了まで予約済み容量に対して課金されます。

予約済みリソースを使用して、追加料金なしでインスタンスを作成できます。ディスクや IP アドレスなど、予約に含まれていないリソースについてのみ支払います。

コンピューティング インスタンスまたは MIG を作成するときに予約にバインドされたプロビジョニング モデルを指定するには、次の操作を行います。

  • コンソールの [**プロビジョニング モデル**] リストで、 [**予約で制限**] を選択します。 Google Cloud

  • Google Cloud CLI で、コマンドに --provisioning-model=RESERVATION_BOUND フラグを指定します。

  • Compute Engine API で、リクエスト本文に "provisioningModel": "RESERVATION_BOUND" フィールドを指定します。

容量を予約した後にインスタンス または MIG を作成するときにこれらのパラメータを設定する方法については、 コンピューティングインスタンスとクラスタの作成の概要をご覧ください。 Cluster Toolkit を使用してクラスタをデプロイする場合、クラスタ ブループリントによってプロビジョニング モデルが設定されます。

Flex Start プロビジョニング モデル

Flex Start プロビジョニング モデルを使用すると、リクエストした容量が使用可能になったときに、スタンドアロンの Flex Start VM を作成したり、Flex Start VM をマネージド インスタンス グループ(MIG)に追加したりできます。サイズ変更リクエストを使用して Flex Start VM を MIG に追加すると、MIG はインスタンスを一度にすべて作成します。このアプローチを使用すると、ワークロードの開始に必要な容量がすべて揃うまで、Compute Engine が提供する部分的な容量に対する不要な料金の発生を防ぐことができます。Flex Start プロビジョニング モデルは、安全な容量プールからリソースをプロビジョニングします。これにより、GPU などの需要の高いリソースを取得できる可能性が高まります。

スタンドアロン インスタンスまたは MIG のインスタンス テンプレートを作成するときに Flex Start プロビジョニング モデルを指定するには、次の操作を行います。

  • コンソールの [**プロビジョニング モデル**] リストで、 [**Flex Start**] を選択します。 Google Cloud

  • gcloud CLI で、コマンドに --provisioning-model=FLEX_START フラグを含めます。

  • Compute Engine API で、リクエスト本文に "provisioningModel": "FLEX_START" フィールドを指定します。

Flex Start プロビジョニング モデルを使用するインスタンスまたはクラスタの作成の詳細については、次のドキュメントをご覧ください。

Spot プロビジョニング モデル

Spot プロビジョニング モデルを使用すると、可用性に基づいて大幅割引のコンピューティング インスタンスを作成できます。ただし、Compute Engine は容量を再利用するために、作成したインスタンスを任意のタイミングで停止または削除する場合があります。このプロセスは プリエンプションと呼ばれます。

インスタンスまたは MIG を作成するときに Spot プロビジョニング モデルを指定するには、次の操作を行います。

  • コンソールの [**プロビジョニング モデル**] リストで、 [**Spot**] を選択します。 Google Cloud

  • gcloud CLI で、コマンドに --provisioning-model=SPOT フラグを含めます。

  • Compute Engine API で、リクエスト本文に "provisioningModel": "SPOT" フィールドを指定します。

インスタンス または MIG を作成するときにこれらのパラメータを設定する方法については、 コンピューティングインスタンスとクラスタの作成の概要をご覧ください。

クラスタ デプロイツール

Cluster Toolkit は、GPU アクセラレータ クラスタの作成におすすめのオープンソースの デプロイツールです。 Cluster Toolkit は、Google Kubernetes Engine(GKE)クラスタと Slurm クラスタの両方をデプロイできます。

または、次のいずれかの方法でコンピューティング インスタンスのグループをプロビジョニングし、必要に応じて独自のワークロード スケジューラを組み込むこともできます。

予約ブロックのデプロイタイプ

A4X Max、A4X、A4、A3 Ultra、A3 Mega、A3 High(8 GPU)のコンピューティングインスタンスまたはクラスタを作成するときに予約にバインドされたプロビジョニングモデルを使用すると、受け取ったマシンは、高密度に割り当てられたホストのブロック内に自動的にデプロイされます。このデプロイには次のようなメリットがあります。

  • Google の動的 ML ネットワーク ファブリックを使用して、一貫した高帯域幅、低レイテンシのインスタンス接続を実現するノンブロッキング ネットワーク。

  • インスタンス間の相対的な近接度を階層的に表示するネットワーク トポロジにアクセスできます。この機能は、高度なジョブ スケジューリングのユースケースに役立ちます。

  • オーケストレータを使用する場合の、きめ細かいトポロジ対応の配置。

  • メンテナンス スケジュールをきめ細かく制御して、ジョブ スケジューリングと稼働時間を最大化し、ダウンタイムを最小限に抑えます。

予約の運用モード

予約にバインドされたプロビジョニング モデルを使用する場合、予約するマシンタイプによって、予約済み容量の予約の運用モードが決定されます。各モードでは、ホストエラーまたは障害のあるホストの報告への対応方法と、予約のインフラストラクチャに対する可視性と制御のレベルが定義されます。

予約の運用モードごとに、次のものが定義されます。

  • 復元を管理するユーザー: ユーザーまたは Google Cloud。

  • **復元に使用する容量**: 予約済み容量のみ、または 予約の内外の容量。

  • 配置制御のレベル: きめ細かい制御のために、特定の予約サブブロックの計画時刻より前に メンテナンスを表示して開始できるかどうか。

コンピューティング インスタンスまたはクラスタを作成する容量を予約する場合は、次のいずれかの予約の運用モードを選択する必要があります: マネージド モードまたはすべての容量モード

マネージド モード

マネージド モードでは、 Google Cloud ホストエラーまたは障害のあるホスト の報告後に、コンピューティングインスタンスのメンテナンスと 復元プロセスを自動的に管理します。このアプローチは、ワークロードに高い安定性が求められ、ダウンタイムを最小限に抑える自動化プロセスが必要な場合に最適です。

マネージド モードには次の機能があります。

  • 復元にのみ予約済み容量を使用する: Compute Engine は、予約済み容量を使用してインスタンスを再起動します。予約で使用可能な容量がない場合、Compute Engine は容量を追加取得した後にのみインスタンスを再起動します。

  • インスタンスの自動再起動: Google Cloud は、インスタンスの復元プロセス全体を処理します。ホスト メンテナンスが必要な場合、Compute Engine は予約内の他の使用可能なマシンにインスタンスを自動的に移行し、インスタンスを再起動します。

  • ブロックの管理と可視性: 個々の予約と予約ブロックのトポロジ、健全性、 メンテナンス ステータスを表示できます。これらのリソースについては、メンテナンス通知を受け取ったり、必要に応じてスケジュールされたメンテナンス時刻より前にメンテナンスを開始したりすることもできます。

  • API レート上限の可能性: report faulty host API の呼び出しは、予約ごとに レート制限される可能性があります。

すべての容量モード

すべての容量モードでは、コンピューティング インスタンスの復元プロセスの管理はお客様の責任となります。ホストエラーまたは障害のあるホストの報告があった場合は、メンテナンスを手動で開始する必要があります。マネージド モードとは異なり、予約サブブロックのメンテナンスを表示して開始することもできます。これらの機能を使用すると、インスタンスのメンテナンスと復元プロセスをきめ細かく完全に制御できます。

すべての容量モードには次の機能があります。

  • 復元に予約済み容量と予約されていない容量を使用する: 予約済みリソースと、予約外で使用可能なリソースを使用して、ホストに障害が発生した場合にインスタンスを移行して再起動できます。

  • インスタンスの手動再起動: インスタンスの復元プロセスはお客様の責任となります。ホストエラーまたは障害のあるホストの報告によりホスト メンテナンスが必要な場合、Compute Engine はインスタンスを停止します。インスタンスを再起動できるのは、メンテナンスが完了した後のみです。

  • ブロックとサブブロックの管理と可視性: 個々の予約、 予約ブロック、予約サブブロックの トポロジ、健全性、メンテナンス ステータスを表示できます。これらのリソースについては、メンテナンス通知を受け取ったり、必要に応じてスケジュールされたメンテナンス時刻より前にメンテナンスを開始したりすることもできます。

  • API レート上限なし: report faulty host API を呼び出すときにレート上限はありません。

メンテナンスのスケジュール設定のタイプ

予約にバインドされたプロビジョニング モデルを使用する場合、 Cluster Director には、 クラスタで実行中のコンピューティング インスタンスのホスト メンテナンスをスケジュールするためのオプションが用意されています。容量を予約するときに、インスタンスをグループ化してメンテナンスのスケジュール設定を同期させるか(グループ化)、インスタンスを疎結合にしてメンテナンスのスケジュール設定を個別に行うか(個別)を指定できます。

グループ化されたメンテナンスのスケジュール設定

グループ化されたメンテナンスのスケジューリング設定のタイプを使用すると、Compute Engine がコンピューティング インスタンスをプロビジョニングするタイミングに関係なく、同じワークロードを実行するすべてのインスタンスの計画メンテナンスの頻度が同じになります。この密結合メンテナンスにより、使用済み容量と未使用容量を完全に制御できるため、ジョブのパフォーマンスを最適化できます。

グループ化されたメンテナンスのスケジュール設定のタイプは、次のような場合に便利です。

  • 環境で Slurm や GKE などのジョブ スケジューラを使用している。

  • トレーニングやその他の高度に並列化されたコンピューティング ワークロードを実行する。

個別のメンテナンスのスケジュール設定

この個別のメンテナンス スケジュール設定のタイプでは、インスタンスに異なるメンテナンス スケジュールが設定されます。この構成は、推論や小規模なトレーニングを実行する場合に最適です。この場合、ワークロードは個別のメンテナンス スケジュールを設定すると効率的に実行されます。

次のステップ