grouped gemm microbenchmark: use te.GroupedLinear

[matthiasdiener]

Description

• matches the gemm benchmark more closely (which uses te.Linear)
• makes it possible to use triton backend
• 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?