HY OmniWeaving Text Encoder Loader
The dual text encoder loader OmniWeaving actually needs
- CLIP
HunyuanVideo 1.5 is a dual-encoder model, and OmniWeaving makes that weirder: its fine-tune replaces one of the encoders with a Qwen2.5-VL checkpoint that the stock ComfyUI text-encoder loader doesn't know how to wire up. HY OmniWeaving Text Encoder Loader is the node that loads the pair correctly - the OmniWeaving-tuned Qwen2.5-VL 7B for the language side, plus a ByT5-small checkpoint for the glyph/character branch - and hands you a single CLIP object that behaves like a normal HunyuanVideo 1.5 clip downstream.
Why you can't just reach for the stock loader: OmniWeaving's whole trick is that its Qwen is the "reasoning" brain. It reads your prompt, expands it, and (for image/video tasks) sees reference frames through vision tokens. That finetuned checkpoint has its own state-dict quirks, and the pack applies deepstack/setclip runtime patches to the loaded clip instance - injection hooks that stock loaders never attach. So when the community port landed, "you only need the diffusion model and text encoder, the rest is the same as HunyuanVideo 1.5" turned out to be mostly true except for this exact part.
How it works
The loader does three things in one shot:
- Loads both checkpoints from
models/text_encoders- the filenames matter, because the validated workflow assumesqwen_2.5_vl_7b_finetuned_model.safetensorsandbyt5_small_glyphxl_fp16.safetensors. - Normalizes the Qwen state dict and feeds both to ComfyUI's
load_text_encoder_state_dictswith theHUNYUAN_VIDEO_15clip type, so the pair comes out as one fused CLIP model. - Applies the OmniWeaving text-encoder patches - deepstack
mm_inhandling and setclip text-mask reconstruction - per loaded instance.
There's a device dropdown with default and cpu; it's advanced and mostly there for debugging / pathological VRAM setups.
The one input that matters
- qwen_text_encoder and byt5_text_encoder are combo dropdowns populated from your
text_encodersfolder. The pack tries to auto-select the OmniWeaving Qwen and abyt5file, but if your local filenames differ, pick them manually - both must be present or the loader fails.
Output is a single CLIP, which feeds straight into HY OmniWeaving Text Encode.
Installing it
It's part of the hy_omniweaving_comfyui_unofficial pack. Either use ComfyUI Manager (search "hy_omniweaving") or:
cd ComfyUI/custom_nodes
git clone https://github.com/Shiba-2-shiba/hy_omniweaving_comfyui_unofficial
Restart after cloning. No pip dependencies, but you do need a current ComfyUI - the pack registers through the newer comfy_entrypoint API. The two text-encoder downloads (~7B Qwen plus the small ByT5) are the big ones on top of the diffusion model; links live in the README under "Required inference files".
Common issues
- "No such file or directory" for one of the encoders - you only downloaded one of the pair, or renamed it. Both files must sit in
models/text_encodersunder the expected names. - Wrong Qwen file - a plain Qwen2.5-VL without the OmniWeaving fine-tune loads but gives you muddy, drifty prompts. The README's
qwen_2.5_vl_7b_finetuned_model.safetensorsfrom the tencent HF repo is the one. - Clip errors that mention deepstack or setclip - you're on a very old ComfyUI. Update; the loader's runtime patches expect a recent core.
Worth knowing before you start: the community consensus is that OmniWeaving rewards CFG and a serious step count (30–50), and it's slow even on a beefy card. Getting this loader right just means your text path isn't the thing that's broken.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| qwen_text_encoder | COMBO | 0 options: | |
| byt5_text_encoder | COMBO | 0 options: | |
| device | COMBO | default | 2 options: default, cpu |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CLIP | CLIP | — |