(Down)Load HunyuanVideo TextEncoder

HunyuanVideo doesn't read your prompt with a normal CLIP or T5 encoder the way most diffusion models do - it reads it with a multimodal LLM (a LLaVA-LLaMA-3 8B variant), plus an optional CLIP model for a pooled embedding on the side. This node loads both and hands them off as an HYVIDTEXTENCODER for the encode nodes to use. It's the first thing you wire up after the model loader, and it's also the single biggest thing people underestimate about this pack: you're downloading and running an 8-billion-parameter language model just to read your prompt, on top of the video model itself.

Why an LLM instead of CLIP

This was one of the more distinctive design choices in the original HunyuanVideo release, and it's a large part of why the model is comparatively expensive to run and why the wrapper needs its own encoder-loading node rather than reusing ComfyUI's stock CLIPLoader. An LLM-based encoder tends to follow complex, compositional prompts better than plain CLIP text encoding does - the tradeoff is size and load time.

The inputs that matter

• llm_model - a dropdown between Kijai's repackaged llava-llama-3-8b-text-encoder-tokenizer and the original xtuner/llava-llama-3-8b-v1_1-transformers. The xtuner version carries the full vision tower, which you only need if you're using the wrapper's experimental IP2V (image-prompting) feature; for a normal text-to-video or the official image-to-video path, Kijai's version is the standard pick and both auto-download.
• clip_model - either disabled (if you're feeding CLIP conditioning some other way) or openai/clip-vit-large-patch14, which also auto-downloads.
• precision - bf16 by default, the sane default on any reasonably modern card.

Optional: hidden_state_skip_layer (default 2) pulls the hidden state from a few layers before the LLM's final output rather than the very last layer - a similar idea to CLIP skip, tuned by the model's training rather than something to fiddle with casually. quantization (disabled / bnb_nf4 / fp8_e4m3fn) quantizes the LLM itself, separate from quantizing the video model, and is worth turning on if VRAM is tight. load_device defaults to offload_device, keeping the LLM off the GPU until it's actually needed - sensible, since it only runs briefly during encoding.

Output: hyvid_text_encoder, which feeds the encode nodes (HyVideoI2VEncode and friends).

How to install it

Ships with the pack. ComfyUI Manager: search ComfyUI-HunyuanVideoWrapper, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-HunyuanVideoWrapper
pip install -r ComfyUI-HunyuanVideoWrapper/requirements.txt

then restart. This node handles its own downloads - first run will pull several gigabytes into ComfyUI/models/LLM/llava-llama-3-8b-text-encoder-tokenizer (and models/clip for the CLIP model) automatically. Budget time and disk for that; it's not a quick first load.

Common issues & troubleshooting

It errors partway through, or on load after a previous failed run. The auto-download is large and a flaky connection can leave a partial or corrupted set of files in the models/LLM folder. This is a documented real-world pain point - people running the LLM text encoder loader have hit errors right at load time. Delete the incomplete model folder and let it re-download, or grab the files manually from the HuggingFace repo if auto-download keeps failing.

Running out of VRAM before generation even starts. The LLM alone is a meaningful chunk of memory on top of the video model. Leave load_device on offload_device, and turn on quantization (bnb_nf4 or fp8_e4m3fn) if you're still tight - that's a separate lever from quantizing the diffusion model itself.

Prompt adherence feels weak or generic. Double-check you actually picked a clip_model if your workflow expects pooled CLIP conditioning alongside the LLM embeds, and that precision matches what the rest of your graph assumes. Mismatched precision between the encoder and the sampler is a common source of subtly-off results.