[Fix] Align GDN target-verify beta semantics with packed decode

[V-aerus]

Motivation

The Triton GDN packed-decode and speculative target-verify paths currently use
different precision semantics for beta = sigmoid(b) when b is BF16:

packed decode: sigmoid -> BF16 materialization -> FP32 recurrent update
target verify: sigmoid -> retained FP32 -> recurrent update

As a result, identical Q/K/V, gating inputs, and initial recurrent state can
produce different recurrent output and state. This is particularly relevant to
speculative verification because the recurrent state persists across decode
steps.

Modification

• Align GDN target-verify beta with the existing packed-decode
  activation-dtype rounding semantics.
• Keep KDA and non-verify calls on their existing FP32 beta path.
• Add a focused, model-free packed-decode-vs-target-verify regression covering
  both recurrent output and FP32 state.

The normal packed-decode kernel is unchanged.

Regression

The new test uses deterministic BF16 inputs with one sequence/head and
production K=V=128 head dimensions. b=-0.5 makes the BF16 beta
materialization observable without random inputs or a model checkpoint.

On current main before the fix, three runs fail consistently:

output unequal: 128 / 128 elements
output max abs diff: 0.000244140625

After the fix, packed decode and T=1 target verify are bitwise equal for both
the BF16 output and updated/intermediate FP32 state.

As an additional development-only check, a real captured Qwen3.8 recurrent
transition changed from:

state unequal: 770774 / 786432
output unequal: 321 / 6144

to zero differences for both tensors. The capture is not part of the test or
this commit.

Validation

• test_fused_verify_triton_gdn.py: 13 passed
• test_gdn_noncontiguous_stride.py: 8 passed
• test_kda_kernels.py: 14 passed, 3 subtests passed
• Ruff, Black, isort, registered-test registry check, and git diff --check

Local kernel validation used an NVIDIA GeForce RTX 4090 with PyTorch
2.11.0+cu130 and Triton 3.6.0.

Scope

This PR intentionally addresses only the isolated GDN beta precision mismatch.
It does not claim to resolve all Qwen3.8 or speculative-decode numerical
divergence, and it does not close #35150.

Related

Related: #35150, #35541, #34734.

The related open PRs also identified the beta alignment. This PR keeps the
change intentionally minimal, narrows it to GDN target verify, and adds focused
packed-decode-vs-target-verify regression coverage on current main.

---

CI States

Latest PR Test (Base): ❌ Run #34223952622
Latest PR Test (Extra): ❌ Run #34223952289
Latest PR Test (AMD ROCm 7.2): ❌ Run #34223952653

[V-aerus]

Hi @yizhang2077, I’ve rebased this PR onto the latest main.

The focused GDN/kernel regression suite passes (36 passed, 3 subtests passed), together with changed-files pre-commit and diff checks.

As independent evidence, #36548 reports that applying this beta fix reduced DFlash C8 wrong answers from 111/304 to 37/304 under the same seeds. This supports the fix as a meaningful isolated correction, while it still does not claim to resolve all remaining Qwen3.8/DFlash correctness issues.

Could you take a look when you have a chance and help kick off CI? Thanks!

[V-aerus]

Hi @BBuf, could you take a look at this focused GDN kernel fix?

I’ve rebased it onto the current main; the patch is unchanged after rebase, and the focused kernel suite passes (37 passed, 3 subtests passed) with clean pre-commit/diff checks.

It aligns target-verify BF16 beta semantics with packed decode and includes a model-free bitwise regression. The PR is currently blocked at the run-ci label gate.

Would appreciate your help with review / CI when convenient. Thanks!

[V-aerus]

Hi @hnyls2002, could you help take a look at this focused GDN target-verify fix when convenient?

It aligns BF16 beta semantics between packed decode and target verify and includes a model-free bitwise regression. The branch is rebased and focused tests are clean; the PR is still blocked at the run-ci gate with no review yet.

Would appreciate help routing/reviewing or enabling CI. Thanks!