Nodes/ComfyUI Functional/Call Remote Function
ComfyUI Node

Call Remote Function

Run part of your workflow on another ComfyUI instance

By Duanyll·Created 11 months ago·Updated 4 months ago· 2
Call Remote Function
  • closure
  • param_0
  • *
base_url
timeout600.00
use_shared_memoryfalse

Call Remote Function is Call Function's jealous sibling: it does the same job, but it ships the work to another ComfyUI server. Different GPU, different machine, different corner of your LAN - the function body runs there, and the result comes back over HTTP/WebSocket. It's a genuinely rare feature in the ComfyUI ecosystem, and it's the pack's most impressive trick. It's also, for most beginners, overkill. Let's figure out which camp you're in.

The inputs that matter

  • closure - the function to execute remotely
  • base_url - where the remote server lives, e.g. http://192.168.1.100:8188
  • timeout - how long to wait, in seconds (default 600)
  • use_shared_memory - same-machine tensor passing (default false)
  • param_0, param_1, … - the function's arguments; these get serialized and sent over the wire

The output is the deserialized return value, typed *.

How it works (and the rule you must not break)

The pack takes the closure, builds a small workflow for the remote instance, serializes your params into it, and injects __Deserialize__ nodes so the remote side can rebuild them. The remote runs the function, the output goes through the pack's __Serialize__ node, and the result comes back to you.

The one rule that trips everyone up: your Function End must have capture set to False. Local calls capture non-parameter-dependent nodes (like a loaded checkpoint) and reuse them. Remote calls can't - models, samplers, and other complex ComfyUI objects aren't serializable, so nothing heavy can ride along. Instead, you load models inside the function body, on the remote machine. That sounds like a downgrade, but it's actually the point: because node IDs stay consistent across remote calls, the remote ComfyUI caches normally, so a model stays resident on the worker instead of being unloaded and reloaded per call.

What can travel: basic Python types, bytes, numpy arrays, CPU torch tensors (GPU tensors get moved to CPU automatically), and PIL images. Everything else - models, CLIP, VAEs - must stay inside the remote function body.

When it's worth it

  • Pipeline parallelism: run stage A on one GPU and stage B on another simultaneously.
  • Avoiding model reloads: keep a big model loaded on a dedicated worker.
  • Shared-memory mode: if both instances run on the same physical machine, flip use_shared_memory on and CPU tensors pass via shared memory instead of base64 - dramatically faster for images and latents. Cross-machine calls always fall back to standard serialization, so don't expect the checkbox to help there.

The gotchas

Same pack-wide traps apply: use Basic Data Handling LIST values, not native Data Lists. Remote calls need the remote server to have this same pack installed. And this pack leans on hacky ComfyUI internals - the README's warning about testing before relying on it in production pipelines applies double here, because now you have two ComfyUI installs that can each break on an update.

Installing it

Ships in Duanyll/comfyui_functional; install on both machines. ComfyUI Manager (search "Duanyll/comfyui_functional") or:

cd ComfyUI/custom_nodes
git clone https://github.com/Duanyll/comfyui_functional
# restart ComfyUI - on every instance you want to call

No models, no pip deps. Start local, on a second port (:8189), before you try a real network box.

Categoryduanyll/functional

Inputs (5)

NameTypeDefaultDescription
closureCLOSURE
base_urlSTRING
timeoutFLOAT600.00
use_shared_memoryBOOLEANfalse
param_0opt*

Outputs (1)

NameTypeDescription
**