MiniMax H3 BSA All-Exact (Scheduled Dense Control)

The author's description is the honest one: "Experiment control: SDPA for warmup and dense layers; full-sink BSA for active H3 attention." This is not a speedup node and it isn't trying to be. It's the reference arm of an ablation.

Spark-H3's pitch is that two specific additions - reblocking tokens by attention preference, and reweighting the compressed branch's summaries - improve block-sparse attention for MiniMax-H3. To show that, you need to know what plain block-sparse attention does at the same schedule. That's this node: it runs the warmup and dense-layer portion exactly like the Spark nodes, then runs ComfyUI's block-sparse path with all selected blocks computed exactly, full sinks and no compression. Everything Spark adds is stripped out.

If you're not reproducing the pack's benchmarks, you don't need it. If you are, it's the difference between a claim and a measurement.

How it works

It requires ComfyUI's native MiniMax-H3 model, and it says so bluntly - anything whose class isn't MiniMaxH3Model with a blocks attribute gets a TypeError, and dense_layers larger than the block count gets a ValueError.

The patch replaces the attention function inside each transformer block via ComfyUI's double_block replacement hook, and decides per block whether to run the original dense block or the sparse one:

• the first ceil(steps × warmup_percent / 100) evaluations stay dense - the same warmup gate the Spark nodes use, just expressed as a percentage instead of a ratio;
• the first dense_layers blocks always stay dense;
• sequences shorter than min_tokens stay dense;
• everything else runs ComfyUI's h3_sparse_attention under a policy built with tau=1.0, topk_ratio=0.0, all_exact=True and sink_conditioning="off".

The schedule counter advances on block 0 at each evaluation, and it detects a new run two ways: the evaluation index exceeding steps, or sigma increasing between calls. That second check matters - in a two-pass workflow the second pass raises sigma back up, and the intent is for the warmup to restart cleanly rather than continue counting from the first pass.

One design choice worth respecting: if a layer reaches the sparse branch and ComfyUI's own eligibility check says it shouldn't be sparse, the node raises rather than quietly computing something else - BSA all-exact expected active H3 layer N, but it was ineligible. In a benchmark harness, a silent substitution would turn a controlled comparison into an uncontrolled one without anyone noticing.

Inputs

• model - native MiniMax-H3 model; patched MODEL out.
• steps - 20 by default, and it means actual model evaluations, not sampler steps. MiniMax's σ=0 endpoint doesn't run the transformer, so a nominal 20-step run needs 19 here if warmup is going to mean what you think it means.
• warmup_percent - 20.0, the percentage twin of the Spark nodes' 0.2 warmup ratio.
• dense_layers - 1 by default, notably not 0; the pack's own rerun script uses 1 with 20% warmup.
• min_tokens - 12288, the short-sequence dense threshold. Note it accepts 0 here, which means "never keep short sequences dense".

It logs one line per evaluation - [BSA-all-exact] evaluation 7/19: BSA active; first 1 layers SDPA - so you can confirm the schedule fired at all instead of trusting the graph.

Installing

Most people should install the pack once and ignore this node; it arrives with everything else:

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

ComfyUI Manager works too - registry publisher zechengtang, node ID comfyui-spark-h3. Requirements: ComfyUI 0.38.x or 0.39.x (0.39.2 recommended) with native MiniMax-H3 support, since this node imports comfy_extras.nodes_sparse_attention at patch time. No Spark kernel is required for the all-exact path itself, but the wheel installer comes along with the package. Models from Comfy-Org/MiniMax-H3.

If you're actually benchmarking with it

Two things will wreck your numbers faster than anything in the node.

Mixed compile state. The pack's own README documents that in a controlled 25-prompt check, toggling the torch.compile state of denoising shifted Spark's PSNR by 3.15 dB on otherwise identical settings. That's larger than most of the quality differences the benchmarks are trying to measure. Match the compile state across every arm, or you're measuring your launch script.

Unmatched step counts. The all-exact path and the Spark path need to declare the same steps, or their warmup windows don't line up and you're comparing a 20%-dense run against a 15%-dense one. Same for the LoRA, the seed, the resolution and the frame count - the pack's harness pins all of them, which is exactly why its numbers are quotable and random forum numbers aren't.

And the ordinary rule applies: don't put this on the same model as a Spark or Sol attention node. One attention patch per model, always.