著者 LiteLLMを自己ホストしてLLMゲートウェイを作る方法
LiteLLMをVPSで運用し、OpenAI互換の1つのエンドポイントに集約します。仮想キー、キーごとの予算、フォールバック、固定イメージの設定方法を解説します。
自己ホスト型 LLM ゲートウェイの役割
LiteLLM は、自分でホストするオープンソースの LLM ゲートウェイです。すべてのアプリケーションが呼び出す 1 つの HTTP エンドポイントを提供し、各リクエストを応答すべきプロバイダーへ転送します。LLM は大規模言語モデルを意味します。このゲートウェイは OpenAI chat completions API（アプリケーションプログラミングインターフェース）に対応しているため、すでに OpenAI と通信しているクライアントライブラリであれば、変更するのは base URL と key の 2 つだけで利用できます。
この間接層こそが目的です。アプリケーションにプロバイダーの認証情報を保持させずに済みます。モデルの切り替えも、5 つのサービスのコードを変更するのではなく、サーバー上の設定ファイルの 1 行を変更するだけです。さらに、すべての呼び出しが 1 つのプロセスを通るため、予算を設定し、使用額の記録を保持する場所を確保できます。
起動すると、次の機能を利用できます。
- 1 つのエンドポイント。 アプリケーションは
https://gateway.example.com/v1を指定し、bulkやstrongのように自分で決めたモデル名を要求します。 - 仮想キー。 各アプリケーションに専用の key を割り当て、それぞれに利用可能なモデルの許可リストと支出上限を設定できます。1 つを無効にしても、ほかには影響しません。
- フォールバック。 呼び出しに失敗した場合やプロンプトが大きすぎる場合は、別のモデルに自動的に再試行します。
- ログに記録された履歴。 すべてのリクエストについて、コストを含む行を記録します。そのため、「どのアプリケーションが支出したのか」を確認できます。
自分でゲートウェイを運用する理由
マネージドルーターは、すべてのリクエストの中間に他者のプロセスが配置された同じ構成です。自分で運用すれば、プロバイダーのキーとプロンプトのテキストを、自分で管理するサーバーに置けます。ただし、コストも発生します。すべてのアプリケーションが依存するコンポーネントを、自分で運用する必要があるためです。このガイドの最後のセクションでは、そのコストを扱います。多くの解説で省かれている部分です。
必要なもの
- Docker と Compose plugin をインストールした Ubuntu 24.04 の VPS（仮想プライベートサーバー）。
- TLS（transport layer security）経由で外部のマシンからゲートウェイへ接続する場合は、VPS を指すドメイン名。
- プロバイダー API key を少なくとも 1 つ。
ゲートウェイは推論を実行しません。リクエストを転送し、応答をストリーミングで返します。そのため、CPU 負荷はモデルのサイズではなく、リクエスト量に応じて変化します。1 vCPU のサーバーでも、少数の内部アプリケーションであれば問題なく処理できます。増加するのはデータベースです。ゲートウェイはリクエストごとに支出レコードを 1 行書き込むためです。
まず config.yaml を作成する
設定ファイルは、クライアントが要求できるモデルを決めます。重要なのは、トップレベルにある model_list、litellm_settings、router_settings、general_settings の4つのセクションです。
model_list:
- model_name: bulk
litellm_params:
model: anthropic/claude-haiku-4-5
api_key: os.environ/ANTHROPIC_API_KEY
- model_name: strong
litellm_params:
model: anthropic/claude-sonnet-5
api_key: os.environ/ANTHROPIC_API_KEY
- model_name: strong
litellm_params:
model: openai/gpt-5.5
api_key: os.environ/OPENAI_API_KEY
litellm_settings:
num_retries: 2
request_timeout: 120
json_logs: true
set_verbose: false
router_settings:
allowed_fails: 3
cooldown_time: 30
fallbacks: [{"bulk": ["strong"]}]
context_window_fallbacks: [{"bulk": ["strong"]}]
general_settings:
background_health_checks: true
health_check_interval: 300model_name はクライアントが送信する名前です。litellm_params.model は実際のモデルで、provider/model の形式で記述します。モデルにはベンダー名ではなく、用途に基づく名前を付けてください。bulk を要求するアプリケーションは、来月 bulk を別のモデルに変更しても、そのまま動作します。
api_key: os.environ/ANTHROPIC_API_KEY は、LiteLLM に実行時にその変数を読み込ませます。リテラルのキーがファイル内に現れないため、config.yaml をコミットする場合に重要です。
意図的に strong という名前のエントリが2つあります。同じ model_name を持つデプロイメントが複数ある場合、ルーターはそれらを交換可能なものとして扱い、その名前へのリクエストを分散します。これにより、1つのプロバイダーに一時的な障害が発生しても strong は継続します。1つのデプロイメントがクールダウン状態になると（後述）、strong への新しいリクエストはもう一方へ送られます。
num_retries: 2 は、再試行可能なエラーを最大2回再試行します。同じモデルグループ内で利用可能な別のデプロイメントが、再試行先として選ばれる場合があります。2026-10-29 に確認した LiteLLM のアーキテクチャドキュメントでは、グループ内の再試行とグループ間のフォールバックは別の段階として説明されています。そのため、strong の再試行は、重み付きフェイルオーバーを有効にしなくても、別のプロバイダーに送られることがあります。フォールバックは、これらの再試行を使い切った後にのみ実行されます。
allowed_fails と cooldown_time はルーターのオプションであるため、router_settings の下に置きます。プロキシはこのセクションからルーターを構築します。v1.95.0 では、litellm_settings の下に記述した cooldown_time はルーターに届かないため、クールダウン期間は気付かないうちにデフォルトの5秒のままになります。cooldown_time: 30 は、クールダウン状態になったデプロイメントをローテーションから外す時間を指定します。設定リファレンスでは、allowed_fails を、cooldown_time の期間内にデプロイメントが超える必要がある失敗回数として説明しています。v1.95.0 のソースでは allowed_fails: 3 がデフォルト値です。このデフォルト値では、ルーターは組み込みのトリガーを使用し、失敗回数の設定は別の値を指定した場合にのみ有効になります。トリガーには、複数のデプロイメントがあるグループでの429応答時の即時クールダウン、そのようなグループで少なくとも5件のリクエストを受けた後、現在の1分間の失敗率が50%を超えた場合、さらに、不正なキーによる401など、ルーターが再試行しないエラーが含まれます。別のトリガーとして、単一のデプロイメントでも、現在の1分間のすべてのリクエストが失敗し、トラフィックが SINGLE_DEPLOYMENT_TRAFFIC_FAILURE_THRESHOLD に達するとクールダウンされます。デフォルトは1000件のリクエストです。プロバイダーが短時間に500エラーを連続して返すと、すべてのリクエストで試行され続けることはなくなります。一方、数分に1回だけ500エラーが発生しても、クールダウンは発生しません。
fallbacks と context_window_fallbacks には異なるトリガーがあり、後者は見落とされがちですが有用です。
fallbacksは、プライマリへの呼び出しが失敗したときに実行されます。context_window_fallbacksは、そのモデルのコンテキストウィンドウを超えているためにプロバイダーがリクエストを拒否したときに実行されます。これにより、大きすぎるプロンプトは呼び出し元にエラーを返す代わりに、収容できるモデルへ送られます。
content_policy_fallbacks もあります。これは、プロバイダーがコンテンツポリシーを理由に拒否した場合に使用します。そのリクエストを送る適切な宛先がある場合にだけ設定してください。
Docker Compose で VPS に LiteLLM をデプロイする
config.yaml、docker-compose.yml、.envの3つのファイルを格納するディレクトリを作成します。upstream のクイックスタートでは latest タグを取得します。代わりにリリースタグを固定してください。そうすれば、翌月に docker compose up -d を実行しても、今日と同じゲートウェイを使用でき、ロールバックも1行で行えます。
services:
litellm:
image: ghcr.io/berriai/litellm:v1.95.0
restart: unless-stopped
command: ["--config", "/app/config.yaml", "--num_workers", "1"]
ports:
- "127.0.0.1:4000:4000"
volumes:
- ./config.yaml:/app/config.yaml:ro
env_file: .env
depends_on:
db:
condition: service_healthy
db:
image: postgres:16
restart: unless-stopped
environment:
POSTGRES_USER: litellm
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in .env}
POSTGRES_DB: litellm
healthcheck:
test: ["CMD-SHELL", "pg_isready -U litellm"]
interval: 5s
timeout: 5s
retries: 10
volumes:
- postgres_data:/var/lib/postgresql/data
volumes:
postgres_data:この例では、Compose は .env を2回読み込みます。1回目は、compose ファイル内の ${POSTGRES_PASSWORD} を置換するためです。2回目は、env_file によってすべての変数をコンテナへ渡すためです。
v1.95.0 は 2026年8月時点の最新リリースでした。プロジェクトのリリースページを確認し、デプロイ時点で最新のタグを固定してください。各リリースには署名が付いているため、信頼する前にイメージを検証できます。
cosign verify --key https://raw.githubusercontent.com/BerriAI/litellm/v1.95.0/cosign.pub ghcr.io/berriai/litellm:v1.95.0ポートの行は 127.0.0.1:4000:4000 です。これにより、loopback インターフェースでのみポートを公開します。4000:4000 と記述すると、ゲートウェイはインターネット全体から到達可能になります。Docker は独自のルールを iptables の FORWARD チェーンに追加し、これらは ufw のルールより先に評価されるため、ufw deny 4000 では阻止できません。自己ホスト型ゲートウェイが公開状態になる原因として、これが最も一般的です。Docker が ufw を直接経由してコンテナポートを公開する方法を参照してください。外部からのネットワークトラフィックは、代わりにリバースプロキシ経由で到達します。
プロバイダーのキーをイメージから除外する
.envファイルにはすべての Secret が含まれます。これは実行時に環境変数として渡すため、イメージに組み込まれることはなく、コミットされることもありません。
LITELLM_MASTER_KEY=sk-REPLACE_ME
LITELLM_SALT_KEY=sk-REPLACE_ME_TOO
POSTGRES_PASSWORD=REPLACE_ME_AS_WELL
DATABASE_URL=postgresql://litellm:REPLACE_ME_AS_WELL@db:5432/litellm
STORE_MODEL_IN_DB=True
LITELLM_MODE=PRODUCTION
LITELLM_LOG=ERROR
ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-proj-...2 つの LiteLLM キーを安全な乱数で生成し、ファイルの権限を制限します。
printf 'sk-%s\n' "$(openssl rand -hex 32)"
chmod 600 .envLITELLM_MASTER_KEYは管理者用の認証情報です。管理 API の認証に使用し、/uiの Admin UI にログインするパスワードでもあります。アプリケーションがこの認証情報を保持することは絶対に避けてください。
LITELLM_SALT_KEYは、データベースに保存されるプロバイダー認証情報を暗号化します。1 度設定したら、そのまま変更しないでください。後から変更すると、すでに保存されている認証情報を復号できなくなります。その場合、ゲートウェイは正常に起動しますが、対象プロバイダーへのすべての呼び出しが認証エラーになります。
STORE_MODEL_IN_DB=Trueを使うと、config.yaml を変更せずに Admin UI からモデルを追加・編集できます。便利な一方で、正しい設定情報の参照元が 2 つに分かれます。どちらを正とするか決め、その判断を config の横に記録してください。
キーを設定ファイルから除外する理由は、エージェントに渡すツールからキーを除外する理由と同じです。AI エージェントからプロバイダーの Secret を除外するではこのパターンを説明し、Docker Compose の env ファイルと Secretでは具体的な方法を説明しています。
起動して、初回起動時のログを監視します。
docker compose up -d
docker compose logs -f litellm実際に動作していることを確認する
認証不要のプローブが2つ、認証が必要なプローブが1つあります。それぞれ失敗する理由が異なります。
curl -s http://127.0.0.1:4000/health/liveliness
curl -s http://127.0.0.1:4000/health/readiness/health/liveliness は認証不要で、プロセスの実行中は "I'm alive!" を返します。/health/readiness も認証不要です。"status": "healthy" と db フィールドを含む JSON オブジェクトを返し、データベースに接続できない場合は503を返します。監視対象には readiness を指定してください。liveliness は、ゲートウェイが仮想キーを1つも検索できない場合でも正常な状態を示し続けるためです。
認証付きチェックは、プロバイダーと通信するチェックです。
curl -s http://127.0.0.1:4000/health \
-H "Authorization: Bearer $LITELLM_MASTER_KEY"healthy_endpoints 配列と unhealthy_endpoints 配列を返します。unhealthy_endpoints にあるモデルで認証エラーが発生している場合、.env のプロバイダーキーが間違っているか、設定されていません。現在確認したいのはこの障害です。background_health_checks: true が設定されているため、プロキシはhealth_check_interval秒ごとに自動でこれらのプローブを実行します。/health は最後の結果を返すため、これをポーリングしても毎回プロバイダーへテストリクエストは送信されません。
仮想キーとキーごとの予算
各アプリケーションには、master key を使って発行した専用の key を割り当てます。
curl -s http://127.0.0.1:4000/key/generate \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H 'Content-Type: application/json' \
-d '{
"key_alias": "nightly-summariser",
"models": ["bulk"],
"max_budget": 5,
"budget_duration": "30d",
"rpm_limit": 60,
"tpm_limit": 200000
}'レスポンスには、key というフィールドが含まれます。このフィールドは sk- で始まります。その文字列がアプリケーションに渡されるものであり、アプリケーションが受け取るのはそれだけです。
modelsは、この key でリクエストできる対象の allowlist です。上記の key はbulkのみを要求でき、それ以外は要求できません。max_budget: 5とbudget_duration: "30d"の組み合わせでは、暦月あたり 5 US dollars です。LiteLLM は、timezoneをlitellm_settingsの下に設定しない限り、UTC の毎月 1 日 00:00 に30dの予算をリセットします。直近 30 日間の移動期間ではありません。そのため、key が 5 dollars を使い切ると、次の 1 日まで機能しなくなります。rpm_limitとtpm_limitは、この key 単体に対する 1 分あたりのリクエスト数と token 数の上限です。key_aliasは、6 週間後に spend log で確認する識別子です。必ず設定してください。
予算を使い切ると、呼び出しは budget_exceeded 型のエラーになり、メッセージは次の形式になります。
Budget has been exceeded! Key=<key> Current cost: <spend>, Max budget: <max_budget>status code は release によって異なります。固定している v1.95.0 では HTTP 429 です。v1.104.0 以降のデフォルトは HTTP 422 ですが、budget_exceeded_status_code: 429 を litellm_settings の下に設定すると以前の code に戻せます。実際の rpm_limit と tpm_limit による制限は、どちらの release でも 429 を返します。upgrade のたびに、どちらの code が返るか確認してください。
status code が分かりにくさの原因です。どちらの code にも「budget」とは示されないためです。client library は 429 を rate limit として報告し、リセットまで回復しない予算に対して backoff 付きの retry を実行することがあります。また、422 は処理できなかった request として報告されます。status code と並べて response body も log に記録してください。そうしないと、予算の枯渇を毎回別の問題として扱うことになります。
同じ management API を使って key を確認・変更できます。
curl -s "http://127.0.0.1:4000/key/info?key=sk-..." \
-H "Authorization: Bearer $LITELLM_MASTER_KEY"
curl -s -X POST http://127.0.0.1:4000/key/update \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H 'Content-Type: application/json' \
-d '{"key": "sk-...", "max_budget": 25}'gateway で適用する予算は、問題の原因が agent 自体にある場合でも有効です。そのため、VPS 上の AI agent の コスト管理の中核になります。
安価なモデルに一括処理を送る
クライアントの接続先をゲートウェイに設定します。ベース URL、キー、モデル名は次のとおりです。
curl -s http://127.0.0.1:4000/v1/chat/completions \
-H "Authorization: Bearer sk-<the virtual key>" \
-H 'Content-Type: application/json' \
-d '{
"model": "bulk",
"messages": [{"role": "user", "content": "Say hello in five words."}]
}'OpenAI クライアントライブラリはすべて同じように動作します。base_url に https://gateway.example.com/v1 を、api_key に仮想キーを設定します。
config.yaml のルーティングポリシーが、呼び出し元に意識させることなく適用されます。bulk へのリクエストは安価なモデルに送られます。この呼び出しが再試行後も失敗すると、リクエストは strong に対して再試行されます。プロンプトが bulk に対して長すぎる場合、context_window_fallbacks はエラーを返さず、代わりに strong へ送信します。分類処理や未処理の要約などの一括処理は、デフォルトで安価なモデルを使用します。コストが高くなるのは、難しいリクエストだけです。
ツールを使用するエージェントでは、ゲートウェイの利点が特に明確になります。同じ VPS 上の MCP（モデルコンテキストプロトコル）サーバーと、それを操作するエージェントの両方を1つのエンドポイントに接続できます。そのため、どちらも再デプロイせずに、背後で使用するモデルを変更できます。
フォールバックが発生したことをどう確認しますか？
この障害モードは、何も壊れていないように見えるため、コストが発生します。フォールバックが成功すると、HTTP 200 と通常のレスポンスボディが返ります。安価なモデルが 1 日停止していても、すべてのリクエストが気付かないうちに高価なモデルで処理され、最初に異常に気付くのは請求書ということがあります。
確認材料はレスポンスヘッダーに含まれています。取得してください。
curl -s -D - -o /dev/null http://127.0.0.1:4000/v1/chat/completions \
-H "Authorization: Bearer sk-<the virtual key>" \
-H 'Content-Type: application/json' \
-d '{"model":"bulk","messages":[{"role":"user","content":"ping"}]}' \
| grep -i '^x-litellm'x-litellm-model-groupは、リクエストのルーティング先として使われたモデル名です。例としてbulkなどがあります。x-litellm-model-idは応答したデプロイメントの ID で、/v1/model/info?litellm_model_id=...を使って照会できます。この ID が自分のbulkデプロイメントに含まれていない場合、フォールバックが発生しています。x-litellm-attempted-fallbacksとx-litellm-attempted-retriesが発生回数を示します。正常なリクエストでは、どちらも 0 を超えません。x-litellm-response-costは、そのリクエスト 1 回分の米ドルでのコストです。x-litellm-call-idは、同じリクエストをログから検索するために使う識別子です。
すべてのリクエストで x-litellm-attempted-fallbacks を記録し、0 を超えたときに必ずアラートを送信してください。この 1 つの値によって、ルーティングポリシーが正常に機能しているか、気付かないうちに「常に高価なモデルを使う」設定になっているかを判別できます。
より完全な方法はトレーシングです。専用の構成が必要になるため、詳細は エージェント呼び出しをトレーシングするセルフホスト Langfuse を参照してください。LiteLLM にはこのコールバックが含まれているため、認証情報を含めても設定は 2 行で済みます。
litellm_settings:
success_callback: ["langfuse"]
failure_callback: ["langfuse"]LANGFUSE_PUBLIC_KEY=pk-lf-...
LANGFUSE_SECRET_KEY=sk-lf-...
LANGFUSE_HOST=https://langfuse.example.comLangfuse v3 以降では、LiteLLM の Langfuse ページは現在 langfuse_otel プリセットを推奨しています。上記の langfuse コールバックも引き続きドキュメントに記載されています。failure_callback と success_callback の両方を設定してください。設定しないと、保持できるトレースは問題が発生しなかったリクエストだけになります。これとは別に、LiteLLM はリクエストごとに支出行を Postgres に書き込み、Admin UI の /ui がこのテーブルを読み取ります。トラフィックに応じて増加するため、容量の小さいディスクでは監視してください。
ゲートウェイをリバースプロキシの背後に置く
ホストの外部から port 4000 に到達できないようにします。nginx または Caddy で TLS を終端し、loopback アドレスへ転送します。
location / {
proxy_pass http://127.0.0.1:4000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off;
proxy_read_timeout 600s;
}この 2 行は省略されがちです。proxy_buffering off が重要なのは、ストリーミング形式の completion が server-sent events の連続として送信されるためです。nginx で buffering を有効にすると、転送前にチャンクをバッファへ蓄積するため、クライアントへの到着が遅れます。proxy_read_timeout 600s が重要なのは、nginx のデフォルト値である 60 秒が、レスポンス全体の制限ではなく、ゲートウェイからの 2 回の読み取りの間に待機する最長時間だからです。ストリーミングしない completion は生成が完了するまで何も送信しません。そのため、長い completion では 60 秒を超えても 1 バイトも到着せず、クライアントは 504 を受け取ります。このとき、エラーログには upstream timed out (110: Connection timed out) while reading response header from upstream が記録されます。チャンクを継続的に送信するストリーミング形式の completion は、60 秒を大幅に超えて実行できます。モデルからその時間だけデータが届かなかった場合にのみ、タイムアウトします。
証明書については、nginx で Certbot と Let's Encrypt を使う方法が最短です。すでに 1 台のホストで複数のコンテナを提供している場合は、複数の Compose アプリの前段に Traefik を置く方法でルーティングと証明書を一元管理できます。
ゲートウェイが単一障害点になりました
構築したものを正しく把握してください。現在、管理しているすべてのアプリケーションが、1 台の VPS 上にある 1 つのコンテナに依存しています。そのコンテナが停止している間は、正常に稼働しているプロバイダーを含め、どのモデルも呼び出せません。ここから、4 つの点が分かります。
- 不適切な設定が、すべてを同時に停止させます。
restart: unless-stoppedはクラッシュ時に再起動し、config.yaml を解析できないコンテナも繰り返し再起動します。設定を変更するたびにdocker compose logs litellmを確認し、変更時には動作を監視できる時間を確保してください。 - キャッシュミス時は、Postgres がリクエスト処理経路に入ります。 Virtual key の検索では、キーがキャッシュされていない場合に Postgres を使用します。利用量の記録はレスポンス後に非同期で実行されます。
/health/readinessが 503 を返す場合は、ゲートウェイは稼働しているものの、どちらの処理も実行できない状態だという警告です。 - まず CPU コアを使い切り、その後にインスタンスを追加します。 1 インスタンスにつき 1 worker というプロジェクトの本番運用ガイダンス（
--num_workers 1）は、Kubernetes などの pod autoscaler がインスタンスを自動追加する環境を前提としています。一方、この例のような単一 VM または単独のコンテナでは、マシンの vCPU 数に合わせて worker 数を設定します。上記の 1 vCPU の環境では、依然として--num_workers 1です。より大きな環境では worker 数を増やしてください。ただし、各 worker が個別にメモリを使用する点に注意してください。ロードバランサーの背後に 2 つ目のゲートウェイを配置すれば、単一コンテナへの依存をなくせます。ただし、データベースへの依存はなくなりません。 - 再生成できないものをバックアップします。 対象は
config.yamlと.env、およびデータベースのpg_dumpです。LITELLM_SALT_KEYを失うと、そのダンプ内にある暗号化されたプロバイダー認証情報を利用できなくなります。そのため、env ファイルとダンプは同じバックアップジョブに含めてください。off-box ストレージへの restic バックアップ
アップグレードでは、イメージタグを編集して docker compose up -d を実行します。LiteLLM はデフォルトで起動時に prisma migrate deploy を実行するため、新しいコンテナは初回起動時にデータベーススキーマを移行します。タグを変更する前にダンプを取得してください。古いイメージに戻しても、すでに実行された移行は元に戻りません。
使用するバージョンだけでなく、途中で飛ばすすべてのバージョンのリリースノートを確認してください。v1.95.0 から v1.104.0 以降へ移行すると、複数の破壊的変更をまたぐことになります。対象には、上記の予算関連のステータスコード、未設定・空・公開済みの master key があると起動を拒否するプロキシ、起動時のデータベースセットアップに失敗すると終了するプロキシが含まれます。restart: unless-stopped では、最後の問題は再起動ループとして現れます。v1.102.x 以前から移行する場合、v1.104.0 のリリースノートでは、2 つの LiteLLM_SpendLogs インデックスを自分で作成するよう求めています。
FAQ
LiteLLM はすべての呼び出しに目立つ遅延を追加しますか？
プロジェクトは、2026 年 10 月時点の README で、毎秒 1000 リクエスト時の 95 パーセンタイルが 8 ms であると公開しています。これはベンダーの公称値として扱ってください。実際の遅延に大きく影響するのは、アプリケーションとゲートウェイ間のネットワーク距離です。すべての呼び出しにラウンドトリップが 1 回追加されるためです。ゲートウェイは、呼び出し元のアプリケーションと同じリージョンで実行してください。そのうえで、実際のレスポンスに含まれる x-litellm-overhead-duration-ms ヘッダーを使い、自環境で追加遅延を測定します。
nginx を前段に置いた後、ストリーミングが動作しなくなったのはなぜですか？
nginx はデフォルトで upstream のレスポンスをバッファリングし、ストリーミングによる完了通知は server-sent events の連続だからです。proxy_buffering が有効だと、nginx はチャンクをバッファーに収集してから転送するため、クライアントへの配信が遅延します。location ブロックで proxy_buffering off; を設定してください。同じブロックで proxy_read_timeout も増やします。デフォルトでは、nginx はゲートウェイから 60 秒間データを受信しないとタイムアウトします。長い非ストリーミング生成ではこの時間に達しやすく、クライアントには 504 が返されます。
仮想キーの予算を使い切るとどうなりますか？
呼び出しは、タイプ budget_exceeded のエラーと、Budget has been exceeded! Key=<key> Current cost: <spend>, Max budget: <max_budget> の形式のメッセージで失敗します。固定した v1.95.0 ではステータスは HTTP 429 です。v1.104.0 以降のデフォルトは HTTP 422 です。どちらのコードにも予算を示す情報はありません。ここが注意点です。クライアントライブラリは 429 をレート制限として報告して再試行することがあり、その結果、メッセージを確認せずにスロットリングの調査を始めてしまいます。ステータスコードとともにレスポンスボディをログに記録してください。マスターキーを使って /key/info?key=sk-... でキーの実際の残額を確認し、予算が低すぎる場合は /key/update で上限を引き上げます。
ゲートウェイはホスト型モデルだけでなくローカルモデルにもルーティングできますか？
はい。model_list にもう 1 つエントリを追加します。ollama_chat/ プレフィックスと api_base を使用します。たとえば、model: ollama_chat/llama3.1 を api_base: http://ollama:11434 と併用します。Compose のデフォルトネットワークでは、コンテナ内の localhost はそのコンテナを指します。そのため、Compose のサービス名または Docker ネットワーク上のホストのアドレスを使用し、127.0.0.1 は決して使用しないでください。例外は、コンテナがホストとネットワークスタックを共有する host networking です。ローカルモデルの起動は別の作業です。VPS 上で Ollama を使って LLM をセルフホストするを参照してください。