MiniMax H3 MLP Activation Chunk / MLP激活分块 (Advanced)

Most "save VRAM" nodes arrive with a hype poster. This one arrives with the author admitting, in the node description itself, that on current kernels it may do nothing at all. That candor is the whole T8 pack in miniature, and honestly it's refreshing.

MiniMaxH3ActivationChunkT8Advanced tries to chunk the MLP activations inside the H3 DiT so fewer tokens get processed as one big matrix. H3 is a 33B joint audio-video transformer, and the sequence length is what eats VRAM on 16GB cards. Chunking the MLP forward into row-blocks of chunk_rows (default 256) is a classic trick from the image-model days. The catch, which the author states flat out: current TensorWise INT8 kernels already fuse SwiGLU, so they may show zero memory benefit. You are explicitly buying an experiment, not a fix.

What it actually does

It's a clone-local patch. In apply_exp mode it modifies a local copy of the model's MLP path so the SwiGLU activation is computed in chunks instead of all at once. Attention is untouched - this is strictly the MLP, and only for the block range block_start to block_end (0–49 covers the whole DiT). preserve_short_path keeps short inputs on the unpatched path so a 22-frame clip doesn't pay the chunking overhead for nothing.

The two knobs you actually touch:

• mode - report_only is the default and makes no change to the MODEL. It validates your expected canvas and prints what a patch would do. Flip to apply_exp only after reading the report, and know that it refuses to run if another node already owns the dit/double_block - it won't silently stomp a Block Cache or Sage wrapper the way some patchers do.
• chunk_rows - 256 is a sane starting point. Lower = more chunks = more overhead per row. There's no point tuning it until a report shows you're actually VRAM-bound on MLP, which it usually isn't.

The expected_width / expected_height / expected_length / expected_single_image_references inputs aren't parameters that change math - they're a contract the node checks its math against. Set them to what you actually run, or the report will mislead you.

Wiring and outputs

model in, model out, plus a report_json string you can dump to a text node. It sits between your model loader and the sampler, exactly where a LoRA or Block Cache would. It's in the T8/MiniMax H3/Models/Experimental menu alongside the other model-patching experiments.

Install

Same as every node in this pack: ComfyUI Manager → search MiniMax H3 Audio T8, or

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

then restart ComfyUI. The pack has no mandatory pip dependencies beyond what ComfyUI ships, and it won't download H3 weights for you - you need the H3 DiT, the Qwen3-VL CLIP, and both VAEs in their models/ folders already.

The honest bottom line

Run it in report_only once to see the audit. If you're on a current TensorWise INT8 stack, the report will likely tell you the fuse already ate the benefit, and the right move is to leave the node out and spend your VRAM hunting elsewhere - the pack's own MiniMaxH3PreflightT8 is a better first stop. If you're on stock fp16 and every megabyte counts, apply_exp is worth an A/B on a 124-frame clip. Just don't expect a miracle; this node's job is to be measured, not to be believed.