MiniMax H3 Forward Sync Optimization (T8 Advanced)

H3 is a 33B model and every sampling step is expensive. If you're on a transitional ComfyUI core - new enough to run H3, old enough to still carry the early H3 integration quirks - a chunk of that per-step time is being wasted on device-to-host synchronization: the model pausing to copy results back to the CPU between steps. This node is a performance shim that cuts those repeated syncs without changing the sampling schedule at all.

"Without changing the schedule" is the important part. This isn't an acceleration trick that trades quality for speed - it's removing overhead that buys you nothing. The math that runs is identical; you're just not stopping to report home every step. On newer ComfyUI builds that already implement the official non-syncing behavior, the node detects that and passes your model straight through.

How to use it

• model in → model out, plus report_json describing whether it optimized the forward path or passed through natively.

Wire the output model into your sampler as usual. There are no settings - the whole node is a wrapper. If your H3 sampling feels slower than the hardware should allow and you're on an older core, slot this in between the model loader and your conditioning/sampler chain and A/B it. Because it's a pure pass-through on current cores, it's also a completely safe thing to leave in a workflow - worst case it's a no-op.

Installing it

Part of the T8mars/comfyui-minimax-h3-audio-T8 pack. Search "MiniMax H3 Audio T8" in ComfyUI Manager, install, restart, or:

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

And the pack-wide rule you cannot skip: update ComfyUI itself first. This family targets comfy_api.latest, comfy.weight_adapter, comfy.patcher_extension and comfy.ldm.minimax; an old core fails the whole pack's import, which surfaces as every T8 node going red at once. requirements.txt is intentionally empty - the runtime deps come from ComfyUI's environment, so leave it alone.

Where people get burned

Two things. First, this is explicitly one of the nodes that takes ownership of the MODEL forward path - the README's rule about not stacking multiple such nodes applies. Adding this alongside another forward-patching node can give you slower or stranger results than either alone, because they fight over the same hook. Second, don't expect a dramatic number from this on hardware that's already bottlenecked on VRAM or raw compute. It only removes synchronization stalls; it doesn't make a 24GB card run a 42GB model footprint. The honest framing: it's a small, free, mathematically-invisible win on older cores, and a no-op on current ones.