Gemma Text Encode

This is the second half of Sana's text pipeline, and it's about as simple a node as this pack ships: take a loaded Gemma model, take your prompt, produce conditioning. There's no separate reference-vs-weighted-implementation split here the way there is on the T5 side of this pack - just one straightforward encode node, because Sana's text conditioning is that much less fiddly to expose.

If you're coming from SD or Flux, the mental model transfers cleanly: this plays the same role CLIPTextEncode plays elsewhere, just pointed at a small language model instead of a CLIP or T5 encoder. Gemma2 2B reading your prompt and producing an embedding the diffusion model cross-attends to - same job, different encoder.

Inputs. Two, both required. text is a standard multiline prompt field - type what you want generated, same as any other text-encode node. GEMMA is the loaded model object, which has exactly one source in this pack: Gemma Loader, wired directly in.

Output. CONDITIONING, which goes into your KSampler's positive or negative slot the normal way. Sana doesn't have a resolution-conditioning node the way PixArt does (there's no SanaResolutionCond in this pack), so this conditioning goes straight to the sampler without an intermediate step.

The chain, start to finish. Gemma Loader → Gemma Text Encode → KSampler, alongside Sana Checkpoint Loader's model output and an empty latent from either Empty Sana Latent Image or Empty DCAE Latent Image, decoded at the end through ExtraVAELoader's VAE (a special one - Sana's compressed latent space doesn't work with a standard SD VAE).

Installing the pack. Search "Extra Models for ComfyUI" in ComfyUI Manager, or:

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

then pip install -r requirements.txt in your venv and restart.

Worth knowing before you get here. This node itself is about as low-risk as nodes in this pack get - there's nothing to misconfigure beyond wiring it correctly. The actual friction in a Sana workflow lives upstream, in getting the checkpoint, Gemma model, and matching VAE all correctly paired, and the pack's own README puts a caution notice on the whole Sana section recommending the Sana team's own fork if you're setting this up from scratch and hit trouble - a full rewrite for better integration was reportedly in progress but not ready as of the version this article covers. If your text encode step runs cleanly but your final image is garbled, the problem is almost never this node; it's a VAE mismatch further down the chain.

One small thing to double check. Make sure you're actually loading the Gemma model, not accidentally treating this as interchangeable with T5 or CLIP encode nodes elsewhere in the pack - the GEMMA type only connects to Gemma Loader on one end and this node on the other, so a type mismatch here will fail loudly at graph-build time rather than silently, which is at least easy to catch.