MiniMax H3 Mem Eff Sage Attn (AMD)

The name says "Sage Attention," so you'd assume this is a speed node. On AMD it isn't - not yet. This is a VRAM insurance policy for one very specific situation: running MiniMax H3 (MiniMax's 33B omni-modal video model) on a 16 GB AMD gfx12 card like the RX 9070 or 9070 XT.

Here's the backstory. H3 got day-zero ComfyUI support, but it's a heavyweight, and on NVIDIA cards people reach for Kijai's KJNodes MiniMaxH3MemoryEfficientSageAttentionPatch, which quantizes attention to int8/fp8 and frees the QKV buffers to squeeze long sequences into less VRAM. That node's kernels are hand-tuned CUDA for sm80/86/89/90. There is no CUDA path on a Radeon. This pack from Newaiguy is the gfx12 answer, and it even registers KJNodes' exact class name as an alias, so NVIDIA-authored H3 workflows that reference the KJNodes node load on AMD without you editing anything.

How it works

The node takes your H3 model and patches the attention forward of all ~50 transformer blocks. Then it picks a path based purely on sequence length - no settings to touch:

seq ≤ 30000 (typical 8s/0.4s clips): a transparent pass-through to ComfyUI's original optimized_attention. If you launched with --use-sage-attention, that hooks the global SageAttention kernel, so you get normal behavior at zero overhead versus an unpatched model.
seq > 30000 (think Ref2VA dual-clock sampling at seq 41414/54545): it auto-enables head-chunking, splitting the 42 heads into 4 groups and running each through fp16 sageattn one at a time. The author measured peak attention VRAM dropping from ~11.3 GB to ~7.1 GB - about 37% - which is the difference between finishing and the GPU hanging on a 16 GB gfx12 card.

Why chunk heads instead of quantizing, like KJNodes does? Because AMD's gfx12 backend currently has exactly one native int8 kernel (_qattn_gfx12_native, from SageAttention PR #368), and it's un-tuned - slower than plain fp16 once you're past ~4k sequence, and ~1.6-1.8x slower in real H3 workflows. Nvidia got per-architecture hand-tuned kernels; AMD got one rough draft. So the author kept fp16 and saved VRAM by chunking instead. It also composes with MiniMaxLowVRAMAttention if you pass minimax_head_chunks through transformer options.

The inputs that matter

There's exactly one. Honest.

model (MODEL) - your MiniMax H3 model.
Output: MODEL - wire it into your sampler just like any model patch.

The node verifies the model is actually a MiniMaxH3Model and errors out if it isn't. That's the whole UI. All the smart behavior is automatic and gated on sequence length, which is refreshing compared to the attention-kernel menu sprawl you get elsewhere.

Installing it

From ComfyUI Manager, search "MiniMax H3 Mem Eff Sage Attn (AMD)" and install, or the manual way:

cd ComfyUI/custom_nodes
git clone https://github.com/Newaiguy/ComfyUI-h3_sage_amd

Then restart ComfyUI and launch with --use-sage-attention.

The catch is the real dependency: you need a compiled SageAttention ≥ 2.2.0 with gfx12 support (the native .pyd from SageAttention PR #368), not the stock pip build. pip install sageattention alone may not cut it on ROCm. The README's escape hatch is a precompiled bundle on Quark netdisk (link in the README, extract code yhqi) that ships the gfx12 SageAttention for Python 3.12/3.13, the node, an AMD patch, a startup script, and build instructions. If you'd rather compile, that PR's thread is your guide.

Where people get burned

Expecting a speedup. It's a fuse, not a turbo. On normal sequences it's overhead-free, but it exists to stop OOMs and GPU hangs on long samples.
Wrong GPU. gfx12 only. On an NVIDIA card this is pointless - you want the original KJNodes node.
"sageattention is not installed" - the code checks the import and raises that RuntimeError, so it means the compiled gfx12 build isn't on your Python path.
Not a MiniMax H3 model (or an older ComfyUI without H3 support) and it refuses to patch - by design.
If you also have KJNodes installed, both packs register the MiniMaxH3MemoryEfficientSageAttentionPatch class name; the alias is meant as a fallback when KJNodes isn't there, so mind the collision.
And the elephant in the room: H3's community license excludes the US, EU, UK and Korea from running the local weights at all. No node patches around a license.

If you're on a 9070/XT and long H3 samples have been locking up or dying on OOM, this is the fix you've been looking for.