Your LLM results may not replicate

Temperature zero does not make an LLM pipeline reproducible. Most empirical researchers I talk to believe the opposite: set the temperature to zero, and you get the same answer every time.

I wanted to test that. So I ran a simple experiment. I took six paragraphs from Tesla’s FY2025 10-K, the one filed in January 2026. The full filing is long, but each API call saw only one extracted paragraph, not the whole 10-K. I asked GPT-5.4-mini to classify each paragraph as containing a forward-looking climate risk disclosure or not. Temperature 0, fixed seed, identical prompt, 50 runs per paragraph. Three hundred API calls total. About four cents.

Five of the six paragraphs came back identical every single time. The sixth did not. In one run, a paragraph about Tesla’s Supercharger network and its co-location with solar and energy storage systems flipped from YES to NO. Forty-nine runs said one thing. One run said the opposite. Same model, same prompt, same parameters, same paragraph.

One flip out of 300 calls sounds small. But the flip happened on the one paragraph where the classification was hardest to make. In a research pipeline with 50,000 disclosure paragraphs, the question is how many of your observations sit on that same kind of boundary. It could be dozens. It could be thousands. You won’t know unless you check, and temperature=0 won’t tell you.

. . .

What temperature actually controls

Here is the entire job description of the temperature parameter. The model produces a vector of numbers, one per token in its vocabulary. These are called logits. Temperature divides each logit by a scalar before converting them into probabilities.

A temperature of 1.0 leaves everything alone. A temperature of 0.5 sharpens the distribution. The top token becomes more dominant. A temperature of 0 collapses the whole distribution to a single point: pick the token with the highest logit. Always. No randomness.

That last part sounds like determinism. It isn’t.

Temperature=0 makes the sampler deterministic. Given this vector of logits, always pick the biggest one.

But temperature says nothing about how those logits were computed in the first place. The model runs a long chain of calculations to produce them, and that chain can return slightly different numbers from one run to the next. When it does, the top token can flip. And once one token flips, the rest of the sequence follows a different path, because each new token depends on everything generated before it.

So temperature=0 is like locking the steering wheel straight on a car whose alignment drifts. You’ve removed one source of variation. The car still won’t drive straight.

There is a second, separate issue with temperature 0 that I am not studying here. For tasks that rely on sampling and aggregation, greedy decoding can lower accuracy and even change benchmark rankings. That is a performance question. My question is narrower: even when temperature 0 is the right setting, it still does not guarantee the same answer twice.

. . .

The real problem is under the hood

The folk explanation for LLM non-determinism usually waves at GPUs and floating-point math, as if the hardware is random. That is too vague. Horace He and a team at Thinking Machines Lab laid out the more specific mechanism in September 2025.

Floating-point arithmetic is deterministic for a fixed computation. If you multiply the exact same two matrices on the exact same GPU with the exact same kernel, you get the exact same answer. The Thinking Machines post demonstrates this: 1,000 repeated matrix multiplications, bitwise identical every time.

The problem is that production inference servers don’t run a fixed computation. They batch your request with other users’ requests to keep the GPUs busy. In practice, the server waits a few milliseconds, stacks whatever prompts arrived in that window into one tensor, and sends the whole stack through the model in a single GPU pass. And the batch size changes how the math is done. Not the answer in exact arithmetic, but the answer in floating-point arithmetic, where the order you add numbers matters.

Here is the first-principles version. IEEE 754, the standard most computers use for floating-point numbers, obeys commutativity (a + b = b + a) but not associativity ((a + b) + c ≠ a + (b + c)). The post shows that an array of just 8 numbers, summed in 10,000 random orders, produces 102 distinct floating-point results. They’re all close to zero. But they’re not the same bits.

Now scale that up. A single pass through a large language model involves billions of additions and multiplications chained together. To go fast, the GPU does not add them all in one stream. It splits the work into chunks, adds up each chunk, then combines the chunks. How it splits the work depends on the batch size: a batch of 1 gets divided one way, a batch of 2,048 another. Same arithmetic, different order of addition, and so a different last few bits in the logits.

As an API user, you can’t see or control the batch size. It depends on how many other people are using the service at the same time. So in many production systems, the logits you receive can depend on backend execution choices that you cannot observe or control.

Horace He puts it simply: the primary reason nearly all LLM inference endpoints are non-deterministic is that server load varies non-deterministically. This isn’t a GPU quirk. CPU-served and TPU-served models have the same issue.

. . .

It gets worse with mixture-of-experts

Some of the largest models today use a mixture-of-experts (MoE) architecture. Instead of feeding every token through the entire network, MoE models route each token to a subset of specialized “expert” sub-networks. That’s great for throughput. Less great for determinism.

