H3 Keyframe Reference

If you're doing image-to-video with MiniMax H3, the first/last-frame conditioning is where the graph starts to sprawl - and this node is the piece that stops you from re-encoding the same picture five times. H3 Keyframe Reference (TuringUtilsH3KeyframeReference) lives in the wjie98/comfyui-svdint4 pack, which its author calls "Turing Utils." Ignore the repo name, by the way: it says SVD INT4, but there's no SVD and nothing INT4-only here. The pack is really a compatibility and speed layer for running big video transformers (H3 especially) on Turing-era cards like the 2080 Ti, and this node is its conditioning helper for H3 keyframes.

The core trick is that the node doesn't decide what an image is for. On the official H3 semantic/build nodes you have distinct first-frame and last-frame sockets, so a normal VAE-encode forces you to pick a role before you know you need one. H3 Keyframe Reference defers that: every image_N input has a matching keyframe_N output, and each output is role-free - it can plug into either the first- or last-frame socket, and you can even use the same encoded keyframe for both roles across different sampling branches without re-encoding. Encode once, wire twice. That's the whole appeal.

How it works

It takes a vae (required) and an optional latent, then an autogrowing images input where you add image_0, image_1, and so on in the UI. For each connected image it aligns the pixels, then runs them through the H3 VAE into the visual latent the model expects (H3's VAE produces 24-channel [1,24,T,H,W] tensors). The output type is the custom TURING_UTILS_H3_KEYFRAME_REFERENCE, which is what the pack's H3 Semantic Reference and H3 Build Conditioning nodes consume - those are the ones that actually build H3's conditioning from your references.

The inputs you'll actually touch:

• vae (required) - the H3 VAE. This is the non-negotiable one.
• latent (optional) - connect your target H3 video latent. When it's connected, each image is cover-resized and cropped to the latent's decoded pixel canvas, so the keyframe lands exactly on the canvas you're generating. Without it, images are just center-cropped to H3's pixel alignment.
• images (optional, autogrowing) - drop as many as you like; the schema allows up to 32 keyframes.

Outputs are keyframe_0 through keyframe_31. Empty ones stay empty - the node pads unfed outputs with nothing, so you can leave the extra sockets dangling.

Install

The pack installs like any custom node:

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

Then the part that trips people: the requirements.txt only ships safetensors. The actual CUDA work lives in a separately-built kernel package, and you need it:

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

That kernel build is the real install. It needs an NVIDIA GPU (Turing sm75 or newer), Python 3.10+, and PyTorch built with CUDA. The build auto-detects the architectures on your visible GPUs - a 2080 Ti plus a 3070 builds 7.5;8.6 in one shot. If you're on ComfyUI Manager, search "comfyui-svdint4" to grab the plugin, but the kernel step above is still on you.

Common issues

The README's own install block tells you to git clone https://github.com/wjie98/comfyui-turing-utils.git - that's a stale name. The live repo is comfyui-svdint4; clone that one.

Images looking wrong are usually the latent question: with a latent connected the node cover-crops to that canvas, without one it only center-crops to the 32px alignment. Both are deliberate, but they produce visibly different results, so wire a latent if you want your keyframe to match the output resolution exactly.

And one reality check that's worth having before you start: H3's weights ship under the MiniMax H3 Community License, which excludes the US, EU, UK, and South Korea from running them locally at all. No node fixes that, and no node should have to.