vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説

自社のGPUサーバーでLLMを動かす段になると、モデルを読み込むだけでは業務に耐えません。同時に来る何十本ものリクエストをさばき、GPUメモリを使い切らずに回し続ける層が要ります。その層を担うOSSが vLLM です。本記事では、速さの中核にあるPagedAttentionと連続バッチング、V1エンジンで作り替えられた内部構造、vllm serveで立てるOpenAI互換APIの実装、そしてマネージドAPIから自社運用へ移す損益分岐までを、2026年7月時点の一次情報で整理します。推論そのものの仕組みはLLM推論の仕組みと高速化の手法で扱っているため、本記事はエンジン側に絞ります。

まとめ：vLLMの中核と使い方・自社運用の判断の結論

vLLMは、大規模言語モデルの推論とサービングを担うOSSの推論エンジンです。カリフォルニア大学バークレー校のSky Computing Labで生まれ、いまは2,000人を超えるコントリビュータが開発しています。ライセンスはApache License 2.0で、商用の自社運用に制約は掛かりません。

速さの土台は2つ。1つはPagedAttentionで、KVキャッシュをOSの仮想メモリのようにページ単位で管理し、確保しすぎた余りや解放後の隙間をほぼ無くします。もう1つは連続バッチングとチャンク化プリフィルで、リクエストの終わりを待たずに次を差し込み、長いプロンプトを分割して生成処理を止めません。

使い方は短い手順で通ります。pipで入れてvllm serveを叩けばOpenAI互換のAPIサーバーが立ち上がり、アプリ側はエンドポイントとモデル名を差し替えるだけ。Anthropic Messages API形式とgRPCの提供も公表されています。

判断の起点は機能表ではありません。月のトークン量が小さいうちや試作段階では、マネージドAPIのほうが総コストで有利。自社運用へ移す価値が出るのは、機密データを社外へ出せない、GPUを常時埋められる負荷がある、モデルや推論の挙動を自分で固定したいのいずれかに当てはまるときです。

vLLMが推論を速くする仕組み｜PagedAttentionと連続バッチングの中身

まず、このエンジンが何を解いているのかを確定させます。

PagedAttentionはKVキャッシュをページ単位で管理して断片化を消す

LLMの生成では、これまでに処理したトークンのKey／Value（KVキャッシュ）をGPUメモリへ置き続けます。従来の実装はリクエストごとに連続した領域を先に確保していたため、実際の生成が短く終われば余りが遊び、解放後には隙間が残りました。空いているのに使えないメモリが積み上がる構造です。

PagedAttentionは、このKVキャッシュを小さな固定サイズのブロックに切り、非連続に割り当てます。着想はOSの仮想メモリとページングで、論文（SOSP 2023採録）ではKVキャッシュの無駄をほぼゼロに近づけたと報告されました。同じ論文の測定では、当時の主要な実装であるFasterTransformerやOrcaに対し、同じレイテンシで2〜4倍のスループットという値が示されています。

ページ単位にすると副産物も得られます。同じプロンプト接頭辞を持つリクエスト間でブロックを共有でき、並列サンプリングやビームサーチでメモリを重複させずに済む構造。キャッシュそのものの理論と削減手法はKVキャッシュによるLLM推論の高速化とメモリ削減の側で詳しく扱っています。

連続バッチングとチャンク化プリフィルが待ち時間を詰める仕組み

2つ目の柱はスケジューリングです。素朴な実装ではリクエストをまとめて1バッチにし、全部の生成が終わるまで次を受け付けません。生成の長さはリクエストごとに違うため、短く終わった分の計算資源が空回りします。

連続バッチングは、終わったリクエストの席を即座に空け、待っている次のリクエストを差し込みます。GPUが遊ぶ時間が減り、同じハードウェアでさばける本数が伸びる仕組み。ここにチャンク化プリフィルが重なります。長いプロンプトの読み込み（プリフィル）を一度に流すと、その間ほかのリクエストの生成が止まりますが、分割して少しずつ混ぜれば生成側の手が止まりません。

