リクエストのレート制限をやめ、トークン単位でスケジューリングする——DataRobot TokenGridの発表

現代のAIスタックにおける本当のボトルネック

企業のIT部門は、奇妙な問題を抱えています。トークンの消費コストとサードパーティ製モデルのサブスクリプション費用は増え続ける一方で、これらのワークロードを動かすGPUクラスターの使用率はわずか20%にとどまっています。この差が生まれる理由は1つです。アクセスを管理するツールが、ワークロードそのものを見る仕組みとして作られていないことです。

従来型のアプリケーションオーケストレーター、Kubernetesのフレームワーク、TykやEnvoyといったAPIゲートウェイは、CPU、GPUの数、メモリ、ネットワーク通信量といった静的なハードウェアを管理する仕組みです。トークン数やプロンプトの長さ、そしてLLM推論のコストを実際に左右するKVキャッシュへの負荷を把握できません。この死角は、AIスタックの両側に影響します。自社運用のGPU基盤を最適化することもできず、サードパーティ製モデルAPIのクォータ（利用上限）やレート制限、コストを統制することもできません。

現在、アクセス管理のためにプラットフォームチームが頼っているのは、LiteLLMのようなステートレスなプロキシです。静的な設定マップ、ハードコードされた帯域幅ルール、そして件数ベースのレート制限——たとえば1分あたり100リクエストという固定の上限です。単純なトラフィックであればこれで問題ありません。しかし、マルチターンの生成AIやエージェント型システムでは、すぐに機能しなくなります。トークンを認識しないゲートウェイは、メタデータが一致していれば2つのリクエストを同一視します。一方が10トークンの短い問い合わせで、もう一方が20万トークンのコンテキストファイルを渡していても関係ありません。クラスター内部での実際のコストは、桁違いに異なります。これらのワークロードを分離する仕組みがなければ、その20万トークンのリクエストがモデルサーバーのKVキャッシュを占有し、同じハードウェアを使う他のすべてのテナントのP95テールレイテンシーを押し上げ、クラスター全体で障害が連鎖し、無関係な基幹アプリケーションにまで429エラーによる拒否が連続する事態を招く可能性があります。ゲートウェイはどちらのリクエストも受け入れてしまいます。制御不能な1人のユーザーや、管理されていないエージェントループが、他の全員のモデル帯域幅を飽和させる制御不能な急増を引き起こすことがあります。ゲートウェイが、そもそもそれを検知する仕組みとして作られていないためです。

プラットフォームチームは、この摩擦に3つの場面で行き当たります。

モデルの急増とサイロ化
トークン管理は、自社基盤と、AWS Bedrock、Azure OpenAI、Anthropicといったサードパーティ製クラウドAPIとの間に分散しています。事業部門がそれぞれ独自にモデルのエンドポイントを立てたり、サードパーティ製APIに個別に接続したりするため、管理者は組織全体でクォータのルールを追跡・監査・適用できる単一の場所を持てません。

帯域幅の乗っ取り
静的なクォータは、受け入れ時点でのみ準拠を確認します。マルチターンのプロンプトやエージェントからのリクエストは、入り口では問題なく見えても、実行の途中でコンテキストサイズや処理の負荷がそのチェックポイントを大きく超えて膨らむことがあります。管理されていない1つのエージェントループが、共有クラスターの帯域幅を独占し、メモリを占有し、隣接するアプリケーションのリソースを枯渇させ、本番のSLAを踏み越えてしまうことがあります。しかも、それを検知するはずだった受け入れ時のチェックには一度も引っかからないままです。

実行時の需要変動
企業のAIアーキテクチャは、今やサードパーティ製クラウドAPIと自社運用のオープンソースモデルを組み合わせて使うのが一般的です。OSSモデルを自社で運用するということは、トークン単位のリソース急増を直接管理することを意味し、静的なハードウェア管理ではこれに追いつけません。従来型の基盤では、コンテナのスケーリングを実際のリクエストの挙動に合わせることができないため、プラットフォームチームは、トラフィックが急増した際の応答速度の低下と、数百万ドル規模の企業コンピュートを遊休状態のまま抱える高コストな過剰プロビジョニングとの間で、いずれかを選ばざるを得なくなっています。

DataRobot TokenGridは、既存のゲートウェイやプロキシを置き換えるのではなく、その隣で動作します。ステートフルでトークンを認識する容量スケジューラーとして受け入れ経路に直接組み込まれ、ゲートウェイが通すリクエストと、その下にある計算基盤が実際に処理できる量との間のギャップを埋めます。

DataRobot TokenGrid——ハードウェアの数ではなく、トークンの物理量でスケジューリングする

TokenGridは、静的なハードウェアの区切りを、共有され無駄なく使い切る容量プールに置き換えます。LLMゲートウェイと、モデルが動く場所——自社運用のクラスター、ハイパースケーラーがホストするモデル、あるいはAnthropicやGoogleといったベンダーから直接利用するサードパーティ製モデル——の間に位置するソフトウェアのスケジューリング層です。これを実現しているのが、次の3つの機能です。

1．動的なレート制限

