Baseten、本番環境の推論における2つのAIゲートウェイパターンを解説

単なるプロンプト以上の判断を伴うすべてのモデルリクエスト

顧客がモデル API にリクエストを送信した瞬間、モデルがトークンを生成する前段階で、システムは驚くほど多くの決断を下す必要があります。

• API キーは有効か？
• これはどの顧客、どのプランに紐づくものか？
• どのモデル、あるいはデプロイメントがリクエストを処理すべきか？
• 顧客の利用制限に達していないか？
• サービングインフラは健全な状態にあるか？
• 利用量はどのように配分・集計されるか？
• システムの一部に障害が発生した場合、顧客にはどのような表示を行うべきか？

すべての本番環境における AI システムが、どこかでこれらの問いに答えなければなりません。意図的なアーキテクチャ設計がない場合、その回答はアプリケーションコード、認証サービス、インフラ設定、請求処理パイプライン、インシデント対応手順など、各システムに散在してしまいます。それぞれのコンポーネントがリクエストに対して異なる視点を持つことになります。

AI ゲートウェイは、こうした判断を一貫した制御層へと集約します。この層の役割は以前よりも重くなっています。Menlo Ventures の試算によると、エンタープライズにおけるモデル API への支出は、2024 年後半の約 35 億ドルから、2025 年半ばには 84 億ドルへと急増しました（ソース）。現在、モデル呼び出しは、重要なかつ急速に成長する運用コストであり、収益源となるか、あるいはその両方となっています。

基盤システムも変化しています。チームはもはや単一のエンドポイントで単一モデルを提供するのではなく、複数のモデルバージョンやデプロイメントを運用し、外部顧客向けに API を公開し、推論インフラを収益源として捉えるようになりました。

AI を本番環境で運用するすべてのチームにとってこれらの問いは重要ですが、モデルの所有・ファインチューニング・運用を行い、安全に複数顧客へ提供しなければならない場合、その重要性は決定的なものになります。そのような状況では、ゲートウェイは単なる他人の API への便利なインターフェースではなく、自社が販売する製品の不可欠な一部となります。

ほとんどの AI ゲートウェイは以下の 2 つのパターンのいずれかに分類されます

「AI ゲートウェイ」という用語は、モデルのルーティング、認証、観測性、コスト管理、信頼性、ガバナンス、あるいはこれらの組み合わせを扱う製品に対する広義のラベルとして使われています。実務上、本番環境でのデプロイメントは主に以下の 2 つのパターンのいずれかに分類されます。

主要な 2 つの AI ゲートウェイパターン：アプリケーション側で複数のモデルプロバイダーにアクセスするケースと、自社が運用するモデルを顧客向けに公開するケース。

アクセスゲートウェイ：1 つのアプリケーション、多数のモデルプロバイダー

最初のパターンでは、アプリケーションチームがゲートウェイの主要な利用者となります。このゲートウェイは、異なるプロバイダー API に対して統一されたインターフェースを提供し、認証情報やポリシーを一元管理します。また、利用状況データの収集や、外部モデルサービスへの切り替え・フォールバック機能もサポートします。

これは、開発者が AI ゲートウェイと最初に連想するパターンです。Cloudflare AI Gateway、Kong AI Gateway、LiteLLM、OpenRouter、Portkey、Vercel AI Gateway などがよく挙げられます。これらはアプリケーション側のアクセスやルーティングのために評価されることが多いですが、機能の範囲は製品によって異なります。

サービングゲートウェイ：自社のモデル、多数の顧客

2 つ目のパターンでは、トラフィックの関係性が逆転します。ゲートウェイが外部の顧客と、組織が運用するモデルの間に位置します。ここで主要な利用者となるのは、サードパーティ製 API を消費するアプリケーションではなく、モデル所有者自身です。

サービングゲートウェイの役割は、認証情報の発行、テナントの分離、利用制限の適用、安定したブランド付き API の公開、使用量のメータリング、そして顧客からのトラフィックを生産環境のモデルデプロイメントへ接続することです。

両方のパターンは、モデルリクエストに関するポリシーを一元化しますが、最適化の対象となる所有者やトラフィックフロー、解決すべき運用課題は異なります。これらを互換性のあるものとして扱うチームは、誤った製品を選定してしまうことになります。

この 2 つのパターンを分ける問いは、「ゲートウェイが制御するトラフィックの主体は誰か、そしてその判断を誰に代わって行っているのか」という点です。アクセスゲートウェイは、エンジニアリングチームやプラットフォームチームに代わり、アプリケーションからのアウトバウンドモデルトラフィックを制御します。一方、サービングゲートウェイは、モデル事業に所属する顧客のインバウンドトラフィックを制御します。この違いが、ほぼすべての機能の重要性を形作ります。

