vLLMとは｜LLM推論サーバーの仕組みと使い方・自社運用の実務

vLLMとは｜本番向けLLM推論サーバーの位置づけ

vLLMは、LLMの推論と配信に特化したライブラリです。UC BerkeleyのSky Computing Labで生まれ、現在はコミュニティ主導で開発されています。Hugging Faceに公開されたモデルの重みを読み込み、HTTPリクエストに応答するサーバーとして常駐させる、という使い方が基本形です。

公式ドキュメントが掲げるのは「Easy, fast, and cheap LLM serving for everyone」という一文で、安さの中身はGPUメモリの使い切りにあります。詳細な機能一覧はvLLM公式ドキュメントで確認できます。

なお本記事の技術情報は、2026年11月時点の公式ドキュメントをもとに整理しています。vLLMは更新の速いOSSで、対応ハードウェア・量子化形式・引数の既定値はバージョンによって変わります。導入時は使用するバージョンのドキュメントで裏を取ってください。

推論エンジンと推論サーバーは役割が違う

結論から言うと、vLLMはエンジンとサーバーの両方を兼ねています。混同しやすいので分けて整理します。

この3層のうち、vLLMが引き受けるのは上の2つです。RAGの検索やプロンプト設計はアプリ側の仕事になります。検索まわりの設計はRAGとは？仕組み・活用事例・導入メリットをわかりやすく解説で別途整理しています。

Ollama・クラウドAPIとの使い分け

選定の基準は「同時に何人が使うか」と「重みを自社の管理下に置く必要があるか」の2軸です。

ローカル実行の入り口についてはOllamaとは？ローカルLLM実行環境の特徴・使い方・案件単価をエンジニア視点で解説が詳しく、マネージドサービス側の選択肢はAmazon Bedrockとは｜主要モデル・料金とAWS LLM開発案件にまとめています。

よくある質問：Ollamaから乗り換えるべき境目はどこですか。

同時接続が常時2〜3を超え、応答待ちのキューが目に見えてきたタイミングです。1人あたりの体感速度より、待ち行列の長さを指標にすると判断しやすくなります。

仕組み｜PagedAttentionと連続バッチングが速さを生む理由

vLLMが従来のナイーブな配信実装に対して数倍のスループットを出せる、と説明されるのは、メモリ管理とスケジューリングを同時に作り替えたためです。公開されているベンチマークでは2〜4倍程度の改善が報告されていますが、倍率はモデル・入出力長・同時実行数・比較対象の実装で大きく動きます。自社のワークロードでそのまま再現する数字ではない、という前提で読んでください。

PagedAttention：KVキャッシュをページ単位で管理する

LLMは生成の過程でKVキャッシュを持ちます。従来の実装は、1リクエストにつき「最大長ぶんの連続したメモリ」を先に確保していました。実際の出力が短ければ、確保した領域の大半が使われないまま塩漬けになります。

PagedAttentionは、OSの仮想メモリとページングの発想を持ち込みました。KVキャッシュを固定サイズのブロックに割り、ブロックテーブルで論理位置と物理位置を対応づけます。これにより次の3つが成立します。

• 断片化が消え、同じVRAMでさばける同時リクエスト数が増える

• 共通のシステムプロンプトを持つリクエスト同士で、プレフィックス部分のブロックを共有できる

• 出力長を事前に決め打ちしなくてよくなる

元になった考え方はPagedAttentionの論文（arXiv）で公開されています。

連続バッチング：終わった枠に次を差し込む

静的なバッチ処理では、バッチ内のいちばん長い生成が終わるまで、先に終わった枠が遊びます。連続バッチングは、デコードの1ステップ単位で完了したリクエストを外し、待機中のリクエストを投入します。

つまり、GPUが止まる時間を潰す仕組みです。加えて、長いプロンプトの前処理を分割して差し込むチャンク化プリフィルも組み合わさり、新規リクエストの待ち時間が伸びにくくなっています。

