LiteLLMとOpenRouterを比較：コスト、管理性、フェイルオーバー

LLMゲートウェイ選びで本当に問われるのは、LiteLLMとOpenRouterがOpenAI互換APIを話せるかどうかではありません。ルーティング層を誰が運用するのか、という点です。すでに本番向けのゲートウェイ基盤を運用していないチームなら、手軽に始められるOpenRouterが有力です。一方、プライベートネットワークや独自ポリシーが必要で、利用量も継続的に増えるなら、運用負担を引き受けてでもLiteLLMで主導権を持つ価値があります。

これはAPI形式の比較ではなく、運用モデルの選択だ

LiteLLMは、Python SDKとしてもセルフホスト型プロキシとしても動かせるオープンソースソフトウェアです。OpenRouterは、マネージドAPIとモデルカタログを提供するサービスで、ゲートウェイの運用、プロバイダーへのアクセスの集約、モデル利用の一元的なアカウント管理を担います。

どちらもOpenAI互換のインターフェースを提供できますが、責任の所在は大きく異なります。

この違いを利用すれば、両者を組み合わせた構成も成立します。LiteLLMを社内のポリシー適用・コスト管理層として使い、特定のモデルアクセスだけをOpenRouterに任せる方法です。

最初に問題になりそうな制約で選ぶ

最適な選択肢は、チームにとって最初に妥協できなくなる要件で決まります。

トークン料金だけでなく、エンジニアリングコストまで追う

LiteLLMとOpenRouterは、異なる層に対して料金が発生します。OpenRouterは基盤となるモデル料金を推論マークアップなしで転嫁し、そのうえでクレジット購入時に5.5%の手数料を請求します。LiteLLMのオープンソースプロキシにはトークン単位のゲートウェイ手数料はありませんが、インフラと運用に必要な人員の費用を負担することになります。

手数料の条件については、OpenRouterの料金ページを確認するのが確実です。この手数料はクレジットの購入に対して発生するもので、すべてのモデルのトークン価格に単純に5%を上乗せする仕組みではありません。

OpenRouterの手数料のほうが安く済むケース

チームが月間の推論費用をまかなえるだけのOpenRouterクレジットを購入するとします。

• 月間利用額が$500なら、クレジット購入手数料5.5%は$27.50。
• $20,000なら、同じ割合で$1,100。
• $50,000なら、$2,750です。

LiteLLMで運用する場合は、ホスティング、デプロイ、パッチ適用、アラート、バックアップ、エンジニアリング時間まで含めたコストが、これらの金額を下回る必要があります。月額$500程度なら、すでにゲートウェイを運用していないチームにとって、プライベートネットワークが必須でない限り、OpenRouterのほうが運用負担の面で有利なことが多いでしょう。月額$20,000になると、プラットフォームを管轄するチームはLiteLLMを本格的に比較すべきです。

LiteLLMのゲートウェイ手数料ゼロが実際に効くケース

LiteLLMがコスト面で有利になるのは、固定的な運用費をすでにプラットフォームチームが吸収できている場合、または削減できる割合手数料が、プロキシ追加運用のコストを上回る場合です。

公式のDockerクイックスタートでは、データベースを使わないシンプルなプロキシと、データベース連携の構成が分けて説明されています。Composeの構成では、モデル、キー、利用額ログにPostgreSQLを使用します。データベースなしでは、仮想キー、利用額の追跡、実効的な予算適用は利用できないとLiteLLMは説明しており、設定したmax_budgetも信頼できる厳格な上限にはなりません。

Redisも、本番運用に進む際の境目です。LiteLLMのRedis要件では、プロキシを複数のワーカーまたはレプリカで動かす場合、共有Redisの利用を推奨しています。共有Redisがないと、レート制限、予算、クールダウン、キャッシュエントリ、ルーティングに関する観測情報がワーカーごとに分散します。シングルワーカーのテストは安価ですが、水平スケールする本番ゲートウェイは別の規模のシステムです。

トークン価格だけでなく、次の式で比較してください。

LiteLLM total cost = provider bills + infrastructure + operations + security ownership
OpenRouter total cost = provider inference + credit-purchase fee

普遍的な損益分岐点はありません。見るべきなのは、月間の推論費用、ホスティング費、エンジニアリング時間、オンコール体制、コンプライアンス対応に伴う追加コストです。

運用することになるコントロールプレーンを比較する

LiteLLMならプラットフォームチームがより細かく制御できますが、プロバイダーへのアクセスまで用意してくれるわけではありません。OpenRouterはモデルの探索と請求の一元化が簡単な一方、ホスト型のカタログを利用することと、プロバイダーと直接契約して関係を持つことは同じではありません。

信頼性を見ると、両者の違いは大きくなる

どちらもリトライやフェイルオーバーに対応できますが、前提となる責任の持ち方が異なります。OpenRouterではプロバイダー群をサービス側が管理します。LiteLLMでは自分でその群を定義し、信頼性基盤の一部として運用しなければなりません。

OpenRouterのプロバイダールーティングのドキュメントによると、デフォルトでは利用可能なプロバイダー間で負荷分散しつつ、価格と直近の障害状況も考慮します。プロバイダーの優先順を指定する、フォールバックを許可・無効化する、特定のパラメーターを必須にする、データポリシーで絞り込む、価格・スループット・レイテンシー順に並べる、といった指定も可能です。モデルフォールバックのガイドでは、modelsに順序付きのリストを指定する方法を説明しています。請求対象になるのは、最終的にリクエストを処理したモデルです。

LiteLLMのルーティングドキュメントでは、重み付きまたはシャッフルによる選択、利用状況を考慮したルーティング、レイテンシーベース、最も負荷の低いデプロイメント、コストベース、独自戦略によるルーティングが説明されています。デプロイメントの優先度、クールダウン、リトライ、フォールバックグループにも対応します。プログラマビリティは高い反面、設定、ヘルスチェック、共有状態、障害対応が正しく運用されていることが前提です。

エージェントのレイテンシー、キャッシュ、プロバイダーの差異

長いストリーミング回答であれば、ネットワークホップが1つ増えても影響は大きくないかもしれません。しかし、エージェントが短いモデル呼び出しを何十回も行う場合、ゲートウェイ、ネットワーク、リトライの遅延がターンごとに積み重なります。セルフホストのLiteLLMプロキシならアプリケーションの近くに配置できますが、OpenRouterでは選択されたプロバイダーの前にマネージドサービスのホップが加わります。どちらのベンダーの一般的なドキュメントも、利用地域、モデル、ストリーミングモード、同時実行数を含めた実測の代わりにはなりません。

ルーティングはキャッシュの経済性にも影響します。OpenRouterでは同じモデルでもプロバイダーのエンドポイントが変わる可能性があり、LiteLLMでも設定したデプロイメント間でリクエストを分散できます。プロバイダー側のプロンプトキャッシュに依存するワークフローでは、ルートの変更によってキャッシュの局所性やトークンコストが変わることがあります。キャッシュの挙動もワークロードテストの対象にしてください。

同じモデルスラッグだからといって、動作まで同じとは限りません。プロバイダーによって、コンテキスト上限、ツール呼び出しへの対応、レイテンシー、量子化、キャッシュ、プロバイダー固有のパラメーターが異なることがあります。OpenRouterではrequire_parametersなどのプロバイダーフィルターを利用できます。LiteLLMはプロバイダー呼び出しを共通インターフェースに正規化しますが、エージェントが使う正確なツールスキーマとモデルパラメーターは必ずテストしてください。

想定しておくべき障害パターン

OpenRouterでは、インフラ障害がベンダー依存の問題になります。LiteLLMでは、障害をプラットフォームチームが調査し、構成を変更できる一方、その障害対応自体をチームが引き受けます。

可観測性とプライバシーは、管理する境界が違う

「セルフホスト」と「プライベート」は同義ではありません。また、「マネージド」だからといって、すべてのプロンプトをログに残すわけでもありません。重要なのは、どの層がコンテンツを保存し、どの層がメタデータを保存し、どのプロバイダーにリクエストが送られるのかです。

OpenRouterのZero Data Retentionのドキュメントによれば、ZDRはアカウント全体、モデルグループ、ガードレール、リクエスト単位で適用できます。また、保持しないエンドポイントと、学習には使わないものの一時的にデータを保持するプロバイダーを区別しています。ZDRが適用されるのは推論ルーティングであり、有効化したツールやプラグインは別途確認が必要です。

LiteLLMでは、ゲートウェイのネットワーク、データベース、認証、ログをより細かく管理できますが、その責任は自社にあります。プロキシの保護、ソフトウェアのパッチ適用、管理用ルートの制限、プロバイダーキーの保護を行い、上流プロバイダーごとのデータ保持・学習条件を確認してください。

現実解になりやすいハイブリッド構成

社内向けの安定したエンドポイントとガバナンスは必要だが、モデルやプロバイダーごとに直接アカウントを開設したくない。そんな場合は、OpenRouterの前段にLiteLLMを置く構成が現実的です。機密性の高いトラフィックや予測可能なトラフィックは承認済みのプロバイダーへ直接送り、探索的な利用やカタログ依存のトラフィックはOpenRouter経由にします。

簡略化した設定例は次のとおりです。

model_list:
  - model_name: direct-claude
    litellm_params:
      model: anthropic/claude-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: catalogue-model
    litellm_params:
      model: openrouter/<provider>/<model>
      api_base: https://openrouter.ai/api/v1
      api_key: os.environ/OPENROUTER_API_KEY

