vLLMとは｜使い方・インストール・OpenAI互換APIとOllamaとの違い

アプリは OpenAI の API と同じ形で vLLM に頼み、vLLM が多くの依頼をまとめて GPU で処理します。

flowchart TD
    A[アプリ<br>OpenAI SDK・curl] -->|/v1/chat/completions| S[vllm serve<br>OpenAI互換API :8000]
    S --> Q[スケジューラー<br>連続バッチング]
    Q --> G[GPU<br>モデルの重み]
    Q --> K[KVキャッシュ<br>PagedAttention]

よく使うコマンドと設定を先にまとめます。

確認環境：Ubuntu 24.04.4・Python 3.11.15・openai（Python SDK）3.24.0・curl 8.5.0・Starlette 1.0.0・uvicorn 0.46.0。vLLM は 0.32.0（PyPI で 2026年10月18日公開）を対象に、GitHub の v0.32.0 タグのソースと同梱ドキュメント、docs.vllm.ai で、要件・オプションの既定値・エラー文の原文を確かめました。OpenAI 互換 API の呼び方は、vLLM 0.32.0 の認証ミドルウェア（authenticate.py）をそのまま組み込んだ擬似サーバーを立て、OpenAI SDK と curl から実際に送られたリクエストを記録しています。PagedAttention・連続バッチング・KV キャッシュの量は、Python で書いた小さな計算で確かめました。Ollama・llama.cpp・TGI の値は各公式ドキュメントで確認しました（確認日 2026年10月22日）。

vLLMとは：LLMを速く配るための推論サーバー

この節では、vLLM が何をするソフトで、誰が作り、何に使うのかが分かります。

vLLM（ブイエルエルエム）は、大規模言語モデル（LLM）の推論（文章の生成）とサービングを、速く・少ないメモリで行うための Python のライブラリ兼サーバーです。 GitHub の README は "a fast and easy-to-use library for LLM inference and serving" と説明しています。カリフォルニア大学バークレー校の Sky Computing Lab で生まれ、今は2,000人を超える貢献者がいるオープンソースのプロジェクトです。ライセンスは Apache License 2.0 で、vLLM 自体は無料で使えます（動かすモデルのライセンスは別に確かめます）。

中心の仕組みは、OS の仮想メモリの考え方を LLM のメモリ管理に持ち込んだ PagedAttention です（後の節で詳しく見ます）。

vLLMでできること・使う場面

Red Hat の解説は、vLLM が Hugging Face・LangChain・LlamaIndex・Docker・Kubernetes・KServe などと組み合わせて使えると紹介しています。OpenAI 互換の API なので、OpenAI 用に書かれたライブラリの多くは接続先を変えるだけでつながります。

読み方と、似た名前との見分け

「vLLM」は「ブイ・エル・エル・エム」と読みます。似た名前のものと混ざりやすいので、何を指すかを分けておきます。

vLLMが速い理由：PagedAttentionと連続バッチング

この節では、vLLM が他の作り方より多くの依頼をさばける2つの仕組みが分かります。

LLM は文章を1トークン（単語のかけら）ずつ作ります。そのたびに、それまでのトークンの計算結果（Key と Value）を KV キャッシュとして GPU のメモリに置いておき、次の計算で使い回します。LLM のサーバーの速さは、この KV キャッシュを GPU のメモリにどれだけ無駄なく詰められるかで大きく変わります。

PagedAttention：KVキャッシュをページに分けて置く

PagedAttention は、KV キャッシュを決まった大きさの「ブロック」に分け、ばらばらの場所に置けるようにする仕組みです。 公式ブログは "one can think of blocks as pages, tokens as bytes, and sequences as processes"（ブロックをページ、トークンをバイト、文章の列をプロセスと考える）と、OS の仮想メモリにたとえています。vLLM 0.32.0 のソースでは、ブロックの既定の大きさ（DEFAULT_BLOCK_SIZE）は16トークンです。

57トークンの依頼は、ブロック表を通して、空いている物理ブロック7・2・9・4にばらばらに置かれます（「16/16」は16トークン中いくつ使っているか）。

flowchart LR
    R[依頼<br>57トークン] --> T[ブロック表]
    T --> B1[物理7<br>16/16]
    T --> B2[物理2<br>16/16]
    T --> B3[物理9<br>16/16]
    T --> B4[物理4<br>9/16]

従来のやり方は、依頼ごとに「最大でこれだけ使うかもしれない」長さを先に連続で確保していました。公式ブログは、従来のシステムは断片化と確保しすぎでメモリの60〜80%を無駄にしていて、PagedAttention では無駄が4%未満になったと報告しています。

