News for hackers. Stuff that matters.
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.
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)
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