コスト管理入門:AI機能を手頃に保つ

AI機能には、ソフトウェアとしては珍しい性質があります。誰かが使うたびに、毎回お金がかかるのです。従来のコードはすでに支払い済みのサーバー上で走るので、呼び出しが一回増えてもほぼ無料です。言語モデルはリクエストごとに課金し、その請求は利用量に応じてスケールします。それが作り方を変えます。1日に数セントしかかからないプロトタイプが、静かに、それを作るチームより高くつく機能になりうるのであり、その差はめったに一つの大きな失敗ではありません。百個の小さな習慣が積み重なったものです。この解説は、AI機能を手頃に保つための揺るがぬレバー、どのモデルやベンダーを使おうと効き続けるものを扱います。

実際にどう課金されるか

理解していないコストは管理できないので、まずは単位から始めましょう。言語モデルはトークンで課金します。トークンとはテキストの塊で、ごく大まかには数文字か単語の一部です。すべてのリクエストは、入っていくトークン(あなたのプロンプト、すなわち指示、コンテキスト、例、ユーザーの入力)と、出てくるトークン(モデルの応答)の両方に対して課金されます。両方向ともコストがかかり、多くのモデルでは出力トークンが入力トークンよりトークンあたりで高くつきます。

ここから二つの帰結が即座に出てきます。第一に、長いプロンプトは、モデルが一言発する前から無料ではありません。そのコンテキストすべてが、毎回の呼び出しで支払う入力です。第二に、冗長な答えは、同じことを言う簡潔な答えより高くつきます。総請求額は本質的にリクエストあたりのトークン数にリクエスト数を掛けたものであり、以下のほぼすべてのレバーは、品質を縮めずにその二つの要素のどちらかを縮める方法です。

レバー1:モデルを適正サイズに

最大のコスト判断は、どのモデルを使うかです。能力と価格は連動して動き、最も強いモデルは小さく速いものよりトークンあたり明らかに高くつくからです。本能は、何にでも最も有能なモデルに手を伸ばすことです。規律は、各タスクが実際に何を必要とするかを問うことです。

多くのタスクは簡単です。メッセージの分類、フィールドの抽出、短い書き換え、定型的な返信です。小さく安いモデルがこれらを完璧にこなすことはしばしばで、それに旗艦モデルを使うのは、使っていない能力に支払うことです。高価なモデルは、本当に難しい仕事、すなわち深い推論やニュアンスのある生成、品質差がその価格に見合う仕事のために取っておきましょう。強力なパターンは、難易度でルーティングすることです。安いモデルが簡単な大多数を処理し、難しいケースだけが高価なモデルへ引き上げられます。品質テストの評価の規律がここに直接当てはまります。安いモデルでは不十分だと決めつける前に、十分かどうかを測りましょう。

レバー2:呼び出しあたりのトークンを減らす

モデルが適正サイズになったら、トークンを攻めましょう。入力側では、プロンプトをタスクが必要とするものに刈り込みます。膨れ上がった指示、冗長な例、モデルが使わないコンテキストは、すべて毎回の呼び出しでお金がかかり、スケールではその無駄こそが問題のすべてです。これは検索システムやエージェントシステムで二重に当てはまります。そこでは「念のため」のコンテキストを詰め込みたくなりますが、使われない一節はすべて、永遠に支払われ続けるのです。

出力側では、必要なものだけを、それ以上ではなく求めましょう。3つの箇条書きが欲しいなら、3つの箇条書きと言うのです。制約のないモデルは、しばしば3段落書きます。タスクが許すなら、コンパクトな形式を要求しましょう。これは、それ自体のためにケチることではありません。何も足さないトークンに支払わないことです。タスクが要求するものだけを運ぶプロンプトと応答は、より安く、たいていより明快でもあります。

レバー3:同じ作業に二度払うのをやめる

AIコストの多くは、同一またはほぼ同一の作業に繰り返し支払うことであり、それをやめるきれいな方法が二つあります。

