Skip to content

The only forward-runnable Laguna fixture is constant: logits do not move for token id, position, or row #2834

Description

@localai-org-maint-bot

Row: MODEL-LAGUNA-REGISTRY-FORWARD-2618

Listed under ## Owed O3 of .agents/specs/laguna-registry-forward-2618.md.

What

BuildFiniteTensors() in tests/vllm/models/test_laguna_nvfp4_loader.cpp builds
the only forward-runnable Laguna fixture in the tree. Run through
LagunaForwardGguf, it produces a constant output: every one of the 24
logits is 0.0444346, and the value does not move for any input.

Measured on row/MODEL-LAGUNA-REGISTRY-FORWARD-2618 at b09ced3a7, by a probe
TEST_CASE added to that file, built and run, then removed:

maxdiff positions {0,1,2} vs {0,0,0}          = 0
maxdiff positions {0,1,2} vs {137,138,139}    = 0
maxdiff positions {0,1,2} vs {0,2000,4000}    = 0
maxdiff tokens {1,3,2} vs {5,5,5}             = 0
all-logit min = 0.0444346  max = 0.0444346  n = 24
row0 vs row1 maxdiff                          = 0

So the forward on this fixture is invariant under position, under token
id
, and across rows.

Why it matters

It is not a bug in the forward. It is a fixture that cannot discriminate, and two
shipped gates read stronger than they are because of it.

laguna nvfp4 forward: fp4 MoE branch runs finite + deterministic (CPU run-gate)
asserts finite, deterministic, and "differs when every routed expert's gate codes
are zeroed". On a constant output the first two hold trivially. Only the third
carries signal.

#2618's new registry cases inherit it. The byte-identity case
(registry logits == LagunaForwardGguf logits) still discriminates — a mutation
returning a different constant, 0.5F, fails it, verified — but on a constant
oracle it is a weaker equality than it looks. The unambiguous reachability proof
on that row is the call-site deletion, which returns the SIGSEGV.

Concretely, neither gate can detect a defect in RoPE, in the causal mask, in the
position plumbing, or in the embedding gather, because none of those inputs
changes the output.

Not fixed in the flow that found it

Repairing the fixture changes what the pre-existing loader round-trip assertions
compare — the same tensors serve the byte-for-byte load checks — so it is a
change to a shared fixture with its own red-first argument, not a one-line
repair. It is recorded as owed rather than deferred silently.

What would close it

A fixture whose logits move when a token id moves and when a position moves,
with the loader round-trip assertions preserved, and the existing run-gate
re-pointed at it.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions