Nodes/comfyui-minimax-h3-audio-T8/MiniMax H3 LoRA Compatibility Loader (Advanced/T8)
ComfyUI Node

MiniMax H3 LoRA Compatibility Loader (Advanced/T8)

An H3 LoRA loader that stops being picky about where the LoRA came from

By T8mars·Created about a month ago·Updated a day ago· 1,031
MiniMax H3 LoRA Compatibility Loader (Advanced/T8)
  • model
  • model
  • report_json
lora_name
strength_model1.00

LoRAs for MiniMax H3 are a mess of provenance. The model's distilled recipes - Turbo, PDD, SLA, and the whole acceleration family - ship from different sources, and plenty of H3 LoRAs in the wild come out of DiffSynth-Studio and ModelScope toolchains with module names that don't match what vanilla ComfyUI expects. Load one of those with the stock LoRA loader and you either get silent wrongness or a wall of key-mismatch warnings. This node is the pack's compatibility valve: a MODEL-only H3 LoRA loader that accepts native ComfyUI LoRAs and direct DiffSynth-Studio/ModelScope module names, then maps them by structure.

The word "compatibility" is doing precise work here. The description says it uses structural key mapping only - filenames and sizes are display-only, with no hash scan and no model-file execution gate. That's the T8 design philosophy across this whole pack: don't block or gate on metadata, map the actual tensor structure and let the math decide. It's friendlier than the alternative, and it means a renamed or re-quantized file won't get refused for the wrong reasons.

What it takes and gives

Inputs are minimal - this is a small, single-purpose node:

  • model - the H3 model you're applying the LoRA to. This is MODEL-only, so it slots right into your existing model chain.
  • lora_name - a combo of the LoRA files found in ComfyUI/models/loras. Drop your DiffSynth-Studio-sourced H3 LoRA in there and it'll show up.
  • strength_model - default 1.0, range −10 to 10. Negative strengths are how you subtract a LoRA's effect, which is occasionally the exact experiment you want on an over-trained distilled LoRA.

Outputs: the patched model (wire it where the original model went) and a report_json describing the key mapping it performed. The report is the useful part - it's where you can see whether the structural mapping actually matched anything, instead of guessing.

When you actually need it

If you're running an all-native ComfyUI H3 workflow with LoRAs that already load fine, you can skip this node. It earns its keep in two situations: you have a DiffSynth-Studio/ModelScope-derived LoRA (common for the Chinese ecosystem this pack orbits, where the model releases and the tooling overlap), or you're debugging why a LoRA silently does nothing - the structural mapping report will tell you if the keys lined up.

One caution that applies to every LoRA on this model: H3's distilled recipes are picky about their base. The pack's README warns FL2VA, Ref2VA, pruned and full base models shouldn't be mixed, and the PDD acceleration LoRAs specifically must be loaded with the matching base-model version. A loader that maps keys structurally can't fix a LoRA that was trained for a different base distribution - it'll just map cleanly and still look wrong. Match the base first.

Install

Same pack, same routine:

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

or ComfyUI Manager → "MiniMax H3 Audio T8" → restart. Update ComfyUI itself first (comfy_api.latest, comfy.ldm.minimax), and remember the requirements.txt is intentionally empty - ComfyUI supplies the stack. The LoRAs go in ComfyUI/models/loras, exactly where you'd expect.

CategoryT8/MiniMax H3/Model/Advanced

Inputs (3)

NameTypeDefaultDescription
modelMODEL
lora_nameCOMBO1 options: disabled
strength_modelFLOAT1.00-10–10

Outputs (2)

NameTypeDescription
modelMODEL
report_jsonSTRING