vLLM-I2I丨API

VLLMI2IAPI is the image-to-image member of the QING vLLM trio: you give it an input image and an edit instruction, it sends both to a vLLM-Omni server, and hands back the edited result as an IMAGE. It's the node that turns a text-edit prompt into a real visual change without leaving the graph.

Display name: "vLLM-I2I丨API".

The two endpoint paths, and the auto-switch that can surprise you

Like its T2I sibling, this node has a path dropdown - i2i_endpoint - but it also has a second, hidden trigger:

• chat_completions (default) - sends the image as a multimodal image_url (base64 data URL) in the user message, alongside your edit text, with the generation params in extra_body (here it's guidance_scale, not true_cfg_scale - don't carry settings over from the T2I node). This matches vLLM-Omni's official I2I example.
• images_edits - POSTs to /v1/images/edits as a multipart form: the image file itself, your prompt, size as "WxH", n, response_format, and negative_prompt. This is the classic OpenAI image-editing shape.
• The auto-switch: if you connect the optional mask input, the node forces the images_edits path regardless of the dropdown - and tells you so, by prepending an [info] note to raw_response. A mask is an editing feature that only the edits endpoint implements, so the node doesn't ask; it just routes.

That auto-switch is the thing to remember. If your server only implements the chat path and you wire in a mask expecting it to still work, the request suddenly goes to /v1/images/edits - which may 404. The node even logs "已连接 mask，自动使用 POST /v1/images/edits" so the debug trail shows you what happened.

What you'll actually set

• image (required) - the input to edit.
• prompt - the edit instruction ("make it dusk", "remove the background object"). negative_prompt too - the tooltip notes it's commonly used in edits mode.
• model, base_url - server and model id, as with the other two nodes.
• width / height - strings, default "1024".
• num_inference_steps, guidance_scale, top_p, repetition_penalty, seed - sampling knobs.
• i2i_endpoint, n, response_format - n and response_format only apply on the images_edits path (same rule as T2I).
• mask (optional) - forces the edits endpoint, as above.
• api_key, advanced_options (optional).
• Outputs: image (IMAGE), raw_response, status, debug_info.

The OOM safety net, same as T2I

Server-side CUDA OOM gets caught: placeholder image instead of a crashed run, plus hints in raw_response (drop resolution to 768×640, cut steps, or restart with PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True). On a path that sends full-resolution input images plus a generation, OOM is a realistic possibility, so this isn't cosmetic.

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

• Status error right after connecting a mask. Read raw_response for the [info] line and the server's reply - the mask forced /v1/images/edits, and your server likely doesn't serve it. Either drop the mask (and use the chat path) or confirm the server supports image edits.
• n / response_format ignored. You're on the chat path; those apply to images_edits only.
• Edits barely change the image. guidance_scale (default 4.0) controls how closely the edit follows the instruction versus the input. Raise it a step at a time.
• Placeholder + error but no obvious cause. debug_info carries the full request payload and HTTP status; raw_response carries the server's own message. One of them names the real problem.

The pattern here is the same as the other API nodes - no model, just an HTTP client pointing at a server (external-api-nodes.md). If you run vLLM-Omni locally, this is the closest thing to an in-graph img2img edit node you'll get without pulling the weights into ComfyUI itself.