発生原因vLLMは高いスループットを実現するように設計されており、GPUメモリを非常に積極的に使用します。エンジンが初期化される際、KV（Key-Value）キャッシュ専用にVRAMの大部分を確保しようとします。この事前割り当てが高速動作の秘訣ですが、同時に起動時のクラッシュの最も一般的な原因でもあります。モデルの重み、システムのオーバーヘッド、および要求されたキャッシュサイズの合計がVRAM容量を超えると、サーバーは即座に停止します。
このクラッシュは通常、モデルがハードウェアに対して大きすぎる場合や、バックグラウンドプロセスがすでにGPUを占有している場合に発生します。わずかな隠れたメモリ使用量であっても、vLLMを限界まで追い込む可能性があります。
エラーメッセージ```
ValueError: No available memory for the cache blocks. Try increasing gpu_memory_utilization when initializing the engine.
## デバッグプロセスまずはハードウェアの現在の状態を確認することから始めましょう。`nvidia-smi`を実行して、VRAMを占有しているゾンビプロセスやGUIアプリケーションを特定します。標準的なUbuntuデスクトップでは、X11ウィンドウシステムやGNOMEが簡単に500MBから1GBのメモリを占有することがあります。
次に、モデルの重みを計算します。FP16（16ビット）でロードされた7Bパラメータのモデルには、約14GBのVRAM（70億 * 2バイト）が必要です。24GBのVRAMを搭載したRTX 3090を使用している場合、残りは約10GBです。しかし、vLLMのデフォルト設定では合計24GBの90%（21.6GB）を確保しようとしますが、モデルの重みですでに14GB占有されているため、これは不可能です。14GB + 21.6GBは24GBの制限を超えるため、エンジンがクラッシュします。
## 解決策### 1. GPUメモリ使用率の調整デフォルトでは、vLLMは全VRAMの90%（0.9）をターゲットにします。他のアプリが動作している場合は、この値を下げる必要があります。逆に、GUIのない専用サーバーでは、より大きなモデルを収めるために0.95まで上げることも可能です。
CLIユーザーの場合は、使用率を80%に下げてみてください：
python -m vllm.entrypoints.openai.api_server
--model mistralai/Mistral-7B-v0.1
--gpu-memory-utilization 0.8
Python APIを使用している場合は、以下のようにLLMオブジェクトを設定します：
from vllm import LLM llm = LLM(model="mistralai/Mistral-7B-v0.1", gpu_memory_utilization=0.8)
### 2. 最大モデル長の制限`max_model_len`（コンテキストウィンドウ）は、各KVキャッシュブロックが消費するVRAM量に直結します。32kトークンの膨大なコンテキストウィンドウが必要ない場合は、4096や8192に削減することで数ギガバイトを解放できます。これは、モデルの品質を犠牲にすることなくサーバーを稼働させるための最も簡単な方法です。
python -m vllm.entrypoints.openai.api_server
--model mistralai/Mistral-7B-v0.1
--max-model-len 4096
--gpu-memory-utilization 0.9
### 3. 量子化の使用モデルの重み自体がカードに対して重すぎる場合は、AWQやGPTQのようなより効率的なフォーマットが必要です。FP16から4ビット量子化に切り替えることで、重みのメモリフットプリントを約70%削減できます。例えば、通常2枚のA100を必要とするLlama-3-70Bモデルも、量子化すれば1枚のカードに収まる可能性があります。
python -m vllm.entrypoints.openai.api_server
--model TheBloke/Llama-2-7B-Chat-AWQ
--quantization awq
### 4. CUDAグラフキャプチャの無効化vLLMは、CPUのオーバーヘッドを最小限に抑え、スモールバッチ処理を高速化するためにCUDAグラフを使用します。この機能は高速ですが、初期化中に約1〜2GBのVRAMを「税金」として事前に必要とします。メモリがわずかに足りない場合は、この機能を無効にしてeagerモードにすることで、クラッシュを防ぐのに十分なスペースを確保できることがあります。
python -m vllm.entrypoints.openai.api_server
--model mistralai/Mistral-7B-v0.1
--enforce-eager
## 修正の確認方法起動中にターミナルのログを詳しく観察してください。エンジンがブロックの割り当てを正常に計算していることを確認します。以下の特定のINFO行を探してください：
INFO 05-22 10:00:00 llm_engine.py:150] # GPU blocks: 1240, # CPU blocks: 512
ログが`Uvicorn running on http://0.0.0.0:8000`に到達すれば、メモリ設定は安定しています。サーバーがアイドル状態のときに`nvidia-smi`を実行して最終的なメモリフットプリントを確認してください。ほぼ満杯に見えるはずですが、これはvLLMの正常な動作です。
## 重要なポイント- **重みがベースライン：** vLLMは最初にモデルの重みをロードします。残ったVRAMが、`gpu_memory_utilization`に基づいてKVキャッシュ用に分割されます。- **90%ルールは目安：** コンシューマー向けカード（RTX 3090/4090）では、バックグラウンドのOSタスクがしばしば1〜2GBを消費します。24GBのカードで利用率を0.9に設定すると、21.6GBが空いていることを前提としますが、モニターを接続している場合はそうなることは稀です。- **コンテキストはVRAMを大量に消費する：** コンテキストウィンドウ内の余分なトークンごとに、サーバーが処理できる並列リクエストの数が減少します。