2026年7月時点の公式ドキュメントでは、チャンク化プリフィルは可能な場面で既定として有効です。加えて、同じ接頭辞の計算結果を再利用するプレフィックスキャッシュ、n-gram・suffix・EAGLE・DFlashといった投機的デコーディングも並んでいます。

V1エンジンで作り替えられたスケジューラとKVキャッシュ管理の構造

vLLMは内部を一度作り替えています。この世代を「V1」と呼び、スケジューラ、KVキャッシュマネージャ、ワーカー、サンプラー、APIサーバーを再設計した構造。旧世代のV0はすでに完全に廃止され、公式ドキュメントは移行を促しています。

設計上の変化で効くのは、統一スケジューラです。プロンプトのトークンと出力のトークンを区別せず同じものとして扱うため、プリフィルとデコードの位相を厳密に分ける必要がなくなり、チャンク化プリフィルやプレフィックスキャッシュ、投機的デコーディングが同じ枠組みに乗ります。

移行時に把握しておくべき差分も公表されています。CUDAグラフのキャプチャはV0よりメモリを食う、logprobsはロジットの後処理前の値が返る（処理後の値も選べる）、best_ofやリクエスト単位のロジットプロセッサ、GPUとCPU間でのKVキャッシュのスワップは削除、という4点。V0前提で書かれた古い記事や社内手順が残っていれば、この4点から見直してください。

vLLMの導入手順とOpenAI互換サーバーの起動・主要オプションの決め方

ここからは実装です。公式のクイックスタートに沿って最短経路を通します。

uvでの導入とオフライン推論をPythonから実行する最小コード

対応するPythonは3.10〜3.13です。公式が案内する導入は、仮想環境を切ってからパッケージを入れる2段。GPUのバックエンド指定をautoにしておくと、環境に合わせたビルドが選ばれます。

uv venv --python 3.12 --seed
uv pip install vllm --torch-backend=auto

サーバーを立てずに、バッチでまとめて推論する使い方もあります。LLMクラスにモデル名を渡し、SamplingParamsで生成の設定を指定してgenerateを呼ぶ形です。評価用のデータセットを一括で流したいときは、この書き方が短く済みます。

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)

llm = LLM(model="facebook/opt-125m")
outputs = llm.generate(prompts, sampling_params)

for output in outputs:
    print(output.prompt, output.outputs[0].text)

ここで指定するモデル名はHugging Faceのリポジトリ名です。vLLMはHugging Face上のモデルをそのまま読み込む設計のため、変換工程を挟まずに検証へ入れます。

vllm serveで立てるOpenAI互換APIサーバーと接続の確かめ方

本番構成では、HTTPサーバーとして常駐させます。コマンドはモデル名を渡すだけ。既定で8000番ポートを開き、OpenAI互換のエンドポイントを公開します。

vllm serve Qwen/Qwen2.5-1.5B-Instruct

クライアント側の書き換えは軽く済みます。OpenAIのSDKをそのまま使い、api_keyにダミー値、base_urlにローカルのエンドポイントを渡すだけで通ります。既存のアプリケーションがOpenAI APIを叩いている構成なら、差し替えは接続先とモデル名の2箇所です。

from openai import OpenAI

client = OpenAI(api_key="EMPTY", base_url="http://localhost:8000/v1")
completion = client.completions.create(
    model="Qwen/Qwen2.5-1.5B-Instruct",
    prompt="San Francisco is a")
print(completion)

公式ドキュメントでは、OpenAI互換APIに加えてAnthropic Messages API形式とgRPCの提供も挙げられています。ツール呼び出しや推論過程のパーサ、構造化出力、ストリーミングも機能として並ぶため、APIからの載せ替え先として検証を始めやすい構成です。

起動時に決めるモデル長・メモリ使用率・並列度の3つのオプション

既定値のまま本番へ出すと、たいてい容量で詰まります。先に決めるのは次の3つです。

• --max-model-len：扱う最大コンテキスト長。長く取るほどKVキャッシュを食う
• --gpu-memory-utilization：GPUメモリのうちKVキャッシュへ先に確保する割合
• --tensor-parallel-size：モデルを分割して載せるGPU枚数