TokenGridは、1分あたりのリクエスト数を固定する仕組みの代わりに、クラスターやAPIの物理的な制約に直接対応した、統一された多次元のクォータを適用します。1秒あたりのトークン数、トークン予算（TPM）、コンテナ単位のメモリといったライブ指標を追跡することで、生の計測データを、事業部門をまたいで一貫して適用できるポリシーベースのクォータへと変換します。これにより、負荷の高い推論ワークロードが、すでに飽和しているノードにさらに積み重なることを防ぎます。

2．公平配分エンジン

TokenGridは、すべての着信リクエストに対して多段階の公平性チェックを実行します。プロンプトがモデルに到達する前に、ワークロードの形状、テナントのクォータ利用履歴、現在のハードウェア制約を照らし合わせて判断します。

• ステージ1：ワークロードの分類 TokenGridは、ゲートウェイの層でプリフィル（初期処理）の負荷を見積もり、重いコンテキストを伴うリクエストと軽量な問い合わせを分けます。大きなコンテキストは専用またはチャンク分割したプリフィル経路に振り分け、キュー全体を止めてしまうことを防ぎます。
• ステージ2：クォータの適用 TokenGridは、自社運用のクラスターとサードパーティ製APIの両方について、トークン消費量を継続的に記録します。あるテナントが公平な配分枠を超えた場合、スケジューラーはその優先度を下げます。自社運用のクラスターでは、リクエストの優先度を下げ、プレフィックスキャッシュの優先ボーナスを取り消すことで、ルールを守っているテナントが高速なKVキャッシュノードへのアクセスを保てるようにします。サードパーティ製APIでは、バックプレッシャー（流入を絞る制御）とペース調整を適用し、利用量の多い1つのテナントが、共有のTPM／RPMの上限を使い切ったり、他の全員に対してプロバイダー側のレート制限（429エラー）を引き起こしたりしないようにします。
• ステージ3：メモリに基づくバックプレッシャー サードパーティ製APIはKVキャッシュの状態を公開していないため、コンテナの計測データが見える自社運用および管理下のデプロイでは、TokenGridがGPUメモリとキャッシュの使用率を直接監視します。モデルサーバー群が設定可能なKVキャッシュのしきい値を超えると、TokenGridは優先度の低いバックグラウンド処理にバックプレッシャー（HTTP 429）を適用し、対話的な処理を利用可能なノードへ移し、実行キューの順序を先着順から「処理時間の短いものを優先」する方式に切り替えます。

3．容量の自動調整

TokenGridは、コンテナの性能に関する指標を中央のToken Admin Serviceに集約し、そのデータを一定間隔でリアルタイムのトラフィックパターンと照合します。これにより、インフラ層で起きていることとトラフィック層で起きていることの間のループが閉じ、モデル群全体にわたって実行スロット、TPMのしきい値、RPMの上限を自動で提案・再調整できるようになります。プラットフォームチームは、トラフィックの急増に備えて過剰にプロビジョニングする必要がなくなります。TokenGridは実際の利用パターンから学習し、それに応じて割り当てを調整するため、他のモデルや学習用ワークロードに使えるGPU容量が生まれます。

オンプレミスとハイブリッド環境のために、そしてこれからのために

この課題を最も多く耳にするのは、主にオンプレミスで運用しているプラットフォームチームからです。こうした組織は、専用のベアメタルGPUクラスターに数百万ドル規模の投資を行っており、無駄になった容量の1パーセントポイントごとが実際のコストとして跳ね返ります。オンプレミスの管理者は、開発者による突発的な負荷の急増と基幹業務アプリケーションを切り分ける標準的な手段を持たないまま、硬直的な計算資源の境界を管理しているのが実情です。

TokenGridは、静的なプロキシ設定では対応できないトラフィックの急増に対して、こうした環境にすぐに使える答えを示します。軽量でコンテナを認識するスケジューリング層として、プラットフォームチームは受け入れ経路上で直接、GPUの余剰リソースを取り戻し、多次元のクォータを適用し、1つのテナントが他のすべてを止めてしまう事態を防げるようになります。

これは、すぐに得られる価値です。より重要なのは、長期的な変化です。固定的なハードウェア配置から、継続的かつ自動化された容量スケジューリングのループへ移ることで、暴走したエージェントループを今どう抑えるかという話に留まらず、企業のLLM推論オーケストレーション全体の考え方そのものを見直す道が開けます。

企業のAI活用が、単純なチャット画面からマルチターンのエージェント型システムへと移っていく中で、成果を上げるのは、GPUを過剰にプロビジョニングしたり、APIプロキシに静的なレート制限を後付けしたりするチームではありません。トークンが自社の基盤の中を実際にどう流れているかを理解しているチームです。TokenGridは、管理されていないモデルの消費を、混乱の原因から予測可能で効率的なものへと変えます。

DataRobot TokenGridは現在、一部の共同エンジニアリングパートナーおよびエンタープライズアカウントを対象にプライベートプレビューを提供しています。アーキテクチャの詳細確認や早期アクセスのご希望は、プロダクトチームまでお問い合わせください。