H3 Semantic Reference

Every H3 generation has two distinct brains. One is the Qwen3-VL-32B multimodal encoder that turns your prompt plus your references into semantics - the expensive one, memory-hungry and slow. The other is the DiT that actually denoises your video. H3 Semantic Reference (TuringUtilsH3SemanticReference) is the node that runs the Qwen pass - once, exactly, and then lets you reuse the result instead of paying for it again every time you tweak a resolution.

That decoupling is the whole reason this node exists, and it's genuinely clever. Because the semantic pass and the DiT-side VAE encode are separated, you can do things like: encode your references at low resolution for Qwen's benefit, then connect separately encoded high-resolution keyframes to the DiT - without re-running Qwen. The semantic understanding stays the same; only the structure changes. If you've ever sat through a 32B text-encoder pass, you know why "run it once" is worth building a node around.

Inputs that matter

• clip (CLIP, required) - the H3 Qwen3-VL encoder. Not a generic CLIP; it must be the H3-compatible one. The node checks the token stream and will tell you off with "clip is not a compatible MiniMax H3 Qwen3-VL encoder" if you plug in the wrong thing.
• prompt (STRING, multiline, dynamic prompts enabled) - your text.
• keyframes_reference, image_reference, video_reference, audio_reference (all optional) - the outputs of the four reference nodes. The order you connect them is the order Qwen "sees" them.

Output: semantic_reference (TURING_UTILS_H3_SEMANTIC_REFERENCE) → H3 Build Conditioning.

How it actually works

It assembles a "presentation" of everything Qwen should look at - keyframe anchors first, then images, then videos (each tagged with whether it carries audio), then standalone audio - and tokenizes the prompt together with that presentation into the H3 qwen3vl_32b token stream. Keyframe tokens and reference tokens are combined into one ordered row, then encoded. Along the way it records a manifest of the reference structure: how many images, which videos had audio, which anchors existed. That manifest is what makes reuse safe - see the gotcha below.

The rule that keeps you out of trouble

The manifest is a contract. When you later feed the semantic_reference into H3 Build Conditioning, the node compares the manifest against whatever references you connect there, and it errors if they differ: "Semantic and DiT H3 reference structures differ." So the practical rule is: connect the same references (same nodes, same counts) to both H3 Semantic Reference and H3 Build Conditioning. You can re-encode at different resolutions, but you can't change the shape of the reference set without re-running Qwen. Change a reference count and you must re-run this node.

Installing it

Part of the ComfyUI Turing Utils pack (repo wjie98/comfyui-svdint4; the README still calls itself comfyui-turing-utils). ComfyUI Manager - search "svdint4" or "Turing Utils" - or:

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

Restart ComfyUI. requirements.txt ships only safetensors. The CUDA kernel is a separate explicit step (python -m pip install -v --no-build-isolation -e ./kernel) - needed to run H3 itself on a Turing card, but this node is tokenization plus a CLIP encode and runs before you build anything.

Where it sits in the graph

Reference nodes → H3 Semantic Reference → semantic_reference → H3 Build Conditioning, which merges it with the target latent and hands the sampler real CONDITIONING. If you're iterating on resolution, that's the node to keep warm: re-encode the DiT side, leave this one untouched, and save yourself a 32B encode every run.