複数のLLM（大規模言語モデル）プロバイダーを1つのAPI窓口にまとめる「AIゲートウェイ」を運用しているインフラ担当者に向けた内容です。LiteLLMはPythonベースのオープンソースAIゲートウェイとして広く使われていますが、本番トラフィックが増えた際に想定外の遅延やエラー率上昇に直面するケースがあります。今回はLiteLLMとGo言語製ゲートウェイBifrostの実測比較データをもとに、乗り換えを検討すべき条件を整理しました。
AIゲートウェイとは、アプリケーションとOpenAIやAnthropicなどのLLM APIの間に挟むプロキシ層です。プロバイダー切り替え、レート制限、フォールバック（障害時の代替プロバイダーへの自動切替）などを一元管理する役割を持ちます。SREの視点では、ここがボトルネックになると全社のLLM機能が同時に詰まるため、可用性設計上は無視できないコンポーネントです。
どんな場面で選定が必要になるか
PoC（概念実証）段階でLiteLLMを導入し、そのまま本番トラフィックを流し始めたタイミングで問題が顕在化します。
具体的には、リクエスト数が増えるにつれてp99レイテンシ（全リクエストの99%がこの時間以内に収まるという指標）が急激に悪化する、あるいはエラー率が上がるといった症状です。
この段階で「設定ミスなのか、ゲートウェイ自体の限界なのか」を切り分けられないまま放置すると、障害対応のたびに原因がゲートウェイに戻ってきます。SLO（サービスレベル目標）にレイテンシやエラー率の項目を含めている場合、ゲートウェイの挙動はSLO達成可否を左右する重要な変数になります。
判断軸
軸1: テール レイテンシへの耐性
平均レイテンシではなく、負荷が高まったときのp99・p999がどう振る舞うかを見る軸です。
実測データでは、100 RPS（秒間リクエスト数）でのp50はBifrostが1.01ms、LiteLLM（ワーカー4つ構成）が5.84msでした。差は5.8倍です。
さらに1,000 RPSまで負荷を上げると、LiteLLMは成功率94.9%まで低下し、p99は33,766ms（約34秒）に達しました。一方Bifrostは1,000 RPSでも成功率100%、p99は2.62msを維持しています。バースト的なトラフィックが想定されるサービスでは、この差がインシデント発生確率に直結します。
軸2: プロセスモデルとリソース消費
LiteLLMはPython製で、デフォルトでは--num_workersが設定されておらず、CLIのデフォルト値は1です。
これはつまり、4コアCPUを積んだサーバーでもPythonプロセス1つしか使われないということです。実際に--num_workers 4を指定してコア数に合わせたところ、500 RPSでの成功率は89.1%から100%に、p50は20,446msから13.29msに改善しました。フラグ1つで3桁の改善幅です。
LiteLLMを本番稼働させている場合、まず--num_workersが設定されているか、コンテナ内にmultiprocessingのfork子プロセスが実際に存在するかを確認してください。これを見落としたまま比較すると、ゲートウェイ自体の性能差だと誤認してしまいます。
メモリ消費も無視できない差があります。起動後15分間docker statsを1分おきに観測した結果、Bifrostは約60MiBで安定したのに対し、LiteLLM（ワーカー4構成）は2.08GiBでした。Pythonの各ワーカーが独立したプロセスとしてメモリを持つ構造のため、レプリカを多数並べる構成ではコストに直結します。
軸3: セキュリティのデフォルト設定
SSRF（サーバーサイドリクエストフォージェリ、外部から内部ネットワークへの不正アクセスを誘発する攻撃）への防御がデフォルトで有効かどうかも比較軸です。
Bifrostは設定済みプロバイダーURLに対するSSRFガードがデフォルトで有効になっています。一方LiteLLMでは、設定したapi_baseに対してこの防御が適用されていません。加えて、公開コンテナイメージの実行ユーザーもBifrostがUID 1000（非rootユーザー）であるのに対し、LiteLLMはrootで動作します。コンテナがroot権限で動くこと自体は即座に脆弱性を意味しませんが、多層防御の観点では非rootが望ましい設計です。
軸4: ライセンスと拡張性
BifrostのリポジトリはApache-2.0ライセンスです。LiteLLMはMITライセンスですが、enterprise/ディレクトリ以下は対象外という条件付きです。
法務レビューを通す際、どの範囲が本当にオープンソースなのかを明確にしておく必要があります。またLiteLLMはPythonで書かれているため、Pythonでカスタムロジックを拡張したいチームには扱いやすい側面もあります。この点は性能差とトレードオフになる判断材料です。
選択肢の比較
| 項目 | Bifrost | LiteLLM（ワーカー4構成） |
|---|---|---|
| p50 (100 RPS) | 1.01 ms | 5.84 ms |
| 成功率 (1,000 RPS) | 100% | 94.9% |
| p99 (1,000 RPS) | 2.62 ms | 33,766 ms |
| 起動時メモリ | 約60 MiB | 2.08 GiB |
| コンテナ実行ユーザー | UID 1000 | root |
--num_workers未設定のまま本番投入されているケースで性能差が最も大きく開きます。乗り換え判断の前に、まずこの設定を確認する価値があります。ケース別の推奨
- バースト的な高トラフィックが想定される、あるいはSLOにp99レイテンシの厳格な目標がある場合はBifrostを選ぶ判断が合理的です
- 多数の小さいレプリカをKubernetesなどで水平展開する構成で、メモリコストを抑えたい場合もBifrostが有利です
- コンテナのセキュリティベースライン（非root実行、SSRFガード）を社内基準として必須にしているチームもBifrostの初期設定が合います
- チームがPythonでゲートウェイのロジックを頻繁に拡張しており、その資産を捨てたくない場合はLiteLLMに残る選択肢が現実的です
- トラフィックが常時低く、システム全体のボトルネックが別の箇所（プロバイダー側のレイテンシなど）にある場合もLiteLLMのままで問題が出にくいです
あえて見送るべき条件
すでにLiteLLMを本番で使っていて、--num_workersをコア数に合わせて設定済みなのに大きな問題が出ていないなら、乗り換えの緊急性は低いです。
また、リクエスト量がベンチマークで差が出た500〜1,000 RPS帯に遠く及ばない小規模システムでは、テールレイテンシの差はほぼ体感されません。移行にはコード変更、設定の作り直し、フォールバック挙動の再検証といったコストがかかるため、現状の負荷プロファイルをまずdocker statsやAPMツールで確認し、実際にボトルネックがゲートウェイにあるかを切り分けてから判断すべきです。
性能ベンチマークは共有CPUのVPS上で測定されたものであり、専有インスタンスでの絶対値とは異なる点にも注意してください。相対的な傾向（Bifrostが高負荷帯で優位）は参考にできますが、自社の本番環境で同条件の負荷テストを再現することをおすすめします。
まとめ
AIゲートウェイの選定は、機能一覧の比較よりも「障害が起きたときに何が起こるか」で判断するのが実務的です。
今回の実測では、LiteLLMのワーカー未設定という一点だけで成功率とレイテンシが3桁改善しました。乗り換えを検討する前に、まず--num_workersの設定値とコンテナ内のプロセス数を確認してください。
そのうえで、SLOに厳しいレイテンシ目標がある、水平スケールでメモリコストが問題になっている、コンテナのセキュリティ基準を強化したいといった条件に当てはまるなら、Bifrostへの移行検討が理にかなっています。逆にPython拡張への依存が強く、現状の負荷でSLOを満たせているなら、無理に切り替える理由はありません。