[Pinoeer-kingxi]

• I, the PR author, have personally reviewed every line of this PR.

What does this PR do?

The fused pre-GDR gate backward accumulates A_log and dt_bias gradients with atomics. Add an ordered reduction when the existing deterministic setting requests it, while preserving the default autotuned atomic reduction.

When use_deterministic_mode() returns True, each program writes independent FP32 partial sums and the caller reduces them on the existing stream. The tile comes from the shared autotune_configs selector; that same config determines scratch capacity and launch parameters. This supports explicit block-size overrides and runtime mode changes without a fixed 128×16 launch.

With determinism disabled, the original autotuner, candidate list and atomic accumulation remain in use, with the original accumulator size. Pinning autotune by itself does not enable ordered arithmetic. The deterministic selector uses the existing block-size/min-cost selection, not tuned-table lookup.

Full pre-GDR fusion still rejects model deterministic_mode=True; this PR does not enable deterministic execution of the entire fused model. No activation-offload code changes are included.

Validation

Final source: d8115c4c3bf52a868b242d032b5519d7c3331a52, compared with upstream 9131593673d037d360d252904f9198d36bc0c246.

• 34 gate GPU cases passed on an A6000: BF16/FP32, tails, strided gradients, side streams, default/overridden tiles, byte-exact replay under contention, Torch numerical reference and runtime mode selection.
• All 11 existing pre-GDR fusion cases passed. All 272 CPU registry cases passed. Zero skips in these suites.
• The fixed-tile PR revision 9d54b872 fails the new default-dispatch regression test after executing the actual backward; the final source passes.
• Three optimizer steps of the full Qwen3.5-0.8B text model (24 layers, BF16, sequence 2048, four accumulated microbatches, native Adam, fusion on, offload off): loss and weights match exactly. Five gradient/Adam state snapshots differ from the first baseline, and all five exactly match an unchanged-upstream rerun; the maximum gradient difference is 1.19e-7. The original strict state comparison fails, as it also does for the upstream rerun. These failures are retained; default atomic training is not claimed to be bit-exact.
• At the recorded Qwen configuration, upstream and final-source default gate kernels have identical SM86 instruction encodings, register usage and zero spills.
• Qwen state and timing runs use the same upstream-recorded kernel configurations in both arms, with ordered arithmetic disabled. Ordinary timing-based autotuning is covered separately by the runtime-mode tests. Final-head timing uses one fresh-process pair, five warmup and fifty timed optimizer steps per arm: 961.09 → 919.98 ms median, with identical 22,793,579,520-byte peak allocated memory. Three earlier fifty-step pairs at cc09983f ranged from −3.45% to +5.51% (paired median +0.64%). No stable throughput change is established.
• tools/autoformat.sh passes in check mode. Its nonblocking mypy stage reports the same four diagnostics as upstream; no new diagnostic remains.

Commands, per-rank logs, raw samples, state differences, traces and offline verification identify each executed revision. These are local results; upstream GPU CI is still pending for this head.

The historical fixed-128×16 wrapper benchmark belongs to 9d54b872. Its 5.9%–8.7% wrapper gains and 2–32 KiB increase do not qualify this implementation or establish end-to-end speedups.

Issue tracking

Related to #6757. Split from #7908 following the requested review boundaries. #7908 preserves the upstream fused kernels and does not depend on this PR.

Contribution process

Pre-checks

• I have added relevant unit tests.
• I have added relevant functional tests.
• I have added a bit-exact kernel replay test and registered it in the determinism manifest.
• I have added proper typing to the changed code.
• I have documented the changed behavior in implementation comments and docstrings.
• I have run tools/autoformat.sh (check mode).

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.