Found by the third-round review of LTX-2.5 phase L3 (#435, PR #437). Not blocking that phase, and deliberately not fixed there.
What
src/vllm/model_executor/models/ltx2_text_encoder.cpp:328-334, Ltx2NormAndConcatPerTokenRms.
Upstream feature_extractor.py:60 is torch.mean(encoded_text**2, dim=2): **2 materializes an f32 tensor (each square rounded to f32), then an f32 sum and an f32 divide. Our port squares in f64, accumulates in f64, and divides by a double.
Measured against upstream (differing f32 bits / max abs diff):
| case |
port today (f64 square) |
full f32 mirror |
| random mask_left |
38 bits / 2.384e-07 |
0 bits / 0 |
| random mask_right |
36 bits / 2.384e-07 |
0 bits / 0 |
| zero-variance |
30 bits / 2.384e-07 |
0 bits / 0 |
Why it matters, and why it is LOW severity
Nothing fails at runtime: everything is 1 ulp and passes the suite's kTol = 1e-5. The cost is that the V2 arm has no bit-exact gate. The goldens permanently record 2.38e-07 where a correct-width port would record 0, so a future real defect of one ulp or less is unfalsifiable there.
This is the same class the phase's round-2 review failed on (a double where upstream promotes to float32, invisible because a token gate cannot catch a dtype that is too WIDE). Here it is less defensible than the V1 sum case: a straight f32 loop reproduces upstream exactly at the gated dimensions, so the "blocked reduction that no flat loop reproduces" defence which legitimately covers V1's accumulator does not apply.
It also falsifies, for this reduction specifically, the blanket claim in that file's header that "a double accumulator lands strictly closer to it than a naive f32 one does".
Why this is a separate row rather than a change in #437
The reviewer flagged the caveat itself, and it is the reason to measure rather than switch: D = 6 in the test fixture but 3840 in the shipped model. At 3840 torch vectorizes the reduction, and bit-exactness demonstrated at D=6 will not necessarily survive. A blind narrowing to f32 could trade a known 1-ulp offset for an unknown one at production width.
Wants: measurement at shipped-like widths first, then the narrowing if it holds, then re-emitting the V2 goldens so the arm gains a bit-exact gate.
🤖 Generated with Claude Code
Found by the third-round review of LTX-2.5 phase L3 (#435, PR #437). Not blocking that phase, and deliberately not fixed there.
What
src/vllm/model_executor/models/ltx2_text_encoder.cpp:328-334,Ltx2NormAndConcatPerTokenRms.Upstream
feature_extractor.py:60istorch.mean(encoded_text**2, dim=2):**2materializes an f32 tensor (each square rounded to f32), then an f32 sum and an f32 divide. Our port squares in f64, accumulates in f64, and divides by adouble.Measured against upstream (differing f32 bits / max abs diff):
Why it matters, and why it is LOW severity
Nothing fails at runtime: everything is 1 ulp and passes the suite's
kTol = 1e-5. The cost is that the V2 arm has no bit-exact gate. The goldens permanently record 2.38e-07 where a correct-width port would record 0, so a future real defect of one ulp or less is unfalsifiable there.This is the same class the phase's round-2 review failed on (a
doublewhere upstream promotes tofloat32, invisible because a token gate cannot catch a dtype that is too WIDE). Here it is less defensible than the V1sumcase: a straight f32 loop reproduces upstream exactly at the gated dimensions, so the "blocked reduction that no flat loop reproduces" defence which legitimately covers V1's accumulator does not apply.It also falsifies, for this reduction specifically, the blanket claim in that file's header that "a double accumulator lands strictly closer to it than a naive f32 one does".
Why this is a separate row rather than a change in #437
The reviewer flagged the caveat itself, and it is the reason to measure rather than switch:
D = 6in the test fixture but 3840 in the shipped model. At 3840 torch vectorizes the reduction, and bit-exactness demonstrated at D=6 will not necessarily survive. A blind narrowing to f32 could trade a known 1-ulp offset for an unknown one at production width.Wants: measurement at shipped-like widths first, then the narrowing if it holds, then re-emitting the V2 goldens so the arm gains a bit-exact gate.
🤖 Generated with Claude Code