MiniMax H3 Spark Attention (SM120)

The headline number for this node is the least impressive of the three Spark architectures: 2.05× over dense in fidelity, 3.15× in speed on an RTX PRO 6000 Blackwell, against 2.42×/4.62× on a 3090. That's not the kernel being worse on Blackwell - it's what happens when the dense baseline is the fastest attention implementation in the room. There's less fat to trim. In absolute terms this is still the fastest way to run H3 on a 50-series card.

It's also the least battle-tested of the three. The pack's own project status lists validating the ComfyUI implementation on SM120 as in progress, while the SM86 Linux build has been validated on a 3090 and the Windows CUDA 13.0 builds on SM89 and SM120 hardware. Worth knowing before you file your first bug report.

What it does

Spark-H3 is adaptive block-sparse attention for MiniMax-H3 - the 33B omni-modal model that emits picture and stereo audio in one pass. Dense attention over its token sequence is the bottleneck; the pack's docs use a 10-second 768p sample with 72,576 video tokens (1,134 blocks of 64) as the reference case.

This node patches ComfyUI's native H3 DiT using ComfyUI's own block-replacement, sigma scheduling and cleanup architecture, plus a chunked QKV producer, and routes attention through the Spark CUDA kernel compiled for 120f. The two algorithmic additions:

• Reblock regroups tokens into 64-token blocks by attention preference - similarity measured as a Mahalanobis cosine under the opposite side's second moment, partitioned by a capacity-constrained tree to exact leaf size, rebuilt for every layer and step from the current input. At a 10% budget the authors measure +12.88 points of attention-mass recall and +3.80 dB PSNR over fixed block partitioning.
• Reweight replaces mean-pooled summaries in the compressed branch with weighted ones and a log-mass correction: −28% absolute log-mass error, and +0.56 dB at the same 10% density.

Q/K/V numbers never change. Only grouping and summarisation do.

Inputs

Wire model in after the loader, and take the patched MODEL out to the guider/scheduler.

mode - fidelity fills a 20% dense warmup, speed sets it to zero, custom is what you land in after hand-editing an active warmup value, and dense bypasses Spark entirely. For the second pass of a two-pass workflow, use speed: at high resolution, spending 20% of the evaluations on dense warmup is money straight out the window. The pack's LBH example runs mode=speed with topk_ratio=0.1 on its high-res stage.

steps - set it to the sampler's actual model-evaluation count. MiniMax's scheduler counts the terminal σ=0 point as a step even though it doesn't run the transformer, so the default 50-step convention means 49 evaluations. Warmup is derived from this number, so a stale value quietly mis-schedules you.

topk_mode + topk_ratio - the exact branch budget, 0.2 default (0.1 fastest, 0.3 most faithful). topk_blocks does the same thing in fixed block counts (228 ≈ 20% on the 10-second 768p sample). dense_layers (0), min_tokens (12288) and strict (on - it errors on unsupported input rather than falling back silently, which is what you want while you're working out whether Spark is even running) fill out the rest.

On the optional side, dense_backend picks the backend for dense warmup steps, dense layers and fallbacks. On Blackwell this is where the interesting option lives: kitchen forces comfy-kitchen's INT8 attention for those calls, and it's marked as the recommended one to try - no wheel rebuild needed, it's a Python-level dispatch through ComfyUI's attention registry. sage and sdpa are the alternatives. The release notes flag Kitchen and Sage dense backends as experimental, not yet through full quality regression testing.

Installing

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

Or install from ComfyUI Manager - the pack is on the registry as publisher zechengtang, node ID comfyui-spark-h3 - which pulls the matching wheel. The installer detects your ComfyUI release and installs comfy-kitchen 0.2.36+spark.h3.sm120.cu130.1 for ComfyUI 0.38.x or 0.2.37+... for 0.39.x, and refuses wheels built for another architecture, CUDA toolchain or OS.

The one version note that matters on Blackwell: testing found comfy-kitchen 0.2.36 (bundled with ComfyUI 0.38.2) is not optimised for W6A8 - the 6-bit weight, 8-bit activation quantisation some H3 checkpoints use. That support landed in 0.2.37, shipped with ComfyUI 0.39.2. If you're running W6A8 weights, upgrade ComfyUI. Separately, the pack recommends ComfyUI 0.39.2 generally; it measured slightly better speedup ratios than 0.38.2.

Models aren't bundled: diffusion model, text encoder and both VAEs come from Comfy-Org/MiniMax-H3 into models/diffusion_models, models/text_encoders and models/vae. Do note that H3's licence excludes the EU, UK, South Korea and the US - including for outputs - so the local pipeline isn't licensed everywhere.

Where people get burned

Wrong arch wheel. SM120 covers RTX 50-series and RTX PRO 5000/6000 Blackwell. The installer will reject an SM86 or SM89 package rather than let you find out at inference time.

Two attention patches, one model. Just don't. Spark is designed to be the single patch in the chain.

KJNodes ordering. If you use MiniMax H3 Low VRAM Attention and MiniMax H3 Chunk FeedForward, the supported order is loader → Low VRAM Attention → Chunk FeedForward → Spark → sampler. Low VRAM Attention has to come first, because Spark checks for its compose hook while installing the patch. Put it after and things usually still run - you just don't get the full head-chunking benefit, which is a silent half-fix.

Comparing timings with a mixed compile state. The pack is explicit that in a controlled 25-prompt check, changing the torch.compile state of denoising moved Spark's PSNR by 3.15 dB on otherwise matched settings. If you're comparing configurations, match the compile state across all runs or the numbers mean nothing.

Expecting speed to match dense output. The authors treat the fully sparse, no-warmup schedule as an optimistic speed upper bound rather than quality-preserving acceleration. fidelity is the mode that claims to track dense. And the first run after install includes kernel compilation, so don't benchmark it.