vLLM forks (RDNA2 / gfx1030)

WIP: Kernel behavior below is traced to fork source commits; published -extras Docker images may lag HEAD until rebuilt. See Verification status.

Fork landscape

#vllm-rdna (Sep 2026): the official gfx1030 vLLM source is the shared-org repo. File new PRs and issues there. Flash-Next work lives on rdna_extras. Published Docker Hub v0.31.0-extras landed 11 Oct 2026.

Day-to-day serving: pull blivioniag/vllm-rdna v0.31.0-extras (#announcements 11 Oct 2026). Source of truth for new kernel work is opengfx1030/vllm-rdna rdna_extras (now the v0.31.0 port). Older Hub tags stay for A/B. Do not assume org GHCR tags exist yet.

Companion (not an engine fork): leapdragon/vllm-rdna2-recipe (mirror opengfx1030/vllm-rdna2-recipe) collects compose/env recipes and open PRs (concurrent MTP, etc.). Wiki entry point: Recipes. #vllm-rdna (Sep 2026): the Flash-Next author treats the recipes repo as a parts pile (less active new work). Day-to-day Flash-Next optimization lives on org rdna_extras (Hub v0.31.0-extras); Concurrent-MTP PRs on the recipes repo are still worth cherry-picking into that stack.

Progress snapshot

For a dated Hub vs HEAD vs backlog table (MonoKernel, HIP defaults, PP3, INT4 KV, W4A8, open drafts), see Fork progress (26 Oct 2026). The chronicle below keeps per-PR detail.

Consolidation status (Sep 3–26 2026)

#vllm-rdna / public merges chronicle — expect this to move quickly:

Official-fork feature set called out in-channel (HIP): MXFP4, AWQ INT4, GPTQ INT4, GDN prefill/decode linear attention, FA-RDNA2, one-shot all-reduce, FULL_AND_PIECEWISE, EXL3, MTP=2. Treat Hub v0.31.0-extras as the current extras bake; clone HEAD for work after that tag. Readable snapshot: Fork progress.

The rdna_extras fork

The official extras source is opengfx1030/vllm-rdna on the default rdna_extras branch (formerly personal blivioniag/vllm rdna2_extras — public repo 404 today). It adds hand-written RDNA2 HIP kernels and the vLLM plumbing to dispatch to them.

Current Hub extras bakes (v0.28.0-extras, v0.31.0-extras) clone this org branch via vllm-rdna-docker (VLLM_REPOSITORY=…/opengfx1030/vllm-rdna.git, VLLM_REF=rdna_extras). Older v0.26 / v0.27.1-extras* bake targets still name the removed personal BlivionIaG/vllm @ rdna2_extras clone. Pull Hub v0.31.0-extras for serving; clone the org repo to contribute.

Why it exists: RDNA2 (gfx1030) has no matrix/WMMA cores — those arrived with RDNA3 (gfx11xx). So quantized GEMM, attention, and MoE have to be implemented efficiently on RDNA2’s regular vector ALUs. This fork does exactly that (with RDNA3 WMMA variants where it makes sense).

INT4/W4A16 on gfx1030 does not use native int4 compute. The RDNA2 kernels dequant on the fly using vdot2 fp16 instructions with int4 packed via dp4a. Community testing found no faster INT8-based HIP kernel vs fp16 for these paths — fp16 dequant is the winning approach on V620.

Branches

Historical names on the old personal fork (feat/enable-gfx1030, perf/rdna2_w4a16, rdna2_extras) are superseded. Only the older v0.26 / v0.27.1-extras* bake targets still name that removed repo; current extras bakes use VLLM_REF=rdna_extras on opengfx1030/vllm-rdna.

What’s in it

The custom device code lives under csrc/rocm/*_rdna2.cu (with _rdna3 variants where WMMA applies), wired into vLLM through Python kernel/layer modules and covered by targeted tests under tests/kernels/.

Attention

• fa_rdna2.cu — a FlashAttention kernel tuned for RDNA2, exposed via vllm/v1/attention/ops/fa_rdna2_backend.py and the vllm/v1/attention/backends/rdna_attn.py backend. Now supports head_size=256 on gfx10x (needed for Qwen3.8-27B-AWQ-INT4; previously capped at 128 and caused Triton GDN compile hangs). #vllm-rdna (Sep 22–24): when the extras fork went public the maintainer dropped the FP16 FA pieces to focus on validating W4A16. In-tree fa_rdna2 is still the org target, but it is currently disabled / not working after the #17 stack changes (prefix-cache + piecewise first). Independent 2kiss/flash-attention-rdna2 is stale — do not treat it as a drop-in. Needs verify.
• sparse_mla_rdna2.cu + rocm_rdna2_mla_sparse.py — sparse MLA (multi-head latent attention, DeepSeek-style).
• indexer_paged_mqa_rdna2.cu — paged MQA indexer.

Quantized GEMM (mixed-precision linear)

• q_gemm_rdna2.cu / q_gemm_rdna2_prefill.cu (+ q_gemm_rdna2_common.cuh) — W4A16 quantized GEMM for decode and prefill.
• q_gemm_w8a16_fp8_rdna2.cu, gemm_w8a8_fp8_dense_rdna2.cu — FP8 W8A16 / W8A8 paths.
• qdq_4_rdna2.cuh, qdq_8_rdna2.cuh, qdq_fp8_rdna2.cuh — quant/dequant helpers.
• Python: model_executor/kernels/linear/mixed_precision/rdna2_w4a16.py, .../scaled_mm/rdna2_w8a16_fp8*.py, rdna2_w8a8_fp8.py, and the rdna_hybrid_w4a16.py selector.
• EXL3 (in-tree on rdna_extras; #announcements 11 Oct 2026 lists it on the v0.31.0 extras bake / RECIPE=27b-exl3): exl3_hadamard.cu, exl3_dot2_*.cu, plus vllm/.../quantization/exl3.py. Still experimental. #vllm-rdna (Sep 24): rdna_extra/v0.29.0 added mul1 so existing EXL3 packs can load. #vllm-rdna (Sep 29–30) + rdna_extras commits (30 Sep–1 Oct): mul1 / K=1..8 plus the v0.30 loader rewrite are on HEAD and GPU-run on gfx1030 (215/215 tests; 27B 3.00 bpw mul1 TP=4 graphs). #vllm-rdna (Oct 2): that path is mul1-tested only — 3inst packs are untested. Draft #32 was the earlier kernel-port PR. Older Hub v0.27.1-extras* tags do not have this — Quantization.

MoE (mixture of experts)

• moe_q_gemm_rdna2.cu, moe_w8a16_rdna2.cu, moe_w8a16_fp8_rdna2.cu — quantized expert GEMMs.
• Python experts fused_moe/experts/rdna2_mxfp4_moe.py, rdna2_w8a16_fp8_moe.py, and compressed_tensors MoE glue (..._fp8_rdna2, ..._w4a4_mxfp4_rdna2, ..._wna16_rdna2).

#vllm-rdna (Sep 19): a quality A/B reported the fused HIP MoE kernel is not deterministic. On the same server and the same tokens, about 3.5% of the most-probable tokens changed between runs, costing about +0.2–0.3% perplexity versus the best reference that host could run. The Triton MoE path was bit-identical across repeats. Cause not isolated (fp16 accumulation order vs a real race). Proposed, not landed as of Sep 19: replace the atomic_add_pk4_f16 CAS loop with global_atomic_add_f32 (fewer atomics, possibly worse bandwidth). #vllm-rdna (Sep 30): an fp32 deterministic MoE mode was described as opt-in because it cuts throughput — flag name was not posted; do not invent an env var. Default stays the faster path. Needs verify — do not switch kernels on this note alone.

GDN (gated delta-net / linear attention)

Kernels for gated-delta-net models (e.g. Qwen3.8-27B hybrid linear attention). As of Aug 2026 the full GDN chain is hand-ported to HIP — no Triton JIT on the hot path:

This replaces the Triton FLA GDN path that previously caused 16k/1k prefill hangs and slow decode on hybrid models. Recent tuning commits improved delta_h register pressure, o-kernel block-vector width, and prep-kernel vectorization.

Using it

The easiest path is a prebuilt -extras image — no compilation required:

docker run -it --rm \
  --device /dev/kfd --device /dev/dri --group-add video --group-add render \
  --security-opt seccomp=unconfined --ipc host -p 8000:8000 \
  docker.io/blivioniag/vllm-rdna:v0.31.0-extras \
  vllm serve <model> --dtype float16

See Running (Docker) for the full run recipe and Building images for how the -extras variant is produced (VLLM_VARIANT=extras-fork, current extras targets VLLM_REF=rdna_extras on opengfx1030/vllm-rdna).

Kernel dispatch on gfx1030

On -extras images, vLLM picks kernels based on quantization format:

Check startup logs for lines like Using RDNA2W4A16LinearKernel for AutoGPTQLinearMethod. If you see TritonW4A16LinearKernel or ExllamaLinearKernel instead, the RDNA2 quant path isn’t active.

Attention backends

• VLLM_USE_RDNA2_FA=1 — enables the custom fa_rdna2.cu FlashAttention backend on Hub -extras. #vllm-rdna (Sep 15): on current Flash-Next / rdna_extras HEAD, native FA is still WIP — community A/B used VLLM_USE_RDNA2_FA=0 (and sometimes VLLM_GDN_HIP_PREFILL=0) when chasing PP3 correctness. Do not copy that disable onto a working 0.27.1 -extras 27B serve.
• --attention-backend RDNA_ATTN — alternative RDNA-tuned attention path (useful for Qwen models with head size 256 where generic AMD Triton FA is slow or broken).
• FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE — enables AMD Triton FA as a fallback; often slower on gfx1030.
• Optional FA-RDNA2 knobs on rdna_extras (rdna_attn.py, Oct 2026): VLLM_FA_RDNA2_GQA_MODE (default subgroup), VLLM_FA_RDNA2_SPLIT_DECODE (default 1). A/B only — not a serve recipe.

#vllm-rdna (13 Oct): FA-RDNA2 is general attention, not “dense models only”. On Flash-Next, full-attention layers are owned by the QSA path (Qwen4ExpQSA*), which picks its Triton backend directly and does not consult --attention-backend / VLLM_USE_RDNA2_FA. Seeing Triton in the stack for those layers is expected. A full switch would need HIP QSA split-K attention plus INT4 PLE n-gram lookup — still open work (community cited fork backlog around #64). Prefer not treating FA flags as a Flash-Next speed lever until that lands — troubleshooting.

On v0.27.1, hybrid GDN models may still auto-select ROCM_ATTN even with VLLM_USE_RDNA2_FA=1 for the attention layers — that’s expected. The GDN linear-attention layers now use the native HIP kernels above (not Triton FLA). For graph capture issues, see CUDA graphs and vLLM troubleshooting.

CUDA graph capture (TP comm fix)

A common _SimpleCData.__new__ crash during V2 cudagraph capture on multi-GPU TP setups was fixed by marking TP communication wrappers with allow_in_graph. With current -extras images, CUDA graphs are the preferred fast path — you should not need --enforce-eager for this class of failure anymore. On multi-GPU, if AOT compile cache replay misbehaves, try VLLM_USE_AOT_COMPILE=0 VLLM_DISABLE_COMPILE_CACHE=1.

Disabling fallback kernels

export VLLM_DISABLED_KERNELS=ExllamaLinearKernel,TritonW4A16LinearKernel

This is the main lever for forcing GPTQ onto the native RDNA2 W4A16 path. The variable accepts a comma-separated list of kernel class names registered in vLLM’s linear-kernel registry.

To test Exllama instead (still relevant on some quants per #general):

--linear-backend exllama

Omit VLLM_DISABLED_KERNELS when testing Exllama — it competes with the RDNA2 kernel for dispatch.

Building from source (advanced)

Create the venv and install torch first — the ROCm 7.2.0 and 7.14.0 commands are on Host venv. Dockerfile.vllm then does an editable install (not requirements/dev.txt):

git clone -b rdna_extras https://github.com/opengfx1030/vllm-rdna.git
cd vllm-rdna
export PYTORCH_ROCM_ARCH=gfx1030
export ROCM_HOME="${ROCM_HOME:-/opt/rocm}"
VLLM_USE_PRECOMPILED=0 ENABLE_CK=0 FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE \
  uv pip install -e . --no-build-isolation

On ROCm 7.2.0 only, add --torch-backend=rocm7.2. On 7.14.0, leave it off and install the multi-arch device wheels first. Details: Host venv.

The kernels have their own tests, e.g.:

pytest tests/kernels/quantization/test_rdna2_w4a16.py
pytest tests/kernels/attention/test_fa_rdna2_shape_sweep.py

These kernels are actively evolving. Treat the fork as experimental, pin to a known-good image tag for reproducible serving, and file issues on opengfx1030/vllm-rdna if you hit correctness or performance problems.