MiniMax H3 SLA Dynamic LoRA Bypass V2 (Advanced EXP)
The SLA LoRA loader that refuses to re-quantize your FP8 base
- model
- model
- report_json
Every serious problem in the T8 pack's SLA history traces back to one mechanical mistake: applying the SLA LoRA the way you'd apply any LoRA - merged into the base weights. When your base is an FP8 quantized MiniMax H3 model, "merge then run" means re-quantizing the merged result, and that second quantization is what melted faces and made outputs fall apart. This small node exists to make that mistake impossible: it loads the SLA LoRA as a model-only dynamic residual over the quantized base, never merging it and never triggering a second quantization pass.
Where it sits in the chain
That makes it the first link in the SLA Precision V2 chain the pack recommends (workflow 15-sla-attention/2026-09-02_..._Advanced_EXP.json): Dual-Clock scheduler → SLA Dynamic LoRA Bypass V2 → SLA Precision V2 Attention → BasicGuider → sampler → Runtime Audit. The node's description is blunt about placement: place this before SLA Precision V2 Attention. The attention node downstream expects the model to already be carrying the SLA LoRA, so the bypass isn't optional garnish - it's the delivery mechanism.
What it does
What it actually does is refreshingly simple, which is why this article is short:
- Inputs:
model(your H3 model, usually an FP8 FL2VA base) andlora_name, a combo populated from yourmodels/lorasfolder. - Default
lora_name:minimax_h3_fl2v_turbo_4step_v0.1_768p_sla_comfyui_bf16.safetensors- the SLA Turbo LoRA the Precision V2 recipe is validated against. Load a different SLA LoRA and it still works as long as it's a genuine H3 SLA LoRA. - Outputs: the
model(patched, still FP8 base + separate residual) and areport_jsonaudit string.
There's nothing to tune, no strength widget, no hidden sampling control. If you're coming from the pack's old SLA route, this node is precisely the correction to it: previously SLA was applied as a standard weight patch (standard_patch), and the byte-identical-vs-dense and melt-free results the author now reports depend on the dynamic bypass behavior this node enforces. If you don't care about SLA's sparse-attention acceleration at all, you don't need this node - plain Turbo LoRA loading is a stock ComfyUI operation.
Set expectations, not speed
A honest sizing of expectations: the Precision V2 route this feeds is a quality-correction experiment, not a confirmed speed win or a universal default. In the author's single controlled run, Precision V2 measured ~12% faster end-to-end than a same-seed dense XFormers control and passed perceptual non-inferiority - but minimum free VRAM on the 16 GB test card (236 MiB) stayed under the project's own 512 MiB safety gate. Everything downstream of this node is Advanced EXP, and the docs say so repeatedly. What you can rely on is the mechanism: the FP8 base stays quantized once, the LoRA stays a residual, and the "re-quantized melt" failure mode is structurally gone.
Installing it
Install is pack-standard: ComfyUI Manager search MiniMax H3 Audio T8, or git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git into custom_nodes, then restart with ComfyUI core itself updated first (the pack leans on comfy.weight_adapter and friends, and an old core red-outs every T8 node at once). Drop the SLA LoRA into models/loras, use the matching FL2VA base rather than mixing variants, and run the dated Precision V2 workflow rather than hand-wiring the chain - the ordering of these three V2 nodes is load-bearing.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| lora_name | COMBO | minimax_h3_fl2v_turbo_4step_v0.1_768p_sla_comfyui_bf16.safetensors | 1 options: minimax_h3_fl2v_turbo_4step_v0.1_768p_sla_comfyui_bf16.safetensors |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| report_json | STRING | — |