Configure H3 Static Virtual KV

Here's the situation this node exists for. MiniMax H3's reference-image path physically runs a five-frame network - two latent-time slices, that's it. But attention wants to behave like it's seeing a longer temporal context. The naive answer is to build all seven K/V slices that a 22-frame context implies, which costs memory and time you're not really using. Configure H3 Static Virtual KV is the pack's experimental answer: keep the physical five-frame run, and make attention see a virtual seven-slice, 22-frame K/V context without materializing it. The node is labelled experimental, so treat it accordingly - don't bury it in a workflow you can't rebuild.

It's a one-input, one-output patch: MODEL in, MODEL out, plus a single mode dropdown. That dropdown is the whole decision, and it's worth understanding because each rung trades exactness against speed:

• conservative (default) - materializes an exact seven-slice virtual K/V context. Boring, correct, and it works with any kernel version. If the other modes scare you, this one is the safe baseline.
• fast - needs kernel 0.39.0+. Keeps only the two physical BF16 K/V slices, gathers them through an exact logical source map (each of the seven logical slices is re-read from one of the two physical ones), applies all seven real temporal RoPE phases, and only ever materializes the W8A8 INT8 containers. The key claim: it does not average temporal phases. Nothing is approximated here, it's just not kept lying around.
• residual - needs kernel 0.41.0+. The two real slices stay dense and exact; the five added virtual slices are compressed into Sol 2x32 skipped-block residuals in the same online softmax. This is the genuinely sparse one, and it inherits whatever numeric backend you loaded (W8A8, Sage, or SDPA).

What "virtual" means physically: Query, attention output, residual, and FFN rows all stay at two slices. Only the target-video K/V presented to attention changes. So the model thinks it's in a 22-frame video while the compute stays at a five-frame clip - the kind of trick that reads like a hack until you watch the memory delta.

Install and the kernel trap

Same pack install as every Turing Utils node:

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

or Manager → search "Turing Utils", restart. But unlike the pure-logic nodes in this pack, fast and residual don't work out of the box. They require rebuilding the bundled CUDA kernel at the right version - 0.39.0 for fast, 0.41.0 for residual:

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

The deliberate design here is that an unsupported or stale kernel safely falls back to exact materialization - i.e. to conservative behavior. So the failure mode is "slower than you were hoping," not "wrong frames." That's genuinely nice engineering; most experimental nodes just crash.

Where it bites

• The mode is only valid for an H3 target with exactly five output frames. Feed it a different geometry and you're outside what the node is designed for.
• This replaces any upstream Sol/SLA/virtual-KV strategy, so don't stack it with the pack's other attention patch nodes - pick one.
• It's experimental and version-pinned. If you update the pack and don't rebuild the kernel, fast/residual silently downgrade to conservative. Check your kernel version before assuming you're getting the sparse path: pip show comfyui-turing-utils-kernel.

The honest take: if you're doing H3 reference-image stills or very short clips and your GPU is at its limit, fast is the sweet spot - sparse-ish memory cost with zero approximation. residual is the frontier, and you should expect to fiddle with kernel builds to keep it alive. For everyone else, conservative is "fine" and you can stop reading here.