MiniMax H3 Sol Attention (Official Compatibility)

Two things about this node surprise people. The first: despite shipping in a pack called Spark-H3 and being named after SM120, it never touches a Spark kernel. The second: that's deliberate, and it's the reason the node exists.

It's a compatibility alias. You hand it a MiniMax-H3 model and it delegates the actual patching to ComfyUI's own official Sol-Attn implementation - the apply_block_sparse_attention path that ships in comfy_extras.nodes_sparse_attention. The pack's description is refreshingly direct about it: "the official block patch, chunked producer, and comfy-kitchen kernel; no Spark-H3 Triton/CuTe backend is reachable."

So why want it? Because when someone posts "Spark gave me 2.4× on my 4090", the obvious next question is "compared to what?" Sol-Attn is what. This node bundles ComfyUI's official kernel with the same warmup and dense-layer scheduling the Spark nodes use, so a comparison is kernel-versus-kernel rather than kernel-versus-different-schedules. It's also a decent fallback if Spark's kernel won't run on your setup - nothing here needs an architecture-specific wheel.

Sol-Attn comes from the NVlabs Sana / Sol-Engine line, which Spark-H3 acknowledges as prior work. Worth knowing the family difference: sol-engine's Sol downsamples only K/V and keeps a real Q per query, while ComfyUI's native Sol downsamples Q and K/V by block, so every query in a block shares the same approximation. The Spark nodes let you pick between those with tail_granularity. Here you get ComfyUI's block-level behaviour, because that's what ComfyUI implements.

What it does with your inputs

mode=dense short-circuits immediately - the model comes back unpatched, no logging, no delegation. Any other mode computes an effective warmup ratio: with warmup_mode=warmup_steps it's min(steps, warmup_steps) / steps; with warmup_ratio it's your ratio, checked to be within [0, 1], and anything else raises. Then it calls the official patch with tau, start_percent set to that warmup, end_percent=1.0, min_tokens, dense blocks for the first dense_layers layers, sink_conditioning="exact_kv_and_rows", and topk_ratio=0.0 - so the budget is Sol's own, not something you tune here. It logs one line naming the block count, tau, warmup percentage and dense layer count.

Inputs

• model - H3's model, after the loader. Output is a patched MODEL.
• mode - fidelity (20% dense warmup), speed (0%), custom, dense (no-op). Same four-choice layout as the Spark nodes.
• steps - the sampler's model-evaluation count, used to convert step-based warmup into a ratio. Same σ=0 convention as everywhere else in MiniMax-H3.
• warmup_mode, warmup_ratio (0.2), warmup_steps (4) - how much dense warmup to run.
• dense_layers (0) - leading transformer layers held dense.
• min_tokens (12288) - keep short sequences dense.
• strict - present, and ignored. The code literally deletes it before patching. It's there so the widget list matches the Spark nodes' schema; don't read it as a behaviour switch.
• tau - float, default 1.0, range 0 to 4. The author's own knob for this path; leave it at 1.0 unless you're deliberately sweeping it.

There's no topk_mode, topk_ratio or topk_blocks here - three fewer widgets than Spark's node - and no dense_backend, tail_granularity or reblock_layout.

Installing

ComfyUI Manager handles it (registry publisher zechengtang, node ID comfyui-spark-h3), or:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/zechengtang/Spark-H3
# restart ComfyUI

The pack also publishes per-architecture release ZIPs with an installer, which is the officially supported path if you're using the Spark attention nodes:

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

You need ComfyUI 0.38.x or 0.39.x (0.39.2 recommended) with native MiniMax-H3 support - this node imports ComfyUI's sparse-attention module at patch time and there's no fallback if it isn't there. Models come separately from Comfy-Org/MiniMax-H3.

Where people get burned

"Spark-H3 Sol expects ComfyUI's native MiniMaxH3Model." You're patching something that isn't the native H3 DiT - usually a wrapper or quantised loader that presents a different class. This node is hard-wired to the native model.

Nothing changed and you can't tell why. Check mode. dense is a deliberate no-op, and it's the mode you land in after clicking around the presets. The log line naming the block count is how you confirm the patch actually applied; if it's missing, the patch never ran.

Chaining it with a Spark node. Pick one attention patch per model. This node and a Spark attention node in series is not a configuration the authors support or test.

The name. The SM120 suffix is a registration artifact - it inherits the SM120 Spark node's input schema. The code path itself never checks your compute capability, and it needs no architecture-specific backend. If you're on a 30- or 40-series card and curious what the official Sol path looks like next to Spark, it will run for you.