Qwen Image 2.1 Prompt Enhancer (GPUStack)

What you're actually installing

You type 一根葱，画面中文字"葱 Pro" - a scallion, with the words 葱 Pro in the frame - and this node hands you back a paragraph: black backdrop, the scallion centred, the text rendered verbatim, lighting falling from a single source. That paragraph is a STRING. Wire it into the positive prompt of your Qwen Image 2.1 text-to-image node and the sampler never sees your five-word original.

It works here rather than fighting the architecture because Qwen-Image is LLM-encoded - its condition encoder is Qwen2.5-VL, so your prompt is an instruction read by a language model. Having a second language model write that instruction is a translation between two things that speak the same language. Weight syntax like (face:1.4) is discarded on these encoders, tags are the wrong register, and this node nudges you into sentences, which is what the model wanted all along.

One caveat up front: this is not Qwen's prompt-rewrite model. The source says so outright - the default system prompt is adapted from Qwen's public T2I rewriting contract, "not the system prompt or the weights of Qwen-Image-2.1-PE-T2I." You're running a general chat model wearing Qwen's prompt. Good prompt, not the fine-tuned thing.

How it works

There's no model here. The node is an HTTP client. It POSTs your prompt as a user message and the system_prompt as a system message to an OpenAI-compatible /v1/chat/completions endpoint, stream: false, and returns choices[0].message.content.

Everything interesting is in that default system prompt, which you can read and edit in the node. It has the model describe the finished image as an observer rather than issue instructions, preserve every subject, count, colour and spatial relation you fixed, reproduce in-image text character for character, treat "sharpness/quality" requests as constraints rather than objects, and keep numeric aspect ratios out of the prompt because width and height are set elsewhere in the workflow.

The default reasoning_effort is off, which the code sends as "none". That's the right default: a reasoner on this job spends tokens deliberating and is more likely to leak its scratch-work into your prompt. Turn it up and you're buying latency per step.

Inputs and output

Only a few fields matter to a beginner. prompt is yours, up to 8000 characters. system_prompt is the author's contract, up to 12000 characters - edit it if you want a house style, leave it alone otherwise. model defaults to qwen3.8-27b, which is a GPUStack alias, not a public model name; set it to whatever your server actually serves.

Then the dials: temperature 0.5 by default, max_tokens 1024 (128–4096), timeout 120 seconds. Output is a single enhanced_prompt STRING. Put a Show Text node in front of your sampler at least once, so you can see what it wrote before you judge the image.

Install

ComfyUI Manager, search "ZMG" or ComfyUI-ZMG-Nodes. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/vanche1212/ComfyUI-ZMG-Nodes
cd ComfyUI-ZMG-Nodes && pip install -r requirements.txt

That requirements.txt is written for the whole plugin - requests, Pillow, numpy, torch, plus oss2 and pydub for nodes you're not using here. This node alone needs requests. No model download, no GPU, no weights; the model runs on whatever server you point at.

Where people get burned

The endpoint is not in the node. There is no URL field. It comes from ZMG_QWEN_PE_API_URL, and if that's unset you get the author's private LAN address, http://10.27.89.24/v1/chat/completions. So your first run almost certainly ends in a connection error. Set it in the environment that launches ComfyUI:

export ZMG_QWEN_PE_API_URL="http://your-server:8080/v1/chat/completions"
export ZMG_GPUSTACK_API_KEY="sk-..."

Two traps in that string. The variable is validated as http:// or https:// and must end in /v1/chat/completions - anything else raises "must be an OpenAI-compatible chat completions endpoint." And GPUStack itself is near-invisible in the community, so nobody's going to hand you a working URL. Any OpenAI-compatible server does: llama.cpp, vLLM, Ollama's OpenAI endpoint, a rented GPU.

The key. Leave api_key blank and the node reads ZMG_GPUSTACK_API_KEY from the server process, which is what you want. Type a key into the node field and it can land in the workflow JSON and the task history - the README warns about this in bold, and it's true. Don't share a workflow with a key in it.

Failures are loud, which is the good news. No key, a non-200, an empty response, a response over 16000 characters, or output that isn't a string - all raise instead of quietly passing your raw prompt through. Error messages deliberately don't echo the server body, so they never leak your key into a log. If you see an HTTP code, that's your endpoint talking: 401 is the key, 404 is usually a model name your server doesn't have, and a timeout at 120s means raise timeout (max 300) or stop raising reasoning_effort.