半年前、私たちがホスト型言語モデルに毎月支払っていた利用料は、経理が思わず問い合わせを入れるほどの金額でした。いまやその10分の1になり、モデルは公衆インターネット経由だった頃よりも自社ハードウェア上の方が高速です。割引交渉をしたわけでも、より安いプランに切り替えたわけでもありません。モデルを社内に持ち帰ったのです。
この転換は実験として始まり、最終的にはスタックとして定着しました。よく選ばれた少数のオープンウェイトモデルを、ネットワーク末端の消費者向け筐体1台で動かす構成が、今では推論トラフィックの大半を処理しています。クラウドモデルも依然として使っていますが、本当に必要な仕事に限定しています。それ以外はすべてローカルで稼働し、削減した金額はそのまま利益に直結しています。
最初の教訓は、 promptsごとに対応を変えることです。サイズが大きければ何でもうまくいくわけではない、ということです。700億パラメータのモデルは確かに印象的ですが、日常的な要約、分類、構造化抽出といった用途にはまったくオーバースペックです。実際のトラフィックをプロファイリングしたところ、リクエストの約7割が日常的なものでした。ファインチューニングした70億パラメータのモデルなら、わずかなレイテンシで、トークンあたりのコストもゼロで処理できました。習慣ではなくタスクでルーティングすることが、突破口になりました。
第二の教訓はハードウェアについてでした。私たちは当初、加速度カードのラックが必要になるだろうと想定していました。実際にやってみると、ピーク時の負荷も、2〜3つの量子化モデルを一度に収められる十分なVRAMを搭載した最新のGPU1枚で十分にカバーできました。4ビット重みへの量子化では品質に計測可能な低下がありましたが許容範囲内であり、その代わりに膨大なメモリとスループットが得られました。重要度の低いジョブのロングテールには、CPU専用の小型モデルによるフォールバックを用意し、GPUが使用中のときもシステムを応答性の高い状態に保ちました。
第三の教訓はキャッシュです。同じコンテキストウィンドウを何度も再評価すると、トークンコストは複利的に膨らみます。推論レイヤーの前段にセマンティックキャッシュを追加し、ほぼ重複したプロンプトはモデルに触れることなく保存済みの応答を返すようにしました。不要な履歴を削るプロンプトテンプーティングと組み合わせると、数週間でキャッシュヒット率は40%を超えました。
第四の教訓は可観測性です。モデルごとのレイテンシ、100万トークンあたりのコスト、品質のスポットチェックといったダッシュボードがなければ、最適化は推測の領域を出ません。すべての呼び出しを計測できるように計装を整え、どのルートが利益をもたらしているか、どのルートが静かに予算を焼却しているかを正確に把握できるようにしました。
もしあなたが、利用料が見返りと釣り合わなくなったモデルの請求書を前にしているなら、やり方は明確です。実際に送っているトラフィックをプロファイリングし、タスクに合わせてモデルを適切にサイズダウンし、量子化を思い切って進め、重複をキャッシュし、計測を続けることです。クラウドは難易度の高いケースのために残しておきます。それ以外はすべて自分のデスクで動かせます。
あなたのトラフィックをこのようにルーティングしたらどうなるか興味がありますか?あなたのモデルの主要なユースケース上位3つを返信いただければ、最初に私たちが提示するであろうルーティングの配分案を共有します。