RTX 5090의 cuBLAS FP32 dispatch 경로에 성능 문제가 있다는 주장

커뮤니티가 주목한 GPU 성능 이슈

2026-04-10에 올라온 r/MachineLearning 게시글은 RTX 5090에서 cuBLAS의 batched FP32 SGEMM 경로가 비정상적으로 약한 kernel을 선택하고 있을 가능성을 제기했다. 검토 시점 기준으로 이 글은 93 score와 6 comments를 기록했고, 본문에는 실험 요약이, 링크된 Medium 글에는 더 긴 profiling 설명이 담겨 있었다. 작성자는 테스트 환경을 CUDA 13.2.51, cuBLAS 13.3.0, driver 595.58.03로 명시했다.

주장의 핵심은 단순하다. 작성자가 만든 TMA 기반 SGEMM kernel이 batched workload에서 RTX 5090의 기본 cuBLAS 경로보다 1.4x~1.7x 빠르게 나왔고, 그 이유를 ncu profiling으로 확인해 보니 5090이 전체 범위의 workload에서 같은 작은 simt_sgemm_128x32_8x5 kernel에 고정돼 있었다는 것이다. Medium 글은 이 경로의 FMA pipe utilization이 대략 33%~42% 수준에 머문다고 설명한다. 반면 같은 계열 비교군으로 제시된 RTX PRO 6000은 약 73%, H200은 약 82%까지 올라간다.

• 작성자 benchmark에서는 1024~8192 크기의 batched workload에서 custom kernel이 cuBLAS를 46%~70% 정도 앞섰다.
• 문제는 단순 threshold miss가 아니라, 5090용 batched FP32 dispatch에서 escalation logic 자체가 빠진 것처럼 보인다는 해석이 붙었다.
• cuBLASLt는 FP32 정확도를 유지하는 경로에서는 여전히 SIMT 중심이고, FAST_TF32나 BF16는 더 빠르지만 input precision trade-off가 생긴다는 설명도 함께 제시됐다.

이 이슈가 중요한 이유는 AI workload 대부분이 결국 거대한 matmul 위에 서 있기 때문이다. 학습과 추론에서 consumer RTX 카드가 workstation이나 datacenter SKU보다 덜 정교한 dispatch를 받는다면, 개발자 입장에서는 library를 믿고 넘어가던 구간에서 예기치 않은 cost와 latency 손실이 생길 수 있다. 동시에 이 글은 TMA가 단순히 빠르기만 한 것이 아니라, 비교적 짧은 코드로도 꽤 높은 효율을 낼 수 있다는 구현상의 메시지도 던진다.

다만 현재 단계에서는 작성자의 benchmark와 linked writeup이 핵심 근거이며, NVIDIA가 이를 공식적으로 확인한 상태는 아니다. Reddit 반응도 아직은 크지 않다. 가장 높은 comment는 “왜 NVIDIA forum이 아니라 여기 올렸느냐”는 질문이었고, 다른 comment는 조사 자체를 흥미로운 investigation으로 평가했다. 따라서 이 주제는 이미 확정된 vendor bug 공지라기보다, 커뮤니티가 소비자용 GPU stack의 dispatch 품질을 재점검하게 만든 기술적 문제 제기에 가깝다.

Source links: Reddit thread, Medium benchmark writeup, DeploDock repository.