Token Management in Multi-Tenant AI Inference Platforms

本論文は、マルチテナント AI 推論プラットフォームにおいて、リソース利用率とサービスレベル保証の両立を実現するため、リクエストの許容と自動スケーリングを推論固有の単位（トークンスループット等）で統一的に管理する「トークンプール」という制御平面の抽象化を提案し、Kubernetes 環境での実験により、過負荷時の P99 レイテンシの安定化や異質 SLO を持つワークロード間の公平なリソース配分が達成されることを実証しています。

要約

この論文は、**「AI へのアクセスを管理する新しい『通貨』の仕組み」**について書かれています。

AI（特に大規模言語モデル）をビジネスで使おうとすると、多くの人が同時に使おうとして混雑が起き、誰かのサービスが遅くなったり止まったりするという問題があります。この論文は、その問題を解決するための「Token Pools（トークン・プール）」という新しい考え方を提案しています。

これを日常の言葉と面白い例え話を使って説明しましょう。

---

🏢 従来の問題：「人数制限」だけじゃダメな理由

今までの AI サービスの管理は、**「1 分間に何回リクエストできるか（レート制限）」というルールでやられていました。
これは、「レストランで 1 時間に 3 回しか注文できない」**というルールに似ています。

しかし、AI の世界ではこれでは不十分です。なぜなら、リクエストの「重さ」が全然違うからです。

• 軽いリクエスト： 「今日の天気は？」（短い答え、軽い作業）
• 重いリクエスト： 「100 ページの論文を要約して、さらに 3 つのアイデアを考えて」（長い答え、重い作業、メモリを大量に使う）

【例え話：タクシーの待ち合い】
従来のルールだと、「1 時間に 3 台まで乗車可能」というルールになっています。

• 軽いリクエストは「1 人乗りのタクシー」。
• 重いリクエストは「10 人乗りの大型バス」。

もし、10 人乗りのバスが 3 台来たら、1 分も経たずに駐車場（GPU メモリ）は満杯になります。その間に、1 人乗りのタクシー（軽いリクエスト）が来ても、**「定員オーバーだから乗れません！」**と断られてしまいます。
でも、実際にはバスが 1 台空いていれば、1 人乗りのタクシーは乗れるはずなのに、ルールが「回数」しか見ていないので、無駄なスペースが生まれてしまいます。

💡 新しい解決策：「Token Pools（トークン・プール）」

この論文が提案するのは、「回数」ではなく「リソースそのもの」を通貨として扱うことです。
AI の世界では、リソースは主に 3 つあります。

1. トークン速度： 文字を生成する速さ（秒間何文字）。
2. KV キャッシュ： 会話の文脈を覚えておくための「作業机の広さ」。
3. 同時接続数： 同時に何人の会話ができるか。

これを**「トークン・プール」という大きな池にまとめ、利用者は「1 秒間に 100 文字」「作業机 2GB」といった「権利（エンタイトルメント）」**を購入します。

【例え話：高級ホテルのスイートルーム】

• 従来のルール： 「1 泊 3 回までチェックイン可能」。
• 新しいルール（Token Pools）： 「あなたは、**『作業スペース 2 平米』と『1 秒間に 100 文字の執筆速度』**という権利を持っています」。

もし、あなたが「作業スペース 2 平米」の権利を持っていても、今ホテルの部屋が満室なら、「今すぐは使えません」と断られます。でも、もし誰かが部屋を空けたら、すぐにその権利を使って入れます。
重要なのは、「重いリクエスト（バス）」が来ても、その分だけ「作業スペース」を消費するので、軽いリクエスト（タクシー）が来ても、スペースが余っていれば入店できるという点です。

🛡️ 優先順位と「借金（Debt）」の仕組み

このシステムには、**「誰を優先するか」**という賢いルールも組み込まれています。

1. サービスクラス（ランク）：

   • VIP（保証付き）： 絶対に遅くならない、優先的に部屋を確保される。
   • 一般（弾力的）： 空いていれば使えるが、混雑時は我慢してもらう。
   • スポット（最安）： 空きがあれば使えるが、誰かが来たらすぐに追い出される。

2. 「借金（Debt）」の仕組み：
   これが最も面白い部分です。
   もし、混雑のせいで「一般」のお客様が部屋に入れず、サービスが滞ったとします。システムは**「あなたはサービス不足（借金）を抱えています」と記録します。
   混雑が少し落ち着いたら、「借金を返すために、次はあなたを優先して部屋に入れます」**という仕組みです。

【例え話：カフェの順番待ち】

• VIP： 常に最前列。
• 一般： 混雑時は後ろに並ぶ。でも、**「今日は 30 分も待たされたね（借金）」**と記録される。
• 次の混雑時： 「昨日は 30 分待たされたから、今日は VIP の次に優先して案内します！」
• これにより、**「誰かがずっと我慢させられる」**という不公平を防ぎます。

