re:Invent 2024: Generative AIサービスのコスト管理戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Control the cost of your generative AI services (COP203)
この動画では、Generative AIサービスを構築する際のコスト管理について、3つの異なるアプローチが紹介されています。Self-managedアプローチではAmazon EC2インスタンスの選択やODCRの活用、Spotインスタンスによる最大90%のコスト削減などが解説され、部分的に管理されたAmazon SageMakerでは、MLライフサイクルの各段階での最適化方法が示されます。さらに、Amazon Bedrockを使用したアプローチでは、Knowledge BaseやPrompt cachingなどの機能を活用したコスト最適化手法が紹介されます。Capital OneでのSelf-managed環境での実践例や、GPUの使用効率を判断するための3つの指標など、具体的な事例を交えながら、AIコスト最適化の実践的な戦略が詳しく解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AIコスト最適化：自己紹介と本日のテーマ
みなさん、本日はご参加いただきありがとうございます。私はAlex Headです。Adam RichterとBrent Segnerと共に、Generative AIサービスを構築する際のコスト管理についてお話しさせていただきます。
本日の内容についてご説明させていただきます。まず、この1年間で私たちが経験してきたAIコスト最適化の道のりについてお話しします。次に、AIアプリケーションの構築方法や、AIサービスの活用方法について、さまざまなアプローチをご紹介します。本日は特に、Capital OneからBrentをお招きしており、Self-managed環境での経験について詳しくお話しいただきます。また、私のチームのAdamが、さまざまなマネージドサービスのオプションについてご説明します。このセッションを通じて、皆様がどの段階にいらっしゃっても実践できる、AIコスト最適化の戦略をお持ち帰りいただけると思います。
本題に入る前に、手を挙げていただきたいのですが、すでにAIを使って何かを構築された方はどのくらいいらっしゃいますか？また、まだ計画段階という方は？これで、説明の詳しさを調整させていただきます。私はAWSのOPTICSというチームを率いており、お客様のコストと使用状況データを実用的な洞察に変換し、コスト削減と効率化を支援しています。この1年間、AIコスト最適化の旅を最前線で見てきました。少し振り返ってみましょう。昨年のre:Inventでは、AIの盛り上がりがすごかったですよね。「AIバズ」という言葉で表現するのは控えめかもしれません。その後、FinOpsチームはコストがどれくらいになるのか、どのような形になるのかを問われました。そして、私たちはFinOpsの世界でAIに関連するものの構築を始めました。そして今、私たちはそれを最適化し、これらのコストを理解する方法を模索している段階にいます。
Cosmoを例にしたAIアプリケーションの構築と成功指標
AIの構築方法と最適化について説明していく中で、話が少し理論的になりがちです。そこで今日は、Cosmoという例を使って説明していきます。これにより、皆様が構築しようとしているものと関連付けて考えていただけると思います。では、Cosmoをご紹介します。夢を解釈するAIコンパニオンです。雲の上にお城を建てたい、火星でレストランを開きたい、そんな夢もCosmoなら対応できます。
Cosmoがどのように機能するのか、AIの用語を使って例を説明させていただきます。「Hey Cosmo、虹色のお城を建てよう」と言うと、3つの重要なステップが実行されます。まず、Cosmoはリクエストをトークンに分解します。これは、テキストの小さな単位で、単語や単語の一部になります。次に、Cosmoはナレッジソースにアクセスします。夢のガイド、色彩科学、城の建築など、参照する知識源です。最後に、簡単な応答や火星のレストランの設計図、ビジュアルガイドなど、さまざまな出力を生成できます。
では、Cosmoの仕組みが分かったところで、成功とは具体的にどういう状態を指すのでしょうか？私たちがお客様向けに、あるいは自社で開発しているAIアプリケーションを見る際、4つの重要な指標に注目しています。1つ目はレスポンス速度です。これはとてもシンプルです。例えば、夢想家がCosmoに虹色の城の建設について尋ねた時、どれだけ早く応答できるか、ということです。2つ目はリソース効率性です。これはコスト最適化に関する細かな部分です。価格はいくらになるのか？経理部門にいくらの支出を報告することになるのか？次に信頼性と柔軟性です。Cosmoはどんな状況にも対応できる必要があります。世界中どこでもCosmoを使えるのか、それとも特定の地域でしか使えないのか？最後に品質と深さです。これは単なるツリーハウスを建てることと、熱帯雨林にソーラーパネルを備えた持続可能なツリーハウスを建てることの違いのようなものです。
私たち3人がステージに立っているのが面白いのは、それぞれがCosmoに対して全く異なるアプローチを取るということです。
私個人としては、財務、ビジネス、技術的な考慮事項のバランスを取るリーダーとして、Fully Managedな世界に傾倒しています。Brentは、エンジニアリングのバックグラウンドを持つあなたは、異なる見方をするかもしれません。パブリッククラウド、プライベートクラウド、マルチクラウドで20年の経験がある私の場合、明らかにSelf-Managedを好みます。Adamは最適化のスペシャリストとして、また違った意見を持っているかもしれません。
私は、パワーとカスタマイズ性のブレンドを追求しています。Self-Managedほどの完全なカスタマイズ性は必要ありませんが、Fully Managedソリューションには存在しないかもしれない一部の機能を変更できる柔軟性は必要です。そのため、私は中間的な立場を取っており、特にServerlessインフラストラクチャーとシンプルなAPIを提供するAmazon Bedrockに傾倒しています。これによって、コストを望ましいレベルに保つことができます。
Self-Managed環境でのAIインフラ最適化戦略
私たちの例に従って、あなたや組織がCosmoのようなソリューションを構築することを想像してみてください。Alexが指摘したように、4つの異なるパスがありますが、まずは最も柔軟でカスタマイズ可能なSelf-Managedから始めましょう。まず考えるべきは、自分の環境でこれを構築する場合どうなるかということです。高速なコンピューティング能力を持つAmazon EC2インスタンスを使用し、独自のモデルを持ち込み、ソフトウェアと設定に責任を持ち、トレーニング、チューニング、推論を行うことになります。これらすべてが、ほとんどの場合、あなたのチームの責任となります。AIやビッグデータの専門知識を持つチームが必要になるでしょう。
今回は、AIチームの作り方についてではなく、コストの管理方法や、このような種類のワークロードを効率的に実行する方法についてお話しします。最初に考えるべきことの1つが、インスタンスの選択です。どのようなインスタンスを実行する必要があるでしょうか？P5やP4などのGeneral Purposeインスタンスで十分なのか、それともGravitonやTrainium、そして新しいTrainium 2のような専用インスタンスが必要なのでしょうか？これを判断する最適な方法は、FM benchを使用してテストすることです。このツールを使用すると、サービングスタックやワークロード全体で様々なインスタンスを分析し、お客様の環境に最適なインスタンスを見つけることができます。
適切なインスタンスタイプが分かったら、次に考えるべきは容量管理です。必要なインスタンス数はいくつでしょうか？常時実行する必要があるのか、それともスケジュール化できるのでしょうか？On-Demand Capacity Reservations（ODCR）を使用していますか？そしてODCRを使用している場合、モニタリングは行っていますか？ODCRを使用している方々のために、私が注目している点をいくつか共有させていただきます。ODCRでは、未使用の容量を監視するのは比較的簡単です。Cost ExplorerとCost and Usage Reportの両方に、Usage Typeというフィールドがあります。このフィールド内には、「unused box」または「unused res」というタイプが存在します。
これを時間単位で確認すると、2つのパターンのいずれかが見えてきます。1つ目は、未使用量が平坦なテーブルトップ型のグラフで、これは定期的に使用していない容量を多く確保していることを示しています。この場合、保護している容量を実際に使用するためにインスタンスを起動するか、使用していない容量の保護を減らしてコストを削減する必要があるかもしれません。もう1つのパターンは、サイン波のように上下する波形で、1日の特定の時間帯にインスタンスを多く使用するようなスケーリングを行っている場合に見られます。使用量が増えると、ODCRの未使用量は減少します。この波の谷も、保護しているものの使用していない容量を表しており、同じルールが適用されます。
ODCRの話題から離れて、もう1つ重要な要素は、一時停止可能なインスタンスやワークロード、時間外に実行できるもの、あるいは中断可能なものがないかを検討することです。そのような場合、Spotインスタンスを使用することで、トレーニングコストを最大90%削減できます。インスタンスのタイプと、実行する数量およびスケジュールが決まったら、次に考えるべきはコミットメントです。これらのワークロードを少なくとも今後1〜3年間継続する予定はありますか？
これが最初に考えるべき質問です。次に考えるべきは、単一のインスタンスファミリーを継続して使用するかどうかです。例えば、今後1年または3年間、P5を使い続けるのでしょうか？もしそうであれば、Instance Savings Planが最適かもしれません。これは最大の割引が得られますが、単一のファミリーに限定されます。もし前世代のインスタンスに切り替える柔軟性が必要な場合や、将来の世代のインスタンスに切り替える柔軟性が必要な場合は、Compute Savings Planの方が適しているでしょう。これにより柔軟性が得られ、どのインスタンスにコミットするかを考える必要なく、自動的に降順で最大の割引が適用されます。
この2つの違いについてもう1つ重要な点があります。環境へのコミットメントが少ない場合、Instance Savings Planは特定のリージョンに縛られてしまいます。一方、Compute Savings Planはリージョンに縛られることがないため、必要に応じて異なるリージョン間でワークロードを移動できます。将来的にリージョンを変更する可能性がある場合は、Compute Savings Planの方が適しているかもしれません。コミットメントの管理ができたら、次は使用量の最適化とレートの最適化について考えていきます。しかし、すでに稼働しているインスタンスからより多くの価値を引き出せたらどうでしょうか？同じインスタンスから30〜40%以上のパフォーマンスや利用率を引き出せたらどうでしょうか？そこで重要になってくるのが、GPUの使用率のモニタリングと最大化です。
Capital OneのBrentが語るSelf-Managed AIインフラの課題と解決策
では、これらの戦略を大規模に実践している方からお話を伺いましょう。Brentさん、Capital Oneでこれらのトレードオフを実践されていますが、どのような学びがありましたか？多くの方がCapital Oneの取り組みをご存じだと思いますので、細かい話は省きます。プライベートクラウドからパブリッククラウドに移行した際、スケーラビリティ、スピーディーなサービス提供能力、そして当然ながら高い回復力を重視して、テクノロジースタック全体を一から再構築する必要がありました。その規模での環境の再構築は非常に困難でしたが、そこで得られた学びが、これらのサービスを提供できる最新のデータエコシステムの基盤となりました。この経験が、Generative AIとそれがもたらし続けているパラダイムシフトへの私たちのアプローチの基礎となっています。
Generative AIの道を進み始めて最初に気づいた3つのことがあります。1つ目は、アクセラレーテッドインスタンスのコストと可用性が従来型のインスタンスとは大きく異なるということです。2つ目は、これらのインスタンスのコストとパフォーマンスの解釈方法を変える必要があったということです。3つ目は、モデルの種類やアーキテクチャなどの外部要因が、これらのインスタンスのパフォーマンスに大きな影響を与えうるということです。以降のスライドでは、これらの点について詳しく説明し、その特徴に対処するための戦略についてお話しします。
まず、コストと可用性に関してですが、Self-managedインスタンスの確保を試みた方なら、より大規模な新しいインスタンスの入手が課題となっていることにお気づきでしょう。その結果、私たちが観察したのは、チームがこれらのインスタンスをプロビジョニングできた場合、もはや必要なくなっても手放すことを躊躇する傾向があるということです。これにより、一部のクラスターで大量の未使用キャパシティが発生する一方で、他のクラスターでは必要なリソースの確保に苦労するという状況が生まれています。この対処法の1つとして、GPUプールを作成し、必要に応じてモデルのトレーニングを行うために、クラスター間でインスタンスを移動できるようにすることが挙げられます。
次に、パフォーマンスを考える際には、これらのアクセラレーテッドインスタンスに伴うアーキテクチャの違いを理解することが重要です。従来の基本的なコンピュートインスタンスでは、CPUそのものが計算の主力でした。アクセラレーテッドインスタンスでは、実際の処理の大部分はGPU上のストリーミングマルチプロセッサーによって行われています。そこで課題となるのは、これらのリソースが実際にどの程度効率的に使用されているかを測定する方法です。 この場合、GPUに特有の3つの異なる測定基準があり、これらが使用率に関する追加のコンテキストを提供してくれます。
GPUの使用効率を判断するために、単一の統一された指標を見るのではなく、実際には3つの指標を使用してリソースの消費状況を推測する必要があります。現在注目している3つの指標は、GPU温度、GPU電力、そしてGPU使用率です。GPU使用率という用語は、CPU世界から来た人には少し誤解を招くかもしれません - GPU使用率の文脈では、GPUのリソースが実際に使用されている時間のみを意味します。つまり、GPUそのものの閾値に対して、電力と温度の両方を活用して、リソースの消費効率に関する洞察を得る必要があります。重要な点として、すべてのGPUが同じように作られているわけではありません。それぞれが電力と温度に関して独自の上限を持っており、実際の使用率を上限と比較して測定する場合は、これらの閾値がどこにあるかを認識しておく必要があります。
パフォーマンスに影響を与える外部要因について説明した3番目のパートに移ります。先ほど議論した効率性に基づいて考えてみましょう。NVIDIA A100の読み取り値を示すグラフでは、使用率と電力の間に強い線形相関が見られるはずです。この特定のケースでは、使用率レベルが上がるにつれて、リソースを効率的に消費している場合、電力も同様に上昇すると予想されます。グラフの右下には、いくつかの外れ値が目立ち始めています。これは必ずしも問題を示すものではありませんが、追加の注意を要する興味深いデータポイントです - これは単にモデルのチューニングの機会かもしれませんし、インフラストラクチャ自体の特性かもしれません。
まとめとして、インスタンスの使用効率を分類し、理想的なパフォーマンスを下回る可能性のある条件を示す一般的なフレームワークを紹介したいと思います。このルーブリックは非常にシンプルですが、非効率が発生する可能性のある場所を理解するための基礎を提供します。この手法は、より多くのモデルのトレーニングを行い、追加のインフラストラクチャを組み込んでいくにつれて、時間とともに進化し続けることを認識しています。これらの発展は、すでに新しいユースケースと新しい仮説を生み出しており、私たちはそれらをテストすることを楽しみにしています。
Amazon SageMakerとAmazon Bedrockを活用したAI開発の最適化
では、Adamに戻したいと思います。皆さんの取り組みと、その過程で得られた重要な洞察について聞けることを楽しみにしています。Capital Oneの経験は、モニタリングと投資の活用・最大化の価値を示しています。しかし、もし組織がCosmoのようなソリューションを構築する必要があるものの、そのすべてのインフラストラクチャを管理する能力や意思がない場合はどうでしょうか？ビジネス価値の構築と提供にのみ集中したい場合や、チームが小規模でそれ以外の時間がない場合はどうでしょうか？そこで、Amazon SageMakerのような部分的に管理されたソリューションが活躍します。
MLライフサイクルの各段階を最適化するために、自分たちで行うべきことと、AWSが担当してくれることについて考え始めることが重要です。Amazon SageMakerでは、AWSがインフラストラクチャを処理します。ツール、ワークフロー、ソフトウェア構成の一部、そしてこれから説明するSageMakerの最適化の多くのレバーは、先ほど説明した自己管理型と類似点がありますが、ここにはいくつかの追加のニュアンスがあります。インスタンス選択から始めましょう - ここで重要なのは、テストではなく、どのようなワークロードタイプを実行するかということです。ノートブックを実行するのか、トレーニングを行うのか、それがインスタンスを選択する際の主要な要因となります。適切なワークロードに適切なインスタンスタイプを合わせることで、25〜35%のコスト削減を実現できることを確認しています。
インスタンス選択の次に重要な要素は、モデル選択です。ワークロードに適したモデルを選ぶことで、最終的なパフォーマンスと必要なリソースの量に大きな違いが生まれます。考慮すべき点としては、入力するデータの種類があります。どのような問題を解決しようとしているのか、テキストだけなのか、それともグラフィックを含むマルチモーダルなシナリオなのか。選択したモデルに必要なリソースはどの程度か。大量の計算能力を必要とする重いモデルなのか、それとも少ないリソースで管理できる軽量なモデルなのか、といった点です。
この評価を行う際は、小規模から始めて、モニタリングを行い、必要に応じて段階的にスケールアップしていくことが重要です。モデル選択のもう一つの要素は、多くの場合無料で利用できるパブリックモデルを使用するのか、それとも独自の価格体系を持つプロプライエタリなモデルを選択するのかという点です。モデルの性能とリソース要件、そして予算のバランスを適切に取ることが、この決定における重要な要素となります。
インスタンスを決定し、モデルの選択について結論を出した後の次の検討事項は、コミットメントです。今後1年から3年間、Amazon SageMakerを継続して使用する予定があるかどうかを考える必要があります。もしそうであれば、SageMaker Commitmentsの利用を検討することが重要です。これは先ほど説明したAmazon EC2やFargate、Lambdaなどに適用されるインスタンスやCompute Savings Planとは異なります。SageMaker Savings Planは SageMakerにのみ適用されますが、すべてのSageMaker使用量に適用されます。SageMakerを1年から3年間使用する予定がある場合、契約期間と前払い金額に応じて、最大64%のコスト削減を実現できます。
SageMakerでトレーニングを行う場合のもう一つの検討事項は、Spotインスタンスを活用できるかどうかです。ワークロードが中断に対応できるか、時間外や1日の異なる時間帯に実行できるかどうかを確認してください。可能であれば、SpotはAWS環境の余剰キャパシティを活用し、最大90%のコスト削減を実現できます。これは、環境やソリューションに適している場合、大きなコスト削減につながります。
SageMaker内で考慮すべき最後の要素は推論です。推論とは、ソリューションやモデルが未知のものについて結論を導き出す能力のことです。先ほどのCosmoの例で言えば、これまでに遭遇したことのない夢について質問された場合、どれだけ良い回答を提供できるかということです。SageMaker内では、4つの主要な推論レベルを実行できます。最も高価なのはリアルタイム推論で、24時間365日専用のエンドポイントが稼働し、最速のレスポンスタイムと最低のレイテンシーを提供します。一方、スペクトルの反対側にはServerlessがあり、リクエスト量に応じてスケールアップ・ダウンし、未使用時にはゼロまでスケールダウンできるため、大幅なコスト削減が可能です。
リアルタイムと完全管理の中間には、非同期処理とBatch推論があります。非同期処理は、大容量のファイルタイプや1時間までの長い処理時間を要するリクエストやプロンプトに最適ですが、リクエストを順次処理します。Batch推論は、リアルタイム処理が不要で、研究目的や時間外にプロンプトを実行できる場合に適しており、1日の異なる時間帯に小さな単位で処理することでコスト削減が可能です。SageMakerは制御とパフォーマンスのバランスを提供しますが、場合によってはさらにインフラ管理を減らしたいこともあるでしょう。そこで登場するのがAmazon Bedrockで、単一のAPIを通じて高性能なFoundation Modelを提供します。Cosmoにとって、これは夢の解釈や出力の品質により注力でき、ソフトウェアの設定やツールに費やす時間を減らせることを意味します。
ここでの大きな考え方の転換は、インフラストラクチャから使用量へのシフトです。最初に考慮すべきは価格モデルです。Bedrockの価格モデルは、先ほど説明した時間単位での課金とは異なる方式で運用されます。Bedrockで利用できる価格モデルの優れている点は、ユーザーのニーズに合わせて選択できることです。
テスト目的や、予測不可能なワークロードの変動がある場合には、オンデマンドを選択することができます。オンデマンドの料金は選択するモデルによって異なります。しかし、リクエスト量をある程度予測できる場合は、Provisionedと呼ばれるコミットメントを選択でき、これは1ヶ月または6ヶ月の契約期間で利用可能です。これにより、一定量のリクエストに対して大幅な節約が可能になります。
Amazon Bedrockで利用できるもう一つのオプションは、Batch処理です。まとめて処理を送信することで分析を行い、定常状態やオンデマンドで実行する必要がないためコスト削減につながります。最終的に、好みのモデルがあるかどうかに関わらず、Batchでテストを実行することを検討することが重要だと考えています。その理由については、モデル選択を考える際に詳しく説明します。
Amazon Bedrockには、Anthropic、Meta、Mistral AIなどの企業や、AmazonのFoundation Modelを含む多くの主要なモデルが用意されています。モデルを評価する際に重要な考慮点は、コスト、速度、そして精度です。簡潔で短い回答を提供する軽量なモデルを使用する場合、出力されるトークン（おおよそ単語数）が少なくなるため、スケールアップした際のコストが抑えられます。Amazon Bedrockの価格体系はトークンベースなので、この点を考慮することが重要です。
私はよく Amazon Bedrock を使用して開発している人たちに、1つのモデルだけに絞らないように伝えています。テストを行って本番環境やテスト用に好みのモデルを選んでいるかもしれませんが、そのリクエストの一部を、バッチであれオンデマンドであれ、別のモデルで実行して出力を比較してみることをお勧めします。Amazon Bedrock の優れている点は、コードを1行変更するだけで異なるモデルを試すことができ、より良い出力が得られるかどうかを確認できることです。顧客やエンドユーザーが良い回答を得るために6回も8回も質問を繰り返す必要がなく、最初の試行で価値のある回答が得られれば、大きなコスト削減につながります。
Amazon Bedrock は Knowledge Base をサポートしています。これは Retrieval Augmented Generation（RAG）として知られているものです。これは、開発中のものに関する専門知識でモデルを補強する簡単で優れた方法で、特定の分野におけるエキスパートとしての能力を強化することができます。先ほどの Cosmo の例で言えば、お城の建築様式に関する Knowledge Base を与えることで、お城を建てる夢に関する質問が出てきた際に、より詳しい回答ができるようになります。
Knowledge Base を使用する際、コストをコントロールする上で考慮すべき重要な変数が2つあります。1つは、与えるデータの量です。必要なデータのみを慎重に選び、余分なものは与えないようにする必要があります。必要以上のデータを読み込むと、それらもインデックス化され、ストレージとインデックス作成の両方でコストが発生します。もう1つは、データの再インデックス化の頻度です。新しい情報を見つけるためにインデックス作成を繰り返すスケジュールや頻度、そして既にインデックス化したものを再度インデックス化するのか、変更点のみを探すのかといった点です。これらは Knowledge Base を追加する際に設定できる重要な構成要素やカスタマイズ項目であり、コストを可能な限り抑えることができます。
Amazon Bedrock のもう一つの強みは Fine-tuning の機能です。参照用にデータを与える Knowledge Base とは異なり、モデルが自身を再トレーニングするためのデータを与え、それをモデルに組み込むことができます。Amazon Bedrock では、データセットを指定するだけで Fine-tuning を実行できるため、非常に簡単です。その結果、より正確な回答が得られ、顧客やエンドユーザーは必要な回答をより早く得られ、質問を繰り返す必要がなくなります。
昨日 Matt Garman が言及したもう一つの機能は Model Distillation です。これは Fine-tuning に関連する機能で、Amazon Bedrock に一連のプロンプトを与えると、それらのプロンプトの出力を分析し、より小規模な、あるいはよりコストの低いモデルを Fine-tuning してくれます。まだ Model Distillation を検討していない方は、コスト削減の優れた方法として是非検討してください。5倍ほど高速または安価になるとのことで、Amazon Bedrock にとって大きな進化となるでしょう。
Amazon Q BusinessとAIアプリケーション開発の総括
Amazon Bedrockのアプリケーション層について、考慮すべき重要な点がいくつかあります。Swamiが先ほどのKeynoteで触れた大きなレバレッジの1つが、Prompt cachingです。ユーザーが非常によく似た質問や同じ質問を繰り返すようなシステムでは、すでに回答済みの内容をその都度モデルに送信する必要はありません。Prompt cachingを使用することで、そうした無駄を省き、追加コストをかけることなく、以前と同様の回答を提供することが可能になります。
アプリケーション層のもう1つの要素として、トークンの前処理があります。これらをアプリケーション層としてグループ化したのは、通常、独自のコードでカスタマイズする必要があるためです。Bedrockはトークンベースで、入出力の単語量に応じて課金されるため、ユーザーが非常に長い質問をする場合、前処理で余分な単語を削除してスリム化することができます。1回のPromptではそれほど大きな価格差は生まれませんが、数万回や数百万回のリクエストに拡大すると、支払額に大きな違いが出てきます。
もう1つのオプションは後処理で、受け取ったPromptや質問にコンテキストを追加することです。Cosmoの例に沿って説明すると、誰かが「強い壁を作るベストな方法は何？」と尋ねた場合、モデルは木製の石膏ボードを使用すると答えるかもしれません。しかし、実際に知りたかったのは城の強い壁の作り方で、その場合はモルタルと石を提案するべきでした。構築しているツールに特定のコンテキストがあることがわかっている場合、受け取ったPromptに接尾辞としてそれを追加することで、ユーザーにとってより意味のある回答を確実に提供できます。
これで、インフラストラクチャ管理の異なるレベルでの最適化方法について確認できました。次は、Alexが、インフラストラクチャ管理やAPIを必要としないCosmoのようなソリューションを作成する方法について説明します。これは、Amazon Q businessというイージーボタンの力で実現可能です。ありがとう、Adam。
Adamが強調したKnowledge baseの力、そして私たちが教え、学び、Bedrockを活用してビジネスのソリューションを生み出す方法について、とても気に入っています。Qでは、完全マネージド型のスペクトラムにいるため、Cosmoはインフラストラクチャの決定について心配することなく、素晴らしい夢の解釈の作成に純粋に集中できます。これは夢のようですね。AIアプリケーションやCosmoを作るための様々な要素を検討する代わりに、Qにおける1つの要素とその入力だけを見ればよいのです。ここでの最適化レバーはシンプルですが、非常に強力です。
まず最初に、価格帯についてお話しします。Q Businessには、ライトなプランと機能が充実したプランという異なるレベルがあります。これは、あなたが求めているものによって選択できます。出力に視覚的な要素を含めたいのか、それともシンプルな回答だけで良いのか。両者には約85%のコスト差があるので、かなりの違いがあります。また、ユーザー管理についても考える必要があります。全員が夢の解決策を得られるようにしたいのか、それとも夢の専門家の中核グループだけにしたいのか。組織内でのユーザー数とその配分について検討する必要があります。
次にContent Indexingについてですが、これはAdamがBedrockについて話していたことと似ています。Content Indexingでは、情報をどれだけ新鮮に保ちたいか、回答をどれだけ深く掘り下げたいか、そしてナレッジソースの規模はどれくらいにするかを考える必要があります。情報を新鮮で刺激的に保つ場合と、単に大規模なナレッジソースを作成する場合では、20〜35%程度のコスト差が生じます。
そして、アプリケーション統合についてです。これは日常業務にどのように統合されているか、効率的な方法で行われているか、ユーザーがCosmoアプリとどのようにやり取りしているか、そしてそれらのレイヤーでの効率性はどうなっているかということです。このような流れで、私たちの例すべてに共通して考慮すべき最後の点であるサポートサービスに繋がります。
AIアプリをどのように構築するにしても、バランスを取り、他に何が関係してくるかを考える必要があります。インターフェースはどうなのか、ストレージはどうなのか。全体的な効率性を考える際に、多くの議論を経て私たちが合意した4つの主要な領域があります。1つ目はストレージです。超高速でアクセス頻度の高いものが必要な場合は、S3 Express One Zoneを使用して高速な取得を実現できますが、それはより高価になります。では、それは重要なのでしょうか？ライトニングスピードが必要なのか、それともユーザー体験においてそれほど重要ではなく、むしろコストを抑えたいのか。
次にVector Databasesについてです。Cosmoはどこに夢の知識ベースを保持し、OpenSearch Serverlessを使用してより豊かな夢の解釈を作成するのでしょうか？しかし、それは本当に必要なのでしょうか？これもまた、ユーザー体験とアプリからどのような出力を求めるかに関係します。そしてData Transferについて - これはグローバルなアプリケーションなのでしょうか？異なる国の人々が夢のプランを立てる必要があるのか、それとも現在のオフィスの人々だけを対象にするのか？これらすべての要素にデータ転送が関係してきます。Analyticsについては - 精度をどのように追跡するのか？それを確認しているのか？アプリケーションがどれだけ成功しているのか？ユーザーが望む回答を得るために、AIアプリに何回プロンプトを入力する必要があるのか？このAnalyticsレイヤーを実行することで、効率性を追跡し、改善や成功を確認することができます。
これはぜひスマートフォンで写真を撮っておいていただきたいスライドです。 私がこのカラースキームを誇りに思っているというだけでなく、これは私たちが今まで話してきたことの素晴らしいまとめになっているからです。AdamがAmazon SageMakerとAmazon Bedrockについて話したときにも触れましたが、この分野は今日も変化し、昨日も変化していました。私たちは、皆さんと同様に、AIに関するすべての分野で非常に速いスピードでイノベーションを進めています。そこで、新機能や新しいものが登場しても一貫性を保てるようなカテゴリーを見つけようと試みました。アプローチは少し異なるかもしれませんが、あのKPIについて考えると、それらは変わりません。スピードを重視しているのか？効率性を見ているのか？アプリケーションの信頼性や柔軟性はどうか？品質や深さについてはどうか？これらの要素は、発表に追いつくためにスライドを何度作り直さなければならなくても、本質的には変わらないものなのです。
夢が叶う話と言えば、皆さんにも今日、私たちの夢を叶えていただけます。AWS Eventsアプリでセッションのアンケートにご回答ください。Cosmoなら「不可能な夢は一歩から始まる」と言うでしょう。この場合は、5つ星評価の5回のクリックからですね。今日は最適化についてちょっとだけギークな話をさせていただき、ありがとうございました。まだ質問がある方や、スライドの写真が必要な方のために、私たちはここに残っています。お役に立てていれば幸いです。ありがとうございました。本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion