OpenRouterとLiteLLMを比較：料金・BYOK・運用の違い

ゲートウェイを自社で運用し、プロバイダーの認証情報を自社インフラ内に置きたいなら、LiteLLMが適しています。ホスティング型のルーティングを使い、モデルの利用料金をまとめて支払いたいなら、OpenRouterが候補です。OpenRouterのStandardではクレジット購入時に5.5%の手数料がかかり、LiteLLMのオープンソース版はライセンス料が$0です。選ぶ際の分かれ目は、ゲートウェイの運用主体、推論料金の請求先アカウント、そして削減できる手数料が自社での運用コストを上回るかどうかです。

OpenRouterとLiteLLM、どちらを選ぶべきですか？

別のサービスを自分で運用せずに複数のプロバイダーを使いたい開発者には、OpenRouterが向いています。ゲートウェイ、認証情報、トラフィック制御を自社管理のインフラで動かす必要があるなら、LiteLLMが向いています。 利用量が多いという理由だけでは決まりません。OpenRouterで自分のプロバイダーキーを使うBYOKと、推論用クレジットを購入する方式では、費用の仕組みが異なります。

ゲートウェイは、プロダクトとモデルプロバイダーの間に置くものです。本記事では、Python SDKだけではなくLiteLLMのセルフホスト型Proxy Serverと、OpenRouterのホスティング型サービスを比較します。OpenRouterについては、クレジット払いと、自分のキーを持ち込むBYOKの両方を扱います。

料金とドキュメントの確認日は2026年10月12日です。 LiteLLMの公開料金とOpenRouterの公開料金もこの日に確認しています。後述の月額費用は、公開されている手数料をもとに計算しました。ログインしての試用やレイテンシーのベンチマークは実施していません。

機能の比較は、LiteLLMのアーキテクチャ、OpenRouterのキースキーマ、および後述するルーティング、ログ、キャッシュの各ドキュメントに基づいています。連携先プロバイダーの数と購入可能なモデルの数は、数えている対象が異なります。いずれの数字も、必要なモデル・リージョン・機能の組み合わせが使えることを保証するものではありません。

プラットフォームの専任担当者がいない小規模なプロダクトなら、ホスティング型のリクエスト経路が具体的な要件に反しない限り、OpenRouterから始めるのがよいでしょう。すでに共通インフラを運用していて、キーごとのレート制限を一元的に適用する必要があるなら、LiteLLMが適しています。成長中のプロダクトでプロバイダーと個別の料金契約を結んでいる場合は、両方にクレジット購入手数料を当てはめるのではなく、OpenRouterのBYOKとLiteLLMを比較してください。

キーの管理、請求、リクエストの転送は誰が担いますか？

LiteLLMではゲートウェイを自社の管理下に置けます。OpenRouterでは、その中継をマネージドサービスに任せます。 BYOKで変わるのは上流プロバイダーへの認証情報と支払い元です。中継サービスを通る点は変わりません。

LiteLLM：自社のゲートウェイから、自社のプロバイダーアカウントへ

LiteLLMは、アプリケーションとモデルプロバイダーの間にデプロイするオープンソースのゲートウェイです。ドキュメントに示された処理経路では、仮想キーの検証、予算とレート制限の適用、リクエストのルーティングを行い、プロバイダーのAPI形式に変換します。仮想キーはゲートウェイが発行するアプリケーション用の認証情報です。そのため、アプリケーションに各プロバイダーの秘密鍵を持たせる必要はありません。LiteLLMのリクエスト処理の構成。

推論料金は、設定した自社のプロバイダーアカウントに請求されます。ゲートウェイには、それとは別に運用予算が必要です。計算リソース、キーと支出を管理するデータベース、導入するキャッシュや共通のレート制限基盤が対象になります。本番環境へのデプロイに関するドキュメントはこれらの構成要素を説明していますが、どの環境にも当てはまるホスティング費用は示していません。

