Apple Reabre um Debate de Hardware: Engenharia Reversa Retrospectiva do Neural Engine da Apple
O Neural Engine M1 da Apple voltou a ser analisado, apesar de uma pausa de três anos no projeto de driver Linux criado para compreendê-lo. Engenharia Reversa Retrospectiva do Neural Engine da Apple documenta por que esse acelerador se destacou em redes neurais mais antigas, mas tem dificuldades com as atuais cargas de trabalho de transformers.
Eileen Yoon, ex-colaboradora do Asahi Linux, retomou o trabalho abandonado depois que a Apple mudou a direção de seu hardware. O M5 posiciona um Neural Accelerator dentro de cada núcleo de GPU, ao mesmo tempo que mantém um Neural Engine separado de 16 núcleos. Essa combinação questiona a ideia de que um único acelerador de função fixa deva sustentar as cargas de trabalho de IA generativa em expansão da Apple.
Isso é mais do que uma desmontagem de hardware tardia. A investigação conecta escolhas feitas para redes neurais convolucionais, ou CNNs, da era de 2017 à resposta da Apple aos modelos de linguagem modernos. As GPUs agora pressionam o Neural Engine independente porque os transformers dependem de agendamento flexível e movimentação contínua de memória.
Um Driver M1 Adormecido Tornou-se uma Autópsia de Hardware
O novo trabalho transforma um driver Linux inacabado em um relato do que a Apple originalmente esperava que o machine learning se tornasse.
Yoon desenvolveu anteriormente um driver Linux para ANE capaz de se comunicar com o Neural Engine dentro dos chips M1. O projeto incluía um módulo de kernel, uma biblioteca em espaço de usuário, testes e bindings Python. Ele oferecia um caminho em torno da abstração pública de software da Apple, embora não tornasse o hardware amplamente programável.
O projeto então permaneceu inativo por três anos. Yoon escreve que o ANE parecia especializado demais para justificar mais trabalho no driver. Abrir sua interface de hardware não mudaria quais operações seu fluxo de dados fixo poderia executar com eficiência.
Essa distinção é importante. Um driver convencional pode expor recursos que o hardware já contém. Ele não pode transformar um acelerador de fluxo de dados criado para uma finalidade específica em um processador geral.
A retrospectiva de arquitetura de Yoon, portanto, faz uma pergunta diferente daquela do esforço original do driver. Em vez de perguntar como o Linux pode enviar trabalho, ela examina a matriz de computação, o agendador, o sistema de memória e o modelo de execução. Esses componentes revelam as premissas de carga de trabalho incorporadas ao design do M1.
A investigação descreve 16 núcleos de computação organizados em torno de um bloco central de memória local. Cada núcleo contém unidades paralelas de multiplicação e acumulação, ou MACs, que multiplicam entradas e adicionam os resultados a acumuladores. Essas operações sustentam convoluções, multiplicação de matrizes e os produtos escalares usados por mecanismos de atenção.
As unidades MAC, por si só, não explicam a especialização do Neural Engine. CNNs e transformers precisam de multiplicação e acumulação. A diferença decisiva está em como pesos e ativações chegam a essas unidades, permanecem disponíveis e se movem pelo chip.
A Apple apresentou seu primeiro Neural Engine com o A11 Bionic em 2017. Naquele momento, as redes neurais voltadas ao consumidor se concentravam em classificação de imagens, análise facial e outras cargas de trabalho densas de CNN. Essas redes ofereciam formas de tensor regulares e reutilização previsível.
O M1 herdou essa linhagem de design quando a Apple levou seus próprios processadores ao Mac. Seu Neural Engine foi otimizado para modelos compilados cujas dimensões e padrões de movimentação eram substancialmente conhecidos de antemão. Essa especialização reduziu a latência e o consumo de energia em tarefas compatíveis.
A retrospectiva não afirma que o Neural Engine M1 não possa executar operações de transformer. Ela argumenta que o fluxo de dados ao redor torna alguns padrões de transformer ineficientes, especialmente a decodificação autorregressiva. Esse processo gera um token de cada vez enquanto relê repetidamente os pesos do modelo e um cache de atenção em crescimento.
Esse reenquadramento cria a tensão central do artigo. A Apple construiu um mecanismo eficiente ao restringir a movimentação de dados em torno de uma carga de trabalho esperada. A IA moderna mudou a carga de trabalho dominante mais rápido do que uma arquitetura de hardware fixa poderia mudar.
A Engenharia Reversa Retrospectiva do Neural Engine da Apple Expõe a Restrição Real
A limitação definidora do Neural Engine M1 não é a capacidade aritmética; é o caminho que os dados precisam percorrer ao redor dessa aritmética.
O driver submetido à engenharia reversa nunca envia comandos de alto nível como CONV, MATMUL ou RELU diretamente ao hardware. O compilador da Apple já converteu essas operações neurais em descritores de tarefa antes do início da execução.
Um descritor de tarefa é um bloco estruturado de dados de configuração. Ele programa grupos de registradores que controlam dimensões de tensores, endereços de memória, funções de ativação, dependências e transferências de dados. O driver coloca o descritor na memória, direciona o gerenciador de tarefas a ele e aciona uma "campainha" de hardware.
Após esse envio, o Neural Engine controla o trabalho até sua conclusão. Ele gera uma interrupção quando a tarefa termina. O processador host não direciona cada instrução matemática enquanto a operação está em execução.
Yoon conclui que o ANE não possui um conjunto de instruções no sentido familiar de CPU ou GPU. Seus descritores de tarefa configuram um fluxo de dados específico de domínio em vez de fornecer um programa arbitrário. Cada descritor representa uma passagem por esse fluxo de dados.
A tarefa começa carregando registradores de configuração. Blocos de transferência dedicados então movem pesos e ativações de entrada da memória principal para armazenamentos locais separados. Os núcleos de computação realizam reduções, o pós-processamento aplica uma ativação, e outro bloco de transferência devolve o resultado.
Essa sequência favorece operações com reutilização previsível. Uma convolução pode aplicar o mesmo conjunto compacto de filtros aprendidos em muitas regiões de uma imagem. O acelerador consegue manter suas unidades aritméticas ocupadas sem recuperar repetidamente um grande conjunto novo de pesos.
A decodificação de transformers altera esse equilíbrio. Cada novo token pode exigir o streaming por uma parcela substancial dos parâmetros do modelo. A aritmética continua reconhecível, mas a movimentação de dados se torna o custo limitante.
O layout do M1 agrava o problema porque separa a memória usada para pesos da memória local usada para blocos de ativação. Yoon identifica aproximadamente 1 MiB de memória de kernel e 2 MiB de memória de blocos no design. A investigação argumenta que a arquitetura não foi organizada para reinterpretar eficientemente tensores produzidos localmente como pesos.
Essa era uma premissa razoável para os modelos que a Apple visava em 2017. A inferência de CNN geralmente trata os pesos aprendidos como kernels fixos e as ativações como dados que fluem entre camadas. A atenção de transformers torna essa distinção menos nítida porque valores produzidos durante a execução podem alimentar operações matriciais posteriores.
Um cache de chave-valor ilustra o problema. O cache armazena representações de tokens anteriores para que o modelo possa reutilizá-las durante a geração. Seu conteúdo cresce à medida que a conversa ou o documento se prolonga, tornando o acesso eficiente à memória cada vez mais importante.
Dimensões fixas de tensor não são o obstáculo central. Uma tarefa compilada pode iterar sobre um comprimento de cache variável, e a sobrecarga do envio de tarefas pode permanecer pequena. A questão mais difícil é alimentar repetidamente os dados por caminhos projetados em torno da reutilização de CNNs.
É por isso que números brutos de operações por segundo oferecem uma comparação incompleta. O pico de throughput aritmético descreve a rapidez com que a matriz de MACs pode trabalhar em condições favoráveis. Ele não revela com que frequência essas unidades esperam por pesos, ativações ou resultados intermediários.
Pesquisas independentes chegaram a uma conclusão compatível por outra direção. O artigo de pesquisa Orion, de 2026, descreve 20 restrições encontradas ao programar o ANE por meio de interfaces privadas. Seus autores identificam compilação, layout de memória e comportamento numérico como barreiras práticas.
O Orion ainda relata resultados significativos com transformers. Em um M4 Max, o sistema produziu mais de 170 tokens por segundo para o GPT-2 com 124 milhões de parâmetros. Também treinou um modelo de 110 milhões de parâmetros por 1.000 etapas em 22 minutos.
Essas medições mostram que o ANE pode executar cargas de trabalho de modelos de linguagem. Elas não estabelecem que ele seja o melhor alvo para todos os modelos grandes ou todas as etapas da inferência. A distinção entre possibilidade técnica e adequação arquitetural continua essencial.
O Software Público da Apple Mantém o Hardware à Distância
Os desenvolvedores podem solicitar o Neural Engine por meio do Core ML, mas a Apple ainda controla como as cargas de trabalho são compiladas, divididas e despachadas.
A Apple expõe o Neural Engine principalmente por meio do Core ML, seu framework público para implantação de modelos de machine learning. Os desenvolvedores fornecem um modelo compatível, enquanto o framework decide se operações individuais devem usar a CPU, a GPU ou o Neural Engine.
Os controles de unidades de computação da Apple permitem que um aplicativo autorize combinações desses processadores. Um desenvolvedor pode permitir todas as unidades disponíveis ou excluir a GPU ou o Neural Engine. A interface pública não oferece programação direta dos descritores de tarefa do ANE.
Esse modelo protege a portabilidade entre dispositivos Apple. Um aplicativo pode descrever a previsão de que precisa sem codificar o layout de registradores de uma geração específica de chip. A Apple pode revisar compiladores e políticas de agendamento enquanto mantém estável a interface do aplicativo.
A contrapartida é a visibilidade. Os desenvolvedores não podem depender do Core ML para posicionar cada operação compatível em um mecanismo específico. Eles também não podem inspecionar o programa final de baixo nível com o controle esperado de APIs de computação de GPU.
A Apple explica que a execução do Core ML pode usar a CPU, a GPU e o Neural Engine enquanto reduz o consumo de memória e de energia. Essa abordagem é apropriada para aplicativos que buscam inferência eficiente no dispositivo sem ajuste específico de hardware.
Ela é menos satisfatória para pesquisadores que investigam limites arquiteturais. Um benchmark pode recorrer a outro processador, dividir um grafo entre processadores ou encontrar transformações de compilador que ocultam o comportamento do hardware subjacente.
O trabalho de engenharia reversa remove parte dessa incerteza. Ele examina descritores de tarefa, escritas em registradores, filas, interrupções e caminhos de memória abaixo do Core ML. Essa visão ajuda a distinguir restrições impostas pelo software de limitações criadas pelo silício.
No entanto, interfaces privadas criam sua própria incerteza. Elas não possuem as garantias públicas de compatibilidade da Apple e podem mudar com uma atualização do sistema operacional. Um código de pesquisa que funciona hoje pode falhar após mudanças no compilador, no formato de modelo ou no serviço de runtime.
Essa lacuna coloca a Apple em uma posição incomum. A empresa fornece hardware dedicado a machine learning em celulares, tablets, Macs e headsets. Ainda assim, desenvolvedores independentes têm controle limitado sobre um dos blocos mais distintos dentro desses processadores.
Para aplicativos convencionais, essa limitação pode ser uma escolha intencional de produto. A Apple otimiza o dispositivo completo e decide onde cada operação é executada. A maioria dos desenvolvedores se beneficia mais de uma implantação previsível do que de acesso direto aos registradores.
Desenvolvedores de IA generativa frequentemente precisam do oposto. Eles experimentam formatos de quantização, kernels de atenção, layouts de cache e operações fundidas. Também comparam o desempenho entre arquiteturas de modelos que mudam rapidamente.
As GPUs acomodam essa experimentação porque seus modelos de programação expõem uma computação mais geral. Os desenvolvedores podem implementar novos kernels sem esperar por um caminho de compilador dedicado. O custo é uma responsabilidade maior pela sincronização, pelo acesso à memória e pelo ajuste de desempenho.
O Neural Engine independente representa o outro extremo desse espectro. Seu compilador e caminho de dados fixo podem proporcionar execução eficiente quando um modelo se encaixa. Quando a carga de trabalho muda, a especialização passa a ser uma limitação em vez de uma vantagem.
A estratégia de software da Apple impede que os desenvolvedores resolvam diretamente essa tensão. O Core ML pode ocultar variações de hardware, mas não pode fazer um sistema de memória orientado a CNN se comportar como uma GPU flexível. A engenharia reversa expõe o limite que o framework normalmente esconde.
O M5 torna a GPU a principal adversária
O M5 da Apple não elimina o Neural Engine independente, mas dá à GPU um papel mais direto no roteiro de IA da empresa.
A Apple anunciou o M5 em outubro de 2025, com uma GPU de 10 núcleos contendo um Neural Accelerator em cada núcleo. O chip também manteve um Neural Engine aprimorado de 16 núcleos. Esse design coloca hardware especializado para matrizes nos dois lados da disputa arquitetural.
Segundo o anúncio do chip M5 da Apple, a nova GPU oferece mais de quatro vezes o desempenho máximo de computação de IA da GPU do M4. A Apple também elevou a largura de banda da memória unificada para 153GB/s, quase 30% acima do M4.
Essas são medições controladas pela Apple, e os detalhes da carga de trabalho determinam o desempenho real das aplicações. Ainda assim, a localização dos novos aceleradores é mais reveladora do que o multiplicador em destaque. A Apple os colocou dentro de núcleos de GPU programáveis, em vez de depender apenas do Neural Engine separado.
A GPU combina execução especializada de matrizes com um ambiente já adequado a algoritmos em constante mudança. A Apple afirma que os desenvolvedores podem programar os Neural Accelerators por meio de APIs de tensores no Metal 4. Isso oferece um caminho público para cargas de trabalho de IA baseadas em GPU sem expor o formato privado de comandos do ANE independente.
Yoon interpreta essa mudança como o começo do fim da NPU independente, ou unidade de processamento neural. A formulação é deliberadamente provocativa, e as decisões de produto da Apple ainda não confirmam uma retirada efetiva.
O M5 ainda inclui um Neural Engine separado. A Apple o descreve como mais rápido e o associa a recursos do sistema, incluindo processamento de fotos e geração de Persona espacial. Essas tarefas se assemelham às cargas de inferência delimitadas e previsíveis que aceleradores dedicados executam bem.
A conclusão mais defensável é mais restrita. A Apple agora trata a GPU como um destino principal para cargas exigentes de IA generativa, enquanto o Neural Engine mantém um papel na inferência eficiente do sistema.
Essa divisão corresponde às evidências obtidas por engenharia reversa. Uma GPU pode combinar aceleração de matrizes com operações flexíveis de memória, kernels gerais e acesso direto dos desenvolvedores. Uma NPU de função fixa pode minimizar a sobrecarga para grafos estáveis com padrões de execução conhecidos.
Nenhum dos designs vence em todas as cargas de trabalho. Um processador geral consome área e energia para oferecer flexibilidade que um pipeline fixo evita. Um mecanismo especializado perde adaptabilidade quando os modelos exigem novos padrões de movimentação.
O M5 sugere que a Apple quer ambos. Seu Neural Engine separado pode dar suporte a recursos consolidados no dispositivo, enquanto os GPU Neural Accelerators visam modelos cujos operadores e comportamento de memória continuam mudando.
Essa estratégia híbrida também pressiona a pilha de software da Apple. O Core ML precisa escolher entre processadores cada vez mais capazes. O Metal precisa dar aos desenvolvedores controle suficiente para aproveitar as novas unidades de GPU. O compilador precisa evitar mover dados entre processadores com tanta frequência que os custos de transferência eliminem a aceleração.
Portanto, a pressão não é simplesmente Nvidia contra Apple, ou macOS contra Linux. É uma disputa dentro do próprio silício da Apple entre eficiência de função fixa e aceleração programável.
Essa disputa começou muito antes da IA generativa. Os chips da Apple já dividem o trabalho entre CPUs, GPUs, mecanismos de mídia, processadores de imagem e hardware de segurança. A diferença agora é que o design de modelos de IA muda em um ritmo que torna ciclos longos de planejamento de hardware especialmente arriscados.
Um bloco dedicado pode levar anos para ser projetado e validado. Arquiteturas Transformer, variantes de atenção e técnicas de quantização podem mudar em questão de meses. Incorporar aceleração mais adaptável à GPU reduz o custo de errar na previsão.
A engenharia reversa não prova que o Neural Engine acabou
A retrospectiva explica uma incompatibilidade arquitetural, mas não pode estabelecer o plano futuro de produtos da Apple nem medir todas as implementações mais novas do ANE.
As descobertas mais profundas dizem respeito à geração M1. Desde então, a Apple lançou diversas famílias de processadores, e detalhes internos podem mudar sem documentação pública. Conclusões sobre chips posteriores exigem medições diretas, não semelhança visual ou nomes de marketing.
Yoon reconhece a incerteza em partes da análise do layout físico. Imagens do die podem revelar grandes blocos de memória e estruturas de computação repetidas, mas não explicam cada decisão de roteamento. Algumas conclusões permanecem interpretações fundamentadas.
A investigação também se concentra na estrutura de hardware, e não em um benchmark abrangente de aplicações. Ela mostra por que a movimentação de memória deve limitar determinadas cargas de trabalho. Não compara todos os modelos entre ANE, GPU e CPU sob limites de energia idênticos.
O Orion fornece medições úteis mais recentes, mas utiliza APIs privadas e software de pesquisa. Seus experimentos com GPT-2 e TinyStories demonstram acesso e capacidade, não ampla prontidão para produção com os atuais modelos de linguagem de grande porte.
Outro projeto aberto relatou treinamento direto por meio de interfaces privadas obtidas por engenharia reversa. Suas medições no M4 situam o desempenho FP16 em cerca de 18,6 trilhões de operações por segundo e o desempenho INT8 em cerca de 35,1 trilhões de operações por segundo. Esses números dependem de configurações selecionadas de convolução e não devem ser generalizados para modelos completos.
A maturidade do software importa tanto quanto o hardware. Um compilador altamente otimizado pode reestruturar grafos, fundir operações e reduzir transferências. Um driver de pesquisa pode expor o mecanismo corretamente, mas deixar grande parte do desempenho sem uso.
O risco oposto também se aplica. Microbenchmarks de pico podem manter unidades aritméticas ocupadas em condições ideais enquanto escondem os gargalos de modelos reais. Latência de ponta a ponta, uso de memória, consumo de energia e tempo de compilação determinam se um acelerador ajuda uma aplicação.
A Apple também pode redesenhar o Neural Engine independente mantendo seu nome de produto. Memória compartilhada maior, caminhos de dados revisados ou novos formatos de tarefa poderiam resolver limitações encontradas no M1. O anúncio do M5 não divulga esse nível de detalhe.
A segurança apresenta outro motivo para o acesso controlado. A Apple usa o hardware do Neural Engine em fluxos de trabalho biométricos protegidos. Sua documentação de segurança da plataforma descreve redefinições de estado e controles de memória para a operação segura do Neural Engine em sistemas mais novos.
Esse papel não exige abrir o mesmo hardware para cargas arbitrárias do Linux. Também significa que a presença contínua do bloco pode refletir uma arquitetura de sistema que vai além dos modelos de linguagem voltados ao consumidor.
A eficiência energética continua sendo outra comparação ausente. A decodificação autorregressiva pode ser executada de forma mais natural em hardware de GPU programável, mas um mecanismo dedicado ainda pode superá-la em tarefas de visão, áudio e classificação. A Apple vende dispositivos alimentados por bateria, nos quais essas economias importam.
Portanto, a afirmação crível não é que o Neural Engine morreu. É que suas premissas de design originais já não abrangem toda a gama de cargas de trabalho de IA estrategicamente importantes.
Essa distinção mantém Retrospectively Reverse-Engineering Apple's Neural Engine ancorado em evidências. O projeto ilumina uma bifurcação arquitetural, enquanto os lançamentos de produtos da Apple determinarão até onde a empresa seguirá qualquer uma das rotas.
Três sinais mostrarão qual arquitetura vence
As próximas APIs, benchmarks e layouts de chip da Apple revelarão se o Neural Engine do M1 era um modelo duradouro ou um ramo especializado.
O primeiro sinal é o acesso dos desenvolvedores aos Neural Accelerators da GPU do M5. O Metal 4 precisa expor operações de tensor úteis sem ocultar tanto o agendamento que os pesquisadores enfrentem outra caixa-preta.
Ferramentas funcionais reforçarão a tese de que a Apple escolheu a aceleração de GPU programável para modelos que mudam rapidamente. APIs limitadas ou suporte restrito a operadores enfraqueceriam essa interpretação e preservariam um papel maior para o hardware gerenciado pelo Core ML.
O segundo sinal é o desempenho de ponta a ponta em cargas de trabalho representativas de Transformer. Comparações úteis precisam incluir processamento de prompts, geração de tokens, comportamento de memória em contexto longo, uso de energia e tempo de carregamento de modelos.
Microbenchmarks sozinhos não resolverão a questão. Um processador pode liderar no throughput de matrizes, mas perder tempo com transferências de pesos, movimentação de cache ou compilação de grafos. As medições também devem identificar qual unidade de computação executou cada operação.
Os resultados de aplicações no M5 serão especialmente importantes. Modelos de linguagem locais e software de difusão podem testar os novos aceleradores de GPU em cargas de trabalho que a Apple destacou explicitamente. Ganhos consistentes validariam o movimento rumo à aceleração dentro de núcleos programáveis.
O terceiro sinal é a arquitetura do próximo Neural Engine independente da Apple. A Apple pode manter o rótulo de 16 núcleos enquanto muda tamanho de memória, interconexões, agendamento e precisão suportada sob essa designação.
Um sistema de memória local redesenhado contestaria a ideia de que o bloco independente está se aproximando do fim. Mudanças mínimas, combinadas com investimentos maiores em GPU, sustentariam a interpretação de Yoon.
O progresso no Linux oferece um caminho secundário de verificação. A comunidade Asahi tem ampla experiência em documentar o silício da Apple por meio de observação e experimentação em clean room. Seu trabalho de engenharia reversa já produziu drivers abertos para outros blocos não documentados.
Um driver ANE utilizável permitiria que pesquisadores comparassem as escolhas do Core ML com o envio direto de tarefas. Também poderia revelar se compiladores alternativos conseguem recuperar desempenho que o framework público da Apple deixa inacessível.
Ainda assim, o suporte ao Linux não deve ser confundido com o principal resultado comercial. O driver importa porque transforma o comportamento oculto do hardware em evidência testável. Os próprios dispositivos, frameworks e cargas de trabalho da Apple decidirão o futuro da arquitetura.
Os desenvolvedores devem observar onde a Apple coloca nova programabilidade pública. Também devem separar o throughput teórico do desempenho completo da aplicação. O processador com o maior número em destaque não é necessariamente aquele que movimenta os dados do modelo com eficiência.
Equipes que realizam investigações técnicas semelhantes precisam de um registro duradouro de experimentos, descobertas de registradores, benchmarks e hipóteses rejeitadas. Uma base de conhecimento de engenharia pesquisável pode manter essas evidências conectadas à medida que ferramentas e gerações de chips mudam.
Retrospectively Reverse-Engineering Apple's Neural Engine captura, em última análise, um raro momento em que o silício antigo explica uma nova estratégia. O M1 mostra os benefícios e os custos de comprometer premissas de CNN no hardware. O M5 mostra a Apple adicionando flexibilidade sem abandonar imediatamente a especialização.
A próxima pergunta é concreta: os futuros chips da Apple ampliarão a aceleração de GPU programável enquanto deixarão o Neural Engine para tarefas estáveis do sistema, ou a Apple reconstruirá o bloco independente para Transformers? Observe as APIs e o comportamento da memória, não apenas o número de TOPS.
