LLM のコスト削減と品質維持のバランスを取る方法

要点

トレースにコスト情報を追加し、その請求がどのリクエスト、モデル呼び出し、ツール、またはエージェントのステップによって発生したのかを紐付けましょう。

削減を検討する前に、同じトラフィックにおけるコストと品質を比較してください。

広範な変更を加える前に、モデルの選択、コンテキストの肥大化、リトライ回数、ツールの出力結果、評価器の使用状況などを調査しましょう。

あらゆる最適化は、固定されたデータセットと一定の品質基準に対して検証する必要があります。

LLM の請求額が増加しました。請求書には増加分が明記されていますが、その増加を引き起こした具体的な行動や、追加支出が結果を改善したかどうかまでは示されていません。

突発的な増加は、より困難なリクエストクラスの発生、リトライループの継続、肥大化したツールの応答、あるいは目に見える改善をもたらさない高価なモデルの使用などが原因かもしれません。その支出の一部は浪費ですが、他方は貴重な作業に貢献しています。

安価なモデルが自動的にシステム全体のコスト削減につながるわけではありません。これは、安価なモデルがマルチエージェントの経済構造を変えた際にも観察されたパターンです。タスク完了のためにより多くのコンテキストやリトライ、エージェント間のやり取り、あるいは人間の再作業が必要になる場合、総コストはより能力の高いモデルを使用した場合を上回ることもあります。重要なのはトークンあたりのコストではなく、検証済みの成果物あたりのコストです。

アプリケーションの品質を損なうことなく支出を抑えるためには、コストデータ、トレース情報、評価結果を一つのワークフローで統合する必要があります。これらを組み合わせることで、高コストのパターンを特定し、変更を試行した上で、その節約が品質低下を伴わないことを確認できます。

LLM コスト最適化がトレースから始まる理由

コーディングエージェントと本番環境のアプリケーションは、同じ AI 利用料金の請求書に載るかもしれませんが、支出を生み出す仕組みは異なります。

コーディングエージェントは、プルリクエストを開く前にファイルを何度も確認したり、増え続けるリポジトリのコンテキストを保持したり、複数のアプローチを試したりする可能性があります。一方、本番環境のエージェントは顧客データを取得し、サブエージェント間でルーティングし、ツールを呼び出し、最終的なレスポンスを生成します。

どちらの場合も、コストを決めるのは以下の 2 つの入力です。

モデル価格：入力トークン、出力トークン、キャッシュされたトークン、推論トークンのそれぞれのレート。

トークン使用量：プロンプト、履歴、ツールの結果、リトライ、レスポンスなど、処理されるすべてのトークン。

大まかに言えば、以下の式が成り立ちます。

総リクエストコスト = Σ（種類ごとの処理トークン数 × そのトークン種別のモデルレート）

ただし、安価なモデルを使えば必ずしもワークフロー全体のコストが下がるわけではありません。タスクを完了するために必要なコンテキストが増えたり、リトライやエージェントのターン回数が増えたりすれば、より高性能なモデルを使う場合よりも総コストが高くなることもあります。

つまり、モデル価格だけで請求書の全貌は説明できません。ワークフローがどのように動作し、結果が品質チェックに合格したかどうかを知る必要があります。

何かを変更する前に、成功した結果とはどのようなものかを定義しましょう。コーディングエージェントであれば、レビューサイクルを減らしてマージされたプルリクエストであることが望ましいでしょう。サポートエージェントであれば、エスカレーションせずに正しく解決することです。

主要な品質指標 1 つと、それを補完する少数の指標を選び、これらをその後のすべての最適化のためのガードレールとして設定してください。

ステップ 1：ワークフロー全体を追跡する

回答に至るまでの全経路を計測することから始めましょう。これには、モデル呼び出し、検索ステップ、ツール利用、ルーティング判断、エージェント処理などが含まれます。

有用なトレースは、以下の情報を捕捉する必要があります。

• モデルとプロバイダー
• 入力・出力のトークン数
• ツール呼び出しとそのレスポンス
• リトライやモデルの再呼び出し
• レイテンシ（遅延時間）
• 最終的な出力結果
• 関連する評価結果

本番環境のアプリケーションでは、OpenTelemetry に準拠した計測機能を用いて、トレースを Arize AX プロジェクトへ送信してください。

