Repository navigation
[Enhancement] Add opt-in FP32 KDA chunk computation - #2301
Draft
qescccczmr wants to merge 1 commit into
Draft
qescccczmr wants to merge 1 commit into
qescccczmr wants to merge 1 commit into
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
GLM-5.3 KDA training's BF16 chunk solve/state intermediates differ from serving's FP32 recurrence. On the same real layer-0 Q/K/V/gate/beta inputs (64 heads x 128 dimensions, 129 fixed tokens), the training core output has relative L2 difference 0.00459635426159536 versus actual LMDeploy recurrence. Gate activation was independently checked; it is not the source of that discrepancy in this fixture.
Change
Add the opt-in startup setting:
export XTUNER_GLM53_KDA_FP32=1For the compile-friendly
chunk_kdapath, promote Q/K/V before L2 normalization, keep normalized vectors, chunk solve/state intermediates and backward recomputation in FP32, and cast only the visible output and input gradients back to the original activation dtypes. The fake implementations reflect the changed intermediate dtypes. The existing fixed-layout gate prefix, packed offsets, parameters and native FLA backward remain in place. No compression backward, new model class or second inference model is introduced.Unset/0 retains the original path. Set before importing XTuner in all training workers; for Ray, propagate it in
runtime_env.env_vars.XTUNER_HF_IMPL=1selects FLA's own entry point and does not use this option. This change does not add initial/final state or context-parallel support to this wrapper.FP32 intermediate storage is not a guarantee of IEEE FP32 GEMM: the installed FLA kernels may use TF32. This PR improves chunk precision; it does not claim bitwise equivalence to serving recurrence.
Validation
On 10.102.215.14 / H200, PyTorch 2.9.1+cu128, FLA 0.5.2, TileLang 0.1.11:
K=16, V=24) raises TileLang'sno available layout found; the same case and error were reproduced on the unmodified main KDA implementation. This is recorded as a dependency/compiler limitation, not a clean whole-suite or zero-added-failures claim. The real 128 x 128 geometry succeeds in the new independent VJP check.CUDA-event timing of CUDA Graph forward replay, 50 samples after warmup (64 heads x 128 dimensions):
This option increases memory/compute; the 16K core is about 1.94x slower. These are operator forward timings, not full training/serving throughput. The option remains off by default.
Scope / remaining work
This draft is intentionally limited to a measured precision option. The remaining recurrence difference is significant and still under diagnosis. A combined five-step reduced-25B MoE-only GRPO run completed with BF16 KPool alignment, FP8 activation rounding and the separate mHC/SwiGLU patches, prefix caching and MTP5. The end-to-end
mismatch/mismatch_k3_kl <= 2e-4target is not yet established and is not inferred from operator relative L2 statistics.Five-step combined numerical check (2026-11-11, H200)
A fresh five-step check completed on 10.102.215.14 / 8 x H200, exit code 0, using the five-layer reduced GLM-5.3 Flash 25B checkpoint, GSM8K, EP4/SP1 training and TP1/EP4 rollout, prefix caching and MTP with
num_speculative_tokens=5.This is a combined recipe: BF16 KPool pooling/head alignment, FP8 MoE activation rounding, opt-in FP32 KDA chunks, and the separate mHC-post/SwiGLU alignment patches. The eight startup variables
FP8,ROLLOUT_FP8,LMDEPLOY_FP8_MOE_ONLY,XTUNER_GLM53_KPOOL_BF16,LMDEPLOY_GLM53_KPOOL_BF16,XTUNER_GLM53_LMDEPLOY_SWIGLU,XTUNER_GLM53_KDA_FP32, andLMDEPLOY_MLA_DISABLE_DENSE_PREFILLwere all1. The actual environments of 8 training workers, 8 inference-compute workers and their engine/controller wrappers were checked; the prefix-cache replay probe also passed.mismatch/mismatch_k3_klThe end-to-end <=2e-4 target was not reached (all five values remain above it). TensorBoard scalar values were cross-checked with the worker's full-precision log values. Local KPool score relative L2 at 2.2e-7 is a different metric and does not imply whole-model KL at that level.
Rewards, losses and gradient norms were zero; this is a numerical GRPO smoke test, not evidence of useful learning or nonzero parameter updates. No per-patch causal improvement is inferred from this combined run. Remaining differences, including the actual DeepEP dispatch/combine path and KDA recurrence, are still under diagnosis.