MiniMax H3 LightX2V SLA Runtime Audit (Advanced EXP)

If you're running the LightX2V SLA node for speed, the whole bet is "85% of attention blocks get skipped by the learned router, and every call runs through the sparse Sage2 kernel." The failure mode that makes that bet worthless isn't a crash - it's a silent fallback, where the model quietly runs the dense path and you still get your render, just slower and never knowing. This node exists to make that impossible to ignore. It's the audit that fails loudly unless all four H3 forwards and all 50 main blocks per forward used the selected dense-control or sparse path with no hidden kernel fallback.

It's in T8/MiniMax H3/Performance/Experimental and it's an output node - it sits at the end of the chain, after the sampler, and it's the "prove it" step in a workflow whose author has spent an unusual amount of effort on not letting claims outrun evidence.

How it works

You connect the av_latent that came out of the sampler plus the runtime object produced by the SLA Loader/Attention node (the H3_T8_LIGHTX2V_SLA_RUNTIME). The audit then cross-checks what the runtime recorded against what should have happened: four H3 forwards (the 4-step profile), each with 50 main blocks, each block on the intended dense-control or sparse path. Any hidden fallback - a kernel that didn't load, a router that bailed, an attention patch that grabbed the call - and the node fails.

That's the entire design, and it's the right one: SLA gives you a performance claim, and performance claims are only as good as the accounting. The audit is the accounting.

The inputs that matter

• runtime - the H3_T8_LIGHTX2V_SLA_RUNTIME from the SLA Loader node. Without it there's nothing to audit. This is a required input, not an optional nicety.
• av_latent - required too, because the audit also passes the latent through (it's an output node, so it returns what it received plus the verdict).

That's it. Two required inputs, no knobs. The node is deliberately boring because the question it answers is binary: did the sparse path actually run, or didn't it?

Outputs

av_latent (passed through, so you can put this node inline without breaking the chain) and report_json with the block-by-block accounting. The report is where the detail lives - a failure tells you which forward and which block fell back, which is exactly the information you need to fix it.

Installing it

Pack install: ComfyUI Manager → "MiniMax H3 Audio T8", or git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8 into ComfyUI/custom_nodes, restart. It has no dependencies of its own beyond the SLA runtime type, but the runtime only exists if you've got spas-sage-attn installed and matched to your Torch/CUDA (see the SLA Loader article for that dance).

Common issues

Audit fails on "kernel fallback." The attention kernel didn't run for some blocks - usually an environment mismatch (Sage wheel vs your GPU architecture) or a foreign attention node that grabbed the wire. Fix the environment, don't silence the node. The pack's own troubleshooting section for KJ Sage is the model here: verify smXX architecture matches your GPU, and don't let the workflow "silently degrade" while still claiming Sage.

Audit passes but it's not faster. Then you've proven the sparse path runs and the win just isn't there on your shape/size. That's a result, not a bug - the README says as much: mechanical verification isn't a speed or quality promise.