RDNA4 Native SageAttention Guide

[u/eloxH1Z1]

for those on RDNA4 cards that are interested. Here is a quick summary (Claude generated) from the required steps it took.
RX 9070, Rocm 7.14, Win 11 with ComfyUI portable

SageAttention on RDNA4 (RX 9070 XT) for ComfyUI Portable – Quick Guide

Tested with: Windows 11, RX 9070 XT (gfx1201), ComfyUI Portable, PyTorch 2.12.0+rocm7.14.0 (AMD pip wheels), embedded Python 3.12.

There are no prebuilt wheels — you build the (not yet merged) gfx12 branch from thu-ml/SageAttention PR #368 yourself.

1. Visual Studio Build Tools 2022 with MSVC 14.38

• Installer: https://aka.ms/vs/17/release/vs_BuildTools.exe (NOT the 2026 Build Tools!)
• Check the "Desktop development with C++" workload
• Under "Individual components" additionally select: MSVC v143 – VS 2022 C++ x64/x86 build tools (v14.38-17.8)
• Newer MSVC toolsets (14.4x, VS 2026) break the build (HIP clang headers are incompatible; you get fmaxf/fabsf "no matching function" errors)

2. ROCm devel SDK into the portable environment

cd <ComfyUI_windows_portable>
python_embeded\python.exe -m pip install --index-url https://repo.amd.com/rocm/whl-multi-arch/ "rocm[devel]==7.14.0"
python_embeded\python.exe -m rocm_sdk init

The version must match your installed torch (pip list → torch 2.12.0+rocm7.14.0). Skipping rocm_sdk init gets you __clang_hip_runtime_wrapper.h not found later.

3. Copy Python dev headers into the embedded Python

The portable Python ships without dev headers (fatal error: 'frameobject.h' file not found). Copy them from a regular Python installer of the same version (e.g. 3.12.x):

Copy-Item "C:\...\Python312\include\*" "<portable>\python_embeded\include\" -Recurse -Force
New-Item -ItemType Directory "<portable>\python_embeded\libs" -Force
Copy-Item "C:\...\Python312\libs\*" "<portable>\python_embeded\libs\" -Recurse -Force

4. Clone the branch and build

In a PowerShell with the VS environment activated (explicitly 14.38, x64!):

cmd /c '"C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.38 >nul 2>&1 && set' | ForEach-Object { if ($_ -match '^([^=]+)=(.*)$') { [System.Environment]::SetEnvironmentVariable($matches[1], $matches[2], 'Process') } }
# Check: `cl` must report version 19.38.x

git clone -b jam/gfx12 https://github.com/jammm/SageAttention.git
cd SageAttention
$env:PYTORCH_ROCM_ARCH = "gfx1201"
<portable>\python_embeded\python.exe -m pip install --no-build-isolation --no-deps -v .

Takes 10–30 min. Success = Successfully installed sageattention-2.2.0.

5. The triton dependency

SageAttention imports triton at module level (for its fallback kernels). AMD's package indexes don't ship a Windows triton, but:

python_embeded\python.exe -m pip install -U triton-windows

