LiteLLM は、複数のモデルプロバイダーの前段に 1 つのエンドポイントを提示する、大規模言語モデル向けの API プロキシである。この wiki が記録している内容は、プロジェクト自身のドキュメントではなく、単一の導入事例の報告に基づいている。Zalando の ML プラットフォームチームは、エンジニアがすでに利用していた IDE の自動補完に加えて API 経由でモデルにアクセスできるよう、2024 年 1 月に LiteLLM ベースのプロキシを導入し、その結果を Zalando におけるエージェント型エンジニアリング：現状のスナップショット で説明している。
この導入事例では、プロキシは OpenAI、AWS Bedrock、Google Vertex のモデルの前段に置かれている。そこに置いた理由として挙げられているのは 2 つある。エンジニアがさまざまなツールやモデルを容易に試せるようになったこと、そしてプラットフォームチームが利用状況を測定する単一の地点（月間・週間アクティブユーザー数、モデル別、User-Agent 別）を得たことである。
機能
ソースが特に取り上げている機能は、フックによる拡張性である。Zalando は、匿名化したコスト追跡に呼び出し後フックを、クライアントのバージョンアップを強制するために呼び出し前フックを使っていると報告しており、後者では User-Agent ヘッダーに基づいてプロキシへのアクセスを制限している。また、プロンプトキャッシュのチェックポイントの自動挿入を有効にしたとも報告しており、これによって、作成者がまだプロンプトキャッシュについて学んでいる途中だったカスタムエージェントのコストが削減されたという。
同じ導入事例からは、運用面の詳細が 2 つ報告されている。安定性とメモリリークの問題を緩和するため、同チームは --max_requests_before_restart 設定を使って 20,000 リクエストごとに再起動を強制しており、これにより、それぞれ 2 CPU コアと 4 GB メモリを備えた 6 つの Pod で 2,000 人の月間アクティブユーザーに対応できているとしている。記事はまた、パフォーマンスと安定性の向上が見込まれる Rust による書き直しに期待していると述べている。これは 2026 年 8 月時点で記録された期待であり、リリース済みの状態ではない。
採用とエコシステム
この事例が示すパターンは、組織のモデルアクセスポリシーを強制する地点として使われる、セルフホスト型のゲートウェイである。すべてのリクエストがそこを通過するため、プロキシは利用状況が測定され、コストが割り当てられ、クライアントのバージョンが強制的に引き上げられ、廃止されたモデルへのアクセスが断たれる場所となる。記事は、自己管理型のクライアントインストールについては、ローカルの設定を更新しないユーザーが常に一定数残り続けるため、アクセスをブロックすることが唯一の有効な手段だと指摘している。
同じ報告は、こうしたプロキシの前段に位置する LLM 対応ツールに繰り返し見られる 2 つの問題を挙げているが、いずれも LiteLLM に固有のものではない。ツールが汎用的な User-Agent ヘッダーを送ることがあまりに多く、クライアントを識別しにくいこと、そしてカスタムの認証コマンドをサポートしておらず、静的な認証情報をデフォルトとするため、その有効期限が切れると手動での更新とアプリケーションの再起動が必要になることである。