Change the attention backend only for a reason
vLLM picks the attention backend for your GPU, and you have two reasons to override it.
A forum post says a different attention backend is faster. When you finish this section, you can read the backend vLLM picked and decide when to override it.
Our result: on our L4, a forced Triton backend fixed a start that failed in the backend vLLM picked.
Read the backend vLLM picked
vLLM writes one line at startup that names the backend and the other backends that could run. Search the log for it:
grep "attention backend" server.log
On our DGX Spark, with Qwen3-30B-A3B and the default settings, the line was:
(EngineCore pid=143) INFO 10-21 10:53:17 [cuda.py:526] Using FLASH_ATTN attention backend out of potential backends: ['FLASH_ATTN', 'FLASHINFER', 'TRITON_ATTN', 'FLEX_ATTENTION'].Know the order vLLM tries
vLLM has one list of backends for each GPU class. It removes each backend that cannot run with your model and your settings, and it picks the first one that is left. For a standard model in vLLM 0.31.0, the order is:
| GPU | Examples | Order |
|---|---|---|
| SM 10.x | B200, GB200 | FlashInfer, FlashAttention, Triton, FlexAttention, TurboQuant |
| other NVIDIA GPUs | L4 (SM 8.9), H100 (SM 9.0), DGX Spark (SM 12.1) | FlashAttention, FlashInfer, Triton, FlexAttention, TurboQuant |
The reasons for each removal go to the debug log, not to the info log. To see them, compare the list in the startup line with the table. A backend that is missing from the list was removed.
Know the switch that an FP8 KV cache makes
In vLLM 0.31.0, FlashAttention reads an FP8 KV cache only on SM 9.0 and on the SM 10.x family. So on an L4 or a DGX Spark, --kv-cache-dtype fp8 changes the backend with no warning. The FP8 KV cache page tells what happened on our L4.
Force a backend
Set the backend with --attention-backend:
vllm serve Qwen/Qwen3-8B --kv-cache-dtype fp8 --attention-backend TRITON_ATTN
If the backend you set cannot run with your model and settings, vLLM stops at startup with an error that gives the reason. It does not move to another backend. So a forced backend is safe to try: it runs, or it fails at once.
--block-size also removes backends. If it removes a backend that is higher in the list, vLLM writes a warning that names it.
See what our run shows
Our only forced-backend run changed the backend and the KV data type together, so its result does not show which backend is faster. We have not compared backends with one KV data type on any of our GPUs.
Decide
Leave the backend to vLLM. Override it for one of two reasons:
- The start fails in the backend that vLLM picked, as FlashInfer did on our L4.
- You measured a slowdown on your own load, and a different backend fixed it on the same load.
A forum post that says a backend is faster tested a different GPU, model, or load. Measure on yours before you change it.
vLLM 0.31.0 · db9527a · 2026-10-05 · Edition 2026.10