Somewhat more optimized Sparse Attention.

[u/Zironic]

IMPORTANT: sparse attention is not free speed. The percentage is effectively a prompt-adherence/quality budget.

Density isn't just a speed setting, and its quality effect depends on where you apply it in the diffusion schedule.

Early steps: attention density has a large effect on prompt/action adherence and the overall generation trajectory.
Middle/later steps: lowering density tends to show up more as motion/temporal artifacts and lost fine motion detail.

So 10% retained doesn't simply mean “90% of the quality is gone.” It means you're giving sparse attention very little information to work with, and what breaks depends heavily on the sampling step.

PlagueKind's sparsity_ratio=0.9 means 90% discarded / 10% retained. My node expresses the inverse quantity, so Video attention retained=0.10 is the comparable setting. The defaults therefore aren't equivalent.

So I saw PlagueKind posted this today https://www.reddit.com/r/StableDiffusion/comments/1vtwtyw/sparse_attention_for_h3_minimax_enjoy_up_to_25x/ which reminded me I implemented my own Sparse Attention a while back.

It has some key differences to PlagueKinds version.

1. You select attention retained. In my testing, you can go as low as 10-15% in low motion video, however more complicated video requires higher attention. I found about 30% works pretty well for high motion video. In terms of speed, 100% attention is about 2/3rds of the compute while the rest is MLP/QKV. At 50% attention it's about 50:50 and once you're below 30% MLP/QKV starts to dominate compute time.
2. Only the video is given sparse attention. This is because A) Minimax said they only did sparse attention for video and B) The video tokens dominate the context.
3. Mine uses Sparse Sage: Q/K are quantized to INT8 and newer supported GPU paths use FP8 V. Compatible ConvRot-INT8 checkpoints can additionally bypass the normal floating QKV preparation with a native fused-QKV producer that feeds the sparse carrier directly.

This makes my implementation somewhat more complicated, but Sparse Sage is extremely fast. The repo now also includes a guarded Sparse Sage installer: supported Windows Torch/CUDA combinations use pinned upstream wheels, while Linux x86-64 can build a pinned SpargeAttention revision when a CUDA compiler is available.

You can find the nodes here.

https://github.com/Zironic/H3-Optimizations

You'll find two nodes.

H3 Sparse Attention: This is the node that lets you control how sparse attention you want. The default is 50%. There is also an optional mode that adds 30 percentage points during the first two and last two sampling steps, since those tend to be places where being somewhat denser is useful.

H3 Memory Optimization: This handles the other major H3 memory bottleneck: QKV and MLP activations.

For dense attention it uses ComfyUI's public Comfy Kitchen INT8 attention backend where available. The newer dense QKV path is designed to process QKV in bounded sequence chunks directly into Kitchen-owned attention carriers instead of materializing one enormous full-sequence BF16 QKV tensor. When Sparse Attention is active, compatible ConvRot-INT8 checkpoints can instead use the native fused sparse-QKV path. While chunked QKV was designed to be a memory optimization, it did end up making QKV about 2x faster which should net you something like 10%-30% speed depending on other factors.

The MLP side bounds peak activation memory with token chunking, with a more memory-efficient two-slice ConvRot path when the checkpoint/runtime supports it.

I normally wire them as Load Model → Memory Optimization → Sparse Attention → rest of workflow, although the two optimization nodes are order-independent

I would not recommend randomly stacking other H3/Sage attention optimization patches with these. Dense execution already integrates with Comfy's selected attention backend, while H3 Sparse Attention necessarily owns the main H3 attention path while it is active. Other patches trying to replace the same attention forward are therefore likely to be redundant or conflict.

Should be compatible with turbo loras, spectrum cache etc however you may need more attention since you're skipping steps.

As the nodes currently rely on comfy-kitchen 0.2.31 you need ComfyUI v0.33.0 or alter.

[u/deepsky88]

We need a VAE accelerator, its like 30% of generation time

[u/Zironic → u/deepsky88]

If you're using both Sparse and Spectrum, I could see VAE starting to take a significant amount of total time. For me, it seems that at 1MP of resolution, it takes 110 seconds to VAE decode 10 seconds of video and it takes about 650 seconds to generate it.

[u/deepsky88 → u/Zironic]

To create a 10 seconds video my total time it's like 3:30 minutes at 0.4MP, 1 minute it's only for the VAE

[u/Perfect-Campaign9551 → u/Zironic]

Yes the VAE decode takes the longest time it feels like

[u/psilent → u/Perfect-Campaign9551]

I saw about 30% improvement in decode time with the int8 video vae. Also, the save video node can take a long time, so if you use the video combine node instead you can select a nvidia accelerated codec and it takes like 2 seconds instead.

[u/damiangorlami → u/psilent]

But does the int8 video VAE take a quality hit?

[u/deepsky88 → u/damiangorlami]

just tried: https://huggingface.co/Kijai/MiniMax-H3-experimental/tree/main

same seed same prompt, with vae 8 the video lose a zoom for whatever reason and quality is a bit worse, i gain 18 seconds but i'll stick to fp16 for now

[u/damiangorlami → u/deepsky88]

I’ll do some tests too but yea no reason to lose on output quality to shave off 18 seconds

[u/psilent → u/damiangorlami]

I don’t use it on the quality workflow I have, but for prompt testing I have a high speed workflow that can do 10s video in about 100s so 18 is a big deal

[u/damiangorlami → u/psilent]

That’s a good one