GPU Pod キャパシティ予約 - Container Compute Service - Alibaba Cloud ドキュメントセンター

Pod ベースのキャパシティ予約は、伸縮自在なワークロードにリソースの確実性を提供します。GPU Pod キャパシティ予約は特定のクラスターにバインドする必要はありません。購入時に Pod 仕様、アベイラビリティーゾーン、予約期間などの属性を指定すると、システムは、一致する Pod が従量課金の Pod よりも低価格で、かつ数分以内にオンデマンドで起動することを保証します。

特長

リソースの確実性：GPU Pod キャパシティ予約の有効期間中、システムはリソースが正常に起動できることを保証します。
コスト削減：Pod の起動後は、従量課金レートで課金されます。Pod が実行されていないときは、未使用のキャパシティ予約として、より低い従量課金料金で課金されます。ビジネスニーズに合わせて Pod を起動および終了できます。
リソースの柔軟性：さまざまなビジネス要件を満たすために、異なるリソース仕様で GPU Pod キャパシティ予約を作成できます。

説明

GPU Pod キャパシティ予約は、BestEffort コンピュートタイプの Pod をサポートしていません。
GPU Pod キャパシティ予約は、リージョンやタイプなどの属性が一致する Savings Plans と互換性があります。
GPU Pod キャパシティ予約の作成は、利用可能な在庫状況に依存します。

ユースケース

リアルタイムワークロードの周期的なリソース需要：ビジネスに予測可能な日次または週次のリソース需要パターンがあり、かつタスクをリアルタイムで完了させる必要がある場合。たとえば、リアルタイム推論サービスなどです。
リソース需要の急増や突然のバースト：ビジネスに予期せぬリアルタイムコンピューティングのニーズがあり、影響を避けるために迅速なリソースの提供とスケーリングが必要な場合。たとえば、インターネットビジネスでトレンドとなっているイベントが引き起こすスパイクなどです。

使用方法と課金の例

GPU Pod キャパシティ予約は、従量課金の課金モデルを使用します。キャパシティ予約の有効期間中、料金には以下が含まれます。

キャパシティ予約の 未使用 部分に対する従量課金料金。
起動された Pod に対する従量課金料金。

以下の例では、2 つの GPU Pod キャパシティ予約と 2 つの従量課金 Pod (Pod1 と Pod2) を使用するシナリオを例に、さまざまなステージでのワークフローと課金について説明します。

ステージ 1：キャパシティ予約の購入と作成

開始する前に、GPU キャパシティ予約を有効化してください。

コンテナサービスコンソールで、 容量の予約 > [Create GPU capacity reservation] に移動します。パラメーターを設定し、 [Create capacity reservation] をクリックします。

パラメーター	説明
キャパシティ予約名	キャパシティ予約のカスタム名。
予約タイプ	GPU タイプ。
リージョン	リソースを予約するリージョン。
アベイラビリティーゾーン	リソースを予約するアベイラビリティーゾーン。
リソース仕様	キャパシティ予約の仕様。GPU 数を選択すると、その GPU 数で利用可能な最高の vCPU およびメモリ仕様がシステムによって自動的に選択されます。
予約モード	Pod 予約 (変更不可)。
課金モデル	従量課金 (変更不可)。
数量	指定されたリソース仕様に対する GPU Pod キャパシティ予約の数。

このステージの課金計算は次のとおりです。

ステージ	料金	説明
ステージ 1	なし	キャパシティ予約は作成されていません。

ステージ 2～6：予約の有効期間

有効期間中、設定が 予約された仕様を超えない 限り、いつでも Pod インスタンスを作成できます。システムは Pod の正常な起動を保証し、対応するキャパシティ予約が利用されます。Pod の GPU (タイプと数)、vCPU、およびメモリは、予約された設定を超えることはできません。一致が成功すると、予約は完全に利用されます。たとえば、1 GPU、10 vCPU、80 GB メモリの予約を購入し、1 GPU、1 vCPU、2 GB メモリの Pod を作成した場合、予約は完全に利用されます。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 タイプと仕様がサポートされます。

GPU タイプ	GPU	vCPU	メモリ (GiB)
L20 (GN8IS)	1 (48 GB ビデオメモリ)	16	128
	2 (48 GB × 2 ビデオメモリ)	32	230
	4 (48 GB × 4 ビデオメモリ)	64	460
	8 (48 GB × 8 ビデオメモリ)	128	920
T4	1 (16 GB ビデオメモリ)	24	90
T4	2 (16 GB × 2 ビデオメモリ)	48	180
A10	1 (24 GB ビデオメモリ)	16	60
	2 (24 GB × 2 ビデオメモリ)	32	120
	4 (24 GB × 4 ビデオメモリ)	64	240
	8 (24 GB × 8 ビデオメモリ)	128	480
