AIREITERUm repositório público no GitHub pode dar a impressão de que uma stack de hardware está mais acessível do que realmente está. O trabalho da DeepSeek para Ascend é concreto e útil, mas não substitui um cluster NVIDIA com um único comando: a versão atual é centrada em kernels para Ascend 950 e depende de CANN, torch_npu e hardware compatível.
Em resumo: componentes abertos, não um cluster Ascend pronto
A DeepSeek publicou código específico para Ascend, incluindo o DeepGEMM-Ascend, uma biblioteca de kernels sob licença MIT que preserva o formato da API do DeepGEMM, mas tem como alvo os NPUs da Huawei. O lançamento inicial do repositório é compatível com dispositivos Ascend 950 e documenta CANN 9.20, torch_npu, Python 3.10 ou superior, uma toolchain C++20 e o TileLang como parte do ambiente.
Isso já permite que uma equipe com acesso a Ascend compatível inspecione, compile, faça benchmarks e integre kernels específicos. Mas ainda não é uma stack completa de treinamento ou produção.
Laboratórios equipados com Ascend, provedores de nuvem e equipes corporativas já podem avaliar o código. Quem trabalha apenas com NVIDIA pode estudá-lo ou usar os projetos da DeepSeek voltados para NVIDIA, mas não consegue executar esses kernels Ascend em uma H100 ou em uma placa GeForce para consumidor.
O que a DeepSeek realmente lançou
O open-infra-index da DeepSeek organiza o trabalho de infraestrutura em camadas. O índice original é majoritariamente orientado a NVIDIA/Hopper: o FlashMLA é um kernel de decodificação MLA para GPUs Hopper, o DeepEP é uma biblioteca de comunicação para paralelismo de especialistas, o DeepGEMM é uma biblioteca de GEMM em FP8, enquanto DualPipe e EPLB cuidam do paralelismo distribuído e 3FS/Smallpond tratam do acesso a dados.
O lançamento específico para Ascend muda o alvo de hardware de determinados caminhos de computação, em vez de substituir todas as camadas de uma só vez. O artefato público mais claro é o DeepGEMM-Ascend, que cobre:
- GEMM em BF16, FP8 e FP4;
- logits de MQA;
- caminhos de GEMM agrupado e MegaMoE;
- um kernel de prenorm mHC; e
- compilação JIT e transformações de layout específicas para Ascend.
O projeto afirma ser compatível com a API do DeepGEMM. Essa compatibilidade é valiosa para engenheiros de modelos, mas não torna binários CUDA portáveis. Os layouts de matrizes, o empacotamento dos fatores de escala, o compilador, o runtime e as APIs de gerenciamento de dispositivos do Ascend continuam sendo relevantes.
Mapa de componentes: equivalentes Ascend para uma stack orientada a NVIDIA
A tabela abaixo mapeia funções, não afirma que as implementações sejam idênticas. Um equivalente cumpre um papel semelhante, mas pode usar outra API, outro tecido de comunicação ou outra estratégia de kernels.
| Camada | Código ou dependência Ascend confirmada | Equivalente orientado a NVIDIA | Limite da comparação |
|---|---|---|---|
| Multiplicação de matrizes | DeepGEMM-Ascend | DeepGEMM mais kernels CUDA/Tensor Core | Mesma função de GEMM, mas com primitivas de hardware e layouts de dados diferentes |
| Computação agrupada para MoE | M-Grouped GEMM e MegaMoE no DeepGEMM-Ascend | Layouts MoE do DeepGEMM mais kernels CUDA personalizados | Computação de especialistas fundida, com formatos e limites específicos de cada plataforma |
| Distribuição de especialistas | Nenhuma biblioteca completa de distribuição Ascend da DeepSeek é identificada neste lançamento; use coletivas Ascend e integrações de operadores | DeepEP com NVLink/RDMA | O problema de sistemas é semelhante, mas os repositórios não são intercambiáveis |
| Atenção/logits | Logits de MQA no DeepGEMM-Ascend | FlashMLA para Hopper | Carga de trabalho semelhante; o FlashMLA é explicitamente focado em Hopper |
| Ponte de dispositivo para PyTorch | TorchNPU (torch_npu) | Backend CUDA do PyTorch, runtime CUDA e cuBLAS | O TorchNPU aciona NPUs Ascend; ele não emula CUDA |
| Toolchain de compilador/operadores | CANN e ferramentas Ascend C/Bisheng | CUDA Toolkit, NVCC, PTX, cuBLAS, Triton | O código Python pode parecer familiar, mas o contrato com o dispositivo muda |
| Runtime distribuído | Coletivas do TorchNPU mais ferramentas da Huawei e de implantação de operadores | NCCL, rede compatível com CUDA e software de cluster da NVIDIA | Tecido de comunicação, drivers, coletivas e versões do framework continuam separados |
| Caminho de armazenamento/dados | Nenhum componente de armazenamento específico para Ascend da DeepSeek é identificado aqui; o armazenamento é fornecido pelo operador | 3FS/Smallpond da DeepSeek mais a stack de armazenamento do operador | O lançamento dos kernels não inclui um cluster de armazenamento correspondente |
Em resumo, cada equivalente Ascend cumpre uma função de sistemas; ele não elimina o ecossistema de software da NVIDIA.
Kernels de computação: DeepGEMM-Ascend versus DeepGEMM
O DeepGEMM-Ascend é a ponte mais concreta deste lançamento. O README descreve uma abstração leve sobre as primitivas MAD do Ascend, ocultando layouts fractais, restrições de alinhamento, cálculos de endereços e parâmetros de baixo nível. O projeto também usa técnicas específicas do Ascend, como carregamento esparso de dados e pipeline baseado em corrotinas.
Os requisitos publicados são específicos: hardware da série Ascend 950, CANN 9.20, torch_npu, Python 3.10 ou mais recente, uma biblioteca padrão compatível com C++20, TileLang e dependências de build que incluem Tree-sitter. O caminho de instalação documentado inclui git clone --recursive seguido de pip install . --no-build-isolation.
O repositório informa utilização de até 99,8% do limite de hardware declarado em GEMM denso, em um setup de teste com Ascend 950DT. Um caso em BF16 aparece com 431 TFLOPS contra um limite de hardware de 432 TFLOPS; os casos em FP8 aparecem com 861 contra 865. São resultados de kernels para formatos específicos, não números de throughput ponta a ponta da DeepSeek nem uma prova de paridade com um cluster NVIDIA.
Execução de MoE: MegaMoE e distribuição de especialistas
O open-infra-index da DeepSeek identifica uma infraestrutura de paralelismo de especialistas para seus sistemas V3/R1. Por isso, a questão importante não é apenas a velocidade de uma multiplicação de matrizes. Os tokens precisam ser roteados, os especialistas precisam processá-los e os resultados devem ser combinados entre os ranks.
O benchmark MegaMoE do DeepGEMM-Ascend funde distribuição com paralelismo de especialistas, dois GEMMs agrupados, SwiGLU e combinação. A configuração informada é EP8, top-k 6, um especialista compartilhado e médias calculadas em oito ranks. Para um caso com 384 especialistas e 16.384 tokens, o README informa 846,3 TFLOPS para uma configuração de dimensão oculta/intermediária e 103,3 GB/s de largura de banda de comunicação para outro caso listado.
A comparação com a NVIDIA envolve o DeepEP, os layouts MoE do DeepGEMM e o ambiente ao redor, formado por NCCL/NVLink/RDMA. O problema arquitetural é semelhante, mas os números não podem ser transportados entre fabricantes sem igualar quantidade de tokens, roteamento de especialistas, precisão, número de ranks e condições de rede.
Kernels específicos de modelo: logits de MQA e prenorm mHC
O projeto para Ascend também inclui kernels que podem passar despercebidos quando o lançamento é descrito apenas como “uma porta do GEMM”. O README do DeepGEMM-Ascend identifica seu benchmark de logits de MQA como parte do caminho DeepSeek Lightning Indexer. Ele lista casos de prefill e decodificação em FP8 e FP4; a decodificação em FP4 aparece com 124,2 microssegundos para o formato documentado, contra 150,9 microssegundos em FP8.
O mesmo README identifica seu kernel de prenorm HC para o módulo mHC da DeepSeek, ou Manifold-Constrained Hyper-Connections. A largura de banda de memória listada chega a 3.463 GB/s em M=8.192, para os valores documentados de N e K. Esses números mostram otimização específica para determinadas cargas de trabalho, não cobertura de todos os operadores do modelo ou caminhos de serving.
Framework e runtime: CANN e TorchNPU versus CUDA
O repositório do TorchNPU da Huawei descreve o TorchNPU como um adaptador do PyTorch para NPUs Ascend. A lista de recursos inclui APIs nativas e personalizadas do PyTorch, FSDP2, DTensor, operações coletivas, captura de grafos, criação de perfis, monitoramento WatchDog e recursos de gerenciamento de memória.
O equivalente conceitual na NVIDIA é PyTorch mais o runtime CUDA e suas bibliotecas. A diferença operacional é grande: uma instalação Ascend precisa da versão correspondente do CANN, do driver, do firmware, do Python, do PyTorch e do TorchNPU. A documentação do TorchNPU usa como exemplo a instalação do CANN 9.1.0, PyTorch 2.12.0 e torch-npu 2.12.0, enquanto o DeepGEMM-Ascend documenta separadamente o CANN 9.20. Essa diferença de versão é um alerta para seguir a matriz de compatibilidade de cada repositório, em vez de misturar comandos de guias diferentes.
A documentação da própria Huawei descreve o CANN como a camada de software que conecta frameworks e hardware Ascend, incluindo o runtime e os caminhos de desenvolvimento de operadores. Na prática, o CANN está mais próximo da base da plataforma do que de uma única biblioteca CUDA. Um modelo PyTorch pode manter a sintaxe Python familiar e, ainda assim, exigir kernels específicos para Ascend, comportamento próprio de grafos e procedimentos de depuração diferentes.
O que continua fora do lançamento
O índice original de infraestrutura aberta da DeepSeek inclui projetos de armazenamento e de nível sistêmico, como 3FS e Smallpond, além de descrever o DualPipe, o EPLB e uma arquitetura de sistema de inferência. Esses projetos são referências importantes, mas o lançamento de kernels específico para Ascend não deve ser interpretado como uma migração completa de todos eles.
Um cluster de produção ainda precisa de provisionamento de hardware, drivers e firmware, instalação do CANN, configuração do interconnect, suporte ao runtime distribuído, observabilidade, checkpointing, recuperação de falhas e um orquestrador de serving ou treinamento. O guia de implantação da DeepSeek na Huawei Cloud ilustra o lado da infraestrutura com instâncias, rede, sub-redes e grupos de segurança; esses serviços são pré-requisitos de implantação, não fazem parte do DeepGEMM-Ascend.
Essa separação é especialmente importante no treinamento. Kernels públicos podem aliviar um gargalo sem provar que um treinamento em escala de fronteira é reproduzível apenas com os repositórios públicos.
Quem já consegue usar a stack
| Usuário ou organização | Já pode usar? | O que é necessário | Veredito prático |
|---|---|---|---|
| Equipe com hardware Ascend 950 | Sim, para os kernels compatíveis | Ambiente Linux, driver/firmware correspondentes, CANN 9.20, TorchNPU, compilador e configuração compatível de Python/PyTorch | Perfil mais indicado para adoção inicial |
| Operador da Huawei Cloud ou empresa com capacidade Ascend | Possivelmente | Uma instância/cluster compatível, a matriz exata de software e conhecimento de implantação | Viável para avaliação controlada e serving |
| Laboratório de pesquisa com hardware Ascend mais antigo | Não automaticamente | É preciso confirmar o suporte ao dispositivo; o lançamento inicial do DeepGEMM-Ascend foi desenvolvido e validado na série Ascend 950 | Não presuma compatibilidade com 910B/910C |
| Proprietário de workstation apenas com NVIDIA | Não para os kernels Ascend | O hardware Ascend é um requisito documentado | Use os repositórios da DeepSeek voltados para NVIDIA |
| Desenvolvedor comum de PyTorch sem acesso a aceleradores | Não em um sentido prático de execução | Pode inspecionar o código e estudar as APIs, mas não reproduzir os benchmarks de hardware | Acesso à documentação não é acesso à execução |
| Equipe que busca um substituto pronto para treinamento em escala de fronteira | Não há prova pública disso | É preciso ter um cluster completo, integração de sistemas e validação de produção além dos repositórios de kernels | Trate como um programa de infraestrutura, não como um simples pip install |
O limite prático também aparece nos requisitos: na versão documentada, o software continua vinculado ao hardware Ascend 950, ao CANN e ao torch_npu. É uma afirmação bem mais restrita do que a de portabilidade geral entre aceleradores.
O que os números publicados comprovam — e o que não comprovam
O índice de 99,8% em GEMM denso é uma evidência útil de que o kernel Ascend listado consegue aproveitar bem o dispositivo testado em determinados formatos. As tabelas do MegaMoE acrescentam evidências de que os engenheiros da DeepSeek trataram de cargas de trabalho fundidas e paralelas entre especialistas, e não apenas de uma multiplicação de matrizes isolada.
Nenhum dos dois resultados responde às perguntas que uma equipe de compras ou treinamento fará no fim:
- Qual é o throughput ponta a ponta em tokens por segundo no modelo completo?
- Qual é o custo por token no tamanho de batch desejado?
- Qual é a estabilidade de execuções longas e reinicializações?
- Quais operadores recorrem a caminhos menos otimizados?
- Como interconnect, memória e consumo de energia se comparam ao cluster NVIDIA pretendido?
- Os mesmos resultados podem ser reproduzidos fora do ambiente de teste original?
A DeepSeek publicou um trabalho sério em kernels Ascend, com detalhes de configuração e tabelas de desempenho selecionadas. O lançamento reduz a barreira de software para equipes que já estão dentro do ecossistema Ascend, mas as barreiras de hardware e de versões continuam existindo.
Perguntas frequentes
A infraestrutura Ascend da DeepSeek é totalmente open source?
Não. O DeepGEMM-Ascend e a documentação relacionada são públicos, mas o material não oferece um cluster de treinamento DeepSeek pronto para uso, com todas as dependências e receitas operacionais.
Posso executar o DeepGEMM-Ascend em uma GPU NVIDIA?
Não. Ele tem como alvo o hardware Ascend 950. Usuários de NVIDIA devem recorrer aos projetos da DeepSeek voltados para NVIDIA.
Isso prova que a DeepSeek treina modelos de fronteira em Ascend?
Não. O lançamento prova que a DeepSeek publicou kernels Ascend e mediu cargas de trabalho específicas. Ele não estabelece uma reprodução pública, ponta a ponta, de um treinamento em escala de fronteira.
Use a stack agora se você já controla capacidade Ascend compatível e consegue assumir o trabalho de compatibilidade entre CANN e TorchNPU. Com hardware exclusivamente NVIDIA, trate o lançamento como referência técnica, não como um backend executável.