Amazon Bedrockでファインチューニングに手を伸ばそうとしているほとんどのチームにとって、正しい答えは検索、プロンプトキャッシュ、より良いプロンプトを、この順番で試すことだ。ファインチューニングは、この3つを使い尽くした後に検討するツールであって、その前に使うものではない。理由はイデオロギーではない。請求書だ。Bedrockでカスタムファインチューニングモデルを使うには、Provisioned Throughput経由で提供する必要があり、その料金モデルはアプリケーション全体の経済性を変えてしまう。

ファインチューニングは真剣な一手のように感じられる。独自データがあり、モデルにそれを「知って」ほしいから訓練する。しかし、ほとんどの人がファインチューニングで求めているものは、実は重みが吸収すべき知識ではない。推論時にモデルが必要とする文脈であり、モデルに従わせることができるフォーマットであり、そもそも明確に書かれていなかった指示だ。この3つはすべて、より安価な解決策を持つ。

ファインチューニングで背負うコスト

Bedrockでは、カスタムのファインチューニングモデルを従量課金のオンデマンド価格で呼び出すことはできない。それに対して推論を実行するにはProvisioned Throughputを購入する必要があり、これはモデルユニットを時間単位で予約するもので、最も安いコミットメントでも月単位以上の長さになる。トラフィックが流れているかどうかに関わらず、予約された容量に対して支払い続けることになる。

これはコスト構造を反転させる。オンデマンド価格は使用量に応じてスケールする。トラフィックがなければ課金もない。Provisioned Throughputは固定の下限だ。午前3時のアイドルなモデルユニットは、ピーク時の稼働中のものと同じコストがかかる。スパイクが多く、低ボリュームで、まだプロダクトマーケットフィットを模索しているワークロードにとっては、使っていない容量の家賃を払い続けることになる。そしてMLOpsの負担も増える。データがドリフトするたびの再訓練、モデルのバージョニング、新しいチェックポイントごとの評価など、誰かが永久に抱え続けることになる。

より安価なスタックが実際に解決すること

RAGが知識を担う

モデルにあなたのドキュメントから答えてほしいのが目的なら、それは訓練ではなく検索の問題だ。Bedrock Knowledge Baseはコンテンツを埋め込み、クエリ時に関連する文章をコンテキストに取り込む。新しいドキュメントが来ても再訓練は不要だ。インデックスすれば数分で検索可能になる。ファインチューニングは知識を重みに焼き付けるが、それはデータが変わった瞬間に古くなる。検索は継続的に更新できるストアに知識を保ち、ベースモデルに対する従量課金の推論でそれを実現する。

プロンプトキャッシュが繰り返しの文脈を担う

RAGとfew-shotプロンプティングに対するよくある反論はトークンコストだ。長いシステムプロンプト、ツール定義、取得したコンテキストを呼び出しのたびに再送信することになる。プロンプトキャッシュはその大部分を取り除く。Bedrockはプロンプトの安定した接頭辞をキャッシュし、繰り返されるトークンは大幅な割引で課金され、より速く処理される。キャッシュ期間は現在1時間まで延長されており、ユーザーセッションやバッチジョブを余裕を持ってカバーできる。太ったプロンプトを高価にしていたものこそ、キャッシュが修正するために作られたものだ。

より良いプロンプトが振る舞いとフォーマットを担う

ファインチューニングプロジェクトの驚くほど多くの割合が、実際にはモデルに一貫したJSONを出力させたい、トーンを採用させたい、手順に従わせたいというだけのことだ。それはプロンプトの問題だ。明確なシステムプロンプトと厳選された少数の例があれば、訓練コストゼロで、再訓練の実行ではなく秒単位で変更できる変更サイクルで、大部分をカバーできる。重みを変える必要があると結論づける前に、構造化されたプロンプティングとfew-shotの例を使い尽くすこと。

コストの計算を、平易な言葉で

典型的な低から中程度のボリュームのアプリケーションについて、2つの道を並べてみよう。

Fine-tune path:
  training run (one-off)
  + Provisioned Throughput (fixed monthly floor, idle or not)
  + retraining + eval + versioning (ongoing engineering)

RAG + cache + prompts path:
  on-demand tokens (scales to zero when idle)
  + Knowledge Base storage + embedding (small, usage-based)
  + prompt cache (discounts the repeated prefix)

高く安定した予測可能なボリュームでない限り、2列目のほうがドル建てで安く、エンジニアリング時間ではるかに安い。Provisioned Throughputの固定の下限が元を取れるのは、予約されたユニットを忙しく保つのに十分な一定のトラフィックを流している場合だけだ。

ファインチューニングが本当に答えになる場合

それは実在するツールであり、実在するニッチを持つ。どんなプロンプトでも確実に生み出せない振る舞いが必要なとき、たとえば特殊な出力スタイル、ベースモデルが苦手とするドメイン語彙、長いプロンプトではあなたのボリュームで満たせないレイテンシとトークンの予算などがある場合はファインチューニングする。そうしたケースは実在する。それらは例外であり、Provisioned Throughputの固定コストにコミットする前に、より安価なスタックの測定済みの失敗を指し示せるべきだ。

結論

Bedrockでのファインチューニングは、Provisioned Throughputを意味し、それは固定のコストの下限と、あなたが無期限に抱え続けるMLOpsのコミットメントを意味する。チームがファインチューニングを求める理由の多くは、知識であり、繰り返される文脈であり、不明確な指示であり、これらは検索、プロンプトキャッシュ、より良いプロンプトによってより安価に解決される。まずは安価なスタックに手を伸ばし、それが失敗する場所を測定し、その後で初めて訓練にお金を払う。

次に読む

AWS全体にわたるより広いコスト最適化のプレイブックについては、フィールドノートがercan.cloudにあり、ハブはercanermis.comにある。