MiniMax H3 PDD Acc (Experimental)

MiniMax H3 is a 33B omni-modal video model - incredible output, and a real appetite for VRAM and time at its full 32-step schedule. This node exists to cut that drastically. It's an experimental acceleration patch that takes H3's "PDD Acc" LoRA weights and step-conditioned output heads and lets you sample at 4–8 network evaluations per frame instead of 32, using a sigma schedule the node computes for you. Roughly: your H3 clip goes from slow to "queued and done before your coffee is."

PDD is Parallel Decoding Distillation - the same idea behind NVIDIA's FastGen-PDD work on distilling diffusion and flow models so a student predicts several timesteps at once. The pack adapts the conversion and head-fusion logic from the community MiniMax-H3-PDD-Acc node, with acceleration weights originally from Alibaba PAI's MiniMax-H3-Acc-LoRAs. You pick the variant that matches your generation mode and the node handles the distilled schedule.

How it works

You feed in your H3 model, and the node does two things. First it applies a trunk LoRA (pdd_lora) that reshapes the model's internals for accelerated sampling. Second, it fuses trained, step-conditioned output heads onto the model - the heads differ depending on how many steps you're taking, which is why the node talks about a "trained envelope." The full 32-step schedule is partitioned into blocks of 4 or 8 (the shapes the heads were trained on), each block collapses into one network evaluation, and the node hands you the matching sigmas.

The critical instruction, straight from the author: use the sigmas output with the Euler sampler. This isn't a normal schedule - the sigmas encode the distilled block structure, and a generic scheduler will fight it.

The inputs that matter

• pdd_lora - pick the file matching your H3 usage: FL2VA for first/last-frame generation, Ref2VA for reference-image generation. Choosing the wrong one is the classic mistake.
• nfe - 8, 7, 6, 5, or 4. 8 is the intended quality; 5–7 are trained-envelope middle grounds; 4 is fastest. If you're using H3 caching, an extra step compensates.
• partition - advanced custom schedule as comma-separated groups of 4 or 8 that total 32. Leave empty for the standard mapping.
• lora_strength (default 1.0) and head_strength (default 1.0) - keep both at 1.0 for the intended result. Lowering weakens the acceleration tuning; raising beyond 1 distorts output.
• on_off_grid - error stops sampling if a sampler asks for unsupported steps; clamp forces the nearest supported count (faster, lower quality).

Outputs are the patched model and the all-important sigmas.

Install

The node itself ships in the pack. The LoRA is a manual download (nothing auto-downloads):

# FL2VA (first/last-frame) or Ref2VA (reference-image), pick the one for your mode
curl -L -o models/loras/minimax_h3_fl2va_pdd_acc_8step_comfyui.safetensors \
  https://huggingface.co/aptech0081/MiniMax-H3-Acc-LoRAs-ComfyUI/resolve/main/minimax_h3_fl2va_pdd_acc_8step_comfyui.safetensors

Restart or refresh, then select it in pdd_lora. And remember the H3 weights themselves carry the geofenced community license - check your region before going far with this.

Where people get burned

• Wrong LoRA variant. FL2VA weights on a Ref2VA workflow (or vice versa) is the number one silent failure - the clip comes out wrong and it's not obvious why.
• Ignoring the sigmas. Feeding the patched model a hand-rolled 8-step schedule defeats the whole design. Use the node's sigmas with Euler.
• An extra step usually helps when you cache - the tooltip says it plainly: 8 steps with whole-block cache can drop to 7 if you need the VRAM.
• It's experimental, so on a novel H3 update the heads may lag the model. Check the README's PDD Acc section for current links before assuming the node is broken.

If you're doing H3 in bulk - or just want video without the wait - this is the single most useful patch in the pack.