LiteLLM: 100以上のLLMのためのオープンソースAIゲートウェイ

多くのLLMプロバイダーのための単一インターフェース

LiteLLMは、OpenAI、Anthropic、Gemini、Bedrock、Azureなど、100以上のLLMプロバイダーを呼び出すための単一の統一インターフェースを提供するオープンソースのAIゲートウェイです。READMEは、異なるSDK、認証パターン、リクエスト形式、エラータイプの摩擦を取り除くことを目的としています。リクエストはOpenAI形式で行われるため、その形式に基づいて書かれたコードは、書き直すことなく他のプロバイダーを指すことができます。このプロジェクトは、直接統合するためのPython SDKとして、またはチームや組織の集中サービスとして機能するプロキシサーバーとして使用できます。

LiteLLMでは、Python SDKのcompletion呼び出しと、4000番ポートのProxy Serverを別々に確認します。モデル名の接頭辞、仮想キー、プロバイダーAPIキー、/chat/completionsの応答を一つの検証記録に残すと、SDK採用とゲートウェイ採用の差が見えます。 この境界を押さえると、READMEの機能一覧を導入判断へ結び付けやすくなります。

2つのモード：SDKとゲートウェイ

READMEは、LiteLLM Python SDKとLiteLLM AIゲートウェイを比較しています。SDKは、コードから複数のモデルを呼び出したいLLMプロジェクトを構築する開発者向けです。SDKには、デプロイメント間の再試行とフォールバックロジックを備えたルーター、アプリケーションレベルの負荷分散、コスト追跡、OpenAI互換の例外処理が含まれています。ゲートウェイは、認証、仮想キー、マルチテナントのコスト追跡、ロギングとガードレールのプロジェクトごとのカスタマイズ、管理ダッシュボードを備えた集中サービスを必要とするGen AIイネーブルメントおよびMLプラットフォームチームを対象としています。両方とも同じ統一インターフェースを共有しており、ロジックをコードに埋め込むか、別のサービスとして実行するかによって選択が異なります。

プロバイダーとエンドポイントのカバレッジ

READMEには、サポートされているプロバイダーの大きな表がリストされており、各プロバイダーには/chat/completions、/messages、/responses、/embeddings、/image/generations、/audio/transcriptions、/audio/speech、/moderations、/batches、/rerankなどのエンドポイントのチェックマークがあります。表はOpenAI、AnthropicからBedrock、Vertex AI、Azure、vLLM、Nvidia NIM、および多くの小規模サービスまでをカバーしています。完全なリストとサポートされているエンドポイントは、プロジェクトのウェブサイトとドキュメントに記録されています。READMEはまた、不足しているプロバイダーは機能リクエストのissueで要求できると述べています。

本番環境向けゲートウェイ機能

ゲートウェイは本番環境対応と説明されており、安全なアクセス制御のための仮想キー、プロジェクトおよびユーザーごとの支出追跡とコスト管理、ガードレール、負荷分散、管理ダッシュボードUIを備えています。READMEは、キャッシュ、ロギング、プロジェクトごとのカスタマイズにも言及しています。プロキシサーバーは依存関係のためにdocker-composeセットアップを使用して開発者モードで実行でき、安定版リリースイメージには-stableタグが付けられ、公開前に12時間の負荷テストを受けていると述べています。READMEの正確なパフォーマンスの主張は、ベンチマークページにリンクされた1k RPSでの8ms P95レイテンシを引用しています。

チャットを超えて：A2AエージェントとMCPツール

2つの機能領域が、ゲートウェイを単純なチャット補完の範囲を超えて拡張します。1つ目はA2A（エージェント間）プロトコルサポートで、LangGraph、Vertex AI Agent Engine、Azure AI Foundry、Bedrock AgentCore、Pydantic AIのエージェントを追加し、A2A SDKを使用してゲートウェイ経由で呼び出すことができます。2つ目はMCP（モデルコンテキストプロトコル）ツールです。Python SDKはMCPツールをOpenAI形式でロードでき、ゲートウェイはMCPサーバーを/chat/completionsを介して呼び出し可能なツールとして公開できます。READMEは、GitHub MCPサーバーを接続し、リクエスト内のツール定義で呼び出す例を示しています。

AWSおよびGCP向けTerraformデプロイ

ゲートウェイをコンポーネント化されたスタックとして実行したいチーム向けに、リポジトリは公開TerraformレジストリでAWSとGCPの両方のTerraformモジュールを公開しています。AWSモジュールはECS FargateとAurora、ElastiCache、ALBを使用します。GCPモジュールはCloud RunとCloud SQL、Memorystore、HTTPSロードバランサーを使用します。両方のモジュールには、マネージドPostgres（ライターとリーダー）、Redis、バージョン管理されたオブジェクトストア、クラウドシークレットマネージャーで自動生成されたマスターキー、プロキシ起動前にprisma migrate deployを実行する1回限りのマイグレーションジョブが含まれています。READMEはサンプル構成を提供し、プロバイダーAPIキーはSecrets ManagerまたはSecret Managerに保存され、gateway_extra_secretsを介して参照されることを述べています。

イメージ署名とライセンス

GHCRに公開されたすべてのDockerイメージはcosignで署名されており、READMEは署名キーに固定されたコミットハッシュを使用する方法とリリースタグを使用する方法の2つの検証方法を説明しています。ライセンスの抜粋は、enterprise/ディレクトリの外のコンテンツがMITライセンスの下にある一方で、enterpriseディレクトリ（存在する場合）はenterprise/LICENSEで定義された別のライセンスの下にあることを示しています。MITテキストは、使用、コピー、変更、マージ、公開、配布、サブライセンス、販売の権利を無保証で許可します。READMEはまた、商用ライセンスの下の機能、機能優先順位付け、カスタム統合、プロフェッショナルサポート、カスタムSLA、シングルサインオンを含むエンタープライズ層に言及していますが、詳細は別のページにあります。

編集部の結論

LiteLLMの2つのデプロイオプション（Python SDKと自己ホスト型プロキシ）により、チームはOpenAI形式を標準にしながら、プロバイダー固有の違いを単一のインターフェースの背後に隠すことができます。READMEはサポートされているエンドポイント、ゲートウェイ機能、クラウドデプロイパスを文書化していますが、引用されたベンチマーク以外のセキュリティ保証やパフォーマンスの詳細は提供していません。 LiteLLMでは、Python SDKのcompletion呼び出しと、4000番ポートのProxy Serverを別々に確認します。モデル名の接頭辞、仮想キー、プロバイダーAPIキー、/chat/completionsの応答を一つの検証記録に残すと、SDK採用とゲートウェイ採用の差が見えます。 導入対象はこの確認結果で決めます。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes