2026.10.21 AI

LiteLLMとは？複数LLMを1つのAPIで呼ぶProxyの構築手順とフォールバック・予算設定【2026年10月】

Q: Ollamaなどのローカルモデルもつなげますか？

つなげます。OpenAI互換のAPIを持つ推論サーバーであれば、config.yamlの litellm_params で openai/ 接頭辞と api_base を指定することで登録が可能です。クラウドのモデルとローカルモデルを同じ model_name の一覧に並べ、機密データはローカル、それ以外はクラウドと使い分ける構成も組めます。ローカル側の準備は ローカルLLMとは？必要スペック・Ollamaでの構築手順 が参考になります。

Q: 予算を日本円で管理できますか？

LiteLLMの max_budget と支出記録はUSD建てです。円で管理したい場合は、社内レートで換算したUSD額を上限に設定し、 /key/info などで取得したUSDの支出に同じレートを掛けて報告します。価格表に無いモデルや契約単価が違うモデルは register_model() で単価を登録しないと金額がずれるため、月に1度はプロバイダの請求額と照合してください。

LiteLLMとは？複数LLMを1つのAPIで呼ぶProxyの構築手順とフォールバック・予算設定【2026年10月】

LiteLLMは、OpenAI・Anthropic・Amazon Bedrockなど各社のLLMを、OpenAI互換の1つの呼び出し形式にそろえるオープンソースのPythonライブラリ兼プロキシサーバーです。この記事では2026年10月時点の1.106系を前提に、Python SDKでモデルを切り替える最小コード、DockerでLiteLLM Proxyを立ててconfig.yamlにモデルを登録する手順、障害時のフォールバック、仮想キーによる部署別の予算とレート制限までを、コピーして動かせる形で示します。後半では2026年3月のPyPI侵害を踏まえた版の固定と、採用・見送りの条件も示します。

まとめ：LiteLLMはOpenAI互換の窓口で複数LLMの切替と費用管理を担うOSS

LiteLLMの使い方は2つあります。アプリのコードに直接組み込むPython SDKと、社内の共通窓口として動かすProxy Server（AIゲートウェイ）です。1つのアプリから2社程度のモデルを呼ぶだけならSDKで足ります。複数のチームや複数のアプリがLLMを使い、APIキーの配布と費用の上限を一か所で握りたいならProxyを選びます。

Proxyで最初に設定する項目は4つです。model_listへのモデル登録、障害時のfallbacks、PostgreSQLを前提にした仮想キー、キーごとのmax_budgetとrpm_limitです。2026年3月にPyPI上の2つの版へ認証情報を盗むコードが混入した前例があるため、版を固定して公式Dockerイメージを使います。SSOを6人以上で使う、監査ログが要る、という段階でEnterpriseかマネージド製品を検討します。

LiteLLMの定義とPython SDK・Proxy Serverの2つの使い方の違い

OpenAI互換の形式で各社LLMを呼び分けるLiteLLMの基本構造と提供元

LiteLLMはBerriAI社が開発し、GitHubのBerriAI/litellmリポジトリで公開されています。PyPIの登録情報では、2026年10月21日時点の最新版は2026年10月20日公開の1.106.1、対応はPython 3.10以上3.15未満、ライセンス表記はMITです。

中心にある考え方は「呼び出し側は1つの形式で書き、違いはモデル文字列で吸収する」です。openai/やanthropic/のようなプロバイダ接頭辞をモデル名に付けると、LiteLLMが各社APIのリクエスト形式・認証・応答の違いを変換し、OpenAIのChat Completions形式で応答を返します。アプリ側のコードは、モデル文字列を差し替えるだけで別の会社のモデルへ移れます。

アプリに組み込むSDKと社内共通の窓口にするProxyを選ぶ判断基準

同じLiteLLMでも、SDKとProxyでは管理できる範囲が違います。判断の軸は「APIキーと費用を誰が握るか」です。

比較項目	Python SDK	Proxy Server
動かし方	アプリにimportして関数を呼ぶ	独立したHTTPサーバーとして常駐
呼び出せる言語	Pythonのみ	OpenAI互換APIを呼べる全言語
APIキーの置き場所	各アプリの環境変数	Proxyだけが保持し利用者には仮想キー
予算・レート制限	アプリ側で自作	キー・ユーザー・チーム単位で設定
必要な基盤	なし	コンテナ実行環境とPostgreSQL

