HAQM Web Services ブログ
HAQM EC2 と SageMaker AI による AI モデル構築のコスト最適化
AWS の生成 AI ワークロードのコスト最適化に関するシリーズの第 2 回目のブログへようこそ。最初のブログでは、生成 AI を適用するためのさまざまな実装アプローチとクラウド財務管理の原則に関する概要を説明しました。今回は、HAQM Elastic Compute Cloud (HAQM EC2) と HAQM SageMaker AI を使用し、カスタム AI モデルの構築とデプロイに関するコスト最適化戦略について詳しく説明します。大規模な言語モデルをトレーニングする場合、既存のモデルをファインチューニングする場合や推論エンドポイントをデプロイする場合いずれにも関連する、HAQM EC2 のインスタンスタイプの選定、キャパシティ管理やコミットメントプランニングなどの主要なコスト要因を説明します。また、HAQM SageMaker AI のモデル最適化、トレーニング効率やデプロイ戦略についても説明します。これらのプラクティスは、独自の AI インフラストラクチャーの管理に伴う柔軟性と制御を維持しながら、パフォーマンス要件とコスト効率のバランスを取るのに役立ちます。
HAQM EC2 と SageMaker AI は、生成 AI の基盤となる AWS サービスのうちの 2 つです。HAQM EC2 はトレーニングと推論に必要なスケーラブルなコンピューティングを提供し、SageMaker AI はモデル開発、デプロイや最適化のための組み込みツールを提供します。生成 AI ワークロードには高性能アクセラレーター (GPU、Trainium や Inferentia) と膨大な処理が必要であり、効率的なリソース管理がないとコストが高くなる可能性があるため、コスト最適化は非常に重要です。以下のコスト最適化戦略を活用することで、パフォーマンスとスケーラビリティを維持しながらコストを削減できます。
画像 1「HAQM EC2 と SageMaker AI のコスト最適化戦略:コスト削減 vs 労力」このグラフは説明のみを目的としています。実際に必要な労力と達成されるコスト削減は、実装規模、インフラストラクチャー、およびチームの専門知識に基づいて変わる場合があります。
HAQM EC2
1. 最適なインスタンスタイプの選択
HAQM EC2 インスタンスは自分でデプロイを管理する主要コンポーネントであり、適切なインスタンスタイプを選択することが重要です。AWS Graviton 搭載のような CPU ベースのインスタンスタイプでは、AWS Compute Optimizer を使用してインスタンスを簡単に分析し、適切なサイズを設定できます。生成 AI ソリューションには通常、NVIDIA GPU または Tranium や Inferentia などの AWS AI チップを搭載した高速インスタンスが必要です。AWS Trainium および Inferentia ベースのインスタンスは、トレーニングと推論のコストパフォーマンスが最大 30 – 50% 向上し、ワークロードにおいて費用対効果の高いオプションとなります。GPU ベースのインスタンスを適切なサイズにするには、CloudWatch エージェントを使用した NVIDIA GPU の利用率の有効化を参照してください。これにより、AWS Compute Optimizer は NVIDIA GPU の使用率を収集し、適切なサイズの推奨事項を提示できます。
データセット、ワークロードやモデルに対するインスタンスのパフォーマンスをより包括的に分析するには、コンテキストテストを使用する必要があります。FM Bench などのツールは、さまざまなインスタンスタイプとサービングスタックのパフォーマンスを分析することで、このテストを合理化するのに役立ちます。推論レイテンシー、1 分あたりのトランザクション数、エラー率やトランザクションあたりのコストを示すマークダウンレポートを通じて、最も費用対効果の高い構成を特定するのに役立ちます。レポートには、説明文、表や図が含まれており、インスタンスを適切なサイズに設定し、必要な分だけを支払っていることを確認するのに必要な情報が記載されています。
2. スマートキャパシティ管理
使用するインスタンスタイプを理解したら、次のステップはキャパシティ管理戦略を理解することです。考えるべきよくある質問は次のとおりです。
- インスタンスはいくつ必要ですか?
- どれくらいの頻度で実行する必要がありますか？
- どれくらいの期間必要ですか？
オンデマンドキャパシティ予約 (ODCR)
ODCR では、特定のアベイラビリティーゾーン (AZ) にある HAQM EC2 インスタンスのコンピューティングキャパシティを予約できます。機械学習 (ML) モデルのトレーニングとファインチューニングのために ODCR を使用することで、予約した高速インスタンス (GPU、Trainium や Inferentia) に中断されることなくアクセスできます。キャパシティ要件が厳しい場合や、ソリューションでキャパシティの確保が必要な場合は、ODCR の使用を検討してください。
ODCR は長期コミットメントを必要とせず、いつでも変更またはキャンセルできます。キャパシティー予約は、予約されているキャパシティーでインスタンスを実行するかどうかにかかわらず、同等のオンデマンド料金が請求されます。アカウントに ODCR がプロビジョニングされるとすぐに請求が開始され、キャパシティ予約がアカウントにプロビジョニングされている間も請求は継続されます。
ODCR を効率的に使用するには、使用率を監視することが重要です。これを実現する方法の 1 つは、HAQM CloudWatch を利用することです。CloudWatch では、「AvailableInstanceCount」などのメトリクスを監視するアラームを設定できます。このメトリクスは、ODCR 内の未使用のインスタンスの数を判断するのに役立ちます。ODCR を監視するもう 1 つの方法は、AWS Cost Explorer または Cost and Usage Reports (CUR) を利用することです。これらのツールを使用すると、「UnusedBox」または「UnusedDed」を含む使用タイプをフィルタリングできます。これにより、キャパシティ予約したが使用されていないインスタンスの数が表示されます。さらに、アカウントの ODCR のキャパシティ使用率が 20% を下回ると、AWS Health Dashboard から E メールが送信されます。
インスタンススケジューリング
ワークロードを年中無休で実行する必要がない場合は、AWS Instance Scheduler の使用を検討する必要があります。AWS Instance Scheduler は、HAQM Elastic Compute Cloud (EC2) と HAQM Relational Database Service (RDS) インスタンスの起動と停止を自動化するように設計されたソリューションです。この自動化は、必要なときにのみリソースを実行できるようにすることで、オペレーションコストの削減に役立ちます。Instance Scheduler は複数の AWS アカウントで動作するように設定できるため、大規模な組織での有用性が高まります。スケジューラーは AWS CloudFormation テンプレートを用いてインストールされ、スケジュール、サービス (HAQM EC2 または HAQM RDS) やタイムゾーン設定などのさまざまなパラメータをカスタマイズできます。この柔軟性により、スケジューラーを特定のニーズに合わせて調整できるため、効率的なリソース管理とコストの最適化が可能になります。
キャパシティ確保の目的でインスタンスをシャットダウンまたはリリースできない場合は、ODCR と共に Instance Scheduler を使用することを検討してください。そうすれば、予備のキャパシティを他のアカウント、チーム、またはワークロードに一時的にシフトできます。この方法ではコスト削減にはならないかもしれませんが、利用しているインスタンスからより多くの価値を引き出すことができます。
3. 戦略的コミットメント計画
AWS コミットメント戦略を策定する際には、ワークロードの存続期間 (1 年または 3 年)、インスタンスファミリーの要件やリージョンの柔軟性といった要素が節約効果を最大化するのに役立ちます。Savings Plans Purchase Analyzer は、過去の利用パターンを調べるのに役立ち、これらの要因に基づいて最適なコミットメントを推奨してくれます。特定のリージョンで特定のインスタンスファミリーを必要とする場合には、EC2 Instance Savings Plans (EC2SPs) が最も大きな割引を提供します。また、Compute Savings Plans (CSPs) では、割引率が下がりますが、インスタンスの世代やリージョンを問わない高い柔軟性を提供します。CSPs を使用すると、コミットされた割引特典を失うことなく、リージョン間でワークロードを移動したり、新しいインスタンスファミリーにアップグレードしたりできます。どちらを選択するかにもよりますが、オンデマンド料金と比較して最大 72% 節約できます。そのため、Savings Plans は AWS インフラストラクチャーにとってインパクトのあるコスト最適化プランとなっています。
4. リソース効率の最大化
アクセラレーター (GPU、Trainium や Inferentia) の使用率を追跡することで、リソースがどの程度効率的に利用されているかをより理解できます。GPU 使用率メトリクスは、インスタンス要件の検証、効率の最大化、またチームやプロジェクト間でのリソース共有の機会特定に役立ちます。CPU 使用率の監視は比較的簡単ですが、GPU 監視には独特の課題があります。前述したように、最適なインスタンスタイプを選択する際、GPU 使用率としてより詳細なメトリクスが必要になります。GPU の使用率を推定するために使用できる指標は、温度と消費電力の 2 つです。これらのメトリクスは CloudWatch エージェントから取得でき、このアプローチにより GPU 飽和度を推定できるため、リソースの使用パターンに関する重要な洞察が得られます。この見積もりにより、既存のインフラストラクチャーからより大きな効用を得ることができ、総所有コスト (TCO)の削減につながります。
（画像内訳：生成 AI の効率性を評価する上で最も難しい側面の 1 つは、リソースがどれだけうまく利用されているかを理解することです。特に GPU に関しては、従来のパフォーマンス指標だけでは必ずしもすべてを把握できるとは限りません。消費電力や熱出力などの要素を評価することで、スループットやレイテンシだけでなく、実際の効率をより深く把握できます。生成 AI ワークロードの最適化は、リソースをどれだけ長く使用しているかだけでなく、リソースの機能を最大限に活用しているかどうかも重要です。
Brent Segner, Distinguished Engineer, Capital One）
HAQM SageMaker AI
AI/ML の取り組みを加速させていると、戦略的な決定を迫られることになります。機械学習インフラストラクチャーの構築とメンテナンスにリソースを投資すべきか、それともビジネス成果の推進に向けて努力を振り向けるべきか、というものです。HAQM SageMaker AI はこのジレンマに対する理想的なソリューションであり、必要な柔軟性を維持しながら、差別化されていない重い作業を排除するフルマネージドサービスを提供します。SageMaker JumpStart は、構築済みのソリューション、すぐに導入できるモデルやサンプルノートブックを提供することで、すぐに使い始めるのに役立ちます。SageMaker AI への取り組みを始めたばかりでも、既存の実装の最適化を検討している場合でも、これらの戦略は、より効率的で費用対効果の高い AI および 機械学習ソリューションの構築に役立ちます。
1. 成功のためのライトサイジング
SageMaker AI インスタンスのタイプとサイズを最適化すると、ソリューションのパフォーマンスとコスト効率の両方に効果がある場合があります。使用パターンを注意深く分析し、SageMaker AI インスタンスを戦略的に適切なサイズにすることで、機械学習インフラストラクチャーのコストを削減できます。ワークロードに適したインスタンスタイプとサイズを選択するには、テストが重要です。前述した FM Bench は、このプロセスを簡単にするための貴重なツールです。
2. モデルのキャパシティとコストバランス
機械学習ワークロードに適したモデルを選択することは、効果的な SageMaker AI プロジェクトを構築する上で最も重要な決定の 1 つです。慎重にモデル選択をすることで、パフォーマンスとコスト効率の両方を最大 45% 向上させることができます。次の 3 つの重要な要素を評価する体系的なアプローチをお勧めします。1) 特定のユースケース要件、2) 利用可能な計算リソース、3) 予算。たとえば、大規模言語モデル (LLM) は優れた機能を備えていますが、 単純なモデルで事足りる簡単なタスクでは必ずしも最も費用対効果の高いソリューションであるとは限りません。SageMaker Jumpstart のモデルから始めることで、最適な結果を得ることができます。SageMaker Jumpstart は、基盤モデル、組み込みアルゴリズムやビルド済みの機械学習ソリューションを備えたハブです。その後、より高度な (そして多くの場合より高価な) モデルによって得られるメリットが、追加の計算コストと財務コストを正当化するかどうかを評価できます。このような反復的なモデル選択アプローチは、多くの場合、技術的に優れ、より持続可能なソリューションにつながります。
3. SageMaker AI Savings Plans の活用
機械学習ソリューションを大規模に運用するには、運用の柔軟性を維持しながらコストを最適化することが重要です。Machine Learning Savings Plans (MLSPs) は、従量制の価格設定モデルよりも、SageMaker AI の料金を最大 64% 節約できるコミットメントです。これらのプランでは、1 年または 3 年の期間にわたって一定量の使用量（1 時間あたりの金額で算出）のコミットメントが必要です。MLSPs を特に強力にしているのは、その柔軟性です。割引は、SageMaker Studio ノートブック、SageMaker オンデマンドノートブック、SageMaker Processing、SageMaker Data Wrangler、SageMaker トレーニング、SageMaker リアルタイム推論や SageMaker バッチ変換の対象となる SageMaker ML インスタンスの使用に自動的に適用されます。つまり、コミットメントによる削減効果を失うことを心配することなく、機械学習インフラストラクチャーを自由に革新して調整できるということです。MLSPs は、特に継続的な機械学習の運用において、手間をかけずに大幅なコスト最適化を実現できます。コスト効率を維持しながら機械学習の取り組みを拡大したいと考えている場合、MLSPs はシンプルかつ効果的であるため欠かせません。
4. スポットインスタンスによるトレーニングのコスト最適化
HAQM SageMaker AI のマネージドスポットトレーニングは、機械学習ワークロードのコスト最適化戦略を提供します。スポットインスタンス価格を活用することで、オンデマンドインスタンスと比較してトレーニングコストを最大 90% 削減できるため、予算が限られているプロジェクトにとって価値のあるオプションとなります。この費用対効果の高いアプローチは、時折中断しても許容できる、時間にセンシティブではないトレーニング作業に特に適しています。AWS Graviton プロセッサと組み合わせると、コストパフォーマンスの面でさらに大きなメリットが得られます。このプロセスを使いやすくするために、SageMaker AI ではスポットインスタンスのライフサイクルを自動的に管理できます。これは、インスタンスが再利用された場合でもトレーニングの進行状況が維持されるように、チェックポイントを使用して、モデルの状態を保存することで実現されます。そのため、開発やテストの環境、およびトレーニング時間に柔軟性があるその他の環境に最適なソリューションになります。
5. 適切な推論戦略の選択
HAQM SageMaker AI は、様々なユースケースとコスト構造に合わせて設計された推論デプロイのオプションをいくつか提供しています。詳細については、推論コスト最適化のベストプラクティスを参照してください。リアルタイム推論ではレイテンシーは低くなりますが、インスタンスが常時実行されるため、継続的なコストが発生します。リアルタイム推論は、即時対応が必要なアプリケーションに最適です。断続的なワークロードのコストを削減するために導入された HAQM SageMaker Serverless Inference は、使用していないときは自動的に エンドポイントをゼロまでスケールダウンさせ、呼び出し中に使用されたコンピューティング時間に対してのみ課金されます。バッチ処理の場合、SageMaker AI バッチ変換 は、永続的なエンドポイントを維持せずに大規模なデータセットを一括処理することにより、最も費用対効果の高いソリューションを提供します。最後に、非同期推論は、リクエストを非同期で処理するため、ペイロードが大きく、処理時間が長く、またリアルタイムに近いレイテンシーが必要な場合に最適です。アイドル時にインスタンスを自動的に停止することでコストを削減できるため、リクエストが処理されているときにのみ支払いが発生します。
これらの最適化戦略を実装することで、高いパフォーマンスとスケーラビリティを維持しながら、インフラストラクチャーのコストを大幅に削減できます。成功の鍵は、これらの選択肢を特定のユースケースやビジネス要件に合わせて調整し、コストを削減するだけでなく、機械学習運用の長期的な成功に向けて最適化することです。
結論：
この投稿では、HAQM EC2 と SageMaker AI を使用してカスタム AI モデルを開発するためのコスト最適化戦略について説明しました。次回のブログでは、スマートモデル選択、ナレッジベースの最適化やキャッシュ戦略など HAQM Bedrock のコスト最適化手法について詳しく説明します。コストを抑えながら基盤モデルの価値を最大化する方法について、次回のブログをお楽しみに。
翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文はこちらです。