Re:Claude Code Daily Benchmarks for Degradation Tracking
by altcognito on Thursday January 29, 2026 @12:08PM
(#46813034)
Explain this though. The code is deterministic, even if it relies on pseudo random number generation. It doesn't just happen, someone has to make a conscious decision to force a different code path (or model) if the system is loaded.
[ Parent
| on HN ]
Re:Claude Code Daily Benchmarks for Degradation Tracking
by FL33TW00D on Thursday January 29, 2026 @12:39PM
(#46813527)
It takes a different code path for efficiency.
e.g
if (batch_size > 1024): kernel_x else: kernel_y
Re:Claude Code Daily Benchmarks for Degradation Tracking
by chrisjj on Thursday January 29, 2026 @12:43PM
(#46813587)
Not deterministic. https://thinkingmachines.ai/blog/defeating-nondeterminism-in...
Re:Claude Code Daily Benchmarks for Degradation Tracking
by pertymcpert on Thursday January 29, 2026 @12:44PM
(#46813594)
Floating point math isn't associative for operations that are associative in normal math.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by measurablefunc on Thursday January 29, 2026 @01:11PM
(#46814024)
That would just add up to statistical noise instead of 10% degradation over a week.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by kevin_thibedeau on Thursday January 29, 2026 @01:56PM
(#46814755)
Catastrophic error accumulation can produce more profound effects than noise.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by measurablefunc on Thursday January 29, 2026 @03:33PM
(#46816185)
Just to make sure I got this right. They serve millions of requests a day & somehow catastrophic error accumulation is what is causing the 10% degradation & no one at Anthropic is noticing it. Is that the theory?
Re:Claude Code Daily Benchmarks for Degradation Tracking
by pertymcpert on Monday February 09, 2026 @02:14AM
(#46942454)
FYI something in that region happened last august/September. Some inference bug triggered worse performance on TPUs vs GPU.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by minimaltom on Thursday January 29, 2026 @01:06PM
(#46813935)
Its not deterministic. Any individual floating point mul/add is deterministic, but in a GPU these are all happening in parallel and the accumulation is in the order they happen to complete.
When you add A then B then C, you get a different answer than C then A then B, because floating point, approximation error, subnormals etc.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by bonoboTP on Thursday January 29, 2026 @05:29PM
(#46817717)
It can be made deterministic. It's not trivial and can slow it down a bit (not much) but there are environment variables you can set to make your GPU computations bitwise reproducible. I have done this in training models with Pytorch.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by minimaltom on Thursday January 29, 2026 @06:47PM
(#46818589)
There are settings to make it reproducible but they incur a non-negligible drop in performance.
Unsurprising given they amount to explicit synchronization to make the order of operations deterministic.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by jmalicki on Thursday January 29, 2026 @02:51PM
(#46815621)
For all practical purposes any code reliant on the output of a PRNG is non-deterministic in all but the most pedantic senses... And if the LLM temperature isn't set to 0 LLMs are sampling from a distribution.
If you're going to call a PRNG deterministic then the outcome of a complicated concurrent system with no guaranteed ordering is going to be deterministic too!
Re:Claude Code Daily Benchmarks for Degradation Tracking
by gmueckl on Thursday January 29, 2026 @03:08PM
(#46815860)
No, this isn't right. There are totally legitimate use cases for PRNGs as sources of random number sequences following a certain probability distribution where freezing the seed and getting reproducibility is actually required.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by jmalicki on Thursday January 29, 2026 @04:23PM
(#46816812)
And for a complicated concurrent system you can also replay the exact timings and orderings as well!
Re:Claude Code Daily Benchmarks for Degradation Tracking
by gmueckl on Friday January 30, 2026 @04:35AM
(#46822359)
That's completely different from PRNGs. I don't understand why you think those things belong together.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by bonoboTP on Thursday January 29, 2026 @03:08PM
(#46815856)
How is this related to overloading? The nondeterminism should not be a function of overloading. It should just time out or reply slower. It will only be dumber if it gets rerouted to a dumber, faster model eg quantized.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by joquarky on Thursday January 29, 2026 @08:23PM
(#46819456)
Temperature can't be literally zero, or it creates a divide by zero error.
When people say zero, it is shorthand for “as deterministic as this system allows”, but it's still not completely deterministic.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by forgotTheLast on Thursday January 29, 2026 @10:22PM
(#46820172)
Zero temp just uses argmax, which is what softmax approaches if you take the limit of T to zero anyway. So it could very well be deterministic.
Re:Claude Code Daily Benchmarks for Degradation Tracking
by make3 on Thursday January 29, 2026 @05:17PM
(#46817562)
There's a million algorithms to make LLM inference more efficient as a tradeoff for performance, like using a smaller model, using quantized models, using speculative decoding with a more permissive rejection threshold, etc etc