PoCをSDKで始め、2つ目のチームが使い始めた段階でProxyへ移す流れが典型です。AIゲートウェイの考え方や、SaaS型・クラウド標準機能との比較はAIゲートウェイとは？役割・LLMゲートウェイとの関係と導入判断で整理しています。本記事はその中のOSS型、LiteLLMを実際に動かす手順に絞ります。

Python SDKでcompletionを呼び出してプロバイダを切り替える最小コード

uv add litellmで導入しOpenAIとClaudeを同じ関数で呼ぶコード例

公式のSDK Quickstartは、uv add litellmで導入し、completion()にモデル文字列とメッセージを渡す形を示しています。APIキーの読み取り元は、各社の既定の環境変数名（OPENAI_API_KEY、ANTHROPIC_API_KEY）です。次のコードは、同じメッセージを2社のモデルへ順に投げ、応答と1回あたりの料金を表示します。

# 事前に: uv add litellm
# 環境変数 OPENAI_API_KEY と ANTHROPIC_API_KEY を設定しておく
from litellm import completion, completion_cost

messages = [{"role": "user", "content": "LiteLLMを一文で説明してください。"}]

# モデル名は2026年10月時点の公式docsの記載例。利用時はプロバイダのページで現行IDを確かめる
for model in ["openai/gpt-6.1-sol", "anthropic/claude-sonnet-5"]:
    resp = completion(model=model, messages=messages, timeout=30)
    print(model, resp.choices[0].message.content)
    # 応答のトークン数と価格表からUSD換算した料金
    print(f"cost: ${completion_cost(completion_response=resp):.6f}")

応答はどちらもOpenAI形式のchoices[0].message.contentで取り出せます。Anthropicのモデル文字列の書き方はLiteLLMのAnthropicプロバイダのページに載っており、記載例はanthropic/claude-sonnet-5です。Claude側の単価やAPIキーの発行手順はAnthropic API（Claude API）の料金とAPIキー取得方法を参照してください。

completion_costで1リクエストごとの料金をドル単位で取得する方法

料金計算の仕組みはToken Usage and Costのページに書かれています。completion_cost()は応答のトークン数に、コミュニティで管理されている価格表model_prices_and_context_window.jsonの単価を掛けて返す仕組みで、金額の単位はUSDです。同じ値はresp._hidden_params["response_cost"]にも入ります。

この仕組みには注意点が2つあります。1つは、価格表に無いモデルや契約で単価が違うモデルは、litellm.register_model()でinput_cost_per_tokenとoutput_cost_per_tokenを自分で登録しないと金額がずれることです。もう1つは、閉じたネットワークでLITELLM_LOCAL_MODEL_COST_MAP="True"を設定すると同梱の価格表を使うため、価格改定を反映するにはLiteLLM本体の更新が必要になることです。

DockerでLiteLLM Proxyを起動しconfig.yamlへモデル登録する手順

model_listとos.environ記法でAPIキーを設定ファイルから分離する方法

Proxyの設定は1つのYAMLファイルにまとめます。公式のConfig.yamlのページによると、主なセクションはmodel_list・router_settings・litellm_settings・general_settingsの4つです。値にos.environ/変数名と書くと環境変数から読み込まれるため、APIキーをファイルに直書きせずに済みます。

# config.yaml
model_list:
  # 利用者が指定する名前（model_name）と、実際に呼ぶモデル（litellm_params.model）を分ける
  - model_name: chat-main
    litellm_params:
      model: openai/gpt-6.1-sol
      api_key: os.environ/OPENAI_API_KEY
      rpm: 300            # このデプロイへの1分あたりの上限リクエスト数
  - model_name: chat-backup
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  routing_strategy: simple-shuffle
  fallbacks: [{"chat-main": ["chat-backup"]}]   # chat-mainが失敗したらchat-backupへ

litellm_settings:
  num_retries: 2
  request_timeout: 30
  allowed_fails: 3
  cooldown_time: 30

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY   # sk-で始まる値にする
  database_url: os.environ/DATABASE_URL       # 仮想キーと支出記録の保存先（PostgreSQL）

