Proof

Field notes: storage, GPUs, prices.

Put your bucket near the machines you pack from, because uploads slow down with distance and downloads barely do. Rent in quiet hours, keep a list of acceptable GPU models instead of waiting for one card, and avoid a GPU a generation newer than the one you packed on. These are field notes from paid runs on 14–15 July 2026, with every number dated and its conditions stated.

What these notes are. A dated report, not a guarantee. Unless a line says otherwise, every number below was measured on 14–15 July 2026, on RunPod and vast.ai, with a minimal test nest (ComfyUI + SDXL, 6.5 GB, one model, no custom nodes) over 40-odd paid runs. Clouds, prices and the product have moved since, and a real workflow with many nodes and LoRAs can behave differently. The full rows, failures included, are in the field reports (vol. 1, vol. 2, vol. 3). Current results are on the Proof page.

Put your bucket near where you pack; restores are far less sensitive to distance

Rule of thumb: put the bucket near the machines you usually pack on, and don't worry much about where restores happen.

• Packing (upload) is distance-sensitive. In July 2026, from a European machine, uploading to a bucket on the same continent ran at 1069 Mbps and to an Oceania bucket at 239 Mbps, about 4.5 times slower.
• Restoring (download) showed no link to distance. In the same runs, downloads went over the storage provider's global network: one US machine (Texas) pulled 257–332 Mbps and another (Georgia) 375–804 Mbps from buckets on five continents, and the Georgia machine was fastest from the farthest bucket.
• Asia-Pacific data is thin, and two hosts there contradicted each other. A nearby bucket won't hurt; whether it is meaningfully faster, we don't have the data to say.
• The tool downloads each large file over 8 parallel ranged connections. In the July runs that was 2.3 to 9.3 times faster than a single connection, peaking at about 5 Gbps, which makes bucket location matter even less when you restore.

Rented GPUs were cheapest in quiet hours, and a busy window can cost several times more

One direct observation. Treat it as a hint, not a law.

• On one weekday in July 2026 we hit a window, 17:17–17:39 Beijing time (a European afternoon), where every cheap card sold out across the market. The clearing price for the same GPU rose to 1.6–4 times the quiet-hour price ($0.74/hr against $0.17–0.46/hr).
• Asian early morning to European late night (06:00–14:00 Beijing time) had the loosest supply and the lowest prices; most of our runs landed there.
• Suggestion: schedule packing and test restores that aren't urgent for quiet hours. When a busy hour leaves no cheap cards, don't queue; try another cloud. A nest isn't tied to one provider, and the pre-flight check tells you whether the new machine can run it.

Price reference, 14–15 July 2026. The same RTX A4000 cleared at $0.076/hr at the low end (vast.ai, Japan) and $0.74/hr at the high end (RunPod, Europe, busy hour), nearly ten times apart. One cross-cloud restore of the 6.5 GB test nest cost $0.014 and took about 7 minutes. Picking your hour and region can save more than a year of storage costs.

Pick from a list of GPU models, and don't restore on a newer generation than you packed on

Four findings, each from the July 2026 runs:

1. Getting a machine at all was the hard part. With a low hourly price cap, most of our rental attempts over the two days never got a machine: every miss was "no stock" or "price jumped". Once a machine was granted, it was ready in about 30 seconds (15 to 38 seconds across the runs). So keep a list of acceptable GPU models plus a price cap, instead of waiting for one exact card.
2. Same GPU model and same CPU brand gave identical images in our test. With the 6.5 GB SDXL test nest, a machine with the same GPU model and the same CPU brand (Intel or AMD) as the packing machine produced images that matched the originals pixel for pixel. When only the CPU brand differed, images carried a small, invisible difference (SSIM about 0.98) that was exactly the same on every run, so it is deterministic rather than noise. Across the Intel and AMD hosts we compared, in different countries and on driver versions from 550 to 595, that difference followed the CPU brand, not the driver. On 15 July 2026, a 23 GB video nest (480p, 17 frames) run again on the same GPU model, across continents, clouds and driver versions, produced a video file with the same checksum as the original.
3. A different GPU model gave small but stable differences, even within a generation. The same video nest, packed on an A5000 and run again on an A10 (same generation) and on an RTX 4000 Ada (one generation newer), came back with every file matching and the recipe unchanged, and the regenerated video sat at an SSIM of about 0.94 against the original, evenly across frames rather than getting worse along the video. Each card was one run. For pixel-exact work, go back to the original GPU model; to simply keep working, switching cards is fine.
4. Don't restore on a GPU a generation newer than the one you packed on. Too-new silicon (Blackwell, in July 2026) couldn't run the older PyTorch pinned at packing time: the files checked out, and rendering failed. Renest now catches this before it costs you: point renest doctor at the nest's manifest from your laptop, and the pre-flight check in renest restore refuses that pairing outright. Picking by hand, avoid the newest flagships.

Where these numbers come from

The minimal test nest (6.5 GB) and 40-odd paid runs over 14–15 July 2026 on two clouds (RunPod, vast.ai), with machines in the US, Canada, Sweden, Romania, Japan, Czechia and Poland; the video findings come from one 23 GB nest measured on 15 July 2026. Asia-Pacific samples are small, so treat those lines as provisional. Full rows, including failures, are in the field reports linked at the top.