プレフィックスキャッシュが効く場面

社内チャットのように、全リクエストが同じ長いシステムプロンプトを共有する構成では、プレフィックスキャッシュの効果が大きくなります。有効化すると、重複部分の計算を使い回せます。逆に、毎回まったく異なる文書を丸ごと投げる要約バッチでは、ほとんど効きません。

使い方｜インストールからOpenAI互換APIまで

最短手順は3ステップです。GPUドライバとCUDAが入っている前提で進めます。

環境要件を先に確認する

• NVIDIA GPU（Ampere世代以降だと量子化まわりの選択肢が広い）、AMD GPU、Google TPU、Intel Gaudi、Apple Siliconなどに対応

• Python 3.9以降の仮想環境を推奨。既存環境のPyTorchと競合しやすいため、専用のvenvを切ったほうが安全です

• 対応モデルは200以上のアーキテクチャ。Hugging Face上のゲート付きモデルはアクセストークンの事前取得が必要です

起動する

導入は pip install vllm の1行です。起動は vllm serve にモデルIDを渡すだけで、たとえば vllm serve meta-llama/Llama-3.1-8B-Instruct のように指定します。初回はモデルのダウンロードが走るため、70Bクラスでは回線とディスクの空きを先に確認しておくと詰まりません。

起動が完了すると、既定ではポート8000でHTTPサーバーが待ち受けます。疎通確認は curl で localhost:8000/v1/models を叩くのが最短で、ロード済みのモデルIDが返ってくれば成功です。チャット補完は /v1/chat/completions、埋め込みは /v1/embeddings に割り当てられています。

アプリ側をつなぐ

vLLMはOpenAI互換のエンドポイント（チャット補完、補完、埋め込みなど）を提供します。OpenAI SDKを使っているアプリなら、base_urlをvLLMのアドレスへ、モデル名をロードしたモデルIDへ差し替えるだけで疎通します。認証が必要な構成では、起動時にAPIキーを設定してヘッダで渡します。

ここが移行コストの低さに直結します。既存の生成AIアプリをそのまま自社GPUへ寄せられるため、切り替えの検証を1日で回せるケースも珍しくありません。

よくある質問：手元にGPUがない場合、CPUだけで試せますか。

動かすことは可能ですが、スループットは実用水準に届きません。検証用途ならクラウドのGPUインスタンスを時間課金で借りるほうが現実的です。

GPU要件と量子化の選び方

必要VRAMは「重み + KVキャッシュ + 実行時のオーバーヘッド」で決まります。重みの部分は計算で出せます。

モデルサイズ別のVRAM概算

下表は「パラメータ数 × 1パラメータあたりのバイト数」で求めた重みのみの概算で、KVキャッシュと実行時オーバーヘッドは含みません。上乗せ量はコンテキスト長と同時実行数で決まるため一律には出せませんが、短めの入力（数千トークン）で同時実行数を絞る構成なら、重み概算に2〜3割を足したあたりが最初の見積もりの出発点になります。長文コンテキストや高い同時実行数を狙うなら、上乗せが重みを上回ることもあります。

70BをFP16で動かすなら、重みだけで80GBのGPU2枚が最低ラインです。FP8なら重みは約70GBまで下がりますが、80GB1枚に載せられるかどうかはKVキャッシュの確保量次第で、コンテキスト長と同時実行数を絞らないと1枚構成は成立しません。この1枚か2枚かの差がそのまま月額のGPU費用に跳ね返るため、見積もり段階で踏み込んで検証する価値があります。

量子化形式の比較

公式ドキュメントはFP8・INT8・INT4・GPTQ・AWQ・GGUFなど複数形式への対応を挙げています。ただし同じ4bitでも、形式が違えば速度も精度も変わります。本番に載せる前に、自社の評価データで比較するのが結局いちばん早い道です。評価の進め方はLLM評価（Evals）とは｜LLM-as-a-Judgeと品質保証の実務まで解説を参照してください。