1つ目のモデル長は業務要件から決めます。社内文書を丸ごと投げる想定がないなら短く切り、その分をKVキャッシュの余白へ回すほうが同時実行数は伸びます。2つ目の使用率は、確保しすぎればモデルの重みが載らず、絞りすぎればキャッシュが足りません。3つ目は単一GPUにモデルが収まらないときに引き上げる値で、収まるうちは1のままで構いません。

llama.cpp・TGI・TensorRT-LLMとの違いとvLLMを選ぶ判断軸

推論エンジンは複数あります。優劣ではなく担当領域で振り分けるのが実務です。

llama.cpp・Ollamaとの違いはGPU前提の同時処理能力にある

llama.cppとその上に乗るOllamaは、CPUと小さなGPUで動かすことを主眼に置いた実装です。1台の端末やサーバーで少数の推論を回す用途では扱いやすく、モデルの入れ替えも軽い。対してvLLMは、GPUを前提に多数の同時リクエストをさばくサービング基盤として設計されています。

分岐点は同時実行数です。社内の数人が順番に使う検証環境なら、vLLMの容量設計を組む工数は回収できません。全社の業務システムからリクエストが並列で飛ぶ構成になった段階で、連続バッチングとPagedAttentionの効きが費用差として表れます。GPUを持たない環境での構築手順はローカルLLMの構築手順とOllamaでの動かし方の側で扱っています。

TensorRT-LLM・TGI・SGLangと並べたときのvLLMの位置

GPU前提の同じ土俵にも複数の選択肢が並ぶ状況です。NVIDIAのTensorRT-LLMは同社GPUに寄せた作り込みが持ち味で、エンジンをビルドする工程を挟む代わりに単一構成での性能を詰められます。Hugging FaceのTGIは同社エコシステムとの結び付きが強く、SGLangは複雑なプロンプト制御やエージェント的な呼び出しの扱いに軸があります。

vLLMを選ぶ理由になりやすいのは、対応ハードウェアの幅です。公式にはNVIDIA GPU、AMD GPU、x86／ARM／PowerPCのCPUに加え、Google TPU、Intel Gaudi、IBM Spyre、Huawei Ascend、Rebellions NPU、Apple Silicon、MetaX GPUが挙がります。調達できるアクセラレータが読めない段階でも、載せ替えの余地を残せる構成です。

対応する量子化形式と、GGUFをvLLMで動かすときの注意点

vLLMが読める量子化形式は広く、2026年7月時点の公式ドキュメントではFP8、MXFP8／MXFP4、NVFP4、INT8、INT4、GPTQ／AWQ、GGUF、compressed-tensors、ModelOpt、TorchAOが列挙されています。GPU向けの主流であるAWQとGPTQの重みは、そのまま読み込ませて構いません。

GGUFは事情が違います。読めますが、この形式はllama.cppの実行形式として設計されたものであり、CPUオフロードを含む単体実行に強みがある容器です。GPUを潤沢に確保してvLLMで並列にさばく構成なら、AWQやGPTQ、あるいはFP8系の重みを使うほうが素直です。形式そのものの構造はGGUFの仕組みとGPTQ・AWQとの違いで詳しく扱っています。

ビット幅を落とすほどGPUメモリは空き、同時実行数へ回せます。ただし日本語の指示追従は落ちやすいため、代表タスクで品質を測ってから採用の可否を決める順番を崩さないでください。

GPUメモリと同時実行数の設計｜並列化と設定値で処理量を伸ばす手順

運用で詰まるのは、ほぼメモリと同時実行数の綱引きです。

GPUメモリ使用率とモデル長でKVキャッシュの余白を確保する

vLLMは起動時に、指定した割合のGPUメモリをKVキャッシュ用として先に確保します。ここが狭いと、同時に抱えられるリクエストの本数が上限に張り付きます。余白を作る手は2つで、使用率の割合を上げるか、最大コンテキスト長を短く切るかです。

順番としては、モデル長を業務要件まで絞るほうを先に試します。使用率を上げすぎると、モデルの重みや実行時の作業領域が圧迫され、起動そのものが通らなくなる場面があるため。長文を投げる要件が本当にあるのかを業務側と確認し、必要な分だけ取るのが手戻りの少ない進め方です。

