vLLM on an RTX 5090 (sm_120) in November 2026: versions, Docker, quantization kernels, 32 GB flags and fixes

vLLM runs on the RTX 5090 (compute capability 12.0, "sm_120") with the stock release: as of 7 November 2026 that is v0.33.0, published 2 November 2026, whose wheels and Docker images are built for CUDA 13.0 only and bundle PyTorch 2.14.0, so the card needs a driver from NVIDIA's R580 branch or newer. FP8, NVFP4 (W4A4), AWQ and GPTQ all have working kernels on sm_120; weight-only NVFP4 checkpoints and NVFP4 mixture-of-experts layers still use the Marlin weight-only path by default instead of a native FP4 kernel. On 32 GB the binding limits are weights and CUDA graph memory: vLLM's own recipe for Qwen3.8-27B on one 5090 uses NVFP4 weights, a 32k context, an FP8 KV cache and --enforce-eager.

All rows read on 7 November 2026. The vLLM docs page still says default binaries use CUDA 12.9; the v0.33.0 release notes are newer and say CUDA 12.9 wheels and -cu129 images are no longer published.

Which vLLM, CUDA and driver versions work on an RTX 5090?

Any current release does; the version trouble is history, but it explains most of the errors people still paste into forums. The timeline from vLLM's GitHub:

• April 2025: Issue 16901: the PyPI wheel on an RTX 5090 with driver 570.124.06 and CUDA 12.8 fails with "no kernel image is available for execution on the device". A maintainer wrote on 26 June 2025 that SM120 support had landed in the wheel and Docker image (PR 19794). FP8 models had needed an extra SM120 CUTLASS patch before that.
• February to May 2026: Issue 35432 reports prebuilt wheels and images failing again on RTX 50 cards, with "sm_120 is not compatible with the current PyTorch installation". A contributor's advice was to use CUDA 13.x builds; the issue was closed as completed on 15 May 2026.
• 18 October 2026, v0.32.0: CUDA 13.0 becomes the default build (CUDA 12.9 images still published), Python 3.10 is dropped, and the NVFP4 KV cache runs on SM12x.
• 2 November 2026, v0.33.0: CUDA 13.0 only, PyTorch 2.14.0.

The driver follows from the CUDA version. NVIDIA's CUDA release notes map CUDA 13.0 to the R580 driver branch and require 580 or newer for minor-version compatibility across 13.x; CUDA 12.8 needed 570.26 on Linux. Check what you have before installing anything:

nvidia-smi
python -c "import torch, vllm; print(torch.__version__, torch.version.cuda, torch.cuda.get_device_capability(0), vllm.__version__)"

The second line should print a 2.14 torch, CUDA 13.0, (12, 0) for the capability, and 0.33.0. If torch is older than the one vLLM pinned, something else in the environment replaced it, which is a typical way to end up with "no kernel image" in 2026.

Docker or pip?

Docker if you have it, uv otherwise; both install the same CUDA 13.0 build. The Docker docs use the official image with the host's shared memory, which PyTorch needs to pass data between processes. Pin the version tag instead of latest, so a restart does not pull a different build:

docker run --runtime nvidia --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --env "HF_TOKEN=$HF_TOKEN" \
  -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:v0.33.0 \
  --model Inferact/Qwen3.8-27B-NVFP4 \
  --max-model-len 32768 \
  --kv-cache-dtype fp8 \
  --enforce-eager \
  --reasoning-parser qwen3

Without Docker, use a fresh virtual environment so no older torch wheel can shadow the bundled one. The install docs give this, and v0.32.0 added vllm download-kernels, which installs FlashInfer's precompiled kernels instead of compiling them on first start:

uv venv --python 3.12 --seed --managed-python
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm download-kernels
vllm serve Inferact/Qwen3.8-27B-NVFP4 \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --kv-cache-dtype fp8 \
  --enforce-eager \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder

