AIREITERGitHub에 공개된 저장소만 보면 특정 하드웨어 스택을 누구나 바로 쓸 수 있을 것처럼 보이기 쉽습니다. DeepSeek의 Ascend 작업은 분명 실체가 있고 유용하지만, NVIDIA 클러스터를 한 번에 대체하는 구성은 아닙니다. 현재 공개된 내용은 Ascend 950용 커널을 중심으로 하며, CANN과 torch_npu, 호환 하드웨어가 필요합니다.
핵심부터 말하면: 완제품 Ascend 클러스터가 아닌 공개 구성 요소
DeepSeek은 Huawei NPU를 겨냥한 Ascend 전용 코드를 공개했습니다. 그중 DeepGEMM-Ascend는 MIT 라이선스로 제공되는 커널 라이브러리로, DeepGEMM의 API 형태를 유지하면서 Huawei NPU를 대상으로 합니다. 최초 공개 버전은 Ascend 950 장치를 지원하며, 환경 구성 요소로 CANN 9.20, torch_npu, Python 3.10 이상, C++20 툴체인, TileLang을 명시하고 있습니다.
호환되는 Ascend 환경을 갖춘 팀이라면 이 코드로 일부 커널을 살펴보고 빌드한 뒤 벤치마크와 통합 작업을 진행할 수 있습니다. 하지만 전체 학습 스택이나 운영 환경을 통째로 제공하는 것은 아닙니다.
Ascend 장비를 보유한 연구소와 클라우드 사업자, 기업 팀은 지금도 코드를 평가할 수 있습니다. 반면 NVIDIA 장비만 가진 개발자는 코드를 연구하거나 DeepSeek의 NVIDIA용 프로젝트를 사용할 수 있을 뿐, H100이나 일반 GeForce 카드에서 이 Ascend 커널을 실행할 수는 없습니다.
DeepSeek이 실제로 공개한 것
DeepSeek의 open-infra-index는 인프라 작업을 여러 계층으로 나눠 소개합니다. 기존 인덱스는 주로 NVIDIA/Hopper 환경을 전제로 합니다. FlashMLA는 Hopper GPU용 MLA 디코딩 커널이고, DeepEP는 전문가 병렬 통신 라이브러리입니다. DeepGEMM은 FP8 GEMM 라이브러리이며, DualPipe와 EPLB는 분산 병렬 처리를, 3FS와 Smallpond는 데이터 접근을 담당합니다.
Ascend 전용 공개 코드는 모든 계층을 한 번에 교체하기보다, 특정 연산 경로의 하드웨어 대상을 바꾸는 데 초점을 둡니다. 현재 가장 명확하게 확인할 수 있는 결과물은 DeepGEMM-Ascend이며, 다음 작업을 포함합니다.
- BF16, FP8, FP4 GEMM;
- MQA logits;
- 그룹화된 GEMM과 MegaMoE 경로;
- mHC prenorm 커널; 그리고
- Ascend 전용 JIT 컴파일 및 레이아웃 변환.
이 프로젝트는 DeepGEMM과 API 호환성을 제공한다고 설명합니다. 모델 엔지니어에게는 중요한 장점이지만, 그렇다고 CUDA 바이너리를 그대로 이식할 수 있다는 뜻은 아닙니다. Ascend의 행렬 레이아웃, 스케일링 팩터 패킹 방식, 컴파일러, 런타임, 장치 관리 API가 모두 별도로 작동합니다.
구성 요소 비교: NVIDIA 중심 스택에 대응하는 Ascend 기술
아래 표는 구현이 동일하다는 뜻이 아니라 각 구성 요소의 역할을 비교한 것입니다. 대응 기술은 비슷한 문제를 해결하지만, API와 통신 패브릭, 커널 전략은 다를 수 있습니다.
| 계층 | 확인된 Ascend 코드 또는 의존성 | NVIDIA 중심 대응 기술 | 한계 |
|---|---|---|---|
| 행렬 곱셈 | DeepGEMM-Ascend | DeepGEMM 및 CUDA/Tensor Core 커널 | GEMM 역할은 같지만 하드웨어 프리미티브와 데이터 레이아웃은 다름 |
| MoE 그룹 연산 | DeepGEMM-Ascend의 M-Grouped GEMM과 MegaMoE | DeepGEMM MoE 레이아웃 및 커스텀 CUDA 커널 | 퓨전된 전문가 연산이지만 플랫폼별 shape와 한계가 존재함 |
| 전문가 디스패치 | 이번 공개 버전에서 DeepSeek의 완성된 Ascend 디스패치 라이브러리는 확인되지 않음; Ascend collective 및 연산자 통합을 사용해야 함 | NVLink/RDMA 기반 DeepEP | 비슷한 시스템 문제를 다루지만 저장소를 서로 바꿔 쓸 수 있는 것은 아님 |
| 어텐션/logits | DeepGEMM-Ascend의 MQA logits | Hopper용 FlashMLA | 처리 대상은 비슷하지만 FlashMLA는 명시적으로 Hopper에 초점을 둠 |
| PyTorch 장치 연결 계층 | TorchNPU (torch_npu) | PyTorch CUDA 백엔드, CUDA 런타임 및 cuBLAS | TorchNPU는 Ascend NPU를 호출할 뿐 CUDA를 에뮬레이션하지 않음 |
| 컴파일러/연산자 툴체인 | CANN 및 Ascend C/Bisheng 도구 | CUDA Toolkit, NVCC, PTX, cuBLAS, Triton | Python 코드가 익숙해 보여도 장치와의 계약은 달라짐 |
| 분산 런타임 | TorchNPU collective 및 Huawei/연산자 배포 도구 | NCCL, CUDA 인식 네트워킹 및 NVIDIA 클러스터 소프트웨어 | 패브릭, 드라이버, collective, 프레임워크 버전은 별도로 맞춰야 함 |
| 스토리지/데이터 경로 | 이 문서에서 DeepSeek의 Ascend 전용 스토리지 구성 요소는 확인되지 않음; 스토리지는 운영자가 제공 | DeepSeek의 3FS/Smallpond 및 운영자의 스토리지 스택 | 커널 공개본에 대응하는 스토리지 클러스터는 포함되지 않음 |
정리하면, 각 Ascend 대응 기술은 시스템에서 비슷한 역할을 맡지만 NVIDIA 소프트웨어 생태계 전체를 없애주는 것은 아닙니다.
컴퓨트 커널: DeepGEMM-Ascend와 DeepGEMM
DeepGEMM-Ascend는 이번 공개에서 가장 구체적인 연결 고리입니다. README에 따르면 Ascend MAD 프리미티브 위에 가벼운 추상화 계층을 제공해 fractal 레이아웃, 정렬 제약, 주소 계산, 저수준 파라미터를 감춥니다. 희소 데이터 로딩과 코루틴 기반 파이프라이닝 같은 Ascend 전용 기법도 사용합니다.
요구 사항은 구체적입니다. Ascend 950 시리즈 하드웨어, CANN 9.20, torch_npu, Python 3.10 이상, C++20 호환 표준 라이브러리, TileLang이 필요합니다. Tree-sitter를 포함한 빌드 의존성도 요구됩니다. 문서에 안내된 설치 과정은 git clone --recursive를 실행한 뒤 pip install . --no-build-isolation을 수행하는 방식입니다.
저장소에는 Ascend 950DT 테스트 환경에서 dense-GEMM이 명시된 하드웨어 한도의 최대 99.8%까지 활용됐다고 나와 있습니다. BF16 사례 중 하나는 하드웨어 한도 432 TFLOPS에 대해 431 TFLOPS로, FP8 사례는 865에 대해 861로 기록돼 있습니다. 다만 이는 특정 shape에서 측정한 커널 결과입니다. DeepSeek 전체 모델의 엔드투엔드 처리량이나 NVIDIA 클러스터와의 성능 동등성을 입증하는 수치는 아닙니다.
MoE 실행: MegaMoE와 전문가 디스패치
DeepSeek의 open-infra-index는 V3/R1 시스템을 위한 전문가 병렬 인프라를 소개합니다. 따라서 중요한 것은 단일 행렬 곱셈의 속도만이 아닙니다. 토큰을 라우팅하고, 전문가가 연산을 수행한 뒤, 여러 rank 사이에서 결과를 다시 결합해야 합니다.
DeepGEMM-Ascend의 MegaMoE 벤치마크는 전문가 병렬 디스패치와 두 번의 그룹화된 GEMM, SwiGLU, combine 작업을 하나로 묶습니다. 공개된 구성은 EP8, top-k 6, 공유 전문가 1개이며, 8개 rank에서 평균을 냅니다. 전문가 384개와 토큰 16,384개를 사용하는 사례에서 README는 특정 hidden/intermediate 구성에 대해 846.3 TFLOPS를, 다른 사례에 대해서는 통신 대역폭 103.3 GB/s를 기록합니다.
NVIDIA 쪽에 대응하는 구성은 DeepEP와 DeepGEMM의 MoE 레이아웃, 그리고 NCCL/NVLink/RDMA 환경입니다. 해결하려는 아키텍처 문제는 유사하지만, 토큰 수와 전문가 라우팅, 정밀도, rank 수, 네트워크 조건을 맞추지 않고는 제조사 간 수치를 그대로 비교할 수 없습니다.
모델 전용 커널: MQA logits와 mHC prenorm
이번 Ascend 프로젝트에는 공개 내용을 단순히 “GEMM 포팅”이라고 부르면 놓치기 쉬운 커널도 포함돼 있습니다. DeepGEMM-Ascend README는 MQA logits 벤치마크를 DeepSeek Lightning Indexer 경로용으로 설명합니다. FP8과 FP4의 prefill 및 decode 사례를 제시하며, FP4 decode는 문서에 기재된 shape에서 124.2마이크로초, FP8은 150.9마이크로초로 기록돼 있습니다.
같은 README는 HC prenorm 커널을 DeepSeek의 mHC 모듈, 즉 Manifold-Constrained Hyper-Connections용으로 설명합니다. 문서에 제시된 N과 K 값에서 M=8,192일 때 메모리 대역폭은 3,463 GB/s에 이릅니다. 이런 수치는 특정 워크로드에 맞춘 최적화를 보여줄 뿐, 모든 모델 연산자나 서빙 경로를 지원한다는 의미는 아닙니다.
프레임워크와 런타임: CANN과 TorchNPU, CUDA와의 차이
Huawei의 TorchNPU 저장소는 TorchNPU를 Ascend NPU용 PyTorch 어댑터로 설명합니다. 기능 목록에는 네이티브 및 커스텀 PyTorch API, FSDP2, DTensor, collective 연산, 그래프 캡처, 프로파일링, WatchDog 모니터링, 메모리 관리 기능이 포함돼 있습니다.
NVIDIA 쪽의 개념적 대응 관계는 PyTorch와 CUDA 런타임 및 라이브러리입니다. 하지만 실제 운영 단계의 차이는 큽니다. Ascend 설치에는 호환되는 CANN 릴리스와 드라이버, 펌웨어, Python 버전, PyTorch 버전, TorchNPU 버전을 함께 맞춰야 합니다. TorchNPU 문서의 예제는 CANN 9.1.0, PyTorch 2.12.0, torch-npu 2.12.0을 설치하지만, DeepGEMM-Ascend는 별도로 CANN 9.20을 요구합니다. 서로 다른 가이드의 명령을 섞지 말고 각 저장소의 호환성 매트릭스를 따라야 하는 이유입니다.
Huawei의 CANN 문서는 CANN을 프레임워크와 Ascend 하드웨어를 연결하는 소프트웨어 계층으로 설명하며, 런타임과 연산자 개발 경로를 모두 포함한다고 밝힙니다. 실제로 CANN은 단일 CUDA 라이브러리보다는 플랫폼 기반에 가까운 역할을 합니다. PyTorch 모델의 Python 문법은 익숙하게 유지할 수 있지만, Ascend 전용 커널과 그래프 동작, 디버깅 절차는 별도로 익혀야 합니다.
이번 공개 범위에 포함되지 않은 것
DeepSeek의 기존 오픈 인프라 인덱스에는 3FS와 Smallpond 같은 스토리지 및 시스템 수준 프로젝트가 포함돼 있으며, DualPipe와 EPLB, 추론 시스템 아키텍처도 설명합니다. 이 프로젝트들은 중요한 참고 자료지만, Ascend 전용 커널 공개본을 이들 모두의 완전한 포팅으로 해석해서는 안 됩니다.
실제 운영 클러스터에는 하드웨어 프로비저닝, 드라이버와 펌웨어, CANN 설치, 인터커넥트 설정, 분산 런타임 지원, 관측 가능성, 체크포인트, 장애 복구, 서빙 또는 학습 오케스트레이터가 추가로 필요합니다. Huawei Cloud의 DeepSeek 배포 가이드는 인스턴스와 네트워킹, 서브넷, 보안 그룹을 통해 인프라 측면을 보여줍니다. 하지만 이런 서비스는 DeepGEMM-Ascend에 포함된 기능이 아니라 배포를 위한 전제 조건입니다.
이 경계는 학습 환경에서 특히 중요합니다. 공개 커널이 병목 하나를 줄여줄 수는 있지만, 공개 저장소만으로 프런티어급 학습을 재현할 수 있다는 뜻은 아닙니다.
현재 이 스택을 사용할 수 있는 사람
| 사용자 또는 조직 | 지금 사용할 수 있나? | 필요 조건 | 현실적인 판단 |
|---|---|---|---|
| Ascend 950 하드웨어를 보유한 팀 | 지원되는 커널에 한해 가능 | Linux 환경, 호환 드라이버/펌웨어, CANN 9.20, TorchNPU, 컴파일러, 호환되는 Python/PyTorch 구성 | 가장 적합한 초기 사용자 |
| Ascend 용량을 보유한 Huawei Cloud 또는 기업 운영자 | 잠재적으로 가능 | 지원되는 인스턴스/클러스터와 정확한 소프트웨어 매트릭스, 배포 전문성 | 통제된 평가와 서빙에 적합 |
| 구형 Ascend 하드웨어를 보유한 연구소 | 자동으로 지원되지는 않음 | 장치 지원 여부를 확인해야 함; 최초 DeepGEMM-Ascend 공개본은 Ascend 950 시리즈에서 개발 및 검증됨 | 910B/910C 호환성을 당연하게 여기지 말 것 |
| NVIDIA 전용 워크스테이션 사용자 | Ascend 커널은 사용할 수 없음 | 문서에 Ascend 하드웨어가 필수 조건으로 명시됨 | 대신 NVIDIA용 DeepSeek 저장소를 사용해야 함 |
| 가속기 없이 PyTorch를 사용하는 일반 개발자 | 실행 측면에서는 의미 있게 사용할 수 없음 | 코드를 확인하고 API를 연구할 수는 있지만 하드웨어 벤치마크를 재현할 수는 없음 | 문서에 접근할 수 있다고 실행할 수 있는 것은 아님 |
| 턴키 방식의 프런티어 학습 대체재를 찾는 팀 | 아직 공개적으로 입증되지 않음 | 커널 저장소를 넘어 완전한 클러스터와 시스템 통합, 운영 검증이 필요함 | pip 설치가 아니라 인프라 프로그램으로 봐야 함 |
요구 사항만 봐도 현실적인 경계는 분명합니다. 문서에 나온 공개 버전은 Ascend 950 하드웨어와 CANN, torch_npu에 묶여 있습니다. 이는 범용 가속기 이식성보다 훨씬 좁은 주장입니다.
공개된 수치가 보여주는 것과 보여주지 않는 것
dense-GEMM에서 99.8%라는 수치는 해당 Ascend 커널이 특정 shape에서 테스트 장치를 효율적으로 활용할 수 있다는 근거입니다. MegaMoE 표는 DeepSeek이 단순한 행렬 곱셈 하나만이 아니라, 전문가 병렬 처리가 결합된 워크로드까지 다뤘다는 점을 보여줍니다.
하지만 이 두 결과만으로는 조달이나 학습 팀이 최종적으로 알고 싶어 하는 질문에 답할 수 없습니다.
- 전체 모델에서 엔드투엔드 초당 토큰 수는 얼마인가?
- 목표 배치 크기에서 토큰당 비용은 얼마인가?
- 장시간 실행과 재시작은 얼마나 안정적인가?
- 최적화 수준이 낮은 경로로 폴백되는 연산자는 무엇인가?
- 인터커넥트, 메모리, 전력은 도입하려는 NVIDIA 클러스터와 어떻게 비교되는가?
- 원래 테스트 환경 밖에서도 같은 결과를 재현할 수 있는가?
DeepSeek은 설정 방법과 일부 성능 표를 포함한 실질적인 Ascend 커널 작업을 공개했습니다. 이번 공개는 이미 Ascend 생태계 안에 있는 팀의 소프트웨어 진입 장벽을 낮춰주지만, 하드웨어와 버전이라는 장벽은 여전히 남아 있습니다.
FAQ
DeepSeek Ascend 인프라는 완전히 오픈 소스인가?
아닙니다. DeepGEMM-Ascend와 관련 문서는 공개돼 있지만, 모든 의존성과 운영 절차를 포함한 턴키 방식의 DeepSeek 학습 클러스터를 제공하는 것은 아닙니다.
NVIDIA GPU에서 DeepGEMM-Ascend를 실행할 수 있나?
실행할 수 없습니다. Ascend 950 하드웨어를 대상으로 합니다. NVIDIA 사용자는 NVIDIA용 DeepSeek 프로젝트를 사용해야 합니다.
이 공개 내용이 DeepSeek이 Ascend에서 프런티어 모델을 학습한다는 사실을 입증하나?
아닙니다. DeepSeek이 Ascend 커널을 공개하고 일부 워크로드를 벤치마크했다는 점을 보여줄 뿐입니다. 공개 저장소만으로 프런티어급 학습을 엔드투엔드로 재현할 수 있다는 뜻은 아닙니다.
지원되는 Ascend 용량을 이미 확보했고 CANN/TorchNPU 호환성 문제를 직접 관리할 수 있다면 지금 이 스택을 검토해볼 만합니다. NVIDIA 하드웨어만 있다면 이번 공개를 실행 가능한 백엔드가 아니라 기술 참고 자료로 보는 편이 정확합니다.