本番運用で効くチューニング

設定は多いものの、最初に触る値は3つに絞れます。引数の正式な定義と既定値はvLLM公式のEngine Argumentsドキュメントに一覧があるので、バージョンを合わせて確認してください。

gpu-memory-utilization

GPUメモリのうち、重み・アクティベーション・KVキャッシュに割り当てる比率です。既定は0.9。値を上げるとKVキャッシュが広がり、同時実行数とスループットが伸びます。OOMが出たら下げる、が基本の調整方向です。

ここで押さえておきたい落とし穴があります。vLLMは起動時点でこの比率ぶんのメモリを確保します。アイドル状態でも占有は解けません。共有GPUクラスタで他プロセスと同居させる構成では、取り合いが起きます。

max-model-len と max-num-seqs

max-model-lenはコンテキスト長の上限、max-num-seqsは同時に処理するシーケンス数の上限です。この2つの積がKVキャッシュの必要量をほぼ決めます。128Kコンテキストを宣言したまま同時実行数を増やすと、すぐにメモリが足りなくなります。実際に使う入力長に合わせて切り下げるのが定石です。

tensor-parallel-size

モデルを複数GPUに分割します。アテンションヘッド数を割り切れる必要があるため、設定できる値は実質1・2・4・8のいずれかになります。並列数を増やすとGPU間通信が増えるので、1枚に載るなら載せたほうが速い、という場面は多いです。

よくある質問：値を変えたら、どこで効果を測ればよいですか。

同時接続を段階的に上げる負荷試験で、スループット（トークン/秒）と最初のトークンまでの時間（TTFT）を2軸で見ます。片方だけ見ると、体感が悪化したことに気づけません。

自社運用と外部APIのコスト分岐

判断軸はシンプルで、GPUを遊ばせないだけのトラフィックがあるかです。外部APIは使った量だけの課金、セルフホストは起動している時間ぶんの課金になります。

損益分岐の考え方

1. 月間の入出力トークン量を実測する（PoC期間の実績でよい）

2. 外部APIの単価を掛けて、月額の変動費を出す

3. 必要なGPUインスタンスの月額を出す（常時起動か、営業時間のみか）

4. 2と3を比べる

平日9〜19時だけ使う社内ツールなら、GPUの稼働率は4割程度にとどまります。この条件では外部APIが有利に働きやすく、逆に24時間のバッチ推論や、常時トラフィックのある顧客向け機能では自社運用が効いてきます。コスト設計の全体像はLLMコスト最適化案件の単価相場｜トークン削減・推論設計のフリーランス実務で整理しています。

見落としやすいコスト

• GPUインスタンス代以外の運用工数（監視、バージョン追従、障害対応）

• モデル更新のたびに発生する評価・回帰テスト

• 冗長化。1台構成だと、そのGPUが落ちた瞬間にサービスが止まります

• ストレージ。70Bクラスの重みは数十GB単位で、複数バージョンを持つと効いてきます

データを外に出せない要件がある場合は、そもそもコスト比較ではなく制約条件での決定になります。社内導入の進め方は社内LLM導入案件とは｜構成・要件・単価とフリーランスの参画実務が参考になります。

よくある失敗と対策

失敗1：起動直後にOOMで落ちる

max-model-lenを宣言値のまま放置しているケースが大半です。モデルの最大コンテキスト長をそのまま採用すると、KVキャッシュの確保だけでVRAMを食い潰します。実運用で使う入力長を測り、そこから切り下げてください。それでも落ちるならgpu-memory-utilizationを0.85前後まで下げて様子を見ます。

失敗2：同時実行数の見積もりを1ユーザー基準で作る