考え方を確かめるため、Python で小さな計算をしました（GPU は使わない仮の数字です）。KV キャッシュに置ける量を16,384トークン分とし、入力100〜800・出力30〜600トークンの依頼を、出力の上限1,024トークンで順に載せています。

import math, random

random.seed(300)
BLOCK = 16                    # vLLM の既定のブロックサイズ（トークン数）
CAPACITY = 16384              # KV キャッシュに置けるトークン数（仮の値）
MAX_TOKENS = 1024             # 1リクエストが出してよい最大のトークン数
reqs = [(random.randint(100, 800), random.randint(30, 600)) for _ in range(200)]

def fit(reserve):
    used = n = 0
    for p, o in reqs:
        r = reserve(p, o)
        if used + r > CAPACITY:
            break
        used += r; n += 1
    real = sum(p + o for p, o in reqs[:n])
    return n, used, real

for name, f in [
    ("最大長を先に連続で確保", lambda p, o: p + MAX_TOKENS),
    ("16トークンのブロックを必要な分だけ", lambda p, o: math.ceil((p + o) / BLOCK) * BLOCK),
]:
    n, used, real = fit(f)
    print(f"{name}: 同時 {n} 件 / 確保 {used:,} / 実際に使用 {real:,} / 無駄 {1-real/used:.1%}")

最大長を先に連続で確保: 同時 10 件 / 確保 15,553 / 実際に使用 8,304 / 無駄 46.6%
16トークンのブロックを必要な分だけ: 同時 22 件 / 確保 16,352 / 実際に使用 16,156 / 無駄 1.2%

同じメモリに載る依頼の数が増えると、1回の GPU の計算でまとめて処理できる数が増え、スループット（時間あたりの処理量）が上がります。 ブロック単位にすると、同じ文章で始まる依頼どうしでブロックを共有することもできます。vLLM ではこれがプレフィックスキャッシュ（enable_prefix_caching。0.32.0 の既定は有効）として使われ、同じシステムプロンプトを毎回送る使い方で計算を省けます。

連続バッチング：空いた席にすぐ次を入れる

連続バッチング（continuous batching）は、1トークン作るたびに、終わった依頼を外して待っている依頼を入れるやり方です。 静的なバッチングは、まとめた依頼が全部終わるまで次を入れません。Red Hat の解説は、各反復で終わった文章を新しい依頼に入れ替えることで、スループット・待ち時間・GPU の使用率がよくなると説明しています。

出力の長さが 120・15・30・200・25・40・10・60 トークンの8件を、同時に4件まで処理する条件で数えました（1ステップで各依頼が1トークン進む仮定）。

vLLM では、1回にまとめる依頼の数を --max-num-seqs、1回に処理するトークンの数を --max-num-batched-tokens で決めます。0.32.0 のソースでは、OpenAI 互換サーバーの既定は、メモリ70GiB未満の GPU で max_num_seqs 256・max_num_batched_tokens 2,048 でした。H100 のような70GiB以上の GPU（A100 を除く）では 1,024・8,192 に上がります。

論文（Kwon ほか「Efficient Memory Management for Large Language Model Serving with PagedAttention」、SOSP 2023）が元になっていて、README でも PagedAttention と連続バッチング・チャンク化したプレフィル・プレフィックスキャッシュが速さの理由として挙がっています。

vLLMの動作環境：GPU・OS・Pythonの要件

この節では、自分のパソコンやサーバーで vLLM が動くかどうかが分かります。

vLLM は Linux と GPU で動かすのが基本です。Windows はそのままでは動かず、WSL を使います。 vLLM 0.32.0 の同梱ドキュメントと PyPI の情報で確かめた要件です（2026年10月22日時点）。

GPU の Compute Capability（世代を表す番号）は、NVIDIA の一覧か nvidia-smi --query-gpu=name,compute_cap --format=csv で調べられます。

Windows・Mac・CPUだけで使えるか

GPU が無いパソコンで手軽に試すなら、llama.cpp や Ollama のほうが向いています。 違いは後の「Ollama・llama.cpp・TGIとの違い」の節で比べます。

vLLMのインストール（uv・pip・Docker）

この節では、vLLM を入れて、動くことを確かめるまでの手順が分かります。

コマンドをまとめると次のとおりです（公式のクイックスタートのとおり）。

# uv で入れる（推奨）
uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm download-kernels

# pip で入れる場合
pip install vllm --extra-index-url https://download.pytorch.org/whl/cu129
vllm download-kernels

