あなたのLLM請求額はオブザーバビリティの問題だ

Amazon Bedrockの請求額が跳ね上がり、誰もどの機能が原因かを言えないとき、それは価格の問題ではない。オブザーバビリティの問題だ。請求書はアカウントがトークンにより多く支払ったことしか教えてくれない。どのエージェント、どのテナント、どのコードパスが支出したのかは教えてくれず、その帰属がなければコストの議論はすべて推測になる。測定できないものは最適化できないのに、ほとんどのチームは合計だけを測定し、その下にあるものは測定していない。

トークン支出には、通常のクラウドコストよりこれを悪化させる性質がある。それは非決定的なシステムによって生成されるということだ。プロンプトの変更、リトライループ、おしゃべりなエージェント、あるいはモデルをより長く考えさせる方法を見つけたユーザー、そのすべてが請求額を動かしうるが、どれも請求書に新しいリソースとしては現れない。支出は1つのBedrockの行項目の内側に隠れている。仕事は、驚かされる前にその行項目を分解しておくことであり、驚かされた後ではない。

帰属こそがすべて

重要な問いは「Bedrockにいくら使ったか」では決してない。「これにいくら使い、それは見合っているか」だ。それに答えるには、トークン支出のすべての単位に次元が必要になる。最低限、各呼び出しには次をタグ付けする。

機能やプロダクト領域。要約機能とチャットアシスタントのどちらがコストドライバーなのかを問えるようにする。
テナントや顧客。あるアカウントが他のアカウントによって補助されていないか、価格設定が提供コストをカバーしているかを見られるようにする。
エージェントやワークフロー。複数ステップのパイプラインのコストが1つの不透明な合計ではなく、ステップごとに見えるようにする。
モデル。安価なモデルで済んだはずのトラフィックが高価なフロンティアモデルに流れているタイミングを見極められるようにする。

これらの次元がなければ、コスト最適化は一律の措置に劣化する。全員にキャップをかける、あるいは機能をオフにしてどのクレームが届くかを見る、といったことだ。次元があれば、成長したパスをまさに指し示し、その成長に見合う価値があったかを判断できる。

2つの計測層

請求書のためのコスト配分タグ

AWSのコスト配分タグは粗い層だ。Bedrockの利用を駆動するリソースとリクエストにタグを付け、課金データ自体にこちらの次元を持たせることで、コストレポートは1つの未分化なBedrockの数値を示す代わりに機能や環境でグループ化できるようになる。これはファイナンスやプラットフォームオーナーが日々見るビューだ。粒度は月単位で、「お金がどこに向かっているか」の会話には向くが、その場でスパイクを捉えるものではない。

リアルタイムの全体像のためのCloudWatchメトリクス

請求書は遅行指標だ。先行指標はトークンのスループットであり、それはCloudWatchに属する。Bedrockは利用メトリクスを発行し、アプリケーションから直接、エージェントごと、テナントごと、機能ごとにディメンションを付けた独自のカスタムメトリクスを発行することもできる。

# emit token counts as custom metrics, dimensioned
put_metric_data(
  namespace = "LLM/Usage",
  metric    = "InputTokens",
  value     = usage.input_tokens,
  dimensions = { "Feature": "summarizer", "Tenant": tenant_id }
)
# same for output_tokens, and cache read/write counts

これで支出はアラームをかけられるグラフになる。一晩で3倍になったエージェントごとのトークンメトリクスは、月末のファイナンスからの質問ではなく、火曜日にアラートを発火させる。入力と出力は別々に読むこと。出力の方が高く価格設定されているので、暴走した生成はまずそこに現れる。

可視性が可能にすること

すべてのトークンが帰属付けされれば、最適化はもう鈍器ではなくなる。エージェントごとのメトリクスが明らかにする安価で機械的な呼び出しをより小さなモデルにルーティングし、フロンティアモデルはそれに見合う推論のために取っておける。提供コストがプランを上回っているテナントを見つけ、価格設定か利用を修正できる。プロンプトの変更が招いたリトライループを、リクエスト数は変わらないのにトークン数だけがスパイクしたことから捕捉できる。これらの動きはどれも、請求書のどの部分を削るべきかを知っている必要があり、それはまさに計測が与えてくれるものであり、生の請求書が決して与えてくれないものだ。

まとめ

分解できないBedrockの請求書は管理できない請求書だ。トークン支出を単なる請求書の行ではなくテレメトリとして扱おう。課金ビューにはコスト配分タグを、リアルタイムのビューにはエージェントごと、テナントごとのトークンメトリクスをCloudWatchに発行し、先行指標にアラームをかけて、スパイクが事後検証ではなくページ通知になるようにする。LLMコストを制御下に置けているチームは、最安値を持っているチームではない。どの瞬間でも、どの機能、どのテナント、どのエージェントがお金を使っているかを正確に見られるチームだ。

次に読むべき記事

Batch Inference on Bedrock: Half Price If You Can Wait、帰属によってどのワークロードを後回しにできるかが見えたときに実行できる具体的な削減策の1つ。
Prompt Caching on Bedrock: The 90% Discount Most Teams Ignore、同じダッシュボードに載せる価値のあるキャッシュの読み取りと書き込みのカウントについての記事。

LLMを超えたFinOpsとクラウドのコスト可視性のプレイブックについては、クラウド分野のフィールドノートをercan.cloudで、ハブをercanermis.comで公開している。