MiniMax H3 Pruned LoRA Adapter
MiniMax H3 pruned checkpoints replace the full 2688-dimensional time embedding and AdaLN branch with a shared 8-dimensional adaln_t_table plus per-block projections. This creates a compatibility problem for LoRAs. The original LoRA still works in 2688-dimensional silu(t_emb) space, while pruned models no longer contain that space. Loading it directly on a pruned model either fails to apply AdaLN or produces shape mismatches.
This workflow solves that by using a full BF16 model and the LoRA together to bake a complete pruned LoRA. It computes the exact AdaLN modulation target and fits a rank-8 table plus per-block projections that pruned models can use directly.
Announcement
After several days of experimentation, I have identified a serious issue: certain DiT blocks (from the 20th to the 40th) in Minimax H3 are extremely sensitive to input perturbations—even when the AdaLN modulation error is as small as 1e-5 to 1e-4. After propagating through 50 layers, this can result in a 10% difference in the hidden L2 norm (compared to the BF16 model + LoRA). Therefore, this is not a good approach, and I have decided to abandon it. Perhaps a better alternative is to follow Larryvrh's method of precomputing t_embedding and computing online. In other words, the offline approximated AdaLN_t_table with low-rank structure cannot adequately represent the rich dynamics of LoRA—it is lossy. However, for users with extremely limited VRAM, this remains the only way to bake weights offline into the model (at least for now). I will provide a simple baking script at https://github.com/xiaolibai-sys/MiniMax-H3-Lora-Bake, where you can bake the converted LoRA weights to reduce runtime LoRA memory usage. Finally, thank you all for your support.
But my vision will never change.
Latest Version
Use the latest version of MiniMax-H3-Pruned-Lora-Adapter, v1.1.0 :
https://github.com/xiaolibai-sys/MiniMax-H3-Pruned-Lora-Adapter
v1.1.0 keeps the existing complete pruned LoRA format unchanged for standard LoRA files. Backbone LoRA keys and AdaLN replacement keys remain the same. Previous standard LoRA and complete pruned LoRA files remain fully compatible and do not need to be regenerated.
The only format change is for DoRA backbone. v1.1.0 outputs DoRA using ComfyUI's official dora_scale keys instead of the legacy diff_b/diff keys. If an older file contains a DoRA backbone, regenerate it with v1.1.0.
How It Works
The full model provides the 2688-dimensional AdaLN weights and time embedder. The workflow first computes E as silu(time_embedder(t)) across 1025 timesteps. For each block it constructs the exact target modulation:
M_i = E @ W_i.T + b_i + E @ (B_i @ A_i).T
Here W_i and b_i are the full AdaLN weight and bias, while A_i and B_i are the LoRA AdaLN matrices. The workflow then fits:
M_i approximately equals T @ P_i.T + b_i
where T is the shared 8-dimensional table, P_i is the per-block projection, and b_i is the bias.
The fitting is done block by block. Each DiT block is processed independently and its projection is solved separately. The global table is initialized first, either from PCA or from an official pruned table, and then optionally refined with alternating least squares. This keeps memory use bounded to roughly one block at a time. Peak GPU memory is around 2 to 3 GB for the full-size model in practice, and the workflow does not need to keep all 50 blocks resident at once.
The generated complete pruned LoRA contains the original backbone LoRA keys, the adaln_t_table, blocks.N.adaln_proj.linear.weight and bias, and final_layer.adaln_proj.linear.weight and bias. Backbone keys load as normal LoRA adapters. AdaLN keys load as full replacements. No h3_silu_temb_grid file is required at runtime.
For DoRA backbone in v1.1.0, the generated file uses lora_A, lora_B, and dora_scale. This is the official ComfyUI DoRA format. Legacy diff_b/diff DoRA output is no longer produced.
Fixed Table and Multiple LoRA Combination
If each adapter generates its own optimized table, the projection spaces are not compatible. You cannot simply average or add projections from different tables.
For multiple LoRAs, use a shared fixed table. Set optimize_table to false and init_table to builtin:fl2va or builtin:ref2va. Only projection and bias are optimized. This makes the combination linear:
P_combined = P_base + sum(strength_j (P_j - P_base))
b_combined = b_base + sum(strength_j (b_j - b_base))
T_combined = T_common
This is the safe path for stacking multiple LoRA adapters. It gives a small precision tradeoff but keeps the combination mathematically consistent.
For a single high-accuracy adapter, use optimize_table true. The workflow can start from the official pruned table and run alternating least squares. ALS alternately solves projections and updates the table. This improves accuracy when you only need one complete LoRA.
Error Explanation
The accuracy numbers compare the fitted rank-8 AdaLN representation against the exact modulation target of the BF16 full model with the LoRA applied. The reference is:
M_i = E @ W_i.T + b_i + E @ (B_i @ A_i).T
where E is silu(time_embedder(t)), W_i and b_i are the full BF16 AdaLN weight and bias, and A_i and B_i are the LoRA AdaLN matrices. The fitted representation is:
T @ P_i.T + b_i
The reported error is the relative reconstruction error of this AdaLN modulation matrix. It is not the final video or audio output error. A small modulation error does not automatically guarantee identical generated audio or video, because the model can be more sensitive at some timesteps or modalities.
Measured on the real FL2VA BF16 model with the 4-step Turbo LoRA:
ALS:
block max relative error 1.5e-5
block mean relative error 6e-6
final layer relative error 4.5e-5
Fixed projection:
block max relative error 8.8e-5
block mean relative error 6e-5
final layer relative error 1.27e-4
Both modes are below 0.02 percent maximum relative error on the AdaLN modulation. ALS is more accurate and is recommended for a single complete LoRA. Fixed projection is slightly less accurate but is the correct mode for multiple LoRAs that must be combined linearly.
For practical deployment, end-to-end quality still needs to be verified by sampling with the pruned model. The AdaLN error is a strong proxy for correctness, but it is not a substitute for listening to the generated audio or viewing the generated video.
How to Use
Required files:
A full MiniMax H3 BF16 model
One or more LoRA files
Python with PyTorch, CUDA, and safetensors installed
Enough disk space for the output LoRA
Optional files:
An official
h3_silu_temb_grid.safetensorsif you want to compare against the official grid. The workflow can compute E from the full model time embedder when this file is not provided.
Download the latest version of the table builder repository:
https://github.com/xiaolibai-sys/MiniMax-H3-Pruned-Lora-Adapter
Use v1.1.0 or newer. Edit config.json at the repository root. Set inputs.full_model to the BF16 model path. Set inputs.loras to the LoRA paths and their strengths. Set optimization.optimize_table to false for fixed-table linear combination, or true for joint ALS optimization. Set optimization.init_table to builtin:fl2va or builtin:ref2va when using a shared fixed table. Set optimization.als_iters to the number of ALS iterations when optimize_table is true. Set outputs.lora to the complete pruned LoRA output path. Set outputs.table to a path if you also want the aligned table and projection file.
After editing config.json, run the entry script:
python run_build_adaln.py
The workflow processes each block one at a time, so it does not need all 50 blocks in memory. The optional aligned table file is around 166 MB. The complete pruned LoRA size depends on the backbone LoRA; for the 4-step Turbo LoRA it is roughly 1.35 GB with float32 backbone weights.
Place the generated complete pruned LoRA into ComfyUI/models/loras.
ComfyUI Node Package
Support for loading this format in ComfyUI is available in ComfyUI-MiniMaxH3 with fixed shift_audio:
https://github.com/xiaolibai-sys/ComfyUI-MiniMaxH3
Version 1.2.0 and newer include MiniMax H3 LoRA Loader support for complete pruned LoRA files.
The acceleration LoRA used for this workflow is available here:
https://huggingface.co/larryvrh/MiniMax-H3-Turbo-Lora
Official ComfyUI LoRA Mechanism
Official ComfyUI support for the complete pruned LoRA format is proposed here:
https://github.com/Comfy-Org/ComfyUI/pull/15353
Under the official PR:
Standard backbone LoRA keys go through the normal ComfyUI LoRA adapter path and are applied additively.
AdaLN replacement keys are handled as full set patches at the loader boundary.
With a shared fixed table, multiple complete pruned LoRAs combine their AdaLN projections linearly.
Multiple standard LoRA backbone adapters remain linearly additive.
Multiple DoRA backbone adapters are applied sequentially by ComfyUI because DoRA is nonlinear and order-dependent.
DoRA files generated by v1.1.0 use
dora_scaleand are recognized by ComfyUI directly.Legacy
diff_bDoRA files are rejected with a clear error so they cannot be silently misapplied.
The generated LoRA format itself remains unchanged for standard LoRA files. Users still place the same complete pruned LoRA into ComfyUI/models/loras and load it with the same LoRA loader.
My Vision
My hope is to remove the potential wall between the full-model and pruned-model LoRA ecosystems.
The complete pruned LoRA format is designed as a common bridge. Developers train once, adapt once, and publish one file. Users on pruned or quantized models can load it with the same ComfyUI LoRA loader.
The shared fixed table makes multiple LoRAs easy to combine without re-fitting or re-training. This lowers the barrier to mixing styles, characters, and acceleration LoRAs, and gives creators a predictable ecosystem instead of fragmented one-off formats.
My hope is to keep the format stable and ComfyUI-compatible, so future LoRA releases do not require custom nodes, special loaders, or duplicate pruned versions. That lets the MiniMax H3 community grow around reusable, combinable, and standardized pruned LoRAs.
Description
FAQ
Comments (7)
what
Loras are made off of the full model and won't work with the smaller pruned models. This tool is supposed to fix the lora so it can work with your smaller models.
explain me like i'm 5
Your loras don't work. Fix the lora with this tool. Now go potty.
Explanation: Loras trained on the non pruned have to be used on the non pruned. Loras trained on the pruned need to be used on the pruned. This apparently allows you to use Loras trained on the pruned on the non pruned. Who knows how well it works.
What a mess. It looks like everything is being trained on the base model, while the one people actually use is the pruned one. And only sexgod's one has separate versions.
It might be better just to have a custom node do this rather than rely on running this through the terminal. Then everyone can just use a ComfyUI workflow rather than type it out every time.
Ugh. That means people are going to have to maintain local copies of the bf16 versions for both the R2V and I2V models unless creators consistently have pruned and non-pruned versions.
