PixArt T5 Text Encode [Reference]

The "[Reference]" tag in this node's display name isn't decoration - it's the author being upfront about what you're getting. This is a straight port of PixArt's own reference implementation for turning text into T5 embeddings, which means it behaves exactly like the original paper's code. The tradeoff, stated plainly in the pack's own README: "PixArt T5 Text Encode is from the reference implementation, therefore it doesn't support weights. T5 Text Encode support weights, but I can't attest to the correctness of the implementation." That's about as honest as a node description gets - pick faithfulness-to-the-source or prompt-weighting syntax, not both, at least according to the person who wrote both nodes.

So: two nodes doing the same job with a real tradeoff between them, and this is the "matches what PixArt's authors actually shipped" option. If you're chasing the exact behavior described in benchmarks and comparisons, or troubleshooting something and want to rule out this pack's own reimplementation as the variable, this is the one to reach for. If you want (word:1.4)-style weight syntax on your prompts, use the sibling T5 Text Encode node instead, with the caveat that its correctness there isn't something even the author will vouch for.

Inputs. Two, both required: text, a multiline string field for your prompt, and T5, the T5 encoder object - wired from this pack's T5 loader node (under ExtraModels/T5 in the node menu), not from CLIP. PixArt uses T5 in place of CLIP entirely, which is part of why it could get away with such small parameter counts while still following instructions well.

Output. CONDITIONING - feed it straight into PixArtResolutionCond next, then into your KSampler's positive or negative input like any other conditioning.

Loading the T5 encoder itself. This is the part that actually costs you resources. Unquantized on CPU, T5 eats roughly 22GB of system RAM. In 4-bit (bnb4bit) mode it drops to around 6GB VRAM, which is what makes it workable on a 12GB card, but bitsandbytes can't temporarily hand the weights back to system RAM the way normal VRAM management does - so once it's loaded 4-bit, it stays resident in VRAM until you switch workflows. Pascal-generation cards (1080ti, P40) reportedly struggle with 4-bit specifically; the README's advice there is to just select cpu if you hit issues. If you've got a second GPU, pointing T5 at cuda:1 frees your primary card entirely.

Installing the pack. ComfyUI Manager: search "Extra Models for ComfyUI." Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/city96/ComfyUI_ExtraModels

then, critically, pip install -r requirements.txt - the README specifically flags that you may need to upgrade transformers and install spiece for the T5 tokenizer to work at all, and Windows users may need a newer bitsandbytes build for 4-bit mode (python -m pip install bitsandbytes).

One real limitation worth knowing up front. If you're pairing this with PixArt's dedicated DPM sampler rather than a standard KSampler, that sampler requires your negative prompt to be shorter than your positive one and only supports a batch size of 1 - neither restriction is this node's fault, but they show up together often enough to be worth flagging here.