--torch-backend=auto は、uv が入っている CUDA ドライバーの版を見て、合う PyTorch の配布元を選ぶ指定です。cu126 のように決め打ちもできます。環境を作らずに一度だけ試すなら uv run --with vllm vllm --help も使えます。

Dockerで動かす

公式の Docker イメージは vllm/vllm-openai です。ホストに NVIDIA Container Toolkit が要ります。

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

vllm serveの使い方：OpenAI互換APIサーバーを起動する

この節では、vLLM をサーバーとして起動し、どの URL で何が呼べるかが分かります。

vllm serve モデル名 で、OpenAI の API と同じ形のサーバーが http://localhost:8000 に立ち上がります。 モデル名は Hugging Face のリポジトリ名（Qwen/Qwen2.5-1.5B-Instruct など）か、手元のフォルダのパスです。

vllm serve Qwen/Qwen2.5-1.5B-Instruct \
  --api-key token-abc123 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.85

起動したら、モデルの一覧で動いていることを確かめます。

curl http://localhost:8000/v1/models -H "Authorization: Bearer token-abc123"

使えるエンドポイント

0.32.0 の同梱ドキュメントに載っている主な道（エンドポイント）です。

1つのサーバーが配るモデルは1つです。 公式の FAQ は、複数のモデルを1つのポートで配ることは今はできないので、モデルごとにサーバーを立て、前に振り分けの層を置くと答えています。

vllmのサブコマンド

オプションの説明は vllm serve --help=max-num-seqs のように1つずつ、--help=max のように言葉で探す、--help=all で全部、の3通りで見られます。

OpenAI互換APIの呼び方：curl・Python・ストリーミング

この節では、アプリから vLLM を呼ぶコードと、そのとき実際に送られる中身が分かります。

OpenAI の SDK は、base_url を vLLM のサーバーに向け、model に vLLM で起動したモデル名を書けば、そのまま使えます。 vLLM を --api-key なしで起動した場合、公式の例のように api_key="EMPTY" のような任意の文字列で通ります。

curl で呼ぶ

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer token-abc123" \
  -d '{
    "model": "Qwen/Qwen2.5-1.5B-Instruct",
    "messages": [{"role": "user", "content": "vLLMとは？"}],
    "max_tokens": 64,
    "temperature": 0.7
  }'

Python（OpenAI SDK）で呼ぶ

from openai import OpenAI, NotFoundError, AuthenticationError

client = OpenAI(base_url="http://127.0.0.1:30001/v1", api_key="token-abc123")

# 1. 普通に呼ぶ
r = client.chat.completions.create(
    model="Qwen/Qwen2.5-1.5B-Instruct",
    messages=[{"role": "system", "content": "日本語で短く答える。"},
              {"role": "user", "content": "vLLMとは？"}],
    max_tokens=128, temperature=0.7,
    extra_body={"top_k": 20, "repetition_penalty": 1.05},   # vLLM 独自の引数
    extra_headers={"X-Request-Id": "faq-0001"},
)
print(r.choices[0].message.content, r.usage.total_tokens)

# 2. ストリーミング
for chunk in client.chat.completions.create(
        model="Qwen/Qwen2.5-1.5B-Instruct",
        messages=[{"role": "user", "content": "こんにちは"}], stream=True):
    print(repr(chunk.choices[0].delta.content), end=" ")
print()

# 3. モデル名の間違い・キーの間違い
try:
    client.chat.completions.create(model="qwen2.5", messages=[{"role": "user", "content": "hi"}])
except NotFoundError as e:
    print("NotFoundError:", e)
try:
    OpenAI(base_url="http://127.0.0.1:30001/v1", api_key="EMPTY").models.list()
except AuthenticationError as e:
    print("AuthenticationError:", e)

top_k や repetition_penalty は OpenAI の API には無い、vLLM 独自の引数です。SDK では extra_body に入れます。X-Request-Id ヘッダーは、vLLM を --enable-request-id-headers 付きで起動すると使えます。

実際に送られたリクエスト（擬似サーバーで記録）

上のコードを、ポート 30001 で待つ擬似サーバーに向けて実行しました。擬似サーバーは推論をせず固定の文を返しますが、認証の部分は vLLM 0.32.0 の authenticate.py をそのまま組み込み、届いたリクエストを記録しています。

（擬似サーバーの固定の返事） 29
'' '（擬似サーバーの固定の返事）' None 
NotFoundError: Error code: 404 - {'error': {'message': 'The model `qwen2.5` does not exist. Valid aliases: Qwen/Qwen2.5-1.5B-Instruct.', 'type': 'NotFoundError', 'param': 'model', 'code': 404}}
AuthenticationError: Error code: 401 - {'error': 'Unauthorized'}

