LLMロードバランサー（エルエルエムロードバランサー）

LLMロードバランサーとは

LLMロードバランサーは、複数のLLM推論サーバーにリクエストを分散する負荷分散機構である。従来のWebサーバー向けロードバランサー（NGINX、HAProxy等）はHTTPリクエストの均等分散を目的とするが、LLMロードバランサーはLLM推論特有の制約を考慮した高度なルーティングが必要である。

LLM推論リクエストは1リクエストあたりの処理時間が数秒〜数十秒と長く、GPU メモリ消費量もリクエストごとに大きく異なる（入力トークン数に比例してKVキャッシュが増大）。単純なラウンドロビンでは一部のサーバーにGPUメモリ過負荷が集中する問題が発生する。

LLM固有のルーティング戦略

Token-Awareルーティング: リクエストの入力トークン数を推定し、処理負荷が均等になるようにサーバーに分散する。長文入力（10K〜100Kトークン）と短文入力（100〜500トークン）を同一サーバーに混在させることで、GPU利用率を平準化する。

Queue-Basedルーティング: 各サーバーの推論キュー長（処理待ちリクエスト数）を監視し、最もキューが短いサーバーにルーティングする。Least-Connections戦略のLLM版。

Prefix-Cachingルーティング: 同一のシステムプロンプトを使用するリクエストを同じサーバーにルーティングし、KVキャッシュのプレフィックスキャッシュヒット率を最大化する。SGLangのRadixAttentionと組み合わせることで、TTFTを50〜80%削減できる。

主要ツール・プラットフォーム

LiteLLM: 100以上のLLMプロバイダ（OpenAI, Anthropic, Azure, AWS Bedrock等）を統一APIで抽象化するプロキシ。ロードバランシング、フォールバック、レート制限、コスト追跡を統合。OpenAI互換APIを提供し、既存アプリケーションのコード変更なしで複数プロバイダ間の負荷分散が可能。

RouteLLM: UC Berkeley開発のLLMルーティングフレームワーク。リクエストの難易度を分類し、簡単なリクエストは安価なモデル（GPT-4o-mini等）、複雑なリクエストは高品質なモデル（GPT-4o等）に自動ルーティング。コストを50%以上削減しつつ品質を95%維持できるとされる。

OpenRouter: 複数のLLMプロバイダを統合したAPIゲートウェイ。プロバイダ間の自動フォールバック、最安値ルーティング、レート制限管理を提供。開発者は単一のAPIキーで数十のモデルにアクセスできる。

スケーリングパターン

水平スケーリング: 同一モデルのレプリカを複数GPUに配置し、ロードバランサーでリクエストを分散。Kubernetes上でHPA（Horizontal Pod Autoscaler）を使用し、GPU使用率やキュー長に基づいてレプリカ数を自動調整する。

垂直スケーリング: テンソル並列やパイプライン並列で1つのモデルを複数GPUに分散配置。大型モデル（70B以上）で必要だが、GPU間通信がボトルネックになるため、NVLink/InfiniBand接続のGPUクラスタが推奨。

よくある質問

Q1: NGINXやHAProxyをLLMロードバランサーとして使えますか？

基本的なラウンドロビン分散は可能だが、LLM固有の最適化（Token-Aware、GPU-Memory-Aware等）は実現できない。NGINX/HAProxyをフロントエンドに配置し、バックエンドにLiteLLM等のLLM対応ロードバランサーを置く2層構成が一般的。

Q2: マルチモデルのロードバランシングはどう実装しますか？

LiteLLMのfallback機能で「プライマリ: GPT-4o → セカンダリ: Claude 3.5 Sonnet → フォールバック: Llama 3.1 70B（ローカル）」のようなカスケード構成が可能。レート制限に達したプロバイダを自動的にスキップし、次のプロバイダにルーティングする。

Q3: オートスケーリングの閾値はどう設定すべきですか？

GPU使用率80%をスケールアウト閾値、30%をスケールイン閾値とするのが一般的な起点。ただしLLMサービングではGPUメモリ使用率の方が重要で、KVキャッシュがGPUメモリの85%を超えるとOOMリスクが高まる。vLLMの--gpu-memory-utilizationパラメータ（デフォルト0.9）をモニタリング指標に含めることを推奨する。