Nucleus-Image Text Encoder Loader
Nucleus-Image's text encoder loader is a promise, not a load — on purpose
- NUCLEUS_TE
Here's the first thing to unlearn: Nucleus-Image does not use a CLIP encoder, so the CLIPLoader you know from SDXL is useless here. This node loads the model's actual text encoder, a Qwen3-VL LLM. And it loads it in the laziest way possible - which is exactly the right call.
Nucleus-Image Text Encoder Loader just records which file you picked and where it lives. It doesn't touch the GPU, doesn't allocate 8GB, doesn't even read the weights. The heavy lifting happens later, inside the Text Encode node, which loads the encoder onto the GPU, encodes your prompt, and releases it again. So your workflow will happily sit with this node "loaded" while the encoder file stays parked on disk.
Why an LLM, and why it matters for your prompts
The KB's text-encoder panel nails the wider shift: from 2026 on, the mainstream encoder isn't a frozen CLIP but a general-purpose LLM, and here it's Qwen3-VL. That changes how you write prompts. This isn't a tag bag - the encoder reads an instruction. The pack wraps your text in a system prompt that tells the model to follow the prompt literally, watch spatial layout (left stays left, right stays right), and match object counts and colors. Write full sentences and you'll get much better adherence than comma-separated keywords. Also, and this is the part that trips people up: no embeddings, LoRAs or prompt-weighting tricks trained on CLIP will carry over. The token space and the vector space are both different.
The inputs
- model_name - dropdown of files in
ComfyUI/models/text_encoders/. You wantnucleus_image_text_encoder_fp8.safetensors(≈8.2 GB); the bf16 variant (≈16.5 GB) is optional and heavier. - precision -
bf16(default),fp16, orfp32. bf16 is what the author tested.
That's it. There's deliberately no load_device option - the node doesn't load anything to a device in the first place. The README calls this out so you don't go hunting for a setting that was never meant to exist.
The output is a NUCLEUS_TE object that feeds Nucleus-Image Text Encode or Text Encode (Dual).
Installing it
Install steps are shared across the whole pack - ComfyUI Manager (search "Nucleus-Image") or:
cd ComfyUI/custom_nodes
git clone https://github.com/a180265/Nucleus-Image-comfyui-beta
Then download nucleus_image_text_encoder_fp8.safetensors from the Nucleus-Image Hugging Face repo into models/text_encoders/. Nice touch: the Qwen3-VL tokenizer and chat template ship inside the pack (a processor/ folder), so unlike some models you don't have to hunt down a separate tokenizer download. The heavy dependencies are the pack's usual ones - transformers 4.57+, torch 2.11+, diffusers 0.38+ - which the README lists and you install yourself.
Common issues
- "Why is this node taking no time / not loading?" Because it isn't supposed to. Encoding happens in Text Encode. If that node errors, the file in
text_encoders/is the thing to check. - Empty dropdown - the file isn't in the right folder, or ComfyUI was started before you placed it. Drop it in
models/text_encoders/and restart. - Don't reuse an SDXL/Qwen-Image CLIP - wrong architecture, wrong file, and the pack's loader won't treat it as a Qwen3-VL encoder.
The one real gotcha: the encoder is big and it reloads per encode by design. That's why the Dual variant exists - if you're doing positive plus negative, use it and load the 8.2GB once instead of twice. See the Text Encode (Dual) article; it's the README's recommended way to run this model.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| model_name | COMBO | Models from ComfyUI/models/text_encoders | |
| precision | COMBO | bf16 | 3 options: bf16, fp16, fp32 |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| NUCLEUS_TE | NUCLEUS_TE | — |