MiniMax H3 Chunk FeedForward

MiniMax H3 is a monster of a video model, and on consumer cards the first thing that makes you hit OOM is usually not the attention - it's the feedforward. Every transformer block runs a big SwiGLU MLP over the whole packed token stream at once, and that intermediate buffer is enormous. This node chops that MLP into slices along the token dimension, so the model never materializes the entire activation at once. Peak VRAM goes down, and here's the part that matters: the output is identical. Token rows are processed independently and quantization happens per-token, so chunking is exact, not approximate.

It's marked experimental, which in kijai's packs means "trust the math but don't blame me if the world ends." The model output is a patched clone; your original is untouched.

Why you'd reach for it

The feedforward chunking is the least-risky of the H3 VRAM levers because it changes literally nothing about the result - unlike attention tweaks, there's no quantization or kernel swap in the default path, just a loop. And it plays nice with quantized models: when your H3 checkpoint is INT8, each chunk still goes through ComfyUI's fused INT8 kernel, and since activations are quantized per-token the chunked result matches the unchunked one anyway.

If you're on a 12–16 GB card trying to squeeze out a longer clip, this is usually the first H3 patch to try. It attacks the biggest cheap win.

How it works

The node patches every DiT block's mlp.forward with a chunked version. Instead of one giant GEMM over the full sequence, it splits the sequence into chunks pieces and runs fc1 → SwiGLU act → fc2 per slice, writing each result into its slot. Because each packed token is independent, the math is unchanged. Two safety rails: a seq_threshold below which it skips chunking entirely (no point paying overhead on tiny sequences), and a guard that checks the model actually looks like MiniMax H3 - if not, it logs a warning and hands the model back untouched rather than crashing.

The inputs that matter

• model - the H3 model to patch. Feed it the MODEL output from your loader, then wire the model output into the sampler.
• chunks - how many slices to split the feedforward into. Default 2. More chunks = lower peak VRAM, slightly more overhead. Bump it until the OOM stops, then leave it.
• seq_threshold - only chunk when the packed token count exceeds this (default 4096). Short sequences skip the patched path entirely.

Installing KJNodes

This ships inside KJNodes for ComfyUI - ComfyUI Manager (search "KJNodes") or:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-KJNodes
cd ComfyUI-KJNodes
pip install -r requirements.txt

Restart after. No extra model files; the pack's own dependencies are light. You do need a recent ComfyUI build with native MiniMax H3 support - these nodes patch comfy.ldm.minimax internals, and an old ComfyUI won't have them.

Gotchas

Because it fails soft, the common complaint is "it did nothing" - which usually means the model isn't actually H3 and the warning went unnoticed in the console. Check the log. Also remember it's a patch, not a loader: it has to sit between the model loader and the sampler, in the model path, or you're patching nothing. And chunks = 1 returns the model unpatched, which is a fine way to A/B whether chunking is actually helping you.