テンソル並列・パイプライン並列・データ並列を使い分ける判断基準

GPUを増やす方向にも順番があります。公式ドキュメントの指針は明快です。

• テンソル並列：単一GPUにモデルが載らないとき。メモリ圧を下げてキャッシュ余白も増やせる
• パイプライン並列：テンソル並列を使い切った後、さらに分散させるとき。深く狭いモデル向き
• データ並列：モデル全体を複製できるGPU数があるとき。同時利用者が多い構成の処理量向上に効く
• エキスパート並列：MoEモデル専用。エキスパートの計算をGPU間で均す

混同しやすいのはテンソル並列とデータ並列です。前者は1つのモデルを切って複数GPUへ分けて載せる手法で、後者は同じモデルを丸ごと複数用意して振り分ける手法。載らないから分けるのか、さばききれないから増やすのかで選ぶものが変わります。

メモリ不足でプリエンプションが起きたときに見直す設定項目の順番

バッチ中のリクエスト全部を抱えるだけのKVキャッシュが無くなると、vLLMは処理中のリクエストを退避させます。V1での既定の退避方式は再計算（RECOMPUTE）で、退避した分は後からもう一度計算し直す挙動。当然、端から端までの応答時間は悪化します。

公式ドキュメントが示す対処は3方向です。GPUメモリ使用率を上げてキャッシュ領域を広げる、--max-num-seqsを下げて同時に抱える本数を絞る、--max-num-batched-tokensを下げて1回に流すトークン量を絞る。まずログでプリエンプションの発生を確認し、余白を広げられるならそこから手を付けます。

処理量と応答性のつまみとしても、この値は効きます。--max-num-batched-tokensを2048程度の小さい値にするとトークン間の遅延（ITL）が改善し、大きく取ると最初のトークンまでの時間（TTFT）が改善する関係。処理量そのものを伸ばしたい場面では8192を超える値が案内されており、小さいモデルでは特に効きます。なおチャンク化プリフィルを無効にする構成では、この値を最大モデル長より大きく取る必要があります。

vLLMを自社で運用すべき条件と、マネージドAPIへ寄せるべき3場面

ここからは判断です。技術的に動くかではなく、払う価値があるかを切り分けます。

トークン量・機密要件・稼働率から引く自社運用に必要な下限条件

起点は1つ。GPUを常時埋められるだけの負荷があるかです。マネージドAPIは使った分だけの課金ですが、自社運用のGPUは遊んでいる時間も課金され続けます。日中の数時間だけ数百リクエストという負荷なら、GPUの遊休費用がAPI課金を上回る計算になりやすい。

それでも自社運用へ移す条件は3つあります。1つ目は機密要件で、外部APIへ送信できないデータを扱うなら負荷の大小に関係なく自前で持つ判断。2つ目は恒常的に大きいトークン量で、GPUを昼夜埋められるなら単価は逆転します。3つ目は挙動の固定で、モデルのバージョンや生成の再現性を自分で握りたい場合。この3つのいずれにも当てはまらないなら、マネージドAPIのまま設計を進めるほうが総額は下がります。

vLLMを見送るべき場面と、導入前に先に潰しておく運用前提の3項目

見送る判断がはっきりする場面もあります。まず、社内の数人が順番に触る検証環境。この規模では連続バッチングの効きが出ず、Ollamaのほうが立ち上げも入れ替えも軽く済みます。次に、GPUを調達できずCPUのみで動かす構成。動作はしますが、多数同時をさばく前提が崩れるためエンジンを選ぶ理由が消えます。3つ目は、モデルを自分で持たずAPI利用で完結する構成です。

採用する場合は、着手前に3項目を潰しておいてください。

• GPUの確保計画：機種・枚数・調達期間と、遊休時間の費用の見積もり
• 監視の設計：TTFTとトークン毎秒、プリエンプション発生、キャッシュ使用率の可視化
• 版の管理：vLLM本体とモデルの更新手順、切り戻しの経路

3つ目は見落とされやすい箇所です。vLLMは0.x系のまま更新が速く、2026年7月時点の最新は0.26.0（2026年7月25日公開）で、直前の0.25系は同月11日と14日という間隔。V0の完全廃止のように内部構造が動く変更も入るため、本番の版を固定し、検証環境で先に通す運用を前提に置いてください。

