Redditが指摘したRTX 5090のバッチFP32 workloadにおけるcuBLAS性能異常
Original: [D] 60% MatMul Performance Bug in cuBLAS on RTX 5090 [D] View original →
Redditが提示した主張
2026-04-09にr/MachineLearningへ投稿された内容は、RTX 5090上でcuBLASがbatched FP32 matrix multiplicationに対して望ましくないkernelをdispatchしているのではないか、というものだ。投稿者は256x256から8192x8192x8までのworkloadでこの経路がtested RTX cardのavailable computeの約40%しか使っていないと説明している。再現環境としてCUDA 13.2.51、cuBLAS 13.3.0、NVIDIA driver 595.58.03が挙げられている。
この投稿が単なる不満以上なのは、evidenceがかなり具体的だからだ。投稿者は自作のtensor memory accelerator double-buffer kernelとcuBLASを比較し、多くのbatched workloadでcustom pathがcuBLASをおよそ20%から70%上回ったと報告している。たとえば2048や4096サイズでは、batch sizeに応じてcustom kernelがcuBLAS throughputの約155%から170%に達するという表が示された。
なぜこの比較が重要なのか
より重要なのは、baselineそのものの選択が誤っている可能性だ。同じ投稿によれば、cuBLASは他のNVIDIA製品ではもっと適切なkernelを使っている。掲載されたprofiling summaryでは、RTX Pro 6000が約73%のFMA utilization、H200が約82%に達する一方、RTX経路はかなり低く見えるという。しかも投稿者自身、自作kernelがProやH200のproperly selected kernelを常に上回るわけではないと認めている。つまり話の中心は、cuBLASが原理的に遅いというより、RTXでkernel selectionを誤っているのではないかという点にある。
投稿はさらにMediumのdeep dive、full Nsight Compute profiling data、GitHubのrepro scriptsとbenchmark reportにもリンクしている。これは重要だ。ほかのengineerがworkload mix、batch size、kernel familyを直接見比べ、non-Pro RTX GPUでも同様のregressionが起きるかを検証できるからだ。
AIインフラ側で見る意味
AIやinferenceのチームにとって、batched GEMM behaviorはsynthetic benchmarkを超える問題だ。libraryが正しいkernelを選ぶか、外すかでthroughput、latency、hardware purchasing decisionまで影響しうる。もしこのReddit報告が正しいなら、consumer RTX cardは実際に使われているkernel pathをprofileしない限り、FP32 batched performanceをかなり取りこぼしている可能性がある。
だからNVIDIAの正式回答前でもこの投稿は興味深い。漠然としたGPUが遅いという不満を、dispatch logic、architecture segmentation、そしてlocal AI builderのworkloadにlibrary defaultが本当に合っているのかを問う、再現可能なsystems questionへ変えているからだ。
Source links: Reddit thread, Linked article, Benchmark report.
Related Articles
r/MachineLearningの投稿とリンク先のbenchmark記事は、RTX 5090のbatched FP32 SGEMMが非効率なcuBLAS経路に入り、GPU計算資源を大きく余らせていると主張する。
Googleは2026年10月から2029年6月まで、約110,000基のNVIDIA GPUなどを使うためSpaceXに月$920Mを支払う。Gemini Enterpriseの需要が想定を上回り、巨大インフラ企業でも外部computeを借りる局面に入った。
Hacker Newsのfront pageに上がったEE Times interviewは、AMDがROCm、Triton、OneROCm、open-sourceの運用でCUDA依存を段階的に削ろうとしていることを整理している。重要なのは派手な互換性宣言ではなく、vLLMやSGLangが自然に動くboringなsoftware完成度だ。