1つ目の呼び出しで、サーバーに届いた中身です。

{
 "method": "POST",
 "path": "/v1/chat/completions",
 "headers": {
  "authorization": "Bearer token-abc123",
  "accept": "application/json",
  "content-type": "application/json",
  "user-agent": "OpenAI/Python 3.24.0",
  "x-stainless-lang": "python",
  "x-stainless-package-version": "3.24.0",
  "x-request-id": "faq-0001"
 },
 "body": {
  "model": "Qwen/Qwen2.5-1.5B-Instruct",
  "messages": [
   {"role": "system", "content": "日本語で短く答える。"},
   {"role": "user", "content": "vLLMとは？"}
  ],
  "max_tokens": 128,
  "temperature": 0.7,
  "top_k": 20,
  "repetition_penalty": 1.05
 }
}

記録から分かったことです。

• extra_body の中身は、JSON の一番上の階層にそのまま混ざって送られます。 top_k と repetition_penalty が model と同じ並びに入っています。vLLM はこれを独自の引数として受け取ります。
• APIキーは Authorization: Bearer token-abc123 として送られます。OpenAI 本家に送るときと同じ形です。
• ストリーミング（stream=True）では、本文に "stream": true が足されるだけで、道は同じ /v1/chat/completions でした。
• キーが違う呼び出しは、401 を返した認証の層で止まり、アプリ側の記録には残りませんでした。 擬似サーバーが記録したのは3件（普通・ストリーミング・モデル名の間違い）だけです。

ストリーミングの応答の形

curl に -N を付けて、"stream": true で呼んだときの擬似サーバーの応答です。Server-Sent Events（data: で始まる行）で少しずつ届き、最後に data: [DONE] が来ます。

data: {"id": "chatcmpl-a55132a3612445f3", "object": "chat.completion.chunk", "created": 1792661715, "model": "Qwen/Qwen2.5-1.5B-Instruct", "choices": [{"index": 0, "delta": {"role": "assistant", "content": ""}, "finish_reason": null}]}

data: {"id": "chatcmpl-a55132a3612445f3", "object": "chat.completion.chunk", "created": 1792661715, "model": "Qwen/Qwen2.5-1.5B-Instruct", "choices": [{"index": 0, "delta": {"content": "（擬似サーバーの固定の返事）"}, "finish_reason": null}]}

data: {"id": "chatcmpl-a55132a3612445f3", "object": "chat.completion.chunk", "created": 1792661715, "model": "Qwen/Qwen2.5-1.5B-Instruct", "choices": [{"index": 0, "delta": {}, "finish_reason": "stop"}]}

data: [DONE]

認証の動き（vLLM 0.32.0 の認証ミドルウェア）

--api-key を付けて起動したときの動きを、curl で確かめました。

$ curl -i http://127.0.0.1:30001/health
HTTP/1.1 200 OK

$ curl -i http://127.0.0.1:30001/v1/models
HTTP/1.1 401 Unauthorized
content-length: 24
content-type: application/json

{"error":"Unauthorized"}

ソースでは、キーを確かめる道は /v1・/v2・/inference・/cohere で始まるものだけ（GUARDED_PREFIX）で、OPTIONS のリクエストも通します。キーはハッシュにしてから比べています。--api-key は「一部の道の入口の鍵」で、サーバー全体の守りではありません。 公開するときの守り方は「vLLMを安全に公開する」の節で扱います。

モデル名を合わせる：--served-model-name

model に書く名前は、vllm serve に渡した名前と一字一句同じにします。違うと、上の 404（The model ... does not exist. Valid aliases: ...）になります。長いリポジトリ名を短くしたいときは --served-model-name qwen を付けると、"model": "qwen" で呼べます。

既存のアプリが OpenAI のモデル名を決め打ちしている場合も、--served-model-name で同じ名前を付ければ、アプリのコードを変えずに向け先だけを vLLM に変えられます。

OpenAI の SDK の使い方は、関連記事「OpenAI API Python入門｜Responses APIのコピペ集」で扱っています。外部の多くのモデルを1つの API キーで切り替える使い方は、関連記事「OpenRouterとは｜使い方・APIキー・無料モデル・料金とコード例」で扱っています。

vllm serveの主なオプション早見表

この節では、起動するときに指定することが多いオプションと、0.32.0 での既定値が分かります。

既定値は v0.32.0 のソース（vllm/config/ と vllm/engine/arg_utils.py、vllm/entrypoints/launchers/cli_args.py）で確かめた値です。