ここで効くのはmodel_nameの付け方です。利用者にはchat-mainのような用途名だけを見せ、裏のモデルを差し替えてもアプリ側の改修が要らない状態にします。同じmodel_nameで複数のデプロイを並べると負荷分散の対象になり、振り分け方はrouting_strategyでsimple-shuffle・least-busy・usage-based-routing・latency-based-routingから選択できる仕組みです。vLLMで自前ホストしたモデルも、openai/接頭辞とapi_baseを指定すれば同じ一覧に並べられます。vLLM側の構築はvLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いで扱っています。

docker runでポート4000に立ち上げcurlで疎通を確かめるまでの手順

公式のProxy Quickstartは、公式イメージに設定ファイルをマウントしてポート4000で起動する手順を示しています。次の例では本番を想定してlatestではなく版を明示したタグにしています。タグ名はGitHubのリリース一覧で実在を確かめてから指定してください。

# 1. Proxyを起動する（タグは検証済みの版に固定する）
docker run -d --name litellm \
  -v "$(pwd)/config.yaml:/app/config.yaml" \
  -e OPENAI_API_KEY="$OPENAI_API_KEY" \
  -e ANTHROPIC_API_KEY="$ANTHROPIC_API_KEY" \
  -e LITELLM_MASTER_KEY="sk-長いランダム文字列" \
  -e DATABASE_URL="$DATABASE_URL" \
  -p 4000:4000 \
  docker.litellm.ai/berriai/litellm:<検証済みの版> \
  --config /app/config.yaml

# 2. OpenAI互換のエンドポイントへ用途名でリクエストする
curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "chat-main", "messages": [{"role": "user", "content": "疎通確認です"}]}'

応答が返れば、既存のOpenAI SDKもbase_urlをhttp://localhost:4000に変えるだけで同じProxyを呼べます。管理画面は/uiです。

フォールバックとリトライ・クールダウンで障害時の切替先を設定する方法

context_window_fallbacksなど3種類で失敗別に切替先を指定

公式のFallbacksのページは、切替先を失敗の種類ごとに3つの設定で分けています。

fallbacks：エラーやタイムアウトでリトライを使い切ったときの切替先
context_window_fallbacks：入力がモデルのコンテキスト長を超えたときの切替先
content_policy_fallbacks：プロバイダのコンテンツポリシーで拒否されたときの切替先

実務でまず入れるのはfallbacksだけで十分です。別の会社のモデルを切替先にしておくと、1社の障害やレート制限でサービス全体が止まる事態を避けられます。context_window_fallbacksを確実に効かせるには、router_settingsでenable_pre_call_checks: trueを指定し、送信前に長さを判定させる設定が必要です。なお、公式ページの例ではこれらのキーがrouter_settingsとlitellm_settingsの両方に登場します。導入する版のページで置き場所を確かめてから書いてください。

num_retriesとcooldown_timeの決め方と本番前に切替を試す方法

切替の手前で効くのがリトライとクールダウンです。num_retriesは同じmodel_name内での再試行回数、request_timeoutは1回の呼び出しの待ち時間（秒）です。allowed_failsを超えて失敗したデプロイは、cooldown_time秒のあいだ振り分け対象から外れます。公式例の値はnum_retries: 3・request_timeout: 10・allowed_fails: 3・cooldown_time: 30です。

値は利用者の待ち時間から逆算します。request_timeout: 30でnum_retries: 2なら、切替先に移るまでの待ち時間は、最悪で約90秒です。チャット画面のように利用者が待っている用途では、タイムアウトを短くしてリトライを減らすほうが体感はよくなります。

検証方法には落とし穴があります。mock_testing_fallbacksはSDKのRouterを直接呼ぶ場合だけの機能で、Proxy v1.85.0以降はProxyへのリクエストから取り除かれて効きません。Proxyでは、検証環境で切替元のAPIキーをわざと無効な値にするなどして実際のエラーを起こし、通常のリクエストで切替を確かめます。

仮想キーとPostgreSQLで部署別の予算上限とレート制限を設定する手順

master_keyとDATABASE_URLを揃えて仮想キーを発行するまでの手順

Proxyを共通窓口にする最大の理由が仮想キーです。各社の本物のAPIキーはProxyだけが持ち、利用者にはsk-で始まる仮想キーを配ります。公式のVirtual Keysのページによると、前提は2つです。DATABASE_URLでPostgreSQLを指定することと、sk-で始まるmaster_keyをgeneral_settingsまたは環境変数LITELLM_MASTER_KEYで設定することです。

