H3 Chunk FeedForward (X2 Stream)

What it actually does

This is a model patcher: MODEL in, MODEL out, sitting in the chain between your H3 loader and the guider. It doesn't touch the VAE and doesn't change your sampler settings - it rewrites how each H3 transformer block's feed-forward runs.

The problem it's aimed at is blunt arithmetic. H3's blocks compute fc1 → SwiGLU → fc2 over the whole token sequence at once, and that middle activation is wide - it's the peak of the block, and it scales with token count. Token count is resolution × frames, so what tips you into an OOM usually isn't the weights you loaded, it's how big a clip you asked for. H3 makes that worse than most, since it's a 33B omni-modal model generating picture and audio together (MiniMax H3 panel).

So the node does the obvious thing: split the token dimension into chunks, run the feed-forward per chunk into a preallocated output tensor. Peak intermediate memory becomes one chunk's worth instead of the whole sequence's.

Keep your expectations calibrated. On the author's RTX 4070, automatic chunking moved a 4-step 544×960 case from 60.319 s to 59.212 s median end-to-end (sampler time 38.700 → 37.509 s). Real, but small: this is a headroom node, not a speed unlock. If you're genuinely OOM-ing, try it before you sacrifice resolution.

The inputs that matter

Only three, and two of them you can leave alone.

• model - your H3 diffusion model after loading and after any other patches. The node validates that it's actually H3: it looks for blocks on the diffusion model and requires every block to have mlp.fc2. Feed it an SDXL or Flux checkpoint and you get a clean H3 Chunk FeedForward requires a MiniMax H3 diffusion model. instead of a mystery crash two nodes later.
• chunks - this is the one to understand. 0 is the new automatic mode: 2048-token chunks, and if the tail is shorter than 1024 tokens it gets merged into the previous chunk (2048 + 85 becomes 2133) so you don't pay for a nearly empty kernel. 1 disables the patch - and it disables it silently, returning your model untouched with no warning, which is a genuinely annoying way to spend twenty minutes wondering why nothing changed. 2 or higher is the older equal-count splitting.
• seq_threshold - default 4096, step 256. Sequences at or below this run dense, unpatched. Worth knowing: in the author's measurements the square 512×512 case fell below the sparse-attention min_tokens threshold and ran dense attention in both modes, so chunking made no difference there.

Output is a single MODEL, straight into your guider/sampler chain. Nothing to wire sideways.

Install

You get this node by installing the whole pack. From your ComfyUI directory:

cd ComfyUI/custom_nodes
git clone https://github.com/sepiablue-ai/ComfyUI-H3-X2-Stream.git

Then install its requirements with ComfyUI's Python - portable Windows installs use python_embeded\python.exe, venv installs use the venv:

.\python_embeded\python.exe -m pip install -r .\ComfyUI\custom_nodes\ComfyUI-H3-X2-Stream\requirements.txt

That's av>=17.0.0 and safetensors>=0.7.0. comfy-kitchen is deliberately not installed here - ComfyUI 0.37.0+ ships it - and PyTorch isn't replaced either. ComfyUI-Manager can do it via Install via Git URL; the pack isn't in the Manager registry, so searching its display name may come up empty. Restart ComfyUI afterwards and you'll find the node under the H3 X2 Stream category.

One caveat that isn't about this node: H3's community licence excludes the EU, UK, Republic of Korea and the US from its Applicable Territory. That's a weights-licensing question, but it applies to everything in this pack.

Troubleshooting and gotchas

Nothing changed and there's no error. Check chunks. 1 returns the model unpatched by design, and any workflow you downloaded that predates the automatic mode will have kept whatever number it shipped with. Set it to 0 to get 2048-token chunks; the pack's bundled examples use 0.

"Requires a MiniMax H3 diffusion model." The block-introspection check failed - usually because you patched something that isn't H3, or because the model is so unusual in structure that it has no mlp.fc2 on every block. It's a guard, not a bug.

Output isn't bit-identical. Only the square 512×512 test pair matched exactly on decoded RGB and audio; the other sizes didn't. Chunk boundaries change floating-point accumulation order, so keep both sides of a comparison on the same chunks setting.

It plays fine with KJNodes. This node is adapted from kijai's MiniMaxChunkFeedForward in ComfyUI-KJNodes under GPL-3.0, with a deliberately distinct node ID "so the two can coexist". You don't need KJNodes, and installing it won't create a conflict.