キャッシングとは、すでに持っている結果を再利用することです。多くのリクエストが大きく不変のコンテキストの塊、すなわち同じ長いシステムプロンプトや同じ参照文書を共有するなら、プロンプトキャッシングはその固定部分を毎回再処理するのを避けさせてくれ、反復的な呼び出しの入力コストを鋭く削減できます。別途、ユーザーが頻繁にまったく同じ問いを尋ねるなら、答えをキャッシュし、モデルをまったく呼ばずに直接提供できます。最も安いモデル呼び出しは、決して行わない呼び出しです。

重複排除とバッチ処理は量に対処します。システムが同じリクエストを二度発射するなら、一度発射しましょう。緊急でないリクエストが多くあるなら(夜間処理、一括分析)、それらをまとめて扱うほうが、一度に一回慌てて呼ぶより安いことがしばしばで、一部のプラットフォームは緊急でないバッチ作業をリアルタイム料金より安く価格設定しています。共通の筋は、同一の作業は一度だけ行うべきで、待てる作業は性急さのプレミアムを払うべきでない、ということです。

レバー4:暴走を上限で抑える

ほとんどのコスト災害は、一定の滴りではありません。それは暴走する単一のコンポーネントです。ループに陥り、モデルを何度も呼ぶエージェント。失敗のたびに上限なく発射されるリトライ。1時間に数千のリクエストを送るユーザー、あるいはユーザーを装うスクリプト。一定の利用は予算化が容易です。暴走こそが、誰かの胃を落ち込ませる請求書を生むのです。

だからループやキューが形成されうるあらゆる場所に上限を置きましょう。エージェントが止まって報告するまでに取れるステップ数に上限を。リトライに上限を。単一のユーザーが一定時間内に行えるリクエスト数を制限。応答の長さに固い最大値を設定し、一つの病的なリクエストが巨大で高価な答えを生成できないようにします。これらの上限は通常利用中に噛みつくべきではありません。それらはまさに異常なケースのために存在し、一度あなたを救えば、その元は何倍にもなって取れるのです。

レバー5:最適化の前に測る

見えないものは管理できず、ほとんどのコストの驚きは実は可視性の失敗です。支出はずっとそこにあり、誰も見ていなかったのです。何かを最適化する前に、お金がどこへ行くかが分かるよう機能を計測しましょう。どの操作が最も高価か、コストが入力と出力でどう分かれるか、どのユーザーやリクエストの種類が支配的か。

これが重要なのは、コストが性能と同様、偏りに従うからです。操作のごく一部が、たいてい請求の大部分を駆動します。安く稀なパスを最適化するのは生産的に感じられ、何も節約しません。まず高価で頻繁なパスを見つけ、それを直しましょう。それから時間を通じて傾向を見守りましょう。利用は増え、ローンチ時に手頃だった機能が、採用が伸びるにつれて高価に漂流しうるからです。意図的に選んだ閾値を支出が越えたときのアラートを設定し、財務からのメールではなく自分のダッシュボードからコスト問題を知るようにしましょう。

コストと品質のバランスを取る

ここでのすべてのレバーは何かとトレードオフであり、そうでないふりをすれば、誰も使いたがらない安い機能ができあがります。小さなモデルはお金を節約し、わずかに悪く答えるかもしれません。短いプロンプトはトークンを節約し、重要だった一片のコンテキストを落とすかもしれません。積極的なキャッシングは呼び出しを節約し、古い答えを提供するリスクを冒します。目標は可能な限り低いコストではありません。それはユーザーのいない機能です。目標は、品質の基準をなお満たす最低のコストです。ここでこそ評価が真価を発揮します。コスト削減の変更を行い、希望ではなく数値で、品質が保たれたことを確認させてくれるのです。コストを削り、品質を測り、品質が耐えた削減を残しましょう。

まとめ

AI機能を手頃に保つことは、ひと握りの揺るがぬ習慣に帰着します。トークンを理解した請求を意識する設計、各タスクへのモデルの適正サイズ化、呼び出しあたりのトークンを減らすこと、同じ作業に二度払わないこと、暴走しうるコンポーネントに上限を設けること、そして実際にお金のかかるパスを最適化できるようすべてを測ること。どれも巧妙なトリックを必要とせず、どれもモデルやベンダーの変化を生き延びます。これらのシステムがどう価格設定されているかから導かれるからです。各削減を評価と組み合わせて品質を正直に保てば、自滅しかねなかった機能が、走らせ続けられる手頃なものであり続けます。