AI 자동화 프로젝트 자동화 프레임워크

DeepGEMM(딥시크 CUDA 커널 라이브러리)

DeepSeek가 공개한 NVIDIA CUDA/Tensor Core 커널 라이브러리. GEMM 행렬 곱셈을 FP8·FP4·BF16 경로로 돌리고, Mega MoE와 FP4 Indexer까지 한 코드베이스에 묶었어.

원본

DeepGEMM(딥시크 CUDA 커널 라이브러리)은(는) 여러 환경에서 자동화 흐름을 설계하고 운영하는 데 도움이 되는 자동화 프레임워크입니다. 문서가 어느 정도 갖춰져 있고 유지 신호도 보여서 스타 7200개와 외부 언급 6개를 함께 보면 먼저 살펴볼 만합니다.

저장소 deepseek-ai/DeepGEMM
스타 7200
외부 언급 6
유지보수 PR #316이 2026-04-24에 병합됐고, 2026-05-06 확인 시점에 GitHub UI 기준 open issues 45개였어. 2025-10-15 v2.1.1.post3 릴리스에 더해 2026년 nv_dev 태그가 이어지고 있어.
라이선스 MIT

환경

환경 정보는 아직 없어.

좋은 용도

SM90·SM100 GPU에서 GEMM·MoE 커널이 실제 병목일 때 커널 경로를 바꿔 처리량을 재보고 싶은 팀FP8·FP4·BF16 정밀도별 커널을 한 코드베이스에서 다뤄야 하는 추론 인프라MoE의 dispatch·linear·SwiGLU·combine을 하나의 mega-kernel로 fuse해 GPU 유휴 시간을 줄이려는 경우CUTLASS/CuTe에 기대지 않고 제한된 핵심 커널만 가볍게 유지하려는 저장소

설치

git clone --recursive 후 develop.sh 또는 install.sh 로 설치해. 커널은 미리 컴파일하지 않고 가벼운 JIT 모듈로 runtime에 컴파일돼. 요구 조건은 NVIDIA SM90/SM100 GPU, Python 3.8+, C++20 compiler, PyTorch 2.1+, CUTLASS 4.0+ 이고 CUDA Toolkit은 SM90에서 12.3+(12.9+ 권장), SM100에서 12.9+ 야.

사용 예시

기본 인터페이스는 `D = C + A @ B` 형태의 GEMM 이야. FP8 dense GEMM, grouped GEMM, masked grouped GEMM 처럼 MoE 모델에서 자주 나오는 모양을 따로 다뤄. 첫 호출 JIT 컴파일 지연과 캐시 위치는 `DG_JIT_CACHE_DIR`, `DG_JIT_USE_NVRTC`, `DG_JIT_PRINT_LOAD_TIME` 로 확인해.

연동 방식

큰 LLM 추론 스택에서 반복되는 행렬 곱셈 커널을 DeepGEMM으로 교체해 기존 런타임과 같은 입력으로 p50/p95 지연, tokens/sec, peak memory, DRAM 대역, GPU utilization을 A/B로 비교해. Mega MoE는 NVLink 통신과 tensor core 계산을 겹치는 fused MoE 경로로 붙여 써.

리뷰

DeepGEMMDeepSeek가 공개한 CUDA 기반 Tensor Core 커널 라이브러리예요. GEMM은 모델 안에서 계속 반복되는 행렬 곱셈 작업이고, DeepGEMM은 이 계산을 NVIDIA GPU 커널 경로에서 더 직접 다루게 해줘요. 공식 README는 이걸 FP8·FP4·BF16 GEMM, Mega MoE, MQA scoring, HyperConnection까지 한 CUDA 코드베이스에 모은 라이브러리로 설명해요.

그래서 기사에서 DeepGEMM이 보이면 새 모델 이름보다 “행렬 곱셈과 MoE 실행 경로를 어느 GPU 커널로 돌리나”를 먼저 보면 돼요. 중요한 건 모델 이름을 바꾸지 않고도 추론 병목이 바뀔 수 있다는 점이에요. 같은 가중치라도 GEMM 커널, 정밀도, 런타임, GPU 세대가 달라지면 처리량과 지연 시간이 달라져요. 2026년 4월 PR #304는 Mega MoE가 dispatch, linear 1, SwiGLU, linear 2, combine을 하나의 mega-kernel로 묶고 NVLink 통신과 tensor core 계산을 겹친다고 설명해요. “모델이 더 똑똑해졌다”가 아니라 GPU가 기다리는 시간을 줄이려는 인프라 변경이에요.

사용 예시

기본 인터페이스는 D = C + A @ B 형태의 GEMM이고, FP8 dense GEMM, grouped GEMM, masked grouped GEMM처럼 전문가 혼합 모델에서 자주 나오는 모양을 따로 다뤄요. 설치는 git clone --recursivedevelop.sh 또는 install.sh로 하고, 커널은 미리 컴파일하지 않고 가벼운 JIT 모듈로 runtime에 컴파일돼요.

그래서 “pip 설치가 됐다”에서 끝나는 게 아니라, 실제 입력 모양이 들어왔을 때 어떤 커널이 컴파일되고 캐시되는지, 처음 호출 지연이 얼마인지, 같은 모양을 반복할 때 p95 지연이 안정되는지를 봐야 해요. DG_JIT_CACHE_DIR, DG_JIT_USE_NVRTC, DG_JIT_PRINT_LOAD_TIME 같은 설정은 개발 편의가 아니라 운영 지연과 디버깅에 직접 닿아 있어요.

확인할 점

요구 조건부터 좁아요. README 기준 NVIDIA SM90 또는 SM100 GPU, Python 3.8+, C++20 compiler, PyTorch 2.1+, CUTLASS 4.0+가 필요하고, CUDA Toolkit은 SM90에서 12.3+(12.9+ 권장), SM100에서 12.9+가 필요해요. 일반 앱 서버나 관리형 API만 쓰는 팀이라면 이 조건부터 이미 멀 수 있어요.

숫자는 출처 맥락을 나눠 읽어야 해요. READMEup to 10x NVRTC 컴파일 속도 항목은 2025년 5월 뉴스, H800 1550 TFLOPS 항목은 2025년 4월 뉴스라서 2026년 4월 공개 릴리스 숫자가 아니에요. PR #316의 Mega MoE 표도 DeepSeek 저장소 작성자가 올린 EP8, 8 ranks 평균 커널 벤치마크라서, 내 서비스 전체 지연시간이 같은 배율로 줄어든다고 보면 안 돼요. FP8·FP4 경로를 쓰면 정확도 회귀·NaN/Inf·출력 품질도 같은 평가셋에서 따로 확인해야 하고요. 결론은 바로 적용하라는 게 아니라, 지원 하드웨어와 측정 가능한 GEMM 병목이 있을 때만 작은 A/B로 시험하라는 쪽이에요.