HF Transformers load model

This is the pack's generic Transformers model loader, and in practice it has one job: loading text encoders. Modern image models are increasingly "LLM-encoded" - a Qwen or T5 model turns your prompt into vectors rather than a CLIP encoder - and those encoders are just Transformers models sitting in a repo. This node loads them so you can hand them to a diffusers pipeline as a swap-in text encoder.

The inputs mirror the VAE loader's, which is deliberate:

• model_class - default AutoModel (Transformers' "figure it out from the config" loader). Replace it with any class in the transformers namespace - the pack's GLM-Image example uses T5EncoderModel this way.
• pretrained_model_name_or_path - the repo id.
• subfolder - default text_encoder, because that's where diffusers-format repos keep it.
• device - default / auto / cpu (plus CUDA options when detected).
• dtype - including bitsandbytes_8bit / bitsandbytes_4bit, which is the genuinely useful part: a 4-bit quantized text encoder is how you fit an LLM-sized encoder next to a diffusion model on a consumer card.
• kwargs - the JSON escape hatch, same as everywhere in this pack.

Output is a single HFT_MODEL, which plugs into HFDLoadPipeline's optional text_encoder input.

When you'd use it

Three honest cases. One: you want a different text encoder than the pipeline's default - swap in a better encoder for the same architecture, or match an exploded workflow where every component loads separately. Two: you want the encoder on a different device or dtype than the rest of the pipeline, so it doesn't share the diffusion model's VRAM budget. Three: you're following the pack's exploded examples, which load the encoder as its own node even though the pipeline would load it internally.

Outside that, skip it. HFDLoadPipeline loads its own text encoder automatically, and adding this node means you're now responsible for matching the encoder to the model's expectations. Get the class or the subfolder wrong and the pipeline will happily accept your tensor-shaped surprise and produce garbage.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Yahweasel/ComfyUI-HF-Diffusers

or search ComfyUI-HF-Diffusers in ComfyUI Manager, then restart. The pack's requirements.txt pins diffusers~=0.36.0; the Transformers side depends on the transformers ComfyUI already ships, and the author notes some brand-new models want the git version of both.

Gotchas

• Repo + subfolder must both be right. The default text_encoder subfolder is a convention, not a law. Some repos keep the encoder elsewhere; check the repo layout before blaming the node.
• Architecture lock-in applies to encoders too. A T5 encoder is not interchangeable with a Qwen encoder - same rule as LoRAs, just for the conditioning path. Newer LLM-based encoders also broke compatibility with CLIP-era embeddings (SD 2.0's OpenCLIP swap already proved that rule once), so don't expect your old embeddings to transfer.
• Quantized encoder + unquantized pipeline can behave oddly at the seams. It works, but if you see subtle quality loss, try the encoder at full precision before debugging the rest of your graph.