メインコンテンツへスキップ
OpenRouter の代替が役立つのは、必要なモデルや地域、デプロイの管理権限、請求フロー、未対応の連携など、具体的な不足を解決するときです。サービスを比較する前に、その要件を書き出してください。モデル数や入力単価だけでは適性を判断できません。 現行の経路が要件を満たしているなら、継続利用も比較対象に含めます。両者が OpenAI 互換形式でも、移行には検証と運用の作業が発生します。

要件から候補を絞る

OpenRouter のクイックスタートは API 接続を説明しています。LiteLLM 文書には SDK、自前運用のプロキシ、仮想キー、コスト追跡が記載されています。Portkey の概要はゲートウェイと可視化機能を説明しています。すべての構成が同じ機能を持つと考えず、利用する版と設定を確認してください。

条件をそろえて請求を比較する

同じモデルバージョン、入出力比率、キャッシュ挙動、通貨で比較します。該当する入金・プラットフォーム費用に加え、自社のインフラと保守費も含めます。一定の上乗せや割引を仮定せず、各サービスの現行条件を読んでください。 Rock API は現在のカタログと料金・請求ガイドから確認します。基本単価、グループ倍率、チャージ費用、過去の精算は別の情報です。表示価格に倍率が含まれている場合は再適用しません。全モデル・全リクエストで一定の節約が得られるわけではありません。

キャッシュを単純な有無で判断しない

OpenRouter は対応プロバイダーとモデルのプロンプトキャッシュを明示しています。サービス全体を「キャッシュなし」と評価するのは不正確です。どの候補でも、接頭辞の条件、書き込みと読み取り、期限、上流経路、使用量報告を確認します。 プロバイダーのプロンプトキャッシュと、ゲートウェイが保存済み回答を返す仕組みは用途が異なります。鮮度とプライバシーの要件を確認し、繰り返しプロンプトと一度きりの要求を分けて試験してください。楽観的なヒット率を予算の前提にしないことが大切です。

切り戻せる移行を計画する

  1. 実際に利用するエンドポイント、モデル ID、ツール、出力形式、ヘッダー、タイムアウト、使用量フィールドを列挙します。
  2. 候補ごとに対応を確認します。クライアント形式の互換性だけでは全パラメータの互換性は分かりません。
  3. 専用の認証情報と上限付き予算を用意し、秘匿情報を除いた代表的な要求で正確さと遅延を測ります。
  4. モデル利用不可、制限、形式エラー、ストリーム中断を試験します。再試行の担当と、代替経路による費用・プライバシー条件の変化も確認します。
  5. 少量のトラフィックから移行し、完了した使用量記録を照合します。旧経路を切り戻し用に残します。

最初に評価する候補

Rock API のホストサービスは、モデル権限を確認してクイックスタートから試せます。プロキシを自分で制御したい場合は LiteLLM のデプロイ設計を、可視性やガバナンスが目的なら Portkey の対象機能と条件を先に確認してください。記録した不足を解決し、業務テストに合格する候補を、保守負担も含めて選びます。