GitHub Repo
vLLMコミュニティのテスト:WSL2でページロックメモリを有効化し、単一GPUのデコードレイテンシが約12%低下
単一マシンでのテストでは、メモリ設定の変更によりデコード時のGPU待機時間が短縮した。公式の既定値は引き続き無効で、効果と容量制限はデプロイ環境ごとに検証する必要がある。

9月26日、vLLMコミュニティがWSL2での比較テストを報告した。RTX 3090、vLLM 0.30.0、Qwen3-8B-AWQを使い、ページロックメモリを有効にしたところ、出力トークン間隔は約8.7~9.0ミリ秒から7.7~7.8ミリ秒に短縮し、約12%低下した。これはユーザーから寄せられた性能データであり、既定の設定に変更はない。[テスト報告](https://github.com/vllm-project/vllm/issues/58849)
今回の変更にモデルの再量子化は不要で、起動前に `VLLM_WSL2_ENABLE_PIN_MEMORY=1` を設定する。公式ドキュメントに記載された既定値は引き続き0だ。対応するWSL2カーネルではページロックメモリを利用できるが、過去にわずかな性能低下が確認されたため、選択制になっている。エンジニアリングチームは新バージョンを待たずに試せるスイッチをすでに用意している。[環境変数のドキュメント](https://docs.vllm.ai/en/latest/configuration/env_vars/)
今回のプロファイリング報告では、設定の切り替え前後でGPUの稼働時間はほぼ変わらなかった一方、アイドル時間は1ステップあたり1.29ミリ秒から0.16ミリ秒に減少した。このことから、主な効果はデータ転送に伴う待ち時間の削減によるものと推測される。[性能プロファイリング](https://github.com/vllm-project/vllm/issues/58849)
これは、新しい実行エンジンの互換性設計にも関係する。Model Runner V2はもともと、ページロックメモリを必要とする統一仮想アドレス指定(UVA)と固定ポインタを利用していた。9月15日にマージされた変更により、ページロックメモリをサポートしていない、または有効にしていないプラットフォームでも動作できるようになった。起動が可能になったことで、異なるメモリアクセス経路による性能差を改めて測定する価値が出てきた。デプロイの観点では、ローカルサービスのチューニングでモデルサイズや量子化形式を比較するだけでなく、実行エンジンが実際にどのデータアクセス経路を使っているかも確認する必要がある。[上流の修正](https://github.com/vllm-project/vllm/pull/56908)
今回のテストは1台のマシンに限られている。単一リクエストのレイテンシテストでは、有効・無効の2条件を交互に実行し、各条件で2ラウンド、各ラウンドで3件のリクエストを処理した。また、KVキャッシュ容量は固定していた。再現可能な設定が示されたものの、他のGPUや本番サービスの負荷でも同様の効果が得られるとはまだ言えない。[テスト方法](https://github.com/vllm-project/vllm/issues/58849)
ページロックメモリは、システムメモリのページを常駐状態に保ち、GPUがアクセスできるようにする。NVIDIAによると、WSL2で利用できるページロック済みシステムメモリには容量制限があり、一部のワークロードでは上限を超えて動作できなくなる可能性がある。エンジニアは次に、モデル、キャッシュ容量、並行数を固定して、レイテンシ分布、スループット、メモリ使用量を比較するとよい。対話型チャットではトークンごとのレイテンシに注目し、バッチ処理では負荷を高めても効果が続くかを確認する。そのうえで、異なるハードウェアでの再測定結果や、上流で既定値が変更されるかどうかを見守りたい。[CUDA on WSLのドキュメント](https://docs.nvidia.com/cuda/wsl-user-guide/index.html)