Clark Air Gemma Encode

This is the node that actually turns your prompt into the numbers Sana can draw from. The Gemma loader upstream is just the library; this is the reader. You'll almost always want two of them - one for the positive prompt, one for the negative - both fed from the same ClarkAirGemmaLoader. The pack's example workflow wires it that way, and there's no reason to fight it.

You type into a big multiline text box, connect a CLARKAIR_GEMMA from the loader, and out comes a standard CONDITIONING socket that plugs straight into the KSampler's positive and negative inputs. That's the whole contract. It slots into the normal ComfyUI graph the way CLIP Text Encode does on any other model - the type name on the output is just CONDITIONING, so KSampler accepts it without complaint.

How it works

Gemma-2-2B is an LLM, not a CLIP encoder, so "encoding" here means the model reads your sentence as text. The node tokenizes the prompt, pads or truncates it to 300 tokens, and masks the padding so the model doesn't attend to empty slots, then takes the encoder's hidden states as conditioning. That's the mechanism - no embedding pooling, no CLIP skip, no layer stacking knobs. Your whole sentence, in context, becomes the conditioning vector. (text-encoder panel has the broader story of why LLM encoders killed CLIP's habits.)

The practical consequences are where beginners get burned:

• Write sentences, not tags. Gemma was trained on natural language. "a cozy reading nook, warm lamp light, film grain" works; a comma-burst of booru tags is wasting the model.
• (word:1.4) weighting does nothing. That's CLIP-era syntax, passed through as literal characters. If you want emphasis, put it in the sentence.
• The 300-token cap is generous but real. The node truncates silently. A short paragraph is the sweet spot; longer isn't better (text-encoder panel notes drift sets in past ~75–100 effective tokens on these models anyway).

What beginners actually set

Only two inputs exist, and you set one of them:

• text - your prompt. Multiline, so stop fighting the single-line box.
• gemma - wired from the loader. You'll see this input auto-fill when you connect it.

The negative prompt can be empty - Sana is trained with classifier-free guidance (the pack's workflow runs cfg 4.5), and an empty negative works fine, which is not something you could say about SD 1.5. Keep the negative short or blank; don't paste a wall of "bad anatomy, mutated hands" boilerplate, it doesn't transfer.

Installing and troubleshooting

The node lives in the Clark Air Sana pack - install via ComfyUI Manager (search "Clark Air Sana") or git clone https://github.com/clark-labs-inc/ComfyUI-ClarkAirSana into custom_nodes, then restart. First run downloads the ~2.1 GB Gemma encoder automatically; subsequent runs are offline.

Real-world failure modes, in order of likelihood:

1. "Just sits there on first queue." It's downloading 2.1 GB of Gemma. Wait, or watch the console.
2. Weird, garbled results → check you're writing natural language, not CLIP syntax.
3. Wrong or empty conditioning → confirm both encode nodes point at the same loader's gemma output. Each encode node needs its own wire; they don't share automatically.
4. Load errors on the encode step → this is upstream, in the loader's bitsandbytes/Triton install, not your prompt. On native Windows, WSL2 is the reliable path.

For a model that costs a third of a gigabyte, this node's job is to make sure the words actually land. Wire it right and Sana does the rest.