In many MoE implementations, experts have capacity limits. If too many tokens in a batch want the same expert, some get bumped to their second-choice expert or dropped from expert processing entirely. Which tokens win depends on what else is in the batch. In these implementations, your sequence’s computation can be coupled to other sequences in the same batch.

A blog post from 2023 argued that this is the dominant cause of GPT-4’s non-determinism, though the Thinking Machines Lab work two years later points to batch-invariance failure in standard kernels as the larger factor, with MoE routing compounding it. The evidence is circumstantial, since OpenAI hasn’t officially confirmed the architecture. But the pattern fits.

In the Thinking Machines experiment, Qwen3-235B was run with temperature=0 on the same prompt 1,000 times and produced 80 unique completions. All 1,000 agreed on the first 102 tokens. Then the model hit a near-tie, and 992 runs said one thing while 8 runs said another. From that fork onward, the sequences diverged completely.

That pattern matches what I found in my Tesla experiment. The Supercharger paragraph was the borderline case. Tesla describes co-locating Superchargers with solar and energy storage to “promote renewable power.” Is that a forward-looking climate risk disclosure or just a description of current infrastructure? Reasonable people could disagree. So could the same model on different runs.

. . .

How large is this problem?

My experiment used a smaller, lower-cost model on a simple YES/NO task. The variation was real but contained: one flip out of 300 calls. Other tasks and model families suggest it can get much larger.

Atıl et al. (2025) ran five models on eight subtasks drawn from MMLU and BIG-Bench Hard. Temperature 0, top-p 1, fixed seed, 10 runs each. Their headline metric is TARr@10, the fraction of test instances where all 10 runs produced the exact same raw output string.

Some of the numbers are bad. GPT-4o on college math: 0% raw-string agreement across 10 runs. Mixtral-8x7B on the same task: a 72-point gap between the best-possible and worst-possible accuracy across repeated outputs. The observed run-to-run swings were smaller, but still large enough that the same benchmark could report very different scores depending on which run you happened to use.

Khatchadourian and Franco (2025) tested five architectures on financial NLP tasks. GPT-OSS-120B, an open-weight MoE model, achieved 12.5% output consistency at temperature 0 across 16 runs. Qwen2.5-7B and Granite-3-8B, both smaller dense models, achieved 100%.

I don’t read these papers as a perfect match to my experiment. But they rhyme with it. The failures cluster around bigger models, MoE models, longer outputs, and borderline classifications. Azure says the same thing more plainly: identical API calls with larger max_tokens values will generally produce less deterministic responses even when the seed parameter is set.

. . .

What the providers actually say

I went through the documentation from the major providers. None of them promise determinism at temperature 0.

OpenAI’s cookbook shows five repeated calls with the same prompt, same seed, same temperature=0, same system_fingerprint. The outputs were different, with different completion lengths (113, 81, 72, 81, and 74 tokens). Their docs say matching seed, parameters, and fingerprint makes outputs “mostly be identical,” while there remains “a small chance that responses differ.”

Anthropic’s API documentation states that “even with temperature of 0.0, the results will not be fully deterministic.” Claude Opus 4.7 goes further and deprecates the temperature parameter entirely. The API rejects it with an error.

Google says temperature=0 means “responses for a given prompt are mostly deterministic, but a small amount of variation is still possible.”

I also have not folded GPT-5.5 into this comparison. OpenAI describes it as a reasoning model, and the migration guide emphasizes reasoning.effort rather than a simple temperature-zero setup. A GPT-5.5 run would be useful, but I would report it as a separate model-family comparison, not an apples-to-apples extension of the GPT-5.4-mini experiment.

For empirical research, those disclaimers are the whole issue. A 50,000-observation LLM-coded variable is not just another column in a dataset. If identical inputs can produce different labels, that column carries an extra source of measurement error. It is not classical. It is not well-characterized. And in most papers, it is not reported. That bothers me.

. . .

Why finance and accounting researchers should care

Start with replication. If I construct an ESG quality score by feeding sustainability reports into GPT-5.4, and my coauthor runs the same pipeline next month, we may get a different vector of scores. Not because the code changed or the data changed. Because the server was busier on Tuesday than it was on Thursday. The standard practice of reporting “we used GPT-5.4 with temperature=0” is not enough information to replicate a result. It never was.

Then there’s measurement error. Non-deterministic classification adds noise to whatever variable the labels feed into.

If the LLM-coded variable is an input to your regression (an explanatory variable) and the noise is random, you get classical attenuation: coefficients pulled toward zero, reduced power. If it is the outcome you are trying to explain, you mostly lose precision.

The harder part is that LLM classification error probably is not random in the way those textbook results assume. It concentrates on ambiguous text, long documents, and complex disclosures. That makes it correlated with exactly the features you care about. The resulting bias can go in either direction, and you won’t see it unless you look. Even the time of day you run the pipeline could matter, since server load follows predictable daily patterns and batch composition shifts with it.

