Short answer: in our measurements, restoring the same ComfyUI environment on hosts with the same GPU model produced exactly two possible images, each byte-identical across hosts. Which one you got was decided by the host's CPU vendor — AMD hosts reproduced the original file, Intel hosts produced a second, fixed image at an SSIM of 0.981439. The driver was ruled out. Measured 2026-08-02 to 2026-08-12, one workflow, one GPU model (RTX A4000).
This is the long version of a finding we first reported in the 23 GB video field report. It answers a question every ComfyUI user asks about moving a setup: will my image come back exactly the same?
The setup
We had one archived ComfyUI environment — packed after a successful run, every file checksummed, kept in object storage. We restored it onto rented hosts that all had the same GPU model, an RTX A4000, spread across five countries. On each host we started the app, regenerated the image with the same workflow, seed and settings, and compared the output to the original: first by SSIM (structural similarity; 1.000000 means the same pixels), then byte by byte.
The scope, before any conclusion: one GPU model, one workflow, a handful of hosts, measured between 2026-08-02 and 2026-08-12. Everything below holds inside that box.
The images collapsed into exactly two files
The regenerated images did not scatter into slightly different results. They fell into exactly two byte-equivalence classes:
- Class A — the same file as the original. SSIM 1.000000, same fingerprint, across countries and hosts.
- Class B — one different image. Every Class B host produced a file with the same fingerprint as every other Class B host. SSIM against the original: 0.981439, every time.
That explains why the score never moved from its sixth decimal place: 0.981439 was never a noisy similarity near some value. It was the fixed distance between two fixed images.
The driver was the first suspect, and the data ruled it out
The obvious guess was the GPU driver, since the hosts ran several driver releases. Our own measurements already refuted it: driver 580.159 appeared in both classes — one host on 580.159 produced Class A, another on 580.159 produced Class B. A variable that takes the same value while producing both outcomes is not the cause. Three different driver versions also landed on the identical 0.981439.
The CPU vendor split the hosts exactly along the class line
| Host | CPU | Driver | Class | SSIM vs. original |
|---|---|---|---|---|
| Host 1 | AMD Ryzen 2700 | 580.159 | A | 1.000000 |
| Host 2 | AMD Ryzen 5600X | 550.163 | A | 1.000000 |
| Host 3 | Intel i7-13700 | 595.71 | B | 0.981439 |
| Host 4 | Intel Xeon E5-2620 v4 | 570.172 | B | 0.981439 |
| Host 5 | Intel Xeon W-2123 | 580.159 | B | 0.981439 |
The Intel side spans three microarchitecture generations (Raptor Lake, Broadwell, Skylake-W) and three drivers; every one produced the same Class B file. The AMD side spans two Zen generations and two drivers; both produced Class A. Inside this experiment, once the GPU model was the same, the CPU vendor alone predicted the output.
Why would the CPU matter in a GPU pipeline? Not all of the computation runs on the GPU; parts execute on the host CPU, where vendor-specific code paths can give slightly different floating-point results. We have not pinned down which operator picks up the difference.
The difference is real, small, and always the same
We subtracted a Class B image from the Class A original, pixel by pixel (1024×1024 RGB):
| Measure | Value |
|---|---|
| Pixels that differ at all | 948,024 of 1,048,576 (90.41%) |
| Mean difference of those pixels | 2.793 / 255 |
| Largest single-pixel difference | 164 / 255 |
| Amplification needed to see it | 20× |
Almost every pixel moved, and almost every pixel moved by a whisker. At 1× we could not tell the two apart side by side; amplify the difference 20× and a faint outline of the picture appears. Because Class B is one fixed image, it is the same faint outline on every Intel host we measured.
What this data does not show
- The claim needs both conditions: same GPU model and same CPU vendor gave a byte-identical image. In a separate run, two different GPU models (RTX 3090 and RTX A5000 — same memory size, same architecture generation) gave different images; that run changed the CPU vendor too, so it only shows the claim can't be widened to "same memory size" or "same architecture".
- 0.981439 belongs to this workflow on this GPU model, not to every setup.
- The original machine's CPU was not recorded when the original image was made; that it belongs to the AMD class is inferred from byte identity. Our probes record the CPU model now.
- Video pipelines are not settled by this data.
- Five hosts make a clean argument, not a proof across all hardware.
What Renest guarantees, and what it doesn't
This is why we word the guarantee the way we do. When you restore a nest, every file is checked against its checksum — a mismatch names the file. A bit-identical regenerated image is not a guarantee, because it depends on hardware the nest doesn't contain.
What the data does give you is predictability. If pixel-exact output matters, rent a machine with the same GPU model and the same CPU vendor as the one you packed on. If you can't match the CPU vendor, expect a small, fixed difference rather than a random one.
You can check this on your own setup: after a restore, renest verify <manifest> --dir <folder> --check image --render starts the restored app, runs the recorded workflow once and compares the picture with the one saved when the nest was packed (it asks before using the GPU). See three gates, not an exit code for how restores are judged.