Seeds and reproducibility: re-running a generation
What a seed pins down, what it does not, and how to keep a usable revision trail.
A seed is the shuffle order of a deck. Give a dealer the same deck, the same shuffle order and the same rules, and the same hand comes out every time. Change the shuffle and the hand changes. Change the deck, or hand the cards to a different dealer with slightly different rules, and the same shuffle order no longer means anything. Generative models work this way: the seed sets the starting noise, and everything downstream is a deterministic march from that noise.
The mechanism is a pseudo-random number generator. In Diffusers you pass a seeded generator object rather than an integer, and the same seed with the same pipeline reproduces the same output. Two details bite people. The generator carries state that is consumed as it is used, so reusing one object inside a loop gives different results on each pass and you have to re-seed for each call. And CPU and GPU generators differ, which is why the library creates noise tensors on the CPU before moving them to the device and recommends a CPU generator when reproducibility matters.
Determinism has a hard boundary, stated plainly in the PyTorch note the Diffusers documentation quotes: completely reproducible results are not guaranteed across PyTorch releases, individual commits or different platforms, and results may not be reproducible between CPU and GPU executions even with identical seeds. Diffusers offers a full-determinism switch that disables convolution benchmarking and reduced-precision matrix operations, at a cost in speed, and still frames the guarantee as within a tolerance range.
Hosted APIs add the version problem. The Sora report itself shows samples generated with fixed seeds and inputs at different points in training: same seed, different model, different picture. A seed identifies a draw from a specific model, not a picture.
Log every generation as if you will be asked to change one word in nine months, because you will be. Prompt, negative prompt, seed, model name and version string, scheduler, step count, guidance value, resolution, frame count, and the file hash of every conditioning image, reference and adapter. On a job with a long revision tail, that log is the argument for pinning an open-weight model locally rather than trusting a hosted endpoint to still exist at the same version. Where you cannot pin, deliver the frames and the project file, not a recipe.
What people get wrong
Each of these is a belief worth dropping, followed by what is actually happening.
- the same seed gives the same picture. The same seed gives the same picture only with the same model version, parameters and, in practice, the same hardware and library stack.
- a seed is a style or a look. It is an index into the noise the process starts from; it correlates with composition and framing for a fixed prompt, but it carries no meaning that transfers to a different prompt or model.
- reusing the same generator object in a batch loop pins the result. Generator state is consumed as it is used, so each call in the loop draws different noise unless you re-seed before every call.
- enabling deterministic algorithms makes runs bit-identical everywhere. Deterministic modes remove specific sources of variation and cost throughput, while the underlying framework still refuses to guarantee identity across releases, commits or platforms.
- keeping the prompt is keeping the revision trail. Without the model version and every parameter, a saved prompt reproduces a family of images rather than the shot that was approved.
Terms this introduces
- Seed
- The integer that initialises the pseudo-random number generator producing the starting noise for a generation.
- Generator
- The stateful random-number object a pipeline draws from, which must be re-seeded per call to repeat a result.
- Determinism
- The property that identical inputs produce identical outputs, which in practice holds only within a fixed software, hardware and model configuration.
- Version pinning
- Fixing the exact model checkpoint and library versions used for a job so it can be rerun later.
- Generation log
- The record of prompt, seed, model version, parameters and conditioning asset hashes needed to reconstruct a delivered frame.
Where this shows up in the directory
Models whose own documentation names this. It is evidence the vendor considers it relevant, not a judgement that the model is good or bad at it.
Whose job this changes
Craft roles whose page discusses this directly. Follow one to see what the person actually decides.