MiniMax H3 Long-Sequence Attention (Experimental)

MiniMaxH3FastPatch - displayed as "MiniMax H3 Long-Sequence Attention (Experimental)" - is the one-input preset from DrBearJew's ROCm fork of kijai's Sol-Attn pack. It slaps a sparse-attention patch onto a native ComfyUI MiniMax H3 model so the long self-attention calls stop being your bottleneck. The name is the whole story: H3-only, fast, and deliberately experimental.

Here's the thing you need to know up front: it does nothing unless you flip a switch. The enabled input defaults to false by design, and the node is a no-op pass-through until you change that. This is not a bug - it's a fork that's honest about being approximate.

Why you'd reach for it

MiniMax H3 is the 33B omni-modal video model that treats text, image, video, and audio as one context and generates 4–15 second clips with native audio. That unified context is exactly why its attention is brutal: a long clip means tens of thousands of tokens, and attention cost grows quadratically. On a 21,760-token H3-shape call, this pack measured the dense pass at ~772 ms per call and the Sol-Attn INT8 path at ~72 ms. That's not a typo - over a whole 90-frame, 20-step generation the author's matched run went from 472.9s dense to 447.2s patched, and 327.6s once you also stack the companion MiniMaxH3BlockCacheT8 (a 1.44× wall-clock win). If you're generating long H3 clips on a 7900 XTX and every step is dragging, this is aimed squarely at you.

How it works

Sol-Attn (arXiv 2607.24027, from NVIDIA's Sana sol-engine work) is training-free sparse attention: instead of every query attending to every KV block, a cheap block-summary pass ranks blocks and only the important ones are computed exactly. This preset wraps that in a conservative policy. It only activates on eligible H3 self-attention calls of at least 12,288 tokens - shorter sequences stay dense because the author measured an 8.5K-token run gaining only 1.6%. On eligible calls it builds an explicit accepted-block mask that must cover 90% of estimated attention mass, keeps at least 50% of KV blocks exact, holds the packed conditioning/reference/audio rows exact, and runs the first three transformer blocks plus the last (0-2,-1) dense. QK and PV math runs in INT8 with a stable grouped kernel. Anything unsupported or malformed falls back to dense.

Placement and the inputs that matter

The node has exactly three inputs and one output. model (MODEL in), enabled (bool, default false), and verbose (bool, tucked under advanced). The output is a MODEL that plugs straight back into your existing chain - nothing downstream changes.

The author's validated order:

MiniMaxH3INT8FastLoader
  → LoraLoaderBypassModelOnly (optional)
  → ModelAttentionBackend (comfy kitchen attention)
  → MiniMaxH3FastPatch
  → MiniMaxH3BlockCacheT8 (optional)
  → MiniMaxH3SigmaShift
  → scheduler / guider / sampler

Two placement rules matter. The patch must sit after a ModelAttentionBackend configured as comfy kitchen attention, which stays the dense backend and fallback. And the two companion nodes are separate packages from the same author - this one alone does not give you the full 1.44×. Flip verbose on if you want to see which calls went sparse versus fell back.

Installing it

The usual routes work. In ComfyUI Manager, search the pack title "ComfyUI-SolAttn_triton" and install, or:

cd ComfyUI/custom_nodes
git clone https://github.com/DrBearJew/ComfyUI-SolAttn_triton

It's also on the Comfy registry as minimax-h3-sol-attn-rocm (comfy node install minimax-h3-sol-attn-rocm). No extra pip packages - the pack ships with zero declared dependencies, and the Triton kernels compile on first use, so the very first run is slower than every one after it.

Where people get burned

First, the version pin: the pack declares requires-comfyui >=0.32.0,<0.33.0 and expects comfy-kitchen 0.2.31. If your ComfyUI is older, the ModelAttentionBackend machinery it hooks into simply isn't there. Second, it's validated on exactly one environment - Linux, ComfyUI 0.32.0, RX 7900 XTX/gfx1100. Everything else is unvalidated, NVIDIA included (this is a ROCm-oriented fork of an NVIDIA team's kernels, so treat that as "works for me," not a promise). Third, if you feed it a non-H3 model it raises a clear error - it checks for H3's rope_freqs/blocks anatomy. And yes, the parent H3 weights themselves carry the MiniMax community license that geofences out the US, EU, UK, and Korea; this node won't help you with that. For a niche fork with zero GSC traffic and no community signal yet, treat the author's own measured results as the ceiling, not the floor - verify quality on your own prompts before trusting it on a job.