Fetch from remote
The node that waits for your second GPU and brings back more than a picture
- final_image
- remote_info
- IMAGE
- latent_base64
- P_conditioning_base64
- N_conditioning_base64
This is the node that closes the loop on any remote job you dispatched with RemoteQueueSimple-Nux. It blocks, waits for the remote instance to actually finish, and then hands the result back - and unlike the plain FetchRemote node in the original city96 NetDist this pack forked from, "with extras" is the operative phrase: it can pull back the render's latent and both conditioning channels too, not just the finished image.
Why the "extras" matter
The pack's signature move - spelled out in its own README's "Remote conditioning Workflow" example - is running T5 and CLIP-L on a second GPU while your primary card handles UNet and VAE. That split is only useful if the encoded conditioning actually makes it back to the machine doing the sampling. This node is the retrieval half of that: it collects whatever the remote graph packaged up with SaveImageWithBase64-Nux and hands it back as ready-to-use base64 strings.
Inputs and outputs
Two required inputs. final_image is an IMAGE socket - the README is explicit that this should be the final image you want back from the second instance, and warns not to route it back into itself (that creates a loop). remote_info is a REMINFO socket that comes straight from RemoteQueueSimple-Nux's output - it's how this node knows which job to wait on.
Four outputs: IMAGE (the finished picture), plus latent_base64, P_conditioning_base64, and N_conditioning_base64 - the positive and negative conditioning, base64-encoded, ready to hand to ConditioningFromBase64-Nux on your primary graph and plug straight into your KSampler.
Installing it
Search ComfyUI_NetDist_Plus in ComfyUI Manager, or:
cd ComfyUI/custom_nodes
git clone https://github.com/nux1111/ComfyUI_NetDist_Plus
pip install requests
Restart ComfyUI. No model downloads for this node - it's pure network fetch.
Where people get burned
There's no progress bar while it waits - the README says so directly. A slow remote render just looks stuck; don't assume it's hung until you've actually given it time.
If the remote graph never wired anything into SaveImageWithBase64-Nux's optional latent/positive_conditioning/negative_conditioning sockets, the three extra outputs here will come back empty. That's expected - this node only returns what the remote side actually packaged up, it can't invent data that was never sent.
The bigger structural thing to know before you build around this: exposing a second ComfyUI instance with --listen so this node can reach it means that instance has no authentication by default. Fine on a trusted home network; not something you want reachable from the open internet. Anyone who can hit that port can queue arbitrary work on it.
And a general framing worth carrying into every remote node in this pack: it's a small, solo-maintained fork built around one specific multi-GPU pattern. The conditioning path is the one the author actually demonstrated working end to end; treat anything adjacent to it - especially the latent output, which the README admits was never fully tested - with a bit more caution until you've verified it on your own setup.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| final_image | IMAGE | — | |
| remote_info | REMINFO | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |
| latent_base64 | STRING | — |
| P_conditioning_base64 | STRING | — |
| N_conditioning_base64 | STRING | — |