When the exact same bytes score differently

Upload the exact same file to the same tool twice, back to back, and you might reasonably expect the exact same score both times. A trained model's weights do not change between the two calls, and the input bytes are identical, so in principle the output should be too. In practice, several ordinary parts of how models are served can break that expectation, and none of them mean anything is wrong.

Why floating-point order matters

GPUs run operations across many parallel threads, and the order in which partial results get summed is not always fixed across runs. Floating-point addition is not strictly associative - (a + b) + c can differ from a + (b + c) by a tiny amount, in the last few bits of precision, because each intermediate sum has to round to the nearest representable value. For a single number this difference is invisible. Propagated through millions of operations across dozens of layers, it can nudge a final output by a small but measurable amount, occasionally enough to move a rounded score by one unit at a boundary.

This is a property of how GPU hardware parallelises arithmetic, not a bug in any particular model, and it is well documented in machine learning infrastructure more broadly.

Why batching changes the answer

Serving infrastructure rarely runs one image through the model in isolation. For efficiency, incoming requests are grouped into batches and processed together, and which other images happen to be in your batch can, in some implementations, affect the exact numerical path your image takes through the network - not through any interaction between images at the level of what the model "knows," but through implementation details like padding, batch normalization statistics computed per batch, or how the batch is split across hardware. Two calls with the same image can land in differently composed batches and take a slightly different numerical route to the same intended answer.

Why preprocessing can be the real culprit

The most common source of visible non-determinism is not the model at all - it is preprocessing left in a mode meant for training rather than for serving. Random crops, random flips, and other data augmentation exist specifically to vary the input during training. If a deployment pipeline accidentally leaves any of that switched on at inference time, the model is not seeing the same input twice even though the uploaded file is identical, and the resulting score difference is not the model being inconsistent - it is the preprocessing step quietly changing what got fed in.

Making inference deterministic

This is fixable, and the fixes are well known: pin the framework to deterministic algorithm modes, fix the random seed, disable any augmentation at serving time, and control batch composition so it does not depend on unrelated concurrent traffic. Doing all of this typically costs some throughput, because deterministic GPU kernels are often slower than the default parallel ones, which is why not every service bothers. Rate Cock runs scoring through a fixed, deterministic inference path for this reason, so a repeated upload of the same file is a genuine test of the model rather than a test of infrastructure noise.

What this is not

This is a narrower claim than why the same subject scores differently across a photo session, which is mostly about you changing the input - angle, light, distance - between shots. It is also a different mechanism from temperature in a language-model scorer, which is deliberate sampling randomness rather than an infrastructure artefact. If you want to test whether a tool's inference is genuinely deterministic, the same bytes twice is the right experiment; if you want to know how much a photo itself can move a score, running a proper controlled comparison is the right one, and neither substitutes for the other. Repeating the same upload and watching the number hold steady is also the simplest version of the reliability check Penis Rater recommends before trusting any single result. A human reviewer's inconsistency has a different shape entirely, drifting with mood and attention rather than GPU rounding, and how that kind of drift compares to a machine's fixedness is worth reading as the direct counterpart to this piece. None of this applies to a physical measurement in the first place - Measure My Cock's numbers come from a tape, not an inference call - and it is one more axis on which a model differs from a human reviewer, whose form of inconsistency has entirely different causes and, unlike GPU rounding, cannot be engineered away.