コーディングエージェントの場合は、適切なトレーシング統合機能をインストールし、プロジェクトに接続してテストインタラクションを実行します。その際、生成されたトレースにエージェントのモデル呼び出し、ツール活動、中間ステップが含まれていることを確認しましょう。

エージェントへの計測は単一コマンドで完了できます。

AX の自動インストゥルメンテーションドキュメントでは、npx evals フローについて説明しています。プロジェクトルートからこのコマンドを実行すると、対応するコーディングエージェントが起動し、Arize AX アカウントへの接続または作成が行われ、必要なトレーシングツールがインストールされます。その後、アプリやエージェントワークフローに計測機能が適用され、最初のトレースが正常に記録されることを確認できます。

npx evals

この可視化により、請求書からは把握できない行動を明らかにできます。例えば、ファイルの繰り返し読み込み、文脈の異常な増大、停止したツール、不要なリトライ、あるいは有用な変更を生み出さない高コストなセッションなどが該当します。

ステップ 2: 価格情報を付与し、高コストのスパンを特定する

トークン数はシステムが処理した作業量を表しますが、支出を理解するためには、これらのトークンに適切な単価を適用する必要があります。

AX では、各モデルに対して適用可能な入力・出力・キャッシュトークン・推論トークンの料金を設定できます。これにより、公開価格と異なる交渉済みレートを使用することも可能です。

AX のコスト追跡ドキュメントによると、着信スパンにすでにコスト属性が含まれている場合は AX がそれを利用し、含まれていない場合はモデルとプロバイダーを照合して設定済みのレートにマッチさせます。AX には一般的なモデル向けのデフォルト料金構成が用意されていますが、この機能は遡って適用されるものではないため、分析対象のトレースを取り込む前に料金を設定する必要があります。

主要なコスト属性は llm.cost.prompt、llm.cost.completion、そして llm.cost.total です。AX はトレース内の LLM スパンのコストを合計し、リクエスト全体の総コストを表示します。

次に、代表的なトレースを開き、総コストからその原因となっているスパンへと遡って調査します。

以下の項目を確認してください：

• トレース全体の総コスト
• スパンごとのコスト内訳
• プロンプトとコンプリートのトークン数
• キャッシュトークンの使用状況
• ツール応答のサイズ
• リトライ回数
• モデルとプロバイダー
• 評価結果

そして、以下の3 つの質問に答えましょう：

1. どのスパンがコストの大部分を生み出したのか？
2. なぜ多くのトークンを処理する必要があったのか、あるいはなぜ多数の呼び出しが必要だったのか？
3. そのリクエストは品質要件を満たしていたか？

直近の四半期に関する質問に答えるために 5 年分のデータを返すツールと、より強力なモデルを必要とする本質的に困難なリクエストでは、解決策が異なります。どのケースに対応すべきかはトレースから判断できます。

ステップ 3：品質とともにコストも監視する

個々のトレースはリクエストの内容を説明しますが、モニタリングによってそのパターンが広がっているかどうかを確認できます。

以下の指標を追跡してください：

• 総 LLM コスト
• リクエストあたりのコスト
• リクエストあたりのプロンプトトークン数
• モデル呼び出し回数
• リトライ回数
• ツール呼び出し回数
• レイテンシ（応答遅延）
• 評価通過率

モニタリングの閾値を超えた場合は、その変化の原因となったトレースを開いて詳細を確認します。

トレーシングプロジェクトのモニタでは、スパン属性やカスタムの Arize Query Language (AQL) メトリクスを利用できます。必要な場合、ソースデータをフィルタリングまたは集約してから AQL メトリクスを定義する方法は、カスタムメトリクスのドキュメントで確認できます。これにより、生産環境での急増から、背後にあるモデル、ツール、コンテキスト、リトライパターンまで直接たどることができます。

次に、同じトラフィックと時間範囲において、コストと品質を比較する必要があります。これはエージェント評価指標で説明されている「トークンから成果へ」のシフトと同じ考え方です：

• コスト：品質 / 推奨アクション
• 高い：弱い / パターンを削減または簡素化する
• 高い：強い / 慎重に調査し、重要な支出を守る
• 低い：弱い / ワークフローの修正か、モデル・コンテキスト・ツールのアップグレード
• 低い：強い / 類似のワークロードでパターンを再現する

このフレームワークにより、チームは高コストなリクエストをすべて無駄だと扱うことを防ぎます。目指すべきは、アプリケーションの品質基準を満たしつつ、最も低コストなパターンです。

