H3 SLA Attention

If you've dropped the lightx2v SLA turbo LoRA into a MiniMax-H3 workflow and wondered why it didn't make anything faster - that's not you doing it wrong. The LoRA only makes the model tolerate sparse attention; the sparse attention itself is a piece of the inference path that plain ComfyUI never had. H3SLAAttention is that missing piece, shipped as a node.

How it works

Block-sparse attention is the trick: instead of attending every token to every token (quadratic, expensive), each query block is scored against every key block with one small pooled matmul, and only the top 1 - sparsity_ratio fraction actually gets attended. Nothing here is trained and nothing is downloaded - the sparsity is decided at runtime from the query and key tensors. That's the whole point of the pairing: the lightx2v SLA turbo LoRA was distilled against this exact inference path, so its job is to make the model behave well under the sparsity, not to provide it. The node wires itself in through transformer_options["optimized_attention_override"] at H3's one attention call site - not the legacy set_model_attn1_patch hook, which is the SD-UNet cross-attention path H3 never consults (a patch installed there reports success and silently does nothing). The kernel itself is Triton.

The author measured end-to-end on a 5090 at 768p/15s with the SLA turbo LoRA: ~44 s/it dense, ~31 s/it at 0.85 sparsity, ~25 s/it at 0.90 - call it 1.4–1.75x, with no extra VRAM. Attention is only ~30s of that 44s step, so the Amdahl ceiling is around 3.17x no matter how fast attention gets; the widely-quoted 2.5x is an eight-GPU number. Long sequences benefit most - the gain grows with resolution and duration.

The inputs that matter

• model - MODEL, after the LoRA loader(s), last before the sampler.
• sparsity_ratio - fraction of key blocks skipped. 0.85 is what lightx2v ships and what the LoRA was distilled against; 0.90 is what this author validated, ~15% faster. Here's the trap: below about 0.60 this kernel is slower than dense attention, so a low value is a loss, not a safe fallback. 0.0 disables sparsity without removing the node.
• block_size - 64 or 128. This matters far more for audio than video: H3 packs audio at 80 rows per second, so a 128-row block forces 1.6 seconds of audio down a single attention pattern. Speech came out robotic at 128 and clean at 64 for ~2% more time. Use 128 only if you generate without meaningful audio.

The optional inputs are the interesting ones. min_seq_len (default 8192) keeps short sequences dense - it guards the short text-refiner attention, which must never be sparsified, and short clips where block selection costs more than it saves. dense_last_steps runs the final N sampling steps at full attention; 0 matches lightx2v exactly, 1 costs a little speed and can recover fine detail, since the last step's error is the one you actually see. protect_audio (on by default) always attends the [text | cond | audio] prefix - audio is ~1% of the packed sequence, so plain top-k regularly drops all of it and your soundtrack degrades while the video still looks fine. enabled toggles the whole thing for a like-for-like speed baseline without rewiring.

What people actually hit

The speech-artefact question comes up a lot. The author's finding: sparsity did not turn out to drive the speech artefacts on H3 - step count did, so use 6 steps rather than lowering sparsity to "fix" speech. And if a LoRA can't take 0.7+ sparsity, this node has nothing to offer it - don't force it.

Install

Same pack as the AdaLN fix, same install: search "PlagueKind-Nodes" in ComfyUI Manager, or

cd ComfyUI/custom_nodes
git clone https://github.com/PlagueKind/ComfyUI-PlagueKind-Nodes.git

Restart after. The Triton kernel needs Triton, which ships with standard torch CUDA installs - no separate dependency to fetch. If Triton is missing or something goes wrong on your GPU, the node catches it and passes the model through unchanged, so your run degrades to plain dense attention instead of dying. Check the console for [H3Utils] SLA: patch installed but never invoked - that warning means the patch is in but the attention path changed under you, and nothing is being sparsified.