LiteLLMとは｜使い方とProxy設定・フォールバックを実機で検証

LLMのAPIは、会社ごとに書き方が違います。OpenAIは messages と Authorization: Bearer、Anthropicは x-api-key と max_tokens 必須、という具合です。LiteLLMはその違いを吸収し、アプリ側は1つの書き方のまま、裏で呼ぶ先だけを差し替えられるようにします。

flowchart TD
    A[自分のアプリ] --> S[LiteLLM SDK]
    T[チームの各アプリ] --> P[LiteLLM Proxy]
    S --> G[各社のAPI<br>OpenAI・Anthropic等]
    P --> G
    P --> L[自前のvLLM・Ollama]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の Python 3.13.18 で venv を作り、LiteLLM 1.106.6（PyPI で2026年10月28日公開）を入れました。入れる前に wheel の SHA-256 を PyPI に載っている値と照らし合わせ、中に .pth と sitecustomize.py が無いことを確かめています。Proxy は litellm[proxy]（FastAPI 0.162.0・uvicorn 0.54.0）、クライアントは openai 2.54.0 と curl 8.5.0 です。外部のLLMには一切接続せず、Python の標準ライブラリで作った OpenAI 互換（/v1/chat/completions・/v1/embeddings・/v1/models）と Anthropic 互換（/v1/messages）のモックを 127.0.0.1 に立て、ループバックしか無いネットワーク名前空間の中で、環境変数を空にして動かしました（外の名前が引けないことを curl で確かめています）。マシンは 2 CPU・メモリ 8GB で、ほかの作業と同時に動いています。容量の上限のため、[proxy] で入る任意のパッケージの一部（polars など）を外して動かしました。仮想キー（/key/generate）は PostgreSQL と Prisma のエンジンが要り、エンジンの取得先がこの環境のネットワークの方針で拒否されたため、DB なしで返るエラー原文を載せ、発行の手順は公式ドキュメントで確かめた範囲で書いています。Docker・管理画面（/ui）・各社の実際の API・有料プランの内容も公式ドキュメントの範囲です。1.107.0 の件は LiteLLM 公式ブログの告知で確かめました。図は mermaid-cli 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

LiteLLMとは（SDKとProxyの2つの使い方）

この節では、LiteLLMが何をするソフトで、SDKとProxyのどちらを使えばよいかが分かります。

LiteLLMは、BerriAI が開発しているオープンソースの「LLMの呼び出しをそろえる層」です。公式の README は「100以上のLLMプロバイダーを、1つの統一されたインターフェースで呼べるオープンソースのAIゲートウェイ」と説明しています。手元の 1.106.6 では、litellm.provider_list に166のプロバイダー名が入り、料金と上限の表（litellm.model_cost）には4,242件のモデルが載っていました。ライセンスは、パッケージの LICENSE によると MIT で、enterprise/ ディレクトリの中だけが別のライセンスです。

LiteLLMがしてくれることは、大きく4つです。

使い方は2通りあります。SDK は自分の Python のコードに import して使う形、Proxy は OpenAI 互換の API サーバーとして立てて、ほかのアプリから HTTP で呼ぶ形です。

なお「LLMそのもの」ではありません。LiteLLMはモデルを持たず、どこかで動いているLLMのAPI（クラウドのAPIや、自分で立てた vLLM・Ollama）へ中継するだけです。モデルを手元で動かしたい場合は、関連記事「vLLMとは｜使い方・インストール・OpenAI互換APIとOllamaとの違い」と関連記事「Ollamaの使い方｜ローカルLLMのコマンド一覧とAPIの呼び方」で扱っています。LiteLLMはその前に置く「窓口」です。

LiteLLMのインストールと安全な版の選び方

この節では、LiteLLMを pip で入れる手順と、2026年10月の改ざん事件を踏まえた版の決め方、入れた後の大きさと速さが分かります。

2026年10月21日、PyPI に公開された litellm 1.107.0 が攻撃者によって改ざんされていました。LiteLLM 公式ブログの告知によると、PyPI では UTC 11:39:51〜13:23 の間、7種類すべての wheel が影響を受け、Docker Hub と GHCR の v1.107.0・latest・main-latest・main-stable の各タグも一時的に置き換わっていました。中身は、Python が起動しただけで動く .pth ファイルから認証情報を集めて外へ送るものです。公式は「それ以前の版は安全で、問題の版は取り下げた」としたうえで、版を明示して固定するよう案内しています。2026年3月にも 1.82.7・1.82.8 が同じように改ざんされたことが報告されています（JFrog の解説）。

2026年10月29日時点で PyPI の最新の安定版は 1.106.6（10月28日公開）で、1.107.0 は一覧から消えていました。この記事は 1.106.6 で動かしています。入れる手順は次のとおりです。

手元で実行したコマンドと出力です。

