PipelineParallel

The graph node called PipelineParallel is almost a decoy. What this pack actually ships is a second prompt API - /parallel/prompt - plus a thread pool that lets several workflows chew on your GPU at the same time. If you've ever watched ComfyUI's queue drain one generation at a time while you've got a backlog of prompts to render, you know the itch it's scratching.

Stock ComfyUI is strictly serial: the prompt worker pulls one item, runs it start to finish, then moves on. Even inside a single graph, independent branches don't overlap - nodes execute in dependency order on one worker, and the fastest branch still waits for the slow one. This pack replaces that machinery with concurrent execution. It's aimed at people driving ComfyUI from the API, not the person clicking Generate in the UI.

What it is not (say it now, save yourself later)

Despite the name, this is not pipeline parallelism in the LLM sense - no splitting one model's layers across GPUs, no activations shuttling over PCIe. Diffusion denoising is a sequential loop, so "true" pipeline parallelism doesn't map onto it anyway; the community's reliable win for multi-GPU setups is data parallelism, running several independent gens at once. That's what this does. Expect more throughput when you queue multiple prompts, not a single image that renders faster. If you just want two instances chugging away, two ComfyUI processes on separate ports is honestly the more robust version of the same idea.

How it works

The pack monkey-patches ComfyUI's internals at import time: it swaps out execution.PromptExecutor.execute, PromptQueue.put/get/task_done, and neuters comfy.model_management.cleanup_models and soft_empty_cache so concurrent threads don't fight over cache eviction. Submitted prompts land in a ThreadPoolExecutor, sized by the COMFY_PIPLELINE_THREADS environment variable (default 6). Each workflow gets its own lock and its own node cache, keyed by the workflow_name you pass in extra_data, and per-node locks let independent branches inside one workflow run in parallel. When everything goes idle, it runs its own garbage collection pass.

The node itself is an output node with a single required INT input, executor_count - and it's honest to tell you it does basically nothing. It doesn't size the thread pool (the env var does), and it returns no outputs; it just echoes the value into the UI. Add it to a graph if you want a visible marker, but don't hunt for a toggle. The real interface is the HTTP API.

Using the API

Same request shape as /prompt, but you must add extra_data.workflow_name - without it you get a 400. The README's example has a stray quote in client_id; here's the shape that actually parses:

curl localhost:8080/parallel/prompt \
  -H "Content-Type: application/json" \
  -d '{"prompt": {"2": {...}}, "client_id": "some-id",
       "extra_data": {"workflow_name": "workflow-api.json"}}'

Results come back from /parallel/history (or /parallel/history/{prompt_id}), and there's a /parallel/ws endpoint if you want live status over a socket. Requests from the normal UI or /prompt are routed through the origin queue, so nothing you already run breaks - in theory.

Installing

Clone it into custom_nodes and restart. ComfyUI Manager may list it under "Pipeline Parallel ComfyUI"; if not, the manual route is:

cd ComfyUI/custom_nodes
git clone https://github.com/DeJoker/pipeline-parallel-comfy

No requirements.txt, no model downloads, no pip dependencies - it leans on aiohttp, torch, and PIL that ComfyUI already ships.

Where people get burned

• It's a monkey-patch, so ComfyUI updates will eventually break it. A core refactor of execution.py will silently do nothing (or worse) until this pack is updated. If you build a service on it, pin your ComfyUI version.
• OOM is easy to trigger. With cache cleanup and soft_empty_cache suppressed during runs, several threads loading big models at once can blow past 8 GB fast. Keep the thread count modest; the COMFY_PIPLELINE_MODEL_COUNT and low_mem knobs exist in the config but aren't actually wired anywhere, so don't count on them.
• The node "does nothing." Correct - it's a placeholder. The knob that matters is COMFY_PIPLELINE_THREADS, set before ComfyUI starts.

It's a niche, code-review-before-you-trust-it sort of pack - the ecosystem has no audit gate, so glance at parallel.py if you're going to run it on something important. For a few concurrent API prompts it works; for a production render farm, buy something with a maintainer.