Eric ERNIE-Image Encode

ERNIE-Image's text encoder is a 3B Ministral model. Every time you hit Generate with a text prompt, that's a 3B model churning through your sentence before the 8B backbone even starts drawing. If you're generating one image, fine. If you're doing what people actually do with ERNIE - running the same prompt across twenty seeds, or A/B testing the SFT and Turbo checkpoints against each other - you're re-running that encoder pointlessly, N times over.

Eric ERNIE-Image Encode is the fix: it runs the text encoder once, caches the result, and lets you reuse it across every subsequent generation. In practice that makes seed-sweeping noticeably snappier, and it's what makes identical-conditioning A/B tests honest, because both checkpoints get fed byte-for-byte the same conditioning.

How it works

The node calls pipeline.encode_prompt() on your loaded pipeline and hands you back the output wrapped as a single ERNIE_EMBEDS object. What's inside, per the source: a list of tensors, each one hidden_states[-2][0] from the encoder - shape [T, 3072], where T is the token count. It's the actual conditioning that the diffusion transformer sees, captured before any denoising happens.

Two inputs, both obvious: pipeline (from the pack's Load Model node) and prompt. One output: embeds (ERNIE_EMBEDS).

How you actually use it

Wire embeds into ErnieImageGenerate's prompt_embeds input. From that point the Generate node ignores its prompt text field and skips the text encoder entirely. A couple of things that makes easy:

• Multi-seed runs: LoadModel → Encode → several Generate nodes (seed 1, 2, 3…) all sharing one Encode output. Text encoder runs once; every seed shares identical conditioning. That's the workflow the README calls out, and it's the one you'll reach for.
• SFT vs Turbo A/B: same embeddings into both checkpoints, same seed, and the difference you see is purely the model - not a typo in the prompt between runs.
• The future bit: because the embeddings are just tensors flowing between Encode and Generate, you could splice your own manipulation in between. The pack doesn't ship a manipulation node, so this is more "the door is open" than "here's a tool."

There's also a negative_prompt_embeds input on Generate, fed by a second Encode node if you want an explicit negative. Wire positive embeds without a negative and Generate silently encodes an empty string for the CFG path, so you can't actually break the workflow by forgetting it.

Caveats worth knowing

• The embeddings are tied to this model's encoder. They're shaped [T, 3072] for Ministral's hidden size. Don't expect to reuse them across another checkpoint, and definitely don't try to feed them back as text.
• It's a CPU/GPU cost-shift, not a magic speedup. The encoder still runs once - you're paying for it one time instead of per-seed, which is the whole point.
• It needs a live pipeline. Encode pulls the encoder off the pipeline you loaded, so it only works after LoadModel has run (and kept the pipeline in VRAM).

Install

Same pack, same one-time setup: ComfyUI Manager search "Eric ERNIE-Image", or cd ComfyUI/custom_nodes && git clone https://github.com/EricRollei/Ernie_Image_Real_Diffusers, restart, point the loader at a downloaded baidu/ERNIE-Image or baidu/ERNIE-Image-Turbo directory. This node adds no dependencies of its own - it's just a thin wrapper around the pipeline's own encode method.

For a beginner the honest take is: you don't need this node. Generate works fine with plain text prompts. But the moment your workflow has two seeds or two checkpoints, the 30 seconds this saves per run add up fast, and it costs you nothing to leave it in the graph.