[Feature] Fused gated RMSNorm (RMSNorm(x) * SiLU(gate)) for GDN output norm
维护者通常 2 天内回复
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
调研方向
Start by reading the existing rmsnorm_fwd and rmsnorm_bwd paths, tests/pytorch/test_numerics.py (test_rmsnorm_accuracy), and the op checks in tests/pytorch/test_fusible_ops.py. The proposed work has two stages: establish the PyTorch RMSNormGated API and numerics, then add native nvte_rmsnorm_gated_fwd/bwd kernels, including strided gates. Done means y, dx, dgamma, and dgate match an FP64 reference for both gamma modes and contiguous and strided gates; kernel performance work spans GPU architectures the author cannot test.
由索引模型根据 Issue 内容生成。
描述
Is your feature request related to a problem? Please describe.
Gated DeltaNet layers (Qwen3.5 / Qwen3-Next style) normalize the attention output and then gate it: y = RMSNorm(x) * silu(gate). TE's RMSNorm has no gate input (neither nvte_rmsnorm_fwd nor the PyTorch module/op), so Megatron-LM runs this as out_norm(x) * act_fn(gate) in megatron/core/ssm/gated_delta_net/gdn.py (_apply_gated_norm). There is also an opt-in Triton kernel (megatron/core/fusions/fused_gated_norm.py, behind gdn_gated_output_norm_fusion). This is the "Gated RMSNorm implementation in TE" item in the Megatron-LM MoE roadmap (NVIDIA/Megatron-LM#6757); @sbhavani suggested opening a design issue here.
Describe the solution you'd like
A separate op rather than a new argument on RMSNorm, following the precedent of backward_add_rmsnorm / nvte_rmsnorm_bwd_add:
norm = te.ops.RMSNormGated(hidden_size, eps=1e-6, zero_centered_gamma=False)
y = norm(x, gate) # y = rmsnorm(x) * silu(gate), dgate returned in backward
I'd do it in two steps:
- A PyTorch op that reuses the existing
rmsnorm_fwd/rmsnorm_bwd, with the gating as pointwise work. Backward isdn = dy * silu(g),dg = dy * n * silu'(g), thenrmsnorm_bwd(dn). This settles the API and the numerics. - Native
nvte_rmsnorm_gated_fwd/bwdkernels so x, gate and y are each read or written once, starting with contiguous BF16/FP16, then strided gate (GDN slices the gate out of a projection output).
For numerics I'd match Megatron's Triton kernel: FP32 accumulation, n and dn rounded to x's dtype before the gate multiply, and dgate in the gate's dtype. That way switching Megatron from the unfused or Triton path to TE doesn't change results beyond rounding.
Tests would follow test_rmsnorm_accuracy in tests/pytorch/test_numerics.py and the op-level checks in tests/pytorch/test_fusible_ops.py: y, dx, dgamma and dgate against an FP64 reference, with zero-centered gamma on and off, and contiguous and strided gate.
Describe alternatives you've considered
- An optional
gateargument onRMSNorm. That touches the C API and every existing RMSNorm path (cuDNN backend, FP8/MXFP8 outputs, JAX), and backward would need an extra output, so a separate op seems cleaner. - Keeping the Triton kernel in Megatron only. That works, but other frameworks can't use it, and it doesn't compose with TE's quantized outputs.
Additional context
I can develop and check correctness on SM86 (RTX 3090, NVTE_CUDA_ARCHS=86) and SM120 (RTX PRO 6000). I don't have SM90/SM100 access, so performance numbers there would need someone else's help. Questions:
- Is a separate
RMSNormGatedop the shape you'd want, or would you rather fold it into the ops fuser? - Should step 1 land on its own, or only together with the native kernel?
- Should the first version support FP8/MXFP8 output, or only BF16/FP16?
- 主要语言
- Python
- 星标
- 3.6k
- 派生
- 872
- 平均合并
- 4 天 11 小时
- 30 天内合并 PR
- 59
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
NVIDIA/TransformerEngine 的其他 Issue
-
[PyTorch] fp8_cs_quantize fake implementation returns a vector inverse scale instead of a scalar可能重新可做 @sanjana658 于 17 天前认领,目前没有进行中的 PR。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
NVIDIA/TransformerEngine#3636 · 2 条评论 ·
维护者通常 2 天内回复
-
[Bug] Backend selection picks FA3 for training with head_dim_qk=192 / v_head_dim=128, but FA3 backward cannot run it可能重新可做 @modelpath-dev 于 51 天前认领,目前没有进行中的 PR。 未关闭attention
难度 2/5 1-3 小时 新手友好度 85/100
NVIDIA/TransformerEngine#3481 · 4 条评论 ·
维护者通常 2 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 68/100
NVIDIA/TransformerEngine#2189 · 7 条评论 · 5 个 reaction ·
维护者通常 2 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
NVIDIA/TransformerEngine#3729 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 52/100
NVIDIA/TransformerEngine#3720 ·
维护者通常 2 天内回复
查看 NVIDIA/TransformerEngine 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 84/100
GoogleCloudPlatform/gce-rescue#195 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 83/100
维护者通常 1 天内回复
-
intake mcp-intake needs-ac needs-human-review priority:medium
难度 2/5 1-3 小时 新手友好度 67/100
Ikalus1988/MisakaNet#3848 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 75/100
521xueweihan/HelloGitHub#4105 ·
-
bug size:XS
难度 2/5 1-3 小时 新手友好度 83/100
维护者通常 1 天内回复