最初のLLM機能は、1つのサービスからBedrockへの直接呼び出しとしてリリースされる。10個目の機能も同じやり方で、10個のサービスから、10組の認証情報、10種類のリトライポリシーで、誰が何を使っているかを一箇所で把握できないままリリースされる。これがプラットフォームチームがLLMゲートウェイを必要としていると気づく瞬間であり、たいていの場合、それを作るのが安上がりだった時期から四半期は過ぎている。ゲートウェイとは、すべてのモデル呼び出しが通過する共有の玄関口であり、各チームが下手に再発明し続けている4つの要素、すなわち認証、クォータ、ルーティング、監査を所有するために存在する。

有用な捉え直し方は、ゲートウェイはAI機能ではないということだ。共有され、計測され、コストのかかる依存関係の前にすでに置いているのと同じコントロールプレーンに過ぎない。すべてのサービスに独自のデータベース管理者パスワードを持たせ、独自の接続数上限を選ばせることはしないはずだ。モデルアクセスも変わらない。違うのは、請求額の増え方が速く、障害モードがより騒がしいことだけだ。

ゲートウェイが実際に一元化するもの

その価値はリクエストをプロキシすることにあるのではない。アプリケーションコードに属すべきではない4つの横断的関心事を所有することにある。

  • 認証。呼び出し元はゲートウェイにサービスIDを提示する。Bedrockと話す唯一の認証情報を保持するのはゲートウェイだ。アプリケーションが長寿命のモデルキーを目にすることは一切なく、そのキーのローテーションは1回の変更で済み、20回にはならない。
  • クォータ。チームごと、モデルごとのトークン予算は一箇所で管理する。あるサービスの暴走ループは、共有の毎分トークン数上限を食いつぶして他のすべてを詰まらせるのではなく、自分自身の上限にぶつかる。
  • ルーティング。ゲートウェイは論理的なモデル名を具体的なデプロイにマッピングする。どのリージョンか、どのプロバイダーか、プライマリがスロットリングされたときのフォールバックはどれか。アプリケーションは特定のリージョンの特定のモデルIDではなく、「要約担当」を求めるだけでいい。
  • 監査。すべてのリクエストとレスポンスが一つの絞り込み点を通過するため、コストの帰属、プロンプトのロギング、不正利用の検知はすべて同じ一箇所で扱える。これがなければ、機能ごとのコストは考古学的な発掘作業になる。

これらのどれもモデル品質の問題ではないことに注目してほしい。これらはすべて、依存先がモデルであるというだけで新しく見えているプラットフォームの問題だ。

自前構築 vs LiteLLM vs API Gateway

誠実なパターンは3つあり、どれが正しいかは初日にどこまで上記が必要かによる。

LiteLLM（または類似のプロキシ）を採用する

LiteLLMのようなオープンソースのプロキシは、プロバイダー横断の統一API、キーごとの予算、基本的なルーティングを標準で提供する。4つの関心事をすでに理解している本物のゲートウェイを最速で手に入れる方法だ。トレードオフは、すべてのAI機能のクリティカルパスに位置するステートフルなサービスを自分たちで運用しパッチを当てる必要があり、ルーティングやロギングに関するその設計思想が自分たちの設計思想になってしまうことだ。2つ目や3つ目のLLM機能を立ち上げているほとんどのチームにとって、これは正しいデフォルトだ。コントロールプレーンを構築するのではなく買う選択になる。

API GatewayとLambdaに乗せる

すでにAWSに深く入り込んでいるなら、Amazon API Gatewayを小さなLambda authorizerとプロキシ関数の前に置けば、すでに運用しているプリミティブから認証、使用量プラン、スロットリング、アクセスログが手に入る。使用量プランがキーごとのレート制限を扱い、authorizerがIDを扱い、CloudWatchが監査証跡を扱う。コストは、モデル固有のロジック、ストリーミング、トークンカウント、プロバイダーフォールバックを自分で書いて所有することになる点だ。統制要件がAWS的な形をしていて、新しい依存関係を持ち込むより既存のプラットフォームを拡張したい場合、このパターンが勝つ。

独自サービスを構築する

自前構築が正しいのは、ルーティングや監査の要件が本当に特殊な場合、すなわち複雑なモデル選択ポリシー、リクエストごとのデータ所在地の判断、あるいは特定の規制当局を満足させる形のロギングが必要な場合だけだ。ゼロから構築するチームの多くは、実際にはLiteLLMをより遅く再構築しているに過ぎない。この選択肢は最後に手を伸ばすべきものであり、既製の選択肢では満たせない要件を具体的に挙げられるときに限る。

ゲートウェイが防ぐ失敗モード

ゲートウェイがなければ、失敗は劇的ではなく、じわじわと進む。認証情報が散らばる。各チームが独自のタイムアウトとリトライを設定するため、プロバイダー側の一時的な不調がリトライの嵐になり、トークンクォータを押し切ってしまう。誰も「サポート要約機能は先月いくらかかったか」に、サービス横断でログをgrepすることなしには答えられない。そしてセキュリティレビューが「どのデータでどのモデルを誰が呼び出せるのか」を尋ね、正直な答えは「わかりません」であり、それはローンチを止める答えだ。

ゲートウェイはこれらすべてを設定に変える。それが全体の主張だ。横断的な意思決定を20個のコードベースから追い出し、理由づけできる1つのコードベースに移す。

線引きを正しい場所に置く

ゲートウェイは薄く保つこと。IDとクォータ、ルーティング、ロギングを扱い、プロンプトの構築やビジネスロジックには関わらない。ゲートウェイがプロンプトを所有し始めた瞬間、それはネットワークホップを伴う共有ライブラリになり、すべてのチームがそのリリースサイクルに縛られてしまう。長続きする設計は、統制について強い意見を持ち、モデルに何を聞くかについては何の意見も持たない、地味なプロキシだ。

結論

2つ以上のLLM機能をリリースするプラットフォームチームは、いずれ必ずゲートウェイを構築する。唯一の選択は、それを意図的に、早い段階で、小さなプロキシのうちに構築するか、それとも認証情報が散らばり、請求額が謎になった後の後始末プロジェクトとして偶発的に、遅れて構築するかだけだ。可能ならプロキシを採用し、AWSネイティブならAPI Gatewayを拡張し、具体的に名前を挙げられる要件に対してのみゼロから構築する。ゲートウェイはAIが起きる場所ではない。どのみち必要になっていた統制が、ようやく居場所を見つける場所だ。

次に読む

このような共有コントロールプレーンを運用するプラットフォームおよびインフラ側の話は、クラウドのフィールドノートがercan.cloudにあり、ハブはercanermis.comにある。