Nodes/ComfyUI_NetDist_Plus/Queue on remote (single)
ComfyUI Node

Queue on remote (single)

The easy way to put a second GPU to work

By nux1111·Created 2 years ago·Updated 2 years ago· 39
Queue on remote (single)
  • remoteapply1
  • remoteapply2
  • remoteapply3
  • remoteapply4
  • remoteapply5
  • remoteapply6
  • remoteapply7
  • remoteapply8
  • remoteapply9
  • remoteapply10
  • seed
  • batch
  • remote_info
remote_urlhttp://127.0.0.1:8288/
batch_local1
batch_remote1
trigger
enabledtrue
seed0

If you've got a second GPU sitting idle - a card you outgrew, a housemate's rig, a second PC on the same network - this is the node that puts it to work. It's the entry point to NetDist_Plus's whole reason for existing: point it at a second ComfyUI instance and it queues a job there alongside whatever your local machine is doing, splitting the render across two GPUs instead of one.

How it fits together

You need two running ComfyUI instances for this to mean anything: your primary one, and a second one on a different port (--port 8288) or a different GPU (--cuda-device 1), or genuinely a different PC on your network (add --listen to its launch args and use its LAN IP). This node lives on your primary instance's graph and talks to the second one over HTTP.

Inputs and outputs that matter

  • remote_url - where the second instance lives, e.g. http://127.0.0.1:8288/ for a second local GPU, or the LAN IP if it's a separate machine.
  • batch_local / batch_remote - how many images each side renders per queue call.
  • trigger - on_change re-fires only when its inputs actually change; always forces it every run. The pack's own guidance: flip it to always if you tweak something like a sampler setting without changing the seed and the remote pass doesn't seem to fire.
  • enabled - true/false switch the whole node on or off; there's also a remote value that appears to skip the local render and only dispatch to the remote side.
  • seed - pass a seed through so local and remote stay coordinated.

There are also ten optional remoteapply1remoteapply10 sockets. Wire in a RemoteApplyValues-Nux (or the -Multi variant) node and you can override a specific parameter on a specific node in the remote graph - a different checkpoint, a different step count - without keeping two separate workflow files in sync.

Outputs: seed and batch pass through for downstream bookkeeping, and remote_info - which you plug into FetchRemoteWithExtras-Nux so it knows which job to wait on and pull back.

Want more than two machines? Chain multiple RemoteQueueSimple nodes together, one per extra worker - the README calls out that seed handling gets a little jank once you scale past two, and suggests just randomizing the seed on every instance rather than fighting it.

Installing it

ComfyUI Manager: search ComfyUI_NetDist_Plus. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/nux1111/ComfyUI_NetDist_Plus
pip install requests

Restart ComfyUI. No model weights involved - this is pure network plumbing.

Where people get burned

remote_url has to be genuinely reachable. If the second instance is on another PC, that instance needs --listen and you need its actual LAN IP (ip a on Linux, ipconfig on Windows) - 127.0.0.1 only works when both instances are on the same box.

Worth knowing before you expose anything: ComfyUI's API has no authentication by default. Adding --listen to a second instance opens it to anything else that can reach that port on your network - fine on a trusted home LAN, a bad idea on an open network or the public internet. Don't put a NetDist worker on the open internet without putting something in front of it.

There's no progress indicator while you wait - the README says so outright - so a slow remote render just looks stuck. Give it time before assuming something's wrong. And the author's own issue list flags that batch sizes above 1 threw unexplained errors in at least one of his own test workflows (a style-transfer setup); if you hit weird batch failures, the first thing to try is dropping batch_remote back to 1 and working up from there.

One more honest framing: this whole pack is a fork of a fork, built by a solo hobbyist and, by the pack's own account, not under active development. When it works it can meaningfully cut render time by splitting the load across two cards - but treat it as a DIY tool you'll occasionally have to debug yourself, not a polished product.

Categoryremote

Inputs (16)

NameTypeDefaultDescription
remote_urlSTRINGhttp://127.0.0.1:8288/
batch_localINT11–8
batch_remoteINT11–8
triggerCOMBO2 options: on_change, always
enabledCOMBOtrue3 options: true, false, remote
seedINT00–18446744073709550000
remoteapply1optREMOTEAPPLY
remoteapply2optREMOTEAPPLY
remoteapply3optREMOTEAPPLY
remoteapply4optREMOTEAPPLY
remoteapply5optREMOTEAPPLY
remoteapply6optREMOTEAPPLY
remoteapply7optREMOTEAPPLY
remoteapply8optREMOTEAPPLY
remoteapply9optREMOTEAPPLY
remoteapply10optREMOTEAPPLY

Outputs (3)

NameTypeDescription
seedINT
batchINT
remote_infoREMINFO