LLM推論基盤の構築を外部へ委託するとき見積書で確認する5項目

推論基盤の構築を外部へ任せる場合、見積書の粒度で後の追加費用が決まります。確認したいのは次の5点です。

• 対象モデルと量子化形式、想定する最大コンテキスト長
• 目標とする同時リクエスト数と、TTFT・トークン毎秒の受け入れ基準
• GPUの調達主体（自社か委託先か）と遊休時間の費用負担
• 監視・ログ・アラートがどこまで成果物に含まれるか
• vLLM本体とモデルの更新、切り戻しの運用を誰が担うか

特に2点目と5点目は曖昧にされやすい箇所です。受け入れ基準を決めずに「速くなる」だけで契約すると、負荷試験の段階で合否の判定ができません。設計から運用の引き渡しまで含めて相談するなら、生成AI開発・AI受託開発のようにモデル選定と基盤構築を一体で扱える体制かを確認してください。

よくある質問

vLLMの検討時に問い合わせが多い論点を5つ挙げます。

vLLMとOllamaはどちらを選べばよいですか？

同時にさばく本数で決まります。1台で少数の推論を回す検証環境や個人利用ならOllamaで足り、モデルの入れ替えも軽く済みます。GPUを確保して多数の同時リクエストを処理量重視でさばく本番構成ならvLLMです。両者は競合というより担当領域が違い、検証をOllamaで進めて本番をvLLMへ載せる進め方も成立します。

vLLMを動かすのに必要なGPUメモリはどれくらいですか？

モデルの重みに加えてKVキャッシュの分が要るため、重みのサイズだけでは足りません。目安としては、重みが収まったうえで同時実行数に見合うキャッシュ余白が残る構成が必要です。余白が足りなければ--max-model-lenを短く切るか、量子化でビット幅を落として重み側を圧縮するかの二択になります。数値の当たりは実際の負荷を流して測るのが確実です。

vLLMはCPUだけでも動きますか？

公式の対応ハードウェアにはx86・ARM・PowerPCのCPUが挙がっており、動作可能です。ただしvLLMの設計思想はGPU上で多数同時をさばくところにあり、CPUのみでは処理量が頭打ちになります。GPUを用意できない構成なら、CPUオフロードを前提に組まれたllama.cppやOllamaのほうが扱いやすく、量子化済みの重みで実用速度に届く場面もあります。

OpenAI互換APIならアプリ側のコードは変えずに済みますか？

接続先とモデル名の変更で通る場面は多いものの、無条件ではありません。OpenAI SDKをそのまま使えるのは大枠の話で、モデル固有のパラメータや構造化出力の指定、ツール呼び出しの形式は実際に確認が要ります。V1ではlogprobsがロジット後処理前の値を返す仕様変更もあるため、この値を業務判定に使っている場合は挙動を突き合わせてください。

vLLMの商用利用やライセンスに制約はありますか？

vLLM自体のライセンスはApache License 2.0で、商用の自社運用に追加の許諾は要りません。注意が要るのは載せるモデル側です。商用可否・再配布条件・利用者数の上限は元モデルの規約が定めるため、Llama系やQwen系など個別のライセンス原文を導入前に確認してください。社内利用と外部提供で条件が変わる例もあります。

関連記事

• LLM量子化とは？仕組みとGPTQ・AWQ・GGUFの違い・企業の採用判断を解説【2026年版】：vLLMへ載せる重みのビット幅と手法の選び方
• SLMとは？小規模言語モデルの仕組み・LLMとの違いと実装判断を解説：モデルサイズ側でGPUメモリを削る選択肢
• LLMとは？大規模言語モデルの仕組み・生成AIとの違いと企業導入の判断基準を解説：上位概念と企業導入の判断基準を発注視点で整理
• ファインチューニングとは？LLMの追加学習の仕組み・RAGとの違いと使い分けを解説：自社運用したモデルへ追加学習を掛ける場合の前提
• RAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説：推論基盤の上に載せる検索連携の設計