본문 바로가기

dev_AI_framework

on-the-fly 전치 + 타일렁 누적 VS cuBLAS 의 비교

언제 차이가 거의 없다?

  • 범용 GEMM(큰 M/N/K, 연속 메모리, FP16/BF16/TF32/FP32)
    cuBLAS는 이미
    • 공유 메모리 타일링, 레지스터 마이크로타일, coalesced 로드,
    • (Ampere+) Tensor Core 경로,
    • 내부 패킹/스케줄링을 최적화
      해서 **루프라인(roofline)**에 가깝게 나옵니다.
      → 같은 아이디어로 직접 커널을 짜도 비슷한 수준을 만드는 건 가능하지만, 꾸준히 앞서기는 매우 어렵습니다.
  • 단발성 곱(가중치 재사용 X)
    B를 물리 전치/패킹하지 않고, on-the-fly 전치로 처리하는 전략은 cuBLAS 커널과 철학이 동일.
    큰 격차가 나기 어려움.

 

언제 차이가 “크게” 벌어질 수 있나?

  1. 형상·데이터형·레이아웃이 특수
    • 아주 작은 매트릭스(작은 M/N, 작은 배치): 커널 런치/오버헤드, occupancy 손실 때문에 cuBLAS가 손해 보기도 함.
      → 특정 고정형상(예: 트랜스포머의 작은 헤드 타일)에 초소형 전용 커널로 이길 수 있음.
    • 비정상 stride / 패킹 레이아웃: 직접 커널이 그 레이아웃에 맞춘 특화 로드/스와즐을 하면 이득.
  2. 반복 재사용(특히 추론)
    • 같은 B(=가중치)를 수십~수백 번 반복해서 곱한다면, 오프라인 패킹/전치(+ 인터리브 레이아웃)로 지속 이득.
    • cuBLAS 기본 GEMM은 자동 전치를 안 하지만, cuBLASLt는 워크스페이스 허용 시 전치/패킹 포함 알고리즘을 고를 수 있고, 이때 큰 차이가 벌어질 수 있음.
    • 직접 커널도 사전 패킹된 B를 전제로 짜면 상당히 유리.
  3. 연산자 Fusion 필요
    • epilogue에서 **α·AB+β·C + bias + activation + (양자화 dequant/requant)**까지 한 번에 → 메모리 왕복 제거
    • 트랜스포머에서는
      • QKV fused projection (X→[Q|K|V] 한 번에)
      • Add+Dropout+LayerNorm fused
      • INT8 requant(채널별 스케일) fused
        같은 것들이 큼.
    • cuBLAS 기본 GEMM은 제한적, cuBLASLt의 epilogueCUTLASS/직접 커널로 하면 큰 차이가 납니다.
  4. 알고리즘 자체가 GEMM을 넘어서는 경우
    • FlashAttention 류 (QKᵀ→softmax→AV를 메모리 O(T)로 타일 합성)
      → 이건 애초에 GEMM 합성이라 cuBLAS와 비교 불가. 직접 구현/전용 커널이 압도.
    • block-sparse / low-rank / grouped-GEMM 등 특수 구조 → 전용 커널 승.
  5. 정밀도/양자화 경로
    • INT8×INT8→INT32 누적 + per-channel requantepilogue에서 끝내면 DRAM I/O가 줄어 큰 차이.
    • cuBLASLt도 지원하지만, 직접 커널로 스케일/제로포인트/오프셋 보정을 더 촘촘히 fuse하면 이득.

 

실제 대형 모델 프레임 워크에서도 상화별로 다른 GEMM 경로를 취한다.

 

  • 큰 Dense GEMM: cuBLASLt (Tensor Core)
  • 작은 head GEMM: Strided-batched GEMM, 혹은 전용 소형 커널
  • Attention 핵심(QKᵀV): 일반 GEMM이 아닌 FlashAttention류 fused kernel
  • 추론/양자화: INT8 GEMM (pre-packed weights + requant)