A seed does not name a picture. It names a place to start rolling.
A seed does not name a picture. It names a place to start rolling.
The number is real and it does something. It just does not do the thing most people think it does.
Somebody posts a render you love. You ask for the settings. They hand over the whole recipe, prompt, model, sampler, scheduler, steps, guidance, and the seed. You paste all of it in, hit generate, and out comes a picture that is recognisably in the same neighbourhood and definitely not the same photograph. Now you are staring at the screen wondering which field you typed wrong.
Probably none of them. The seed did exactly what seeds do. What it does not do is what the shorthand promises.
ComfyUI's own description of the KSampler seed field is one clean line: it is "used to generate random noise," and "using the same seed generates identical images." That sentence is completely true and it carries a silent condition on the end, which is that everything else generating those random numbers has to be identical too.
Go one layer down to the library doing the actual work and the promise disappears. PyTorch's reproducibility notes open with a sentence that a lot of people have never read: "Completely reproducible results are not guaranteed across PyTorch releases, individual commits, or different platforms." Not discouraged. Not usually fine. Not guaranteed.
PyTorch does hand you the controls. torch.manual_seed() seeds the generator for all devices, both CPU and CUDA, which is the piece your interface is calling under the hood when you type a number into the box. Setting torch.backends.cudnn.benchmark = False makes cuDNN pick its algorithm deterministically rather than auto-tuning for speed, and the docs are upfront that you pay for this in performance. There is also torch.use_deterministic_algorithms, which swaps in deterministic implementations wherever they exist and throws an error when an operation is nondeterministic and has no deterministic alternative.
Read that last one again. There are operations where the deterministic version simply does not exist, and the library's answer is to raise an error rather than pretend.
| Situation | Same seed gives you |
|---|---|
| Same machine, same session, nothing touched | The same image, every time |
| Same machine, app updated since last week | Usually the same, no promise |
| Your GPU versus their GPU | Same composition, different pixels, sometimes different everything |
| Same seed, resolution changed | A completely different image |
| Same seed, ancestral sampler | Extra noise injected each step, so less stable |
That fourth row surprises people the most, and Automatic1111's documentation states it flatly: normally, when you change resolution, the image changes entirely, even if you keep all other parameters including seed. It is not a bug and it is not your VAE. A different latent size means a different amount of noise to draw, so the stream gets consumed differently from the first step onward.
Tucked behind the Extra checkbox next to the seed field sit a Variation strength slider and a Variation seed field. The documented behaviour is a blend: crank strength to maximum and you get the picture belonging to the variation seed, drop it to minimum and you get the picture belonging to your original seed, and everything between is a controlled slide from one to the other. Ancestral samplers are the noted exception, because they keep adding noise as they go.
This is the tool for the moment when a render is almost right. Instead of rerolling and losing the composition you liked, you hold the original seed, set a variation seed, and creep the strength up in small increments until the thing that was bothering you resolves.
The same panel carries seed resize, which exists specifically to solve the problem in row four of that table. You tell it the resolution the seed was originally found at, and it works to produce something visually similar at your new dimensions. It is not a guarantee and the docs do not sell it as one. It is a great deal better than rolling seeds blindly at the new size hoping to stumble back into the framing you already had.
ComfyUI puts a small dropdown under the seed with four options: Random, Inc, Dec, and Keep. It decides what happens to the number after each run. Random is the default and it is why the thing you liked twenty minutes ago is gone. Keep freezes the seed so you can change one other setting and see what that setting alone did. Inc and Dec walk the seed by one each time, which gives you a tidy neighbourhood of nearby renders rather than a scattershot across the whole space.
Somebody reasonable will read all this and say the practical experience contradicts it, because they share seeds with friends constantly and the images match. That is often true, and it is worth understanding why rather than dismissing it. Two people running the same app version, the same checkpoint file, the same sampler and the same resolution on similar hardware are running an extremely similar computation, and similar computations on a pseudo-random stream usually land in the same place. The determinism holds far more often than it breaks.
What it does not have is a guarantee, and the guarantee is the part people rely on when they treat a seed like a catalogue number. The moment somebody updates a library, switches cards, or crops to a different aspect ratio, the whole arrangement quietly stops holding, and there is no error message to tell you. The picture just comes out different and you go hunting for a setting you never changed.
Stop thinking of the seed as a name for a picture. Think of it as a starting position in a very long roll of noise. Your prompt, model, sampler, scheduler, step count and resolution are the machine that turns that noise into an image. The seed decides where the machine starts. Everything else decides what the machine does. Change the machine and the same starting position produces a different result, which is not mysterious at all once you stop expecting the number to carry information it never held.
Next time somebody hands you a seed and the render comes out different, check the resolution first, then the app version, then the sampler. The seed is almost never the thing that was wrong.
The KSampler seed description, the control_after_generate options and the denoise, cfg, sampler and scheduler behaviour were read today from ComfyUI's own built-in node documentation. The reproducibility guarantee, torch.manual_seed covering both CPU and CUDA, the torch.backends.cudnn.benchmark tradeoff and torch.use_deterministic_algorithms raising errors on nondeterministic operations were read today from the PyTorch randomness notes. The variation seed and variation strength behaviour, the ancestral sampler exception, the Extra checkbox location and the seed resize description were read today from the Automatic1111 features wiki. Nothing here is quoted from memory, and no claim about how a specific GPU model behaves is made anywhere on this page, because that was not tested.