vLLM Community Test: Enabling Pinned Memory in WSL2 Cuts Single-GPU Decoding Latency by About 12%

On September 26, the vLLM community published a WSL2 comparison test: on an RTX 3090 running vLLM 0.30.0 and Qwen3-8B-AWQ, enabling pinned memory reduced the interval between output tokens from about 8.7–9.0 milliseconds to 7.7–7.8 milliseconds, a reduction of about 12%. This is performance evidence submitted by a user; no default setting has changed so far. [Test report](https://github.com/vllm-project/vllm/issues/58849)

The change does not require requantizing the model. Instead, set `VLLM_WSL2_ENABLE_PIN_MEMORY=1` before startup. The default listed in the official documentation remains zero. It notes that compatible WSL2 kernels support pinned memory, but that the feature remains optional because it has previously caused minor performance regressions. Engineering teams can test the switch now without waiting for a new release. [Environment variables documentation](https://docs.vllm.ai/en/latest/configuration/env_vars/)

The profiling report found that GPU busy time was nearly unchanged before and after enabling the switch, while idle time fell from 1.29 milliseconds per step to 0.16 milliseconds. This suggests that the main benefit comes from reducing waits caused by data transfers. [Performance profile](https://github.com/vllm-project/vllm/issues/58849)

This also relates to compatibility design in the newer executor. Model Runner V2 originally used Unified Virtual Addressing (UVA) and fixed pointers, which require pinned memory. A change merged on September 15 enabled it to run on platforms that do not support or have not enabled pinned memory. Now that successful startup is possible, the performance gap between different memory paths is worth measuring again. For local deployments, this suggests that tuning should include checking the data access path actually used by the executor, alongside comparing model sizes and quantization formats. [Upstream patch](https://github.com/vllm-project/vllm/pull/56908)

One limitation is that the test used only a single machine. The single-request latency test alternated between the enabled and disabled configurations, with two rounds of three requests per configuration, and kept KV cache capacity fixed. It provides a reproducible setting, but not enough evidence to conclude that other GPUs or production workloads will see the same benefit. [Test methodology](https://github.com/vllm-project/vllm/issues/58849)

Pinned memory keeps system memory pages resident so the GPU can access them. NVIDIA notes that WSL2 has a capacity limit for pinned system memory, and some workloads may exceed it and fail to run. Engineers should next compare latency distributions, throughput, and memory usage while holding the model, cache capacity, and concurrency constant. For interactive chat, they can focus on per-token latency; for batch serving, they should check whether the benefit persists as load increases, then monitor retests across hardware and whether upstream changes the default. [CUDA on WSL documentation](https://docs.nvidia.com/cuda/wsl-user-guide/index.html)