LLMゲートウェイのボトルネックは、モデル推論ではなくプロキシ側の処理コストにあります。LiteLLMは2026年6月、スタック全体をRustへ移行する計画を公式ブログで発表しました。既存のconfig.yamlやクライアントAPIを変えずに、ゲートウェイのオーバーヘッドを約150分の1、スループットを約15倍に引き上げる狙いです。
この記事でわかること
- LiteLLMがRust移行を選んだ背景と性能目標
- ベンチマークで示された具体的な数値
- 4段階の移行アーキテクチャと2026年のスケジュール
- 既存環境で変わらない点と変わる点
https://docs.litellm.ai/blog/litellm-rust-launch
なぜ今、Rustなのか
LiteLLMは100以上のLLMプロバイダーをOpenAI互換APIで束ねるオープンソースのAIゲートウェイです。Python製のプロキシは本番運用で実績がありますが、高負荷時にCPUとメモリ消費が増え、PodがOOM（Out of Memory）で落ちる事例が報告されていました。公式ブログでは、負荷テスト時のPythonプロキシのピークメモリが約359MBだったと述べています。
ユーザーからは「最速で最軽量なゲートウェイが欲しい」という声が1年にわたって寄せられてきたとのこと。LiteLLMはこれに応える形で、ゲートウェイのオーバーヘッドを1ms未満、バイナリサイズを100MB未満に抑えることをコミットしました。v2への書き換えではなく、ホットパス（リクエスト処理の中核）のランタイムを段階的にRustへ置き換える方針です。
ベンチマークが示す性能差
公式が公開したベンチマークでは、モック上流・Rust転送ゲートウェイ（axum）・現行のLiteLLM Pythonパス（litellm.acompletion over uvicorn）を同条件で比較しています。
| 指標 | Rustゲートウェイ | LiteLLM（Python） |
|---|---|---|
| リクエストあたりのオーバーヘッド | 約0.05ms | 約7.5ms |
| スループット（50同時接続） | 6,782 req/s | 453 req/s |
| 負荷時のピークメモリ | 31.7MB | 358.9MB |
10同時クライアントではオーバーヘッドが約150分の1、50同時接続ではスループットが約15倍、メモリは約11分の1です。測定対象はゲートウェイの転送パス（リクエスト変換・転送・レスポンス処理）であり、本番ワークロード全体ではありません。ベンチマーク用ハーネスはリポジトリのbenchmark/に公開されており、再現可能です。
ゲートウェイの遅延はモデル推論時間に比べると小さいことが多いです。ただし分類や埋め込み（embeddings）のように大量リクエストを扱うワークロードでは、リクエストごとの数ミリ秒が積み上がります。コーディングエージェントのように1タスクで数十回のモデル呼び出しが発生する場面でも、ゲートウェイの軽量化は体感レイテンシに効きます。
4段階で進める移行設計
LiteLLMは「データ変換だけをRustで行い、I/Oはホストが担う」という分離を軸にしています。Rustコア（litellm-core）はリクエストをプロバイダー形式へ変換し、レスポンスやストリームチャンクを戻します。ソケット接続、シークレット読み込み、DBアクセスは行いません。
| 段階 | 内容 | ホットパスのRust比率 |
|---|---|---|
| Stage 0 | 現行の純Python（SDK + FastAPIプロキシ） | 0% |
| Stage 1 | PyO3経由でRustコアが変換処理を担当 | 変換＋ルーター |
| Stage 2 | FastAPIは薄いシェル、転送はRustエンジン一括 | 転送パスほぼ全体 |
| Stage 3 | axum/hyperの純Rustサーバー、Pythonはサイドカー | 100% |
ルートごとに「1プロバイダーで検証 → 全プロバイダー展開 → Rustコアへ統合」の順で進めます。リスクの小さいOCRから着手し、次に/v1/messages（ストリーミング検証）、その後/chat/completions（最大のパラメータ面）という順序です。各ルートはパリティテストとE2Eテストを通過してから本番投入されます。
Stage 3では認証・レート制限・ルーティング・コスト計算をRustサーバーが担います。カスタムPythonプラグイン（ガードレール、コールバック、SSOなど）はオプションのサイドカーで動き続け、破壊的変更を避けます。
2026年の移行スケジュール
公式タイムラインは次のとおりです。
- 2026年8月15日:
litellm.ocr()と/ocrルート - 2026年9月1日:
/messages、続いて/chat/completions - 2026年9月15日: ルーター（負荷分散、フォールバック、リトライ、クールダウン）
- 2026年12月1日: サーバー本体（FastAPI薄シェル → 純Rust axumサーバー）
移行完了後は単一のRustバイナリをデプロイし、メモリ使用量は約65MB、オーバーヘッドは1ms未満を目標としています。config.yaml、データベーススキーマ、クライアントAPI、100以上のプロバイダー対応は維持されます。Python SDKのインターフェースも同じで、内部がRustバインディングに切り替わるだけです。
既存ユーザーへの影響
設定ファイルやDBスキーマ、リクエスト/レスポンス形式を変える必要はありません。新しいメジャーバージョンへの移行作業も不要です。ルート単位でフラグ制御しながら段階的に切り替えるため、既存のPythonパスはフラグがオフの間そのまま動きます。
早期ベータの参加者募集も開始されています。自社スタックで高速・軽量ゲートウェイを検証したいチーム向けで、開発チームとの直接連絡窓口が用意されています。Rustエンジニアの採用も進めており、100以上のプロバイダーを担うホットパス開発に関わる募集です。
LLMインフラの選択肢が増える中、プロバイダー網の広さとゲートウェイ性能の両立は難しいテーマでした。LiteLLMはRust移行でこのトレードオフの解消を狙っています。移行が計画どおり進めば、自前ホスト型ゲートウェイの性能比較における新たな基準点になる可能性があります。