TorchInductor의 오토튜너가 잠시 멈춘다. Triton과 cuBLAS를, CUTLASS와 새로 등장한 CuteDSL을 저울질한다. 그리고 트랜스포머 연산량을 ‘박살’ 낼 GEMM을 위해 Python 기반의 contender를 선택한다.
이건 단순한 과장이 아니다. LLM의 핵심 연산인 행렬 곱셈, 즉 GEMM은 언제나 하드웨어와의 ‘픽셀 단위’ 신경전이 필요한 영역이다. PyTorch의 백엔드 전쟁에서 계산된 움직임이라 할 수 있다.
왜 CuteDSL이 TorchInductor에 ‘착붙’하는가?
세 가지 조건만 만족하면 된다: 낮은 유지보수 비용, 컴파일 회귀 현상 없음, 주요 워크로드에서 압도적인 속도. CuteDSL이 이 모든 걸 해낸다. NVIDIA는 여기에 자원을 쏟아붓고 있으며, PyTorch 개발자들의 부담을 덜어줄 기성 커널 템플릿까지 제공한다. 컴파일 시간은? Triton과 동급, CUTLASS의 nvcc 느려터진 속도에 비하면 ‘신이 내린 선물’이다.
“CuteDSL은 CUTLASS C++와 동일한 추상화 위에 구축되었습니다. FP8 GEMM 및 에필로그 퓨전에서 강력한 성능을 입증했지만, Python으로 작성되어 컴파일 시간이 빠르고 유지보수가 덜 복잡합니다.”
이건 PyTorch 팀의 ‘진짜’ 이야기다. 꾸밈없다. 그리고 여기, 묻혀있던 핵심이 있다. 이건 단순한 백엔드 교체가 아니다. PyTorch가 Python을 통해 NVIDIA의 텐서 코어를 ‘완전히’ 제어하겠다는 선언이다. H100의 분산 공유 메모리부터 B200의 클러스터 트릭까지 모두 포함한다.
CuteDSL은 C++의 짐 없이 워프, 스레드 블록, 메모리 계층 구조 등 전체 스택을 드러낸다. ‘오토튜닝’은 후보군 폭발로 이어진다. 퓨전 벤치마킹이 ‘현실’이 된다. 이미 Triton으로도 강력했던 PyTorch의 파이프라인이 이제 GEMM 정밀도까지 확장된다.
하지만 잠깐. GEMM만? 왜?
GEMM이 ‘왕’이라면, 왜 이들에 집착하는가?
트랜스포머는 속삭이지 않는다. 그들의 순방향 패스는 GEMM을 ‘외친다’: 어텐션 프로젝션, FFN, 출력 헤드. 매번 GPU 사이클의 대부분을 차지한다. 최대 활용률? 이는 타일 크기를 텐서 파이프라인에 맞게 조정하고, 공유 메모리를 ‘딱 맞게’ 배치하며, 워프를 ‘마에스트로처럼’ 스케줄링하는 것을 의미한다.
고수준 언어는 이 디테일을 숨긴다. CuteDSL은 — CUTLASS처럼 — 숨기지 않는다. 수동 최적화된 템플릿으로 시작하여 모양에 맞게 매개변수를 조정한다. 처음부터 커널을 생성하는 것은 ‘고문’에 가깝다.
Triton은 나머지 부분을 책임진다. 요소별 연산, 활성화, 리덕션 — 메모리 바운드, 벡터화된 ‘천국’이다. 두 DSL 모두 소프트맥스와 같은 연산에서 대역폭 상한선에 도달한다. GB200 스케일에서도 마찬가지다. 여기서는 CuteDSL의 저수준 작업이 의미 없다.
CuteDSL은 ‘땀 한 방울’ 흘리지 않고 CUTLASS를 어떻게 능가하는가?
CUTLASS C++는 분명 강력하다. FP8 GEMM, 촘촘하게 퓨전된 에필로그. 하지만 각 변형마다? 전체 nvcc 컴파일이 필요하다. 오토튜닝은 볼륨에 질식하고, 퓨전 벤치마크는? ‘포기’해야 한다.
CuteDSL은 판을 뒤집는다. Python에서 MLIR 컴파일러로, ‘번개처럼’ 빠르다. CUTLASS와 동일한 타일 대수학, 메모리 프리미티브, 퓨전 모델을 사용한다. 그럼에도 TorchInductor는 Triton처럼 취급한다: 완전한 오토튜닝의 ‘광란’이다.
NVIDIA의 하드웨어 행진 — Hopper의 클러스터, Blackwell의 분산 SM — 은 CuteDSL의 프리미티브와 ‘장갑처럼’ 딱 맞는다. 오픈소스 모멘텀이 쌓이고 있다: Tri Dao의 Quack, Colfax의 Jay Shah. ‘별들이 정렬’된 것이다.
그리고 독특한 각도는? 이는 CUDA 자체의 진화를 반영한다. PTX를 기억하는가? 도구에는 충분히 높지만 ISA 트윅에는 충분히 낮은 수준. CuteDSL은 GEMM에서 바로 그것이다 — PyTorch의 PTX 순간, DSL이 컴파일러 복잡성을 ‘집어삼키도록’ 하고 NVIDIA가 하드웨어를 튜닝하게 한다. 대담한 예측: Hopper가 끝날 때쯤이면 CUTLASS C++는 사라지고, CuteDSL이 그 자리를 차지하며 코드베이스는 간결해지고 PyTorch는 더 빨라질 것이다.
회의적인가? 당연하다. 기업의 홍보는 ‘전략적 투자’를 외치지만, 메트릭은 거짓말을 하지 않는다. 컴파일 동등성 입증, SOTA 성능 달성. 유지보수는 NVIDIA에 ‘넘겼다’. 오히려 PyTorch는 안전하게 가는 것처럼 보이지만 — CuteDSL이 필드를 ‘쓸어버릴’ 때까지는.
더 깊이 보면: 이 백엔드 변경은 PyTorch의 GEMM 야심을 보여준다. cuBLAS 래퍼에 만족하지 않고, 이제는 DSL 네이티브가 되었다. NVIDIA 스택에서 LLM을 튜닝하는 개발자들은 더 ‘빡빡하게’ 돌아가는 퓨전 커널과 줄어든 런타임을 기대할 수 있다.
GEMM이 아닌 연산은? Triton이 담당한다. 실험 결과: 두 DSL의 소프트맥스 커널 모두 크기가 커질수록 GB200 대역폭을 포화시킨다. 회귀도, 성능 향상을 위한 복잡한 추격도 없다.
CuteDSL, PyTorch GEMM 오토튜닝의 미래인가?
그렇다, 하드웨어가 계속 발전한다면. B200의 스레드 블록 클러스터? CuteDSL 프리미티브가 네이티브로 동기화한다. 미래 세대는? 동일한 추상화가 확장될 것이다. CUTLASS C++는 nvcc 때문에 ‘삐걱’거리지만, Python은 ‘유연’하다.
PyTorch의 기준은 임의적이지 않았다. 공급업체 약속 (확인), 시간 중립성 (확인), 워크로드 승리 (확인). 결과: 온디맨드로 생성되는 SOTA GEMM.
PR의 미사여구를 비판할 수도 있다. ‘장기 전략 투자’는 이사회 냄새가 나지만, 실질이 이를 뒷받침한다. 더 빠른 컴파일은 오토튜닝의 약속을 ‘해제’하고, 퓨전 결정은 실시간으로 이루어진다. 트랜스포머가 ‘승리’한다.
역사적 비교: GCC의 등장은 속도와 이식성에서 경쟁자들을 ‘눌러’ 독점 C 컴파일러를 파멸시켰다. CuteDSL도 GEMM 백엔드에서 같은 일을 할 수 있다 — Python의 접근성이 NVIDIA의 저수준 우위를 ‘민주화’하는 것이다.
CuteDSL, LLM 학습에 왜 중요한가?
GEMM에서 절약된 사이클은 ‘연쇄 반응’을 일으킨다. 순방향 패스가 타이트해지고, 역방향 패스도 마찬가지다. 파인튜닝은 몇 시간에서… 더 짧아진다. GB200 클러스터에서는, 이는 클러스터 수에 달하는 처리량이다.
개발자는 템플릿을 받고, 모양을 튜닝하고, TorchInductor가 승자를 선택하게 한다. 더 이상 C++ 커널 해킹은 없다.
🧬 관련 인사이트
자주 묻는 질문
TorchInductor CuteDSL 백엔드는 무엇인가요?
PyTorch의 TorchInductor에 통합된 NVIDIA의 Python DSL로, 고성능 GEMM 커널을 생성하여 CUTLASS 수준의 제어를 Triton 속도의 컴파일로 제공합니다.
CuteDSL이 PyTorch에서 CUTLASS를 대체하나요?
더 빠른 Python 컴파일과 공유된 추상화를 통해, 장기적으로 유지보수를 단순화하면서 최신 NVIDIA 하드웨어에서 점진적으로 대체될 것으로 보입니다.
CuteDSL이 LLM 추론 속도를 향상시킬 수 있나요?
잠재적으로 그렇습니다. 트랜스포머 레이어에서 더 나은 오토튜닝 GEMM을 가능하게 하며, 특히 H100/B200 GPU에서 에필로그 퓨전과 함께 사용될 때 그렇습니다.