認証情報とデプロイ環境を管理したいなら、LiteLLMが優位です。 ただし、アップグレード、データベースの可用性、リクエスト失敗への対応を担う人がいないなら、導入は見送るべきです。ソフトウェアが無料でも、運用担当者まで確保できるわけではありません。

OpenRouter：ルーティングの運用を任せ、支払い元を選ぶ

OpenRouterは、ホスティング型のゲートウェイとモデルカタログを提供します。購入したクレジットを使う場合、アプリケーションはOpenRouterのキーを使用し、利用分がクレジット残高から差し引かれます。BYOKでは、プロバイダーの認証情報を自分で登録します。OpenRouterによると、登録したキーは暗号化され、指定したプロバイダーへのリクエストに使われます。推論の利用料金はプロバイダーアカウントに請求され、該当するルーティング手数料はOpenRouterのクレジットから差し引かれます。OpenRouterのBYOKドキュメント。

初期設定で注意したいのは、共有キャパシティへのフォールバックです。優先するBYOKキーでリクエストを処理できない場合、OpenRouterは自社のキャパシティを使い、利用者のOpenRouterクレジットを消費することがあります。プロバイダー単位で最も厳しく制限する設定は、**「このプロバイダーのどのモデルでも共有キャパシティを使わない」**です。ただし、許可するプロバイダーも制限しない限り、別のプロバイダーがリクエストを処理する可能性は残ります。これは可用性だけでなく、どこに請求するかを決める設定でもあります。

モデルカタログをすぐに使いたい、購入先をまとめたい、ゲートウェイの運用を任せたい場合は、OpenRouterが優位です。 自社のプロバイダーアカウントを維持したいならBYOKが適しています。ただし、フォールバックによって請求先がOpenRouterに切り替わってよいかは、明示的に決めてください。

OpenRouterの料金：クレジット購入とBYOKの違い

OpenRouterでは、クレジットの購入時と、無料枠を超えたBYOKのルーティングにそれぞれ手数料がかかります。別々の手数料として考える必要があります。 FAQには、クレジット購入ごとに5.5%、最低$0.80の手数料、および暗号資産での支払いに5%の手数料が記載されています。プロバイダーの推論料金には上乗せがありません。OpenRouterの手数料に関するFAQ。

公開中のプラン比較表では、Standardが5.5%、Businessが**8%**です。どちらも、定価換算で月額$25,000分の推論まではBYOK手数料が無料で、それを超える分には5%の手数料がかかります。Enterpriseは個別条件です。後述の試算にはStandardを使っています。その料率をBusinessに当てはめないでください。現在のプラン比較表。

BYOK手数料の算定基準は、同じモデルとプロバイダーをOpenRouterで通常利用した場合の料金です。プロバイダーから割引を受けている場合、その請求額と一致するとは限りません。無料枠はリクエスト数ではなく推論の金額で計算され、手数料はOpenRouterクレジットから差し引かれます。BYOK手数料の定義。

クレジット購入と利用料金の仕組みは、OpenRouterの料金ガイドで詳しく説明しています。

LiteLLMのOpen SourceとEnterpriseの料金体系

LiteLLM Open Sourceは、本番利用でもライセンス料がかかりません。 料金ページには、仮想キー、支出の追跡、予算、レート制限、フォールバック、リクエストとレスポンスのログ、Prometheusメトリクスが含まれています。これらがすべてEnterprise限定というわけではありません。LiteLLMのプラン。

Enterpriseでは、SSO/SCIM、OIDC/JWT認証、監査ログ、シークレットマネージャー、キーのローテーションといったID・組織管理機能に加え、サポートやデプロイの選択肢が増えます。料金は年額で、トークンの利用額ではなく、ゲートウェイのリクエスト処理容量、構成、必要なサポートによって決まります。月額費用を公平に比較するために使える公開価格はないため、実際の見積額を使ってください。

月額費用を試算：小規模な利用と、利用量が増えた場合

月間の推論利用額を定価換算で$50,000とした例では、Standardのクレジット払いは$52,750、StandardのBYOKのみを使う場合は後述の購入条件で$51,318.75です。LiteLLM Open Sourceは$50,000に自社の運用コストを加えた額になります。 これらは計算上の金額であり、セット料金の見積もりでも、実測したワークロードでもありません。

同じモデル、プロバイダー、トークン構成で比較し、月間の推論利用額をBとします。小規模な例は**$100**、利用量が増えた例は、公開されているBYOK無料枠の倍に当たる**$50,000**です。プロバイダーの請求額は定価と等しく、キャッシュによる節約や個別契約による割引はなく、共有キャパシティへのフォールバックもないものとします。また、暗号資産以外の決済でStandardクレジットを一度に購入し、全額を使い切る前提です。税金と任意の追加サービスは比較に含めません。

LiteLLMの実際の月額ホスティング・保守費用をHとします。根拠のないサーバー費用の見積もりで置き換えないでください。

計算には、クレジット購入手数料と現在のBYOK無料枠を使っています。BYOKのみを使う月でルーティング手数料が発生しない場合は、クレジットを購入する必要もないと仮定しています。

利用量が増えた例をクレジット払いで処理する場合、$50,000分のクレジットを購入し、$50,000 × 5.5% = $2,750が加算されます。実際の支出合計は**$52,750**です。

同じ利用量をBYOKで処理すると、プロバイダーの請求額は**$50,000です。ルーティング手数料は無料枠を超えた推論利用額に適用されるため、($50,000 − $25,000) × 5% = $1,250になります。この手数料を支払うためにStandardクレジットを購入すると、さらに$1,250 × 5.5% = $68.75がかかります。合計は$50,000 + $1,250 + $68.75 = $51,318.75**です。この購入手数料は、BYOK手数料を購入済みクレジットで支払うことから生じる費用です。プロバイダーの請求額に再び手数料をかけているわけではありません。

損益分岐点は、OpenRouterのどの方式と比べるかで変わります

Standardのクレジット払いと比べると、Hが削減できるクレジット購入手数料より小さい場合に、LiteLLMのほうが安くなります。 最低手数料が適用される範囲を超えていれば、損益分岐点はB = H ÷ 0.055です。小規模な例でHに充てられる額は**$5.50にとどまり、利用量が増えた例では$2,750**です。

StandardのBYOKのみを使う場合との比較では、無料枠以下の利用でルーティング手数料を削減する余地はありません。 無料枠を超え、かつ料率で計算したクレジット購入手数料が最低額を上回る範囲では、損益分岐点はB = $25,000 + H ÷ 0.05275です。利用量が増えた例で、ここに挙げた費用だけでLiteLLMが安くなるには、運用費を月額$1,318.75未満に抑える必要があります。Enterpriseライセンスを使う場合は、HをHと実際の見積額の月額換算分の合計に置き換えます。

プロバイダーの割引、モデル料金、クレジットの購入単位、フォールバックの利用状況が変われば、請求額も変わります。リクエストごとにトークンの費用が異なるため、リクエスト数だけで損益分岐点を判断することはできません。

フォールバック・予算・キャッシュは、どちらが得意ですか？

自社のゲートウェイ内で制御を運用するならLiteLLM、ゲートウェイを保守せずにルーティングを使うならOpenRouterが優位です。 判断を分けるのは、フォールバック機能の有無だけではなく、設定できる内容とその適用範囲です。

ルーティングとフォールバック：運用を任せるならOpenRouter

OpenRouterのプロバイダールーターでは、プロバイダーの優先順、許可リスト、allow_fallbacksを設定できます。それとは別のmodels配列は、優先モデルがリクエストを処理できないときに代替モデルを試します。この違いは重要です。同じモデルのまま提供元を変えることと、モデル自体を変えることでは、プロダクトとしての判断が異なります。プロバイダーのルーティング、モデルのフォールバック。

LiteLLMのドキュメントでは、設定したモデルグループ内でのリトライと、別のグループへのフォールバックが説明されています。そのデプロイ環境とルールは自社で管理します。LiteLLMのルーティング構成。

フェイルオーバーの運用を任せたい開発者には、OpenRouterが向いています。 承認済みのフォールバック先が、すでに自社で管理しているデプロイ先なら、LiteLLMを選ぶのがよいでしょう。フォールバック先の一覧からレイテンシーの優劣は分かりません。本記事も、その優劣を示すものではありません。

予算とキーごとのレート制限：トラフィックを統制するならLiteLLM

LiteLLMでは、仮想キーに予算と、分あたりのリクエスト数（RPM）、分あたりのトークン数（TPM）の上限を設定できます。支出上限は累積費用を、レート制限はアプリケーションがキャパシティを消費する速さを制御します。顧客が月間予算を超えていなくても、望ましくないリクエストの集中が起きることはあります。LiteLLMの予算とレート制御。

明示されている制約は、データベースへの依存です。 LiteLLMのドキュメントには、データベースを使わないデプロイでは予算によって利用量を制限できないと明記されています。全体の予算チェックは失敗時にリクエストを通す「フェイルオープン」になり、キー・ユーザー・チームごとの予算は利用できません。必要な基盤サービスがなければ、設定ファイルに予算額を書くだけでは機能しません。

OpenRouterには、キーごとの金額上限、リセット周期、include_byok_in_limit設定が用意されています。キー作成スキーマには、ユーザーがキーごとに設定できるRPM/TPMのフィールドは記載されていません。一方、制限に関するページでは、プラットフォームとプロバイダーのキャパシティ制御が説明されています。キーの支出上限と、アプリケーション単位のスループット上限は別物です。キーの制御、レートと予算の制限。

キーごとの支出とスループットのルールが必須なら、LiteLLMが優位です。 OpenRouterにも支出を制御する機能はありますが、ドキュメントに示された適用範囲と、実際に支払うアカウントが合っているかを確認してください。

ログとキャッシュ：保存先を管理するならLiteLLM

LiteLLMではログの出力先を指定でき、支出のメタデータを残しながらメッセージ内容をマスキングできます。レスポンスキャッシュは、ローカル、Redisなど、ドキュメントに記載されたバックエンドに対応しています。完全一致キャッシュは、同一のリクエストに保存済みの回答を再利用します。ログの制御、キャッシュのバックエンド。

OpenRouterでは、非公開の入出力ログをオプトインで利用できます。また、ゲートウェイ側のレスポンスキャッシュとプロバイダー側のプロンプトキャッシュを分けて説明しています。前者は、同じリクエストに対し、プロバイダーを呼び出さずに保存済みのレスポンスを返す仕組みです。後者は、プロバイダー内部でプロンプトの処理結果を再利用します。レスポンスキャッシュは明示的に有効化しない限り無効で、APIキー単位で適用されます。非公開ログ、レスポンスキャッシュ、プロンプトキャッシュ。

ゲートウェイのログとキャッシュの保存先を選びたいなら、LiteLLMが優位です。 OpenRouterは、より手軽に使えるホスティング型の選択肢です。ただし、キャッシュには導入前に判断しておきたい制約があります。アカウント単位でゼロデータ保持を設定すると、レスポンスキャッシュは無効になります。 一方、リクエスト単位のprovider.zdrは、キャッシュの適用可否を変えません。データを保持しないプロバイダーを指定するだけでは、ゲートウェイのレスポンスキャッシュでの保持は無効になりません。

データの取り扱い：自社管理でも外部送信がなくなるとは限りません

LiteLLMを使うと、リクエスト経路からホスティング型ゲートウェイの事業者を外せます。ただし、外部で行う推論がローカル処理になるわけではありません。 セキュリティページには、「セルフホストする場合、データやテレメトリーはLiteLLMのサーバーに保存されません」と記載されています。それでも、アーキテクチャ上は選択したモデルプロバイダーにリクエストを転送します。LiteLLMのセキュリティ、リクエスト経路。

自社で管理できるのは、プロキシ、そのログ、設定した転送先です。上流プロバイダーや、有効にした外部ログサービスのポリシーが適用されなくなるわけではありません。

OpenRouterは、「OpenRouter上でのプロンプトの保持は、すべてオプトインです」と説明しています。非公開のデバッグログと、入出力を製品改善に使う許可は別の設定で、どちらも初期状態では無効です。リクエストのメタデータは保存します。また、少数のプロンプトを抽出し、ゼロデータ保持ポリシーのモデルで分類すると説明しています。入出力の利用にオプトインしていなければ、分類結果は匿名で保存され、アカウントやユーザーIDにはひも付けられないとしています。OpenRouterのデータ収集。

上流プロバイダーの取り扱いも、別に確認する必要があります。OpenRouterはデータ保持と学習利用のポリシーを分けて記載し、ゼロデータ保持（ZDR）の条件でエンドポイントを絞り込む機能を提供しています。データを学習に使わないことと、データを保持しないことは、異なる約束です。 ZDRのドキュメントでも、有効にしたプラグインやツールには独自の保持ポリシーがある場合があると注意しています。プロバイダーのポリシー、ZDRの制御。

ゲートウェイでのデータの取り扱いを自社で管理するなら、LiteLLMが優位です。 OpenRouterもホスティング型サービスの利用方針に適合する可能性はありますが、ゲートウェイ、プロバイダー、キャッシュ、有効にしたツールをそれぞれ評価してください。「BYOK」というだけでは、これらのデータ保持に関する疑問は解消しません。

OpenRouterからLiteLLMへ、または逆方向へ移行するには

移行の負担は、APIの接続先変更だけでなく、その周囲にある運用ルールと会計管理の再構築にあります。 リクエスト形式に互換性があっても、プロバイダーとの契約、予算、過去のログ、フォールバックのルールまでは移行されません。

1. 1

   すべての経路で、支払い元と認証情報を対応付ける

   LiteLLMに移行する場合は、クレジット払いのアクセスに代わるプロバイダーの認証情報とアカウントを特定します。OpenRouterに移行する場合は、購入クレジットかBYOKかを選び、フォールバック時に共有キャパシティを使ってOpenRouter側に請求してよいかを指定します。

2. 2

   モデルと動作を対応付ける

   プロダクトで使っているモデルの識別子やエイリアス、許可するプロバイダー、対応するリクエストパラメーター、フォールバック先を記録します。カタログ内のモデルをどれも交換可能と考えず、アプリケーションが意図したモデルの動作を維持してください。

3. 3

   予算・レート制限・データ保持を明確に設計し直す

   各キーの支出ルール、リセット周期、必要なスループット制御を引き継ぎます。LiteLLMでは、予算管理に必要なデータベースも構成に含めます。OpenRouterでは、どの予算にBYOKを含めるかを決めます。ログとキャッシュの保持は、プロバイダー側の保持とは分けて文書化してください。

4. 4

   会計上の切り替え点と、元に戻せる範囲を確保する

   従来の利用記録を自社のポリシーに従って保持し、切り替え時点を記録して、以前のルーティング設定を使える状態にしておきます。移行後にプロバイダーの請求書とゲートウェイのクレジットを照合する担当者を決めてください。

小規模なプロダクトがOpenRouterで問題なく動いていて、削減できる手数料より別のサービスを運用する費用のほうが大きいなら、手数料だけを理由にLiteLLMへ移行しないでください。ゲートウェイの自社管理が必須要件なら、稼働中のLiteLLMをホスティング型ルーターへ移すべきではありません。また、必要なモデルと機能を確認せず、カタログの大きさだけで移行を決めないでください。

両方を併用する構成もサポートされています。LiteLLMは、上流プロバイダーとしてOpenRouterを使う方法を説明しています。これにより、ローカルに制御点を置きながらOpenRouterのカタログを利用できます。ただし、OpenRouterのリクエスト経路と該当する手数料も残ります。ホスティング型の推論を、完全なローカルシステムに変える方法ではありません。

OpenRouterの代替候補：VercelとCloudflare

ホスティング型の手数料を比較するなら、まずVercel AI Gatewayが候補になります。Cloudflare AI Gatewayは、そのゲートウェイ制御が既存のインフラに合う場合に検討する価値があります。 いずれの場合も、どの認証情報を使い、どこに請求されるかを理解する必要があります。

Vercel AI Gatewayは、トークン料金への上乗せとプラットフォーム料金がなく、BYOKのゲートウェイ手数料もないとしています。BYOKを使うにはクレジットの購入が必要です。BYOKのリクエストが失敗すると、システム側の認証情報でリトライし、ゲートウェイ残高から課金されることがあります。無料枠には、対象モデルに使える月額$5分が含まれますが、クレジットを購入すると、この毎月の無料枠は終了します。決済処理手数料や任意の追加機能の費用は、別途かかる場合があります。Vercelの公式料金。

Cloudflare AI Gatewayは、基本的な分析、キャッシュ、レート制限を無料で提供しています。Unified Billingでは、クレジット購入時に5%が加算されます。公式の例では、$100分のクレジットに対して請求額は$105となり、プロバイダーの推論料金はそのまま適用されます。最初のゲートウェイを2026年9月24日以降に作成した新規顧客には、Workers Logsの料金が適用されます。ゲートウェイの機能が無料でも、ログを無制限に無料で使えるとは限りません。Cloudflareの公式料金。

この新しいログ料金の対象アカウントでは、Workers Paidに月間2,000万件のログが含まれ、超過分は100万件あたり$0.60です。Freeプランは1日200,000件のログと記載されています。Workers Logsの料金。認証情報のルールはCloudflareで請求先を制御するための記事で、より幅広い候補はOpenRouterの代替サービス比較で説明しています。

導入前によくある質問

OpenRouterとLiteLLMでは、プロバイダーのキーを誰が管理しますか？

セルフホスト型のLiteLLMでは、ゲートウェイが使うプロバイダーの認証情報を自社で管理します。OpenRouterのBYOKでは、ホスティング型サービスにプロバイダーのキーを登録します。OpenRouterは、このキーを暗号化すると説明しています。OpenRouterのクレジット払いでは、各プロバイダーのキーを自分で用意する必要はありません。

OpenRouterでも、プロバイダーとの既存契約を維持できますか？

BYOKなら、自社のプロバイダーアカウントを使ってリクエストできます。プロバイダーの請求額、定価を基準とするOpenRouterのBYOK手数料、共有キャパシティへのフォールバックは、請求上それぞれ別に考える必要があります。手数料の無料枠があっても、プロバイダーの推論料金まで無料になるわけではありません。

利用量が増えると、LiteLLMのほうが安くなりますか？

運用コストと、利用する場合のEnterpriseライセンス料の合計が、削減できるOpenRouterの手数料を下回る場合に限ります。代替手段がBYOKなら、BYOK手数料と比較してください。BYOKでのプロバイダー請求額全体にクレジット購入手数料率をかけると、削減額を過大評価してしまいます。

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

はい。LiteLLMのドキュメントには、OpenRouterとのプロバイダー連携が記載されています。ルーティングが両方の層を通るため、それぞれに関係する運用コスト、OpenRouterの手数料、ホスティング型のデータ経路も残ります。

ゲートウェイを切り替える前に、プロバイダーのキー、モデルへの支出、フォールバックの担当者を整理しましょう。ニュースレターからAI Business Workflow Audit Checklistを入手できます。