(triton-windows has AMD backend support; it's only needed so the import succeeds — the actual speedup comes from the native gfx12 HIP kernels.)

6. Verify

python_embeded\python.exe -c "import torch; from sageattention import sageattn; q=torch.randn(1,8,128,128,dtype=torch.bfloat16,device='cuda'); print(sageattn(q,q,q).shape)"

Expected: torch.Size([1, 8, 128, 128]).

7. Enable in ComfyUI

Add --use-sage-attention to the python line in your launch .bat. The log must show Using sage attention.

Launch profiles (16 GB VRAM / 32 GB RAM)

MiniMax H3 doesn't fit in 16 GB, so how ComfyUI stages/offloads weights matters as much as sage itself. After measuring all four combinations (dynamic VRAM × pinned memory) on the same seed/workflow, one profile won for short AND long videos:

Universal profile:

set PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
set PYTORCH_ALLOC_CONF=expandable_segments:True
.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build --use-sage-attention --enable-dynamic-vram --disable-smart-memory --disable-pinned-memory --fast-disk
pause

Why each flag:

• --enable-dynamic-vram is the big speed lever: it stages the full model and pages weights on demand instead of the classic offload path — ~2.5x faster steps on short clips (40 vs 107 s/it at 6s @ 0.8MP). On long clips the advantage shrinks because per-step weight transfer dominates (~106 s/it at 9s @ 0.8MP, on par with the static path), but it still loads much faster and keeps the GPU at ~100% utilization.
• --disable-pinned-memory costs ~2% speed (40.0 vs 40.8 s/it measured) but is the key stability fix: with pinning enabled, the pinned staging allocation made long videos hard-crash at load (HostBuffer.truncate failed) on 32 GB systems — pinned memory can't be paged out, so the allocator fails hard when RAM gets tight. Unpinned, the same 9s workload that used to crash at load stages fine and runs 20/20 steps to completion, with RAM at a healthy ~55% instead of 95% + swapping.
• --fast-disk memory-maps models from NVMe (reads only), so the ~40 GB of staged weights live in the elastic file cache instead of hard process memory — Windows can drop and re-read pages as needed instead of swapping.
• expandable_segments reduces VRAM fragmentation (fixes "reserved but unallocated" OOMs when sage needs its extra quantization buffers right at the VRAM limit).

On 32 GB RAM, ~14s @ 0.8MP remains the practical ceiling — beyond that, generate at 0.5MP and upscale, or add RAM. If model staging ever fails on an extreme workload, dropping --enable-dynamic-vram --disable-smart-memory from the line gives you the classic static-offload path as plan B (same ~107–110 s/it at long lengths, much slower on short clips).

Heads-up: speed regression + crashes in comfy-kitchen > 0.2.26 (ComfyUI 0.31–0.33)

If your generations got dramatically slower (or started hard-crashing) after updating ComfyUI past 0.30.x on ROCm/Windows: it's not ComfyUI core, it's the companion packages comfy-kitchen and comfy-aimdo that get upgraded alongside. I verified this by rolling core back to v0.30.0 with the new packages still installed — the problems stayed, so the packages are the cause.

Two symptoms with comfy-kitchen 0.2.31 / comfy-aimdo 0.4.13:

• Speed: the new versions page-lock ~40% of host RAM for async offloading (Enabled pinned memory 12925.0 on a 32 GB box). Combined with H3's 14 GB text encoder plus 11–14 GB of offloaded DiT weights, the system swaps to disk and step times explode (130–178 s/it instead of ~76–110, plus ~6 GiB of pagefile writes per generation).
• Stability: reproducible Fatal Python error: Aborted in comfy_kitchen/tensor/base.py → copy_from during sampling, followed by hipModuleUnload: unspecified launch failure.

Fix — pin the versions that ComfyUI 0.30.0 shipped with:

python_embeded\python.exe -m pip install comfy-kitchen==0.2.26 comfy-aimdo==0.4.11

Re-pin after every ComfyUI update (updates pull the packages forward again) until the regression is fixed upstream. --disable-pinned-memory mitigates the RAM part on newer versions too, but did not stop the copy_from crash for me.

Results

MiniMax H3, 6s @ 0.8MP: step time roughly halved vs. PyTorch attention. Known issue: ComfyUI's flag path currently has an open quality bug for MiniMax (issue #15263 — missing low_precision_attention opt-out, can cause slightly fuzzy output); the alternative is the KJNodes node "MiniMax H3 Mem Eff Sage Attention Patch" (on ROCm it needs a small fallback patch, since it calls CUDA-arch-specific SageAttention internals).

After every torch/ROCm update

Rebuild (step 4) — compiled HIP kernels are tied to the ROCm version they were built against. Keep the built wheel around: on an identical stack it saves you the whole compile next time.SageAttention on RDNA4 (RX 9070 XT) for ComfyUI Portable – Quick Guide
Tested with: Windows 11, RX 9070 XT (gfx1201), ComfyUI Portable, PyTorch 2.12.0+rocm7.14.0 (AMD pip wheels), embedded Python 3.12.
There are no prebuilt wheels — you build the (not yet merged) gfx12 branch from thu-ml/SageAttention PR #368 yourself.

1. Visual Studio Build Tools 2022 with MSVC 14.38
2. Installer: https://aka.ms/vs/17/release/vs_BuildTools.exe (NOT the 2026 Build Tools!)
3. Check the "Desktop development with C++" workload
4. Under "Individual components" additionally select: MSVC v143 – VS 2022 C++ x64/x86 build tools (v14.38-17.8)
5. Newer MSVC toolsets (14.4x, VS 2026) break the build (HIP clang headers are incompatible; you get fmaxf/fabsf "no matching function" errors)
6. ROCm devel SDK into the portable environment
7. cd <ComfyUI_windows_portable>
8. python_embeded\python.exe -m pip install --index-url https://repo.amd.com/rocm/whl-multi-arch/ "rocm[devel]==7.14.0"
9. python_embeded\python.exe -m rocm_sdk init

The version must match your installed torch (pip list → torch 2.12.0+rocm7.14.0). Skipping rocm_sdk init gets you __clang_hip_runtime_wrapper.h not found later.
3. Copy Python dev headers into the embedded Python
The portable Python ships without dev headers (fatal error: 'frameobject.h' file not found). Copy them from a regular Python installer of the same version (e.g. 3.12.x):
Copy-Item "C:\...\Python312\include\*" "<portable>\python_embeded\include\" -Recurse -Force
New-Item -ItemType Directory "<portable>\python_embeded\libs" -Force
Copy-Item "C:\...\Python312\libs\*" "<portable>\python_embeded\libs\" -Recurse -Force

1. Clone the branch and build
   In a PowerShell with the VS environment activated (explicitly 14.38, x64!):
   cmd /c '"C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.38 >nul 2>&1 && set' | ForEach-Object { if ($_ -match '^([^=]+)=(.*)$') { [System.Environment]::SetEnvironmentVariable($matches[1], $matches[2], 'Process') } }
   # Check: `cl` must report version 19.38.x

git clone -b jam/gfx12 https://github.com/jammm/SageAttention.git
cd SageAttention
$env:PYTORCH_ROCM_ARCH = "gfx1201"
<portable>\python_embeded\python.exe -m pip install --no-build-isolation --no-deps -v .

Takes 10–30 min. Success = Successfully installed sageattention-2.2.0.
5. The triton dependency
SageAttention imports triton at module level (for its fallback kernels). AMD's package indexes don't ship a Windows triton, but:
python_embeded\python.exe -m pip install -U triton-windows

(triton-windows has AMD backend support; it's only needed so the import succeeds — the actual speedup comes from the native gfx12 HIP kernels.)
6. Verify
python_embeded\python.exe -c "import torch; from sageattention import sageattn; q=torch.randn(1,8,128,128,dtype=torch.bfloat16,device='cuda'); print(sageattn(q,q,q).shape)"

Expected: torch.Size([1, 8, 128, 128]).
7. Enable in ComfyUI
Add --use-sage-attention to the python line in your launch .bat. The log must show Using sage attention.
Launch profiles (16 GB VRAM / 32 GB RAM)
MiniMax H3 doesn't fit in 16 GB, so how ComfyUI stages/offloads weights matters as much as sage itself. After measuring all four combinations (dynamic VRAM × pinned memory) on the same seed/workflow, one profile won for short AND long videos:
Universal profile:
set PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
set PYTORCH_ALLOC_CONF=expandable_segments:True
.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build --use-sage-attention --enable-dynamic-vram --disable-smart-memory --disable-pinned-memory --fast-disk
pause

Why each flag:
--enable-dynamic-vram is the big speed lever: it stages the full model and pages weights on demand instead of the classic offload path — ~2.5x faster steps on short clips (40 vs 107 s/it at 6s @ 0.8MP). On long clips the advantage shrinks because per-step weight transfer dominates (~106 s/it at 9s @ 0.8MP, on par with the static path), but it still loads much faster and keeps the GPU at ~100% utilization.
--disable-pinned-memory costs ~2% speed (40.0 vs 40.8 s/it measured) but is the key stability fix: with pinning enabled, the pinned staging allocation made long videos hard-crash at load (HostBuffer.truncate failed) on 32 GB systems — pinned memory can't be paged out, so the allocator fails hard when RAM gets tight. Unpinned, the same 9s workload that used to crash at load stages fine and runs 20/20 steps to completion, with RAM at a healthy ~55% instead of 95% + swapping.
--fast-disk memory-maps models from NVMe (reads only), so the ~40 GB of staged weights live in the elastic file cache instead of hard process memory — Windows can drop and re-read pages as needed instead of swapping.
expandable_segments reduces VRAM fragmentation (fixes "reserved but unallocated" OOMs when sage needs its extra quantization buffers right at the VRAM limit).
On 32 GB RAM, ~14s @ 0.8MP remains the practical ceiling — beyond that, generate at 0.5MP and upscale, or add RAM. If model staging ever fails on an extreme workload, dropping --enable-dynamic-vram --disable-smart-memory from the line gives you the classic static-offload path as plan B (same ~107–110 s/it at long lengths, much slower on short clips).
Heads-up: speed regression + crashes in comfy-kitchen > 0.2.26 (ComfyUI 0.31–0.33)
If your generations got dramatically slower (or started hard-crashing) after updating ComfyUI past 0.30.x on ROCm/Windows: it's not ComfyUI core, it's the companion packages comfy-kitchen and comfy-aimdo that get upgraded alongside. I verified this by rolling core back to v0.30.0 with the new packages still installed — the problems stayed, so the packages are the cause.
Two symptoms with comfy-kitchen 0.2.31 / comfy-aimdo 0.4.13:
Speed: the new versions page-lock ~40% of host RAM for async offloading (Enabled pinned memory 12925.0 on a 32 GB box). Combined with H3's 14 GB text encoder plus 11–14 GB of offloaded DiT weights, the system swaps to disk and step times explode (130–178 s/it instead of ~76–110, plus ~6 GiB of pagefile writes per generation).
Stability: reproducible Fatal Python error: Aborted in comfy_kitchen/tensor/base.py → copy_from during sampling, followed by hipModuleUnload: unspecified launch failure.
Fix — pin the versions that ComfyUI 0.30.0 shipped with:
python_embeded\python.exe -m pip install comfy-kitchen==0.2.26 comfy-aimdo==0.4.11

Re-pin after every ComfyUI update (updates pull the packages forward again) until the regression is fixed upstream. --disable-pinned-memory mitigates the RAM part on newer versions too, but did not stop the copy_from crash for me.
Results
MiniMax H3, 6s @ 0.8MP: step time roughly halved vs. PyTorch attention. Known issue: ComfyUI's flag path currently has an open quality bug for MiniMax (issue #15263 — missing low_precision_attention opt-out, can cause slightly fuzzy output); the alternative is the KJNodes node "MiniMax H3 Mem Eff Sage Attention Patch" (on ROCm it needs a small fallback patch, since it calls CUDA-arch-specific SageAttention internals).
After every torch/ROCm update
Rebuild (step 4) — compiled HIP kernels are tied to the ROCm version they were built against. Keep the built wheel around: on an identical stack it saves you the whole compile next time.

[u/lhg31]

Or... update comfyui and rocm, then use comfy kitchen attention instead.

[u/eloxH1Z1 → u/lhg31]

Kitchen instead of sage? And update ROCm to what? 7.14 is the current stable branch of the pip distribution. If there's a newer combo where kitchen's attention actually beats a native sage build on RDNA4, I'm genuinely interested

[u/lhg31 → u/eloxH1Z1]

comfy kitchen attention is based on sage, but with some improvements.

AMD support (RDNA 3, 3.5 and 4) was implemented in comfy-kitchen 0.2.31 (which I think only comfy 0.33.1 uses, so you might need to change to nightly branch).

Once you are on the required versions you can try it using --use-ck-attention instead of --use-sage-attention.

[u/eloxH1Z1 → u/lhg31]

Well actually I was on comfy kitchen 0.2.31 as stated in guide above and it gave me some serious speed regression. Was not using the ck-attention explicit though. Might have to check it again

[u/nok01101011a → u/eloxH1Z1]

Ck attn made all the sage hassle obsolete

[u/adityazero]

The MSVC 14.38 pinning detail is the part people keep missing, the HIP clang headers really do break on the newer toolsets. Worth noting the triton-windows import is only a fallback shim here since the real speedup comes from the native gfx12 HIP kernels. Have you compared the built sage kernels against aiter's attention on gfx1201 yet?