[GH-ISSUE #39] DeepGEMM: Benchmark Report for Shape-Specific Performance Issues #25

New issue

Closed

opened 2026-10-26 21:10:49 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-26 21:10:49 +00:00

Owner

Originally created by @cc13ny on GitHub (Mar 5, 2025).
Original GitHub issue: https://github.com/deepseek-ai/DeepGEMM/issues/39

The DeepGEMM README notes performance limitations for specific shapes.

DeepGEMM does not behave very well on some shapes.

To enable community contributions for optimization, could you please provide a benchmark report detailing these shape-dependent performance issues?

Originally created by @cc13ny on GitHub (Mar 5, 2025). Original GitHub issue: https://github.com/deepseek-ai/DeepGEMM/issues/39 The DeepGEMM [README](https://github.com/deepseek-ai/DeepGEMM/blob/main/README.md) notes performance limitations for specific shapes. > DeepGEMM does not behave very well on some shapes. To enable community contributions for optimization, could you please provide a benchmark report detailing these shape-dependent performance issues?

bsakaguchi closed this issue

2026-10-26 21:10:50 +00:00

bsakaguchi commented

2026-10-26 21:10:50 +00:00

Author

Owner

@soundOfDestiny commented on GitHub (Mar 5, 2025):

We test all shapes potentially used in DeepSeek-V3/R1 inference (including both prefilling and decoding)

Performance is expected on shapes used in DeepSeek-V3/R1 inference (in benchmark table in README)

However, the speedup of some shapes is 1.0x in that table, and perhaps there is still room for improvement.

In addition, performance would not be as good as expected when m/n is small since we don't apply algorithms like split-k or stream-k.

@soundOfDestiny commented on GitHub (Mar 5, 2025): > We test all shapes potentially used in DeepSeek-V3/R1 inference (including both prefilling and decoding) Performance is expected on shapes used in DeepSeek-V3/R1 inference (in benchmark table in [README](https://github.com/deepseek-ai/DeepGEMM/blob/main/README.md)) However, the speedup of some shapes is 1.0x in that table, and perhaps there is still room for improvement. In addition, performance would not be as good as expected when m/n is small since we don't apply algorithms like split-k or stream-k.

bsakaguchi referenced this issue

2026-10-26 21:14:53 +00:00

[PR #25] [CLOSED] add fp8 block-wise gemm benchmark #209