MiniMax H3 Spark Attention (SM89)

If you're on a 40-series card, this is the node you want and it's the one with the least drama attached. The authors measured 2.37× over dense attention in fidelity mode and 4.35× in speed mode on an RTX 4090, using the LightX2V 768p 8-step workflow at 1344×768 / 345 frames - right in the middle of the three architectures Spark-H3 supports, and the one where the surrounding ecosystem has had the longest to settle.

One correction to expectations first: video generation is where VRAM tier actually bites. A 5-second clip on a 4090 without speed LoRAs is a 15–40 minute proposition, and this pack's whole reason for existing is that chunk of that time is attention. Spark-H3 doesn't change what H3 costs in memory - it changes how much of the wall clock the attention kernel owns.

What it's doing under the hood

MiniMax-H3 is a 33B omni-modal model: one transformer producing video and stereo audio from a unified text/image/video/audio context. Attention over its token sequence is quadratic and the sequence is gigantic - the pack's own documentation uses a 10-second 768p sample with 72,576 video tokens (1,134 blocks of 64). This node swaps in block-sparse attention with two fixes on top of the plain approach:

Reblock reorders tokens into blocks by attention preference rather than by position, using a Mahalanobis cosine distance built from the opposite side's second moment (M_K = E[kkᵀ] for queries, M_Q for keys), then a capacity-constrained tree partition down to exactly 64-token leaves, recomputed per layer and per step. Q/K/V values are never modified - only which tokens end up sharing a block. At a 10% budget that's worth +12.88 points of attention-mass recall and +3.80 dB PSNR versus fixed blocks.

Reweight replaces mean-pooled summaries in the compressed branch with weighted ones plus a log-mass correction: −28% absolute log-mass error, +0.56 dB at the same 10% density.

Where it differs from ComfyUI's own Sol path: the approximate branch keeps a real Q per query and downsamples only K/V, which matches sol-engine's Sol. The node's tail_granularity option lets you switch to ComfyUI's block-level behaviour if you need to match it.

Inputs you'll actually set

model in, patched MODEL out - after the loader, before the guider and scheduler. The defaults are fine; these are the ones worth understanding.

mode is the whole personality of the node: fidelity (default) spends the first 20% of evaluations on dense attention to preserve the dense model's output, speed starts sparse immediately, custom appears when you edit an active warmup value by hand, and dense bypasses Spark entirely. steps must match the sampler's real evaluation count - the terminal σ=0 in MiniMax's schedule doesn't run the transformer, so a nominal 20-step run is 19 evaluations and the warmup maths gets skewed if you type 20.

topk_mode/topk_ratio set the exact branch's budget: 0.2 is the pack's default and recommended balance, 0.1 is fastest, 0.3 most faithful; topk_blocks is the fixed-count alternative. dense_layers (0) pins leading blocks to dense, min_tokens (12288) keeps short clips dense so you don't pay sparse overhead for nothing, and strict (on) makes unsupported inputs error out instead of quietly falling back - leave it on until you trust your setup.

Optional: dense_backend chooses the backend for the dense warmup (and dense layers, and fallbacks) - inherit by default, or force kitchen, sage or sdpa. This is Python-level dispatch through ComfyUI's attention registry, so it doesn't require rebuilding the SM89 wheel.

Installing

The supported route is the architecture-specific ZIP, because the CUDA kernel is compiled per-architecture:

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

ComfyUI Manager works too (registry publisher zechengtang, node ID comfyui-spark-h3), and git clone https://github.com/zechengtang/Spark-H3 into custom_nodes is fine for the non-kernel nodes but leaves you running the installer for the backend anyway. Environment: ComfyUI 0.38.x or 0.39.x (0.39.2 recommended), CUDA 13.0, Linux or Windows x86_64, BF16 execution, and a prebuilt wheel expects CPython 3.12+ - 3.10/3.11 falls back to a source build needing Git, CMake, Ninja, a C++ compiler and matching nvcc. The installer rejects an SM86 or SM120 wheel outright, so don't mix them up. Model files come separately from Comfy-Org/MiniMax-H3.

Where people get burned

Don't stack attention patches. One per model. Spark plus another attention patch is not a combination anyone benchmarked.

KJNodes low-VRAM ordering. loader → MiniMax H3 Low VRAM Attention → MiniMax H3 Chunk FeedForward → Spark → sampler. Low VRAM Attention must precede Spark so it can detect the compose hook and use the head-chunk path; reversed, you usually get no error and an incomplete memory win.

dense_backend=sage is not a free win. SageAttention has a track record of producing corrupt output on specific architectures - the KB documents it turning Z-Image Base patchy, lined or fully black across 3090/4090/5090 - and the pack's own release notes flag Kitchen and Sage dense backends as not yet through complete quality regression testing. Change one thing, fix the seed, look at the result. If your render is suddenly bilinear-blurry, check this widget first.

The first run after install is slow. Sparse kernels compile on first use. Benchmark the third run, not the first.