# 部署用の仮想キーを発行する（予算は30日ごとに10米ドル、毎分100リクエスト・1万トークンまで）
curl -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "models": ["chat-main", "chat-backup"],
    "max_budget": 10,
    "budget_duration": "30d",
    "rpm_limit": 100,
    "tpm_limit": 10000,
    "metadata": {"department": "sales"}
  }'

# 発行したキーの支出（USD）を確認する
curl "http://localhost:4000/key/info?key=発行されたsk-キー" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

modelsで呼べる用途名を絞れるので、高額なモデルを一部の部署だけに開放することもできます。支出は呼び出しのたびにcompletion_cost()でUSD換算されて加算され、キー単位は/key/info、ユーザー単位は/user/info、チーム単位は/team/infoで確認できます。

max_budgetとrpm_limitで部署別の使い過ぎを止める設定値と注意点

公式のBudgets, Rate Limitsのページが定める挙動は次のとおりです。max_budgetはUSDの上限で、超えたキーのリクエストは失敗します。budget_durationは30s・30m・30h・30dの形式でリセット周期を決め、指定しなければ予算はリセットされません。キーにteam_idがあるときは、キー所有者の個人予算ではなくチームの予算が適用されます。

レート制限はrpm_limit（毎分のリクエスト数）、tpm_limit（毎分のトークン数）、max_parallel_requests（同時実行数）の3種類です。tpm_limitが数える対象はtoken_rate_limit_typeで入力・出力・合計から選べ、既定は合計です。

見落としやすいのは、予算の判定がPostgreSQLの支出記録に基づく点です。データベースを用意しない構成ではmax_budgetを書いても上限として働きません。

2026年3月のPyPI侵害事案から学ぶLiteLLM導入時の版の固定と確認項目

1.82.7と1.82.8に混入した認証情報窃取コードの影響範囲と対処

LiteLLM公式のセキュリティ告知によると、PyPIで配布されたlitellm==1.82.7と1.82.8に不正なコードが混入しました。2026年3月24日10時39分（UTC）から、PyPIに隔離されるまで約40分間公開されていた版です。混入したコードは環境変数・SSH鍵・AWSやGoogle Cloud・Azureの認証情報・Kubernetesのトークン・データベースのパスワードを集め、公式ではないドメイン（models.litellm[.]cloud）へ送信するものでした。1.82.8はlitellm_init.pthを追加しており、LiteLLMをimportしなくてもPythonの起動時に実行される作りでした。

公式Dockerイメージは依存関係を固定していたため影響を受けていません。修正版として新しいCI/CDで作られた1.83.0が公開されています。手元の環境は次のコマンドで確かめられます。

# 導入済みの版を確認する（1.82.7・1.82.8なら認証情報をすべて入れ替える）
pip show litellm | grep -i "^version"

# site-packages に litellm_init.pth が残っていないか探す
python -c "import site; print('\n'.join(site.getsitepackages()))" \
  | xargs -I{} find {} -maxdepth 1 -name "litellm_init.pth"

該当した場合はホスト上の認証情報をすべて入れ替え、CIやDockerビルドのログにも該当版の記録がないかを確かめます。

Dockerイメージの署名検証と版の固定で更新の速さに備える運用

LiteLLMは更新が速いOSSです。GitHubのリリース一覧では、2026年10月20日の1日だけで1.106.1・1.105.2・1.104.4・1.103.6の4つが公開されており、複数の系列へ修正を戻す運用になっています。最新版へ自動で追従すると、毎週のように挙動が変わる前提で動くことになります。

本番では次の3点を運用ルールにします。

Dockerイメージのタグを版で固定し、latestを使わない
リリース一覧が案内するcosignの公開鍵でイメージの署名を確かめる（告知によれば対象はv1.83.0-nightly以降のイメージ）
検証環境でフォールバックと予算の挙動を確認してから本番の版を上げる

SDKとして入れる場合もuv.lockなどで版とハッシュを固定します。各社のAPIキーを一手に握る部品なので、更新は人の確認つきの作業として扱います。

LiteLLMを採用する条件と見送る場面、Enterpriseとマネージドとの選び分け