ステップ 4：管理されたエージェントによる反復的な浪費の調査

モニタリングが問題を指摘しても、実際にトレースを検査し、繰り返される行動を見つけ、改善案を提案するのは人間の仕事です。

管理されたエージェントは、調査の多くを自動化できます。ウェビナーのワークフローでは、エージェントは隔離されたサンドボックス内で実行され、AX プロジェクトからのトレースと評価にアクセスできます。また、GitHub リポジトリや関連するスキルから追加のコンテキストを受け取ることも可能です。管理されたエージェントのハッチスドキュメントには、ハッチ、サンドボックス、オプションのスキル、リポジトリコンテキストがどのように構成されるかが記載されています。

特に有用なテンプレートは 2 つあります。

Cost Agent（コストエージェント）

調査が主に支出に関するものである場合に Cost Agent を使用します。以下を特定できます：

• 低複雑度のタスクを担当している高コストモデル
• 過剰なプロンプトやツール応答
• 重複するモデル呼び出しまたはツール呼び出し
• 高コストのタスク、または特定の時間帯
• ルーティング変更の可能性
• 提案された修正による推定節約額

Signal Agent（シグナルエージェント）

より広範な行動分析には Signal Agent を使用します。以下を浮き彫りにできます：

• 制御不能なコンテキストの蓄積
• 繰り返される探索
• 遅延または停止したツール
• 非効率なルーティング
• コンパクト化や再起動に失敗するセッション
• コストやレイテンシを増加させる再発性の障害

Cost Agent は請求書（コスト）に焦点を当て、Signal Agent はその原因となる行動をより広範囲に分析します。ご自身のトレースでこの分析を実行するには、Signal のチュートリアルに従ってください。

例：小規模モデル内に隠れたコンテキストの肥大化

ウェビナーのデモンストレーションでは、Cost Agent が 500 スパン以上を分析しました。アプリケーションはすでに比較的小さなモデル上で動作していたため、モデルの切り替えが最大の機会ではありませんでした。

エージェントは、5 年以上の履歴を含む金融データツールを検出しました。このツールの利用により、28 のスパンで 5,000 トークン以上のプロンプトが消費され、平均コストの約 7 倍に達し、測定された請求額の約 24% を占めていました。

また、サイズが大きすぎるスーパーバイザーのプロンプトと、他の場所で既に情報が入手可能な重複したツールも発見されました。

提案された修正はシンプルでした。直近の 2 つの財務期間のみを返すようにし、スーパーバイザーのプロンプトを短縮し、重複するツールを削除することです。エージェントによると、これらの変更により請求額を約 34% 削減できる見込みです。

この数値は特定のデモワークロードに基づくものであり、普遍的なベンチマークの結果ではありません。しかし、より重要な教訓はここにあります。コンテキストの設計やツールの構成が、モデルそのものよりも大きなコスト問題を引き起こす可能性があるということです。

ステップ 5: トレースが示すパターンを修正する

LLM のコストに関する問題は、主にいくつかのカテゴリーに分類されます。

測定された難易度に基づいてルーティングする

品質基準を満たしつつ、最も小さなモデルを使用してください。単純な分類や抽出タスクであれば、小規模なモデルで十分に機能します。一方、複雑な推論や困難なリファクタリングが必要な場合は、最先端のモデルを採用しても正当化されます。

モデル価格だけでルーティングするのではなく、データに基づいてこの仮説を検証してください。コストが可視化された段階でより安価なモデルへ切り替える際にも、同様に評価を最優先とするアプローチが有効です。

不要なコンテキストを削減する

古い会話履歴、繰り返されるシステム指示、過剰なツール応答、無関係なリポジトリファイル、他のツールが既に返した情報などを確認し、不要なものを排除しましょう。

タスクに必要な時だけコンテキストを取得し、ワークフロー全体にあらゆる入力を持ち運ぶことは避けてください。

エージェントループを短縮する

検索の繰り返し、ファイル読み込み、リトライ、サブエージェントの呼び出しは、回答の質を向上させないままコストを増加させる要因となります。

トレーシングデータを活用して、明確な停止条件やリトライ制限、コンテキストの上限、圧縮ルールを設定しましょう。

プロンプトの安定した部分をキャッシュする

変更のない指示や参照資料と、リクエスト固有の入力を分離してください。プロバイダーがプロンプトキャッシングに対応している場合、同じコンテキストを繰り返し処理するコストを削減できます。