そのほか、よく使うものです。

• --generation-config vllm：既定では、モデルの generation_config.json にある推奨値（temperature など）が使われます。vLLM の中立な既定値に戻すときに付けます。v0.8.0 で既定の出どころが変わりました。
• --chat-template：モデルのトークナイザーに入っていないチャットテンプレートを、ファイルで渡します。
• --trust-remote-code：モデルのリポジトリにある Python のコードを実行して読み込みます。中身を確かめたモデルだけに付けます。
• --download-dir：モデルを置く場所。既定では Hugging Face のキャッシュ（~/.cache/huggingface）です。
• --enable-lora：LoRA（追加学習した差分）を読み込めるようにします。

--max-model-len などの整数には 8k・32K のような書き方が使えます。 ドキュメントでは、小文字の k は1,000倍（8k＝8,000）、大文字の K は1,024倍（32K＝32,768）です。0.32.0 のソースでは --max-model-len auto（または -1）で、GPU のメモリに入る最大の長さを自動で選びます。

vLLMに必要なGPUメモリ：KVキャッシュの計算

この節では、あるモデルを動かすのに GPU のメモリがどれだけ要るかを、自分で見積もる方法が分かります。

GPU のメモリは「モデルの重み」と「KV キャッシュ」でほとんどが埋まります。 重みは、16ビット（bfloat16）なら「パラメーター数×2バイト」です。KV キャッシュは、1トークンあたり「2（Key と Value）×層の数×KV ヘッドの数×ヘッドの次元×2バイト」で、文脈が長いほど、同時の依頼が多いほど増えます。

モデルの config.json の値から計算しました。

GiB = 1024 ** 3

def kv_per_token(layers, kv_heads, head_dim, dtype_bytes=2):
    return 2 * layers * kv_heads * head_dim * dtype_bytes   # 2 = Key と Value

