コンテンツへスキップ

移行ガイドLiteLLMから

自分で運用するLiteLLMプロキシから、運用しなくてよいものへ

LiteLLMには2つの側面があります。100社以上のプロバイダーと通信するPython SDKと、PostgresおよびRedisとともにデプロイして、仮想キー、予算、フォールバック、キャッシュを加えるプロキシです。どちらも、INFROと同じく、お客様自身のプロバイダーキーで動作します。変わるのは、プロキシを誰が運用するかです。このページでは、プロキシのコンフィグをINFROに対応付け、SDKを使い続ける方法を示します。

BerriAI製のMITオープンソース、およびライセンス制のEnterpriseエディション。セルフホスト

INFROのアカウントはセルフサービスで作成できます。 カタログ、ドキュメント、API仕様は公開済みで、ゲートウェイもデプロイ済みです。v1以降の機能には「今後提供」と表示しています。 プランとトライアル

現状

ライセンスとエディション

enterprise/ディレクトリ以外はMITです。Enterpriseは同じイメージにライセンスキーを加えたもので、SSO、SCIM、監査ログ、シークレットマネージャー、サポートが加わります。

2026年のセキュリティアドバイザリー

LiteLLM自身のブログには、2026-03-24のlitellm 1.82.7と1.82.8のPyPI侵害（公式のDockerイメージは影響なし。クリーンな1.83.0が2026-03-30に公開）、1.83.7（2026-04-29）で修正されたプロキシのキー検証におけるSQLインジェクション、1.84.0（2026-06-01）で修正されたHostヘッダーによる認証バイパスが記載されています。プロキシを運用する場合、これらを自分で追跡する必要があります。

リクエストを処理するアカウントの所有者

どちらの製品でもお客様のものです。LiteLLMがプロバイダーアカウントを保有することはなく、INFROも同様で、プロバイダーはお客様に直接請求します。

LiteLLMは無料でオープンであり、どこでも動作します。それが選んだ理由であれば、今でも十分に良い理由です。

  • トラフィックを自社のネットワークから出してはならない、またはゲートウェイのコードを読んで修正できなければならない場合。INFROはホスト型でクローズドソースです。セルフホストまたはハイブリッドはエンタープライズ契約になります。
  • セマンティックキャッシュ、コンテキストウィンドウやコンテンツポリシーのフォールバック、A2Aエージェントゲートウェイ、または特定のロギングベンダーへのコールバックを使っている場合。INFROには、完全一致のキャッシュ、ルートの障害ルール、MCPゲートウェイ、OpenTelemetryエクスポートがあります。
  • INFROが接続していないプロバイダーや、提供していないエンドポイントを呼び出している場合：バッチ、ファイル、ファインチューニング、Realtime、OpenAI、Azure OpenAI、Mistral、OpenAI互換エンドポイント以外のプロバイダーでの埋め込み。
  • プラットフォームチームがすでにPostgres、Redis、アップグレードを担当しているため、運用の負担が小さい。

変更点を1行ずつ。ここにないものはそのままです。

 LiteLLMINFRO
ベースURLお客様のプロキシ。例：http://0.0.0.0:4000。https://api.infro.io/v1
キー/key/generateから発行した、LiteLLMの仮想キー（sk-...）。コンソールまたは管理APIで作成したINFROのゲートウェイキー。プロバイダーキーはlitellm_paramsからINFROの接続へ移します。
モデルIDmodel_listのmodel_name（gpt-4oなど）。同じ名前のルート（呼び出し元は引き続きその名前を送れます）、またはvendor/modelを直接。
ボディのフィールドmetadata { tags, trace_id, trace_user_id, generation_name }, cache { ttl, namespace }, user.metadata { user_id, session_id, tags }。レスポンスキャッシュにはcache。トレースIDにはX-INFRO-Trace-Id。

変更前 · LiteLLM proxy

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "http://0.0.0.0:4000",
  apiKey: process.env.LITELLM_API_KEY, // virtual key
});

await client.chat.completions.create({
  model: "claude-default", // model_name in model_list
  messages: [{ role: "user", content: "Hello" }],
  user: "user-123",
  // @ts-expect-error LiteLLM extension
  metadata: { tags: ["production"] },
});

変更後 · INFRO

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.infro.io/v1",
  apiKey: process.env.INFRO_API_KEY,
});

await client.chat.completions.create({
  model: "claude-default", // an INFRO route, same name
  messages: [{ role: "user", content: "Hello" }],
  // @ts-expect-error INFRO extension
  metadata: { user_id: "user-123", tags: { env: "production" } },
});

`model_list`はルートになる

複数のデプロイメントを持つ各model_nameは、それらをターゲットとするルートになります。rpmの重みは重み付きターゲットに、router_settings.fallbacksはルートの後続ターゲットまたはfallbacksになります。

SDKを使い続ける

LiteLLMのOpenAI互換プロバイダーは、openai/以降のすべてをモデルIDとして送信するため、openai/anthropic/claude-sonnet-5.5はanthropic/claude-sonnet-5.5としてINFROに届きます。その場合、フォールバックはSDKではなくINFRO内で行われます。

または、INFROの背後にプロキシを残す

移行の間は、プロキシをopenai-compatibleの接続として接続してください。その場合、INFROから見えるのはプロキシという1つのプロバイダーだけなので、プロバイダーを直接接続するまでは、プロバイダーごとのフェイルオーバーとコストはLiteLLM内で処理されます。