🚀 実験結果：何が起きた？

研究者たちは、このシステムを実際の AI サーバーでテストしました。

• 実験 1（混雑時の保護）：
  大量の「スポット（安価）」なリクエストが殺到してサーバーがパンクしそうになった時、「VIP（保証付き）」のユーザーは全く遅くならず、快適に使い続けられました。
  一方、従来のルール（レート制限）だと、VIP も一般も全員が 19 秒以上待たされる大惨事になりました。

  • 結果： 新しいルールなら、VIP は 1.2 秒以内で返事が返ってきます。

• 実験 2（公平な分配）：
  容量が半分になった時、**「すぐに返事が欲しい開発者」と「多少待ってもいいデータ分析」**が争いました。
  システムは、開発者を優先しつつ、データ分析の方も「待たされすぎた（借金）」と判断したら、徐々に優先度を上げて公平に配分しました。

🌟 まとめ

この論文が言いたいことはシンプルです。

「AI の混雑を管理するには、単に『人数』を制限するのではなく、『作業の重さ』と『利用者の重要度』を考慮した、賢い通貨システムが必要だ」

• 従来のルール： 「1 分間に 3 回まで！」（重さを無視）
• 新しいルール： 「あなたの権利は『作業机 2 平米』。混雑時は優先順位と『過去の我慢（借金）』で配分します！」

これにより、企業は AI を使っても「誰かが遅くなる」というトラブルを防ぎつつ、サーバーを無駄に空けずに最大限の効率で動かすことができるようになります。まるで、**「賢いホテルのコンシェルジュ」**が、客の要望と部屋の空き状況を瞬時に判断して、最高の配分をしているようなものです。

技術概要

論文要約：マルチテナント AI 推論プラットフォームにおけるトークン管理

タイトル: Token Management in Multi-Tenant AI Inference Platforms
著者: William J. Cunningham (DataRobot)
会議: CAIS '26 (2026 年 5 月)

1. 背景と問題定義

大規模言語モデル（LLM）の企業利用が拡大する中、その推論インフラの管理には重大な課題が存在します。特に、マルチテナント環境（複数の顧客がリソースを共有する環境）において、以下の問題が顕在化しています。

• リソース消費の不均一性: 従来の CPU 中心のマイクロサービスやバッチ処理向けスケジューリングは、Transformer モデルの特性（キー・バリュー（KV）キャッシュの巨大なメモリ消費、推論時間のばらつき、コンテキスト長によるリソース需要の急変）を捉えきれていません。
• 既存アプローチの限界:
  • 専用エンドポイント: 各テナントやモデルに GPU を割り当てる方式は隔離性が高いですが、アイドル時のリソースの遊休（ストランド）を招き、効率が低下します。
  • レートリミット: 従来の「リクエスト数/分」や「トークン数/分」の制限は、推論のコスト（GPU 時間や KV キャッシュ消費量）を考慮していません。長いコンテキストや複雑な推論を行うリクエストは、短いリクエストに比べてはるかに多くのリソースを消費するため、単純なレート制限では公平なリソース配分ができません。
• 結果: これらの手法では、リソース不足時の「ワークコンサーベーション（アイドル容量の借用）」が不可能であり、バースト時のレイテンシ劣化が全テナントに波及してしまいます。

2. 提案手法：トークンプール（Token Pools）

著者は、推論ネイティブな単位でリソースを表現し、制御平面（Control Plane）で管理する新しい抽象化概念**「トークンプール」**を提案しました。

2.1 資源モデルの定義

トークンプールは、GPU ワーカーの自動スケーリンググループを、以下の 3 つの「スケジューリング可能なリソース」として表現します。

1. トークンスループット（$\lambda$）: 秒間生成トークン数。GPU 時間の消費を直接制限します。
2. KV キャッシュ容量（$\chi$）: アテンション状態を保持するためのメモリ容量（バイト）。長いコンテキストを持つモデルではこれがボトルネックとなります。
3. 並行性（$r$）: 同時に実行されている推論シーケンスの数（アクティブなデコードスロット数）。

2.2 エンタイトルメントとサービスクラス

テナントはプール容量の一部に対する「エンタイトルメント（権利）」を取得します。このエンタイトルメントに基づき、以下のサービスクラスが定義され、リソース競合時の保護順序が決定されます。

• Dedicated/Guaranteed: 予約されたベースライン容量が保証され、縮小されません。
• Elastic: 時間平均でベースラインが保証されますが、容量不足時は縮小され、後で補償（債務メカニズムによる優先度上昇）を受けます。
• Spot/Preemptible: ベースライン保証なし。容量不足時に最初にスロットリングまたは終了されます。

2.3 優先度と債務メカニズム（Debt Mechanism）

