数か月のLLM実験から得た四つの反直感的な教訓——安いモデルこそ最も高くつく

数か月のLLM実験から得た四つの反直感的な教訓——安いモデルこそ最も高くつく

pvl-dual-rail、AutoGEOコンテンツパイプライン、Studio画像フローの三つで数か月にわたりモデル比較を続け、見栄えはよくないが有用な請求書の束が手元に残った。本稿はそこから得た、直感に反する四つの結論をまとめたものである。四つに共通するのは次の一点だ。百万トークンあたりの単価だけを見て判断すると、ほぼ毎回間違える。

先に結論を述べる。LLMのコストは「単価 × 使用量」ではない。「単価 × 使用量 × 再試行回数 ÷ 一度で成功する確率」である。分母を無視した時点で、あらゆるコスト削減の判断は赤字を生んでいる。

一、タスクごとに異なるモデルへ振り分ける——一つのモデルで全てを賄わない

最も着手しやすく、効果も最も直接的なのは、すべての作業を単一モデルで処理するのをやめることだ。

我々のパイプラインには、性質がまったく異なる少なくとも四種類のタスクが存在する。

機械的なタスクをフラッグシップモデルに投げるのは、必要のない推論能力に金を払っていることになる。開放型推論を小型モデルに投げるのは、「完成したように見えるが実際には使えない」出力に金を払うことになる。そして後者のほうがはるかに高くつく。誤りが下流に流れてから初めて発見されるからだ。

実務上の解はルーティングである。タスク種別、入力長、失敗コストに応じて、リクエストを異なる階層のモデルへ振り分ける。`pvl-dual-rail` をオープンソースとして公開したのは、まさにこの「どのリクエストがどのレールを通るか」を扱うためである。

判断基準：「このタスクを誤ったとき、どれだけの時間で気づき、修正にいくらかかるか」を問う。答えが「即座に気づき、一度回し直せば済む」ならば安いモデルを使う。答えが「数日後に顧客から指摘される」ならば高いほうを使う。

二、安いことが最適解とは限らない——再試行回数を計算に入れる

これが最も直感に反する点である。二つのモデルがあると仮定する。

• Aモデル：単価が低い。ただしこの種のタスクで一度に成功する確率はおよそ55%
• Bモデル：単価はAの5倍。一度に成功する確率はおよそ92%

単価だけを見ればAは5倍安い。しかし再試行を計算に入れると、使える結果を一つ得るのにAは平均1.8回を要し、Bは1.09回で足りる——実際のコスト差は5倍から3倍未満へと縮まる。しかもこれは、真に大きな支出をまだ含んでいない。

• 人手によるレビュー時間：Aの出力はおよそ半分が、人が目を通し、差し戻し、指示を出し直す必要がある。この時間はトークンよりはるかに高価である。
• デバッグと追跡：品質の低い出力は「明らかに壊れている」ことは少なく、「正しく見えるが細部が誤っている」ことが多い。この種の誤りは発見に時間を要する。
• 下流への汚染：誤った内容がナレッジベースや公開済みページに入り込んだ場合、その除去コストは元の生成コストの数十倍に達する。

実際に遭遇した事例がある。ある抽出タスクを安価なモデルに切り替えたところ、トークンの請求額は6割下がった。だがその月、人手による修正に費やした時間のせいで、全体の納品はかえって遅くなった。請求書は見栄えがよくなり、コストは上がったのである。

判断基準：安いモデルが適するのは「誤っても構わない・回し直しが安価・誤りが即座に見える」タスクである。この三条件のうち一つでも欠けるなら、計算をやり直すべきだ。

三、高価なモデルを使い、一度で仕上げる

第二の点から自然に導かれるが、独立して述べる価値がある。見落とされやすいコストが絡むからだ——コンテキストを再構築する代償である。

安価なモデルで複雑なタスクを実行し、失敗し、再試行するとき、支払っているのは二回目のトークン費用だけではない。加えて次のものを負担する。