models = {
    # 名前: (層の数, KVヘッド数, head_dim, パラメーター数, 既定の max_model_len)
    "Qwen2.5-1.5B-Instruct": (28, 2, 1536 // 12, 1.54e9, 32768),
    "Qwen3-8B": (36, 8, 128, 8.2e9, 40960),
}
for name, (L, H, D, P, ctx) in models.items():
    t = kv_per_token(L, H, D)
    print(f"[{name}]")
    print(f"  KV/トークン       : {t:,} バイト ({t/1024:.0f} KiB)")
    for n in sorted({2048, 8192, 32768, ctx}):
        print(f"  1リクエスト {n:>6,} トークン: {t*n/GiB:6.3f} GiB")
    print(f"  重み(bf16)        : {P*2/GiB:6.2f} GiB")

print("\n[Qwen3-8B を 24 GiB の GPU 1枚で動かす目安]")
L, H, D, P, ctx = models["Qwen3-8B"]
t = kv_per_token(L, H, D)
for util in (0.92, 0.85):
    budget = 24 * GiB * util
    kv = budget - P * 2
    print(f"  util={util}: 使える {budget/GiB:5.2f} GiB - 重み {P*2/GiB:5.2f} = 残り {kv/GiB:4.2f} GiB"
          f" → {kv//t:,.0f} トークン分（40,960トークンの会話 {kv/(t*ctx):.2f} 本分）")

[Qwen2.5-1.5B-Instruct]
  KV/トークン       : 28,672 バイト (28 KiB)
  1リクエスト  2,048 トークン:  0.055 GiB
  1リクエスト  8,192 トークン:  0.219 GiB
  1リクエスト 32,768 トークン:  0.875 GiB
  重み(bf16)        :   2.87 GiB
[Qwen3-8B]
  KV/トークン       : 147,456 バイト (144 KiB)
  1リクエスト  2,048 トークン:  0.281 GiB
  1リクエスト  8,192 トークン:  1.125 GiB
  1リクエスト 32,768 トークン:  4.500 GiB
  1リクエスト 40,960 トークン:  5.625 GiB
  重み(bf16)        :  15.27 GiB

[Qwen3-8B を 24 GiB の GPU 1枚で動かす目安]
  util=0.92: 使える 22.08 GiB - 重み 15.27 = 残り 6.81 GiB → 49,562 トークン分（40,960トークンの会話 1.21 本分）
  util=0.85: 使える 20.40 GiB - 重み 15.27 = 残り 5.13 GiB → 37,328 トークン分（40,960トークンの会話 0.91 本分）

層の数・KV ヘッドの数・ヘッドの次元は、各モデルの config.json（Qwen2.5-1.5B-Instruct は 28・2・128、Qwen3-8B は 36・8・128）、パラメーター数はモデルカード（1.54B・8.2B）の値です。実際には、計算の途中の値や CUDA グラフにもメモリを使うので、残りはこの計算より少なくなります。

読み取れることです。

• Qwen3-8B は、config.json の max_position_embeddings が 40,960 なので、何も指定しないと1件で 5.625 GiB の KV キャッシュを前提にします。 24 GiB の GPU で --gpu-memory-utilization 0.85 にすると、計算上1件分も入りません。これが後で見る「To serve at least one request with the model's max seq len」のエラーです。
• --max-model-len 8192 にすると、1件分は 1.125 GiB で、残りの 6.81 GiB に6件分が入ります。長い文脈が要らない用途なら、--max-model-len を縮めるのがいちばん効きます。
• KV ヘッドが少ないモデル（Qwen2.5-1.5B は2個）は、1トークンあたりの KV キャッシュが小さくなります（GQA という作り）。

モデルの大きさとGPUの目安

重み（16ビット）の大きさを「パラメーター数×2バイト」で計算した表です。KV キャッシュ用に、これより余裕のある GPU が要ります。

4ビットの列は「パラメーター数×0.5バイト」で計算した重みだけの目安で、量子化の方式によって増えます。vLLM の量子化のドキュメントには、AWQ・GPTQ・bitsandbytes・FP8（W8A8）・INT4（W4A16）などが並んでいます。GGUF も読めますが、ドキュメントでは "highly experimental and under-optimized" とされています。

vLLMのよくあるエラーと直し方

この節では、vLLM を起動・利用したときに出るエラーの原文から、原因と直し方を引けます。

原文は v0.32.0 のソースのメッセージの書き方そのままで、数値の部分は状況によって変わります（〈 〉 の部分）。

1行目の原文は、vLLM のフォーラムに投稿された例の一部（"GPU 0 has a total capacity of 15.47 GiB of which 52.94 MiB is free." と続く）です。

CUDA out of memoryの直し方の順番

GPU のメモリ不足は、効きやすく副作用の小さいものから順に試します。公式ドキュメント「Conserving Memory」とソースの既定値をもとにした順番です。

起動・ダウンロードで止まるとき

さらに詳しく調べるときは、VLLM_LOGGING_LEVEL=DEBUG でログを増やし、vllm collect-env で環境の情報を集めます。

外部の LLM API で 429 などが返ったときの再試行の書き方は、関連記事「LLM APIの429・529エラー対処｜リトライ実装とエラー一覧」で扱っています。

vLLMを安全に公開する

この節では、vLLM のサーバーを社内やインターネットに公開するときに確かめることが分かります。

--api-key は /v1 などの一部の道だけを守ります。 vLLM のセキュリティのドキュメントは、--api-key だけに頼らず、リバースプロキシで公開する道を絞るよう勧めています。また、分散処理で使う torch.distributed は既定ですべてのネットワークの口で待ち受けるため、API サーバーのポート以外をファイアウォールで閉じるよう書かれています。

• 1vLLM のポートを直接インターネットに開けていないリバースプロキシの内側に置き、外から届くのはプロキシだけにする
• 2プロキシで、使う道（/v1/chat/completions など）だけを通しているドキュメントは、キーで守られない道があると明記している
• 3API キーを付け、ソースや設定ファイルに直接書いていない環境変数 VLLM_API_KEY でも渡せる
• 4分散処理の通信用のポートを、信頼できる相手だけに絞っているtorch.distributed は既定で全部の口で待ち受ける
• 5本番で VLLM_SERVER_DEV_MODE=1 を設定していない開発用の操作の道が開く。ドキュメントは本番で使わないよう強く書いている
• 6--trust-remote-code は中身を確かめたモデルだけに付けているモデルのリポジトリの Python コードが実行される

nginx を前に置く設定は、関連記事「Nginxリバースプロキシ設定｜proxy_passの書き方と502/504対処」で扱っています。生成に時間がかかる API では、nginx の proxy_read_timeout（既定60秒）とストリーミングの扱いも確かめます。

vLLMとOllama・llama.cpp・TGIの違い

この節では、似た目的のツールとの違いと、どれを選ぶかが分かります。

各公式ドキュメント・README の記載をもとにした比較です（2026年10月22日時点）。

TGI（text-generation-inference）のドキュメントには、"text-generation-inference is now in maintenance mode" とあり、今後は vLLM・SGLang、手元向けには llama.cpp や MLX を勧めると書かれています。

どれを選ぶかの判断表

どれも OpenAI 互換の API を持つので、アプリ側は base_url とモデル名を変えるだけで行き来できます。 手元では Ollama で作り、本番は vLLM で配る、という組み合わせも取れます。Ollama のコマンドと API は、関連記事「Ollamaの使い方｜ローカルLLMのコマンド一覧とAPIの呼び方」で扱っています。

Pythonから直接使う：オフライン推論（LLMクラス）

この節では、サーバーを立てずに、Python のプログラムの中で vLLM を使う書き方が分かります。

大量の文章をまとめて処理するだけなら、vllm serve を立てずに LLM クラスを使えます。 公式のクイックスタートの例です。

from vllm import LLM, SamplingParams

prompts = [
    "Hello, my name is",
    "The capital of France is",
]
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)

