MiniMax H3 Turbo / SLA Profile Router (Advanced EXP)

H3 has two different speed paths floating around the community, and they are not interchangeable: the consumer 8-step Turbo LoRA and the LightX2V SLA sparse-attention experiment. The Turbo/SLA Profile Router exists to keep them from getting mushed together - because running an SLA LoRA as a dense Turbo fallback is exactly the kind of mistake that produces a "collapsed" video that looks like the model broke. Its whole personality is fail-closed: mismatched sigmas refuse before sampling, and an SLA file is never silently treated as a Turbo.

How it works

You feed it the Dual-Clock MODEL (optionally through the complete KJNodes MiniMax H3 Sage patch - do not attach an external LoRA) and the SIGMAS from the same Dual-Clock node. Then the profile Combo picks a lane:

• consumer_turbo8_recommended - loads the corrected Alpha8 bypass Turbo LoRA, requires 8 NFE with video/audio shift 12/3, dense or authenticated KJ Sage attention. This is the validated, project-blessed route.
• sla_4step_upstream_exact_exp - loads the LightX2V SLA LoRA at the published 4 NFE, shift 6/3, 85% sparse. This replicates the upstream experiment's exact contract; it is not a quality preset.
• sla_4step_int8_bypass_exp - the research lane: 4/6/3 with the INT8 ConvRot base left untouched and the SLA residual applied dynamically. Explicitly not validated.
• disabled_identity - no LoRA, no attention change. Handy as an A/B control.

The turbo_lora_name and sla_lora_name Combos are the two files it can load, and base_policy (default auto_detect_exp) records whether your base resembles the published BF16/FP8 evidence - reporting mismatches without blocking, so you stay informed while the node stays permissive about which base actually runs.

Outputs: model, a runtime object (H3_T8_LIGHTX2V_SLA_RUNTIME) that carries the SLA state for downstream consumers, and report_json saying exactly which lane ran and how many forwards happened.

Why the strictness matters

The tooltips are unusually explicit about the failure mode: a sigmas mismatch "fails before sampling instead of producing a misleading collapsed video." The author's verification report documents the exact incident - an 8-NFE rerun that the SLA path rejected after ~1 second, which his own runtime report proved was zero SLA calls and incompatible FL2VA anchors, not an SLA kernel failure. That's the kind of archaeology this node is designed to spare you. It will never quietly run an SLA LoRA through dense attention and call it "close enough."

Installing it

Standard pack install - ComfyUI Manager search "MiniMax H3 Audio T8", or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Update ComfyUI core first, restart. The LoRAs themselves go in ComfyUI/models/loras - the Turbo file is the ..._alpha8-T8-convert.safetensors and the SLA file is the ..._768p_sla_comfyui_bf16.safetensors. The max_router_workspace_mib (default 512) is an SLA-only fail-closed workspace ceiling, not a whole-workflow VRAM limit, and sla_start_percent/sla_end_percent only matter for the INT8 bypass lane (0.15–0.90 maps to dense/sparse/sparse/sparse across four forwards).

Where people get burned

Three things. The Alpha8 Turbo file must be the corrected convert - the pack shipped a fix because the original Alpha8 reference had issues, so don't keep an old copy around. Second, the SLA "infer_steps=5" confusion: LightX2V's published infer_steps=5 means five sigma grid points, which is four model evaluations, which is the 4 NFE this node demands - don't "help" by raising NFE. And third, the released SLA evidence is BF16/FP8-family only; if you're on the INT8 ConvRot base, the exact profile reports it rather than pretending to be upstream parity. That honesty is a feature.