Amazon、Sonnet 4.6をStrands Deciderに置き換えて数百万ドルを節約

Amazon、Sonnet 4.6をStrands Deciderに置き換えて数百万ドルを節約

しばらくの間、AmazonとAWSのチームは、Claude Sonnet 4.6を使用して、費用を抑えながら内部システムのチケットを分類していました。

Sonnet 4.6は、インテリジェンスとコストのバランスを取る「適正」な選択肢でした。世界最大級の内部チケットシステムの一つを扱っていたことを考えると、9ヶ月前のモデルでも良好なパフォーマンスを発揮しました。しかし、最近、2人のAmazonエンジニアがSonnet 4.6を、1ヶ月前にリリースした決定モデルであるStrands Deciderに置き換えました。その結果、パフォーマンスは同等でありながら、コストは98%削減されました。この変更により、年間数百万ドルのトークンコストが節約される見込みです。

内部チケットシステムを担当するCarrとMehulが、これがどのように実現したかを以下で説明します。

LLMの仕事を決定モデルで置き換える

私たちはSonnet 4.6を使って、膨大な量のチケットを分類していました。チケットは、顧客からのエスカレーション、キャパシティリクエスト、自動アラーム、セキュリティインシデント、または社内のその他のあらゆるものを、20種類のカテゴリタイプに分類する必要がありました。エージェントは、各チケットに対して長いシステムプロンプトを実行し、JSONを生成して、固定されたラベルセットに対して推論を行っていました。

決定モデルはテキストを生成できません。まず、状態と選択肢のセットを持つ質問が与えられ、決定モデルは各選択肢の確率と信頼スコアを返します。この方法がチケット分類に完璧に適合することを確認しました。状態はチケットであり、選択肢はラベルカタログです。

オリジナルのStrands Decider 2Bから始めました。チケットのテストセットでは、E4B Gemma 4ビルドが明らかに優れた結果をもたらしたため、それに切り替えました。その後、ラベルを適用する前にモデルがどの程度の信頼度を必要とするかを調整しました。結果として、E4Bは本番のSonnetを、別のチケットセットで上回りました。

E4BをSageMakerのml.g5.xlargeインスタンス（各A10G、24GB）で実行しました。モデルは約19GiBを使用し、1つのリクエストは1つのインスタンスで約640msかかりました。エンドポイントはトラフィックに応じて自動スケーリングしますが、ネットワークは分離されており、コンテナへのアウトバウンドアクセスは許可されていませんでした。SageMakerは、起動前にモデルの重みをS3からコピーします。

顧客も同様のことを行えます！チケットAPIを除き、パス上のすべては標準的なAWSサービスです。チケットイベントはSQSキューに着信し、Lambda関数をトリガーします。Lambda関数はチケットデータを読み取り、モデル（Strands Deciderを備えたSageMaker AI Endpoint）を呼び出します。AppConfigはスイッチ（下記参照）を保持し、CloudWatchはログ、メトリクス、アラームを収集します。スタックはCDKで定義され、Beta、Gamma、Prodのデプロイメントステージがあります。

Sonnet 4.6とStrands Deciderを同じチケットで実行する

私たちはスイッチを切り替えて、ただ願うというようなことはしたくありませんでした。ラベリングLambdaは、各メッセージでAWS AppConfigから3つの設定を読み取ります。

• BEDROCK: Sonnetがすべてのチケットをラベル付けしますが、Strands Deciderは呼び出されません。
• DUAL: SonnetとStrands Deciderの両方のモデルが並列で呼び出されます。Sonnetモデルからの結果がチケットに適用され、Strands Deciderの結果と比較されます。
• DECIDER: Strands Deciderがすべてのチケットをラベル付けし、Bedrockは呼び出されません。

測定したもの

トークン数の削減は2つの要因によるものでした。Strands Deciderは、JSON応答の代わりに、選択肢という1つの出力を生成しました。また、プロンプトもSonnet 4.6よりもはるかに短かったです。本番環境のラベル説明だけでも、Strands Deciderの4,096トークンウィンドウよりも長いため、20個のラベルそれぞれを1〜2文の基準として書き直し、単一の選択質問の選択肢として送信しました。これに「なし」の選択肢も追加しました。チケットデータはSonnetが受け取るものと同じですが、長いチケットではStrands Deciderが古いコメントを削除して収まるようにします。

以下は、Sonnetの使用を停止した日のLambda実行時間のグラフで、平均Lambda実行時間が74%減少したことを示しています。

コスト

公開されているus-east-1のオンデマンド価格に基づくと:

Sonnetのチケットあたりのコストは、上記のトークン数から直接算出されます。Strands Deciderのコストは、各インスタンスの負荷によって異なります。リクエストあたり約640msの場合、1つのインスタンスは1時間あたり約5,600枚のチケットを処理でき、フル稼働で100万枚あたり約250ドルになります。バーストのためのヘッドルームを確保しており、実際には100万枚あたり約500ドルになります。これはSonnetよりも約44倍安く、98%の削減です。

これらは公開されているリスト価格です。Lambdaのコストは含まれていませんが、Lambdaもチケットあたりの実行時間が短くなっています。

驚いたことの一つは、JSONキーの順序が結果を変えるということでした。キーの順序が異なる同じコンテンツを送信すると、出力確率が最大0.19変動しました。現在、すべてのリクエストでキーをソートして送信しています。したがって、APIの背後で決定モデルを提供する場合は、実行を比較する前にこの点を確認してください。

私たちの教訓

このアプローチがうまくいったのは、タスクが既知のカタログからのクローズドな選択であり、ボリュームが高く、古いパスのレイテンシが重要だったからです。ラベルに説明テキストが必要な場合、カタログが毎週変更される場合、または有用なコンテキストを数千トークンに収めることができない場合、決定モデルはおそらくLLMの仕事を置き換えることはできないでしょう。

モデルに関係なくコピーする部分は、3段階のスイッチです。実際のトラフィックで両方を実行し、すべての不一致を判断したことは、オフライン評価よりも多くのことを教えてくれました。また、戻るのが45秒の設定変更で済むことも意味しました。

決定モデルが登場することで、エージェントの世界は（より低コストで）はるかにエキサイティングになります。分類エージェントを実行している場合は、Strands Deciderリポジトリとそのサービングノートを試してみてください。