Repository navigation
Conversation
cuDNN 9.26 heuristics overflow a stack buffer while planning the BF16-intermediate graph for that one forward-training shape. The FP32 intermediate still uses the cuDNN norm. Signed-off-by: Liang Yan <lyan@coreweave.com>
for more information, see https://pre-commit.ci
Contributor
[Medium impact] The PR appears safe to merge; no actionable issues were found. SummaryKeeps the FP32 MXFP8 RMSNorm intermediate for 2048×7168 forward training on cuDNN 9.26, even when
Reviews (1) · Last reviewed commit: "[pre-commit.ci] auto fixes from pre-comm..." · Reviewed by Greptile |
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.
Description
On cuDNN 9.26,
NVTE_CUDNN_MXFP8_NORM_OUTPUT_IN_INPUT_DTYPE=1makesCudnnNormalizationPlantype the MXFP8 RMSNorm virtual output as the input dtype (BF16). Heuristics then die with SIGSEGV while planning that graph at exactly 2048×7168, forward training (row-wise and column-wise block-scale quantize).create_execution_plansnever returns, so no norm kernel runs. There is no Python exception: the process exits -11 after the warning incommon.cpp.Single GPU, GB200, cuDNN
92600, Transformer Engine from the image that prints that warning atcommon.cpp:312. Each case isLayerNormLinear(hidden, 128, normalization="RMSNorm"), BF16, MXFP8, cuDNN norm on in both directions, in its own process.Failing case:
Same call at 4096×7168 prints the same warning and finishes:
exit=-11, noforward-okcommon.cpp:312warning4096×7168 is the tensor-parallel-1 shape of a 4096-token, hidden-7168 model. 2048×7168 is that sequence split by tensor parallel 2. Hidden 6144 at the same token count plans, so this is one shape, not a width threshold. Eval plans because the column-wise quantize output is absent.
This keeps the FP32 intermediate for that one shape on cuDNN 9.26 (
cudnnGetVersion()92600–92699) even when the flag is 1. cuDNN norm stays on. Other shapes still take the BF16 intermediate. Drop the guard once a cuDNN release fixes the heuristic.The overflow is in
libcudnn_engines_runtime_compiled.so.9.26.0, reached fromEngineHeuristics::finalize_internal. cudnn-frontend only forwardsHeurMode_t::Aintoquery_cudnn_heuristics_impl, and the process dies before an engine id comes back. A cuDNN bug report is being filed separately.Type of change
Changes
NVTE_CUDNN_MXFP8_NORM_OUTPUT_IN_INPUT_DTYPE.Checklist:
No unit test is included. The failure is a SIGSEGV inside cuDNN during
create_execution_plans, beforeexecute(), and it needs cuDNN 9.26 and the exact shape. A test would kill the process on that library. The five cases above were run against the unmodified library in the image. This change was not compiled in the environment that opened the pull request.