vLLM-T2I丨API

VLLMT2IAPI is the text-to-image member of the QING vLLM trio. Give it a prompt, and it asks a running vLLM-Omni server to generate an image, then drops the result back into the graph as a normal IMAGE tensor - ready for a Preview or Save node like any locally-sampled output.

Display name: "vLLM-T2I丨API".

The two endpoint paths (this is the important choice)

The node's t2i_endpoint dropdown picks which HTTP path the request takes, and they behave differently:

• chat_completions (default) - the vLLM-Omni documented main path. The node POSTs to <base_url>/v1/chat/completions with your prompt as a user message, and tucks the generation parameters - width, height, num_inference_steps, true_cfg_scale, top_p, repetition_penalty, seed, and negative_prompt if provided - into an extra_body block. vLLM-Omni reads those extra fields and returns an image in the chat response.
• images_generations - the OpenAI-style /v1/images/generations endpoint, used in vLLM-Omni's LoRA examples and some other setups. Here the request is a flat OpenAI image call: size as "WxH", n (how many images), response_format (b64_json or url), plus top_p and repetition_penalty.

So the two knobs that say "only images_generations" in their tooltips - n and response_format - are exactly that: on the default chat path they're ignored. Set t2i_endpoint first, then the path-specific settings make sense.

What you'll actually set

• prompt, negative_prompt - the generation text.
• model - the model id, matching the server's /v1/models.
• base_url - default http://127.0.0.1:8091, your vLLM server.
• width / height - strings, not numbers, in this node. Default "1024"/"1024".
• num_inference_steps - default 50.
• true_cfg_scale - default 4.0. This is the Flux-family guidance parameter vLLM-Omni expects; it's written into extra_body.true_cfg_scale on the chat path. Note it's true_cfg_scale here - the I2I sibling uses guidance_scale - so don't copy settings across the two nodes blindly.
• seed, top_p, repetition_penalty, timeout_sec - the rest.
• Outputs: image (IMAGE), raw_response, status, debug_info.

The advanced_options input merges in extra JSON from VLLMAdvancedOptions on top of everything, which is how you add guidance scale, CFG, resolution, layers, or a LoRA without waiting for new widgets.

The OOM safety net (a genuinely nice touch)

If the server responds with a CUDA out-of-memory error, the node detects it and does two things: it returns a placeholder image instead of crashing your run, and it appends hints to raw_response - drop to 768×640 or lower, cut steps to 20–30, or restart the server with PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True. It's a small thing, but it turns the most common failure mode from "mystery placeholder" into "actionable advice."

Installing it

Ships in ComfyUI-QING:

cd ComfyUI/custom_nodes
git clone https://github.com/GAO-SHIQING/ComfyUI-QING
cd ComfyUI-QING
python install_dependencies.py

Restart ComfyUI, or install "ComfyUI-QING" via ComfyUI Manager.

Troubleshooting

• Placeholder image + status error. Read raw_response - it's the server's own message. Connection refused means no server on that port; 400 usually means a bad model id or a param the endpoint doesn't accept.
• n / response_format appear to do nothing. You're on the chat_completions path where they're ignored. Switch to images_generations if you need batches.
• Image looks soft or unguided. true_cfg_scale of 4.0 is a starting point, not a law; some models want 3–7. Move one knob, compare, repeat.
• Took ages then failed. Raise timeout_sec (max 600) - big diffusion requests at 50 steps can exceed the default 120s on a busy server.

As with its siblings, this node runs no model itself - it's an HTTP client for a server that does (external-api-nodes.md). If you already have a vLLM-Omni instance serving an image model, it's the fastest way to get that model's output into a ComfyUI graph as a first-class IMAGE.