AI software needs different rules for invalid and special numbers

Original research record

We connect fresh changes in vLLM, PyTorch and LLVM. A negative GPU index could select the wrong device, a NaN training setting could pass a check, and a meaningful infinite compiler weight could spoil other features. The new lesson is to decide what each value means before rejecting or transforming it.

We see three distinct failures at the point where software decides whether a number is usable. In vLLM, a negative index into the visible GPU list could select its last device. The new check requires the index to lie inside the allowed range. PyTorch changes the checks for SGD, a training method, so NaN, a value meaning “not a number”, is rejected for three training settings. LLVM needs a different response: it intentionally gives infinite weight to values that must stay in registers, the processor’s small, fast storage. Dividing by that infinity spoiled the features sent to its machine-learning model. The new code maps the special weight to one and leaves it out of the scale used for ordinary weights. We infer that validation must separate an invalid input, a legal language shortcut and a meaningful special value. A single rule for all unusual numbers would miss that distinction.

vLLM tests a visible device list of 4 and 5. An index of -1 now raises an error instead of selecting the last visible device. The checked change applies when an integer index is resolved through a visible-device list; it is not proof of validation for every hardware-selection path.

SGD now rejects NaN learning rate, momentum and weight decay during construction. The new check still accepts positive infinity. We therefore describe this as a NaN fix, without calling it a complete test that every value is finite.

LLVM keeps the meaning of infinite weights while protecting the ordinary features. It excludes infinity when finding their scale, then maps an infinite feature to 1.0. Its regression test checks that no NaN appears in the recorded features.

The sources cover three projects and different code paths. We use them to build a more precise test question, not to estimate an industry failure rate or claim better model accuracy.

We would narrow this view for systems that do not use the affected device-selection, SGD or LLVM model-guided register-allocation paths. The changes do not share one root bug. We have not run the regression suites, verified inclusion in a stable release, or measured production incidents. Later code or a reproduced test could change the stated scope. These selected fixes cannot show whether this kind of failure is becoming more common.

We would write down the accepted meaning of each setting and feature, then test negative values, NaN and infinity separately. Where a special value is intentional, check that converting it does not erase useful differences among normal values. Reject invalid inputs before work starts. We see a concrete validation lesson, with no investment direction or measured savings claim.

This signal has no investible bullish or bearish call. A market-direction percentage does not apply. Bayesian · what changed the estimate? Not applicable as a numerical forecast: we have new code evidence but no fitted prior or likelihood for deployment failures. de Finetti · are the comparisons fair? These three projects and failure paths are not interchangeable trials; we do not pool them into a success rate. Kolmogorov · do the numbers agree? No event partition or forecast percentages are proposed. Consistent code values alone would not establish a calibrated real-world probability. Horizon, price basis and market neutral band: Not applicable. Research gaps: release inclusion, independent test results and deployment outcomes remain unverified.

We join two OTR Database Data research batches. The earlier batch records vLLM’s visible-device index change, committed at 13:01:25 UTC on 8 October. The later batch adds LLVM’s feature-normalization fix at 14:58:41 and PyTorch’s SGD validation fix at 14:59:40. We reopened all three exact commits and read their changed code and regression tests, plus the surrounding vLLM device-selection function. These are three project-specific evidence clusters. Their link is the decision about a number’s meaning before it controls hardware, training or model inputs.

Not applicable to past price moves. Earlier OTR research covered settings lost during request conversion and a beta-zero operation that should ignore an unused input. We retain those records. This new view concerns acceptance and normalization rules: the value may reach the correct place unchanged, yet still be misread there. The new LLVM evidence adds the important case where infinity has a valid role and should be converted carefully.

The primary code sets limits on the thesis. vLLM’s new range check sits inside the visible-device-list branch. PyTorch’s new nonnegative check rejects NaN but still permits positive infinity, so it is not a general finite-value filter. LLVM deliberately uses infinite weights; rejecting every such value would lose a valid instruction. Its fix changes both the special value and the scaling of ordinary values. We have source tests, not independently reproduced outcomes or a measured reduction in failed jobs.

No bullish or bearish direction applies. We add a new explanation built from later OTR Database Data records and three freshly checked source changes. It changes the operational question from whether a value survives a conversion to whether its meaning is valid at the point of use. We have not changed any earlier forecast, reference price, expiry or recorded result.

The code shows narrow failure paths and repairs. We have no representative public-discussion sample, incident denominator or user-cost study. A contributor’s explanation is not evidence that all AI software has the same problem. We keep the practical test lesson separate from claims about rising failure rates, customer losses or demand for a supplier.

No matched set of resolved operational forecasts was found for this thesis. We provide no success percentage. The three projects are selected examples with different conditions, so counting them as repeat trials would be misleading. Market-direction probabilities, price outcomes and investment performance do not apply.

OTR Database Data

https://github.com/vllm-project/vllm/commit/194da61de1769c28bfad2b6642c60cc7eca544dd

https://github.com/pytorch/pytorch/commit/69a425d33532440f99236e48473e2d5bb558277c

https://github.com/llvm/llvm-project/commit/9e01927d0ab198ba32d15fde4e3817819b3865a0

We read both newly assigned Technology findings documents in full and the three raw observation records used by this card. The two raw observation files contain 37 parsed records; parsing is not full semantic review. Other raw observations, coverage logs and the wider database have not all been read in full for this card.

The three cited source diffs and their tests were checked directly. A public-web reader returned cache misses, while the GitHub connector supplied the exact first-party records. No code was run and no stable release or production impact was verified.

Source timestamps identify repository changes. OTR preparation, retrieval and public publication clocks are separate. Internal synthesis is attributed to OTR Database Data; the source trail links to the public upstream records.