サービング側のゲートウェイにおけるリクエスト処理

本記事の後半では、主にサービング側について解説します。これは 2 つのパターンのうち文書化が少ない方であり、モデルを自社で所有している場合にアーキテクチャに最も大きな変化をもたらすパターンです。

サービングゲートウェイが何を管理しているかを理解する最も明確な方法は、顧客からの単一のリクエストを追跡することです。

サービング側のゲートウェイは、ルーティング、保護、推論、メータリング、監査の各段階において、顧客のアイデンティティとコンテキストを保持します。

アイデンティティの確立

ゲートウェイは認証情報を検証し、それを適切な顧客コンテキスト（組織、ユーザー、プロジェクト、プラン、または権限）に解決します。

認証情報は、リクエストを制限、利用記録、請求、サポート、監査履歴と結びつける鍵となります。キーが有効であることを示すだけで、どの顧客や商業ポリシーに属するかがわからないゲートウェイでは、トラフィックの認証はできても、ビジネス運営には役立ちません。

提供パスの選択

呼び出し元が特定された後、ゲートウェイは要求されたモデルを解決し、デプロイメント、リージョン、容量プール、モデルバージョンなど、利用可能な提供パスを選択します。より高度なシステムでは、この決定にバックエンドの状態—デプロイメントの健全性、容量、KV キャッシュの局所性—を考慮し、リクエストが既存の文脈を再利用できる場所に届くようにします。

モデルルーティングはモデルのアイデンティティ、容量、可用性、顧客ポリシーと密接に関連しています。このポリシーをゲートウェイ内に保持することで、呼び出し元となるすべての製品を変更せずに、モデルの提供方法を柔軟に変更できます。

サービス保護

ゲートウェイは、インフラストラクチャや他のユーザーを守るためのポリシーを適用します。具体的には、リクエスト数やトークンの制限、並行処理の制約、過負荷防止、テナント間の分離です。これらの制御により、あるテナントの悪天候がすべてのテナントに波及するのを防ぎます。

完全なサービス停止は明白に最悪のケースですが、本番環境でより頻繁に発生するのは部分的な性能低下です。バックエンドが故障せずに遅延したり、顧客から予期せぬリクエストバーストが発生したり、あるリージョンがキャパシティ限界に近づいたりする状況です。

これらの条件下において、サービングゲートウェイは単にサービスが技術的に稼働しているか停止しているかを判断するだけでなく、明確な対応策を示す必要があります。

利用量の計測

リクエストが処理された後、モデル所有者は「何が」「誰によって」消費されたかを把握する必要があります。計測単位としては、入力トークン数や出力トークン数、文字数、リクエスト数、処理時間、あるいはモデル固有の指標などが該当します。

重要なのは、これらの利用記録を正確な顧客情報とサービングパスに紐付けることです。

こうした記録は請求書の発行、価格設定、キャパシティ計画、利益率分析、カスタマーサポート、および不正利用の検出を支える基盤となります。もし計測機能をアプリケーションコード内に実装すると、ストリーミング処理や部分的な障害への対応、推論システムとの整合性確保など、重複した実装が必要となり、それぞれが独立してこれらの課題を解決しなければなりません。

すべてのリクエストを把握できるレイヤーに、計測の責任を持たせるべきです。

監査可能な結果の生成

最後に、システムは発生した事象を記録します。どのデプロイメントがそのリクエストを処理し、遅延時間はどれほどだったか、エラーが発生した場合はどのようなものか（もしあれば）、利用量はどの程度で、どのようなポリシー判断に基づいて処理されたのか——これらすべてを記録する必要があります。

重要な要件は、外部からの顧客リクエストと内部の推論イベントを結びつける機能です。これがなければ、チームは互いに連携しない 2 つのシステムでデバッグを行うことになります。つまり、顧客が見る API サーフェスと、応答を生成するインフラストラクチャが分断された状態です。顧客が請求書に異議を唱えたり、処理が遅いことを報告したりした際、この「結びつき」があるかどうかで、明確な回答が得られるか、調査が必要になるかが決まります。

AI ゲートウェイで評価すべきポイント

すべてのゲートウェイは認証、ルーティング、観測性を謳っていますが、これらの機能だけではアーキテクチャが適切かどうかは判断できません。以下の問いに答える必要があります。

カスタマーモデルを表現できるか？

本番環境のモデルビジネスにおいて、API キーの単純なリストしか扱えないケースは稀です。顧客にはユーザーやプロジェクトが含まれる場合があり、プランごとに異なる制限が設定されることもあります。また、エンタープライズアカウントでは、利用履歴を保持したまま認証情報のローテーションが必要になることもあります。

