Configure H3 Image Sol Attention

MiniMax H3 is a 33B omni-modal video model, and the moment you point it at an image reference the attention gets genuinely silly - tens of thousands of tokens, every Query attending to every Key. That's the whole reason this node exists. It's a MODEL-in, MODEL-out patch that applies Sol sparse attention to the H3 image path, and it's the difference between an image-to-video run that takes over a room and one that takes a lunch break. If you're generating H3 clips from a reference image on a consumer GPU, this is one of the first knobs you should learn.

Sol, in one sentence: attention that skips most of the Key/Value blocks and substitutes a single 64-token "residual" centroid per skipped block, corrected in the same online softmax. The trick is which blocks get skipped, and that's where this node earns the H3-specific name. Your reference image and keyframes are usually the whole point of the shot, so by default they stay fully dense - sparse_reference_image is false, and sparse_reference_audio is false too (dialogue conditioning stays exact). Long reference video is the one thing allowed to route (sparse_reference_video defaults to true), because a long reference clip is exactly the case where dense attention is pure waste.

The input that matters most is temporal_layout:

• dense_anchor_grid (default) keeps every 17-frame H3 chunk anchor plus the first continuation exact - the model's native VAE anchor grid stays protected.
• dense_window keeps only the initial 1+4 latent-time window exact, which is more aggressive and cheaper.

A five-frame target stays fully dense either way; H3's native 5k+2 latent-time layout only kicks in for longer inputs. The dense_prefix_steps (1) and dense_prefix_layers (2) controls are Sol's standard "first step and first two layers stay exact" policy, and you can extend the protection with dense_suffix_steps/dense_suffix_layers if you ever see quality drop on the tail of sampling. debug_route_density logs the min/mean/max route density once per denoising step - handy for confirming routing is actually happening, but it adds a sync per step, so leave it off in production.

How to install it

This node lives in the ComfyUI Turing Utils pack, installed under the repo name comfyui-svdint4:

cd ComfyUI/custom_nodes
git clone https://github.com/wjie98/comfyui-svdint4

or grab it via ComfyUI Manager by searching "Turing Utils", then restart ComfyUI. Here's the part people miss: the Python side installs cleanly (its requirements.txt is just safetensors), but Sol attention runs on a separately compiled CUDA kernel package. The node code itself is Python-only, but without the kernel built for your GPU it can't actually execute the Sol backend:

cd ComfyUI/custom_nodes/comfyui-svdint4
python -m pip install -v --no-build-isolation -e ./kernel

That build targets every CUDA architecture it can see on the machine (a 2080 Ti + 3070 box gets 7.5;8.6 in one shot) and needs Python 3.10+, PyTorch with CUDA, and a Turing/Ampere/Ada GPU or newer.

What to wire and where it breaks

Wire the loader's MODEL in, get a patched MODEL out, and feed that to your KSampler. That's the whole interface.

The most common failure is running it against anything that isn't MiniMax H3 - the node raises a clear requires MiniMax H3 error, so that one is at least honest. The subtler one is forgetting the kernel build above: you'll get an error or a silently slow fallback because the native W8A8/Sol path needs a cubin for your card. And before you sink a weekend into it, check the legal box: the H3 weights ship under a community license that geofences out the US, EU, UK and South Korea. If you're in one of those, the hosted Hailuo API is your only licensed path, and no node fixes that.

One honest take: this is a "when it fits, it's great" node, not a "must have" one. If your H3 clips are short and your GPU is roomy, dense attention is fine and this is another moving part. If your references are long video and your VRAM is tight, it's the one you'll reach for.