The Same Seed Does Not Establish the Same AI Result

Identify the random stream and its position

PyTorch 2.14's Generator reference exposes the initial seed separately from state that identifies a particular point in the generator's history. Matching seed fields therefore leaves a useful question open: which state supplied randomness to this request?

For a request sharing a generator with earlier work, prior consumption can change which draw reaches it. Two applications can start with the same seed while a particular request reaches a different position in that stream. A claim about restarting an application with the same input sequence differs from a claim about repeating any request after arbitrary earlier work.

The Reproducibility note also identifies generators outside PyTorch, including independent NumPy Generator objects. Ask which generators the provider's evidence covers and whether it concerns a fresh application start, an isolated request or continuation from retained state. The related training-checkpoint guide explains which application objects were preserved; a saved seed or state alone cannot establish the next accepted application output.

References: [P1][P3]

Read the operation policy and its failure behavior

PyTorch 2.14 defines deterministic algorithms in terms of the same input on the same software and hardware producing the same output. With its deterministic-algorithms policy enabled, documented affected operations use deterministic alternatives where available. For a covered operation with only a nondeterministic implementation, the default behavior is a runtime error. Warning-only mode replaces that error with a warning. A report that execution completed needs that distinction attached.

Algorithm selection adds a separate question. The Reproducibility note describes optional cuDNN convolution benchmarking whose timing noise can change the algorithm selected across runs. Consistently selecting an algorithm does not establish that its execution is deterministic.

The deterministic-algorithms API expressly says its policy alone may not make an application reproducible. Ask what coverage the supplied application actually has, including custom or third-party execution paths. A policy label cannot serve as evidence that every source of variation was covered.

References: [P1][P2]

Keep the environment attached to the claim

PyTorch 2.14's Reproducibility note, updated May 14, 2026, provides no general guarantee of matching results across releases, commits or platforms, or between CPU and GPU execution with equal seeds. Those limits belong to the offer's interpretation.

Have the provider identify the model revision and saved state, input sequence, framework and runtime releases, hardware and relevant numerical settings represented by its evidence. An upgrade or changed platform needs evidence for the required equivalence to the earlier result. Matching the seed does not supply it. The related evaluation-mode and TF32 guides explain other configuration descriptions that belong in that comparison.

References: [P1]

Compare repeated equality with an accepted output

Consider fictional comparison REPEAT3. Three offers claim the same seed and supply two returns for one stipulated input. The reference is [0.8, 0.2]. This invented application accepts a return only when its largest absolute component difference from that reference is at most 0.001. These numbers are stipulated exact decimal values, not rounded tensor printouts, customer measurements or a recommended real-world tolerance.

A supplies [0.8, 0.2] twice. Its supplied values match each other and the reference. Their maximum absolute error is zero.

B supplies [0.79, 0.21] twice. Its returns also match each other, but each differs from the reference by 0.01 in both components. That exceeds the stipulated tolerance. Repeating the same result does not make that result acceptable against this reference.

C supplies [0.8001, 0.1999], then [0.7999, 0.2001]. The largest component difference between its two returns is 0.0002. Each return is only 0.0001 from the reference in either component, so both meet this application's numerical requirement despite differing from each other.

These supplied pairs support the stated comparisons only. They establish neither future determinism for A or B nor a particular RNG, kernel or hardware cause for C's difference. The reference is an agreed comparison target; agreement with it does not establish predictive correctness against real-world ground truth.

Choose the output relationship the buyer actually needs

If the requirement is exact replay for regression or investigation, the provider's evidence needs to address exact equality at a defined output boundary, including the representation when bitwise identity matters. REPEAT3's decimal values supply no binary-encoding evidence. C's unequal pair would fail a requirement for equal repeated values, even though both returns meet the stated reference tolerance.

If the requirement is that numerical tolerance, B's matching pair fails it. If the only stipulated task requirement instead selects the index of the largest component, all three offers return label 0. That task agreement would not erase B's failure when the numerical requirement also applies. State which relationships are required together before treating any comparison as sufficient.

Ask the software provider what result evidence it offers for the chosen relationship: the reference and its purpose, the output boundary, comparison rule, covered inputs and execution conditions, and operation-policy coverage. Keep model state, module behavior and numerical policy attached to that evidence. More configuration detail makes a claim interpretable; it does not supply missing accepted outputs.

Only then does a timing comparison have a defined unit of useful work. The related GPU benchmark guide covers that broader comparison. A repeatable result, an acceptable numerical result and an acceptable task result are different conclusions to establish for the intended application.

Bring selected equipment to a separate installation discussion

If the selected equipment needs physical installation, Leviathan's rack-and-stack service and project inquiry provide a route to discuss agreed mounting, physical IT cabling, labeling and handoff records. Share a nonconfidential equipment, rack and site outline to discuss scope and availability. Runtime evaluation and application acceptance remain with the appointed software team.

References: [L1]