vLLM Security は「self-host だから安全」という雑な安心を壊す

要点

要点まとめ

推論を自分の server へ移すと、データを外へ出しにくくはなるが、その代わりに「誰が叩けるか」「何で落ちるか」「どこへ外部接続できるか」を自分で守る責任が戻ってくる。
この docs は、その責任を速度の話の外へ押し出さず、公開 API、認証、負荷制御、外部 tool 接続までまとめて security surface として扱っている。
特に `--api-key` だけでは守りが薄く、network isolation や reverse proxy の前段制御が別に必要だと分かる。
さらに tool server や MCP までつなぐなら、単なる text generation server ではなく、外部行動を持つ serving system として境界を見直す必要がある。

続けて読む

読み終えたら次へ

この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。

同じ目的で読む 仕事で安全に使いたい

権限、秘密情報、監査、失敗時の扱いを確認したい人向け。

同じテーマで読む オープンソースAI

Hugging Face、OSS agent、モデル配布、ローカル実行。

次の記事 PagedAttention は LLM serving のボトルネックを「GPU不足」から「KV cache 運用」へ引き戻した

LLM server が遅いとき、原因は GPU の計算力だけではなく、会話途中のメモリをどう抱えるかで同時実行数が詰まることにもある。

読解

何が変わったのか

この docs は、vLLM を「ローカルで動く推論高速化ソフト」から「公開 API と外部接続を持つ serving system」として読み直させます。network isolation、configuration hardening、access control、resource exhaustion、tool server / MCP security まで章立てされており、推論品質とは別の運用責任を前面に出しています。具体的には、大きな `n` を投げる request が memory、CPU、GPU を食い潰す点と、それを `VLLM_MAX_N_SEQUENCES` で抑える考え方が示されています。また tool server は default off ですが、明示的に opt in すると external action surface が増えます。

日本の文脈

なぜ重要か

日本語圏では self-hosted LLM が「クラウドに出さないから安全」「API key を付けたから安心」という理解で止まりやすいです。しかし安全性は配置場所ではなく、境界設計で決まります。誰が endpoint に届くのか、逆プロキシで何を絞るのか、どの request が server を詰まらせるのかを自分で決めないと、むしろ危険になります。創業者や導入担当者にも重要です。vendor コストを減らしても、運用責任と監査責任は増えるからです。infrastructure choice を価格比較だけで決めないための資料になります。

技術ポイント

技術的ポイント

docs は security recommendations として network isolation、configuration best practices、access control を前面に置いています。endpoint を閉じたネットワークや reverse proxy の後ろに置く発想が基本です。
`VLLM_MAX_N_SEQUENCES` は、`/v1/completions` や `/v1/chat/completions` の `n` に上限をかけ、1 request が resource を食い尽くす blast radius を抑える環境変数です。
tool server と MCP は default で無効ですが、`--tool-server` で明示有効化すると external capability が増えます。便利さではなく exposure 増加として読むべきです。
OpenAI-compatible であることは security-compatible を意味しません。auth、rate limiting、request validation、audit logging は別に用意する必要があります。

用語

英日キーワード

英語	日本語	補足
self-hosted inference	自前推論運用	モデル推論 API を自分で運用する形。コストや主権の代わりに運用責任が増える。
reverse proxy	逆プロキシ	前段で認証、制限、検査をかける層。公開 endpoint の露出を減らす。
network isolation	ネットワーク分離	到達可能範囲を制限して露出を減らすこと。self-host では第一防御になる。
resource exhaustion	資源枯渇	1 件の request で CPU、GPU、memory を使い潰す状態。可用性事故の原因になる。
tool server	ツールサーバー	外部ツール呼び出しを受け持つ接続先。enable すると権限境界が広がる。
MCP security	MCP セキュリティ	MCP 連携時の認可、到達性、権限境界の設計。つながることと安全は別問題。

試す

試すなら

vLLM endpoint が今どこから到達できるかを書き出し、public exposure を前提にしない配置へ寄せる。
reverse proxy 側で auth、rate limit、request size 制限を入れ、vLLM 単体に全部背負わせない。
`VLLM_MAX_N_SEQUENCES` を workload に合わせて下げ、異常 request で server 全体が詰まらないかを試す。
tool server や MCP を使うなら、enable 前に「どの tool がどの network へ届くか」を棚卸しする。

注意

注意点

この page 自体は公開日や更新日を明示していません。将来の docs 変更や実装差分を前提に、手元の version と設定値で再確認したほうがよいです。
`--api-key` があるから十分、とはこの docs 自体の主張ではありません。前段制御を外す口実にしてはいけません。
self-host は data residency の議論を助けても、security 運用の手間を減らすわけではありません。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。