The tool-calling flags are taken from the recipe's two-card command and are optional; which parser each model family needs, and how to test it, is in the function calling guide. On a DGX Spark (sm_121 on ARM64) the install differs again, as the vLLM on DGX Spark page explains. Not every rented GPU gives you a Docker daemon (GPUwerk's DGX Spark instances, for example, are themselves containers, as the tenant environment page explains), so the uv route is the one that works everywhere.

Which quantization formats have working kernels on sm_120?

FP8, NVFP4 W4A4, AWQ and GPTQ all run; what varies is whether you get a native FP4 kernel or the Marlin weight-only fallback. vLLM's own quantization support table stops at Hopper and has no Blackwell column (checked 7 November 2026), so this table is compiled from recipes, release notes and issues:

The RTX PRO 6000 Blackwell is the same sm_120 architecture as the RTX 5090, which is why its reports apply. The GPT-OSS recipe still says the team is "actively working on" RTX 5090 support for that model, so treat MXFP4 on a 5090 as reported to work rather than documented.

The W4A16 row trips people up. A contributor explained in issue 47749 that weight-only FP4 checkpoints carry no activation scales, so no native FP4 GEMM exists for them on any GPU; vLLM routes them to Marlin by design, and the warning saying your GPU lacks FP4 support is simply wrong about the reason. If you want the native kernel, pick a W4A4 checkpoint. For how NVFP4, MXFP4 and FP8 differ in block size and accuracy, see the sibling article on NVFP4 vs MXFP4 vs FP8; the GB10 steps for the same formats are on the quantization page.

How do you fit a 27B model and its context into 32 GB?

Use 4-bit weights, an FP8 KV cache and a context cap, then spend what is left on concurrency. An FP8 build does not fit: the recipe's two-card table shows 14.28 GiB of FP8 weights per GPU at tensor parallel 2, about 28.6 GiB for the model, against 31.4 GiB usable on one card.

KV cache, by my calculation from the config.json: only 16 of Qwen3.8-27B's 64 layers are full attention (the rest are linear attention with a small fixed state), each with 4 KV heads of dimension 256.

• Per token in FP8: 2 (K and V) × 16 × 4 × 256 × 1 byte = 32,768 bytes, or 32 KiB. In BF16, 64 KiB.
• One full 32k conversation: 32,768 × 32 KiB = 1 GiB.
• The recipe's 91,022 cache tokens are about 2.8 GiB, so roughly three full-length 32k requests at once, or many more short ones.

The recipe measured how flags move that number on one 5090:

KV token counts from the vLLM Qwen3.8-27B recipe, updated 15 October 2026. The last column is my division by 32,768. BF16 KV does not halve the count because the linear-attention state and other fixed buffers take a share of the same pool (my inference).

The flags that matter, with defaults from the engine arguments page:

• --gpu-memory-utilization: share of GPU memory vLLM may use; 0.92 by default, or 1.0 with the newer extensible KV cache. The recipe notes that lowering it does not cure the CUDA graph out-of-memory error.
• --max-model-len: set it to the longest prompt plus output you need. Leaving it at the model's 262,144 is the usual reason a 5090 refuses to start.
• --kv-cache-dtype fp8: doubles cache tokens against BF16 in principle; nvfp4 is accepted on SM12x from v0.32.0, and a prototype in issue 49011 reached 244,928 tokens on a 5090 against about 163k with FP8.
• --enforce-eager: turns CUDA graphs off. It frees the memory graph capture needs, at a speed cost (one sm_120 report measured rounds about 23.6% slower).
• --max-num-seqs: caps the batch; a lower cap shrinks the activation reserve.

A smaller model leaves far more room. gpt-oss-20b ships in MXFP4 at about 14 GB (the size of the gpt-oss:20b download), and per its config.json only 12 of its 24 layers keep a full KV cache (the other 12 use a 128-token sliding window), with 8 KV heads of dimension 64. In BF16 that is 2 × 12 × 8 × 64 × 2 bytes = 24 KiB per token, so a full 131,072-token context costs 3 GiB. With roughly 15 GiB left after weights and overhead, by my estimate, that is around 600,000 cache tokens, enough for several long-context users at once. The sibling article on KV cache size by model has the same arithmetic for other models.