$ python3 -m pip download --no-deps litellm==1.106.6 -d dl
Saved ./dl/litellm-1.106.6-cp310-abi3-manylinux_2_28_x86_64.whl
$ sha256sum dl/*.whl
ec3cae6c87971657c9ae905b6d23aef456e979c8848f22bbc5096a31e1a1da4d  dl/litellm-1.106.6-cp310-abi3-manylinux_2_28_x86_64.whl
$ curl -s https://pypi.org/pypi/litellm/1.106.6/json | python3 -c '...digests を表示...'
litellm-1.106.6-cp310-abi3-manylinux_2_28_x86_64.whl ec3cae6c87971657c9ae905b6d23aef456e979c8848f22bbc5096a31e1a1da4d
$ python3 -I -c "import zipfile,glob; n=zipfile.ZipFile(glob.glob('dl/*.whl')[0]).namelist(); print('files',len(n)); print([x for x in n if x.endswith('.pth') or 'sitecustomize' in x or '.data/' in x])"
files 3778
[]
$ python3 -m venv venv
$ venv/bin/pip install "dl/litellm-1.106.6-cp310-abi3-manylinux_2_28_x86_64.whl[proxy]"
$ venv/bin/pip show litellm | head -2
Name: litellm
Version: 1.106.6

uv を使う場合は、公式 README のとおり uv add litellm（Proxy は uv tool install 'litellm[proxy]'）で、ここでも ==1.106.6 のように版を固定します。uv でも pip でも、ロックファイルに版とハッシュが残る形にしておくと、CI で同じものを入れられます。

入れた後の大きさと速さを測りました。[proxy] 付きは、SDK だけの用途にはかなり大きくなります。

なお、SDK は import のたびに料金表（model_prices_and_context_window.json）を GitHub から取りに行きます。ソースの説明によると、環境変数 LITELLM_LOCAL_MODEL_COST_MAP=True で同梱の表だけを使うようにでき、litellm コマンド（Proxy）は最初から同梱の表を使います。外に出られない環境ではこの変数を付けておきます。以前の版にあった --telemetry オプションは、1.106.6 では「互換のために残した何もしないオプション」になっていました。

LiteLLMの使い方：completion()でOpenAIとAnthropicを同じ形で呼ぶ

この節では、LiteLLM SDK の基本の呼び方と、モデル名の書き方、ストリーミング・埋め込みの返り値が分かります。

model は「プロバイダー名/モデル名」で書きます。openai/ を付ければ OpenAI 互換の API、anthropic/ を付ければ Anthropic の Messages API の形に変換して送ります。api_base を指定すれば、送り先を自分のサーバーに変えられます。次のコードは、OpenAI 互換モックと Anthropic 互換モックを同じ書き方で呼んだものです。

from litellm import completion
msgs = [{"role": "user", "content": "LiteLLMとは何ですか"}]

r1 = completion(model="openai/mock-gpt", messages=msgs,
                api_base="http://127.0.0.1:18001/v1", api_key="sk-mock-openai")
print(type(r1).__name__, r1.choices[0].message.content)
print('usage', r1.usage.prompt_tokens, r1.usage.completion_tokens, r1.usage.total_tokens)

r2 = completion(model="anthropic/mock-claude", messages=msgs, max_tokens=100,
                api_base="http://127.0.0.1:18002", api_key="sk-mock-anthropic")
print(type(r2).__name__, r2.choices[0].message.content)
print('finish_reason', r2.choices[0].finish_reason)

for ch in completion(model="openai/mock-gpt", messages=msgs, stream=True,
                     api_base="http://127.0.0.1:18001/v1", api_key="sk-mock-openai"):
    print(repr(ch.choices[0].delta.content), end=' ')

ModelResponse [OpenAI互換モック/mock-gpt] 受け取った質問: LiteLLMとは何ですか
usage 12 20 32
ModelResponse [Anthropic互換モック/mock-claude] 受け取った質問: LiteLLMとは何ですか
finish_reason stop
'[OpenAI互換モック' '/mock-gpt] 受' 'け取った質問: LiteLLMとは何ですか' None

Anthropic 側のモックは stop_reason: "end_turn" と input_tokens・output_tokens を返していますが、LiteLLM を通すと finish_reason: "stop"、usage.prompt_tokens / completion_tokens に置き換わり、どちらも同じ ModelResponse になりました。モック側のログを見ると、送り先のパスも /v1/chat/completions と /v1/messages に正しく振り分けられています。

14:44:35.348 openai POST /v1/chat/completions model=mock-gpt -> 200
14:44:35.876 anthropic POST /v1/messages model=mock-claude -> 200
14:44:35.892 openai POST /v1/chat/completions model=mock-gpt -> 200
14:44:35.927 openai POST /v1/embeddings model=mock-emb -> 200

よく使うプロバイダー名を並べます。どれも 1.106.6 の litellm.provider_list に入っていることを確かめました。

表に載っている有名なモデル名なら、プロバイダー名を省いても推測されます（手元では gpt-4o は openai、claude-sonnet-4-5 は anthropic と判定）。ただし自分で付けた名前や表に無い名前は推測できず、後で出てくる LLM Provider NOT provided になります。迷ったら必ずプロバイダー名を付けるのが確実です。API キーは引数のほか、OPENAI_API_KEY・ANTHROPIC_API_KEY などの環境変数からも読まれます。キーはコードに直接書かず、環境変数か秘密情報の管理の仕組みから渡します。

非同期は acompletion()、埋め込みは litellm.embedding() です。埋め込みもモックへ /v1/embeddings で届き、[0.1, 0.2, 0.3] がそのまま返りました。テストでは mock_response="固定の応答" を渡すと、どこにも送らずに 0.01 秒で応答が返ります。

LiteLLMのリトライとタイムアウト（二重の再試行に注意）

この節では、LiteLLM のリトライが実際に何回送っているか、タイムアウトがどう効くかが、モックのログで分かります。

モックに「毎回429を返す」「毎回500を返す」「3回に2回503を返す」「5秒待ってから返す」モデルを用意し、num_retries を付けずに呼びました。

num_retries を付けていないのに、OpenAI 系は3回送っていました。例外の継承関係を見ると、litellm.RateLimitError は openai.RateLimitError を親に持ち、OpenAI 系の呼び出しは中で openai SDK を使っています。openai SDK は既定で2回まで再試行し、Retry-After も守るため、合わせて3回になります。ここに LiteLLM の num_retries=3 を足すと、最大で「LiteLLM の回数 × openai SDK の回数」まで増えます。一方、Anthropic 系は openai SDK を通らないので、529 は1回で例外になりました。

タイムアウトも同じで、timeout=2 でも、openai SDK の再試行が挟まって7.41秒かかりました。全体の待ち時間に上限を付けたいときは、つなぎ先ごとに max_retries: 0 を付けて openai SDK の再試行を止め、回数は LiteLLM の num_retries にまとめます。次の節の Router と Proxy の設定は、この形にしています。

待ち時間の決め方は関連記事「指数バックオフとは？リトライ間隔の決め方とジッターの実装」で、429・529 の扱いそのものは関連記事「LLM APIの429・529エラー対処｜リトライ実装とエラー一覧」で扱っています。

LiteLLMのフォールバックとロードバランス（Router）

この節では、Router を使って「落ちたら別のモデルへ」「複数のつなぎ先に振り分ける」を設定し、実際にどう動いたかが分かります。

Router は、model_name（アプリから呼ぶ名前）と、その裏の実際のつなぎ先（deployment）を対応させる仕組みです。同じ model_name を複数書けば振り分け、fallbacks に書けば失敗時の代わりになります。

from litellm import Router
OA = {"api_base": "http://127.0.0.1:18001/v1", "api_key": "sk-mock-openai"}
AN = {"api_base": "http://127.0.0.1:18002", "api_key": "sk-mock-anthropic"}
router = Router(
    model_list=[
        {"model_name": "main",   "litellm_params": {"model": "openai/mock-500", **OA, "max_retries": 0}},
        {"model_name": "backup", "litellm_params": {"model": "anthropic/mock-claude", **AN, "max_tokens": 100}},
        {"model_name": "lb",     "litellm_params": {"model": "openai/mock-gpt", **OA}},
        {"model_name": "lb",     "litellm_params": {"model": "anthropic/mock-claude", **AN, "max_tokens": 100}},
    ],
    fallbacks=[{"main": ["backup"]}],
    num_retries=1,
)
r = router.completion(model="main", messages=[{"role": "user", "content": "フォールバックの確認"}])

[main→backup] 8.58s [Anthropic互換モック/mock-claude] 受け取った質問: フォールバックの確認 | hidden api_base http://127.0.0.1:18002
[lb 20回の振り分け] {'[OpenAI互換モック': 11, '[Anthropic互換モック': 9}

モック側のログ
14:46:44.082 openai POST /v1/chat/completions model=mock-500 -> 500
14:46:47.188 openai POST /v1/chat/completions model=mock-500 -> 500
14:46:49.184 anthropic POST /v1/messages model=mock-claude -> 200

「main」は500を2回（初回＋num_retries=1）返したあと、「backup」の Anthropic 側へ切り替わり、アプリには正常な応答が返りました。ただし切り替わるまでに8.58秒かかっています（初回の呼び出しの準備と、再試行の間の待ち時間を含む）。フォールバックは「止まらない」ための仕組みで、「速く返す」仕組みではありません。応答時間を守りたいなら、主のほうの num_retries を減らし、timeout を短くします。

「lb」は同じ名前に2つのつなぎ先を書いたもので、20回呼ぶと11回と9回に分かれました。既定の振り分けはランダムに近い動きで、公式ドキュメントには最少の使用量・遅延の少なさなどで選ぶ方式（routing_strategy）も載っています。リトライ回数が尽きたのにフォールバック先が無いときは、次のように「フォールバックが設定されているのは main だけ」と教えてくれるメッセージになりました。

litellm.ServiceUnavailableError: ServiceUnavailableError: OpenAIException - mock-flaky: overloaded (call 8)
LiteLLM: model group 'flaky' failed with the error above and no fallback model group was found for it, so the request was not retried on another model. Fallbacks are configured for: main. Add a fallbacks entry for that model group (Router fallbacks or proxy router_settings.fallbacks) to retry on another model. LiteLLM Retried: 1 times, LiteLLM Max Retries: 1

使用量・料金の記録と予算（completion_cost・コールバック）

この節では、1回ごとのトークン数と料金の取り方、自分のモデルに単価を登録する方法、予算で止める方法が分かります。

料金は litellm.completion_cost() で計算できます。ただし、料金表に無いモデル名では計算できません。自作のモデル名で呼ぶと、次の例外になりました。

ModelNotMappedError This model isn't mapped yet. model=mock-gpt, custom_llm_provider=openai. Add it here - https://github.com/BerriAI/litellm/blob/main/model_prices_and_context_window.json.

社内の vLLM や、契約で単価が違うモデルは litellm.register_model()（Proxy では model_info）で単価を登録します。入力 12 トークン × 0.000003 ドル＋出力 20 トークン × 0.000015 ドル＝0.000336 ドルと、計算どおりの値が返りました。

import litellm
from litellm.integrations.custom_logger import CustomLogger
litellm.register_model({"openai/mock-gpt": {
    "input_cost_per_token": 0.000003, "output_cost_per_token": 0.000015,
    "litellm_provider": "openai", "mode": "chat"}})

class UsageLog(CustomLogger):
    def log_success_event(self, kwargs, response_obj, start_time, end_time):
        u = response_obj.usage
        print(kwargs.get('model'), u.prompt_tokens, u.completion_tokens,
              kwargs.get('response_cost'), (end_time - start_time).total_seconds())
    def log_failure_event(self, kwargs, response_obj, start_time, end_time):
        print(kwargs.get('model'), 'FAIL', type(kwargs.get('exception')).__name__)
litellm.callbacks = [UsageLog()]

登録後 completion_cost 0.00033600000000000004
('mock-500', 'FAIL', 'InternalServerError')
('mock-500', 'FAIL', 'InternalServerError')
('mock-claude', 'http://127.0.0.1:18002/v1/messages', 15, 25, 0.00042, 0.444)
('mock-gpt', 'http://127.0.0.1:18001/v1/', 12, 20, 0.00033600000000000004, 0.005)
成功 22 失敗 4 合計コスト 0.007896 合計トークン 784

コールバックには成功も失敗も届くので、上の Router の実験（フォールバック・振り分けを含む26回）を、そのまま「成功22・失敗4・合計0.007896ドル」と集計できました。失敗した呼び出しも記録に残るため、どのつなぎ先がどれだけ落ちたかも分かります。Langfuse などの観測ツールへ送る設定も用意されていて、送り方は関連記事「Langfuseとは｜使い方・料金・セルフホストとSDKの送信を実例で解説」で扱っています。

予算は2つの方法を試しました。SDK の litellm.max_budget は、1.106.6 のチャットの呼び出しでは加算されませんでした。0.0005 ドルにして3回呼んでも _current_cost は 0.0 のままで、ソースを見ると加算はテキスト補完の形の結果のときだけでした。効いたのは Router のつなぎ先ごとの max_budget と budget_duration です。1回0.00042ドルのモデルに0.001ドルの予算を付けると、3回目で超え、4回目から止まりました。

0 OK cost= 0.00042
1 OK cost= 0.00042
2 OK cost= 0.00042
3 ValueError No deployments available - crossed budget: Exceeded budget for deployment model_name: claude, litellm_params.model: anthropic/mock-claude, model_id: 597f9353…: 0.00126 >= 1d
4 ValueError No deployments available - crossed budget: …

超えたかどうかは呼ぶ前に判定するため、最後の1回で少し予算を超えます（0.001 に対して 0.00126）。また、この予算は既定ではプロセスのメモリで数えるので、プロセスを立て直すと0に戻ります。複数のプロセスで合わせて数えるには、公式ドキュメントのとおり Redis を設定します。利用者ごとの予算は、次の Proxy の仮想キーで管理します。

LiteLLM Proxyの使い方：config.yamlと起動

この節では、LiteLLM Proxy の設定ファイルの書き方と起動の手順、起動にかかった時間とメモリが分かります。

Proxy は litellm --config config.yaml で起動する OpenAI 互換の API サーバーです。設定ファイルには、model_list（呼び名とつなぎ先）、litellm_settings（SDK 全体の設定）、router_settings（フォールバック・振り分け）、general_settings（マスターキー・DB）を書きます。手元で使った設定です。

model_list:
  - model_name: gpt-main
    litellm_params:
      model: openai/mock-500
      api_base: http://127.0.0.1:18001/v1
      api_key: os.environ/MOCK_OPENAI_KEY
      max_retries: 0
  - model_name: claude-backup
    litellm_params:
      model: anthropic/mock-claude
      api_base: http://127.0.0.1:18002
      api_key: os.environ/MOCK_ANTHROPIC_KEY
    model_info:
      input_cost_per_token: 0.000003
      output_cost_per_token: 0.000015
  - model_name: gpt-mini
    litellm_params:
      model: openai/mock-gpt
      api_base: http://127.0.0.1:18001/v1
      api_key: os.environ/MOCK_OPENAI_KEY
      rpm: 3
    model_info:
      input_cost_per_token: 0.000003
      output_cost_per_token: 0.000015

litellm_settings:
  num_retries: 1
  request_timeout: 10
  drop_params: true
  use_chat_completions_url_for_anthropic_messages: true

router_settings:
  fallbacks:
    - gpt-main: ["claude-backup"]
  optional_pre_call_checks: ["enforce_model_rate_limits"]

general_settings:
  master_key: sk-local-master-1234

api_key: os.environ/変数名 と書くと、キーを設定ファイルに書かずに環境変数から読みます。マスターキーは公式ドキュメントのとおり sk- で始め、本番では長いランダムな値にします（環境変数 LITELLM_MASTER_KEY でも渡せます）。drop_params: true は、つなぎ先が対応していない引数を黙って落とす設定です。

$ MOCK_OPENAI_KEY=sk-mock-openai MOCK_ANTHROPIC_KEY=sk-mock-anthropic \
  litellm --config config.yaml --host 127.0.0.1 --port 14000
INFO:     Started server process [30808]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://127.0.0.1:14000 (Press CTRL+C to quit)
LiteLLM: Proxy initialized with Config, Set models:
    gpt-main
    claude-backup
    gpt-mini

既定のポートは 4000 で、公式のクイックスタートも 4000 を使っています（ここでは他と重ならないよう 14000 にしました）。--host を付けないと、すべてのネットワークインターフェースで待ち受けます。手元の PC で試すだけなら 127.0.0.1 を付けておくと、同じネットワークのほかの機器から呼ばれません。

Docker で動かす場合、公式のクイックスタートは docker.litellm.ai/berriai/litellm:latest のイメージに設定ファイルを /app/config.yaml として渡し、-p 4000:4000 で公開する手順です。1.107.0 の件では latest などの動くタグも置き換えられていたので、版の付いたタグかダイジェストで固定しておくと、意図しない版に入れ替わりません。

LiteLLM Proxyをcurlで呼ぶ（レスポンスヘッダーの読み方）

この節では、Proxy へ curl と OpenAI の SDK で送った実物と、応答に付く x-litellm- ヘッダーの意味が分かります。

$ curl -i http://127.0.0.1:14000/v1/chat/completions \
  -H 'Authorization: Bearer sk-local-master-1234' -H 'Content-Type: application/json' \
  -d '{"model":"gpt-mini","messages":[{"role":"user","content":"プロキシ経由のテスト"}]}'
HTTP/1.1 200 OK
content-type: application/json
x-litellm-call-id: c663bead-c85d-444b-bf20-6bea32a8f49d
x-litellm-model-name: openai/mock-gpt
x-litellm-model-api-base: http://127.0.0.1:18001/v1
x-litellm-version: 1.106.6
x-litellm-response-cost: 0.00033600000000000004
x-litellm-response-cost-input: 3.6e-05
x-litellm-response-cost-output: 0.00030000000000000003
x-litellm-key-spend: 0.00033600000000000004
x-litellm-response-duration-ms: 1901.0798931121826
x-litellm-overhead-duration-ms: 354.2299
x-litellm-model-group: gpt-mini
x-ratelimit-remaining-requests: 2
x-ratelimit-limit-requests: 3
x-litellm-attempted-retries: 0
x-litellm-attempted-fallbacks: 0

{"id":"chatcmpl-d0cb472e0370","model":"gpt-mini","object":"chat.completion","choices":[{"finish_reason":"stop","index":0,"message":{"content":"[OpenAI互換モック/mock-gpt] 受け取った質問: プロキシ経由のテスト","role":"assistant"}}],"usage":{"completion_tokens":20,"prompt_tokens":12,"total_tokens":32}}

ヘッダーを見れば、実際にどのつなぎ先へ送ったか（x-litellm-model-name・model-api-base）、1回の料金（response-cost）、Proxy 自身にかかった時間（overhead-duration-ms）、再試行とフォールバックの回数が分かります。主のモデルが落ちる「gpt-main」を呼ぶと、応答は Anthropic 側から返り、ヘッダーにフォールバックが1回と出ました。

HTTP/1.1 200 OK
x-litellm-model-name: anthropic/mock-claude
x-litellm-model-api-base: http://127.0.0.1:18002
x-litellm-response-cost: 0.00042
x-litellm-model-group: claude-backup
x-litellm-attempted-retries: 0
x-litellm-attempted-fallbacks: 1
（全体 2.98 秒。モックには mock-500 へ2回、mock-claude へ1回届いた）

OpenAI の公式 SDK からは、base_url を Proxy に変えるだけで使えます。呼び名に Anthropic 側の「claude-backup」を指定しても、OpenAI の形で返ってきます。

from openai import OpenAI
c = OpenAI(base_url="http://127.0.0.1:14000", api_key="sk-local-master-1234", max_retries=0)
r = c.chat.completions.create(model="claude-backup",
                              messages=[{"role": "user", "content": "OpenAI SDKからAnthropic側へ"}])
print(r.choices[0].message.content, r.usage.prompt_tokens, r.usage.completion_tokens)

[Anthropic互換モック/mock-claude] 受け取った質問: OpenAI SDKからAnthropic側へ 15 25
[stream] '[OpenAI互換モック' '/mock-gpt] 受' 'け取った質問: ストリーム'

Proxy の状態は GET /health（マスターキーが要る）で確かめられます。設定したつなぎ先へ実際に送ってみるため、落ちるモデルは unhealthy に出ました。

healthy 2 unhealthy 1
 NG openai/mock-500 litellm.InternalServerError: InternalServerError: OpenAIException - The server had an error while processing your reques…
 OK anthropic/mock-claude
 OK openai/mock-gpt

/health はつなぎ先に本物のリクエストを送るので、従量課金の API では呼ぶたびに少し料金がかかります。ロードバランサーの死活監視には、つなぎ先へ送らない /health/liveliness を使います。

LiteLLM Proxyの仮想キーとDB（PostgreSQLが要る）

この節では、仮想キー（Virtual Keys）で何ができ、何が要るのか、DB が無いときに返るエラーの原文が分かります。

仮想キーは、Proxy が発行する「利用者ごとの API キー」です。各社の本物の API キーは Proxy の中に置いたまま、利用者やチームには仮想キーだけを配り、キーごとに使えるモデル・予算（max_budget）・予算の期間（budget_duration）・有効期限（duration）・1分あたりの回数（rpm_limit）などを決められます。公式ドキュメントによると、仮想キーを使うには PostgreSQL の接続先を DATABASE_URL に設定し、マスターキーを sk- で始まる値にします。DB の操作には Prisma が使われます。

DB を付けずに起動した Proxy で試すと、次の原文が返りました。

$ curl -s -H 'Authorization: Bearer sk-local-master-1234' -H 'Content-Type: application/json' \
  http://127.0.0.1:14000/key/generate -d '{"models":["gpt-mini"],"max_budget":0.001,"duration":"1d"}'
{"error":{"message":"{'error': 'DB not connected. This endpoint needs a database; set DATABASE_URL to a PostgreSQL connection string (postgresql://...) to enable it. See https://docs.litellm.ai/docs/proxy/virtual_keys'}","type":"internal_server_error","param":null,"code":"500"}}

$ curl -s -H 'Authorization: Bearer sk-wrong' http://127.0.0.1:14000/v1/models
{"error":{"message":"No connected db.","type":"no_db_connection","param":null,"code":"400"}}

$ curl -s http://127.0.0.1:14000/v1/models
{"error":{"message":"Authentication Error, No api key passed in.","type":"auth_error","param":"None","code":"401"}}

DB なしの Proxy では、マスターキーしか通りません。違うキーを送ると「401」ではなく「No connected db.（400）」になるのは、マスターキーでなければ DB で仮想キーを探しに行くためです。DB を付けた後の発行は、公式ドキュメントでは次の形です（確認環境では DB を用意できなかったため、ここは実行していません）。

curl -X POST 'http://localhost:4000/key/generate' \
  -H 'Authorization: Bearer sk-（マスターキー）' -H 'Content-Type: application/json' \
  -d '{"models": ["gpt-mini"], "max_budget": 10, "budget_duration": "30d", "metadata": {"user": "taro"}}'
# 返ってきた "key": "sk-..." を利用者に渡す
curl 'http://localhost:4000/key/info?key=sk-（発行したキー）' -H 'Authorization: Bearer sk-（マスターキー）'
# info.spend に使った金額（ドル）が入る。止めるときは POST /key/block {"key": "..."}

公式ドキュメントでは、budget_duration を省くと設定の既定値が使われ、明示的に null を送ると予算が戻らないキーになる、と説明されています。また、公式のクイックスタートによると、管理画面（/ui）のユーザー名は admin、パスワードは既定でマスターキーで、キーの管理や使用量の表示は DB なしの構成では使えません。UI から各社のキーを登録する場合は、それを暗号化する LITELLM_SALT_KEY も設定し、後から入れ替えられない点に注意します。

LiteLLM ProxyのAnthropic形式（/v1/messages）とレート制限

この節では、Anthropic の形式で Proxy に送ったときの落とし穴と、モデルごとの回数制限を効かせる設定が分かります。

Proxy は OpenAI の形式だけでなく、Anthropic の Messages API と同じ /v1/messages も受け付けます。Anthropic の SDK や、Anthropic 形式で話すツールから、裏の OpenAI 互換モデルを呼べるということです。ところが最初の設定で、裏が openai/ のモデルを指定すると、404 になりました。

{"type":"error","error":{"type":"not_found_error","message":"litellm.NotFoundError: NotFoundError: OpenAIException - {\"error\": {\"message\": \"not found\"}}\n\nLiteLLM: model group 'gpt-mini' failed with the error above and no fallback model group was found for it, ..."}}

モック側のログ
14:54:26.950 openai POST /v1/responses model=mock-gpt -> 404

/v1/messages で受けたリクエストを、LiteLLM は OpenAI の Responses API（/v1/responses）に変換して送っていました。OpenAI 本体は Responses API を持っていますが、OpenAI 互換をうたう自前のサーバーやモックには無いことがあります。ソースを読むと、litellm_settings に次の1行を足すと、Chat Completions（/v1/chat/completions）へ送るように変わります。

litellm_settings:
  use_chat_completions_url_for_anthropic_messages: true

$ curl -s http://127.0.0.1:14000/v1/messages -H 'x-api-key: sk-local-master-1234' \
  -H 'anthropic-version: 2023-06-01' -H 'Content-Type: application/json' \
  -d '{"model":"gpt-mini","max_tokens":100,"messages":[{"role":"user","content":"Anthropic形式で送る"}]}'
{"id":"chatcmpl-f9184b5ad07c","type":"message","role":"assistant","model":"gpt-mini","stop_sequence":null,"usage":{"input_tokens":12,"output_tokens":20},"content":[{"type":"text","text":"[OpenAI互換モック/mock-gpt] 受け取った質問: Anthropic形式で送る"}],"stop_reason":"end_turn","stop_details":null}

OpenAI 互換モックの応答が、Anthropic の形（content の配列・stop_reason: "end_turn"・input_tokens）に変換されて返りました。自前のサーバーにつなぐときは「どのパスへ送っているか」をつなぎ先のログで確かめるのが近道です。

もう1つ、litellm_params の rpm: 3 は、書いただけでは止まりませんでした。最初の設定では4回続けて呼んで4回とも200です。rpm・tpm はもともと振り分けの判断に使う値で、超えたら断るには router_settings に optional_pre_call_checks: ["enforce_model_rate_limits"] を足します。足した後は、4回目から次の 429 になりました。

[rpm 0] 200 0.02s
[rpm 1] 429 RateLimitError 0.02s Error code: 429 - {'error': {'message': "litellm.RateLimitError: Model rate limit exceeded. RPM limit=3, current usage=4 ...

この回数は Proxy のプロセスのメモリで数えるため、Proxy を複数台に増やしたときは Redis の設定が要ります（公式ドキュメント）。

LiteLLMの速度と資源の実測（SDK・Proxyのオーバーヘッド）

この節では、LiteLLM を挟むとどれだけ遅くなるか、メモリと容量がどれくらい要るかが、同じマシンで測った数字で分かります。

同じ Anthropic 互換モックを、(A) httpx で直接、(B) LiteLLM SDK の completion()、(C) LiteLLM Proxy 経由、の3通りで30回ずつ呼び、かかった時間を比べました（準備の1回は除く）。

モックの応答そのものに約44ms かかる作りなので、見るべきは差です。SDK は数ms、Proxy は20ms 前後を足すだけで、数秒かかる LLM の応答に比べれば小さい差でした。気にするべきは遅延より資源で、Proxy 1プロセスでメモリ 326〜406MB、venv で 584MB でした。小さな VM やコンテナに載せるときは、この分を先に見込みます。

• 1版を == で固定したか1.107.0 は使わない。Docker も版の付いたタグで
• 2model にプロバイダー名を付けたかopenai/・anthropic/ など
• 3再試行を1か所にまとめたかmax_retries: 0 と num_retries
• 4自前のモデルに単価を登録したか無いと料金が数えられない
• 5Proxy の待ち受けを絞ったか--host 127.0.0.1 か、前段に認証付きの入口
• 6マスターキーを長いランダムな値にしたかsk- で始める。設定ファイルに直接書かない
• 7仮想キーを使うなら DB を用意したかPostgreSQL と DATABASE_URL

LiteLLMのよくあるエラーと直し方（原文つき）

この節では、手元で実際に出たエラーの原文から、原因と直し方を引けます。

表の RuntimeError: no running event loop は、予算付きの Router が作られるときに、バックグラウンドの処理を asyncio.create_task() で始めようとするために出ます。asyncio.run(main()) の main() の中で Router を作ると、4回目から予算で止まる、上の結果になりました。また、[proxy] の任意パッケージをそろえていない環境では、キーなしの呼び出しが 401 ではなく「Internal Server Error」（500）になることがありました。ログを見ると、DB のエラーかどうかを調べる処理が prisma を import しようとして失敗していたためで、prisma の Python パッケージを入れると 401 に戻りました。認証のエラーが 500 に見えたら、Proxy のログの最後の例外を確かめます。

LiteLLMとOpenRouter・各社SDKの判断表

この節では、LiteLLM を使うべきか、OpenRouter や各社の SDK を直接使うほうがよいかが、状況別に分かります。

OpenRouter はクラウドのサービスで、OpenRouter の1つの API キーで多くのモデルを呼べます。LiteLLM は自分の手元やサーバーで動かすソフトで、各社のキーは自分で持ちます。リクエストが通る場所（自社の中か、外のサービスか）と、運用を誰が持つかが大きな違いです。OpenRouter の使い方は関連記事「OpenRouterとは？使い方・料金・無料モデルとAPIキーの取り方」で扱っています。なお LiteLLM には openrouter/ というプロバイダー名もあり、両方を組み合わせることもできます。

入れる順番を段階で並べると、次のようになります。

1. 1各社の SDK を直接使う1社・1アプリなら、まずこれ
2. 2LiteLLM SDK の completion() に置き換える2社目を足したくなったとき
3. 3Router でフォールバックと振り分け429・障害で止まるのを避けたいとき
4. 4Proxy を DB なしで立てる複数のアプリ・言語から同じ窓口を使うとき
5. 5PostgreSQL を付けて仮想キー・予算人やチームごとに鍵と使用量を分けたいとき
6. 6Redis を付けて複数台に回数制限・予算を台数をまたいで数えたいとき

Proxy を自分で動かすということは、サーバーの更新・監視・鍵の管理を自分で持つということです。公式の有料版（Enterprise）には SSO や監査ログなどが用意されていて、内容と価格は公式サイトで案内されています。

よくある質問

Q. LiteLLMとは何ですか？ A. OpenAI・Anthropic・Gemini・Bedrock・vLLM など100以上のLLMのAPIを、OpenAI と同じ書き方で呼べるオープンソースの Python ライブラリと、OpenAI 互換のプロキシサーバーです。BerriAI が開発し、MIT ライセンス（enterprise/ 以下を除く）で公開されています。

Q. LiteLLMは無料で使えますか？ A. ソフト自体は無料です。ただし、つなぎ先の LLM の API 料金はそれぞれの会社に払います。Proxy を動かすサーバーや PostgreSQL の費用も別にかかります。SSO などが付く有料版もあります。

Q. LiteLLMのSDKとProxyはどちらを使えばよいですか？ A. Python のアプリ1つから呼ぶなら SDK、複数のアプリや Python 以外の言語から使う、鍵や予算をまとめて管理したい、なら Proxy です。Proxy の中でも SDK が動いているので、設定の考え方は同じです。

Q. litellm 1.107.0 を入れてしまったかもしれません。 A. 公式の告知では、まず pip show litellm で版を確かめ、site-packages に cook.pth・sitecustomize.py が無いかを見るよう案内しています。入っていた場合、その環境で pip や Python を先に動かさず、環境を作り直し、その機械から届いた認証情報（クラウド・API キー・マスターキー・DB のパスワードなど）を入れ替えるよう求めています。

Q. LiteLLMのProxyのポートは何番ですか？ A. 公式のクイックスタートでは 4000 番です。--port で変えられます。手元で試すときは --host 127.0.0.1 を付け、ほかの機器から呼ばれないようにします。

Q. 仮想キーにDBは必須ですか？ A. 必須です。公式ドキュメントのとおり DATABASE_URL に PostgreSQL を設定します。DB なしで /key/generate を呼ぶと「DB not connected. This endpoint needs a database」の 500 が返りました。DB なしでもマスターキーだけで使う構成は動きます。

Q. フォールバックとリトライの違いは何ですか？ A. リトライは同じモデルにもう一度送ること、フォールバックは別のモデル（別の会社）に切り替えることです。手元では、リトライを1回したあとフォールバックし、合わせて8.58秒（Proxy では2.98秒）かかりました。

Q. 料金が0やエラーになるのはなぜですか？ A. 料金表に無いモデル名で呼んでいるためです。自作の名前や社内の vLLM では ModelNotMappedError になったり、料金が数えられなかったりします。SDK は litellm.register_model()、Proxy は model_info に単価を書きます。

Q. LiteLLMは外部と通信しますか？ A. 呼んだ LLM の API のほか、SDK は import のときに GitHub から料金表を取りに行きます（LITELLM_LOCAL_MODEL_COST_MAP=True で止められます）。手元では、外に出られない環境で、この変数を付けて全部の動作を確かめました。

まとめ

• LiteLLM は、多数の LLM を OpenAI と同じ書き方で呼ぶライブラリ（SDK）とプロキシ（Proxy）。model は「プロバイダー名/モデル名」で書く。
• 2026年10月21日の 1.107.0 は改ざんされていた。版を == で固定し、wheel のハッシュと .pth の有無を確かめてから入れる。
• OpenAI 系は中の openai SDK も再試行する。max_retries: 0 と num_retries で回数を1か所にまとめる。
• Router の fallbacks で別モデルへ回せるが、切り替えまでの時間は延びる。予算はつなぎ先の max_budget、人ごとなら Proxy の仮想キー（PostgreSQL が要る）。
• Proxy の遅延は約+18ms と小さく、気にするべきはメモリ（326〜406MB）と、/v1/messages・rpm などの設定の落とし穴。

参考・出典

確認日はいずれも 2026年10月29日です。

• BerriAI「litellm」GitHub リポジトリ（README）：https://github.com/BerriAI/litellm
• PyPI「litellm」：https://pypi.org/project/litellm/
• LiteLLM Docs「Getting Started」：https://docs.litellm.ai/docs/
• LiteLLM Docs「Docker Quick Start」：https://docs.litellm.ai/docs/proxy/docker_quick_start
• LiteLLM Docs「Virtual Keys」：https://docs.litellm.ai/docs/proxy/virtual_keys
• LiteLLM Docs「Providers」：https://docs.litellm.ai/docs/providers
• LiteLLM Blog「Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised」：https://docs.litellm.ai/blog/security-incident-oct-21-2026
• LiteLLM Blog「The attack chain behind the v1.107.0 LiteLLM release」：https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain
• JFrog Security Research「LiteLLM Hijacked Again: Malicious 1.107.0 Wheels Steal Credentials and Load Remote Code」：https://research.jfrog.com/post/litellm-hijacked-again/
• litellm 1.106.6 のソースコード（litellm/litellm_core_utils/get_model_cost_map.py・litellm/proxy/proxy_cli.py・litellm/__init__.py）

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。