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 카드의 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 경로는 훨씬 낮게 보인다는 것이다. 동시에 작성자는 자신의 custom kernel도 Pro나 H200의 properly selected kernel을 항상 이기지는 못한다고 적는다. 그래서 이 보고는 어떤 불가능한 magic optimization보다, 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을 고르느냐, 잘못된 kernel을 고르느냐에 따라 throughput, latency, hardware purchasing decision까지 달라질 수 있다. 만약 이 Reddit 보고가 맞다면, consumer RTX card는 exact kernel path를 profile하지 않는 한 FP32 batched performance를 상당량 테이블 위에 남길 수 있다는 불편한 교훈을 준다.
그래서 NVIDIA의 공식 답변이 나오기 전에도 이 글은 볼 가치가 있다. 막연한 체감 저하가 아니라, 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 writeup은 RTX 5090의 batched FP32 SGEMM이 비효율적인 cuBLAS 경로를 타며 GPU 계산 자원을 크게 남기고 있다고 주장한다.
PyTorch는 2026년 4월 9일 X에서 Safetensors와 Helion이 PyTorch Foundation의 foundation-hosted project로 합류했다고 밝혔다. 이번 조정으로 foundation은 model distribution safety와 저수준 kernel tooling에 대한 역할을 더 크게 갖게 된다.
Astral의 2026년 4월 8일 글이 HN에서 주목받은 이유는 공급망 보안을 추상론이 아니라 CI/CD 운영 규칙으로 풀어냈기 때문이다. 위험한 GitHub Actions trigger 금지, action hash pinning, <code>permissions: {}</code> 기본화, secret 격리, GitHub App과 Trusted Publishing 조합이 핵심으로 꼽혔다.
Comments (0)
No comments yet. Be the first to comment!