Amazon Bedrockはバッチ推論をオンデマンドのトークン価格の50%で実行し、諦めるのは即時性だけだ。リクエストをまとめたファイルを提出すると、キャパシティが空いたときに非同期でジョブが実行され、結果を後で回収する。応答を待っている人間が誰もいないワークロードでは、誰も必要としていない速度のためにリアルタイム推論の全額を払うことは、テーブルの上に半分のお金を置き去りにしているのと同じだ。

よくある間違いは、最初のプロトタイプがそう書かれていたという理由だけで、すべてのモデル呼び出しを同期的なリアルタイムパスにデフォルトしてしまうことだ。インタラクティブなチャットはリアルタイムでなければならない。昨日のサポートチケットを分類する夜間ジョブはそうではない。これらはレイテンシ要件が異なり、Bedrockはそれらに異なる価格を付けている。エンジニアリングの問いは単純で、どのワークロードが本当に今すぐ答えを必要とし、どれがいずれ答えが得られればよいのかを見極めることだ。

Bedrockでのバッチの仕組み

バッチ推論は呼び出しではなくジョブだ。フローは意図的に地味に作られている。

1. write requests as JSONL to S3   (one record per line)
2. create a batch inference job     (input S3 -> output S3)
3. job runs asynchronously          (minutes to hours)
4. read results from the output S3 prefix

各入力レコードはレコードIDと、リアルタイムで送るのと同じモデル入力を運ぶ。出力はS3に書き戻され、入力1件ごとに結果が1件、そのレコードIDでキー付けされるので、結果を入力に結び付けられる。維持すべきウォームなエンドポイントも、調整すべき並行度も、監視すべきスロットリングもない。リクエストとレスポンスのループを提出と回収のループに置き換え、ジョブがこちらのスケジュールではなくサービスのスケジュールで終わることを受け入れる代わりに割引価格を得る。

レイテンシが本当に問題にならない場所

適合するワークロードは、結果が画面の前で待っている人ではなく、プロセスに供給されるものだ。

  • 一括分類とタグ付け。ドキュメント、チケット、製品の滞留分を分類する。答えはユーザーの前ではなくデータベースに着地する。
  • エンリッチメントパイプライン。あらかじめ生成して保存しておく要約、抽出、エンベディング。リアルタイムパスは事前計算された値を読むだけになる。
  • オフライン評価。モデルやプロンプトの変更を何千ものテストケースにわたってスコアリングする。これはレポートであり、レポートは1時間待てる。
  • 定期レポート。スケジュールで実行され、即座にではなく後で人間が読む出力を生成するもの全般。

共通するのは、締め切りが時間単位で測られ、トークン価格の半減が誤差ではなく実際のお金になるほどの十分な量があることだ。

コストの計算

紙の上に置いてみると、この取引の効果はくっきり際立つ。それぞれ固定のトークンコストを平均する100万件のレコードのジョブを例にとる。

Real-time path:
  1,000,000 requests x on-demand token price
  + endpoint kept responsive
  + throttling handling under load

Batch path:
  1,000,000 records x (0.5 x on-demand token price)
  + S3 storage (negligible)
  + the willingness to wait

バッチ側の列はトークン請求額が半分であるうえに、運用面の露出も少ない。バーストから守るべき生きたエンドポイントが存在しないからだ。損益分岐点は量の問題ではなく、締め切りの問題だ。答えが待てるなら、バッチはコストとシンプルさの両方で勝つ。待てないなら、どんな割引を積んでも非同期ジョブは受け入れられない。

バッチが間違った道具になるとき

形が合わない場所に無理強いしてはいけない。ユーザーが出力を待っているとき、1つのリクエストが前のリクエストの結果に依存しているとき、あるいはジョブが小さすぎて割引がとるに足らず非同期の配管が見合わないとき、バッチは間違いだ。スロットリングの回避策としても間違っている。リアルタイムトラフィックがスロットリングされているなら、修正すべきはキャパシティプランニングとプロンプトキャッシングであって、インタラクティブなリクエストを何時間も後に結果が返るジョブに押し込むことではない。バッチは元々後回しにされるべきだった仕事のためのものであり、レイテンシの問題を隠すためのものではない。

まとめ

大きなトークン請求額の半分は、多くのチームがすでに手元に持っているアーキテクチャに見合う価値がある。S3に書き込み、ジョブを提出し、結果を後で読むだけだ。この割引は巧妙な仕掛けではなく、オンデマンドのキャパシティではなく後回しにできるキャパシティに対して支払っているだけのことだ。モデル呼び出しを監査し、誰が待っているかで分類しよう。人間が反対側にいるものはすべてリアルタイムのままにする。それ以外、つまり人ではなくパイプラインに供給される分類、エンリッチメント、評価、レポートは、50%オフのバッチジョブに属する。節約分は、これまで一度も疑ったことのないワークロードの中に眠っている。

次に読むべき記事

AWS全体にわたるより広いコスト最適化とパイプラインのプレイブックについては、クラウド分野のフィールドノートをercan.cloudで、ハブをercanermis.comで公開している。