Production
The seed is not why you get a different video twice
Two identical requests differ because the endpoint was busier the second time. The seed is the one term in that product you actually control.
Thinking Machines Lab sent one prompt to one model 1,000 times at temperature 0 in September 2025 and got 80 different completions back. Nothing in the request changed between them. The outputs were identical for the first 102 tokens and split at the 103rd, where 992 of them wrote Queens, New York and 8 wrote New York City. The seed was not the cause, and the temperature could not have been, because it was zero. The cause was how busy the server happened to be, which sets how many requests are batched together, which sets the order the additions inside the kernel run in. Fix the seed all you like. It is not the term that moved.
The claim is not a forum myth, it is in vendor documentation
Adobe's developer documentation for Firefly seeds spends two sentences on it and hedges in neither. Computer programs are completely deterministic, so they cannot create true randomness. Using the same seed, prompt, and other presets, would generate the same image every time. Search that page for the words batch, load, server or GPU and you get nothing. The whole workflow it describes depends on re-sending a seed that the job status JSON hands back per output.
Hugging Face's Diffusers documentation ends on the opposite sentence: you can try to limit randomness, but it is not guaranteed even with an identical seed. The goal it sets is the same result each time across releases and platforms within a certain tolerance range. Within a tolerance range, not bit for bit: close enough that a regression test passes, which is not the same file twice.
The vendors selling video hedge inside the parameter description. Google's Veo page calls SEED_NUMBER a value the model uses to generate deterministic videos, then says specifying it without changing other parameters guides the model to produce the same videos. Guides. The word deterministic appears exactly once on that page, there. OpenAI's cookbook has said since 6 November 2023 that its system makes a best effort to sample deterministically, and ships a second field, system_fingerprint, to tell you when the backend moved under you.
The load on the endpoint is the dominant term, and it is not in your request
The clearest statement of the mechanism is Thinking Machines Lab's, published 10 September 2025: the load determines the batch size that the kernels are run under, and thus changes the eventual result of each individual request. The general form: compose a property under which the kernel is not invariant, the batch size, with nondeterminism of that property, the load the server is under, and you get a nondeterministic system.
Underneath that is arithmetic, not machine learning. Floating point addition is not associative, so the order of a sum changes the sum. Take an array of four values and their four negations, shuffle it 10,000 times, and there are 102 possible different results for summing those 8 numbers. PyTorch's reproducibility page says the same of attention: bitwise matching numerics across different scaled dot product attention backends are not guaranteed, even for the same inputs and dtype, because each backend accumulates in a different order.
So the variable deciding your output is other people. Thinking Machines put the reader's position exactly: from the perspective of an individual user, the other concurrent users are not an input to the system but rather a nondeterministic property of the system. Set that beside the glossary a founder lands on. Morphic's entry lists four things that can affect exact reproducibility, model updates, platform infrastructure, floating point precision across hardware and ancestral samplers. How many requests were in flight when you pressed the button is not among them.
The other people using the endpoint are not an input to your render: they are a property of the machine you rented.
Chain as described by Thinking Machines Lab, 10 September 2025, and confirmed independently by LMSYS Org on SGLang, 22 September 2025. Both measured language model serving, not a video endpoint, and no published measurement of the same effect on a commercial video endpoint exists. Each stop names what varies at it, not what it costs.
The popular culprit, parallel addition on a GPU, is the wrong one
The story everybody repeats is that GPUs add numbers in a racy order, and that is why nothing reproduces. Thinking Machines killed it in the same post: running the same matrix multiplication on the same data repeatedly will always provide bitwise equal results, and concurrency and atomic adds end up being completely uninvolved, because the forward pass involves no operations that require atomic adds. Four statements hold at once. Some kernels on GPUs are nondeterministic, every kernel in the forward pass is deterministic, and the inference server can be called deterministic too. From the perspective of anybody using it, the results are not.
Where hardware does enter is narrower than the folklore. NVIDIA's cuBLAS documentation promises bit wise identical results at every run only from a given toolkit version, on GPUs with the same architecture and the same number of streaming multiprocessors, and says the guarantee no longer holds when multiple CUDA streams are active. Two cards of one generation with different SM counts are outside it. So is a CUDA upgrade you did not perform, on a fleet you do not own.
Somebody has audited that documentation rather than trusting it, and it came back incomplete. Shanmugavelu and colleagues swept operation hyperparameters over 10,000 runs on an H100 and reported that documentation on which functions in PyTorch are deterministic may be erroneous or incomplete, highlighting the large burden placed on end users. They hit a runtime error trying to get a deterministic result out of an operation the docs list as controllable. The worst movement they measured was 5.03 in units of ten to the minus six, on index_add. Small is enough: one different bit at step one is a different frame by step fifty.
Fix the seed, fix the batch size, and the number of GPUs still moves the answer
The strongest measurement here starts with the seed already nailed down. Zhang and colleagues, in a paper updated 29 May 2026, evaluated reproducibility under random sampling with fixed random seeds and decoding parameters, because that is what real usage looks like. Each prompt ran under 12 runtime configurations: batch sizes of 8, 16 and 32, crossed with tensor parallel sizes of 1, 2, 4 and 8. On AIME24, Qwen3-8B averaged 12.00 unique outputs and Mistral-7B-Instruct 12.00, the maximum the design allows.
Not every model hit its ceiling. Llama-3.1-8B-Instruct averaged 9.60 of the 12 available on AIME24, and on the AMC23 prompt set the highest of the four models was 11.08. Qwen3-32B, run under 9 configurations rather than 12, averaged 9.00, its own maximum.
Batch invariant kernels alone do not close it. They bring Qwen3-8B from 12.00 to 7.87, and only the paper's tree based kernels reach 1. The footnote is the part a caller cannot act on: outputs produced under one GPU and under two GPUs are not identical to each other, even with batch invariance in place. Nothing in your request says how many GPUs the model is sharded across today.
The fix has a published price, and the two teams who measured it disagree. LMSYS Org reports most slowdowns ranging from 25 to 45 per cent, averaging 34.35 per cent across the FlashInfer and FlashAttention 3 backends, with a before and after that is stark: 18 distinct outputs from 50 identical requests at a prefix length of 2,048 in normal mode, and 1 in deterministic mode. Zhang and colleagues put their overhead at 22 to 63 per cent. LMSYS also attributes a 61.5 per cent overhead to Thinking Machines, who never print it: their table gives 26 seconds for default vLLM and 42 with an improved attention kernel, and 42 divided by 26 is where 61.5 comes from.
Revision cost is the number a marketer feels
Ask what a render has to be for the same request to return the same answer, and the reply is a list nobody has time for. VBench-2.0 pins its initial random seed at 42 to make comparison fair, then also pins the official inference code, the frame count, the resolution and the frame rate. Its note on cost says why nobody re-runs anything casually: HunyuanVideo and CogVideoX-1.5 take over five minutes per sample on 8 A100 GPUs, HunyuanVideo at 129 frames of 720 by 1280 and 24 frames per second.
Morphic's glossary says seeds are used in client presentation workflows to regenerate approved outputs on demand. That is a promise about approvals, and it is the one that breaks first. If frame 400 moves because you changed a word on frame 12, every approval already banked is void, and the review restarts on a clip costing five minutes of eight A100s an attempt. OpenAI concedes it structurally: its answer to iteration is an edits endpoint that reuses the original structure, continuity, and composition.
One honest limit. Every measurement above, the 80 completions, the 12 configurations, the 18 of 50, was taken on language model serving, because that is where the work has been done. A video diffusion model runs the same non associative floating point reductions on the same rented hardware, so the arithmetic is the same arithmetic, but no published measurement of the effect on a commercial video endpoint exists.
Which is the argument for a pipeline rather than one model, in a line: a step whose output is a file can be approved once and reused, and a step whose output is a sample from a busy endpoint cannot. A script is text. A read is a recording. Frames assembled from HTML and CSS are the same frames tomorrow, so a word changed on frame 12 leaves frame 400 alone.
A seed is a pointer into a model version, a GPU fleet and a load level, and only one of those three is written down anywhere.
Thinking Machines Lab, Defeating Nondeterminism in LLM Inference, 10 September 2025. The horizontal axis is token position, drawn to scale from token 0 at the left to token 1,000 at the right, so the shared segment really is that short.
What to do about it
- Stop treating a differing re-render as a prompt bug. Record the model version and the vendor's own backend fingerprint first, and check those before you rewrite anything.
- Approve files, not seeds. Whatever a client signs off has to be the artefact itself, because a seed only buys a request to generate it again.
- Never compare two prompts on one sample each. On a fixed seed, 12 runtime configurations produced 12 different answers on two of the four models tested, so a pair of clips measures the queue.
Questions people actually ask
does setting a seed guarantee the same video twice?
No. In the clearest published test of it, 1,000 identical requests at temperature 0 returned 80 different completions, because the batch size the kernel runs at changes with the load on the endpoint. Vendors word this carefully: Google's Veo docs say a seed guides the model to produce the same videos, and OpenAI's cookbook says its system makes a best effort to sample deterministically. Neither says guaranteed.
why do i get different results with the same seed and the same prompt?
Because how many other requests are being served alongside yours sets the batch size, the batch size sets how the kernel splits its reductions, and floating point addition is not associative, so a different order gives a different sum. There are 102 possible results for summing one array of 8 numbers depending on the order alone. The seed is identical in both runs and is not the term that changed.
does running on the same gpu make ai generation reproducible?
Not by itself. NVIDIA's cuBLAS documentation promises bit wise identical results only within one toolkit version, on GPUs of the same architecture and with the same number of streaming multiprocessors, and withdraws the guarantee when multiple CUDA streams are active. A paper updated 29 May 2026 found that even with the seed fixed, 12 runtime configurations of batch size and tensor parallel size produced an average of 12.00 unique outputs on two of the four models tested.
how much slower is deterministic inference?
Between about a quarter and two thirds slower, depending on who measured. LMSYS Org reports slowdowns of 25 to 45 per cent with an average of 34.35 per cent on FlashInfer and FlashAttention 3, and Zhang and colleagues report 22 to 63 per cent total overhead for their approach. In exchange, the same 50 identical requests that gave 18 distinct outputs in normal mode gave 1.
can i regenerate an approved ai clip months later from its seed?
Only while the exact model is still running, which is not a safe assumption: OpenAI has published 24 September 2026 as the shutdown date for Sora 2 and the Videos API, and a seed recorded against a retired model has nothing to run against. Keep the rendered file as the approved asset. For a small change, an edit endpoint that reuses the original structure, continuity, and composition preserves more than a fresh generation does.
Sources
- Thinking Machines Lab, Defeating Nondeterminism in LLM Inference
- LMSYS Org, Towards Deterministic Inference in SGLang and Reproducible RL Training
- Zhang et al., Deterministic Inference across Tensor Parallel Sizes That Eliminates Training-Inference Mismatch, arXiv:2511.17826
- PyTorch 2.13 documentation, Reproducibility
- NVIDIA, cuBLAS documentation, Results Reproducibility
- Shanmugavelu et al., Impacts of floating-point non-associativity on reproducibility for HPC and deep learning applications, arXiv:2408.05148
- OpenAI Cookbook, How to make your completions outputs consistent with the new seed parameter
- Google Cloud, Generate videos from text prompts
- Adobe, Understanding Firefly API Seeds
- Hugging Face, Diffusers documentation, Reproducibility
- OpenAI, Video generation with Sora
- Zheng et al., VBench-2.0: Advancing Video Generation Benchmark Suite for Intrinsic Faithfulness, arXiv:2503.21755
- Morphic, AI Video Glossary: Seed
Every figure on this page comes from one of these. Where two of them measure the same thing differently, the article says so rather than picking the flattering one.