本番のLLMトラフィックの大半は難しくない。分類、抽出、短い書き換え、ルーティングであり、これらは小さく速いモデルが正確かつ安価にこなす種類の作業だ。それでもよくあるパターンは、すべての呼び出しを利用可能な最大のモデルに配線することだ。それが「とにかく動く」からであり、そして請求額とレイテンシの両方が高いことを不思議に思う。Amazon Bedrockでは、Claude Haiku 4.5とClaude Opus 4.5の両方が利用可能であり、エンジニアリング上の勝利はどちらかを選ぶことではなく、タスクの種類でルーティングし、安価なモデルに大多数を処理させ、高価なモデルはデフォルトではなくエスカレーション経路にすることだ。

捉え直し方はこうだ。モデルの選択はプロジェクト全体の決定ではなく、タスクごとの決定だ。すべてのリクエストを最も難しいリクエストに合わせてサイジングするのは、すべてのワークロードを最大のインスタンスタイプで動かすのと同じ間違いだ。適正サイジングとは、個々の呼び出しの難易度にモデルを合わせることであり、呼び出しの大部分にとって適正なサイズは小さい。

なぜ大きなモデルが誤ったデフォルトなのか

フロンティアモデルをデフォルトにすることは安全に感じられるが、2つの面でコストがかかる。OpusクラスのモデルはトークンあたりHaikuクラスのモデルの数倍のコストがかかるため、90パーセントが機械的なワークロードは、小さなモデルが完璧にこなす作業にフロンティア価格を払っていることになる。より高性能なモデルは一般に応答に時間がかかるため速度も遅く、ユーザーが速度を最も意識する高頻度でシンプルな呼び出しにおいて、まさにレイテンシを膨らませてしまう。

隠れたコストは、シンプルなタスクに大きなモデルを使っても、より良い結果が出ることはめったにないという点だ。メールから日付を抽出することや、チケットを6つのバケットのいずれかに分類することは、能力を投入したところで改善しない。より多く払い、より長く待って得られる答えは、小さなモデルでも正しく出せたはずのものだ。

タスクの種類でルーティングする

うまくいく設計は、リクエストを難易度で分類し、それに合ったモデルに送ることだ。ユーザー単位でも機能単位でもなく、タスクの種類単位で分ける。

  • 機械的な作業はHaikuに送る。分類、抽出、フォーマット変換、短い要約、ツール引数の構築、ルーティングの判断だ。高頻度で曖昧さが少なく、小さなモデルの方が安価かつ高速で、品質の損失はない。
  • 判断を要する作業はOpusに送る。多段階の推論、曖昧な指示、長文コンテキストの統合、そして間違った答えのコストが高いものすべてだ。頻度は低いが、その能力が実際に結果を変えるため割増料金の価値がある。
  • ルーター自体は安価だ。入力の長さとタスクの種類に基づくヒューリスティック、あるいは1回の小さなモデル呼び出しがクラスを決める。すべてをトップモデルにデフォルトさせないことで節約できる金額に対して、ルーティングのコストは誤差の範囲だ。

エスカレーション経路としての大きなモデル

最も信頼できるパターンは、フロンティアモデルを玄関口ではなくエスカレーションにすることだ。まず小さなモデルを試す。成功すれば、機械的な大多数についてはそうなるはずだが、コストとレイテンシのほんの一部で完了する。チェックに失敗した場合、つまり信頼度が低い、スキーマ不正な出力、明示的な「わからない」といった場合には、そのリクエストだけを大きなモデルにエスカレーションする。

result = invoke(HAIKU, task)
if not passes_check(result):
    result = invoke(OPUS, task)   # escalate only the hard cases
return result

これは経済性を逆転させる。まれな難しいケースをカバーするためにすべてのリクエストにOpus価格を払う代わりに、一般的なケースにはHaiku価格を払い、安価な試みが目に見えて不足していたときだけOpusに手を伸ばす。トレードオフは、それを必要とする少数のリクエストへの1回の追加呼び出しと引き換えに、必要としない大多数における大きな節約だ。

配分を仮定する前に測定する

チームが間違える場所は、タスクの構成比を測定せずに推測することだ。ルーティングする前に、実際のトラフィックをサンプリングし、どれだけが本当に機械的でどれだけが本当に難しいかをラベル付けすること。この数字はほぼ常にチームが予想するよりも機械的な割合が高く、それこそが大きなモデルをデフォルトにすることがこれほど無駄になる理由だ。それはまた、エスカレーションのトリガーをどこに設定すべきかも教えてくれる。小さなモデルがトラフィックの92パーセントをきれいに処理しているなら、エスカレーション率は8パーセント前後になるはずであり、それよりはるかに高い率は、チェックが厳しすぎるかルーティングが較正されていないことを意味する。

結論

HaikuもOpusも数ヶ月前からBedrockに存在しており、重要なのはどちらかを選ぶことではなく、それぞれが適した場所で使うことだ。タスクの種類でルーティングし、機械的な大多数は小さく速いモデルに送り、フロンティアモデルは判断を要する少数派のために、できれば失敗したチェックによって発火するエスカレーション経路として確保すること。配分をチューニングする前に、実際のタスク構成比を測定すること。モデルの適正サイジングはインスタンスの適正サイジングと同じ規律であり、最速で最も安価なシステムとは、小さなモデルが正確にこなせる作業にフロンティア価格を払うのをやめたシステムだ。

次に読む

モデル間のルーティングとキャパシティに関するプラットフォーム側の話は、クラウドのフィールドノートがercan.cloudにあり、ハブはercanermis.comにある。