1リクエストのレイテンシだけを見て「十分速い」と判断すると、本番で詰まります。社内50人が使うツールなら、ピーク時の同時リクエストは体感の数倍になります。負荷試験の目標値に決まった基準はありませんが、想定ピークに5割程度の上積みを乗せた水準まで試しておくと、見積もり誤差を吸収できます。利用者数が読めない外部公開の機能では、さらに上を見る必要があります。

失敗3：可観測性なしで本番投入する

トークン単位のレイテンシとエラー率を取っていないと、劣化に気づくのがユーザーからの申告になります。推論基盤のメトリクスに加えて、アプリ層のトレースも最初から入れておくべきです。トレース基盤の選定はLangfuse・LangSmithの使い方｜LLMトレース管理と選び方を参照してください。運用設計そのものはLLMOpsとは｜MLOpsとの違いと評価・監視・運用の実務にまとめています。

案件でvLLMはどう扱われるか

公開案件の募集要件でvLLMが単独の必須スキルとして立つことは、まだ多くありません。実際には「生成AI基盤の構築・運用」「LLM推論基盤のコスト最適化」といった案件の、要素技術のひとつとして登場します。

ここから先の単価の目安は、2026年11月時点で首都圏中心の主要フリーランスエージェント数社の公開案件ページを確認し、LLM推論基盤・生成AI基盤の構築運用に言及する募集を観測ベースで整理したものです。該当する公開案件の母数はまだ多くないため、相場というより目安として読んでください。

まずは公開案件ベースで、生成AI基盤まわりの構築・運用案件は月80〜120万円前後のレンジで募集が見られます。上限側に乗っているのは、クラウドインフラ（Kubernetes、IaC）の実務経験が3年以上あり、そのうえでGPUワークロードの設計と、評価・監視まで一人称で回せる人の求人です。推論基盤の経験だけ、インフラの経験だけでは、このレンジの上限には届きにくい構造があります。非公開で打診される案件は個別条件での上振れがあり、公開案件のレンジとは分けて考えたほうが実態に近くなります。

自分の経歴だとどのあたりを狙えるのか気になる方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に引き上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？に、複数案件を比較する際の優先順位のつけ方は案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位にまとめています。

実際の募集条件を見たい場合は、AIエンジニアの案件一覧で現在掲載中の案件を確認できます。周辺領域から入るルートとしてはLLMファインチューニング案件の全体像｜必要スキル・単価目安・参画ルートやRAG構築案件の実情｜単価相場・必要スキル・獲得方法もあります。

自社運用チェックリスト

本番に載せる前に、次の10項目を確認してください。

このうち2と6は、落ちてから気づく項目です。稼働開始前に必ず潰しておきます。

まとめ

vLLMは、同時アクセスをさばくためのLLM推論サーバーであり、導入判断は「同時接続数」と「GPUの稼働率」の2点でほぼ決まります。

• 1人の検証ならOllama、複数ユーザーへの配信ならvLLM

• 速さの中身はPagedAttentionによるKVキャッシュのページ管理と、連続バッチングによる空き枠の即時充填

• vllm serveでOpenAI互換APIが立ち、既存アプリはbase_urlとモデル名の差し替えで移行できる

• VRAMは重み概算にKVキャッシュぶんを上乗せして見積もる。70BのFP8は重み約70GBだが、80GB1枚に載るかは入力長と同時実行数次第

• 最初に触る設定はgpu-memory-utilization、max-model-len、tensor-parallel-sizeの3つ

• 外部APIとの分岐点はGPUの稼働率。営業時間のみの社内ツールなら外部APIが有利に働きやすい

次の一歩としては、手元のPoCで入出力トークン量を1週間実測し、外部APIの月額とGPUインスタンスの月額を並べて比べるところから始めてください。数字が出れば、自社運用に踏み込むべきかどうかは自ずと決まります。

参照した一次情報はvLLM公式ドキュメント、vLLMのGitHubリポジトリ、PagedAttentionの論文（arXiv）、vLLMのEngine Argumentsドキュメント、OpenAI互換サーバーのドキュメントです。