OSS版で足りる構成とEnterpriseライセンスが必要になる機能の境目

OSS版のProxyで、モデル登録・フォールバック・仮想キー・キー単位の予算とレート制限まではそろいます。ログの可視化も、公式のLoggingのページにあるとおりlitellm_settingsのsuccess_callbackにlangfuseを指定し、LANGFUSE_PUBLIC_KEYとLANGFUSE_SECRET_KEYを設定すればログを送信できる仕組みです。Langfuse側の画面や評価機能はLangfuseとは？読み方・機能・使い方とLangSmithとの違いで解説しています。

境目は統制の機能です。公式のEnterpriseのページでは、Admin UIのSSOは5ユーザーまで無料で、それを超えるとライセンスが必要です。監査ログ、ロールベースのアクセス制御、IPアドレスによる制限、キーのローテーション、シークレットマネージャー連携、タグ別やモデル別の予算もライセンスキーで有効になる機能として並んでいます。同ページは対象を「100ユーザー超、または本番のAIユースケースが10件超」のチームとしています。

利用者が数十人までで監査ログを求められていないなら、OSS版で始めてかまいません。全社の窓口として運用し、誰がいつキーを変えたかの記録が要るなら、OSS版のまま監査機能を自作するのは割に合いません。

LiteLLMを見送るべき4つの場面と代わりに選ぶ構成の判断基準

LiteLLMを入れないほうがよい場面もはっきりしています。

使うモデルが1社だけで、切替の予定もない：プロバイダ公式SDKを直接使うほうが新機能への追従が早い
AWSの中で完結し、Bedrockのモデルだけで足りる：Amazon Bedrock Converse APIがモデル間の形式差を吸収し、IAMで権限を管理できる
コンテナとPostgreSQLを24時間運用する担当者がいない：Proxyが止まると全アプリのLLM呼び出しが止まるため、マネージド型のAIゲートウェイを選ぶ
各社固有の機能（独自のツール形式や最新のベータ機能）を初日から使いたい：互換層を通すと対応が遅れる、または変換で情報が落ちる場合がある

反対に、2社以上のモデルを併用し、部署ごとの費用上限とAPIキーの一元管理が必要で、コンテナ基盤を自社で持てるなら、LiteLLMのProxyは有力な選択肢です。社内のLLM基盤をどこまで自前で持つか、既存の業務システムとどうつなぐかを含めて検討する場合は、生成AI開発・AI受託開発で構成の設計から相談を受け付けています。

よくある質問

LiteLLMの導入を検討する段階でよく出る質問に答えます。

LiteLLMは無料で使えますか？

本体はライセンス表記がMITのOSSで、SDKもProxyも費用なしで使えます。モデルの利用料は各プロバイダへ支払い、ProxyのサーバーとPostgreSQLの費用も別にかかります。有料になるのは、6人目以降のSSOや監査ログなど、ライセンスキーで有効になる機能を使う場合です。

LiteLLMとLangChainは何が違いますか？

役割の層が違います。LiteLLMはモデル呼び出しの窓口をそろえ、切替・費用・レート制限を受け持ちます。LangChainはプロンプトの組み立て、RAG、エージェントの処理の流れを組むフレームワークです。両者は併用でき、LangChainからLiteLLM Proxyを呼ぶ構成も取れます。LangChainの全体像はLangChainとは？LLMアプリ開発フレームワークの仕組みで解説しています。

Ollamaなどのローカルモデルもつなげますか？

つなげます。OpenAI互換のAPIを持つ推論サーバーであれば、config.yamlのlitellm_paramsでopenai/接頭辞とapi_baseを指定することで登録が可能です。クラウドのモデルとローカルモデルを同じmodel_nameの一覧に並べ、機密データはローカル、それ以外はクラウドと使い分ける構成も組めます。ローカル側の準備はローカルLLMとは？必要スペック・Ollamaでの構築手順が参考になります。

予算を日本円で管理できますか？

LiteLLMのmax_budgetと支出記録はUSD建てです。円で管理したい場合は、社内レートで換算したUSD額を上限に設定し、/key/infoなどで取得したUSDの支出に同じレートを掛けて報告します。価格表に無いモデルや契約単価が違うモデルはregister_model()で単価を登録しないと金額がずれるため、月に1度はプロバイダの請求額と照合してください。