Conditioning2Base64

This is the sending half of NetDist_Plus's conditioning round trip. CONDITIONING is just a tensor in memory - fine as long as it stays inside one ComfyUI process, useless the moment you need it on a different machine. This node flattens it into a plain base64 string that can actually travel: over HTTP, or embedded inside a saved image file.

Why this exists

The pack's whole reason for being is splitting a render across two GPUs, and its flagship pattern for doing that is running text encoding on a second instance - T5 and CLIP-L on the remote box, UNet and VAE on your primary one - so the primary GPU isn't burning cycles on encoding it doesn't need to repeat. Once your remote instance has produced conditioning from its CLIPTextEncode, this node is what turns it into something transportable. Wire your conditioning into it there, and the resulting string can either ride back automatically (this pack's remote-fetch machinery collects it for you) or manually, by wiring the output into SaveImageWithBase64-Nux's conditioning sockets so it's embedded straight into a saved PNG for later retrieval.

Inputs and outputs

One input: conditioning, a standard CONDITIONING socket - plug in whatever your CLIPTextEncode (or equivalent) produced.

One output: base64_conditioning, a plain string. On the far end, ConditioningFromBase64-Nux turns it back into real conditioning.

That's the entire node - no options to tune, no compression settings. It serializes what you give it and nothing more.

Installing it

ComfyUI Manager: search ComfyUI_NetDist_Plus. Or:

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

Restart ComfyUI afterward. No model weights are involved in this node.

Where people get burned

This node doesn't validate anything - it just serializes whatever CONDITIONING you hand it. If the conditioning going in is already malformed (say, from a model mismatch upstream), you won't see that failure here; you'll see it downstream, once ConditioningFromBase64-Nux tries to turn the string back into something usable and the receiving sampler chokes on it.

The other thing worth knowing before you lean on this for anything beyond single prompts: the pack's own README lists batched base64 handling as an open issue the author never fully solved ("there are existing node[s] that should fix that"). If you're trying to serialize conditioning for a batch of multiple prompts at once rather than one at a time, this straightforward serializer isn't the tool built for that - you're better off looking at a dedicated batching node pack, or keeping your batch size at 1 through this path.

Broader context worth having going in: NetDist_Plus is a small, solo-maintained fork built specifically around this remote text-encoding pattern. It's a real and useful trick if you've genuinely got a spare GPU sitting around and want to offload CLIP/T5 work to it - but it's DIY tooling, not something with a large user base to lean on if you hit an edge case the author didn't test.