grouped gemm microbenchmark: use te.GroupedLinear

[matthiasdiener]

Description

• matches the gemm benchmark more closely (which uses te.Linear)
• makes it possible to use (e.g.) the Triton/CK Grouped GEMM backends
• now that we can profile the kernels in the benchmark, no need to run
  the lower-level API directly

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

[ipanfilo]

What are benchmarks results comparing to baseline?

[matthiasdiener]

What are benchmarks results comparing to baseline?

Despite the different methodology, results are remarkably similar:

Case family	Forward latency (normalized to dev)	Backward latency (normalized to dev)
DSV2-Lite-Down	1.4% slower	6.7% slower
DSV2-Lite-GateUP	2.4% slower	6.4% slower
DSV2-Down	0.5% slower	1.7% slower
DSV2-GateUP	0.5% slower	0.4% slower
DSV3-Down	flat	0.2% slower
Grok-V2-Down	0.5% slower	1.1% slower
Grok-V2-GateUP	flat	0.5% slower

[ipanfilo]

If grouped linear is slower, shouldn't its usage be discouraged?

[matthiasdiener]

If grouped linear is slower, shouldn't its usage be discouraged?

It's not slower, the table in my comment compared the prior Grouped GEMM microbenchmark implementation (which just called transformer_engine.pytorch.cpp_extensions.general_grouped_gemm() directly) vs. the one from the PR (which uses te.GroupedLinear and has a bit more overhead)

[ipanfilo]

If grouped linear is slower, shouldn't its usage be discouraged?

It's not slower, the table in my comment compared the prior Grouped GEMM microbenchmark implementation (which just called transformer_engine.pytorch.cpp_extensions.general_grouped_gemm() directly) vs. the one from the PR (which uses te.GroupedLinear and has a bit more overhead)

I understand that but ~6% is quite big overhead that may make te.GroupedLinear usage undesired. Are those 'Lite' shapes expected to demonstrate such sensitivity?

[matthiasdiener]

If grouped linear is slower, shouldn't its usage be discouraged?

It's not slower, the table in my comment compared the prior Grouped GEMM microbenchmark implementation (which just called transformer_engine.pytorch.cpp_extensions.general_grouped_gemm() directly) vs. the one from the PR (which uses te.GroupedLinear and has a bit more overhead)

I understand that but ~6% is quite big overhead that may make te.GroupedLinear usage undesired. Are those 'Lite' shapes expected to demonstrate such sensitivity?

Yes, this is expected, it's specifically a smallest-shape effect. Raw kernel times (measured with --kernel-profile) are identical between te.GroupedLinear and general_grouped_gemm, so the difference is on the host side.

Profiling the host side shows that general_grouped_gemm itself costs ~0.1–0.5 ms/call on the host (three grouped-GEMM launches for fwd + dgrad + wgrad). te.GroupedLinear adds ~0.3 ms of framework work on top (autograd Function apply/backward, per-group split/cast, save_for_backward, allocations, grad-zeroing), independent of GEMM size.

Whether that fixed cost surfaces in wall time depends on the GPU work per call. On the smallest 'Lite' config (M=512) the GEMM is small so it's a meaningful fraction, which is where the ~6% comes from; as M grows and on the larger DSV2/DSV3/Grok shapes the GEMMs are big enough to hide it, so the slowdown shrinks towards zero.