if __name__ == "__main__":
    llm = LLM(model="facebook/opt-125m")
    outputs = llm.generate(prompts, sampling_params)
    for output in outputs:
        print(f"Prompt: {output.prompt!r}, Generated text: {output.outputs[0].text!r}")

if __name__ == "__main__": の中で LLM を作ります。 トラブルシューティングのドキュメントによれば、そうしないと、子プロセスの起動の方式（spawn）によって RuntimeError: An attempt has been made to start a new process before the current process has finished its bootstrapping phase. が出ることがあります。

vLLM を RAG（検索で集めた文書を LLM に渡す仕組み）の土台に使う作り方は、関連記事「RAGの作り方｜Pythonで動かす最小構成と精度の上げ方」で扱っています。base_url を vLLM に向ければ、OpenAI の SDK を使う部分はそのまま動きます。

よくある質問

Q. vLLMとは何ですか？ A. LLM の推論とサービングを、速く・少ないメモリで行うオープンソースのエンジンです。vllm serve で OpenAI 互換の API サーバーになります。仕組みは「vLLMが速い理由：PagedAttentionと連続バッチング」の節にあります。

Q. vLLMの使い方を一言でいうと？ A. uv pip install vllm --torch-backend=auto で入れ、vllm serve モデル名 で起動し、OpenAI の SDK の base_url を http://localhost:8000/v1 にして呼びます。

Q. vLLMはGPUなしで動きますか？ A. CPU 版があり、x86（AVX512 推奨）・ARM・Apple シリコンで動きます。ただし本来の強みは GPU での同時処理で、手元で手軽に試すなら Ollama や llama.cpp が向いています。

Q. vLLMはWindowsで使えますか？ A. 公式は Windows をそのままではサポートしていません。ドキュメントは WSL（Windows 上の Linux）に入れる方法を案内しています。

Q. vLLMとOllamaの違いは何ですか？ A. vLLM は Linux と GPU のサーバーで多くの依頼を同時にさばく作り、Ollama は手元のパソコンで手軽に動かす作りです。Ollama の OLLAMA_NUM_PARALLEL の既定は1です。どちらも OpenAI 互換の API を持ちます。

Q. vLLMはOllamaより速いですか？ A. 同時の依頼が多いほど差が出やすい作りです。Ollama の既定の並列数は1、vLLM は連続バッチングで既定256件（70GiB未満の GPU のサーバー）までまとめます。1件ずつの速さはモデル・量子化・GPU で変わるため、vllm bench などで自分の環境で測ります。

Q. Ollamaとllama.cppの違いは何ですか？ A. llama.cpp は C/C++ で書かれた推論のエンジンと llama-server です。Ollama の README は対応するバックエンドとして llama.cpp を挙げていて、そのうえにモデルのライブラリ（ollama pull）や常駐のサーバーを持ちます。

Q. PagedAttentionとは何ですか？ A. KV キャッシュを16トークンなどのブロックに分け、OS の仮想メモリのページのように、ばらばらの場所に必要な分だけ置く仕組みです。確保したのに使わない領域が減り、同じメモリに多くの依頼が載ります。

Q. CUDA out of memoryが出たらどうしますか？ A. 他に GPU を使うプロセスを止め、--max-model-len・--max-num-seqs を下げ、量子化モデルや --enforce-eager、--tensor-parallel-size を順に試します。「CUDA out of memoryの直し方の順番」にまとめています。

Q. gpu-memory-utilizationは何を決めますか？ A. GPU のメモリのうち、その vLLM が使ってよい割合です。0.32.0 の既定は 0.92 で、モデルの重みを引いた残りが KV キャッシュになります。1枚の GPU で vLLM を2つ動かすなら、それぞれ 0.5 などにします。

