MiniMax H3 Spark Attention (SM86)

Here's the number that makes people stop scrolling: on a 3090 running the LightX2V 768p 8-step workflow at 1344×768 and 345 frames, this node measured 2.42× faster than dense attention in fidelity mode and 4.62× in speed mode. The 4090 gets 2.37×/4.35× and an RTX PRO 6000 Blackwell gets 2.05×/3.15×. Older, slower attention has more headroom to win back, which is why the 30-series node - added in v0.1.3, validated by the authors on both Linux and Windows RTX 3090 - is the one many people actually care about.

The pack is Spark-H3: adaptive block sparse attention for MiniMax-H3, the 33B omni-modal video model that generates picture and stereo audio together. The attention math over tens of thousands of video tokens is the bottleneck, and this node replaces it.

How it works, briefly

H3's dense attention is quadratic in sequence length, and the sequence is enormous - the pack's own docs use a 10-second 768p sample with 72,576 video tokens, which is 1,134 blocks of 64. Block-sparse attention splits that into an exact branch (a selected set of blocks, computed properly) and a compressed branch (everything else, summarised cheaply). Spark's two contributions target those branches separately:

Spark-Reblock groups tokens by attention preference into the 64-token blocks, instead of using consecutive tokens or fixed spatio-temporal tiles. Similarity is a Mahalanobis cosine distance under the opposite side's second moment - queries are compared with M_K = E[kkᵀ], keys with M_Q = E[qqᵀ] - and a capacity-constrained hierarchical partitioner splits down to exact 64-token leaves. It never changes the Q/K/V values, only which tokens share a block, and it's rebuilt per layer and per step from the current input. At a 10% budget the authors report +12.88 points of attention-mass recall and +3.80 dB mean PSNR over fixed block partitioning.

Spark-Reweight fixes the compressed branch's mean-pooling bias with weighted summaries and a log-mass correction: −28% absolute log-mass error, +0.56 dB at the same 10% density. Tail tokens, the awkward remainder at the end of the sequence, get their own treatment.

The inputs that matter

model goes in - connect it after your model loader, before the guider/scheduler - and a patched MODEL comes out. Everything else has a sensible default, so here's the short list of what you'd actually touch.

• mode - fidelity (default) fills in a 20% dense warmup; speed sets it to zero and goes sparse from the first evaluation; custom is what you get once you've hand-edited an active warmup value; dense bypasses the patch entirely and passes the model through. The pack recommends speed for the high-resolution second pass of a two-pass workflow, where a dense warmup is wasted.
• steps - must equal the sampler's actual model-evaluation count. MiniMax's scheduler counts the terminal σ=0 endpoint as a step, so the default 50-step H3 run is 49 evaluations, and a 20-step run is 19. Get this wrong and your warmup percentage is computed against a step count that doesn't exist.
• topk_mode + topk_ratio - the exact branch's budget. topk_ratio=0.2 (default) is the pack's recommended balance; 0.1 is fastest, 0.3 is the fidelity end. topk_blocks is the alternative fixed-block-count form (228 ≈ 20% on a 10-second 768p sample).
• dense_layers - how many leading transformer blocks always run dense. Default 0.
• min_tokens - below this sequence length everything stays dense, because sparse overhead isn't worth it on short clips. Default 12288.
• strict - keep it on while you're setting up. With it off, unsupported inputs silently fall back to the original attention and log the reason, which is a great way to benchmark a fallback path by accident.
• Optional: dense_backend (inherit/kitchen/sage/sdpa) picks the attention backend for the dense warmup steps, and tail_granularity / reblock_layout are the fidelity/perf knobs the shipped workflows pin to query and q_reuse_k.

Installing, and the arch wall

cd /path/to/ComfyUI/custom_nodes
unzip /path/to/ComfyUI-Spark-H3-<version>-linux-x86_64-sm86-cu130.zip
/path/to/ComfyUI/.venv/bin/python ComfyUI-Spark-H3/install.py

Or install from ComfyUI Manager (registry publisher zechengtang, node ID comfyui-spark-h3), which pulls the matching wheel. Use the ComfyUI venv's Python, never a system one. The installer picks the comfy-kitchen backend matching your ComfyUI release (0.2.36 for 0.38.x, 0.2.37 for 0.39.x) and rejects a wheel built for another architecture or CUDA toolchain - there is no silent fallback.

Which is the first real gotcha: the ComfyUI build ships SM86, SM89 and SM120 only. On an A100 or A800 (SM80) or an H100 (SM90) there is no installer path, despite SM80 kernels existing in the authors' own benchmark harness. On the 30-series side you're fine, and BF16 is what you want - Ampere has no fp8, and the pack targets CUDA 13.0 with BF16 execution. ComfyUI 0.38.x or 0.39.x; 0.39.2 is the current recommendation.

Models aren't bundled. Grab the diffusion model, text encoder and both VAEs from Comfy-Org/MiniMax-H3 into models/diffusion_models, models/text_encoders and models/vae. And the licence heads-up worth repeating: H3's weights are void in the EU, UK, South Korea and the US, outputs included.

Where people get burned

Two attention patches on one model. Apply one. Stacking Spark with another attention patch produces nonsense numbers and occasionally nonsense video.

Combining with KJNodes low-VRAM nodes in the wrong order. If you use MiniMax H3 Low VRAM Attention or MiniMax H3 Chunk FeedForward, the supported chain is loader → Low VRAM Attention → Chunk FeedForward → Spark → sampler. Low VRAM Attention has to come first: Spark detects its compose hook at patch time and switches to a head-chunked path. Reversed, it usually still runs, which is worse - you get the VRAM cost without the benefit.

Judging speed mode by its throughput. The authors are honest about this one: with no warmup the schedule "may deviate more from the dense model", and they treat those speedups as "an optimistic speed upper bound, rather than evidence of comparable quality-preserving acceleration." If you care about matching dense output, fidelity is the mode that's claiming that.

First-run timing. The kernel compiles on the first sparse evaluation, so the first generation after install is slower than the ones after it. Don't benchmark that one.