Pod ベースの容量予約は、弾性サービスのリソース可用性を保証します。GPU Pod の容量予約は、クラスターにアタッチする必要はありません。予約を購入する際に、Pod 仕様、ゾーン、予約期間などのプロパティを指定します。これにより、ACS は指定された仕様の Pod を数分以内に起動できることを保証します。GPU Pod の容量予約は、リソースの可用性を確保し、従量課金の Pod よりもコスト効率が高いです。このトピックでは、GPU Pod の容量予約の特徴について説明します。
特徴
リソースの可用性：容量予約の有効期間中、システムはリソースを正常に起動できることを保証します。
コスト削減：Pod が起動すると、従量課金レートで課金されます。Pod が破棄されると、容量予約レートで課金されます。サービスのトラフィックに基づいて、Pod の起動と破棄の時間を柔軟に設定できます。
リソースの柔軟性：さまざまなビジネスニーズに合わせて、異なる仕様の GPU Pod 容量予約を作成できます。
GPU Pod の容量予約は、BestEffort 計算能力タイプの Pod のリソースを保証しません。
GPU Pod の容量予約は、リージョンやタイプなど、予約のプロパティに一致する節約プランをサポートします。
GPU Pod の容量予約が正常に作成されるかどうかは、在庫の可用性によって決まります。
利用シーン
定期的なリアルタイムサービスのリソース需要：サービスのトラフィックが日次または週次で周期的なパターンを示し、タスクをリアルタイムで実行・完了する必要がある場合。例として、リアルタイム推論サービスが挙げられます。
突発的な高いリソース需要：サービスにリアルタイムコンピューティングの突発的な需要があり、ビジネスへの影響を防ぐために迅速なリソース配信とスケールアウトが必要な場合。例として、インターネットサービスのホットスポットイベントによってトリガーされるリソース需要が挙げられます。
課金例
GPU Pod の容量予約は、従量課金の課金方法を使用します。容量予約の有効期間中、料金には以下が含まれます：
未使用の容量予約に対する従量課金料金。
起動した Pod に対する従量課金料金。
この例では、2 つの GPU Pod 容量予約を購入し、2 つの従量課金 Pod (Pod1 と Pod2) を作成するシナリオを使用します。次の図は、各フェーズのプロセスと課金アルゴリズムを示しています。
フェーズ 1：容量予約の購入と作成
以下の操作を実行する前に、まず GPU 容量予約を有効化する必要があります。
Container Compute Service コンソールで、[容量予約] > [GPU 容量予約の作成] を選択し、パラメーターを設定してから [容量予約の作成] をクリックします。
設定項目 | 説明 |
[容量予約名] | 容量予約のカスタム名。 |
予約タイプ | GPU カードタイプ。 |
リージョン | リソースを予約するリージョン。 |
ゾーン | リソースを予約するゾーン。 |
リソース仕様 | 容量予約の仕様。GPU の数を選択するだけで、システムはその GPU 数で利用可能な最高の CPU とメモリ仕様を自動的に照合します。 |
[予約方法] | Pod 予約 (変更不可)。 |
課金モード | 従量課金 (変更不可)。 |
数量 | この仕様の GPU Pod 容量予約の数。 |
このフェーズの料金アルゴリズムは次のとおりです：
フェーズ | 料金 | 説明 |
フェーズ 1 | なし | 容量予約は作成されていません。 |
フェーズ 2〜6：容量予約の有効期間
有効期間中、予約構成を超えない限り、いつでも Pod インスタンスを作成できます。システムは Pod が正常に作成されることを保証し、対応する容量予約クォータを差し引きます。予約を適用するには、Pod の GPU (カードタイプと数量)、CPU、およびメモリが予約された仕様を超えてはなりません。一致が見つかった場合、予約全体が適用されます。たとえば、1 つの容量予約 (1 GPU、10 vCPU、80 GB メモリ) を購入し、1 GPU、1 vCPU、2 GB メモリの仕様で Pod を作成した場合、システムは容量予約全体を適用します。Pod が破棄されると、対応する GPU Pod 容量予約クォータが復元されます。
これらのフェーズの料金アルゴリズムは次のとおりです：
フェーズ | 料金 |
フェーズ 2 | 2 × 容量予約単価 × フェーズ 2 の期間 |
フェーズ 3 | 1 × 容量予約単価 × フェーズ 3 の期間 + Pod1 の従量課金単価 × フェーズ 3 の期間 |
フェーズ 4 | Pod1 の従量課金単価 × フェーズ 4 の期間 + Pod2 の従量課金単価 × フェーズ 4 の期間 |
フェーズ 5 | 1 × 容量予約単価 × フェーズ 5 の期間 + Pod2 の従量課金単価 × フェーズ 5 の期間 |
フェーズ 6 | 2 × 容量予約単価 × フェーズ 6 の期間 |
容量予約単価は、未使用の容量予約に対する従量課金料金です。Pod1 と Pod2 の従量課金単価は、Pod が起動した後に適用される標準の従量課金レートです。
フェーズ 7：容量予約の有効期限切れ
容量予約の有効期限が切れると、システムは自動的に GPU Pod 容量予約をリリースします。
利用可能なリソース予約タイプ
容量予約仕様のクォータを増やした後、容量予約は次のカードタイプと仕様をサポートします：
カードタイプ | GPU | vCPU | メモリ (GiB) |
L20 (GN8IS) | 1 (48 G GPU メモリ) | 16 | 128 |
2 (48 G × 2 GPU メモリ) | 32 | 230 | |
4 (48 G × 4 GPU メモリ) | 64 | 460 | |
8 (48 G × 8 GPU メモリ) | 128 | 920 | |
T4 | 1 (16 G GPU メモリ) | 24 | 90 |
2 (16 G × 2 GPU メモリ) | 48 | 180 | |
A10 | 1 (24 G GPU メモリ) | 16 | 60 |
2 (24 G × 2 GPU メモリ) | 32 | 120 | |
4 (24 G × 4 GPU メモリ) | 64 | 240 | |
8 (24 G × 8 GPU メモリ) | 128 | 480 | |
P16EN | 1 (96 G GPU メモリ) | 10 | 80 |
2 (96 G × 2 GPU メモリ) | 22 | 225 | |
4 (96 G × 4 GPU メモリ) | 46 | 450 | |
8 (96 G × 8 GPU メモリ) | 92 | 900 | |
16 (96 G × 16 GPU メモリ) | 184 | 1800 | |
GU8TF | 1 (96 G GPU メモリ) | 16 | 128 |
2 (96 G × 2 GPU メモリ) | 46 | 230 | |
4 (96 G × 4 GPU メモリ) | 92 | 460 | |
8 (96 G × 8 GPU メモリ) | 184 | 920 | |
GU8TEF | 1 (141 G GPU メモリ) | 22 | 225 |
2 (141 G × 2 GPU メモリ) | 46 | 450 | |
4 (141 G × 4 GPU メモリ) | 92 | 900 | |
8 (141 G × 8 GPU メモリ) | 184 | 1800 | |
L20X (GX8SF) | 1 (141 G GPU メモリ) | 22 | 225 |
2 (141 G × 2 GPU メモリ) | 46 | 450 | |
4 (141 G × 4 GPU メモリ) | 92 | 900 | |
8 (141 G × 8 GPU メモリ) | 184 | 1800 |
適用ルール
容量予約は、以下のすべての条件が満たされた場合にのみ適用されます：
Pod の GPU カードタイプが、予約されたカードタイプと完全に一致する。たとえば、予約されたカードタイプと Pod のカードタイプが両方とも L20 である場合。
GPU の数が、予約された構成と完全に一致する。たとえば、予約された GPU の数と Pod の GPU の数が両方とも 1 である場合。
Pod の vCPU 数 ≤ 予約された vCPU 数。
Pod のメモリ ≤ 予約されたメモリ。
以下のマッチングシナリオは、Pod のカードタイプが予約されたカードタイプと同じであることを前提としています：
控除ルール | シナリオの説明 | 結果と説明 |
完全一致または下位互換 | 予約：1 × (1 GPU、16 vCPU、128 GB)。 Pod 作成：1 × (1 GPU、8 vCPU、16 GB)。 | 結果： 説明：Pod が必要とするリソース (GPU の数、CPU、メモリ) が予約された仕様を超えていないため、一致が見つかります。この Pod は容量予約全体を使用します。 |
最小仕様優先 | 予約：
Pod 作成：1 × (1 GPU、5 vCPU、30 GB)。 | 結果： 説明：リソース使用率を最大化するため、システムは Pod の要件に最も適合する最小の予約を優先します。 |
先入れ先出し (FIFO) | 予約：4 × (1 GPU、10 vCPU、80 GB)、異なる時間に作成。 Pod 作成：4 × (1 GPU、5 vCPU、30 GB)。 | 結果： 説明：同じ仕様の予約については、先入れ先出しの原則に従います。 |
マルチ GPU 仕様の原子性 (分割不可) | 予約：1 × (4 GPU、46 vCPU、450 GB)。 Pod 作成：4 × (1 GPU、10 vCPU、60 GB)。 | 結果： 説明：マルチ GPU 予約は原子的な単位であり、複数のシングル GPU Pod に対応するために分割することはできません。これらの 4 つの Pod は、代わりに従量課金インスタンスとして作成されます。 |
混合仕様のマッチング | 予約：
Pod 作成：
| 結果： 説明：残りの Pod は残りの 4-GPU 予約に一致できず、代わりに従量課金インスタンスとして作成されます。 |
リアルタイム動的マッチング | 既存の従量課金 Pod：1 × (1 GPU、5 vCPU、30 GB) 新規予約購入：1 × (1 GPU、10 vCPU、80 GB) | 結果： 説明：容量予約は、予約の仕様に一致する既存の従量課金 Pod に適用できます。 |