Lazu と LiteLLM
LiteLLM は最も広く使われているオープンソースの LLM ゲートウェイです。1 つの関数で百のプロバイダーを呼ぶ Python SDK として始まり、プロキシはその周りに育ちました。Lazu は台帳、コンソール、ドキュメントサイトを備えた 1 つの製品として出荷される Go ゲートウェイです。両者は「1 つのエンドポイント、多数のプロバイダー」で重なり、その周りのほぼすべてで分かれます。以下の事実は 2026 年 11 月 2 日に確認しました。
それぞれ誰向けか
LiteLLM は、自社サービスのために共有ゲートウェイを運用するプラットフォームチーム向けです。バージョン管理できる config.yaml、フックできる Python コールバック、キー・チーム・支出を扱う管理 UI が欲しいチームです。SDK はプロキシなしでも使えます。
Lazu は、人とエージェントにキーを配るチーム、研究室、企業向けです。各キーに予算があり、各リクエストに記録があり、キーの持ち主がそれを読めます。運営者はコンソールで上流、価格、ユーザーを管理し、ルーティングの設定ファイルはありません。
並べて見る
| LiteLLM | Lazu | |
|---|---|---|
| ランタイム | Python プロキシ（Rust 経路はオプトインで一部ルートのみ）。pip、Docker、Helm | Go ゲートウェイと worker、React コンソール、Vocs ドキュメント。1 つの Docker Compose スタック |
| 設定 | config.yaml と環境変数。管理 UI | 上流、価格、ユーザー、お知らせはコンソール。環境変数と config.yaml は認証情報のみ |
| アカウント | 仮想キー、内部ユーザー、チーム、組織、顧客 | ユーザー、チームとプロジェクト、メンバー予算、API キー |
| 予算 | キー、チーム、メンバー、ユーザー、顧客ごと、リセット周期あり。max_budget でハードブロック | 前払い残高。キー別上限、プロジェクトと支出予算。呼び出し前に予約、プロバイダーのカウンターで精算、失敗時に解放 |
| 利用記録 | 支出追跡とログ。支出レポート、チーム別ログ、各種エクスポートは Enterprise | リクエストごとに 1 件、利用量・計測元・課金明細付きで、送ったキーが読める。エージェントセッション。照合スクリプト |
| ルーティング | 複数デプロイ間で再試行とフォールバックを行う Router、負荷分散 | モデルごとに優先度と重みでチャネル選択、ヘルスウィンドウ、同一モデルでの再試行。公開の経路ヘルスページ |
| プロトコル | OpenAI、Anthropic /v1/messages、Gemini generateContent を受け、任意のプロバイダーへ変換 | 同じ 3 系統を受ける。無損失のときだけ変換し、それ以外は機能名を示す 400 |
| 拡張 | litellm_settings の Python CustomLogger フックとガードレール | ビルドに組み込む Go と Web の拡張ポイント。コアは拡張の存在を知らない |
| 有料版 | Enterprise ライセンス：5 人超の SSO、監査ログ、RBAC、タグ予算、アラート、支出レポート、ログエクスポート、追加ガードレール | なし。リポジトリにあるものはライセンスキーなしで全部動く |
| ライセンス | MIT、enterprise/ は別ライセンス | AGPL-3.0-or-later |
お金
LiteLLM はスコープ別に支出を追跡し、予算を超えたスコープをブロックします。Lazu はより早く始めてより遅く終わります。上流を呼ぶ前に前払い残高から見積額を予約し、呼んだ後にプロバイダーが報告した利用量で精算し、各次元をプロバイダー計測、ローカル推定、取得不能のいずれかとして記録します。課金対象の出力がない失敗は予約を返金し、アカウントが賄えないリクエストはプロバイダーに届かず、アカウントがこっそり赤字になることはありません。規則は課金契約に書かれており、予約は見積であって上限ではないため、出力制限のないリクエストは予約額より高くつき得る、という但し書きも正直に添えてあります。
十数個の社内サービスに月次リセットの予算が欲しいなら、LiteLLM に今日あります。外注先やエージェントにキーを渡し、後で正確にいくらかかったかを示したいなら、Lazu はそのために作られています。
プロトコル
どちらも OpenAI、Anthropic、Gemini 形式のリクエストを受け付け、別形式を話すプロバイダーに送ります。LiteLLM はサポートする全プロバイダーへの変換を文書化していますが、忠実性の規則は示していません。Lazu は無損失と検証されたエッジに沿ってのみ変換し、それ以外は上流を呼ぶ前に機能とフィールドを示す 400 で拒否するので、ツール呼び出しや推論パラメーターが途中で落とされることはありません（設計ノート）。
どちらを選ぶか
- ゲートウェイがプラットフォームの内部部品で、YAML と Python フックが欲しい、または既に LiteLLM SDK を使っているなら LiteLLM。
- ゲートウェイそのものが人に渡す製品であるなら、つまり予算付きキー、ウォレット、本人が読めるリクエスト記録、プログラマーでない運営者が扱えるコンソールが要るなら Lazu。
- 両方を動かすのも妥当です。LiteLLM をサービス内のライブラリとして、Lazu をそのサービスが引き落とすアカウントとして。
Lazu と New API、他のゲートウェイの概要も参照してください。