LiteLLMのオブジェクトとINFROのオブジェクトの対応。2026年10月19日に読んだLiteLLMの公開ドキュメントに基づき、ゲートウェイの実装と照合しています。 INFROにないものは1行あります。

LiteLLMそこでの役割INFROでは
`model_list`と`litellm_params`同じ形式モデル名ごとのデプロイメント。プロバイダーキーはコンフィグ内に。プロバイダー接続（キーは封印、1つのプロバイダーに複数）と、その上のルート。
仮想キー同じ形式プロキシが発行するキー。許可モデル、予算、tpmとrpm、チームとユーザー付き。許可するモデル、プロバイダー、IPレンジ、環境、支出上限、リクエストレートのティアを持つゲートウェイキー。ローテーションとオフスイッチ。
チーム、ユーザー、予算同じ形式キー、チーム、ユーザーごとのmax_budgetとbudget_duration。組織、プロジェクト、メンバー、キー、エンドカスタマーごとの予算。同時実行下でも維持され、上限に達するとプロバイダー呼び出しの前に402を返します。
tpm制限異なるキーまたはデプロイメントごとの毎分トークン数制限。キーごとのリクエストレートのティアとドル建て予算。毎分トークン数の制限はありません。
フォールバックとリトライ同じ形式fallbacks、num_retries、クールダウン、allowed_fails。ルートのターゲットと、種別ごとの障害ルール（再試行、フェイルオーバー、停止）。リクエストごとのfallbacks。
コンテキストウィンドウとコンテンツポリシーのフォールバック異なるプロンプトが長すぎる場合や、プロバイダーのポリシーで拒否された場合に使う別のモデル。moderationの障害ルールで、次のターゲットへフェイルオーバーできます。コンテキストウィンドウによるフォールバックはありません。
キャッシュ異なるRedis、S3、GCS、Qdrantなどによる、完全一致とセマンティックのキャッシュ。完全一致、オプトイン、チャット補完向け、ホスト型。セマンティックキャッシュはありません。
ガードレール異なるプラグイン式のガードレール。いくつかの連携はEnterpriseが必要。ブロック、マスク、フラグ付けを行うパターンルールと、意思決定モデルによるチェック。ガードレールを含むすべてのプランで。
ロギングのコールバック異なるLangfuseなどのツールへのコールバック。Postgresの支出ログ。リクエストログ、エクスポート、OpenTelemetryコレクターへのスパン。
支出の追跡異なるLiteLLMのモデル価格マップに基づくコスト。お客様の交渉済みの料金、またはベンダーの定価に基づく推定プロバイダー費用。不明な場合はunpriced。OpenAIとAnthropicのコストAPIと照合。
MCPゲートウェイ同じ形式プロキシの背後にあるMCPサーバー。自社のMCPサーバー向けのMCPゲートウェイ。承認済みのツールとキーごとの付与に対応します。
A2Aエージェントゲートウェイなしプロキシ経由のエージェント間トラフィック。なし。
自社で運用する場合異なるMIT。Dockerまたはpipで、どこでも。ホスト型。セルフホスト型またはハイブリッド型はエンタープライズ契約です。Enterprise — セルフサービスではなく、Enterprise契約で提供します。

LiteLLMの公開ドキュメントに対する当社の読み取りであり、トライアルやベンチマークではありません。誤りがあればお知らせください。該当する行を修正します。

INFROが行わないこと

  • エンタープライズ契約なしで自社のインフラで実行する、またはソースを読める。
  • セマンティックキャッシュ、コンテキストウィンドウのフォールバック、A2A。
  • バッチ、ファイル、ファインチューニング、Realtime、またはOpenAI、Azure OpenAI、Mistral、OpenAI互換エンドポイント以外のプロバイダーでの埋め込みの提供。
  • 毎分トークン数の制限。INFROは、リクエストレートとドルで制限します。

引き継がれないもの

  • LiteLLMのPostgresにある支出ログとリクエスト履歴。インポーターはありません。
  • 仮想キー。INFROのゲートウェイキーを発行し、呼び出し元を順次切り替えます。
  • コールバックとカスタムフック。OpenTelemetryエクスポートを使うか、そのロジックをご自身のコードに置いてください。

質問

LiteLLMのPython SDKは引き続き使えますか？
はい。LiteLLMのOpenAI互換プロバイダー経由でINFROを呼び出します。model="openai/<INFROのモデルID>"、api_base="https://api.infro.io/v1"、INFROのキーを指定してください。
INFROは、LiteLLMのようなオープンソースですか？
いいえ。INFROはホスト型サービスです。セルフホストまたはハイブリッドのデプロイは、エンタープライズ契約のもとで利用できます。
モデルプロバイダーへの支払いは誰が行いますか？
LiteLLMと同じく、お客様が直接お支払いします。INFROはサブスクリプションで、モデル支出への上乗せは0%です。

当社と一緒に、またはご自身で移行

移行プログラムでは、通話でLiteLLMの設定をINFROの接続、ルート、予算に対応付け、最初のサービスを一緒に移行します。プロバイダーは引き続きお客様に直接請求し、INFROはサブスクリプションで、モデル利用料への上乗せは0%です。

14日間のトライアルを開始 移行セッションを予約INFRO vs LiteLLMクイックスタートを読む

出典

このページにあるLiteLLMについての記述は、すべて2026年10月19日に読んだこれらの資料に基づいています。トライアル、ベンチマーク、会話から推測したものはありません。