What errors do people hit, and what fixes them?

Almost all of them trace to a mismatched build, CUDA graph memory, or NVFP4 kernel selection.

Issue 54331 was reported on an RTX PRO 6000 Blackwell (sm_120, 96 GB); a commenter could not reproduce it in October 2026 on a different setup. Status of all issues as read on 7 November 2026.

What speed should you expect?

For a dense 27B model at 4-bit, roughly 85 to 95 tok/s for one request and several hundred to about a thousand tok/s in total under load, according to third-party tests. GPUwerk has published no RTX 5090 measurements of its own; its only vLLM runs are on a DGX Spark, on the benchmarks page (vLLM 0.27.1, 2 September 2026).

Reported figures, read 7 November 2026. Test conditions differ (prompt length, output length, drafting), so compare rows only within one source. More engines and models are in the sibling RTX 5090 LLM benchmarks article.

The single-request numbers sit close to the card's limit. Decode reads all weights once per token, so 1,792 GB/s (per NVIDIA's spec table) divided by roughly 16.5 GB of 4-bit weights caps a dense 27B model near 109 tok/s by my calculation; MTP drafting is the only way past that, because it verifies several tokens per weight read. If one card is not enough memory, the next step is two cards with tensor parallel 2 (Paralon reports 149 to 156 tok/s for one request on two 5090s) or a 128 GB machine; the DGX Spark vs RTX 5090 comparison covers that trade.

FAQ

Sources

Every figure above is attributed to its source in the sentence or table where it appears. Pages were read on 7 November 2026 unless a date says otherwise.

• Releases · vllm-project/vllm, GitHub, 2026-11-02
• GPU installation, vLLM docs
• Using Docker, vLLM docs
• Engine arguments, vLLM docs
• Quantization, vLLM docs
• Qwen3.8-27B on vLLM, vLLM recipes, 2026-10-15
• GPT-OSS recipe, vLLM recipes
• RuntimeError on RTX 5090: no kernel image is available (issue 16901), GitHub, 2025-04-21
• Prebuilt vLLM wheels / official images fail on RTX 50-series (issue 35432), GitHub, 2026-02-26
• RTX 5090 / SM120 ModelOpt mixed NVFP4 checkpoint falls back to Marlin W4A16 (issue 47749), GitHub, 2026-07-06
• Add SM120 support for native NVFP4 MoE kernels (issue 31085), GitHub, 2025-12-20
• RTX 5090 (SM120): Nemotron-3-Nano-30B-A3B-NVFP4 fails to start (issue 35065), GitHub, 2026-02-22
• sm_120 hybrid-GDN NVFP4 dies under sustained load with CUDA graphs (issue 54331), GitHub, 2026-08-29
• nvfp4 KV cache on SM120 (issue 49011), GitHub, 2026-07-18
• GPT-OSS-120B MXFP4 on RTX PRO 6000 Blackwell Max-Q (SM120): full debug path, NVIDIA Developer Forums, 2026-04-01
• CUDA Toolkit release notes, NVIDIA
• Qwen/Qwen3.8-27B config.json, Hugging Face
• openai/gpt-oss-20b config.json, Hugging Face
• Compare GeForce graphics cards, NVIDIA
• gpt-oss, Ollama library
• Ollama vs vLLM vs llama.cpp: Speed Benchmarked, ComputingForGeeks, 2026-10-06
• 2x RTX 5090 vLLM Benchmark on Qwen3.8-27B, Paralon Cloud, 2026-10-12
• RTX 4090 vs 5090 vs PRO 6000: LLM Inference Benchmark, CloudRift, 2025-10-09