Enable post-RHT amax estimation with separate amax scale kernel

[negvet]

Description

Please include a brief summary of the changes, relevant motivation and context.

Fixes # (issue)

Type of change

• Documentation change (change only to the documentation, either a fix or a new content)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Infra/Build change
• Code refactoring

Changes

Please list the changes introduced in this PR:

• Change A
• Change B

Checklist:

• I have read and followed the contributing guidelines
• The functionality is complete
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[negvet]

/te-ci

[zhongbozhu]

Having a separate amax scale API automatically means that we need a grouped API for MOE and therefore not a good choice moving forward. Can we fuse the amax scaling as part of the FP4 quantize kernels via the quantization config struct? Whenever we change the numeric for Dense, we have to change it for MOE.

[negvet]

Having a separate amax scale API automatically means that we need a grouped API for MOE and therefore not a good choice moving forward. Can we fuse the amax scaling as part of the FP4 quantize kernels via the quantization config struct? Whenever we change the numeric for Dense, we have to change it for MOE.

nvte_scale_amax is intentionally a standalone kernel. This helps to avoid amax scale through every kernel that deals with amax (quantize, gemm, etc).

This is functional with commont entry point:

• dense: call nvte_scale_amax
• moe: call the same, per-split

This is single explicit step that applies everywhere and reduce the chance we forget to scale in the new op/refactor.

I agree that extra launch cost in the loop is an issue (now, nvte_compute_amax_with_config is done per split). This is your main concern right?

What about compute all per-split pre‑RHT amaxes in one grouped call instead of calling nvte_compute_amax_with_config in a loop? Can I reuse nvte_group_amax?
And then we can decide whether grouped scaling is worth to be grouped as well.
What do you think?