この構成なら、LiteLLMで社内キー、予算、タグ、ログを管理できます。ただし、OpenRouter経由のリクエストについては、OpenRouterの手数料、ホスト型サービスを経由するデータ境界、プロバイダーポリシーの境界が残ります。ホップと障害ドメインも増えるため、すべてのリクエストを自動的に両方の層へ通すべきではありません。

現実的な振り分けは次のようになります。

1. 機密データ、安定した本番モデル、個別に契約したプロバイダーには、直接接続のルートを使う。
2. モデル探索、利用頻度の低いプロバイダー、マネージドなプロバイダーフォールバックには、OpenRouterのルートを使う。
3. アプリケーションキー、チーム、予算、社内のコスト配賦はLiteLLMで管理する。
4. 直接接続とOpenRouter経由のトラフィックで、ダッシュボードとアラートを分ける。

移行で変わるもの、変わらないもの

OpenAI互換クライアントを2つのゲートウェイ間で切り替えるだけなら、変更は小さく済むことがあります。しかし、本番ワークロードの移行は、ベースURLを書き換えるだけでは終わりません。

from openai import OpenAI
import os

client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

OpenRouterでは通常、https://openrouter.ai/api/v1を使用します（APIリファレンス）。LiteLLMプロキシでは、http://localhost:4000のようなプライベートエンドポイントを公開するのが一般的です（プロキシのクイックスタート）。それでも、モデルID、プロバイダープレフィックス、認証、オプションパラメーターには違いが残る場合があります。

本番トラフィックを切り替える前に、次の項目をテストしてください。

1. ストリーミングとタイムアウトの挙動。
2. 実際に使うJSONスキーマでのツール呼び出し。
3. 構造化出力と厳格なJSON処理。
4. 推論、キャッシュ、プロバイダー固有のパラメーター。
5. プライマリーモデルが429、5xx、またはバリデーションエラーを返した場合のフォールバック。
6. コストの配賦。請求イベントがアプリケーションのリクエストとは別の層で発生する可能性があるため。

API互換性があれば、最初の統合まではスムーズに進められます。しかし、出力、レイテンシー、プロバイダーの選択、請求の意味まで同じになるとは限りません。

選定前によくある質問

LiteLLMとOpenRouterは併用できますか？

できます。LiteLLMからOpenRouterを上流ルートとして利用すれば、社内キー、予算、ログ、ポリシーはLiteLLMで管理しながら、特定モデルへのアクセスとプロバイダー間のルーティングをOpenRouterに任せられます。ただし、経路にホップが1つ増え、そのトラフィックにはOpenRouterの手数料とホスト型サービスを通るデータ境界が残ります。

本番APIでは、どちらが安いですか？

すでにゲートウェイ基盤を運用していない小規模チームなら、OpenRouterのほうが運用負担を抑えやすいでしょう。必要なインフラをすでに運用していて、割合ベースのゲートウェイ手数料を避けたいチームでは、利用額が大きくなるほどLiteLLMが安くなる可能性があります。トークン料金だけでなく、総コストで比較してください。

LiteLLMでOpenRouterのカタログ全体にアクセスできますか？

LiteLLM単体ではできません。LiteLLMはプロキシのクイックスタートで100以上のLLMと幅広いプロバイダーへの対応を説明していますが、実際にアクセスできるのは自分で設定したプロバイダーと認証情報の範囲です。OpenRouterを上流として追加すれば到達可能なカタログを広げられますが、そのリクエストはOpenRouter側のモデルとプロバイダーの提供状況に従います。

プライバシーとコンプライアンスでは、どちらが優れていますか？

セルフホストのLiteLLMなら、ゲートウェイの配置、ログ、認証情報、ネットワーク境界をより細かく管理できます。OpenRouterもコンテンツログの制御、プロバイダーポリシーフィルター、ZDRルーティング、Enterprise向けのEU/USリージョンオプションを提供していますが、リクエスト経路の一部であることに変わりはありません。選定前に、実際に使うプロバイダーと契約上の要件を確認してください。

自社で責任を持って運用できる境界を選びましょう。割合ベースの手数料を、実際にゲートウェイを運用するコストと比較し、ホスト型の中継サービスを通してよいリクエストを分類し、必要なルーティングとツール呼び出しの挙動を障害テストで確認してください。LiteLLMのデータベース、Redis、アップグレード、オンコール対応まで担える体制がないなら、OpenRouterを選ぶほうが現実的です。すでにそのプラットフォーム能力があるなら、LiteLLMまたはハイブリッド構成によって、主導権を取り戻し、継続的なゲートウェイ手数料を抑えられる可能性があります。

OpenRouterの代替サービスを幅広く比較したい場合は、OpenRouter alternativesも参照してください。この記事は意図的に対象を絞り、LiteLLMをどう運用モデルとして選ぶかに焦点を当てています。