評価規模を適切に調整する

すべてのリクエストで LLM による判定が行われる場合など、評価にかかるコストは無視できないほど大きくなる可能性があります。

まず、対象の挙動を確実に測定できる最も安価な評価器から始めましょう。評価器の種類に関するドキュメントではコード評価、人間評価、LLM-as-judge 評価について解説されており、結果とコストに関するドキュメントでは評価コストやサンプリング、フィルタリングの方法が紹介されています。

コードで表現可能な要件については、決定論的なチェックを使用しましょう。

タスクの一部のみが意味的な判断を必要とする場合は、コードと LLM を組み合わせて使用します。

主観的または自由記述型の基準には LLM による判定を活用してください。

多段階の調査が必要な評価に限って、エージェント自体を判定者として用いるワークフローを採用しましょう。

サンプリングやフィルタリングを活用すれば、高コストな評価を最も価値のあるトラフィックに限定できます。

Arize AX は、これらの変更がもたらす影響を測定します。ルーティング、キャッシュ、ワークフローの変更は、アプリケーションやゲートウェイ、エージェントのハッチス内で行われます。

ステップ 6：本番展開前の最適化検証

有望なトレースがあれば仮説を立てることはできますが、それだけで変更をデプロイするには不十分です。

検証用データセットには、以下の要素を含める必要があります。

• 一般的なリクエスト
• コストのかかるリクエスト
• 既知の失敗事例
• 困難なエッジケース
• 現在のシステムが適切に処理しているリクエスト

まず、既存のワークフローをベースラインとして実行します。次に、モデル、プロンプト、コンテキストサイズ、ツール出力、リトライポリシー、ルーティングロジック、評価器など、いずれかの変数を変更した候補バージョンを作成します。このワークフローにおけるデータセット側の詳細は、AX データセットドキュメントに記載されています。

両方のバージョンを同じデータセットと品質基準で比較し、実験ワークフローを通じて検証を行います。

評価駆動型開発と同じループが機能します：一つの変数を変更し、コストと品質を測定して判断を下すのです。

• 候補変更：コスト測定項目 / 品質ガードレール
• より小型のモデルを使用する：リクエストあたりのコスト / タスクの成功
• コンテキストを削減する：プロンプトトークン数 / 回答の正確性
• ツール出力を制限する：ツールおよびプロンプトのトークン数 / 完全性
• リトライ回数を減らす：呼び出し回数とレイテンシ / 正常な完了
• 評価器をサンプリングする：評価コスト / 回帰カバレッジ

コストが削減され、かつ必要な品質基準を満たす場合にのみ、候補バージョンを採用します。

その後、通常のリリースプロセスに従います。

• 提案されたコード、プロンプト、ツール、または設定変更をレビューする。

CI と関連する評価データセットを実行し、コストが低下したことを確認します。その際、品質に重大な劣化がないことも併せて検証してください。

変更には必ず人間の承認が必要です。

本番環境へのデプロイ後は、継続的にトラフィックを監視します。

安価なパターンが一貫して機能することが確認できたら、それを共有スキル、ルーティングルール、プロンプトテンプレート、ツールレスポンスの制限、あるいはエージェント設定として体系化してください。これにより、チーム全体が最適化の恩恵を受け、毎回個別に再発見する必要がなくなります。

再現可能な LLM コスト最適化ワークフロー

以下の手順は、コストが増加した際にいつでも実行できる単一のループとしてアプローチを凝縮したものです。

image トレースと測定を行い、原因を調査します。そして、品質基準を満たしつつコストを抑えるパターンを見つけたら、変数を一つずつ変更して共有してください。

アプリケーションがユーザーが必要な結果を生み出せている場合のみ、請求額の削減は意味を持ちます。

トレース、評価、実験がつながれば、コストの急増もデバッグ可能な本番環境の挙動として捉えられるようになります。どこにお金がかかったかを確認し、それが価値につながったかを判断した上で、根拠を持って修正を適用できます。

品質を犠牲にせず LLM コストを削減する方法に関するウェビナーで、このワークフローの実践例をご覧ください。また、Arize AX を活用すれば、同様のコスト・トレース・評価の可視化機能を自社アプリケーションにも導入可能です。

「品質を犠牲にせず LLM コストを削減する方法」という記事は、もともと Arize AI で公開されたものです。