FL MiniMax H3 VDN

MiniMax H3 is a 33B omni-modal model, and the expensive part of sampling it is the attention over long video token sequences. FL MiniMax H3 VDN is the node that trades that full softmax attention for a trained linear-attention branch - the "Video Delta Attention" thing in the name - so you can render H3 faster without reaching for the aggressive turbo variant the author clearly doesn't trust.

Let's be precise about what this node is, because the naming is doing a lot of work. VDN-H3 is an attention-level swap, not a new diffusion model. The node takes your loaded H3 model, verifies it's a native ComfyUI MiniMax H3 diffusion model (it checks the block layout and the attention projection before it will touch anything), clones it, and patches every transformer block's attention with the VDN linear branch plus the required Stage-B adapter. The checkpoint it uses is the official Stage-DMD-250 release from OpenVDN/vdn-minimax-h3 - the "DMD" in the name tells you it came out of a distribution-matching-distillation pipeline, the family of tricks that lets a model reach its result in far fewer steps than the base. The author's README frames it as "acceleration" and goes out of its way to say the optional turbo adapter is neither downloaded nor applied - turbo being the faster-but-lossier end of that trade. This node is the middle path: faster attention and a distilled branch, without the quality haircut the turbo route takes. (The distillation tradeoff is real and well-trodden - every distilled variant loses something - which is exactly why this one exists as the less-aggressive option.)

What you actually need to know about running it:

• Inputs are model (the H3 diffusion model from your loader) and strength - default 1.0, range 0–2, and it controls the weight of that required Stage-B adapter. Start at 1.0 and only move it when you're A/B-testing against a baseline.
• Output is a model you wire into your sampler in place of the original. It's a clone, so your base model node stays untouched and you can compare patched vs. unpatched without reloading.
• Weights stream through ComfyUI's model-management path, so you don't end up with a second permanent GPU copy of a 33B model. That detail matters on consumer cards.

The download is the gotcha nobody warns you about. First execution downloads about 4.3 GiB into ComfyUI/models/vdn/stage-dmd-step-250/ - branch weights, model spec, metadata, and the default adapter - from a pinned revision of the OpenVDN repo, and it only happens when the node actually runs. First render will look like it's hung while that pulls down. It's one-time, and after that the files are local, but budget for it. It's also why the pack lists huggingface_hub as its only Python dependency - that's the download machinery. VDN weights do not come from MiniMax's own model card; they're a separate community release, which sidesteps at least one licensing headache on top of H3's already-geofenced base weights.

Installing the pack itself is the standard two-step: ComfyUI Manager, search FL MiniMax H3, install - or:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI-FL-MiniMaxH3.git

then restart. It needs a current ComfyUI with H3 support and your own H3 model files; this is filliptm's pack (the Fill Nodes author - these H3 nodes migrated out of Fill Nodes at v1.2.0, so don't run it against an old Fill Nodes that still registers the same node IDs).

Where people get burned, honestly: applying it to a model that isn't a native ComfyUI H3 - it errors out with a clear message rather than silently doing nothing, which is the good kind of failure. And patching a model that already has a VDN patch - it refuses, again loudly. The one real disappointment is that you won't get a headline speed number from any of this: VDN's benefit shows up most on long renders where attention cost dominates, so measure it on your workflow rather than trusting somebody's benchmark. Expect it to help most on the long multi-shot renders this pack's beat-sampler workflows are built around.