A AMD lança ZenDNN 6.1 com otimizações LowOHA, kernels MATMUL e INT8, enquanto colabora com a Intel no oneDNN para PyTorch. Confira a análise completa e os detalhes técnicos agora.
A corrida pela eficiência em inteligência artificial não acontece só nas GPUs. Nas CPUs x86, a briga é por latência baixa, vazão alta e um ecossistema de software que não obligue o desenvolvedor a reescrever o código a cada troca de processador. É nesse tabuleiro que a AMD acaba de mover mais uma peça com o lançamento do ZenDNN 6.1, uma atualização da sua biblioteca de aceleração de redes neurais profundas para arquiteturas Zen.
O movimento chama atenção por um detalhe de estratégia: no mês passado, AMD e Intel anunciaram uma colaboração inédita para unificar otimizações de CPU para PyTorch dentro do oneDNN, biblioteca de código aberto governada pela UXL Foundation.
A parceria já rendeu o oneDNN 3.14, que trouxe as primeiras otimizações para processadores AMD Zen. A pergunta que ficou no ar foi: a AMD abandonaria o ZenDNN? A resposta chegou nesta semana. Não. A empresa continua desenvolvendo sua biblioteca paralela, agora na versão 6.1, enquanto contribui para o esforço conjunto.
Neste artigo, você vai entender o que muda no ZenDNN 6.1, por que a AMD insiste em manter as duas frentes e o que isso significa na prática para quem treina ou faz inferência de modelos em CPUs AMD EPYC e Ryzen.
O que há de novo no ZenDNN 6.1
O ZenDNN 6.1 foi anunciado em 4 de novembro de 2026 e chega como uma evolução do ZenDNN 6.0, lançado em julho. Enquanto a versão anterior focou em um suporte funcional a FP16 e otimizações para modelos de mistura de especialistas (MoE), a 6.1 aprofunda o LowOHA (Low Overhead API), a interface de baixo overhead que se tornou o caminho principal de inferência da biblioteca.
O LowOHA expõe funções diretas como matmul_direct e group_matmul_direct, que operam sobre ponteiros brutos com o mínimo de sobrecarga por chamada. Isso reduz a criação repetitiva de primitivas e faz diferença em cenários de latência sensível, como inferência em tempo real e modelos com muitos GEMMs pequenos.
As principais adições da versão 6.1 incluem:
- Kernels MATMUL agrupados mais rápidos: otimização direta para operações de multiplicação de matrizes em lote, comuns em mecanismos de atenção e roteamento de especialistas em MoE.
- Kernels FP16 e DA8W4: suporte a meia precisão (FP16) e a formatos quantizados específicos (DA8W4), ampliando a gama de modelos que podem se beneficiar da aceleração.
- Kernels MATMUL customizados para DA8W4, DA8W8, INT8 e BF16: cada formato de dados ganha um caminho dedicado, evitando conversões custosas em tempo de execução.
- Pré-empacotamento simétrico INT8: melhora a eficiência de modelos quantizados simetricamente, reduzindo o trabalho de preparação de pesos a cada inferência.
Na prática, o recado é claro: a AMD quer que o ZenDNN seja a via mais rápida para tirar proveito das instruções e da hierarquia de memória das CPUs Zen, sem depender exclusivamente do ritmo de integração do oneDNN.
ZenDNN 6.0: a base que pavimentou o caminho
Para entender o 6.1, vale olhar para o que o 6.0 entregou em julho. O ZenDNN 6.0 foi a primeira versão a adicionar suporte funcional a FP16 mirando os futuros processadores EPYC de 6ª geração.
Operadores como MatMul, BatchMatMul e Embedding ganharam caminhos dedicados em meia precisão, preparando o terreno para uma inferência de modelos maiores com menor pegada de memória.
Além disso, o 6.0 trouxe operadores fusionados de MoE no plugin zentorch, kernels de atenção otimizados e paridade com o vLLM até a versão 0.23.0. Ou seja, a biblioteca já vinha se alinhando ao stack moderno de serving de LLMs, que cada vez mais depende de roteamento esparso e computação condicional.
O 6.1 não substitui esse trabalho: ele o aprofunda. Enquanto o 6.0 expandiu a cobertura de operadores e formatos, o 6.1 lapida o desempenho dos caminhos já existentes, especialmente no LowOHA.
Produto Recomendado
Você já percebeu que a maioria das pessoas só conversa com o ChatGPT... enquanto uma minoria está criando agentes de IA que executam tarefas, tomam decisões e geram receita sozinhos?
O livro "Construindo Aplicações com Agentes de IA: Projeto e Implementação de Sistemas Multiagentes" é o seu mapa prático — do zero à arquitetura profissional.
✅ Projeto e implementação passo a passo
✅ Sistemas multiagentes que colaboram entre si
✅ Aplicações reais para negócios e automação
✅ Linguagem acessível, com rigor técnico
💡 Não é teoria. É engenharia aplicada.
Eu ganho uma comissão quando você faz uma compra.
Por que a AMD mantém o ZenDNN enquanto contribui para o oneDNN?
Essa é a pergunta que muita gente da comunidade técnica se fez depois do anúncio da parceria com a Intel. A resposta tem camadas.
Primeiro, o oneDNN é hoje a biblioteca padrão para aceleração x86 dentro do PyTorch. A integração das otimizações ZenDNN ao oneDNN reduz a fragmentação do ecossistema e dá aos desenvolvedores um caminho comum para rodar cargas de IA tanto em CPUs AMD quanto Intel.
A AMD inclusive se juntou à UXL Foundation como membro do conselho diretor, o que lhe dá voz formal sobre o futuro da biblioteca. Segundo, o ZenDNN continua sendo o campo de testes e o veículo de entrega mais rápido para inovações específicas das arquiteturas Zen.
Nem toda otimização chega ao oneDNN no mesmo ritmo, e a AMD quer garantir que seus clientes tenham acesso imediato a ganhos de desempenho em formatos como DA8W4 e INT8 simétrico.
Terceiro, há uma questão de compatibilidade e legado. O ZenDNN é compatível com a API do oneDNN, o que significa que o código escrito para uma biblioteca pode, em tese, ser portado para a outra com esforço relativamente baixo. Manter as duas linhas permite que a AMD experimente sem quebrar a base instalada.
Em resumo: a AMD não está dividida; está usando duas frentes complementares. O oneDNN é a aposta de longo prazo na padronização; o ZenDNN é a vanguarda de curto prazo no hardware Zen
O que isso significa para desenvolvedores e para o ecossistema
Para quem desenvolve modelos em PyTorch e roda inferência em CPU, a mensagem é positiva. A competição e a colaboração simultâneas tendem a acelerar a maturidade do software.
Se você já usa o oneDNN como backend padrão, o oneDNN 3.14 já traz as primeiras otimizações Zen, mas elas são opt-in: é preciso compilar a biblioteca com a flag ONEDNN_X64_USE_ZEN=ON e, por enquanto, contar com o código do ZenDNN dentro da árvore do oneDNN. Isso mostra que a integração está em andamento, mas ainda não é plug-and-play.
Se você precisa do máximo desempenho em um EPYC de 5ª geração ou em um Ryzen recente, o ZenDNN 6.1 é o caminho mais direto para os kernels mais recentes. A biblioteca é open source e está disponível no GitHub, o que permite auditar, contribuir e integrar ao seu stack.
Para o ecossistema como um todo, o recado é de menos fragmentação no futuro. A colaboração entre AMD e Intel no oneDNN, recomendada pelo x86 Ecosystem Advisory Group, sinaliza que as duas empresas entenderam que a briga por desempenho não precisa vir acompanhada de uma briga por padrões de software. Isso é especialmente relevante diante do avanço de alternativas como Arm e RISC-V no espaço de IA.
Checklist para avaliar o ZenDNN 6.1 no seu fluxo de trabalho
Se você quer testar a nova versão na prática, aqui está um checklist para copiar e colar:
□ Verifique se a sua CPU é uma arquitetura Zen suportada (EPYC de 4ª, 5ª ou 6ª geração, ou Ryzen equivalente).
□ Confirme a versão do PyTorch e do plugin zentorch compatíveis com o ZenDNN 6.1.
□ Baixe o código no repositório oficial do ZenDNN no GitHub e siga as instruções de build com CMake 3.26 ou superior.
□ Ative o LowOHA como caminho de inferência e meça a latência antes e depois.
□ Teste os kernels FP16 e DA8W4 se o seu modelo usar quantização ou meia precisão.
□ Compare o desempenho com o oneDNN 3.14 compilado com ONEDNN_X64_USE_ZEN=ON para entender qual caminho rende mais no seu caso.
□ Valide a acurácia do modelo após a quantização simétrica INT8, especialmente em camadas sensíveis.
□ Monitore o uso de memória e a vazão em cenários de lote (batch) e de requisição única.
Questionário rápido sobre o ZenDNN 6.1
1.Qual é a principal interface de inferência aprofundada no ZenDNN 6.1?
O LowOHA (Low Overhead API), que expõe funções diretas como matmul_direct e group_matmul_direct.
2. Quais formatos de dados ganharam kernels MATMUL customizados na versão 6.1?
Resposta: DA8W4, DA8W8, INT8 e BF16.
3. Por que a AMD continua desenvolvendo o ZenDNN mesmo depois de contribuir com otimizações para o oneDNN?
Resposta: Porque o ZenDNN serve como campo de testes e via de entrega rápida para inovações específicas das arquiteturas Zen, enquanto o oneDNN é a aposta de longo prazo na padronização do ecossistema x86.
Conclusão
O ZenDNN 6.1 é mais do que uma atualização incremental: é um sinal de que a AMD está jogando nos dois tabuleiros ao mesmo tempo, sem abrir mão de nenhum.
De um lado, contribui para o oneDNN e ajuda a construir um caminho comum para PyTorch em CPUs x86. Do outro, mantém o ZenDNN como vitrine de desempenho para suas próprias arquiteturas, com kernels afinados para LowOHA, FP16 e formatos quantizados.
Para o desenvolvedor, o recado é de oportunidade: vale a pena testar as duas rotas, medir no seu workload e escolher a que entrega o melhor equilíbrio entre latência, vazão e esforço de integração.
Para o ecossistema, a notícia é boa: menos fragmentação no horizonte e mais competition na base. E para quem acompanha a disputa x86 contra Arm, o movimento mostra que a dupla AMD-Intel ainda tem cartas para jogar no software.
Nenhum comentário:
Postar um comentário