Q. vLLMは商用利用できますか？ A. vLLM のコードは Apache License 2.0 です。動かすモデルは、モデルごとのライセンス（商用利用の可否・条件）を別に確かめます。

Q. 複数のモデルを1つのvLLMで配れますか？ A. 公式の FAQ では、1つのサーバーが配るモデルは1つです。モデルごとにサーバーを立て、前に振り分けの層を置きます。LoRA の差分なら --enable-lora で1つのサーバーから配れます。

まとめ

• vLLM は、LLM を GPU で速く動かし、OpenAI 互換の API として配るオープンソースの推論サーバー。0.32.0 は Python 3.11〜3.14・Linux が基本。
• 速さの元は、KV キャッシュを16トークンのブロックで管理する PagedAttention と、空いた席にすぐ次の依頼を入れる連続バッチング。小さな計算でも、同じメモリに載る依頼が10件から22件に増えた。
• vllm serve モデル名 で :8000 に API が立つ。OpenAI SDK は base_url を変えるだけで使え、vLLM 独自の引数は extra_body で JSON の一番上に混ざって送られる。
• --api-key は /v1 などの一部の道だけを守る。公開するときはリバースプロキシで道を絞る。
• メモリ不足は、まず --max-model-len を用途に合わせて縮める。KV キャッシュは「2×層×KV ヘッド×次元×2バイト×トークン数」で見積もれる。
• 手元で手軽に試すなら Ollama・llama.cpp、同時に多くの依頼をさばくサーバーなら vLLM。どれも OpenAI 互換なので、アプリ側の変更は小さい。

参考・出典

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

• vLLM「GitHub リポジトリ（v0.32.0 のソースと README）」：https://github.com/vllm-project/vllm
• PyPI「vllm」：https://pypi.org/project/vllm/
• vLLM ドキュメント「Quickstart」：https://docs.vllm.ai/en/stable/getting_started/quickstart/
• vLLM ドキュメント「GPU」（インストール）：https://docs.vllm.ai/en/stable/getting_started/installation/gpu/
• vLLM ドキュメント「CPU」（インストール）：https://docs.vllm.ai/en/stable/getting_started/installation/cpu/
• vLLM ドキュメント「OpenAI-Compatible Server」：https://docs.vllm.ai/en/stable/serving/openai_compatible_server/
• vLLM ドキュメント「vLLM CLI Guide」：https://docs.vllm.ai/en/stable/cli/
• vLLM ドキュメント「Conserving Memory」：https://docs.vllm.ai/en/stable/configuration/conserving_memory/
• vLLM ドキュメント「Troubleshooting」：https://docs.vllm.ai/en/stable/usage/troubleshooting/
• vLLM ドキュメント「Frequently Asked Questions」：https://docs.vllm.ai/en/stable/usage/faq/
• vLLM ドキュメント「Security」：https://docs.vllm.ai/en/stable/usage/security/
• vLLM ドキュメント「Quantization」：https://docs.vllm.ai/en/stable/features/quantization/
• vLLM ドキュメント「GGUF」：https://docs.vllm.ai/en/stable/features/quantization/gguf/
• vLLM Blog「vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention」（2023年6月20日）：https://vllm.ai/blog/2023-06-20-vllm
• Woosuk Kwon ほか「Efficient Memory Management for Large Language Model Serving with PagedAttention」（SOSP 2023）：https://arxiv.org/abs/2309.06180
• Red Hat「Meet vLLM: For faster, more efficient LLM inference and serving」：https://www.redhat.com/ja/blog/meet-vllm-faster-more-efficient-llm-inference-and-serving
• vLLM Forums「torch.OutOfMemoryError: CUDA out of memory」：https://discuss.vllm.ai/t/torch-outofmemoryerror-cuda-out-of-memory/2420
• Hugging Face「Qwen/Qwen2.5-1.5B-Instruct」（モデルカードと config.json）：https://huggingface.co/Qwen/Qwen2.5-1.5B-Instruct
• Hugging Face「Qwen/Qwen3-8B」（モデルカードと config.json）：https://huggingface.co/Qwen/Qwen3-8B
• Hugging Face「Text Generation Inference」：https://huggingface.co/docs/text-generation-inference/index
• Ollama「FAQ」：https://docs.ollama.com/faq
• Ollama「OpenAI compatibility」：https://docs.ollama.com/api/openai-compatibility
• Ollama「Importing a Model」：https://docs.ollama.com/import
• llama.cpp「GitHub リポジトリ」：https://github.com/ggml-org/llama.cpp
• llama.cpp「LLaMA.cpp HTTP Server」：https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md

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