ゲートウェイのアイデンティティモデルが、API の販売方法やサポート体制と整合しているかを評価してください。単にキーを生成できるかどうかだけでなく、実際の運用イメージに合致しているかが重要です。

テナント間の分離は保たれるか？

ある顧客が急激なトラフィックの増加（バースト）を起こし、クォータを使い果たしたり、過度な並行処理を行ったり、不正なトラフィックで API を洪水のように攻撃したりした場合、ゲートウェイはどう振る舞うのかを問う必要があります。

多くのゲートウェイは仕様書上で制限機能を備えていると謳っています。真の試練は、基盤となるモデルがキャパシティに近づいた際でも、サービスの商業的・運用的な境界線を維持できるかどうかです。分離機能は主張するのは簡単ですが、実証するのは困難です。「存在するか」ではなく、「どのように機能するのか」を問うべきです。

商用 API のサポートは可能か

ゲートウェイは、請求、認証情報の管理、カスタマーサポート、レコンシリエーション（照合）のために、信頼性の高いアイデンティティと利用状況の層を提供する必要があります。

ゲートウェイが直接請求書発行システムやサブスクリプション管理システムになる必要はありません。しかし、それらのシステムにはどこかから信頼できるデータが必要です。

推論に関する情報はどのように扱うか

従来のゲートウェイは HTTP リクエスト、エンドポイント、ステータスコードを理解します。一方、推論を認識するゲートウェイは、デプロイメント状況、ストリーミング生成、トークン消費量、バックエンドの健全性、モデル固有のパフォーマンスシグナルなども理解できます。

この文脈こそが、ゲートウェイが何を測定可能にし、どのような判断を安全に行えるかを決定します。

トレードオフは以下の通りです。推論から切り離されたゲートウェイは、より高い移植性やプロバイダー中立性を提供できる可能性があります。その代わり、必要な文脈情報を再構築するために追加の連携が必要になります。一方、推論に近い位置に配置されるゲートウェイは、運用面での深い認識を得られる一方で、その連携がどれほど移植可能か、そして深夜 2 時に何かが起きた際に誰が対応するのかを注意深く確認する必要があります。

実行環境はどこか

ゲートウェイは、アプリケーションレイヤーで動作するか、独立したサービスとして稼働するか、あるいは推論プラットフォームと併設されるかのいずれかです。この配置場所が、推論パス内でどのような判断が可能になるか、バックエンドのコンテキストをどの程度利用できるか、ポリシー適用とトークン生成の間に別のサービス境界が存在するかどうかを決定します。さらに、障害ドメイン、データ経路、観測可能性、デプロイメントの所有権、アイデンティティ統合、そして移植性にも影響を与えます。

適切な選択は、ゲートウェイが制御するトラフィックの種類によって導き出されます。アクセス側のトラフィックは、アプリケーションレイヤーまたは独立したプロキシを指向する傾向があります。一方、サービング側のトラフィックは推論層を指向します。モデルの所有権が誰にあるかによっても答えは変わります。

チームがまだ構築すべきもの

ゲートウェイを導入しても、商用モデル API の運用に必要な要素すべてが不要になるわけではありません。開発者ポータル、サブスクリプション管理、請求書発行、顧客分析、サポートツールの整備など、チームが引き続き行う必要がある業務は残ります。

ゲートウェイが何を提供するかだけでなく、その機能とあなたが展開を計画している完全な顧客体験の間に何がまだ必要なのかを問うべきです。

モデルラボの場合、重要なゲートウェイの判断は推論に近い領域で行われることが多い

組織的な問いに戻りましょう。ゲートウェイはどのようなトラフィックを制御し、誰に代わって判断を下しているのか。API を提供するモデルラボにとって、答えは明確です。「顧客からのトラフィック」であり、「あなたの代わりに（つまり、ラボの立場で）」判断を行っています。

アクセスポイントゲートウェイでは、モデルプロバイダをアプリケーション側から見た単なる HTTP エンドポイントとして扱えるため、互換性のあるものとして置き換え可能なケースが多いです。しかし、サービス提供用ゲートウェイ（Serving Gateway）はそうはいきません。その判断は、モデルを実行するインフラストラクチャと直接結びついています。具体的には、どの顧客が認証されているか、利用可能リソースの制限はどうなっているか、リクエストがどのような使用量を生むのか、そして背後にあるデプロイメントが信頼性を持って処理できるかどうかといった要素を考慮します。

自社のモデルを提供するチームにとって、最も効果的なゲートウェイの判断は、推論（Inference）に近い場所で行われることが多いです。サービス提供層と推論層を統合することで、具体的なメリットが得られます。例えば、高コストなモデル実行前にポリシーを適用できる点や、顧客の身元確認と利用状況のアトリビューションを同一システムで処理できる点が挙げられます。また、ゲートウェイは下位のデプロイメントの状態を外部から再構築するのではなく、その存在を意識した状態で動作できます。さらに、顧客からのリクエストからモデルへのレスポンスに至るまでの間に、独立して運用されるコンポーネントの数を減らすことも可能です。

