<h2 id="minimax-h3-pruned-lora-adapter">MiniMax H3 Pruned LoRA Adapter</h2>MiniMax H3 pruned checkpoints replace the full 2688-dimensional time embedding and AdaLN branch with a shared 8-dimensional <code>adaln_t_table</code> plus per-block projections. This creates a compatibility problem for LoRAs. The original LoRA still works in 2688-dimensional <code>silu(t_emb)</code> 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.<h3 id="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">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</h3><h2 id="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-perturbationseven-when-the-adaln-modulation-error-is-as-small-as-1e-5-to-1e-4.-after-propagating-through-50-layers-this-can-result-in-a-10percent-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-lorait-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.comxiaolibai-sysminimax-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."><span style="background-color:rgb(21, 21, 23);color:rgb(249, 250, 251);font-family:quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, Oxygen, Ubuntu, Cantarell, &quot;Open Sans&quot;, &quot;Helvetica Neue&quot;, sans-serif;font-size:16px">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 <a target="_blank" rel="ugc" href="https://github.com/xiaolibai-sys/MiniMax-H3-Lora-Bake">https://github.com/xiaolibai-sys/MiniMax-H3-Lora-Bake</a><span style="background-color:rgb(21, 21, 23);color:rgb(249, 250, 251);font-family:quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, Oxygen, Ubuntu, Cantarell, &quot;Open Sans&quot;, &quot;Helvetica Neue&quot;, sans-serif;font-size:16px">, where you can bake the converted LoRA weights to reduce runtime LoRA memory usage. Finally, thank you all for your support. <span style="background-color:rgb(21, 21, 23);color:rgb(249, 250, 251);font-family:quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, Oxygen, Ubuntu, Cantarell, &quot;Open Sans&quot;, &quot;Helvetica Neue&quot;, sans-serif;font-size:16px">But my vision will never change.</h2>Latest VersionUse the latest version of MiniMax-H3-Pruned-Lora-Adapter, v1.1.0 :<a target="_blank" rel="ugc" href="https://github.com/xiaolibai-sys/MiniMax-H3-Pruned-Lora-Adapter">https://github.com/xiaolibai-sys/MiniMax-H3-Pruned-Lora-Adapter</a>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 <code>dora_scale</code> keys instead of the legacy <code>diff_b/diff</code> keys. If an older file contains a DoRA backbone, regenerate it with v1.1.0.How It WorksThe full model provides the 2688-dimensional AdaLN weights and time embedder. The workflow first computes E as <code>silu(time_embedder(t))</code> 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).THere 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_iwhere 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 <code>adaln_t_table</code>, <code>blocks.N.adaln_proj.linear.weight</code> and bias, and <code>final_layer.adaln_proj.linear.weight</code> and bias. Backbone keys load as normal LoRA adapters. AdaLN keys load as full replacements. No <code>h3_silu_temb_grid</code> file is required at runtime.For DoRA backbone in v1.1.0, the generated file uses <code>lora_A</code>, <code>lora_B</code>, and <code>dora_scale</code>. This is the official ComfyUI DoRA format. Legacy <code>diff_b/diff</code> DoRA output is no longer produced.Fixed Table and Multiple LoRA CombinationIf 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 <code>optimize_table</code> to <code>false</code> and <code>init_table</code> to <code>builtin:fl2va</code> or <code>builtin:ref2va</code>. 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_commonThis 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 <code>optimize_table</code> <code>true</code>. 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 ExplanationThe 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).Twhere E is <code>silu(time_embedder(t))</code>, 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_iThe 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-5Fixed projection: block max relative error 8.8e-5 block mean relative error 6e-5 final layer relative error 1.27e-4Both 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 UseRequired files:<ul><li>A full MiniMax H3 BF16 model</li><li>One or more LoRA files</li><li>Python with PyTorch, CUDA, and safetensors installed</li><li>Enough disk space for the output LoRA</li></ul>Optional files:<ul><li>An official <code>h3_silu_temb_grid.safetensors</code> if 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.</li></ul>Download the latest version of the table builder repository:<a target="_blank" rel="ugc" href="https://github.com/xiaolibai-sys/MiniMax-H3-Pruned-Lora-Adapter">https://github.com/xiaolibai-sys/MiniMax-H3-Pruned-Lora-Adapter</a>Use v1.1.0 or newer. Edit <code>config.json</code> at the repository root. Set <code>inputs.full_model</code> to the BF16 model path. Set <code>inputs.loras</code> to the LoRA paths and their strengths. Set <code>optimization.optimize_table</code> to <code>false</code> for fixed-table linear combination, or <code>true</code> for joint ALS optimization. Set <code>optimization.init_table</code> to <code>builtin:fl2va</code> or <code>builtin:ref2va</code> when using a shared fixed table. Set <code>optimization.als_iters</code> to the number of ALS iterations when <code>optimize_table</code> is <code>true</code>. Set <code>outputs.lora</code> to the complete pruned LoRA output path. Set <code>outputs.table</code> to a path if you also want the aligned table and projection file.After editing <code>config.json</code>, run the entry script:python run_build_adaln.pyThe 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 <code>ComfyUI/models/loras</code>.ComfyUI Node PackageSupport for loading this format in ComfyUI is available in ComfyUI-MiniMaxH3 with fixed <code>shift_audio</code>:<a target="_blank" rel="ugc" href="https://github.com/xiaolibai-sys/ComfyUI-MiniMaxH3">https://github.com/xiaolibai-sys/ComfyUI-MiniMaxH3</a>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:<a target="_blank" rel="ugc" href="https://huggingface.co/larryvrh/MiniMax-H3-Turbo-Lora">https://huggingface.co/larryvrh/MiniMax-H3-Turbo-Lora</a>Official ComfyUI LoRA MechanismOfficial ComfyUI support for the complete pruned LoRA format is proposed here:<a target="_blank" rel="ugc" href="https://github.com/Comfy-Org/ComfyUI/pull/15353">https://github.com/Comfy-Org/ComfyUI/pull/15353</a>Under the official PR:<ul><li>Standard backbone LoRA keys go through the normal ComfyUI LoRA adapter path and are applied additively.</li><li>AdaLN replacement keys are handled as full set patches at the loader boundary.</li><li>With a shared fixed table, multiple complete pruned LoRAs combine their AdaLN projections linearly.</li><li>Multiple standard LoRA backbone adapters remain linearly additive.</li><li>Multiple DoRA backbone adapters are applied sequentially by ComfyUI because DoRA is nonlinear and order-dependent.</li><li>DoRA files generated by v1.1.0 use <code>dora_scale</code> and are recognized by ComfyUI directly.</li><li>Legacy <code>diff_b</code> DoRA files are rejected with a clear error so they cannot be silently misapplied.</li></ul>The generated LoRA format itself remains unchanged for standard LoRA files. Users still place the same complete pruned LoRA into <code>ComfyUI/models/loras</code> and load it with the same LoRA loader. <h3 id="my-vision">My Vision</h3>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.

MiniMax Lora Adapter for meging with pruned model

v1.1.0<ul><li>DoRA backbone is now exported using ComfyUI's official <code>dora_scale</code> format instead of the legacy <code>diff_b/diff</code> keys.</li><li>Official ComfyUI LoraLoader can correctly apply the new DoRA format.</li><li>Legacy DoRA files are now rejected explicitly to prevent silent numerical errors.</li><li>Existing standard LoRA and complete pruned LoRA files remain fully compatible and do not need to be regenerated.</li><li>If an older file contains a DoRA backbone, regenerate it with v1.1.0.</li><li>Non-DoRA LoRAs and existing workflows are unaffected. </li></ul>Do not use the old version.

Files with SHA256: 9cd9ae59c3672688905eacf530f9c395c97a786e72726ffa6432e301d1cb86eb