# 機械学習用のキャパシティブロック
ML 用のキャパシティブロックを使用すると、短期間の機械学習ワークロードをサポートするため、GPU ベースの高速コンピューティングインスタンスを将来の日付で予約できます。キャパシティブロック内で実行されるインスタンスは、[Amazon EC2 UltraClusters](https://aws.amazon.com/ec2/ultraclusters/) 内に自動的に互いに近く配置され、低レイテンシーでペタビットスケールのノンブロッキングネットワーキングを実現します。
キャパシティブロックを使用して、Amazon EC2 UltraServers のキャパシティを予約することもできます。UltraServers は、低レイテンシー、高帯域幅のアクセラレーター相互接続内で複数の Amazon EC2 インスタンスを接続します。UltraServers を使用することにより、トレーニング、ファインチューニング、推論において、コンピューティングとメモリを大量に消費する AI/ML ワークロードを処理できます。詳細については、「[Amazon EC2 UltraServers](https://aws.amazon.com/ec2/ultraservers/)」を参照してください。
キャパシティブロックを使用すると、GPU インスタンスのキャパシティを今後いつ使用できるかを確認でき、都合のよい時間にキャパシティブロックを開始するようにスケジュールできます。キャパシティブロックを予約すると、GPU インスタンスのキャパシティを予測して確保することができます。料金は必要な時間分しか発生しません。ML ワークロードを一度に数日間または数週間サポートするために GPU が必要であり、GPU インスタンスを使用していない間は予約の料金を支払いたくないという場合は、キャパシティブロックをお勧めします。
キャパシティブロックの一般的なユースケースは以下のとおりです。
+ **機械学習モデルトレーニングとファインチューニング** — 機械学習モデルトレーニングとファインチューニングを完了するために予約した GPU インスタンスに、中断なしにアクセスできます。
+ **ML 実験とプロトタイプ** — GPU インスタンスを必要とする実験の実行およびプロトタイプの構築を短期間で行えます。
キャパシティブロックは、一部の AWS リージョンで特定のインスタンスタイプで使用できます。詳細については、「[サポートされているインスタンスタイプとリージョン](#capacity-blocks-prerequisites)」を参照してください。
キャパシティブロックは、最大 8 週間先を開始時刻に設定して予約することができます。各キャパシティブロックには最大 64 件、キャパシティブロック全体では最大 256 件のインスタンスを含めることが可能です。
**Topics**
+ [サポートされているインスタンスタイプとリージョン](#capacity-blocks-prerequisites)
+ [サポートされているプラットフォーム](#capacity-blocks-platforms)
+ [考慮事項](#capacity-blocks-considerations)
+ [関連リソース](#capacity-blocks-related-resources)
+ [Amazon EC2 キャパシティブロックの仕組み](capacity-blocks-how.md)
+ [キャパシティブロックの料金と請求](capacity-blocks-pricing-billing.md)
+ [キャパシティブロックを見つけて購入する](capacity-blocks-purchase.md)
+ [キャパシティブロックを使用してインスタンスを起動する](capacity-blocks-launch.md)
+ [キャパシティブロックを表示する](capacity-blocks-view.md)
+ [キャパシティブロックを拡張](capacity-blocks-extend.md)
+ [キャパシティブロックを共有する](capacity-blocks-share.md)
+ [UltraServer キャパシティブロックのリソースグループを作成する](cb-group.md)
+ [EventBridge を使用してキャパシティブロックをモニタリングする](capacity-blocks-monitor.md)
+ [AWS CloudTrail を使用したキャパシティブロック API コールのロギング](capacity-blocks-logging-using-cloudtrail.md)
## サポートされているインスタンスタイプとリージョン
インスタンスおよび UltraServer キャパシティブロックは、次のインスタンスタイプと AWS リージョンで使用できます。
**注記**
64 インスタンスのキャパシティブロックサイズは、すべての AWS リージョン のすべてのインスタンスタイプでサポートされているわけではありません。
### インスタンスキャパシティブロック
+ **`p6-b300.48xlarge`**
+ 米国西部 (オレゴン) - `us-west-2`
+ **`p6-b200.48xlarge`**
+ 米国東部 (バージニア北部) - `us-east-1`
+ 米国東部 (オハイオ) — `us-east-2`
+ 米国西部 (オレゴン) - `us-west-2`
+ **`p5.4xlarge`**
+ 米国東部 (バージニア北部) - `us-east-1`
+ 米国東部 (オハイオ) — `us-east-2`
+ 米国西部 (オレゴン) - `us-west-2`
+ 欧州 (ロンドン) — `eu-west-2`
+ アジアパシフィック (ムンバイ) – `ap-south-1`
+ アジアパシフィック (東京) — `ap-northeast-1`
+ アジアパシフィック (シドニー) — `ap-southeast-2`
+ 南米 (サンパウロ) – `sa-east-1`
+ **`p5.48xlarge`**
+ 米国東部 (バージニア北部) - `us-east-1`
+ 米国東部 (オハイオ) — `us-east-2`
+ 米国西部 (北カリフォルニア) — `us-west-1`
+ 米国西部 (オレゴン) - `us-west-2`
+ 欧州 (ストックホルム) — `eu-north-1`
+ 欧州 (ロンドン) — `eu-west-2`
+ 南米 (サンパウロ) – `sa-east-1`
+ アジアパシフィック (東京) — `ap-northeast-1`
+ アジアパシフィック (ムンバイ) – `ap-south-1`
+ アジアパシフィック (シドニー) — `ap-southeast-2`
+ アジアパシフィック (ジャカルタ) — `ap-southeast-3`
+ 米国東部 (アトランタ) ローカルゾーン — `us-east-1-atl-2a`
+ **`p5e.48xlarge`**
+ 米国東部 (バージニア北部) - `us-east-1`
+ 米国東部 (オハイオ) — `us-east-2`
+ 米国西部 (北カリフォルニア) — `us-west-1`
+ 米国西部 (オレゴン) - `us-west-2`
+ 欧州 (ストックホルム) — `eu-north-1`
+ 欧州 (ロンドン) — `eu-west-2`
+ 欧州 (スペイン) — `eu-south-2`
+ 南米 (サンパウロ) – `sa-east-1`
+ アジアパシフィック (東京) — `ap-northeast-1`
+ アジアパシフィック (ソウル) – `ap-northeast-2`
+ アジアパシフィック (ムンバイ) – `ap-south-1`
+ アジアパシフィック (ジャカルタ) — `ap-southeast-3`
+ 米国西部 (フェニックス) ローカルゾーン — `us-west-2-phx-2a`
+ **`p4d.24xlarge`**
+ 米国東部 (バージニア北部) - `us-east-1`
+ 米国東部 (オハイオ) — `us-east-2`
+ 米国西部 (オレゴン) - `us-west-2`
+ **`p4de.24xlarge`**
+ 米国東部 (バージニア北部) - `us-east-1`
+ 米国西部 (オレゴン) - `us-west-2`
+ **`trn1.32xlarge`**
+ 米国東部 (バージニア北部) - `us-east-1`
+ 米国東部 (オハイオ) — `us-east-2`
+ 米国西部 (北カリフォルニア) — `us-west-1`
+ 米国西部 (オレゴン) - `us-west-2`
+ 欧州 (ストックホルム) — `eu-north-1`
+ アジアパシフィック (ムンバイ) – `ap-south-1`
+ アジアパシフィック (シドニー) — `ap-southeast-2`
+ アジアパシフィック (メルボルン) — `ap-southeast-4`
+ **`trn2.3xlarge `**
+ アジアパシフィック (メルボルン) — `ap-southeast-4`
+ 南米 (サンパウロ) – `sa-east-1`
+ **`trn2.48xlarge`**
+ 米国東部 (オハイオ) — `us-east-2`
### UltraServer キャパシティブロック
+ **`Trn2`**
+ 米国東部 (オハイオ) — `us-east-2`
+ **`P6e-GB200`**
+ 米国東部 (ダラス) ローカルゾーン — `us-east-1-dfw-2a`
## サポートされているプラットフォーム
ML 用のキャパシティブロックは、現在、デフォルトテナンシーのインスタンスおよび UltraServer のみをサポートしています。AWS マネジメントコンソール を使用してキャパシティブロックを購入する場合、デフォルトのプラットフォームは Linux/UNIX です。AWS Command Line Interface AWS CLIまたは AWS SDK を使用してキャパシティブロックを購入する場合、以下のプラットフォームオプションを使用できます。
+ Linux/UNIX
+ Red Hat Enterprise Linux
+ RHEL with HA
+ SUSE Linux
+ Ubuntu Pro
## 考慮事項
キャパシティブロックを使用するときは、事前に以下の詳細と制限を念頭におきます。
+ UltraServer キャパシティブロックに影響を与える障害が検出された場合、ユーザーに通知されますが、通常はキャパシティブロックのインスタンスを終了するアクションが実行されません。ワークロードへの意図しない中断を最小限に抑えるためです。この通知を受け取った後に UltraServer キャパシティブロックを現状のままで引き続き使用するか、UltraServer キャパシティブロックのインスタンスをすべて終了し、AWS サポートケースを送信することで修復をリクエストできます。サポートケースを受け取ったら、修復が完了した際にユーザーが通知されます。インスタンスを UltraServer キャパシティブロックに再起動できます。
+ `P6e-GB200` UltraServer キャパシティブロックの場合、キャパシティブロックの終了時刻の 60 分以上前にインスタンスを終了する必要があります。
+ ローカルゾーン内のキャパシティブロックを購入して使用するには、ローカルゾーンにオプトインされている必要があります。
+ 各キャパシティブロックには最大 64 件、キャパシティブロック全体では最大 256 件のインスタンスを含めることが可能です。
+ 早くて 30 分で開始できるキャパシティブロックサービスを記述できます。
+ キャパシティブロックは、協定世界時 (UTC) の午前 11 時 30 分に終了します。
+ キャパシティブロック内で実行しているインスタンスの終了プロセスは、予約の最終日の協定世界時 (UTC) 午前 11 時に始まります。
+ キャパシティブロックの開始時刻は最大 8 週間先を予約できます。
+ キャパシティブロックはキャンセルはできません。
+ UltraServer キャパシティブロックは AWS アカウント間や AWS 組織内で共有することはできません。
+ キャパシティブロックを[移動](capacity-reservations-move.md)または[分割](capacity-reservations-split.md)することはできません。
+ リソースグループで使用できるのは UltraServer キャパシティブロックのみです。インスタンスキャパシティブロックはリソースグループでは使用できません。詳細については、「[UltraServer キャパシティブロックのリソースグループを作成する](cb-group.md)」を参照してください。
+ AWS 組織内の全アカウントでキャパシティブロックに予約できるインスタンスの合計数は、特定の日に 256 インスタンスを超えることはできません。
+ キャパシティブロックを使用するには、インスタンスが予約 ID を明確にターゲットにしている必要があります。
+ キャパシティブロック内のインスタンスは、オンデマンドインスタンスの制限にはカウントされません。
+ カスタム AMI を使用する P5 インスタンスの場合は、[EFA に必要なソフトウェアと設定があることを確認してください](gpu-instances-started.md)。
+ Amazon EKS 管理された型ノードグループについては、「[Create a managed node group with Amazon EC2 Capacity Blocks for ML](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html)」を参照してください。Amazon EKS セルフ管理された型ノードグループについては、「[セルフ管理された型ノードで機械学習用のキャパシティブロックを使用する](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks.html)」を参照してください。
## 関連リソース
キャパシティブロックを作成したら、キャパシティブロックを使用して次の操作を実行できます。
+ インスタンスをキャパシティブロックで起動します。詳細については、「[キャパシティブロックを使用してインスタンスを起動する](capacity-blocks-launch.md)」を参照してください。
+ Amazon EC2 Auto Scaling グループを作成します。詳細については、「[Amazon EC2 Auto Scaling ユーザーガイド](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-template-capacity-blocks.html)」の「*Use Capacity Blocks for machine learning workloads*」を参照してください。
**注記**
Amazon EC2 Auto Scaling または Amazon EKS を使用する場合は、キャパシティブロック予約の開始時にスケーリングを実行するようにスケジュールできます。スケジュールされたスケーリングでは、AWS が再試行を自動的に処理するため、一時的な障害を処理するための再試行ロジックの実装について心配する必要はありません。
+ AWS Parallel Computing Service を使用して機械学習ワークフローを強化します。詳細については、「[Capacity Blocks support for AWS Parallel Computing Service](https://aws.amazon.com/blogs/hpc/announcing-capacity-blocks-support-for-aws-parallel-computing-service/)」を参照してください。
+ AWS ParallelCluster で ML ワークフローを強化します。詳細については、「[Enhancing ML workflows with AWS ParallelCluster and Amazon EC2 Capacity Blocks for ML](https://aws.amazon.com/blogs/hpc/enhancing-ml-workflows-with-aws-parallelcluster-and-amazon-ec2-capacity-blocks-for-ml/)」を参照してください。
AWS Parallel Computing Service の詳細については、「[AWS Parallel Computing Service とは](https://docs.aws.amazon.com/pcs/latest/userguide/what-is-service.html)」を参照してください。
AWS ParallelClusterの詳細については、[とはAWS ParallelCluster](https://docs.aws.amazon.com/parallelcluster/latest/ug/what-is-aws-parallelcluster.html)を参照してください。