重要なポイント
- 無料でApache 2.0ライセンスのオープンソース。UC BerkeleyのSky Computing Labで誕生
- PagedAttentionが固定サイズの非連続なブロックでKVキャッシュを管理し、GPUメモリの無駄を減らす
- continuous batchingにより、固定バッチを1つずつ処理するのではなく、多数の同時リクエストを処理する
vllm serveコマンドで起動する、内蔵のOpenAI互換APIサーバー- AWQ、GPTQ、FP8などの量子化フォーマットをサポート
- 複数GPUにわたるテンソル並列・パイプライン並列サービングをサポート
- 主な、最もサポートが手厚いハードウェアはNVIDIA GPU。AMD、Intel、その他のバックエンドも存在するが対応範囲は狭い
- 単一ユーザー向けデスクトップアプリではない——グラフィカルなインストーラーはなく、llama.cppやOllamaのようにCPU専用やApple Silicon向けに設計されているわけでもない
📍 一文で説明
vLLMは、UC BerkeleyのSky Computing Labで生まれた無料でApache 2.0ライセンスの推論・サービングライブラリで、PagedAttentionとcontinuous batchingを使って1台のGPUから多数の同時LLMリクエストを効率的に処理し、OpenAI互換のAPIサーバーを内蔵している。
💬 簡潔に説明
デスクトップのチャットアプリではなく、vLLMはサーバーソフトウェアです。モデルを指定すると、多くの人やアプリケーションが同時に呼び出せるAPIを公開し、単純な「1リクエストずつ処理」の構成よりもGPUメモリを効率的に使います。
📌補足: 本記事はvLLMの公式GitHubリポジトリと公開ドキュメントに基づいており、独自のベンチマークではありません。具体的なスループットやレイテンシの数値は、本記事のために独自に測定したものではなく、GPU、モデル、バッチサイズ、vLLMのバージョンによって大きく変動するため掲載していません。
vLLMとは何か？
vLLMは、大規模言語モデルの推論を大規模に実行するための、無料でApache 2.0ライセンスのライブラリ兼サーバーです。UC BerkeleyのSky Computing Labの研究プロジェクトとして始まり、その後、学術機関や企業の何千人もの開発者が貢献する、最も広く使われているオープンソースLLMサービングエンジンの一つに成長しました。自分のマシンでモデルとチャットする単一ユーザー向けに主に構築されたツールとは異なり、vLLMは複数のユーザーやアプリケーションからの多数の同時リクエストを、共有GPUキャパシティからできる限り効率的に処理するよう設計されています。
- UC BerkeleyのSky Computing Labで誕生し、現在はコミュニティ主導のオープンソースプロジェクト
- Apache 2.0ライセンス：ソースコードはライセンス条項の下で利用・改変・再配布のために公開されている
- Hugging Face Transformers互換フォーマットでモデルを読み込むため、Llama、Mistral、Qwen、DeepSeekなど幅広いモデルファミリーのアーキテクチャをカバーし、多くのモデルで別途の変換ステップを必要としない
- 単一の会話を素早く処理することだけでなく、多数の同時リクエストを効率的に処理することを目的として構築されている
- GitHub上で最も参照されているオープンソースLLMサービングプロジェクトの一つ
PagedAttentionとは何で、なぜ重要なのか？
PagedAttentionは、vLLMが最もよく知られているメモリ管理技術です。生成中、トランスフォーマーモデルはアクティブな各リクエストのトークンごとにアテンションのキー・バリュー（KV）キャッシュを保存します——通常、このキャッシュはリクエストごとに1つの大きな連続したブロックとして割り当てられ、リクエストが取りうる最大長に合わせてサイズが決められるため、リクエストが早く終わったり予約した最大値より短かったりするたびにGPUメモリが無駄になります。PagedAttentionは代わりに、KVキャッシュを小さな固定サイズのブロック（ページ）に分割し、非連続に割り当ててリクエスト間で共有できるようにします——これはオペレーティングシステムが仮想メモリを管理する発想を借用したものです。
- 最大長より短く終わるリクエストのためにKVキャッシュ領域を過剰確保することによるメモリの無駄を削減する
- 同じシステムプロンプトなど、共通の接頭辞を持つリクエスト間でメモリブロックを共有できる
- 単純な連続割り当て方式と比べ、同じメモリ量でより多くの同時リクエストのKVキャッシュをGPUに保持できるようにする
- continuous batchingと連携して動作する。これにより、固定バッチの完全な終了を待ってから次を開始するのではなく、リクエストの到着と完了に合わせて実行中のバッチにリクエストを随時追加・削除できる
vLLMにはどのようなハードウェアが必要か？
vLLMの主要な、最もサポートが手厚いターゲットはCUDA搭載のNVIDIA GPUであり、本番デプロイの大半はNVIDIAハードウェア上で動作しています。プロジェクトは追加のバックエンドも文書化していますが、対応範囲と性能はすべてで同等というわけではありません。
NVIDIA GPU（CUDA）
- 詳細:
- 主要で最も成熟したターゲット。複数のNVIDIA GPUにまたがるテンソル並列・パイプライン並列サービングは十分に文書化されており、本番環境で広く使われている。
AMD GPU（ROCm）
- 詳細:
- ROCm経由でAMDハードウェア向けにサポートされているバックエンドとして文書化されているが、実際の採用実績とコミュニティのカバー範囲はCUDA経路より狭い。
Intel GPUおよびGaudiアクセラレータ
- 詳細:
- プロジェクトがIntelハードウェア向けに文書化した追加バックエンド。NVIDIA GPUに比べ、より小規模で実績の少ないデプロイ経路として扱うべき。
Google TPU
- 詳細:
- Google Cloud TPUハードウェア向けに文書化されたバックエンドで、すでにそのインフラ上で稼働しているチーム向け。
CPU（x86 / ARM / PowerPC）
- 詳細:
- CPU専用バックエンドは存在するが、vLLMが想定するユースケースではない——プロジェクトはGPUサービング向けに構築されており、CPU実行はGPUバックエンドより大幅に遅いと文書化されている。
Apple Silicon（Mac）
- 詳細:
- 公式にメンテナンスされる第一級の経路ではない。コミュニティメンテナンスのプロジェクト（Metalバックエンドプラグインなど）が部分的なApple Siliconサポートを追加しているが、カバー範囲と成熟度はvLLMのNVIDIA GPUサポートに大きく劣る。
1台のMacやCPUのみのマシンでモデルを動かしたい場合、vLLMはそのために作られたツールではありません——llama.cppや、それを基盤とするOllama、LM StudioのようなツールがCPUやApple Siliconハードウェアを直接対象としており、そのシナリオにはより適しています。
vLLMはどの量子化フォーマットをサポートしているか？
vLLMは、単一の独自フォーマットではなく複数の確立された量子化フォーマットを使い、メモリ使用量を減らし、多くの場合スループットを向上させるために、低い数値精度でモデルをサービングすることをサポートしています。
AWQ
- 詳細:
- Activation-aware Weight Quantizationは広く使われている4ビット重み量子化手法で、コミュニティがHugging Face上で事前量子化モデルを公開している。
GPTQ
- 詳細:
- 一般的に事前量子化されたモデルのチェックポイントとして配布される訓練後量子化手法で、こちらも通常は4ビット精度。
FP8
- 詳細:
- ハードウェアFP8サポートを備えた新しい世代のNVIDIA GPUでサポートされる8ビット浮動小数点精度で、FP16/BF16に比べ精度を多少犠牲にしてメモリ使用量削減と高速実行を実現する。
INT8 / INT4
- 詳細:
- AWQやGPTQと並んでプロジェクトが文書化している、さらなるメモリ削減のための低精度整数量子化パス。
本記事には各フォーマットごとの独自に測定した品質低下の数値は含まれていません——これはモデルアーキテクチャとタスクによって変わります。自分のプロンプトでいくつかのフォーマットの出力を比較することが、自分のワークロードにとってのトレードオフを判断する最も信頼できる方法です。
vLLMのOpenAI互換サーバーは何を提供するか？
vllm serveを実行すると、OpenAI APIプロトコルを実装したHTTPサーバーが起動するため、すでにOpenAI API向けに構築されているアプリケーションやSDKは、多くの場合ベースURLとモデル名を変更するだけで自己ホストのvLLMインスタンスを指せます。
- チャット補完・補完向けのOpenAI互換エンドポイントで、OpenAI APIベースのクライアントコードの直接的な置き換えとして利用できる
- 設定可能なホストとポート（サーバーはデフォルトで
http://localhost:8000で待ち受ける） - サーバー起動時に設定する、テンソル並列サイズ、GPUメモリ利用率の目標、量子化フォーマットのエンジンフラグ
- 1つのロード済みベースモデルに対して複数のLoRAアダプタをサービングするサポート
- 互換性のあるリクエスト形式に対する構造化出力と関数・ツール呼び出しのサポート
vLLMをどうインストールして実行するか？
vLLMはPythonパッケージとして配布されており、通常はNVIDIA GPUと互換性のあるCUDAドライバが利用可能なPython環境にpipでインストールします。
- 1サポートされているNVIDIA GPUと最新のCUDAドライバがインストールされているか確認する（AMD/Intel/TPU向けのバックエンドを対象とする場合は、それぞれのインストール手順をプロジェクトのドキュメントで確認する）。
- 2Python仮想環境を作成し、vLLMをインストールする：
pip install vllm。 - 3Hugging FaceのモデルでOpenAI互換サーバーを起動する。例：
vllm serve meta-llama/Llama-3.1-8B-Instruct。 - 4事前量子化モデルの場合は対応するフラグを渡す。例：
vllm serve TheBloke/Llama-2-13B-AWQ --quantization awq。 - 5マルチGPUサービングの場合はテンソル並列フラグを追加する。例：
vllm serve <model> --tensor-parallel-size 2でモデルを2つのGPUに分割する。 - 6デフォルトでサーバーは
http://localhost:8000で待ち受ける。任意のOpenAI API互換クライアントライブラリやcurlで/v1/chat/completionsエンドポイントにリクエストを送信する。 - 7既存のOpenAI APIクライアントコードのベースURLとモデル名だけを変更し、自己ホストサーバーを指すようにする。
vLLMを実行するにはGPUが必要ですか？
テスト以上の用途では必要です——vLLMの主要な、最もサポートが手厚いターゲットはNVIDIA GPUです。CPU専用バックエンドは存在しますが、大幅に遅いと文書化されており、プロジェクトの焦点ではありません。
vLLMを量子化モデルで実行できますか？
はい——vLLMはAWQ、GPTQ、FP8などのフォーマットをサポートしており、これらのフォーマットで事前量子化された多くのモデルがHugging Faceで公開されていて、対応する--quantizationフラグでサービングできます。
vLLMはOllamaやLM Studioとどう違うか？
OllamaとLM Studioは、vLLMとは異なる問題を対象としています。1人のユーザーに、自分のマシンで素早く簡単にチャットできるモデルを提供することです。vLLMは、共有GPUキャパシティから多数の同時ユーザーやアプリケーションをできる限り効率的にサービングすることを目指しています。この2つのツールのカテゴリは、ほとんどのユースケースにおいて近い代替関係にはありません。
- OllamaやLM Studioは通常、llama.cppや同様のエンジンとGGUFモデルフォーマットを基盤とし、CPU専用マシンやApple Siliconを含むコンシューマーハードウェア上の単一ユーザー向けに最適化されている
- vLLMはPagedAttentionとcontinuous batchingを基盤とし、控えめなハードウェア上の単一ユーザーの応答性よりも高並行性のGPUサービング向けに最適化されている
- Ollamaは1コマンドでインストールでき、GPUを必要としない。vLLMはPython環境を想定し、ほとんどのデプロイでNVIDIA GPUが必要で、コマンドライン設定が必要
- LM Studioはグラフィカルなデスクトップチャットインターフェースを追加する。vLLMにはグラフィカルインターフェースがなく、OpenAI互換APIまたはコマンドラインフラグ経由でアクセスする
- vLLMとllama.cppベースのツールはどちらもOpenAI互換APIを公開できるため、そのAPI向けに構築されたフロントエンドツールはどちらとも動作することが多い
vLLMはTGIやTensorRT-LLMとどう違うか？
vLLM、Hugging FaceのText Generation Inference（TGI）、NVIDIAのTensorRT-LLMはいずれも、大規模な本番LLMサービングという同じ広い目標を対象としていますが、設計とトレードオフが異なります。
vLLM
- 詳細:
- Apache 2.0ライセンス、Pythonベースで、PagedAttentionとcontinuous batchingを中心に構築。Hugging Face Transformers互換モデルを直接読み込め、幅広いアーキテクチャカバー範囲とマルチベンダーGPUバックエンドサポート（NVIDIAが主、AMD・Intel・TPUも文書化）を持つ。
TGI
- 詳細:
- Hugging Face自身のサービングエンジンで、Apache 2.0ライセンス。continuous batchingと複数の量子化フォーマットもサポートし、Hugging Face Hubとそのエコシステムに密に統合されている。
TensorRT-LLM
- 詳細:
- NVIDIA GPU専用に構築されたNVIDIAのエンジン。モデルは事前に対象GPU向けに最適化されたTensorRTエンジンへコンパイルされ、その特定のハードウェアで高い性能を発揮しうるが、コンパイルステップが必要で、vLLMやTGIに比べてハードウェア間の柔軟性は低い。
本記事はこれら3つのエンジンを互いに独自ベンチマークしておらず、どれかが普遍的に高速だと主張するものではありません——スループットはモデル、ハードウェア、バッチの特性、各エンジンのバージョンに大きく依存します。3つすべてのデプロイとライセンスに関するより詳細な比較は、エンタープライズ推論サーバーガイドを参照してください。
vLLMはどんな人に向いているか？
vLLMは、GPUインフラストラクチャ上で多数の同時ユーザーやアプリケーションにモデルをサービングするチームに向いています。自分のコンピュータでモデルと最も早くチャットする方法を探している人向けではありません。
vLLMと代替ツールの比較一覧
これらのツールは、単一ユーザー向けと本番サービング向けのスペクトル上の異なる位置にあります。
vLLM
- インターフェースとセットアップ:
- pip経由でインストールするPythonパッケージ。
vllm serveで起動するOpenAI互換APIサーバー。ほとんどのデプロイでNVIDIA GPUとCUDAが必要。 - 最適な用途:
- 本番環境における高スループット・複数ユーザー向けGPUサービング。
Ollama
- インターフェースとセットアップ:
- CLIとREST API。ほとんどのプラットフォームでllama.cppをバックエンドとして使っていると一般に報告されている。1コマンドでインストールでき、1コマンドでモデルを取得・実行できる。
- 最適な用途:
- ビルド手順やGPUなしで、単一ユーザー向けにローカルモデルを最も早く動かす方法。
LM Studio
- インターフェースとセットアップ:
- Mac、Windows、Linux向けのグラフィカルなデスクトップアプリ。ダウンロードしてインストールし、アプリ内でモデルを閲覧・ダウンロードする。
- 最適な用途:
- クリック操作のローカルチャットアプリが欲しい非技術系ユーザー。
llama.cpp
- インターフェースとセットアップ:
- CLI、内蔵Web UI、llama-server経由のOpenAI互換API。ソースからビルドするか、ビルド済みバイナリを使用。CPUまたはGPUで動作する。
- 最適な用途:
- エンジンレベルでの直接的な制御、組み込み・エッジデプロイ、CPUやApple Siliconハードウェア。
本記事はこれらのツール間の速度や出力品質を独自にベンチマークしておらず、どれかが技術的に優れていると主張するものではありません——上の比較は文書化されたアーキテクチャ、セットアップ、アクセスモデルの事実のみを扱っています。ハードウェアごとのスループット数値については、llama.cpp vs. Ollama vs. vLLM比較とエンタープライズ推論サーバーガイドを参照してください。
本記事がカバーしていないこと
これはvLLMの公開ドキュメントとリポジトリに基づいた解説記事であり、実践的なベンチマークレポートではありません。
- 独自に測定したスループット、レイテンシ、秒あたりリクエスト数の数値はなし——これらはGPU、モデル、バッチ構成、vLLMのバージョンに大きく依存する
- 特定の量子化フォーマットについて独自に検証した品質低下の割合はなし——これはモデルアーキテクチャとタスクによって変わる
- vLLMのコードベースの行ごとのセキュリティ監査はなし——オープンソースでApache 2.0ライセンスのため、コード自体はレビュー可能
- サポートされているすべてのハードウェアバックエンド、エンジンフラグ、デプロイオーケストレーションオプション（Kubernetes、クラウド固有の設定）を網羅していない——本記事は多くのチームが最初に評価する概念とフラグに焦点を当てている
- 商用サポート契約やvLLMのマネージドホスティングサービスについては扱っていない。vLLM自体はサポート契約付きのベンダー製品ではなく、コミュニティ主導のオープンソースプロジェクトであるため
vLLMを試す際によくある間違い
vLLMにまつわる摩擦の多くは、本番サーバーソフトウェアではなく単一ユーザー向けデスクトップツールとして扱うことから生じます。
よくある質問
vLLMとは何ですか？
vLLMは、UC BerkeleyのSky Computing Labで生まれた、高スループットLLM推論のための無料でApache 2.0ライセンスのライブラリ兼サーバーです。PagedAttentionとcontinuous batchingを使い、1台のGPUから多数の同時リクエストを効率的に処理します。
vLLMは無料ですか？
はい。vLLMはApache 2.0ライセンスの下で公開されている無料のオープンソースソフトウェアで、自分で実行するのにサブスクリプションやアカウントは不要です。
PagedAttentionとは何ですか？
PagedAttentionは、リクエストごとに1つの大きな連続領域を割り当てるのではなく、小さな固定サイズの非連続なブロックでアテンションKVキャッシュを管理するvLLMの技術で、GPUメモリの無駄を減らし、共通の接頭辞を持つリクエスト間でメモリを共有できるようにします。
vLLMにはGPUが必要ですか？
実際のワークロードでは必要です——vLLMの主要な、最もサポートが手厚いターゲットはNVIDIA GPUです。CPU専用バックエンドは存在しますが大幅に遅いと文書化されておりプロジェクトの焦点ではなく、Apple Siliconサポートは第一級の経路ではなくコミュニティメンテナンスの追加機能に限られています。
vLLMはどの量子化フォーマットをサポートしていますか？
vLLMはAWQ、GPTQ、FP8、INT8/INT4を含む複数のフォーマットをサポートしており、これらのフォーマットで事前量子化された多くのモデルがHugging Faceで公開されています。
vLLMはOllamaより優れていますか？
「優れている」は目的次第です。vLLMは高並行性の本番GPUサービング向けに構築されており、OllamaはGPU不要で単一ユーザー向けローカルモデルに最速でたどり着くために構築されています。ほとんどのユースケースで近い代替関係にはありません——上の比較表を参照してください。
vLLMは複数のGPUにまたがってモデルをサービングできますか？
はい。vLLMは複数のGPUにまたがるテンソル並列・パイプライン並列サービングをサポートしており、サーバー起動時に--tensor-parallel-sizeなどのフラグで設定できます。
vLLMにはOpenAI互換APIがありますか？
はい。vllm serveを実行するとOpenAI APIプロトコルを実装したサーバーが起動し、OpenAI API向けに構築された多くのアプリケーションが、ベースURLとモデル名を変更するだけで自己ホストのvLLMインスタンスを指せます。
vLLMはTensorRT-LLMとどう違いますか？
TensorRT-LLMはNVIDIAのエンジンで、モデルを特定のNVIDIA GPU向けに最適化されたエンジンへ事前にコンパイルします。vLLMはHugging Face Transformers互換モデルを事前コンパイルステップなしで直接読み込み、NVIDIA GPU以外へのバックエンドサポートも文書化しています。ハードウェア固有の最適化はやや劣りますが、柔軟性が高く反復も速くなります。