This matters beyond academia. Firms and regulators are building or buying LLM tools to screen disclosures, flag anomalies, and assess compliance. If the same filing can receive a different risk flag depending on when in the day the system processes it, that creates a basic fairness problem. A firm shouldn’t face different regulatory scrutiny because the GPU happened to batch its filing with a different set of requests.

. . .

Policy implications

Regulators who accept or build LLM-assisted analysis should require a reproducibility audit. Not just “what model did you use?” but the full stack: model version, inference provider, hardware class, framework version, decoding parameters, and evidence of run-to-run consistency. The SEC’s EDGAR filing analysis, the PCAOB’s inspection targeting tools, and any regulator using NLP for supervisory triage should document this. Right now, I don’t think most of them do.

The IAASB is currently developing non-authoritative guidance on applying its standards to AI tools in audit. That guidance should address one distinction explicitly, because practitioners routinely equate “temperature zero” with “deterministic.” These are different things. Audit firms that build LLM-based tools for substantive testing or risk assessment need to demonstrate that the tools give stable results, not just that they set a parameter to zero.

Accounting standard-setters face a subtler version of the same problem. FASB, IASB, and ISSB receive large volumes of comment letters, and there’s growing interest in using LLMs to summarize stakeholder views. If the summarization is non-deterministic, the characterization of stakeholder input could vary across runs. Even small variation can matter when the output is supposed to represent public input. It should be tested and documented.

AI regulation has the same blind spot. Under frameworks like the EU AI Act or Singapore’s Model AI Governance Framework, a high-stakes classifier should have to disclose whether the same case can receive different labels across runs. If a bank uses an LLM to screen loan applications, that is not a minor technical detail. It affects fairness and accountability.

. . .

What to do about it

If you’re a researcher, I’d start here.

Run your LLM pipeline multiple times on a held-out sample and measure the exact-match rate. Report it the way coding papers report inter-rater agreement. If 95% of your labels are stable across runs, say so. If only 80% are stable, say that too.

Then show your main results survive when you swap in labels from a different run, use majority-vote labels across runs, or drop the unstable cases. Treat unstable labels as a measurement problem to disclose and test, not a number to bury.

One caveat on dropping unstable cases: ambiguous text may be exactly where managers exercise discretion or where the construct you care about lives. Report how many cases you drop and whether they differ systematically from the ones you keep. The field has decades of experience handling inter-rater reliability for hand-coded variables. We should apply the same discipline to machine-coded ones.

Pin everything you can. Not just the model name, but the snapshot version (gpt-5.4-mini-2026-03-17, not gpt-5.4-mini). Log the system_fingerprint on every API call. Record it in your replication package. Treat a fingerprint change the way you’d treat switching to a different survey instrument mid-sample.

Consider using a smaller, dense model instead of the biggest available MoE model. The evidence from Khatchadourian and Franco suggests that Qwen2.5-7B achieves 100% consistency at temperature 0 on their financial tasks, compared to 12.5% for GPT-OSS-120B. The bigger model might classify better on average, but if its classifications aren’t stable, the measurement error may eat the accuracy gains. My own results fit that pattern: GPT-5.4-mini held steady on five out of six classification tasks. The one that flipped was exactly the kind of borderline case where the model was least confident.

If you need true bitwise determinism, the simplest path is local inference: rent a single GPU, run an open-weights model like Llama or Qwen at batch size 1 with deterministic CUDA settings, and the problem disappears entirely. For 50,000 binary classifications, that’s a weekend and a few hundred dollars.

If you need higher throughput at scale, self-hosted inference with batch-invariant kernels (available in recent vLLM and SGLang releases) can handle continuous batching with roughly 35 to 60 percent lower throughput. Either way, you own the full stack. Nothing changes under you between runs.

And if you’re reviewing or editing a paper that uses LLM-based measurement, ask the authors: did you run this more than once? What happened?

. . .

So what do I actually take from this? Five of my six Tesla paragraphs came back identical across 50 runs. That’s good news. LLM classification can be stable, and for well-defined tasks with clear decision boundaries, it usually is.

The paragraph that flipped was the one where the classification was genuinely ambiguous, where a human coder might hesitate too. The flip landed exactly where I’d expect instability to show up: on the paragraph closest to the decision boundary. And if your research pipeline has observations sitting on that boundary, some of your labels are a coin toss you didn’t know you were making.

I’m not arguing that researchers should stop using LLMs for measurement. I am arguing that an LLM-generated variable should face the same reliability checks as any hand-coded one. And if the result doesn’t survive a different labeling run, the honest conclusion may be that the effect was too fragile to publish, not that the labels need fixing. Run the pipeline more than once. Report the stability rate. Account for the error. We already do this with human coders. We forgot to do it with machines.