AIREITERUn repository pubblico su GitHub può far sembrare una piattaforma hardware più accessibile di quanto non sia davvero. Il lavoro di DeepSeek su Ascend è concreto e interessante, ma non trasforma una macchina qualunque in un cluster NVIDIA con un solo comando: la release attuale ruota attorno ai kernel per Ascend 950 e richiede CANN, torch_npu e hardware compatibile.
In breve: componenti aperti, non un cluster Ascend pronto all’uso
DeepSeek ha pubblicato codice specifico per Ascend, tra cui DeepGEMM-Ascend, una libreria di kernel distribuita con licenza MIT che mantiene la forma delle API di DeepGEMM, ma punta agli NPU Huawei. La release iniziale del repository supporta i dispositivi Ascend 950 e indica come parte dell’ambiente CANN 9.20, torch_npu, Python 3.10 o versioni successive, una toolchain C++20 e TileLang.
Per un team che ha già accesso a sistemi Ascend compatibili, è sufficiente per analizzare, compilare, misurare e integrare alcuni kernel. Non è però uno stack completo per il training o la produzione.
I laboratori dotati di Ascend, gli operatori cloud e i team enterprise possono iniziare a valutare il codice. Chi lavora esclusivamente con NVIDIA può studiarlo oppure usare i progetti DeepSeek orientati a NVIDIA, ma non può eseguire questi kernel Ascend su una H100 o su una scheda GeForce consumer.
Che cosa ha rilasciato davvero DeepSeek
L’open-infra-index di DeepSeek organizza il lavoro sull’infrastruttura in diversi livelli. L’indice originale è orientato soprattutto a NVIDIA/Hopper: FlashMLA è un kernel di decoding MLA per GPU Hopper, DeepEP è una libreria per la comunicazione nell’expert parallelism, DeepGEMM è una libreria GEMM FP8, mentre DualPipe ed EPLB si occupano del parallelismo distribuito e 3FS/Smallpond dell’accesso ai dati.
La release specifica per Ascend cambia il bersaglio hardware di alcuni percorsi di calcolo, senza sostituire in un colpo solo tutti gli altri livelli. L’artefatto pubblico più chiaro è DeepGEMM-Ascend, che comprende:
- GEMM in BF16, FP8 e FP4;
- logit MQA;
- percorsi GEMM raggruppati e MegaMoE;
- un kernel mHC prenorm; e
- compilazione JIT e trasformazioni dei layout specifiche per Ascend.
Il progetto dichiara la compatibilità a livello di API con DeepGEMM. È un vantaggio importante per chi sviluppa modelli, ma non rende portabili i binari CUDA. Layout delle matrici, impacchettamento dei fattori di scaling, compilatore, runtime e API per la gestione dei dispositivi Ascend restano elementi distinti.
Mappa dei componenti: gli equivalenti Ascend in uno stack orientato a NVIDIA
La tabella mette a confronto i ruoli, non sostiene che le implementazioni siano identiche. Un equivalente svolge una funzione simile, ma può utilizzare API, interconnessioni o strategie di kernel differenti.
| Livello | Codice o dipendenza Ascend confermata | Equivalente orientato a NVIDIA | Limite del confronto |
|---|---|---|---|
| Moltiplicazione di matrici | DeepGEMM-Ascend | DeepGEMM più kernel CUDA/Tensor Core | Stesso ruolo GEMM, ma primitive hardware e layout dei dati differenti |
| Calcolo raggruppato per MoE | M-Grouped GEMM e MegaMoE in DeepGEMM-Ascend | Layout MoE di DeepGEMM più kernel CUDA personalizzati | Calcolo degli esperti fuso, con forme e limiti specifici della piattaforma |
| Dispatch degli esperti | In questa release non è identificata una libreria completa di dispatch Ascend di DeepSeek; si utilizzano collettive Ascend e integrazioni degli operatori | DeepEP con NVLink/RDMA | Problema di sistema simile, ma repository non intercambiabili |
| Attention/logit | Logit MQA in DeepGEMM-Ascend | FlashMLA per Hopper | Carico di lavoro simile; FlashMLA è esplicitamente focalizzato su Hopper |
| Bridge PyTorch per il dispositivo | TorchNPU (torch_npu) | Backend CUDA di PyTorch, runtime CUDA e cuBLAS | TorchNPU richiama gli NPU Ascend, non emula CUDA |
| Toolchain per compilatore e operatori | CANN e toolchain Ascend C/Bisheng | CUDA Toolkit, NVCC, PTX, cuBLAS, Triton | Il codice Python può sembrare familiare, ma cambia il contratto con il dispositivo |
| Runtime distribuito | Collettive TorchNPU più strumenti Huawei/operatori per il deployment | NCCL, networking compatibile con CUDA e software per cluster NVIDIA | Interconnessione, driver, collettive e versioni dei framework restano separati |
| Percorso storage/dati | Qui non è identificato alcun componente storage specifico per Ascend di DeepSeek; lo storage è fornito dall’operatore | 3FS/Smallpond di DeepSeek più lo stack storage dell’operatore | La release dei kernel non include un cluster storage corrispondente |
In sintesi, ogni equivalente Ascend copre un ruolo nell’architettura, ma non cancella l’ecosistema software NVIDIA.
Kernel di calcolo: DeepGEMM-Ascend e DeepGEMM a confronto
DeepGEMM-Ascend è il ponte più concreto offerto dalla release. Il README lo descrive come un’astrazione leggera sulle primitive MAD di Ascend, capace di nascondere layout frattali, vincoli di allineamento, calcolo degli indirizzi e parametri di basso livello. Il progetto usa inoltre tecniche specifiche di Ascend, come il caricamento sparso dei dati e il pipelining basato su coroutine.
I requisiti pubblicati sono precisi: hardware della serie Ascend 950, CANN 9.20, torch_npu, Python 3.10 o versioni successive, una libreria standard compatibile con C++20, TileLang e dipendenze di build tra cui Tree-sitter. Il percorso di installazione documentato include git clone --recursive seguito da pip install . --no-build-isolation.
Il repository riporta un’utilizzazione del dense GEMM fino al 99.8% del limite hardware dichiarato su una configurazione di test Ascend 950DT. Un caso BF16 è indicato a 431 TFLOPS contro un limite hardware di 432 TFLOPS; i casi FP8 arrivano a 861 contro 865. Sono risultati ottenuti dai kernel con forme selezionate, non prestazioni end-to-end di DeepSeek né una prova di equivalenza con un cluster NVIDIA.
Esecuzione MoE: MegaMoE e dispatch degli esperti
L’open-infra-index di DeepSeek identifica un’infrastruttura di expert parallelism per i sistemi V3/R1. La domanda, quindi, non è soltanto quanto velocemente venga eseguita una moltiplicazione di matrici: i token devono essere instradati, gli esperti devono elaborare i dati e i risultati devono essere ricomposti tra i vari rank.
Il benchmark MegaMoE di DeepGEMM-Ascend fonde dispatch dell’expert parallelism, due GEMM raggruppati, SwiGLU e combine. La configurazione riportata usa EP8, top-k 6, un esperto condiviso e medie calcolate su otto rank. Per un caso con 384 esperti e 16.384 token, il README indica 846.3 TFLOPS per una configurazione hidden/intermediate e 103.3 GB/s di banda di comunicazione per un altro caso riportato.
Il confronto sul versante NVIDIA è DeepEP insieme ai layout MoE di DeepGEMM e all’ambiente NCCL/NVLink/RDMA circostante. Il problema architetturale è simile, ma i numeri non possono essere trasferiti da un produttore all’altro senza allineare quantità di token, instradamento degli esperti, precisione, numero di rank e condizioni della rete.
Kernel specifici per il modello: logit MQA e mHC prenorm
Il progetto Ascend include anche kernel che rischiano di passare inosservati se la release viene descritta soltanto come un “porting di GEMM”. Il README di DeepGEMM-Ascend identifica il benchmark dei logit MQA come parte del percorso DeepSeek Lightning Indexer. Sono riportati casi di prefill e decode in FP8 e FP4; il decode FP4 è indicato a 124.2 microsecondi per la forma documentata, contro i 150.9 microsecondi dell’FP8.
Lo stesso README identifica il kernel HC prenorm come parte del modulo mHC di DeepSeek, cioè Manifold-Constrained Hyper-Connections. Per i valori documentati di N e K, la banda di memoria arriva a 3,463 GB/s con M=8,192. Anche in questo caso si tratta di ottimizzazioni mirate a specifici carichi di lavoro, non della copertura di ogni operatore del modello o di ogni percorso di serving.
Framework e runtime: CANN e TorchNPU contro CUDA
Il repository TorchNPU di Huawei descrive TorchNPU come un adattatore PyTorch per gli NPU Ascend. L’elenco delle funzioni comprende API PyTorch native e personalizzate, FSDP2, DTensor, operazioni collettive, acquisizione dei grafi, profiling, monitoraggio WatchDog e funzioni per la gestione della memoria.
La corrispondenza concettuale lato NVIDIA è PyTorch insieme al runtime CUDA e alle relative librerie. La differenza operativa, però, è sostanziale: un’installazione Ascend richiede versioni compatibili di CANN, driver, firmware, Python, PyTorch e TorchNPU. L’esempio nella documentazione TorchNPU installa CANN 9.1.0, PyTorch 2.12.0 e torch-npu 2.12.0, mentre DeepGEMM-Ascend documenta separatamente CANN 9.20. Questa differenza di versione è un chiaro invito a seguire la matrice di compatibilità di ogni repository, senza mescolare comandi provenienti da guide diverse.
La documentazione ufficiale Huawei descrive CANN come il livello software che collega framework e hardware Ascend, includendo runtime e strumenti per lo sviluppo degli operatori. In pratica, CANN è più vicino alle fondamenta della piattaforma che a una singola libreria CUDA. Un modello PyTorch può conservare la familiare sintassi Python, ma richiedere comunque kernel specifici per Ascend, un comportamento dei grafi differente e procedure di debugging dedicate.
Che cosa resta fuori dalla release
L’indice dell’infrastruttura aperta di DeepSeek include progetti per lo storage e per i sistemi, come 3FS e Smallpond, e descrive anche DualPipe, EPLB e un’architettura per i sistemi di inferenza. Sono riferimenti importanti, ma la release dei kernel specifici per Ascend non va interpretata come un porting completo di tutti questi componenti.
Un cluster di produzione richiede ancora provisioning dell’hardware, driver e firmware, installazione di CANN, configurazione dell’interconnessione, supporto al runtime distribuito, osservabilità, gestione dei checkpoint, recovery dagli errori e un orchestratore per serving o training. La guida al deployment di DeepSeek su Huawei Cloud mostra il lato infrastrutturale con istanze, networking, subnet e security group: sono prerequisiti per il deployment, non componenti di DeepGEMM-Ascend.
Il confine è particolarmente importante per il training. Un insieme di kernel pubblici può ridurre un collo di bottiglia senza dimostrare che un training su scala frontier sia riproducibile usando soltanto i repository disponibili al pubblico.
Chi può usare oggi lo stack
| Utente o organizzazione | Può usarlo subito? | Che cosa serve | Verdetto pratico |
|---|---|---|---|
| Team con hardware Ascend 950 | Sì, per i kernel supportati | Ambiente Linux, driver/firmware compatibili, CANN 9.20, TorchNPU, compilatore e configurazione Python/PyTorch compatibile | Il caso ideale per i primi adottanti |
| Operatore Huawei Cloud o azienda con capacità Ascend | Potenzialmente sì | Un’istanza o un cluster supportato, la matrice software esatta e competenze di deployment | Adatto a valutazioni controllate e serving |
| Laboratorio di ricerca con hardware Ascend meno recente | Non automaticamente | Verificare il supporto del dispositivo; la release iniziale di DeepGEMM-Ascend è stata sviluppata e validata sulla serie Ascend 950 | Non dare per scontata la compatibilità con 910B/910C |
| Proprietario di una workstation solo NVIDIA | No, per i kernel Ascend | L’hardware Ascend è un requisito documentato | Usare invece i repository DeepSeek per NVIDIA |
| Sviluppatore PyTorch senza accesso ad acceleratori | Non in un senso utile per l’esecuzione | Può esaminare il codice e studiare le API, ma non riprodurre i benchmark hardware | Accedere alla documentazione non significa poter eseguire il software |
| Team alla ricerca di un sostituto pronto per il training frontier | No, non esiste ancora una prova pubblica | Servono un cluster completo, integrazione dei sistemi e validazione in produzione oltre i repository dei kernel | Va trattato come un programma infrastrutturale, non come un semplice pip install |
Il limite pratico emerge anche dai requisiti: nella release documentata, il software resta legato all’hardware Ascend 950, a CANN e a torch_npu. È una dichiarazione molto più circoscritta rispetto alla portabilità generale tra acceleratori.
Che cosa dimostrano, e che cosa non dimostrano, i numeri pubblicati
Il dato del 99.8% per il dense GEMM è un’evidenza utile del fatto che il kernel Ascend indicato riesce a sfruttare in modo efficiente il dispositivo testato su forme selezionate. Le tabelle MegaMoE mostrano inoltre che gli ingegneri di DeepSeek hanno affrontato carichi di lavoro con expert parallelism fuso, non soltanto una moltiplicazione di matrici isolata.
Nessuno dei due risultati risponde però alle domande che, alla fine, interessano a un team incaricato degli acquisti o del training:
- Qual è il throughput end-to-end in token al secondo sul modello completo?
- Qual è il costo per token con la dimensione di batch prevista?
- Quanto sono stabili le esecuzioni lunghe e i riavvii?
- Quali operatori ricadono su percorsi meno ottimizzati?
- Come si confrontano interconnessione, memoria e consumi con il cluster NVIDIA previsto?
- Gli stessi risultati sono riproducibili al di fuori dell’ambiente di test originale?
DeepSeek ha pubblicato un lavoro serio sui kernel Ascend, con dettagli di configurazione e tabelle di performance selezionate. La release riduce la barriera software per i team già inseriti nell’ecosistema Ascend, ma le barriere hardware e di compatibilità delle versioni restano.
Domande frequenti
L’infrastruttura Ascend di DeepSeek è completamente open source?
No. DeepGEMM-Ascend e la documentazione collegata sono pubblici, ma il materiale non offre un cluster DeepSeek completo e pronto per il training, con tutte le dipendenze e le procedure operative già definite.
Posso eseguire DeepGEMM-Ascend su una GPU NVIDIA?
No. Il progetto è destinato all’hardware Ascend 950. Gli utenti NVIDIA dovrebbero utilizzare i progetti DeepSeek orientati a NVIDIA.
Questo dimostra che DeepSeek addestra modelli frontier su Ascend?
No. Dimostra che DeepSeek ha pubblicato kernel Ascend e misurato alcuni carichi di lavoro. Non dimostra l’esistenza di una riproduzione pubblica e completa di un training frontier end-to-end.
Usa lo stack se hai già accesso a capacità Ascend supportata e puoi gestire direttamente la compatibilità tra CANN e TorchNPU. Con il solo hardware NVIDIA, considera questa release un riferimento tecnico, non un backend pronto da eseguire.