実行プログラムと拡張機能
最終更新
vLLMローカルサーバーの設定：小さなモデルから0.30の適応型検証まで
vLLMでローカルLLMサーバーを起動し複数のリクエストを処理する
vLLMはモデルをメモリに保持し、API1で届く質問に回答を生成するLLM2サーバーです。複数のリクエストをまとめて処理し、会話のコンテキストをキャッシュで管理してGPU3を活用します。小さなモデルで接続を確認してからモデルと同時リクエスト数を決め、0.30.0のDFlash・DSparkによる高速化や適応的検証を試せます。
個人用コーディング支援では最初のトークン4待ちと回答完了時間が重要で、複数利用者向けサーバーでは処理量も見ます。vLLMのcontinuous batchingは複数要求でGPUを活用しますが、サーバー処理量は個人の応答時間と同じではありません。
個人の応答遅延とサーバー処理量は別指標
複数の人が同時に質問すると、vLLMは進行中のリクエストをまとめてGPUで計算します。これがcontinuous batchingです。サーバー全体が1秒に生成したトークンの合計が処理量で、自分の質問の最初のトークンと完了までの時間が体感する応答速度です。
同時利用者が増えると全体の完了量が増えても個別要求はキューで待つ場合があり、要求ごとのKV cache5もメモリを使います。同時負荷の結果を個人利用の応答速度へ読み替えません。
CUDAサーバーの基本接続から検証
この接続例は互換性のあるLinux NVIDIA CUDA6環境を前提とします。別の仮想環境7または機器用コンテナを使いPyTorch8・CUDA・ドライバー構成を記録します。DGX SparkにはARM64・Blackwell対応ビルドが必要で、x86イメージをそのまま使いません。MacのCPU/MLXとコミュニティ製vllm-metalはCUDAサーバーとは別経路です。
まずQwen2.5-1.5B-Instructでモデル読み込みと応答を確認します。コンテキスト4096・同時シーケンス1は接続確認用であり、最新モデルや最高速度の推奨値ではありません。初回ダウンロードと準備時間は生成速度と分けます。
最初のコマンドでモデルが読み込まれ、サーバーの準備完了が表示されたら、別のターミナルでcurlリクエストを実行します。回答が返ったら、エディターやチャットアプリのOpenAI互換ベースURLをhttp://127.0.0.1:8000/v1に設定します。モデルIDとポートを両方のコマンドで一致させます。
vllm serve Qwen/Qwen2.5-1.5B-Instruct \
--host 127.0.0.1 --port 8000 \
--max-model-len 4096 --max-num-seqs 1curl --fail-with-body http://127.0.0.1:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"Qwen/Qwen2.5-1.5B-Instruct","messages":[{"role":"user","content":"Explain what a local AI server does in two sentences."}],"max_tokens":64,"temperature":0}'
モデルとメモリ条件を先に合わせる
対象モデルのファイル名・revision・精度・コンテキスト長を記録します。NVFP49とGGUF10 Q4はどちらも4-bitでも互換設定ではなく、GPU世代・モデル構造・ランタイム11の対応が必要です。重み以外に入力KV cacheと作業領域も必要です。
--max-model-lenは入出力を合わせたコンテキスト上限で、まず--max-num-seqs 1で確認します。--gpu-memory-utilizationを上げるとKV cacheなどの領域を増やせますが、OSや他プロセスの余裕が減ります。エラー時はコンテキストと同時数を一つずつ減らします。
要求数が増えると合計処理量が増えても個人の完了時間は延びる場合があります。個人用コーディング支援では処理量だけでなく最初のトークンからコード完成までを記録します。
vLLM 0.30.0のadaptive verification要件を確認
コンテナまたは仮想環境でvLLM 0.30.0を固定し、vllm --versionで確認します。DeepSeek-V4-Flash-DSparkとtokenizerが機器・attention12 backendで対応するか調べます。例のdeepseek_v4 tokenizerと--trust-remote-codeはモデル提供コードを実行し得るため、出所と実行環境を確認します。
adaptive verificationはCUDA graphで段階コストを計測します。full cudagraphが必要な構成では--enforce-eagerが拒否される場合があり、公式資料はLoRA13・pipeline parallelism14の制限も示しています。モデルとKV cacheのメモリ、backend、graph captureを先に確認します。
基準接続を確認した後、DeepSeek-V4-Flash targetとDSpark draftを用意します。例の投機トークン数7・probabilistic samplingはその資料の設定であり、別draftの推奨深さではありません。ログと採用統計で意図したtarget・draftが有効か確認します。
この節のサーバー例はすべて8000ポートです。小モデルのサーバーをCtrl+Cで止めてからDeepSeekを起動し、別ターミナルでリクエストを確認します。DSparkへの変更でも前のサーバーを終了します。旧プロセスがGPUメモリを保持しているなら、終了を確認してから次を起動してください。
DSpark配布版はDeepSeek-V4-Flashのチェックポイント15へ推測デコード16モジュールを追加したものです。下のコマンドはサーバーモデルとdraft設定の両方にdeepseek-ai/DeepSeek-V4-Flash-DSparkを指定します。切り替え後は/v1/modelsでIDを確認し、次のリクエストにも同じIDを使います。前の通常Flash用リクエストは基準サーバーの確認に使ってください。
vllm serve deepseek-ai/DeepSeek-V4-Flash --host 127.0.0.1 --port 8000 --tokenizer-mode deepseek_v4 --trust-remote-codecurl -sS http://127.0.0.1:8000/v1/models
curl -sS http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"deepseek-ai/DeepSeek-V4-Flash","messages":[{"role":"user","content":"Reply with one short sentence."}],"temperature":0,"max_tokens":64,"stream":false}'vllm serve deepseek-ai/DeepSeek-V4-Flash-DSpark --host 127.0.0.1 --port 8000 --tokenizer-mode deepseek_v4 --trust-remote-code --speculative-config '{"method":"dspark","model":"deepseek-ai/DeepSeek-V4-Flash-DSpark","num_speculative_tokens":7,"draft_sample_method":"probabilistic","enable_adaptive_verification":true}'curl --fail-with-body http://127.0.0.1:8000/v1/models
curl --fail-with-body http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"deepseek-ai/DeepSeek-V4-Flash-DSpark","messages":[{"role":"user","content":"Reply with one short sentence."}],"temperature":0,"max_tokens":64}'要求負荷ごとに遅延・処理量・採用率を比較
同じコード編集要求で同時数1件と複数件を試します。target・draft・入出力長・sampling・GPU・メモリを固定し、同時数だけ変えて複数回測ります。モデル読み込みとCUDA graph capture時間は要求処理と分けて記録します。
単一要求ではTTFT17・トークン間遅延・完了時間を、サーバー全体では完了要求数やtokens/sを記録します。acceptance統計・GPUメモリ・preemption・OOMも追跡します。同時数が増えると処理量は上がっても個人の待ち時間が延びる場合があります。
リリースノートではH200のgraph captureが約12秒から2秒、engine initが約28.9秒から8.2秒になったと説明しています。GC freezeの変更によるモデル起動の準備段階の改善です。応答時間とサーバー起動時間を分けて記録すると、運用のどの工程が短くなったか確認できます。
起動に失敗したらbackendのdevice-decided query length対応・full cudagraph・LoRA/pipeline parallelism条件を確認します。動くが効果がない場合は採用率・負荷時のdraft競合・短い出力での準備コストを調べ、一条件だけ変えて再試験します。
公式資料を再現環境に合わせる
0.30.0リリースとadaptive verification資料で導入版・モデル・機器対応を確認します。最新main文書やコンテナタグは0.30.0と異なる場合があるため、試験版の資料を基準にします。
vLLM 0.31.0で再起動時のモデル読み込みを短縮する
vLLMサーバーを再起動すると、大きなモデルファイルを再び読み、GPUに載せるまで待つ必要があります。0.31.0のvllm preloadは別のデーモンでGPU上の重みを保持し、新しいサーバープロセスが再利用できるようにします。開発や設定変更で同じモデルを頻繁に再起動する場合に便利です。
一つ目のターミナルでデーモンを起動し、別のターミナルで--load-format ipc_cacheを指定してサーバーを開始します。例はGPU一枚でQwen3-8Bを実行します。キャッシュの再利用にはモデル・バージョン・並列化・dtype・量子化18設定の一致が必要です。異なる場合はディスクから読み直します。
preloadは0.31.0の別環境で試します。0.30.0サーバーを止め、0.31.0を入れた仮想環境かコンテナーへ切り替え、vllm --versionを確認します。デーモンとサーバーの両ターミナルは同じ0.31.0環境にしてください。旧サーバーが8000ポートを解放した後、下の二段階を始めます。
vllm preload --model "Qwen/Qwen3-8B" --tensor-parallel-size 1vllm serve "Qwen/Qwen3-8B" --tensor-parallel-size 1 --load-format ipc_cache --host 127.0.0.1使い終わったらpreloadデーモンも終了します。
preloadデーモンが動いている間、モデルの重みはGPUメモリに残ります。サーバーだけを停止・再起動しても保持されます。別の作業でGPUを使う前にデーモンのターミナルでCtrl+Cを押し、nvidia-smiやROCm19の管理ツールでメモリが戻ったことを確認します。
CUDA・ROCm環境のテンソル・エキスパート・データ並列化に対応します。パイプライン並列化は非対応で、量子化方式によってはUnsupportedQuantForIPCErrorが発生します。Apple Siliconのvllm-metalは別のプロジェクトなので、この機能を適用しません。preloadは再起動の待ち時間を短縮する機能であり、回答の生成速度は別に測定します。
用語の注釈
API — 別のコードからプログラムの機能を呼び出すための決められたインターフェースです。
本文に戻る大規模言語モデル — 大量のテキストデータから言語パターンを学び、文脈に沿ったテキストを処理・生成するモデルです。
本文に戻るGPU — 多くの計算を並列に処理するプロセッサーです。AIモデルの実行ではモデル計算を担います。
本文に戻るトークン — モデルが入力や出力を分けて処理する単位です。
本文に戻るKVキャッシュ — 過去トークンのAttention用キー・バリューを保存し、後続トークン生成で再利用するメモリです。容量はコンテキスト長やバッチサイズで変わります。
本文に戻るCUDA — NVIDIA GPUで汎用計算を行うソフトウェア基盤です。
本文に戻るPython仮想環境 — プロジェクトごとにPythonパッケージを分けて導入する環境です。パッケージのバージョンの衝突を減らせます。
本文に戻るPyTorch — AIモデルを作成・実行するソフトウェアフレームワークです。モデルと合わせて、対応するPyTorchの版やハードウェアも確認します。
本文に戻るNVFP4 — NVIDIAが定義した4ビット浮動小数点データ形式です。対応状況はGPU世代、モデル、ソフトウェア実装によって異なります。
本文に戻るGGUF — モデル情報を格納するファイル形式で、llama.cpp系のツールで広く使われます。
本文に戻るランタイム — プログラムの実行時に必要な機能を提供するソフトウェア環境です。ローカルAIではモデル実行エンジンを指すこともあります。
本文に戻るAttention — 入力トークン間の関連度を計算し、各位置の情報を現在の表現に反映するニューラルネットワーク演算です。
本文に戻るLoRA — 基本モデルの動作を調整する小さな追加の重みを学習・適用する方法です。基本モデルとアダプターを組み合わせ、画風の調整や少ないステップでの生成などに使います。
本文に戻るパイプライン並列 — モデルの層を装置ごとの段階に分け、各段階の出力活性値を次の装置へ渡して処理する並列化方式です。
本文に戻るチェックポイント — 学習済みモデルの重みなどを保存したファイルです。同じモデル系列でも、版や用途によって異なるチェックポイントを使うことがあります。
本文に戻るトークンのデコード — 入力とそれまでの回答をもとに、次の出力トークンを順に生成する段階です。
本文に戻る最初のトークンまでの時間 — リクエスト送信から最初の出力トークンが届くまでの時間です。
本文に戻る量子化 — モデルの重みや計算値を少ないビット数で表し、保存容量やメモリ使用量を減らす方法です。表現が粗くなるため、精度にも影響することがあります。
本文に戻るROCm — AMD GPUでAIや高性能計算を実行するソフトウェア基盤です。対応状況はGPUだけでなく、OS・ドライバー・フレームワークの版の組み合わせで確認します。
本文に戻る
よくある質問
- この記事で最初に確認すべきことは何ですか？
- vLLMはモデルをメモリに保持し、APIで届く質問に回答を生成するLLMサーバーです。複数のリクエストをまとめて処理し、会話のコンテキストをキャッシュで管理してGPUを活用します。小さなモデルで接続を確認してからモデルと同時リクエスト数を決め、0.30.0のDFlash・DSparkによる高速化や適応的検証を試せます。
- 必要なメモリはどのくらいですか？
- 同時利用者が増えると全体の完了量が増えても個別要求はキューで待つ場合があり、要求ごとのKV cacheもメモリを使います。同時負荷の結果を個人利用の応答速度へ読み替えません。
変更履歴
サイトの説明を変更した記録です。インストール済みのエンジンやモデルのバージョンを自動で確認した結果ではありません。
vLLMの実行条件・リクエスト処理の案内を追加
CUDA環境の短いサーバー・API例を追加し、一般的なPC、ARM64のSpark、Macの実行経路を区別しました。1件の生成速度とサーバー全体の処理量を分け、モデルごとに量子化とMTPの対応を確認するよう説明しました。