AIREITEREin öffentliches GitHub-Repository lässt eine Hardware-Plattform schnell zugänglicher erscheinen, als sie tatsächlich ist. DeepSeeks Ascend-Arbeit ist real und nützlich, ersetzt aber keinen NVIDIA-Cluster per Einzeiler: Das aktuelle Release konzentriert sich auf Ascend-950-Kernels und setzt CANN, torch_npu sowie kompatible Hardware voraus.
Die Kurzfassung: offene Komponenten statt schlüsselfertigem Ascend-Cluster
DeepSeek hat Ascend-spezifischen Code veröffentlicht, darunter DeepGEMM-Ascend. Die unter MIT-Lizenz stehende Kernel-Bibliothek behält die API-Struktur von DeepGEMM bei, zielt aber auf Huawei-NPUs. Das erste Release unterstützt Ascend-950-Geräte und nennt CANN 9.20, torch_npu, Python 3.10+, eine C++20-Toolchain und TileLang als Bestandteile der Umgebung.
Für ein Team mit Zugang zu kompatibler Ascend-Hardware reicht das aus, um ausgewählte Kernels zu untersuchen, zu kompilieren, zu benchmarken und zu integrieren. Eine vollständige Trainings- oder Produktionsplattform ist es nicht.
Labore mit Ascend-Systemen, Cloud-Anbieter und Unternehmen können den Code bereits evaluieren. Wer ausschließlich NVIDIA-Hardware besitzt, kann ihn studieren oder DeepSeeks NVIDIA-orientierte Projekte verwenden, die Ascend-Kernels jedoch nicht auf einer H100 oder einer GeForce-Karte ausführen.
Was DeepSeek tatsächlich veröffentlicht hat
DeepSeeks open-infra-index ordnet die Infrastrukturarbeit in verschiedene Ebenen ein. Der ursprüngliche Index ist überwiegend auf NVIDIA/Hopper ausgerichtet: FlashMLA ist ein MLA-Decoding-Kernel für Hopper-GPUs, DeepEP eine Kommunikationsbibliothek für Expert Parallelism, DeepGEMM eine FP8-GEMM-Bibliothek, während DualPipe und EPLB verteilte Parallelisierung adressieren. 3FS und Smallpond kümmern sich um den Datenzugriff.
Das Ascend-Release ändert bei ausgewählten Rechenpfaden das Hardwareziel, ersetzt aber nicht auf einen Schlag jede einzelne Ebene. Das deutlichste öffentliche Ergebnis ist DeepGEMM-Ascend mit Unterstützung für:
- BF16-, FP8- und FP4-GEMM;
- MQA-Logits;
- Grouped-GEMM- und MegaMoE-Pfade;
- einen mHC-Prenorm-Kernel sowie
- Ascend-spezifische JIT-Kompilierung und Layout-Transformationen.
Das Projekt gibt an, API-kompatibel mit DeepGEMM zu sein. Für Model Engineers ist das wertvoll, macht CUDA-Binaries aber nicht automatisch portierbar. Ascends Matrix-Layouts, das Packing der Skalierungsfaktoren, Compiler, Runtime und APIs zur Geräteverwaltung bleiben eigenständige Bestandteile.
Komponentenübersicht: Ascend-Gegenstücke für einen NVIDIA-orientierten Stack
Die folgende Tabelle ordnet ähnliche Aufgaben ein. Sie behauptet nicht, dass die Implementierungen identisch sind. Ein Gegenstück erfüllt eine vergleichbare Funktion, kann aber eine andere API, ein anderes Kommunikationsnetz oder eine andere Kernel-Strategie verwenden.
| Ebene | Bestätigter Ascend-Code oder Abhängigkeit | NVIDIA-orientiertes Gegenstück | Abgrenzung |
|---|---|---|---|
| Matrixmultiplikation | DeepGEMM-Ascend | DeepGEMM plus CUDA-/Tensor-Core-Kernels | Gleiche GEMM-Aufgabe, aber andere Hardware-Primitiven und Datenlayouts |
| Grouped Compute für MoE | M-Grouped GEMM und MegaMoE in DeepGEMM-Ascend | DeepGEMM-MoE-Layouts plus eigene CUDA-Kernels | Zusammengeführte Expert-Berechnung mit plattformspezifischen Shapes und Grenzen |
| Expert Dispatch | In diesem Release ist keine vollständige DeepSeek-Dispatch-Bibliothek für Ascend ausgewiesen; zum Einsatz kommen Ascend-Collectives und Operator-Integrationen | DeepEP mit NVLink/RDMA | Ähnliches Systemproblem, aber keine austauschbaren Repositories |
| Attention/Logits | MQA-Logits in DeepGEMM-Ascend | FlashMLA für Hopper | Ähnliche Arbeitslast; FlashMLA ist ausdrücklich auf Hopper ausgerichtet |
| PyTorch-Geräteanbindung | TorchNPU (torch_npu) | PyTorch-CUDA-Backend, CUDA-Runtime und cuBLAS | TorchNPU spricht Ascend-NPUs an und emuliert CUDA nicht |
| Compiler-/Operator-Toolchain | CANN sowie Ascend-C-/Bisheng-Tools | CUDA Toolkit, NVCC, PTX, cuBLAS, Triton | Der Python-Code kann vertraut wirken, während sich der Gerätevertrag ändert |
| Verteilte Runtime | TorchNPU-Collectives plus Huawei- und Operator-Deployment-Tools | NCCL, CUDA-bewusstes Networking und NVIDIA-Cluster-Software | Netzwerk, Treiber, Collectives und Framework-Versionen bleiben getrennte Themen |
| Storage-/Datenpfad | Hier ist keine Ascend-spezifische DeepSeek-Storage-Komponente ausgewiesen; der Storage wird vom Betreiber bereitgestellt | DeepSeeks 3FS/Smallpond plus der Storage-Stack des Betreibers | Das Kernel-Release enthält keinen passenden Storage-Cluster |
Kurz gesagt: Jedes Ascend-Gegenstück übernimmt eine bestimmte Systemaufgabe, ersetzt aber nicht das NVIDIA-Softwareökosystem.
Compute-Kernels: DeepGEMM-Ascend im Vergleich zu DeepGEMM
DeepGEMM-Ascend ist die greifbarste Brücke in diesem Release. Die README beschreibt eine schlanke Abstraktion über Ascend-MAD-Primitiven, die sich um Fraktal-Layouts, Alignment-Vorgaben, Adressberechnungen und Low-Level-Parameter kümmert. Hinzu kommen Ascend-spezifische Techniken wie Sparse Data Loading und Coroutine-basiertes Pipelining.
Die veröffentlichten Anforderungen sind konkret: Hardware der Ascend-950-Serie, CANN 9.20, torch_npu, Python 3.10 oder neuer, eine C++20-kompatible Standardbibliothek, TileLang sowie Build-Abhängigkeiten wie Tree-sitter. Der dokumentierte Installationsweg umfasst git clone --recursive und anschließend pip install . --no-build-isolation.
Das Repository meldet bei Dense GEMM eine Auslastung von bis zu 99,8 % des angegebenen Hardware-Limits auf einem Ascend-950DT-Testsystem. Ein BF16-Fall wird mit 431 TFLOPS gegenüber einem Hardware-Limit von 432 TFLOPS angegeben; bei FP8 lauten die Werte 861 gegenüber 865. Das sind Kernel-Ergebnisse für ausgewählte Shapes – kein End-to-End-Durchsatz von DeepSeek und kein Beleg für Parität mit einem NVIDIA-Cluster.
MoE-Ausführung: MegaMoE und Expert Dispatch
DeepSeeks open-infra-index nennt Infrastruktur für Expert Parallelism in den V3/R1-Systemen. Entscheidend ist daher nicht nur, wie schnell eine einzelne Matrixmultiplikation läuft: Tokens müssen geroutet, von den Experts verarbeitet und anschließend über mehrere Ranks hinweg wieder zusammengeführt werden.
Der MegaMoE-Benchmark von DeepGEMM-Ascend führt Expert-Parallel-Dispatch, zwei Grouped GEMMs, SwiGLU und Combine zusammen. Die angegebene Konfiguration lautet EP8, Top-k 6, ein Shared Expert; die Mittelwerte werden über acht Ranks gebildet. Für einen Fall mit 384 Experts und 16.384 Tokens nennt die README 846,3 TFLOPS für eine aufgeführte Hidden-/Intermediate-Konfiguration sowie 103,3 GB/s Kommunikationsbandbreite für einen weiteren aufgeführten Fall.
Das NVIDIA-Gegenstück besteht aus DeepEP, den MoE-Layouts von DeepGEMM und der umgebenden NCCL-/NVLink-/RDMA-Umgebung. Das Architekturproblem ist ähnlich, die Zahlen lassen sich ohne identische Tokenzahlen, Expert-Routing, Präzision, Rank-Anzahl und Netzwerkbedingungen jedoch nicht zwischen den Herstellern übertragen.
Modellspezifische Kernels: MQA-Logits und mHC-Prenorm
Das Ascend-Projekt enthält außerdem Kernels, die leicht übersehen werden, wenn das Release nur als „GEMM-Port“ beschrieben wird. Die DeepGEMM-Ascend-README kennzeichnet ihren MQA-Logits-Benchmark als Pfad für den DeepSeek Lightning Indexer. Aufgeführt sind FP8- und FP4-Prefill- sowie Decode-Fälle; FP4 Decode wird für die dokumentierte Shape mit 124,2 Mikrosekunden angegeben, gegenüber 150,9 Mikrosekunden bei FP8.
Dieselbe README ordnet den HC-Prenorm-Kernel dem mHC-Modul von DeepSeek zu, also den Manifold-Constrained Hyper-Connections. Die angegebene Speicherbandbreite erreicht bei M=8.192 für die dokumentierten N- und K-Werte 3.463 GB/s. Die Zahlen zeigen eine Optimierung für konkrete Arbeitslasten, aber keine vollständige Abdeckung aller Modelloperatoren oder Serving-Pfade.
Framework und Runtime: CANN und TorchNPU im Vergleich zu CUDA
Huaweis TorchNPU-Repository beschreibt TorchNPU als PyTorch-Adapter für Ascend-NPUs. Zu den aufgeführten Funktionen gehören native und eigene PyTorch-APIs, FSDP2, DTensor, Collective Operations, Graph Capture, Profiling, WatchDog-Monitoring und Funktionen zur Speicherverwaltung.
Das konzeptionelle NVIDIA-Gegenstück ist PyTorch zusammen mit der CUDA-Runtime und den CUDA-Bibliotheken. Operativ ist der Unterschied erheblich: Eine Ascend-Installation benötigt zueinander passende Versionen von CANN, Treiber, Firmware, Python, PyTorch und TorchNPU. Das Beispiel in der TorchNPU-Dokumentation installiert CANN 9.1.0, PyTorch 2.12.0 und torch-npu 2.12.0, während DeepGEMM-Ascend separat CANN 9.20 dokumentiert. Dieser Versionsunterschied ist ein deutlicher Hinweis darauf, die Kompatibilitätsmatrix des jeweiligen Repositorys zu befolgen, statt Befehle aus unterschiedlichen Anleitungen zu kombinieren.
Huaweis eigene CANN-Dokumentation beschreibt CANN als Softwareschicht zwischen Frameworks und Ascend-Hardware, einschließlich Runtime- und Operator-Entwicklungspfaden. In der Praxis ist CANN eher das Plattformfundament als eine einzelne CUDA-Bibliothek. Ein PyTorch-Modell kann zwar vertraute Python-Syntax behalten, benötigt aber weiterhin Ascend-spezifische Kernels, Graph-Verhalten und Debugging-Abläufe.
Was nicht Bestandteil des Releases ist
DeepSeeks ursprünglicher Open-Infrastructure-Index umfasst mit 3FS und Smallpond auch Storage- und Systemprojekte und beschreibt außerdem DualPipe, EPLB sowie eine Architektur für Inferenzsysteme. Diese Projekte sind wichtige Referenzpunkte, doch das Ascend-spezifische Kernel-Release ist nicht als vollständiger Port all dieser Komponenten zu verstehen.
Für einen Produktionscluster braucht es weiterhin Hardware-Bereitstellung, Treiber und Firmware, eine CANN-Installation, die Konfiguration des Interconnects, Support für die verteilte Runtime, Observability, Checkpointing, Fehlerbehandlung sowie einen Orchestrator für Serving oder Training. Huaweis DeepSeek-Deployment-Leitfaden zeigt die Infrastrukturseite anhand von Instanzen, Netzwerken, Subnetzen und Security Groups. Diese Dienste sind Voraussetzungen für das Deployment, aber kein Bestandteil von DeepGEMM-Ascend.
Diese Abgrenzung ist beim Training besonders wichtig. Öffentliche Kernels können einen Engpass beseitigen, beweisen aber nicht, dass sich ein Training auf Frontier-Niveau allein aus den öffentlichen Repositories reproduzieren lässt.
Wer den Stack heute nutzen kann
| Nutzer oder Organisation | Jetzt nutzbar? | Voraussetzungen | Praktische Einschätzung |
|---|---|---|---|
| Team mit Ascend-950-Hardware | Ja, für unterstützte Kernels | Linux-Umgebung, passende Treiber/Firmware, CANN 9.20, TorchNPU, Compiler sowie kompatible Python-/PyTorch-Umgebung | Am besten geeigneter Early Adopter |
| Huawei-Cloud- oder Enterprise-Betreiber mit Ascend-Kapazität | Potenziell ja | Eine unterstützte Instanz oder ein unterstützter Cluster sowie die exakte Software-Matrix und Deployment-Erfahrung | Für kontrollierte Evaluierungen und Serving realistisch |
| Forschungslabor mit älterer Ascend-Hardware | Nicht automatisch | Geräteunterstützung prüfen; das erste DeepGEMM-Ascend-Release wurde auf der Ascend-950-Serie entwickelt und validiert | Kompatibilität mit 910B/910C nicht voraussetzen |
| Besitzer einer reinen NVIDIA-Workstation | Nein, nicht für die Ascend-Kernels | Ascend-Hardware ist eine dokumentierte Voraussetzung | Stattdessen die NVIDIA-DeepSeek-Repositories verwenden |
| Gewöhnlicher PyTorch-Entwickler ohne Accelerator-Zugang | Nicht in einem praktisch relevanten Laufzeit-Sinn | Der Code und die APIs lassen sich untersuchen, die Hardware-Benchmarks aber nicht reproduzieren | Dokumentationszugang ist kein Ausführungszugang |
| Team auf der Suche nach einem schlüsselfertigen Ersatz für Frontier-Training | Nein, dafür gibt es noch keinen öffentlichen Nachweis | Erforderlich wären ein vollständiger Cluster, Systemintegration und Produktionsvalidierung über die Kernel-Repositories hinaus | Als Infrastrukturprogramm behandeln, nicht als pip install |
Die praktische Grenze zeigt sich auch in den Anforderungen: Das Release bleibt an Ascend-950-Hardware, CANN und torch_npu gebunden. Das ist eine deutlich engere Aussage als allgemeine Accelerator-Portabilität.
Was die veröffentlichten Zahlen belegen – und was nicht
Die Zahl von 99,8 % bei Dense GEMM ist ein brauchbarer Hinweis darauf, dass der angegebene Ascend-Kernel ausgewählte Shapes auf dem getesteten Gerät effizient ausführen kann. Die MegaMoE-Tabellen zeigen außerdem, dass DeepSeeks Entwickler sich mit zusammengeführten Expert-Parallel-Arbeitslasten beschäftigt haben und nicht nur mit einer isolierten Matrixmultiplikation.
Keine der beiden Messungen beantwortet jedoch die Fragen, die sich ein Beschaffungs- oder Trainingsteam am Ende stellt:
- Wie hoch ist der End-to-End-Durchsatz in Tokens pro Sekunde beim vollständigen Modell?
- Wie hoch sind die Kosten pro Token bei der Ziel-Batchgröße?
- Wie stabil laufen langfristige Jobs und Neustarts?
- Welche Operatoren fallen auf weniger optimierte Pfade zurück?
- Wie schneiden Interconnect, Speicher und Leistungsaufnahme im Vergleich zum geplanten NVIDIA-Cluster ab?
- Lassen sich dieselben Ergebnisse außerhalb der ursprünglichen Testumgebung reproduzieren?
DeepSeek hat ernstzunehmende Ascend-Kernel-Arbeit mit Einrichtungsdetails und ausgewählten Performancetabellen veröffentlicht. Das Release senkt die Softwarehürde für Teams, die bereits im Ascend-Ökosystem arbeiten. Die Hardware- und Versionshürden bleiben jedoch bestehen.
FAQ
Ist DeepSeek Ascend Infrastructure vollständig Open Source?
Nein. DeepGEMM-Ascend und die zugehörige Dokumentation sind öffentlich, liefern aber keinen schlüsselfertigen DeepSeek-Trainingscluster mit sämtlichen Abhängigkeiten und Betriebsanleitungen.
Kann ich DeepGEMM-Ascend auf einer NVIDIA-GPU ausführen?
Nein. Das Projekt zielt auf Ascend-950-Hardware. NVIDIA-Nutzer sollten die NVIDIA-orientierten DeepSeek-Projekte verwenden.
Beweist das, dass DeepSeek Frontier-Modelle auf Ascend trainiert?
Nein. Es belegt, dass DeepSeek Ascend-Kernels veröffentlicht und ausgewählte Arbeitslasten gebenchmarkt hat. Eine öffentliche End-to-End-Reproduktion eines Frontier-Trainings lässt sich daraus nicht ableiten.
Wer bereits über unterstützte Ascend-Kapazitäten verfügt und die Kompatibilitätsarbeit rund um CANN und TorchNPU übernehmen kann, kann den Stack jetzt ausprobieren. Mit NVIDIA-Hardware allein sollte man das Release als technische Referenz betrachten, nicht als ausführbares Backend.