• 完全なコンテキストをもう一度送信する（長いプロンプトの場合、これ自体が主要な支出となる）
• 複数ラウンドにわたる遅延の累積を引き受ける
• 多段階パイプラインでは、完了済みの前段をロールバックする必要が生じうる

一度で正しく仕上げることが節約するのは、鎖全体の再実行である。これは長いコンテキストを扱うタスクで特に顕著になる。プロンプト自体が数万トークンに達する場合、「一度の再試行」の代償は「タスク全体の再実行」に近づく。

さらに、定量化は難しいが確かに存在するコストがある——信頼のコストだ。あるパイプラインの出力が「およそ半分は見直しが必要」だとチームが知った時点で、人はそれを習慣的に信用しなくなる。結果として一件ごとに人手で確認することになり、自動化の価値は消失する。信頼できるモデルを用いて通過率を九割以上へ引き上げて初めて、人手の確認は「全件を見る」から「抜き取り検査」へと降格できる。この転換がもたらす便益は、モデル間の価格差をはるかに上回る。

判断基準：一件ずつ人が見ることのない自動化パイプラインに入るタスクであれば、負担できる範囲で最良のモデルを使う。自動化の前提は信頼できることであって、安価であることではない。

四、Max Tokensを小さく設定するのは、金を払って何も受け取らないに等しい

これは最も犯しやすく、最も痛い誤りである。失敗の仕方が最も見えにくいからだ。

出力が `max_tokens` によって打ち切られたとき、あなたはすでに支払っている——入力トークンの全額と、打ち切りまでに生成された出力トークンのすべてを。それでいて手元に残るのは不完全な断片である。閉じ括弧を欠いたJSON、文の途中で途切れた記事、半分だけの表。この状況における回収率はゼロだ。全額を払い、使えないものを受け取る。

さらに厄介なのは、多くの場合エラーにならないことである。APIは200を返し、内容は成功したように見え、下流のパースが失敗して初めて——あるいはさらに悪いことに、パースは成功したが内容が欠落していて初めて——問題が露見する。

我々のやり方は次の通りである。

1. まず計測し、それから設定する。 実際のタスクを20〜30回実行して出力長の分布を記録し、P95を取ったうえで30〜50%の余裕を加える。感覚でキリのよい数字を決めない。
2. `finish_reason` を監視する。 これが最も直接的なシグナルである。`length`（打ち切り）の比率が1〜2%を超えるなら、上限が厳しすぎる。
3. 構造化出力には追加の余裕を持たせる。 JSONや表のように閉じ構造を持つ出力では、打ち切りの破壊力が平文をはるかに上回る。平文なら前半だけでも使えるが、JSONの打ち切りは丸ごと廃棄になる。
4. タスクごとに設定し、グローバルな既定値を使わない。 分類タスクなら200トークンで十分だが、長文生成に200トークンを与えるのは失敗の保証である。
5. 打ち切りを正常な応答ではなくエラーとして扱う。 `finish_reason: length` を検出したら再試行するかモデルを上位へ切り替える。半端な内容を下流へ流してはならない。

判断基準：`max_tokens` はコスト削減のつまみではなく、安全弁である。節約したいならプロンプトの圧縮、モデル選定、キャッシュに取り組むべきであって、出力上限を絞ることではない。それでは節約にならず、すでに支払った金を廃棄物に変えるだけである。

四点を一文にまとめる

四つの教訓はいずれも同じ原則を指している。最適化すべき対象は「使える結果一件あたりの総コスト」であり、「百万トークンあたりの単価」ではない。

実装上はこの三つに帰着する。タスクを等級付けし、等級に応じてモデルを選び、実測データからパラメータを設定する。これ自体が我々のAI Operational Excellence方法論の一部である。AI能力が継続的に稼働するための前提は、そのコスト構造が理解され、計測され、統治されていることであって、毎月請求書を眺めてどこで何が起きたかを推測することではない。

モデルは数か月ごとに入れ替わる。だがこの判断の方法論は陳腐化しない。