LiteLLM vs Bifrost：本番環境で両方をテストしてみた
2週間にわたり、LiteLLMとBifrostを並行して稼働させました。
使用したトラフィック、モデル、インフラはすべて同じ条件です。チームのためにどちらか一つのゲートウェイを選ぶ必要がありました。マーケティングの謳い文句ではなく、実際のデータが欲しかったのです。
以下に、その検証結果をまとめます。
テスト環境
4 vCPU、8GB RAMのc5.xlargeインスタンスを使用しました。小さなテスト用インスタンスではなく、当社のエージェントプラットフォームからの実際のユーザーリクエスト（毎秒200〜400リクエスト）を使用しました。
プロバイダーの対応範囲
- LiteLLMは100以上のプロバイダーをサポートしています。
- Bifrostは約23のプロバイダーをサポートしています。
LiteLLMは、シンプルな設定でOpenAI、Anthropic、Bedrock、Vertex、Groq、Deepseekを扱えます。Bifrostは、当社が必要としていたプロバイダーの一部が不足していました。これが決定的な判断材料となりました。
パフォーマンス
BifrostはGoを使用しているため、ゲートウェイ自体のオーバーヘッドは高速です。測定したところ、オーバーヘッドは約0.08msでした。一方、LiteLLMのPythonプロキシは、1リクエストあたり約7msから8msの遅延が加わりました。
しかし、LLMの呼び出しには500msから30秒かかります。モデルのレスポンスタイムと比較すれば、7msの遅延はほとんど無視できるレベルです。
また、LiteLLMはRustベースのゲートウェイをリリースしたばかりです。これにより、オーバーヘッドは0.05msまで抑えられます。これでパフォーマンスの差は解消されます。
コスト追跡
ここがLiteLLMの勝ち筋です。LiteLLMは、すべてのAPIキーおよびすべてのチームにわたって、コストを自動的に追跡します。
- キーごとの予算設定が可能です。
- チームごとの予算設定が可能です。
- 日次のコストレポートを取得できます。
Bifrostにも予算制限はありますが、LiteLLMは詳細なコスト配分（attribution）を提供します。月に1,000万件の呼び出しを行うようになると、CTOから「各チームが各モデルにいくら使ったのか」と正確に問われることになります。LiteLLMなら、その問いに即座に答えられます。
ルーティング戦略
LiteLLMは5つのルーティング戦略を提供しています：
- シンプルなシャッフル (Simple shuffle)
- 最小負荷 (Least busy)
- レイテンシベース (Latency-based)
- コストベース (Cost-based)
- 使用量ベース (Usage-based)
Bifrostには重み付けルーティングや適応型ルーティングがありますが、コストベースのルーティングがありません。LiteLLMは、リクエストに対して最も安価なモデルを自動的に選択できます。
結論
私はLiteLLMを選びました。
主な理由は、プロバイダーのリストとコスト追跡機能です。Bifrostは、OpenAIやAnthropicのみを使用する小規模なチームにとっては優れたエンジニアリング製品です。しかし、規模の拡大と多様性を考慮すると、LiteLLMの方が実用的です。
Optional learning community: https://t.me/GyaanSetuAi