リクエストの承認（Admission Control）は、単なる閾値チェックではなく、動的な優先度スコアに基づいて行われます。優先度 $w_e$ は以下の要素で計算されます：
$$w_e = w_{\kappa} \cdot f(\text{SLO}) \cdot f(\text{Burst}) \cdot f(\text{Debt})$$

• サービスクラス（$w_{\kappa}$）: 基本の重み付け（Dedicated が最も高い）。
• SLO 緊急性: より厳しいレイテンシ目標を持つテナントに高い優先度。
• バースト履歴: 過度なリソース消費に対するペナルティ。
• 債務（Debt）: これが核心的な革新です。 テナントがベースラインより少ないリソースしか受けられなかった場合、「債務」が蓄積します。この債務は優先度を上げる係数として機能し、リソースが回復した際に「公平なシェア（Fair-Share）」へ収束させるフィードバックループを形成します。

2.4 システムアーキテクチャ

• Kubernetes 統合: 既存の推論ランタイム（vLLM など）やクラスタースケジューラを変更せず、その上に制御平面レイヤーを構築します。
• バーチャルノード: 物理 GPU の代わりに、トークンプールの容量（トークン数、KV キャッシュ量）を表現する「バーチャルノード」を作成し、Kubernetes のスケジューラーをリソース承認メカニズムとして再利用します。
• 承認制御（Admission Control）: API ゲートウェイ（LiteLLM など）でリクエストをインターセプトし、エンタイトルメントの状態、バースト、債務、現在のプール混雑度を評価して、リクエストの承認または拒否（429 エラー）を即座に行います。

3. 評価結果

Kubernetes クラスター（vLLM バックエンド）上で 2 つの実験を行いました。

実験 1: クラス間保護（Cross-Class Protection）

• シナリオ: 保証されたワークロード（Guaranteed）とスポットワークロード（Spot）が混在し、過負荷状態（需要が供給の 138%）に陥った場合。
• 結果:
  • トークンプールあり: 保証されたワークロードの P99 レイテンシは1.2 秒未満で維持されました。スポットリクエストは即座に拒否（429）され、キューが蓄積しませんでした。
  • ベースライン（承認制御なし）: 全ワークロードのレイテンシが19 秒以上に劣化し、キューが 34 リクエストまで膨れ上がりました。
  • 意義: 低優先度のトラフィックを適切に遮断することで、高優先度ワークロードを保護しつつ、プール全体のリソース利用率を最大化できることが示されました。

実験 2: SLO 意識の公平シェア（SLO-Aware Fair Share）

• シナリオ: 容量が半分になった障害発生時、異なる SLO 要件を持つ 2 つの Elastic ワークロード（低遅延のコーディングアシスタント vs 遅延許容のバッチ処理）が競合する場合。
• 結果:
  • 低遅延要件（500ms SLO）を持つワークロードは、高優先度でリソースを確保されました。
  • 遅延許容（30s SLO）のワークロードはスロットリングされましたが、債務メカニズムにより、時間経過とともに優先度が上昇し、飢餓（Starvation）を防ぎながら徐々にリソースを回復しました。
  • 障害復旧後、債務が指数関数的に減衰し、優先度が SLO ベースの基準に戻りました。
  • 意義: 静的なレート制限では不可能な、動的な容量変動に対する適応と、時間軸での公平なリソース配分が実現できました。

4. 主要な貢献

1. 推論ネイティブなリソース抽象化の形式化: スループット、KV キャッシュ、並行性の 3 次元で容量を定義し、優先度と債務を組み合わせたメカニズムを提案しました。
2. Kubernetes ネイティブなアーキテクチャ: 既存の推論エンジンを変更せず、バーチャルノードとカスタムリソース（CR）を用いて、Kubernetes スケジューラーをトークン容量の承認制御として再利用する設計を実証しました。
3. 実証データ: 過負荷時の P99 レイテンシの安定化（1.2 秒 vs 19 秒）と、異種 SLO を持つワークロード間の公平なシェア収束を実験的に証明しました。

5. 意義と結論

この論文は、マルチテナント AI 推論プラットフォームにおける「リソース効率」と「サービスレベル保証（SLA）」の間の根本的な緊張関係を解決する道筋を示しています。

• ゲートウェイでの承認制御: 推論実行前にリソースのコミットメントを決定することで、リソース枯渇時の graceful degradation（優雅な劣化）を実現しています。
• 債務ベースの公平性: 単なる静的な割り当てではなく、過去のサービス不足を記憶し、将来の優先度を調整するメカニズムにより、動的な環境下でも公平性を維持します。
• 実用性: 既存の成熟したバックエンド（vLLM, TensorRT-LLM など）を置き換えることなく、制御平面レイヤーとして導入可能であるため、実運用での採用障壁が低いです。

結論として、トークンプールは、スケーリングと多様化するワークロード要件に対応する、原理的な容量管理の基盤を提供します。