Load Switti Dual CLIP
Two encoders and a swap-proof check
- SWITTI_TEXT
Like SDXL, Switti conditions on two text encoders at once. Unlike SDXL, the pair is specific to it: OpenAI's CLIP ViT-L/14 (768-dim) plus LAION's CLIP ViT-bigG/14 (1280-dim), whose outputs get concatenated and pooled into the prompt conditioning. This node loads both and hands you a single SWITTI_TEXT output. It looks like a two-line loader, but the size check inside is the whole point.
Here's the mechanism. Both encoders are read from ComfyUI/models/text_encoders, then the node runs a probe encode through each and inspects the dimensions:
- Encoder 1 must be 768-dim (CLIP-L/14).
- Encoder 2 must be 1280-dim, pooled 1280 (CLIP-bigG/14).
If either check fails you get a "Switti CLIP size mismatch" error before anything wastes your GPU time. That check is a genuine feature: the README's blunt warning - "If CLIP inputs are swapped, you will get a size mismatch error" - is backed up in code. Load SDXL's OpenCLIP-ViT-bigG (plus whatever) in the wrong slot, or reverse the two encoders, and the node catches it instead of silently generating garbage. In a niche port like this, that kind of defensive engineering is a pleasant surprise.
One thing to understand about clip_1_name and clip_2_name so you're not confused by the dropdown: the node looks at the file or folder you select, and if it's a folder, it loads the Transformers model straight from that path. If it's a .safetensors, it matches the filename to the known encoders and actually pulls the weights from HuggingFace (openai/clip-vit-large-patch14 and laion/CLIP-ViT-bigG-14-laion2B-39B-b160k). So the filenames matter - name matters more than the file contents, honestly. The reference workflow ships with clip-vit-large-patch14.safetensors and CLIP-ViT-bigG-14-laion2B-39B-b160k.safetensors, which is exactly the naming the resolver expects.
Install the pack the usual way - ComfyUI Manager → search "ComfyUI-Switti", or:
cd ComfyUI/custom_nodes
git clone https://github.com/RyukoMatoiFan/ComfyUI-Switti
then restart. Dependencies are pinned in the vendored switti/requirements.txt (transformers==4.45.2, diffusers==0.31.0, huggingface_hub==0.26.2, torchvision==0.19.1); if imports fail, that pin list is where to look.
For models, you have two reasonable routes. Drop real folders of the two CLIP models into text_encoders and pick them (no download at generation time), or drop the two .safetensors files with the exact names above and let the node fetch from HF. Both work; the folder route is nicer if you're offline, and the resolver also warns you with "Text encoders must be full Transformers model folders or supported filenames" if you hand it something it can't place.
Honest expectations: this is a small, single-commit community port of a research model, so there's no ecosystem around it - no alternate CLIPs, no fine-tunes, no LoRA support. You get the two encoders Switti was trained with, and the node makes sure you loaded exactly those two. That's the whole job, and it does it well.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| clip_1_name | COMBO | 0 options: | |
| clip_2_name | COMBO | 0 options: |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| SWITTI_TEXT | SWITTI_TEXT | — |