Somebody posts a stunning render with the caption "seed 1234567, steps 30, CFG 7". You copy every number, press generate, and get a different picture. Not slightly different. Different.
Nobody lied to you. The seed was real. It was just never the whole recipe, and treating it like one is why so much prompt sharing quietly fails.
What a Seed Actually Controls
A diffusion render starts from random noise. The seed fixes that noise, so the same seed on the same setup starts from the same place. Everything after the starting point is computation, and computation depends on far more than the seed.
The Diffusers reproducibility guide is candid about this. It recommends a CPU random generator when reproducibility matters, because CPU random numbers are "more stable across machines", and notes that a GPU generator "samples on-device instead and can diverge from CPU results". It ends with a warning worth pinning to your monitor: you can limit randomness, but reproducibility is not guaranteed even with an identical seed.
The Fine Print From PyTorch Itself
The underlying framework says the same thing more bluntly. PyTorch's reproducibility notes open with: "Completely reproducible results are not guaranteed across PyTorch releases, individual commits, or different platforms. Furthermore, results may not be reproducible between CPU and GPU executions, even when using identical seeds."
Read that list again: releases, commits, platforms, CPU versus GPU. Two people with "the same settings" almost never share all of those.
The Full Recipe
| Ingredient | Why it changes the image |
|---|---|
| Model file and version | A fine-tune or a re-upload is a different network |
| Prompt and negative prompt | Exact text, including punctuation and order |
| Sampler and its schedule | "DPM++ 2M" and "DPM++ 2M Karras" take different paths |
| Steps and CFG | Each changes the trajectory, not just the finish |
| Width and height | A different size is a different noise tensor |
| Seed | Fixes the starting noise, and only that |
| LoRAs and their weights | Each one modifies the network |
| Precision | bf16, fp16 and fp32 round differently |
| Hardware, drivers and library versions | Kernels differ; PyTorch says results may too |
The seed is one row of nine. Sharing it alone is like sharing the oven temperature and calling it a recipe.
Why Two GPUs Disagree
It is fair to ask how the same maths on two machines can produce different pictures. The answer is that GPUs are allowed to take different routes to nearly the same number, and diffusion compounds tiny differences over dozens of steps.
The Diffusers guide shows how many switches it takes to pin those routes down. Its enable_full_determinism() helper sets CUBLAS_WORKSPACE_CONFIG so cuBLAS uses a fixed workspace layout, turns on PyTorch's deterministic algorithms, sets cuDNN to deterministic mode, disables cuDNN benchmarking so it "does not pick a different convolution algorithm each run", and disables TensorFloat32 in favour of full-precision matrix maths.
Every one of those settings exists because the default behaviour is allowed to vary. The same guide warns that deterministic algorithms may be slower. Most people, reasonably, choose speed. That choice is fine, as long as nobody treats a seed as a promise it cannot keep.
What This Means in Practice
None of this makes seeds useless. It makes them local. On one machine, with one model file, one software version and every other setting held fixed, a seed is an extremely powerful tool: it lets you change one variable and see only that variable's effect. Across machines, treat a shared seed as a strong hint, not a contract.
We will be precise about our own app here. Vision Studio's engine seeds its random generator on the device that runs the model, the GPU when you have one, which is the faster path. The generator code is public. A practical consequence follows from the guidance above: your seeds are reliable on your machine, and a seed you share with someone on different hardware may not reproduce your image exactly. We would rather tell you that than imply a portability nobody can deliver.
Record the Recipe, Not the Seed
If the full recipe is what makes a result reproducible, the tool should record the full recipe. That is the job of the iteration tree in Vision Studio.
- Every render becomes a node. Its prompt, model, sampler, steps and seed travel with it.
- Fork to branch. Forking starts a new render from a node's settings, so you change one thing on purpose.
- Re-roll to explore. Re-rolling keeps the settings and draws a fresh seed.
- Every child records its difference. Each node stores a settings diff against its parent, so "what changed?" has an answer.
- It survives restarts. The tree is still there tomorrow, which is when you will want it.
When the Result Has to Travel
Sometimes a render genuinely has to be reproduced somewhere else: a client wants a variation next month, or a teammate needs to continue your series. Plan for that instead of hoping for it. Keep the original output file, because the image itself is the only artifact that is perfectly portable. Note the model file and version, not just the model's name. Note the app version and the GPU it ran on. And if exact reproduction truly matters, render the follow-up on the same machine and software that made the original.
None of that is exotic. It is the same discipline photographers apply to raw files and engineers apply to builds: keep the source, record the environment, and do not assume the next machine will agree with the last one.
A Disciplined Loop
- Explore with random seeds until something is close.
- Fix that seed and change one setting per render.
- Keep the lineage. Branch rather than overwrite, so the path back exists.
- When you share, share everything. Model and version, every setting, and the hardware and software it ran on.
Reproducibility Is a Record
A seed feels like a magic number because it is the only number that looks random. The real secret is boring: reproducible work is work that recorded everything that affected it. Make your tools do that recording, keep your seeds for controlled experiments on your own machine, and the mystery of the image that will not come back mostly disappears.
Vision Studio is free, open-source (MIT), and runs locally on your GPU. The iteration tree and its source files are documented at vision-studio-x.com/features. Download it at vision-studio-x.com/download.
-Rocky
#Reproducibility #PyTorch #Diffusers #AIArt #Workflow #OpenSource #VisionStudio