Qwen2.5

Most of the buzz around this pack is about the vision node, but the Qwen2.5 node is the quietly more useful half for a lot of people: it's a text-only LLM sitting inside ComfyUI, no image input, no vision weight, no API key. You feed it a system prompt and a user prompt, it generates a STRING, and that string is usually destined for a CLIPTextEncode node.

Why would you want an LLM in your graph at all? Because modern text-encoder models reward good prose, and the community's answer to "writing good prompts is work" has converged on letting an LLM do it. The pattern: you type a rough idea, Qwen expands it into a well-structured natural-language prompt, and the result goes straight into your positive conditioning. It's LLM-assisted prompting as a first-class workflow step, and this node is the smallest way to get it.

Quick naming note so it doesn't confuse you: Qwen2.5 and Qwen are the same node. Both class names in this pack map to the same text-only Qwen class, registered twice for compatibility. Same inputs, same behavior.

How it works

It's the plainest possible wrapper around Hugging Face's AutoModelForCausalLM and AutoTokenizer. Your system and prompt strings get wrapped in a chat template, tokenized, and run through the model's generate() inside torch.no_grad(), then decoded back to text. Like its vision sibling, it auto-downloads the checkpoint on first run into ComfyUI/models/LLM/, runs bfloat16 on Ampere+ (fp16 otherwise) with device_map="auto", and offers the same quantization options.

The model list is small and sensible: Qwen2.5-3B/7B/14B/32B-Instruct plus Qwen3-4B-Thinking-2507 and Qwen3-4B-Instruct-2507. The default is the Qwen3-4B instruct model - a good default, since 4B is plenty for prompt rewriting and fast to run.

The inputs that matter

• system - the persona/instruction slot. The default, "You are a helpful assistant.", is fine, but this is where you paste your "you are a prompt engineer who writes detailed Flux-style prompts" boilerplate. It's multiline and it's the one most people customize.
• prompt - what you actually want generated. "Turn this into a detailed prompt: a rainy neon alley" works.
• model - six choices, as above. For pure text-to-prompt work, 7B is a comfortable sweet spot; 32B exists if you have the VRAM and want the best writing.
• quantization - none/4bit/8bit. 4bit is the standard move for the 14B and 32B.
• keep_model_loaded - default False unloads the model after every run. For a text model the reload is cheaper than for the VL 7B, but if you're generating a batch of prompt variations, flip it on.
• temperature (default 0.7), max_new_tokens (128–2048, default 512), seed (-1 = random) - the usual knobs. Lower temperature for more consistent prose.

There are no optional inputs here - no image, no video, by design. If you feed both an empty system and an empty prompt, the node returns an error string instead of doing anything clever.

Output is one STRING, which wires into CLIPTextEncode (positive text) or a ShowText node.

Install

ComfyUI Manager, search "Qwen-VL wrapper for ComfyUI", or:

cd ComfyUI/custom_nodes
git clone https://github.com/alexcong/ComfyUI_QwenVL
cd ComfyUI_QwenVL
pip install -r requirements.txt

Restart ComfyUI. It shares the pack's dependency list - transformers>=4.57.1, accelerate, bitsandbytes, optimum - so you only install once for all four nodes.

Gotchas

Same pack-level quirks apply: keep_model_loaded defaults off, so repeated runs reload the weights; 4bit/8bit need bitsandbytes working on CUDA or they error; and the transformers>=4.57.1 pin can collide with Nunchaku-style setups that pin older transformers. For this node specifically, don't over-spec the model - a 14B in 4-bit is the most you'll ever actually need for prompt generation, and the 3B/4B options do it almost as well at a fraction of the memory. If the prompt it writes reads a little generic, that's the temperature talking: drop it to 0.5 and give it a better system prompt before you blame the model.