Short answer: yes, the setup moved. A ReActor face swap that worked on one rented RTX 3090 was restored on another and swapped the faces again, with no model download on the second machine. Three things made it harder than a plain image workflow, and they are worth knowing if you run ReActor yourself.
The setup
Our workflow generated two portraits with Stable Diffusion 1.5, swapped the face from one onto the other with ReActor and inswapper_128, and restored the result with GFPGAN. It is the typical use of the node pack. On a fresh machine it needs:
onnxruntime-gpu, the GPU build of ONNX Runtime. It is built for a particular CUDA version.- Models that ReActor downloads the first time you run it. You never put them in a folder: the node pack fetches them into ComfyUI's model folders itself. In our run that was 13 files, 1.8 GB: the
buffalo_lface detection and recognition models, a face-parsing network, an NSFW classifier and three face-restoration models, among others. - A licence check.
inswapper_128andbuffalo_lare InsightFace's models, which are for non-commercial use, even though the Hugging Face dataset that hosts them labels itself as MIT.
What we did
We built the workflow on a RunPod RTX 3090, ran it until it produced three images, and packed the folder. We did not tell the tool about any of the 13 downloaded files; it found them, because they had appeared in the model folders while the workflow was running, and listed each with its size.
The nest came to 7.07 GB. Then we rented a second RTX 3090 and pasted the restore command.
What happened
The restore finished in two and a half minutes (150 seconds door to door) and the test render produced the same three images. Compared with the first machine's pictures, the similarity was 1.0: the same pixels, on the same GPU model.
The restore machine downloaded no models. We looked at the whole program run, not only the log: nothing came from Hugging Face or from GitHub releases. The face swap step ran in all three runs on the restored machine, and none of the three program logs records a fall-back to the CPU.
We then ran the workflow again with the network watched (strace, because the machine would not let us switch the network off). The only connections outside the machine were address lookups with no data sent, never a TCP connection. That doesn't prove the run would work with the network unplugged, because strace doesn't block anything. It does say the program didn't try to download anything.
Three things to know
It also carried what you didn't use. The tool looks for files that the running ComfyUI holds open. None was open when it looked, so it couldn't tell which of the files in those four folders the workflow had loaded. It carried all of them, three face-restoration models that this workflow never used included, and said so. That costs size, not correctness. The other way round, leaving out something that was needed, would give you a nest that checks out byte for byte and fails when it runs.
The downloaded models don't travel in a hand-off. The 13 downloaded files are marked "unknown" and not shareable, because nothing vouches for them. If you hand this nest to someone else, those files won't travel; their restore lists them and fetches them from where they came from, if the nest recorded where. Whether you may use inswapper_128 for your work is between you and its publisher.
onnxruntime-gpu came back as the GPU build. The dependency list pins onnxruntime-gpu 1.26.0 and the restore installed that package. The face swap ran three times on the restored machine, and none of the three program logs records a fall-back to the CPU.
What this doesn't say
One workflow, one pair of identical cards, on version 0.1.22. Other ReActor setups (other swap models, other restore models) may download other files. The similarity of 1.0 is for the same GPU model. On a different model we'd record the similarity as a fact, as in our FLUX.2 Klein runs.