FL PixelGen Text Encoder Loader

The PixelGen denoiser can't read a word of your prompt by itself. This node loads the network that turns your prompt into conditioning vectors it can understand: Qwen3-1.7B, a full language model, not CLIP. If you've only ever run SD 1.5/SDXL-era models, this is the node that quietly ends a bunch of old habits - no CLIP skip, no prompt weighting syntax, no 77-token truncation. You're writing to a language model now, and the practical caption length is whatever you can usefully say.

It's the second node in the standard FL PixelGen pipeline: Model Loader → Text Encoder Loader → Generate. Both loaders connect into FL PixelGen Generate (or FL PixelGen Train), and the pack refuses to run without both.

The mechanism, from the source: the loader pulls Qwen/Qwen3-1.7B from HuggingFace on first use, wires it into the denoiser's expected dimensionality (embed_dim 2048, max_length 128), and caches it in memory keyed by name+device. That 1.7B footprint is modest compared to the 4B–24B LLM encoders on 2026's bigger models - which is part of why the whole pack runs on a 12GB card. It's not a tokenizer-plus-pooler hack; the denoiser was trained against this encoder, so swap in a different Qwen variant and you're on your own.

Inputs you'll touch:

• model_name - dropdown, currently one option: Qwen/Qwen3-1.7B. The tooltip is blunt: "Qwen3 text encoder variant." Don't expect a menu of quantized alternatives yet.
• device - cuda or cpu. CPU loads and runs, just slowly; leave it on cuda.
• force_reload - set to True to bypass the encoder cache, e.g. after updating the HF download.

The output is one text_encoder (PIXELGEN_TEXT_ENCODER) that plugs straight into the Generate node's text_encoder socket.

Installing: nothing special - this node ships inside ComfyUI-FL-PixelGen. ComfyUI Manager (search "FL PixelGen") or

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI-FL-PixelGen
cd ComfyUI-FL-PixelGen
pip install -r requirements.txt

then restart. The first time you execute, the loader downloads ~3.5GB of Qwen3 weights; transformers>=4.45 (in the requirements) is what actually loads it, so if the node errors at runtime with an import or a "no module" complaint, that's your first suspect.

Troubleshooting worth knowing: because this is a real LLM encoder, negative prompts behave differently than your SDXL instincts suggest - this encoder has no CLIP-adjacent embedding space, so old negative embeddings and CLIP-skip tricks are dead on arrival. If generations ignore your negative prompt entirely, that's the model family, not a broken node. And if the pack feels slow to start, remember the encoder load is a one-time-per-session cost; it stays cached until you flip force_reload or restart. That's the same "load once, cache the conditioning" philosophy the training side uses when it pre-encodes captions - encode once, generate a hundred times.