re:Invent 2025: TurbonomicによるAgentic AI時代のGPUリソース最適化と自動化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Optimize for AWS with intelligent automation (AIM235)
この動画では、Agentic AIとAIアプリケーションが引き起こす予測不可能なリソース使用パターンとパフォーマンス課題について解説しています。従来の線形プロセスと異なり、Agentic AIは1つのリクエストから数百のマイクロワークロードを生成し、GPUのオーバープロビジョニングや利用率30%程度という非効率を招きます。Turbonomicは、GPU使用率やメモリ飽和度などのメトリクスをリアルタイムで分析し、継続的な最適化アクションを提供します。具体例として、P3DN 24XLargeをP3.8X largeにスケールダウンすることで月額13,800ドルの削減を実現し、Big AI Modelsチームではアイドルリソースを5.3倍削減、スループットを2倍改善した事例が紹介されています。可視性だけでなく、プロアクティブなオートメーションによるリソース最適化の重要性が強調されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Agentic AI がもたらす予測不可能なリソース消費と隠れたコスト
みなさん、こんにちは。このセッションにご参加いただきありがとうございます。今日は、AWS のお客様とハイブリッドクラウドのお客様全般が直面している、成長中のパフォーマンス課題についてお話しします。それは Agentic AI と AI アプリケーション全般に関するものです。これらは非常に強力ですが、リソースの観点から見ると予測不可能な使用パターンを示す傾向があります。この問題がどのように現れるのか、問題そのものについて詳しく説明し、その後、潜在的なソリューションについて議論します。最終的には、Agentic AI を使用しているエンドユーザーのパフォーマンスを維持しながら、コスト配分の効率性も確保して、その急騰を避けるようにしたいのです。
始める前に、Agentic AI の導入状況に関する簡単なポーリングで、オーディエンスからフィードバックをいただきたいと思います。Agentic AI について探索中で、学習を始めたばかりで、それがあなたの環境にどのように適用されるかを知りたいという方は、手を挙げてください。実際に開発中のワークロードがあり、それを見ている、概念実証を実行している方は何人いますか。実際のユーザーがいて、複数のワークストリームが適用されている初期本番環境にいる方は何人ですか。そして最後に、ビジネスクリティカルな段階で、実際のユーザーがいて、これを大規模に使用していて、それが ROI の大きな部分を占めているという方は。まだその成熟度の採用レベルには達していませんが、私たちが顧客から見ているものを考えると、多くのことが理にかなっています。
では、Agentic AI の隠れたコストについて詳しく説明すると、多くの場合、過度なプロビジョニングとリソースの肥大化が見られます。これは主に、人々がパフォーマンスやリソースの決定を平均に基づいて行わないという事実に帰着します。通常、パフォーマンスが低下する可能性があることを懸念しているため、最悪のシナリオを選択します。これは非常に保守的なキャパシティ決定につながります。なぜなら、最終的にはパフォーマンスの低下を恐れているため、GPU を過度にサイズ設定し、RAM ファームを過度に割り当て、ストレージを過度にプロビジョニングすることになるからです。これにより、これらの高価なリソースの多くのアイドルコストが発生します。多くのチームで見られるのは、これらのパフォーマンスバッファを作成することへの懸念から、これらの高価なリソースを過度に割り当て、その後、起こるかもしれないそのピークを恐れているため、静的スケーリングポリシーが導入されているということです。
しかし、これらのスケーリングポリシーの問題は、それらが反応的である傾向があるということです。ピークが発生した場合、スケーリングポリシーが有効になるのはすでに遅すぎます。Agentic AI と AI アプリでは、使用パターンが非常に予測不可能なことが多いです。また、それに対応し続けるには、かなりの人的介入が必要です。そのため、スケーリングポリシーを継続的に確認したり、それに対処するための是正措置を講じたりしています。
Agentic AI がワークロードの動作をどのように変えているかについて話すと、これの多くは、従来のレガシーアプリケーションでは通常、線形プロセスに従うという事実に帰着します。リクエストが入ってきて、処理され、リソースを消費し、これは通常、直線に従います。より多くのユーザーが表示され、例えばサイトにアクセスすると、リソースは線形方式で消費されます。Agentic AI と AI アプリでは、必ずしもそのようには機能しません。非常に予測不可能です。計画を立て、分岐し、その後、時には数百のマイクロワークロードなど、多くの異なるワークロードを生成することができます。Gen AI が別の Agentic AI と通信し、別の Agentic AI と通信し、Agentic AI が複数の API と通信し、これらすべてがバックグラウンドで発生して、時にはアプリケーションを機能不全に陥らせることができるリソーススパイクを作成しています。
例えば、1つのユーザーリクエストが来ると、それが何百もの下流タスクを生成することになり、これが GPU のオーバープロビジョニングにつながります。スロットリングやスパイキングの問題が見られ、実際に私たちが見てきたお客様の中には、オーバープロビジョニングに対処しなければならず、時には本来必要な GPU 時間の 10 倍から 20 倍、利用率が 30 パーセント程度という状況に直面している方もいます。
結局のところ、パフォーマンスのリスクを恐れているために、これらのアイドル状態のリソースがそこに放置されることになり、非常に無駄が生じ、組織にとって隠れた税金のようなものになってしまいます。Agentic AI と AI アプリケーションが本質的に動的であるのと同じように、リソースの使用方法も動的であることを確認する必要があります。
インサイトとアクションのギャップについて話すと、Observability ソリューションがあり、CPU スロットリングが発生しているかどうか、GPU の競合があるかどうか、またはレイテンシーのスパイクがあるかどうかなど、情報を提供するのに優れています。そこで観測することはできますが、実際にそれが起きたときに何をすべきかについては、必ずしも何もしません。事後的に根本原因分析を行って修正することはできますが、実際にはアクションを取りません。
これらのタイプの Agentic AI アプリケーションを FinOps の観点から扱う場合、FinOps は、どのくらい支出しているか、またはショーバックやチャージバックのためにレポートを作成する必要があるかという点で優れた仕事をしています。それを見ることができ、これらのアプリケーションに対して適切に割り当てることができますが、繰り返しになりますが、主にレポート作成に関するものです。GPU のリサイジングを行ったり、これらの動的なシナリオに対処したりするためのものではありません。実際には、コスト配分に関するもので、問題を実際に解決するためのものではありません。
これらの他のソリューションでさえ、オーバーサイジングがデフォルトになってしまいます。この問題について私たちに相談に来られる多くのお客様は、パフォーマンスを心配し、SLO を維持することを懸念しているため、パブリッククラウドで、あるいは場合によってはプライベートクラウドでも、単にオーバーサイジングしてしまうと言われます。静的スケーリングが導入されていますが、これらのアプリケーションの性質上、作業の進め方が非常に動的であるため、需要に対応することができません。リソースの観点から問題を本当に見つめ直し、それをサポートするプラットフォームのための動的リソースを持つことで、常に変わる需要に対応することが非常に重要です。
Turbonomic によるリアルタイム最適化とインテリジェントオートメーション
Turbonomic が対応しているのは、agentic AI ワークロードへのリアルタイム最適化 を提供することです。GPU インスタンス自体から得られるデータ、vCPU と VMM の飽和度、ストレージとネットワークのスループットを分析することで継続的な最適化を実現するアクションを提供しており、これらのメトリクスを時系列で監視しています。その後、これらのメトリクスから得られた情報に基づいて、環境全体にわたって適切なサイジングを行うための意思決定を行います。
私たちは単にその情報を分析するだけでなく、agentic AI アプリケーションから始まるこのサプライチェーン全体を見て、それをサポートしているリソースもリアルタイムでスケールアップ・ダウンしています。EC2、GPU 自体、EKS、そしてハイブリッド環境を見ていますし、もちろん AWS だけでなく、オンプレミスのワークロードや他のパブリッククラウド上のワークロードがある場合もカバーしています。このようにしながら、パフォーマンスを維持して SLO を満たすことを確保しつつ、効率性も保つことでコストをコントロール下に置いています。
GPU 最適化は、agentic AI にとって最も影響力のあるユースケースの一つです。リソースの大部分がそこから来ているからです。ピークが来てより多くのリソースが必要になると、私たちはそれらをリサイズして、必要に応じて追加の GPU インスタンスを投入します。リアルタイムで需要が減少すると、それらのインスタンスをリサイズして削減し、メモリなどの他のリソースも削減して、過度なプロビジョニングを減らし、お客様が直面している課題に対応します。これを継続的に行うことで、人的ミスを大幅に削減でき、agentic AI アプリケーションがパフォーマンスを発揮しながらも、可能な限り効率的に実行されることを確認できます。
では、具体例を見てみましょう。これは私たちのプロダクトのスクリーンショットで、ここで見ているのはペンディングアクション、つまりユーザーが実行できるアクションで、これは手動アクションの例です。Turbonomic は GPU の使用率、GPU メモリ、インスタンスのサイジングと全般的な利用率を分析してきており、この特定の GPU である P3DN 24XLarge（AWS でも最も高価な GPU の一つ）を見ています。私たちが見ている利用率に基づいて、これを P3.8X large にスケールダウンできます。
利用率データを見て、これを SLO と照らし合わせ、これが実行できる安全なアクションであることを知っているため、そうすることができます。ご覧のように、たった 1 つの GPU だけで、月額 13,800 ドルの節約を実現でき、それでもなおパフォーマンスを維持して SLO を満たしています。
では、詳細な部分に少し入っていきたいと思います。これは素晴らしい推奨事項ですが、お客様やオペレーターの皆さんは、このアクションがパフォーマンスを維持できるということをどうやって信頼できるのかを知りたいわけです。ですから、もう一段階詳しい情報を見る必要があります。左側のチャートに表示されているのは、GPU数のパーセンタイルと使用率です。この観測期間の使用率は約13%なので、このEC2インスタンスに紐付いているにもかかわらず、実際にはそこまで使われていません。次にGPUメモリの使用率を見ると、これは約22%前後で推移しており、やはり全体的にはそこまで多くの使用量を示していません。VCPUについては3～4%前後です。つまり、このアプリケーションではそこまで多くのリソースが使われていないということです。
リソースへの影響を見ると、右側の赤いボックスに、現在の状態と推奨アクション後の状態が表示されています。Turbonomicは、現在のGPU数を8から4に削減することを推奨しており、これにより使用率が13%から26%に上がると予測しています。これは予測値です。メモリについては、32ギガバイトから16ギガバイトに削減され、このアクション後の使用率は44%に上がると予測されています。これは非常に安全であり、パフォーマンスの低下は見られません。VCPUは約13%で、ストレージスループットとネットワークスループットも同様の状況です。
ここで素晴らしいのは、オペレーターとして、このアクションを見て安心できるということです。なぜなら、パフォーマンスがそこに存在することを知っており、SLOを維持し続けることができるからです。そのため、安心してこのアクションを実行でき、さらには自動化することもできます。このアクションを実行すれば、物事が前向きに進むという確信を持つことができるのです。単にこのアクションでコストが削減されるから実行すべきだと言っているのではなく、ユーザーに対して、このアクションを実行しても、さらには自動化しても、物事が前向きに進むという確信を与えているのです。
このアクションの全体的なまとめとしては、オンデマンドレートが1時間あたり31.21ドルから12ドルに下がります。これはRIとセービングスプランも考慮に入れており、その後、オンデマンドコストが月あたり約13,800ドルの削減に相当します。これはたった1つのGPUインスタンスからの削減です。ですから、かなり大きな投資がある場合を想像してみてください。さらに大きな削減が見られるでしょう。
では、インテリジェントオートメーションがどのようにしてAWS環境を本当に変革できるのかについて、もう少し詳しく説明しましょう。スマートGPU最適化についてはたくさん話してきました。私たちが行うことは、それらのGPUを自動的にチューニングすることです。リアルタイムで需要スパイクに基づいて右サイズ化を行い、その後、コスト効率の観点からできるだけ効率的になるように調整して、アイドル容量を排除することができます。
また、リアルタイムの可視性も備えています。つまり、私たちのアプリケーションはリアルタイムで実行されているすべてのリソースを監視しています。EC2、EKS、GPU環境に至るまで、ビジネスアプリケーション自体からリソースまでをマッピングするサプライチェーンを持っており、これらのリソース全体を見渡して、それらがどのように連携しているかを確認しています。これらのメトリクスを相関させることで、害が生じないようにし、最終的にはアプリケーションが必要なリソースを確実に得られるようにしています。また、サプライチェーン内に潜在的な問題やボトルネックが存在する可能性があることも考慮します。特定の1つのリソースに直撃していないかもしれませんが、私たちはそれを特定し、私たちが行っていることについてプロアクティブに対応するようにしています。
また、オーケストレーター統合も備えており、ポッドプレースメント、アフィニティ、リソースクォータ、スケジューリングなどを理解しています。ですから、コンテナインフラストラクチャと従来のインフラストラクチャレイヤーの両方をビジネスアプリケーション向けに最適化します。また、プロアクティブなオートメーションも備えています。先ほど挙げた例は単一のアクションでしたが、私たちが実行しているアクションを完全に自動化することができるため、人間の介入は必要ありません。潜在的な問題を特定した場合、私たちはそれに対処します。ですから、RCAが必要になったり、事後的に問題解決を試みたりするようなインシデントを経験する必要がありません。
結局のところ、私たちが行っていることの一部は効率性とコスト削減に関するもので、コスト配分はその大きな部分です。私たちはビジネスに売却し、個々のアクションを合計し、発生しているすべてのオートメーションの全体的なROIを合計して、それを顧客に提示します。これも利用可能です。
Big AI Models チームの成功事例と実践的な導入アプローチ
私たちが行ってきた仕事に直接適用される2、3のケーススタディについて説明したいと思います。私たちの内部顧客の1つは Big AI Models チーム、つまり BAM で、これは Watson X の背後にある LLM をサポートしています。彼らが本当に探していたのは、環境を改善して、環境を管理するために必要な手動チューニングを減らすことでした。彼らは数百個のコンテナを持っており、Kubernetes を実行しており、約100個の A100 Nvidia GPU を持っており、本当に彼らがやりたかったのは、これらの GPU をより密集させて、私たちが行っていることからより多くの ROI を得ることができるかを把握することでした。
Turbonomic を使用した後、彼らは素晴らしい結果を見ました。アイドル GPU リソースの削減において 5.3 倍 を達成しました。これにより、ヘッドルームが3から16に増加し、これら16個の GPU とリソースが他のワークロード用に利用可能になりました。レイテンシに影響を与えることなく、2倍のスループット改善を実現しました。これは彼らにとって大きなメリットでした。必要な GPU が13個少なくなり、これらの GPU を他のワークロードに割り当てることができたため、他の GPU をより密集させ、これらの新しい GPU と、まだ割り当てられている GPU からの追加リソースを他の新しい AI ワークロードに割り当てることができたことで、彼らにとって大きな節約になりました。詳しく知りたい場合や詳しく読みたい場合は QR コードをスキャンできますが、繰り返しになりますが、これは私たちが一緒に 取り組んだ素晴らしい例です。
では、今日お伝えしたい3つのポイントがあります。Agentic AIは、その性質上、非常に予測不可能です。多くのリソースが必要で、線形的にはスケールしません。ですから、Agentic AIの導入成熟度曲線に沿ってプロジェクトを考える際には、このことを念頭に置いてください。バースト的で予測不可能な性質があるため、これに対して敏感に対応する必要があります。
可視性だけでは十分ではありません。背後にあるリソースへのアクセスがあり、いくつかの問題が見えるだけでも、それをサポートするために多くの手作業が必要になる可能性があります。これらのインサイトを活用して継続的なアクションを起こし、環境を適切にサイズ調整し、アプリケーションが必要なリソースを確保できるようにするソリューションを持つことが非常に重要です。
まずは1つの高い価値を持つワークロードから始めることができます。パフォーマンスを維持しながら、GPUをより効率的にできることを証明したいアプリケーションを探してください。それをターゲットにして、その後スケールアウトし、結果を見てみましょう。私たちとの協業に関しては、ソリューションを一緒に検討し、パイロットワークロードを特定することをお勧めします。Agentic AIであれ、GPUサービスであれ、パフォーマンスまたはコストのどちらが最も重要かに関わらず、私たちは両方のバランスを取ることができます。
また、ハイブリッドクラウド全体にわたって幅広い統合があります。最適化する多数のAWSサービスがあります。また、VMwareやNutanixなどのプライベートクラウドにも対応しています。OpenShiftとハイブリッド環境、その他のCSPもサポートしています。可観測性とオートメーションを組み合わせる機会もあります。私たちの姉妹製品であるInstanaは、さらに優れたメトリクスを提供して、私たちのオートメーションを強化し、適切なサイズ調整のアクションをさらに良くすることができます。
最後に、本日はお時間をいただきありがとうございます。アンケートへのご回答とフィードバックをいただき、本当に感謝しています。ブースはあちらにありますので、デモをご覧になりたい場合はぜひお立ち寄りください。改めて、本日はお時間をいただきありがとうございました。残りのイベントを楽しんでください。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion