MiniMax H3 SLA Precision V2 Runtime Audit (Advanced EXP)

Here's the problem with a sparse-attention patch: you can't tell from the picture whether it actually ran. The output looks like a video either way - the interesting question is whether the 90%-sparse kernel genuinely executed, or whether your card quietly fell back to dense attention the whole time and you just paid for a speed experiment that never happened. Kernel fallbacks are silent by default. That's why the T8 pack ships this node and tells you to put it at the end of every Precision V2 chain: it's the flight recorder, and it fails closed.

What it checks

The SLA Precision V2 Runtime Audit sits after sampling. Wire in the av_latent that came out of the sampler and the runtime object emitted by the SLA Precision V2 Attention node - that exact object, not a copy, not a proxy. It then checks the recorded runtime against the contract the attention node was supposed to honor:

• logical NFE matches the sigmas that were connected,
• every logical step was actually observed,
• each sparse step routed exactly 50 H3 blocks, each dense boundary step routed at least 50 dense H3 blocks,
• no sparse-kernel failure and zero kernel fallback,
• audio/language key blocks were protected (pinned),
• the sequence actually crossed the sparse threshold with at least one key block retained.

Every check lands in a structured report as a true/false field, and the summary status is precision_v2_mechanically_verified only if all of them pass. Any miss and the report says FAIL with the specific broken checks named. The node also marks the runtime object as finalized - one audit per run, no re-using a runtime to launder a second pass - and it refuses the wrong runtime type outright.

Fail-closed by design

So it's an output node with a shape that surprises nobody in this pack: av_latent in, av_latent out (a passthrough - the audit doesn't alter your video), plus report_json, which it also surfaces as text in the UI. Because it fails closed, a contract violation raises rather than quietly passing a render you might mistake for verified. That's the entire philosophy of the Precision V2 line in one node: better to stop and show you the failing check than to let "it rendered, so it worked" carry the day.

What a good report looks like

A real example from the author's validation, so you know what a good report looks like: 8 NFE run, steps 0 and 7 each logged 50 dense calls, steps 1–6 each logged 50 sparse calls (300 total), 20 pinned protection blocks, zero kernel fallback, 12,785-token sequence with 400 key blocks of which 59 were kept - and the decoded video/audio were byte-identical to the same render made before the per-step counters were added. That last bit is the real confidence builder: the observability itself doesn't perturb the math.

What the audit is not: it does not vouch for quality. The report ends with a standing disclaimer - mechanical execution only; normal-speed visual review and clear-dialogue listening remain mandatory. A green audit means the sparse kernel really ran the way it was configured, not that the output is good. That's a narrower claim than you might want, and it's exactly the claim you can trust.

Use it or skip Precision V2

Use it or don't use Precision V2 at all. If the runtime isn't there, the node refuses; if you skip the audit, you forfeit the one piece of evidence that the expensive sparse experiment you just ran was actually the experiment.

Installing it

Install: ComfyUI Manager search MiniMax H3 Audio T8, or git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git into custom_nodes, restart after updating ComfyUI core/frontend together. The dated workflow in 15-sla-attention shows the full chain with the audit in place - chain it after sampling, before you save, and read its report the way you'd read a unit test output.