H3 Video Outpaint · 模型组合审计 (EXP)

Here is the shape of a bad afternoon. You open the outpaint workflow, drop in your favourite speed LoRA because obviously faster is better, queue a 22-window sequence, and come back two hours later to motion mush and a seam you can't explain. Nothing errored. That's the problem.

MiniMaxH3VideoOutpaintCompatibilityAuditT8 exists to make that impossible. It's a single-input, no-GPU node that inspects the actual MODEL object and tells you what's on it. The shipped 09_Model_Compatibility_Audit_EXP workflow is just this node on a canvas.

It reads the model, not the filename

This is the design decision that makes the node worth having. The description says it reads real MODEL content and patch/wrapper state and does not guess from filenames - and the report carries model_filename_used_as_evidence: false to prove it. That matters because the outpaint route has been validated against a specific execution identity: the Stock20 native path plus the pinned KJ low-VRAM attention and FFN patches. Two files with similar names, or the same file loaded through a different wrapper node, are different executions. Checking the filename would tell you nothing.

Inputs and outputs

One required input: model. Three outputs: model passed straight through (so you can drop the audit into a live graph as a pass-through rather than a dead-end), ready as a BOOLEAN, and compatibility_report as JSON.

It's marked as an output node, which mainly means it displays the report when you queue it. Watch ready. On a clean native model you get status: "verified_execution_identity" and quality_or_vram_acceptance_implied: false - note that second flag: passing the audit means the combination is supported, not that your VRAM will hold or that the output will look good.

The policy table it reports against

The report ships its own matrix, so you can read the verdict instead of guessing:

• native_stock_20_steps - supported.
• pinned_kj_low_vram_attention, pinned_kj_chunk_ffn - supported as memory optimisations, not speed claims. If you assumed the KJ attention patch was making you faster, that's your answer.
• regional_routing_plus_pinned_kj - supported contract, human quality review pending.
• dlss_nr_after_completed_compose - supported, as an independent post-process.
• turbo_lora, speed, sla_attention, vdn, fast_h3, prompt_relay - all unsupported, each with a stated reason: competing attention owner, different architecture and execution contract, no verified composition adapter.
• unknown_lora_or_wrapper - unsupported_fail_closed.

That last line is the ethos of this whole node. The default is to refuse, because a wrong answer here is invisible until you've paid for it. This is also why the outpaint workflows and the OpenVDN eight-step workflow stay on separate shelves even though the same pack ships both.

When it says not-ready

If the identity check can't establish a native stock model, you get ready: false, status: "unsupported_fail_closed", and a reason string. That's your cue to walk the graph backwards and find the node that patched the model - a LoRA loader, an attention-replacement node, a sampler-owner wrapper. Strip it out and re-run the audit until ready is true. Don't try to route around it; the pack's docs are explicit that these combinations are unverified rather than merely untested, and that they will produce conflicts or bad output rather than an error.

Install

Manager: search MiniMax H3 Audio T8, then restart ComfyUI fully. Manual:

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

Nothing to pip install - requirements.txt in this pack is deliberately empty so the install can't touch your Torch/CUDA stack. The audit needs no H3 weights, no VAE and no ffmpeg; it only inspects the MODEL object already in the graph. Which makes it the cheapest node in the pack and, on a long run, the best value per second.