これらは、アプリケーション側やプロバイダに依存しないゲートウェイが不要になることを意味しません。それらのゲートウェイは異なる課題を解決するものであり、一つの組織が両方を適切に運用することも十分にあり得ます。例えば、社内アプリケーションが外部モデルを利用する方法を統制するゲートウェイと、自社のモデルを顧客に提供する別のゲートウェイを併用するケースです。

Baseten Frontier Gateway におけるこのアーキテクチャの実装方法

サービス提供側ゲートウェイの具体的な実装方法を検討すると、サービス提供用ゲートウェイと推論用ゲートウェイの違いがより明確になります。

Baseten Frontier Gateway は、Baseten 上でホストされたモデルを生産環境向けのマルチテナント API として公開するチーム向けに管理されるサーバーサイドのゲートウェイです。このゲートウェイは Baseten の Dedicated Inference（専用推論）を基盤として構築されており、モデル開発ラボが個別のゲートウェイシステムを構築・運用する必要なく、前述のような顧客向けの制御機能を直接利用できます。

カスタマーアクセスの管理

Frontier Gateway は、ラボが下流のカスタマーに配布する API キーの生成と管理を行います。すべてのリクエストはモデルに到達する前に認証および認可が行われ、これらの制御機能はアプリケーションコードや別途運用するプロキシではなく、推論パス内でネイティブに処理されます。

利用制限の適用

ラボは、各 API キーに対してトークン数またはリクエスト数ベースの利用制限を設定できます。これにより、デプロイメントが濫用されるのを防ぎ、あるテナントからのトラフィックが他のすべてのユーザーのサービス品質を低下させるリスクも軽減されます。制限はグループ（ユーザーがマッピングされたグループ）単位やモデル単位でスコープを指定でき、キーは所属するグループの制限を引き継ぐため、顧客の認証情報をローテーションしても、その利用料金の規模感（spend posture）が変わることはありません。

モデル消費量の追跡

Frontier Gateway は、各 API キーごとのトークン数と文字数の消費量を記録します。これにより、ラボはすべての推論呼び出しに課金やメータリングのロジックを巻きつけることなく、顧客レベルでの利用実績データを取得できます。

ブランド名で API を提供

リクエストは、ラボ独自のドメインを通じて公開されます。Baseten はこれらのリクエストを基盤となる推論インフラストラクチャへルーティングします。顧客は Baseten ではなく、あなたの API とブランドと連携します。

本番環境の推論インフラ上で運用する

Baseten の Frontier Gateway は、管理対象の推論インフラストラクチャと同じ場所に配置されています。ラボは、弾力的で従量課金型の GPU リソースや推論の可視化機能、Baseten が提供するエンタープライズグレードのセキュリティとコンプライアンス体制、そして高い稼働率を保証する SLA などを含む、その下のプラットフォームをそのまま継承できます。

Poolside が Laguna モデルをリリースした際、ホワイトラベル化した API はアカウント作成から 48 時間以内に Frontier Gateway で稼働しました。Laguna XS.2 では最初のトークン生成までの時間（TTFT）が 146 ms、Laguna M.1 では 605 ms という結果でした。

Frontier Gateway はアクセスパターンではなく、提供パターンを前提に設計されています。これこそが、推論パスの内部で動作できる理由です。ただし、このゲートウェイは Baseten 上で稼働するモデルを提供するチーム向けに作られており、サードパーティ製の独自 API プロバイダ間でのアプリケーショントラフィックをルーティングするための汎用プロキシとして位置づけられているわけではありません。

モデルの重みから、顧客が使える製品へ

トレーニング済みのモデルが、実際に利用可能なモデル API になるまでには、いくつかのステップが必要です。その間に挟まれるのが、この記事で説明した要素たちです。つまり、アイデンティティ、テナンシー、制限、信頼性、メータリング、可視化、そして開発者向けの安定したエンドポイントなどです。

モデルが研究段階の成果物から、実際の製品へと転換する重要なレイヤーです。すべての本番環境で稼働している AI システムにはゲートウェイが存在します。その責任範囲がアプリケーションコードやインフラストラクチャ、運用ツールに分散していても構いません。重要なのは、これらの責任を意図的に構築するか否かというアーキテクチャ上の判断です。

モデルをスケーラブルで本番環境対応の API へと転換するお手伝いが必要であれば、エンジニアと話すために お問い合わせください。また、Baseten Frontier Gateway については こちら で詳しくご覧いただけます。