LLM パフォーマンス最適化のための効率的なリクエストキューイング
問題: パワーユーザーによるリソースブロック
標準的な推論エンジン（vLLM や HuggingFace TGI など）では、リクエストは通常、ワーカー、キュー、スケジューラによって処理されます。GPU 計算はバッチで実行した方が効率的であるため、バックエンドキューはスケジューラが複数のリクエストを単一のバッチにまとめることを可能にします。
しかし、"パワーユーザー" が大量のリクエストを送信すると、バックエンドキューが埋まってしまいます。これにより、他のユーザーからの後続リクエストは、パワーユーザーのリクエストがすべて処理されるまで待たなければならず、新しいリクエストの緊急性や量に関係なくブロックされるという効果が生じます。
解決策: フェアスケジューリングの実装
リソースブロックを防ぐために、TNG はユーザーと推論バックエンドの間に位置する「LLM-Server」（API サーバ）を実装しています。リクエストをバックエンドに直接送る代わりに、LLM-Server はユーザーごと、モデルごとに別々のキューを管理します。
ラウンドロビン・スケジューリング
LLM-Server は、先入れ先出し（FIFO）方式ではなくラウンドロビン・スケジューラを採用しています。これにより、異なるユーザーからのリクエストが公平に優先され、あるユーザーが単一のリクエストだけを持っている場合でも、別のユーザーが特定のキューで複数のリクエストを保留していても、より速く処理されます。
スケジューリングの拡張可能性
単純なリクエスト数だけでなく、スケジューリングは以下のような複数の指標に基づいてさらに細かく調整できます：
- Processing Time: 短いリクエストを優先して全体の待ち時間を短縮する。ただし、生成長さの推定は困難です。
- Cache Optimization: リクエストを類似性で整理し、KV キャッシュヒットを最大化する。これは NVIDIA Dynamo や AIBrix などのフレームワークで使用される手法です。
- Business Cost: 操作の金銭的コストに基づいてリクエストを優先する。
- Priority Tiers: 用途別に異なるキューを設定する。例えば、インタラクティブなチャットインターフェースは応答性の高い UI を維持するために高優先度とし、コードレビューやベンチマーク用のバッチ API ジョブは低優先度とする。
バックエンドのバックプレッシャー管理
LLM-Server レベルでのフェアスケジューリングは、サーバが優先されたすべてのリクエストを即座にバックエンドへ送信すると、バックエンドの FIFO キューに単に蓄積され、ブロック問題が再現されるため、効果がありません。
メトリックベースのレート調整
一部のバックエンド（vLLM など）はバックエンドキューの最大要素数を制限できないため、LLM-Server はリクエスト転送レートを動的に調整する必要があります。TNG は vLLM の /metrics エンドポイントから Prometheus メトリクスを取得することでこれを実現しています。
backend queue length metric を監視することで、LLM-Server はキュー長が特定の閾値（例: 3）未満のときだけ新しいリクエストを転送します。これにより新規ユーザーのレイテンシを最小化しつつ、低レイテンシと GPU の低利用率というトレードオフをバランスさせます。
高度なメトリックフィードバックループ
このフィードバックループにより、リアルタイムのパフォーマンスに基づくさらなる最適化が可能になります：
- Token Speed Thresholds: time-per-output-token metric が一定の上限（例: 150ms）を超えると、サーバは新しいリクエストのスケジューリングを停止し、最低生成速度（例: 7 トークン/秒以上）を維持できます。
- Priority-Specific Thresholds: 低優先度のバッチリクエストは、バックエンドキューが完全に空の場合にのみスケジュールされ、高優先度ユーザーのレイテンシを増加させないようにします。
代替案: バックエンド側の優先度スケジューリング
vLLM の最近のバージョンでは優先度ベースのスケジューリングが導入され、リクエストに優先度レベルを付与できるようになりました。高優先度リクエストはキューを「ジャンプ」し、処理済みバッチに直接移動でき、低優先度リクエストを待機キューに戻すことさえ可能です。
LLM-Server スケジューリングとの比較
バックエンド側の優先度スケジューリングは一部のロジックを簡素化しますが、上流の LLM-Server が必要とされる理由は以下の通りです：
- Compatibility: バックエンドの優先度機能は
vLLMでは利用可能ですが、HuggingFace TGIでは利用できません。 - Rate Control: バックエンドスケジューリングは、
time-per-output-tokenのようなパフォーマンス指標に基づくリクエスト送信レートを制御しません。 - Priority Assignment: ユーザーの身元やアプリケーションタイプに基づいてリクエストに優先度を割り当てるためには、客観的な上流インスタンスが必要です。
キューイング戦略のまとめ
| 戦略 | 実装場所 | 主な利点 | 制限 |
|---|---|---|---|
| FIFO | バックエンド | 実装が簡単 | パワーユーザーが他者をブロック |
| Fair Scheduling | LLM-Server | ユーザーのブロックを防止 | 上流サーバが必要 |
| Metric-Based Backpressure | LLM-Server | バックエンドのレイテンシを最小化 | メトリックのポーリングが必要 |
| Priority Scheduling | バックエンド (vLLM) | 高優先度リクエストを即時処理 | レート制御なし; vLLM のみ |