[RunningLeon]

Root Cause

GLM-5.3-Flash uses a mixed-precision FP8 recipe, not FP8 for every linear layer. The official checkpoint configuration explicitly lists the KDA q/k/v/o, beta and forget/output-gate projections in quantization_config.modules_to_not_convert. LMDeploy correspondingly builds these projections without an FP8 quantization config.

XTuner currently forwards the model-wide Float8Config through KDAConfig.build into all KDA projections. Enabling FP8 training therefore changes the KDA projection precision relative to the official recipe and the rollout model.

The existing gate_projection_block_size option from #2167 only excludes selected sensitive gates when fixed blocking is enabled; it does not implement the full GLM53 KDA exclusion. This is also separate from the FLA state-layout API compatibility in #2197.

Fix

• Add KDAConfig.quantize_projections, defaulting to True to preserve generic KDA behavior.
• Consume the flag in the builder: pass no Float8Config to KDA when disabled; do not forward the config-only flag to the module constructor.
• Disable it in both GLM53 configuration entrypoints: the default text-model config and from_hf.
• Leave the shared FP8 configuration and non-KDA projections untouched. The flag excludes FP8; it does not force a global dtype or alter recurrent-state accumulation precision. Existing explicitly supplied custom KDA configs retain their chosen policy.

Only the KDA policy and regression tests are included. No grad-norm compatibility patches, FLA dependency changes, rollout instrumentation, or weight-export changes are included.

Test Plan

Focused regression tests on this PR

tests/model/test_glm53_kda_quantization.py covers:

• every KDA projection with FP8 enabled/disabled, for both low-rank and full-rank output gates;
• the unchanged generic FP8 default and behavior without a global FP8 config;
• preservation of an unrelated FP8 linear built from the same config;
• GLM53 default configuration, KDA configuration serialization, and local HF-config conversion without network/model downloads.

Results on PR base 214ad3e3 plus this patch:

• pt2121_all_en_sglang: 9 passed, including real local HF-config conversion, with the repository conftest enabled.
• verl: 8 passed, 1 skipped with --noconftest (the environment lacks expecttest; its Transformers lacks GLM5Next). No packages were installed into either environment.
• The new suite fails on the unmodified base (missing policy field); the fixed suite passes.
• Focused Ruff lint, formatting and git diff --check pass. Focused non-type-check formatting/lint hooks also pass.
• Full pre-commit is not green: the all-files run found unrelated existing formatting/lint findings (auto-edits were reverted). The isolated mypy bootstrap was stopped while installing its pinned Torch 2.6 environment; mypy was not validated. The Pydantic scan imports GPU-only modules and fails with CUDA hidden in this CPU check. These limitations are not claimed as passing checks.

These are CPU/meta construction tests, not attention-kernel forward/backward tests.

Prior end-to-end evidence for the same policy change

A cropped GLM-5.3-Flash ~25B model was run for five RL steps before and five after the KDA-only policy fix, on 8 H200 GPUs, with FP8 training/rollout, MTP3, routed-expert replay, and FP32 heads. Source snapshots: XTuner 6a5cbe08a5d0f04b38e2bbc7f2e1a61408d0172a, LMDeploy 9f2cd03ad1187443ede93c8f75f540c5c643b419. Both arms retained the same separate Torch 2.11 grad-norm compatibility patch; it is not part of this PR. Environment: Torch 2.11.0+cu130, training FLA 0.4.2 / rollout FLA 0.5.2 isolated per process.

• Before: native logged sampled KL was 1.585e-3 initially and 3.36e-2–3.79e-2 after updates.
• After: native logged sampled KL stayed between 7.23e-4 and 1.07e-3. Independently recomputed, token-weighted overall sampled KL was 8.447e-4, and k3 was 8.218e-4 over 326,596 valid response tokens.
• The corrected run completed 5 optimizer steps per rank and 4 post-training weight synchronizations, consumed routed-expert IDs, had nonzero MTP gradients, and exited without residual workers or forced cleanup.

Limitations: naturally generated trajectories differ between arms, so this is not a fixed-trajectory paired KL attribution. Framework metrics use microbatch aggregation; the independent overall result uses token weighting. These are sampled log-probability estimators, not full-vocabulary KL. Rewards/advantages were zero for this cropped-model run; MTP auxiliary loss supplied the gradient signal. The baseline completed training but required cleanup of one lingering worker. Full-size accuracy, throughput, and RL reruns on the newer PR base are not claimed.

Performance / Compatibility

This correctness fix intentionally uses the non-FP8 linear path for GLM53 KDA, matching the checkpoint recipe. It may change KDA projection memory/throughput versus the previous global-FP8 path; no performance improvement is claimed. MoE/MLP and sparse-attention FP8 selection is unchanged. No additional per-token branching or kernel changes are introduced.

ProduceBatchResult impact: not affected.
RoutedExperts ownership/format impact: not affected.