【ITニュース解説】My LLM chat API's routing tiers taught me that 'auto' is a pricing decision, not a quality decision

システムエンジニアを目指す皆さんにとって、最近よく耳にする「大規模言語モデル（LLM）」は、これからの開発に欠かせない技術となるだろう。チャットボットや文章生成、プログラミング支援など、その応用範囲は非常に広い。しかし、こうした強力な技術を利用する上で、避けて通れないのが「コスト」と「効率」の問題だ。今回のニュース記事は、まさにその核心に迫る内容で、複数のLLMを統合して提供するAPIサービスを運用する筆者が、実体験を通じて得た教訓について語っている。

筆者は、OpenAIが提供するようなチャットAPIと互換性のある独自のサービスを開発している。このサービスは、なんと50種類以上のLLMを裏側で利用できるようにしているのが特徴だ。当初、このAPIの設計はとてもシンプルだった。ある特定のモデル名を選べば、それに対応する料金で、そのモデルの機能がそのまま利用できるというものだ。しかし、このシンプルな設計に問題があることに、筆者自身の開発した「エージェント」（自動でタスクを実行するプログラムのこと）がLLMを使い始めたときに気づいた。エージェントが非常に簡単な質問、例えば「このファイルはPDFですか？」といった内容をLLMに問い合わせる際にも、高価で高性能な「最先端モデル」（frontier model）を使ってしまい、無駄にコストがかさんでいたのだ。LLMの利用料金は通常、「トーケン」という単位で計算される。トーケンは単語や文字のまとまりのようなもので、生成された文章の量に応じて費用が変わるため、簡単な質問に高価なモデルを使うことは、まるでコンビニで牛乳を買うために高級車を使うようなものだ。

この無駄をなくすため、筆者はAPIの利用方法に3つの「ルーティング層」（routing tiers）を追加した。ルーティングとは、リクエストに応じて最適な経路や処理を選択することだ。

1. eco（エコ）層: この層は、安価で処理速度が速いモデルを利用する。シンプルなタスクや、そこまで高い精度が求められない場合に適している。
2. premium（プレミアム）層: こちらは、性能が高く、複雑な推論や高度な文章生成が得意な最先端モデルを利用する。その分、料金も高くなる。
3. auto（オート）層: この層が最も重要で、リクエストの内容に応じて、自動的にeco層のモデルを使うか、premium層のモデルを使うかを判断する。

筆者は、このauto層の導入自体は驚きではなかったと述べているが、驚いたのはauto層が「実際に何を判断しなければならなかったか」という点だ。最初は、リクエストの「プロンプト」（LLMへの指示文や質問）の長さだけでモデルを切り替えられると考えていたかもしれない。しかし、それは間違いだった。例えば、たった40トーケン程度の短いプロンプトでも、「この数学の定理について詳しく説明してください」といった高度な質問であれば、最先端のpremiumモデルが必要になる。逆に、4,000トーケンもの長いプロンプトでも、「この契約書から日付だけをすべて抽出してください」というような単純な情報抽出であれば、安価なecoモデルで十分な場合がある。つまり、プロンプトの長さだけでは、モデルの適切な選択はできないのだ。

そこで筆者は、auto層を単なる「ロードバランサー」（複数のサーバーに処理を分散させる仕組み）ではなく、独自の「小さな決定エンジン」（small decision engine）として機能させることにした。具体的には、以下の要素を組み合わせて、リクエストごとに最適なモデルを判断する「分類器」（classifier）を構築した。

• タスクタイプ: リクエストが「要約」「情報抽出」「コード生成」「論理的推論」「一般的なチャット」のどれに該当するかを判断する。例えば、コード生成であれば高性能なモデル、情報抽出であれば比較的シンプルなモデル、といった具合だ。
• プロンプトの長さのバンド: プロンプトの長さをいくつかの範囲（バンド）に分けて、それぞれのバンドで適切なモデルの候補を絞り込む。
• 呼び出し元ごとのオーバーライド: 特定のエージェントや開発元からのリクエストに対しては、個別にモデル選択のルールを上書きできるようにする。 このようにして、auto層はリクエストの内容を多角的に分析し、最適なモデルを動的に選択する賢い仕組みへと進化した。

しかし、予期せぬ問題も発生した。それが「レイテンシ」（Latency、処理の遅延）だ。eco層のモデルは高速だが、時々、あまり一般的ではない「エッジケース」（特殊な状況や例外）で誤った回答を返すことがあった。すると、筆者のエージェントは、間違った回答を受け取ると、問題を解決するために再度ecoモデルに質問し直したり、最終的にpremiumモデルに切り替えて質問し直したりする「再試行」（retry）の動作をしてしまっていた。結果として、2回のecoモデルへの問い合わせと1回のpremiumモデルへの問い合わせが発生し、最初からpremiumモデルを使っていた場合よりも、かえってコストが高くなってしまうケースがあったのだ。この状況は、安価なモデルを使ったつもりでも、結局は高いコストになってしまうという皮肉な結果を生んでいた。

この問題を解決するため、筆者は「信頼度閾値」（confidence threshold）という仕組みを導入した。これは、ecoモデルからの回答を分析し、その回答が「不確実」であると判断された場合に、すぐにpremiumモデルにエスカレートして質問をやり直す、というものだ。例えば、ecoモデルの回答が非常に短すぎたり、あいまいな表現（「おそらく」「かもしれません」といった曖昧な言葉）を含んでいたりする場合、「このモデルは自信がないな」と判断し、エージェントが何も知らずに再試行を繰り返す前に、より高性能なモデルに切り替えるのだ。これにより、無駄な再試行によるコスト増大を防ぎ、全体としての効率とコストパフォーマンスを高めることができた。

筆者の提供するLLM APIサービスは、プロバイダが直接提供するLLM（例えばOpenAIのAPIなど）を直接利用する場合と比較して、いくつかのメリットとデメリットがある。 メリットとして挙げられるのは「統合税」（integration tax）の節約だ。通常、複数のLLMプロバイダを利用しようとすると、それぞれのプロバイダごとに異なるAPIキーを管理し、異なるURLへリクエストを送り、それぞれの課金システムと契約を結ぶ必要がある。これは、システム開発者にとって非常に手間がかかる作業だ。しかし、筆者のサービスを利用すれば、APIキーは一つ、リクエスト先のURLも一つ、課金も筆者のサービスとの関係だけで済む。これは、特に多数のLLMを横断的に利用したい場合に、大きな開発コストと管理コストの削減につながる。 一方で、デメリットとして「ルーティング税」（routing tax）が発生する。これは、リクエストごとにauto層の分類器が動作するためにかかるわずかな処理時間（約2ミリ秒）のことだ。この処理は、直接プロバイダのAPIを呼び出す場合には発生しないオーバーヘッドとなる。筆者自身の開発したエージェントにとっては、このルーティング税を支払っても統合税の節約効果の方がはるかに大きく、十分な価値があると判断している。しかし、もし開発者が最初から「このタスクにはこのモデルを使いたい」という明確な意図を持っている場合、auto層による自動判断は不要な手間であり、モデル名を明示的に指定してauto層をバイパスすることも可能だ。

この一連の経験から得られた最も重要な教訓は、「auto」（自動）という言葉が、「便利さ」を表す機能のように聞こえるが、実際には「コスト管理」のための機能である、という点だ。それは便利さという見せかけの衣装をまとったコスト管理の仕組みなのだ。システムエンジニアとしてエージェントのインフラストラクチャを設計する際には、エージェントが「自分は何を必要としているのか」を常に知っているわけではない、という前提で設計する必要がある。なぜなら、ほとんどのエージェントは、ほとんどの場合、自分に必要なものを正確には理解していないからだ。この教訓は、LLMを活用したシステム開発において、コストと性能のバランスをどのように取るべきか、深く考えるきっかけを与えてくれるだろう。