DeepGEMM은 H100, H800 같은 NVIDIA Hopper GPU에서 FP8 행렬 곱셈을 돌릴 때 검토할 라이브러리이며, 모든 GPU나 모든 행렬 크기에서 2.7배 빨라진다는 뜻은 아닙니다. 공개된 최대 수치는 특정 GEMM 크기에서 CUTLASS와 비교한 결과이므로 자신의 모델 모양과 정밀도 요구를 함께 확인해야 합니다.
DeepGEMM의 높은 처리량은 모든 행렬 크기와 GPU에서 자동으로 나오는 값이 아닙니다. 실제 모델이 사용하는 M, N, K shape, dtype, 정렬 조건과 커널 준비 비용을 포함해 기존 GEMM과 비교해야 합니다.
대형 모델의 핵심 계산에는 두 행렬을 곱하는 GEMM이 반복됩니다. DeepGEMM 프로젝트는 이 연산을 Hopper Tensor Core의 FP8 경로에 맞추고, 일반 GEMM과 Mix-of-Experts(MoE)의 Grouped GEMM을 제공합니다.
원문에 소개된 최적화는 네 축으로 나뉩니다.
FP8은 FP16, FP32보다 한 값을 표현하는 비트 수가 적습니다. 그만큼 메모리와 계산 측면의 이점이 있지만, 값의 표현 범위와 정확도가 같지는 않습니다. 따라서 “FP8을 지원한다”와 “현재 모델이 FP8에서도 요구 정확도를 지킨다”는 별도의 판단입니다.
MoE에서는 expert별 계산 크기가 달라질 수 있습니다. DeepGEMM이 제공하는 contiguous, masked layout의 Grouped GEMM은 이런 여러 블록을 한 종류의 고정 GEMM으로 억지로 맞추지 않고 처리하기 위한 기능입니다.
원문에 제시된 CUTLASS 대비 결과는 다음과 같습니다.
| M×N×K | 제시된 성능 향상 |
|---|---|
| 64×2112×7168 | 2.7배 |
| 64×24576×1536 | 1.7배 |
| 128×7168×2048 | 1.7배 |
MoE Grouped GEMM에는 약 1.2배 향상이 제시됐습니다.
이 표에서 바로 알 수 있는 한계도 있습니다. 비교 결과는 행렬 크기에 따라 1.7배와 2.7배로 달라지고, MoE 결과는 또 다른 폭을 보입니다. 따라서 최대값 하나를 전체 모델 속도 향상으로 환산하면 안 됩니다. 모델의 실제 M/N/K, 일반 GEMM과 Grouped GEMM의 비중, JIT 이후 반복 실행 구간을 같은 조건에서 측정해야 합니다.
또한 FFMA SASS 최적화에는 FP8 연산에서 10% 이상 향상이라는 설명이 있지만, 이것 역시 전체 서비스 지연 시간의 10% 감소와 같은 말은 아닙니다. 데이터 준비와 다른 레이어가 함께 실행되는 전체 경로는 별도로 재야 합니다.
원문에 적힌 요구 사항은 명확합니다.
설치 예시는 다음과 같습니다.
1
2
3
git clone --recursive git@github.com:deepseek-ai/DeepGEMM.git
cd DeepGEMM
python setup.py install
이 명령은 저장소와 submodule을 가져와 설치하는 기본 조각입니다. GPU 드라이버, CUDA, PyTorch 조합까지 자동으로 검증해 주는 완전한 배포 절차로 보기는 어렵습니다.
설치 뒤 원문이 제시한 테스트는 두 개입니다.
1
2
python tests/test_jit.py
python tests/test_core.py
test_jit.py는 JIT 경로를, test_core.py는 GEMM 구현을 확인하는 출발점입니다. 통과 여부와 별개로 실제 모델의 대표 행렬 크기와 출력 오차를 추가로 비교해야 도입 판단이 가능합니다.
DeepGEMM이 특히 잘 맞는 경우는 Hopper GPU를 이미 쓰고 있고, 추론이나 학습에서 FP8 GEMM 또는 MoE Grouped GEMM의 비중이 큰 경우입니다. 반대로 다른 GPU 세대이거나 FP8 변환이 준비되지 않았다면 원문에 나온 장점을 그대로 적용할 수 없습니다.
검증 순서는 다음처럼 잡을 수 있습니다.
M/N/K를 수집합니다.메모리 절감, 전력 효율, GPU 수 감소는 FP8과 빠른 GEMM이 만들 수 있는 기대 효과이지만, 이 글에 제시된 표만으로 각각의 절감률을 확정할 수는 없습니다. DeepGEMM의 핵심 가치는 “Hopper에서 FP8을 쓴다”가 아니라, 실제 모델의 계산 모양이 이 커널과 맞을 때 그 병목을 얼마나 줄이는지 측정할 수 있다는 데 있습니다.
Transformer의 attention projection과 MLP는 모두 행렬곱이지만 batch, sequence, hidden size에 따라 M, N, K가 다릅니다. 큰 정사각 행렬에서 빠른 kernel이 작은 batch의 가늘고 긴 행렬에서는 launch overhead 때문에 이득이 작을 수 있습니다. 먼저 profiler에서 자주 나타나는 shape와 호출 횟수를 뽑아야 합니다.
FP8은 값의 범위가 좁으므로 scale을 어떻게 나누는지가 정확도에 영향을 줍니다. 입력과 weight의 분포가 layer마다 다른데 하나의 scale을 넓게 쓰면 작은 값이 손실될 수 있습니다. kernel의 출력 오차만 보지 말고 모델 logits와 최종 task metric이 BF16 baseline에서 얼마나 달라지는지 확인해야 합니다.
TFLOPS나 token/s를 기록할 때 GPU 모델, clock 상태, CUDA와 compiler version, warm-up, 측정 반복, 입력 shape와 dtype을 함께 남깁니다. JIT compile 시간은 반복 서비스에서는 amortize될 수 있지만 shape가 자주 바뀌거나 첫 요청 지연이 중요한 환경에서는 실제 비용입니다. cache가 없는 cold run과 준비된 warm run을 분리합니다.
비교 대상도 같은 조건이어야 합니다. 기존 library의 최적 algorithm 선택과 workspace를 허용하고, 데이터 전송과 layout 변환을 포함한 end-to-end 시간을 잽니다. kernel만 빠르지만 앞뒤 transpose가 추가되면 layer 전체 이득은 줄어듭니다.
극단값이 많은 layer, 작은 batch, 다양한 sequence 길이를 failure set으로 둡니다. NaN, Inf와 최대 절대 오차, 상대 오차를 확인한 뒤 실제 generation을 반복해 출력 붕괴가 없는지 봅니다. dynamic shape가 새로 들어왔을 때 compile, fallback이 어떻게 동작하는지도 중요합니다.
DeepGEMM 도입은 peak benchmark가 아니라 목표 workload의 p50, p95 latency와 throughput, 정확도 차이, cold start를 기존 stack과 나란히 비교해 결정해야 합니다. 특정 shape에서 이득이 없다면 전체를 강제 교체하기보다 잘 맞는 layer에만 선택적으로 적용하는 편이 안전합니다.
아닙니다. GPU architecture, CUDA 환경, 행렬 shape와 dtype에 따라 결과가 달라지므로 목표 하드웨어에서 직접 benchmark해야 합니다.
보장되지 않습니다. scaling 방식과 값 분포에 따라 오차가 커질 수 있어 kernel 오차와 최종 모델 품질을 BF16 기준선과 비교해야 합니다.
네. 반복 호출에서는 줄어들 수 있지만 cold start와 dynamic shape가 중요한 서비스에서는 end-to-end 지연에 포함해야 합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.