P16EN	1 (96 GB ビデオメモリ)	10	80
	2 (96 GB × 2 ビデオメモリ)	22	225
	4 (96 GB × 4 ビデオメモリ)	46	450
	8 (96 GB × 8 ビデオメモリ)	92	900
	16 (96 GB × 16 ビデオメモリ)	184	1800
GU8TF	1 (96 GB ビデオメモリ)	16	128
	2 (96 GB × 2 ビデオメモリ)	46	230
	4 (96 GB × 4 ビデオメモリ)	92	460
	8 (96 GB × 8 ビデオメモリ)	184	920
GU8TEF	1 (141 GB ビデオメモリ)	22	225
	2 (141 GB × 2 ビデオメモリ)	46	450
	4 (141 GB × 4 ビデオメモリ)	92	900
	8 (141 GB × 8 ビデオメモリ)	184	1800
L20X (GX8SF)	1 (141 GB ビデオメモリ)	22	225
	2 (141 GB × 2 ビデオメモリ)	46	450
	4 (141 GB × 4 ビデオメモリ)	92	900
	8 (141 GB × 8 ビデオメモリ)	184	1800

利用ルール

Pod がキャパシティ予約を利用するためには、以下のすべての条件を満たす必要があります。

Pod の GPU タイプは、予約された GPU タイプと完全に一致する必要があります。たとえば、予約と Pod の両方が L20 GPU タイプを使用する場合です。
Pod の GPU 数は、予約された GPU 数と完全に一致する必要があります。たとえば、予約と Pod の両方が 1 GPU である場合です。
Pod の vCPU 数は、予約された vCPU 数以下である必要があります。
Pod のメモリ量は、予約されたメモリ量以下である必要があります。

以下のシナリオでは、Pod の GPU タイプが予約された GPU タイプと一致することを前提としています。

利用原則

シナリオ

結果と説明

完全一致または下方互換性

予約：1 × (1 GPU、16 vCPU、128 GB)。

作成された Pod：1 × (1 GPU、8 vCPU、16 GB)。

結果： $✓$ 利用成功。

説明：Pod のリソース要件 (GPU 数、vCPU、メモリ) が予約された仕様を超えていないため、一致が成功し、予約は完全に利用されます。

最小仕様優先

予約：

1 × (1 GPU、10 vCPU、80 GB)。
1 × (1 GPU、16 vCPU、128 GB)。

作成された Pod：1 × (1 GPU、5 vCPU、30 GB)。

結果： $✓$ 1 GPU、10 vCPU、80 GB の予約が最初に利用されます。

説明：リソース効率を最大化するため、システムは Pod の要件を満たす利用可能な最小の予約を優先します。

先入れ先出し (FIFO)

予約：4 × (1 GPU、10 vCPU、80 GB)、異なる時間に作成。

作成された Pod：4 × (1 GPU、5 vCPU、30 GB)。

結果： $✓$ 4 つの Pod は、予約が作成された順序 (古いものから順) で 4 つの予約を利用します。

説明：仕様が同一の予約については、FIFO 原則が適用されます。

複数 GPU 仕様の原子性 (分割不可)

予約：1 × (4 GPU、46 vCPU、450 GB)。

作成された Pod：4 × (1 GPU、10 vCPU、60 GB)。

結果： $\times$ 予約は利用されません。

説明：複数 GPU の予約はアトミックであり、複数のより小さな Pod を満たすために分割することはできません。これらの 4 つの Pod は、従量課金インスタンスとして作成されます。

混合仕様のマッチング

予約：

1 × (2 GPU、22 vCPU、225 GB)。
1 × (4 GPU、46 vCPU、450 GB)。

作成された Pod：

2 × (1 GPU、12 vCPU、60 GB)。
2 × (2 GPU、20 vCPU、120 GB)。

$\times$ 結果：一部一致。2 GPU、20 vCPU、120 GB の Pod 1 つのみが、2 GPU、22 vCPU、225 GB の予約を正常に利用します。

説明：他の Pod は残りの 4 GPU 予約と一致させることができないため、従量課金インスタンスとして作成されます。

リアルタイム動的マッチング

既存の従量課金 Pod：1 × (1 GPU、5 vCPU、30 GB)

新規に購入した予約：1 × (1 GPU、10 vCPU、80 GB)

結果： $✓$ 新しい予約が正常に作成されると、既存の従量課金 Pod と即座に自動的に照合され、利用されます。

説明：キャパシティ予約は、一致基準を満たす既存の従量課金 Pod によっても利用できます。