O chip que a Apple esconde dentro do seu Mac

Você já parou pra pensar no que acontece quando o seu iPhone identifica um rosto numa foto em milissegundos? Ou quando o ditado por voz do Mac transcreve tudo sem mandar nada pra nuvem? Por trás disso existe um processador dedicado que a Apple quase nunca menciona em keynotes: o Neural Engine (ANE).

Desde 2017, quando apareceu pela primeira vez no chip A11 do iPhone X, o Neural Engine evoluiu silenciosamente. Hoje, no M5, ele processa 38 trilhões de operações por segundo. Mas aqui vai o detalhe bizarro: a Apple nunca publicou documentação técnica sobre como ele funciona. Nenhum manual. Nenhuma ISA pública. Nenhum SDK de baixo nível. Só o Core ML, uma caixa preta que decide sozinha o que roda no ANE e o que vai pro GPU.

Até que uma pesquisadora chamada Eileen Yoon decidiu abrir essa caixa preta. E o que ela encontrou muda a forma como entendemos não só o Apple Silicon, mas o futuro dos aceleradores de IA em geral.

Quem é Eileen Yoon e por que isso importa

Eileen começou esse projeto de engenharia reversa em 2023, abandonou, e voltou três anos depois com um paper completo publicado no arXiv. O trabalho envolveu análise estática do runtime privado da Apple, do compilador, do driver de kernel e do firmware do ANE. Tudo sem acesso a documentação oficial.

O resultado é o primeiro mapa detalhado da arquitetura do Neural Engine, cobrindo desde o chip A11 até o M5. Não é especulação de blog. É medição direta no hardware, com roofline analysis, benchmarks reais e desmontagem de binários proprietários.

Por que isso importa? Porque o ANE é o componente mais subutilizado do Apple Silicon. Desenvolvedores não têm controle sobre ele. Pesquisadores não conseguem otimizar modelos pra ele. E a Apple parece ter desenhado um chip que era perfeito pra 2018, mas que agora, na era dos transformers, tem limitações fundamentais que ninguém discutia porque ninguém sabia como ele funcionava por dentro.

16 núcleos, 2.048 lanes e zero instruções

A arquitetura do ANE no M1 tem 16 núcleos, cada um com 128 lanes de multiplicação-acumulação (MAC) em FP16. São 2.048 MACs operando em paralelo, entregando 11 TOPS (trilhões de operações por segundo) no M1.

Mas a parte realmente surpreendente não é o número de cores. É o modelo de execução.

O ANE não executa instruções. Leia isso de novo: ele não tem um instruction set. O que ele faz é mais parecido com um motor de dataflow de função fixa. Na prática, o compilador do Core ML transforma seu modelo inteiro em “Task Descriptors” (TDs), que são dumps serializados dos registradores do datapath do ANE. Cada TD configura completamente o pipeline de dados para uma operação.

Isso significa que toda a lógica de execução é decidida em tempo de compilação, não em tempo de execução. O ANE não interpreta nada. Ele recebe um pacote de configuração, liga os circuitos na ordem certa, e processa. É brutalmente eficiente pra workloads previsíveis, mas completamente inflexível pra qualquer coisa que exija decisões dinâmicas.

Convoluções, não multiplicações de matrizes

Aqui vem a revelação que pegou muita gente de surpresa: a primitiva computacional fundamental do ANE é a convolução, não a multiplicação de matrizes.

“Mas espera, transformer usa matmul o tempo todo!” Exato. E é exatamente aí que mora o problema.

O ANE foi projetado numa época em que CNNs (redes neurais convolucionais) dominavam tudo: classificação de imagem, detecção de objetos, segmentação. O chip é otimizado pra esse padrão de acesso: pesos fixos sendo reutilizados em múltiplas posições espaciais de um tensor de entrada.

Quando você precisa fazer uma multiplicação de matrizes no ANE, a abordagem mais eficiente (descoberta pela engenharia reversa) é expressar o matmul como uma convolução 1×1. Isso pode parecer um hack, mas na prática entrega cerca de 3x mais throughput do que tentar usar o matmul “nativo”.

Pense no absurdo: um chip de 2026 que roda melhor quando você finge que uma multiplicação de matrizes é uma convolução. Isso diz muito sobre como decisões de arquitetura de hardware de 2017 ainda assombram o ecossistema em 2026.

A hierarquia de memória que ninguém conhecia

Outro achado importante da engenharia reversa é a hierarquia de memória do ANE, que tem três níveis:

O ANE usa três engines de DMA independentes: uma pra carregar kernels (pesos), uma pra tiles de entrada e uma pra tiles de saída. Em teoria, as três poderiam operar em paralelo. Na prática, a análise mostrou que as requisições de DMA do kernel e do tile executam serialmente, não em paralelo.

O resultado? O ANE precisa de 162 operações por byte lido da DRAM pra saturar o compute. Em comparação, GPUs modernas precisam de muito menos. Nos testes reais, o ANE do M1 atingiu apenas 38 a 60 GB/s de throughput de leitura, contra 77.7 GB/s do GPU do mesmo chip.

Traduzindo: o ANE é rápido pra contar, mas lento pra buscar dados. Qualquer modelo que não reutilize os pesos intensamente (como modelos de linguagem gerando token por token) vai esbarrar no gargalo de memória antes de chegar perto de saturar os MACs.

Por que o ANE sofre com transformers

Transformers modernos, especialmente na fase de decode (geração de texto token por token), têm um padrão de acesso à memória que é o pesadelo do ANE:

1. Pesos diferentes a cada layer: não há reutilização espacial como em convoluções
2. KV-cache cresce linearmente: cada token novo precisa acessar todo o histórico
3. Operações são sequenciais: cada token depende do anterior, impossibilitando batch grande
4. Atenção é memory-bound: a multiplicação Q×K^T acessa enormes matrizes de contexto

O ANE foi feito pra o oposto disso: workloads onde os mesmos pesos são aplicados repetidamente em posições diferentes de um tensor espacial (como numa imagem). Numa CNN, um filtro 3×3 com 64 canais é reutilizado milhares de vezes ao deslizar pela imagem. O ANE adora isso.

Num transformer gerando texto? Cada token é uma operação única com pesos diferentes em cada camada. O ANE fica esperando dados 90% do tempo.

O truque do Core ML (e por que ele falha)

Quando você roda um modelo via Core ML no Mac, o framework tenta automaticamente dividir o modelo entre CPU, GPU e ANE. A ideia é colocar as operações que o ANE faz bem (convoluções, normalizações) no ANE, e o resto no GPU.

O problema é que essa divisão automática introduz overhead de transferência de dados entre processadores. Cada vez que um tensor precisa sair do ANE e ir pro GPU (ou vice-versa), há uma cópia de memória. Em modelos grandes com dezenas de camadas, essas transferências se acumulam e podem anular qualquer ganho de performance.

A pesquisa da Eileen mostrou que, em muitos casos, rodar o modelo inteiro no GPU é mais rápido do que a divisão automática do Core ML. O ANE só vale a pena quando o modelo inteiro (ou pelo menos grandes blocos contíguos) cabe nele sem precisar trocar dados com outros processadores.

Alguém treinou um modelo de 600M de parâmetros no ANE

Se a Apple não quer que desenvolvedores acessem o ANE diretamente, alguém não recebeu o memorando.

Usando o trabalho de engenharia reversa como base, um desenvolvedor conseguiu treinar (sim, treinar, não apenas fazer inferência) um modelo de 600 milhões de parâmetros diretamente no Neural Engine do chip M4. O projeto mapeou mais de 40 classes privadas do framework da Apple e conectou diretamente ao driver de kernel via IOKit, bypassando completamente o Core ML.

Isso é significativo por dois motivos. Primeiro, a Apple sempre posicionou o ANE como um chip de inferência, não de treinamento. Segundo, mostra que o hardware tem capacidades que o software oficial da Apple deliberadamente não expõe.

A comunidade open source está essencialmente desbloqueando funcionalidades que a Apple poderia ter oferecido desde o início. E isso levanta uma pergunta incômoda: a Apple limita o ANE por decisão técnica ou por estratégia de produto?

O M5 e o começo do fim do NPU standalone

Talvez a revelação mais impactante do paper seja sobre o futuro. A análise dos chips mais recentes da Apple sugere que a empresa está integrando as funcionalidades do ANE diretamente nos cores do GPU no chip M5.

Eileen Yoon descreve isso como “o começo do fim do NPU standalone” (standalone Neural Processing Unit). E faz sentido: se o ANE tem gargalos de memória que o GPU não tem, e se os workloads de IA estão migrando de CNNs pra transformers, por que manter um acelerador separado que não consegue acompanhar?

A tendência é clara quando você olha pro mercado:

A Apple parece estar admitindo, na arquitetura do M5, que a aposta de 2017 em um acelerador dedicado pra CNNs não envelheceu bem. Não que o ANE tenha falhado, ele fez exatamente o que foi projetado pra fazer. O problema é que o mundo mudou mais rápido do que o hardware conseguiu acompanhar.

O que isso significa pra quem desenvolve com Apple Silicon

Se você é desenvolvedor e roda modelos de IA no Mac, as implicações práticas são:

Pra inferência de modelos pequenos (classificação de imagem, OCR, detecção de objetos): o ANE ainda é excelente. Consome menos energia que o GPU e entrega latência mais baixa pra modelos que cabem inteiramente nele. Use Core ML com MLComputeUnits.cpuAndNeuralEngine pra esses casos.

Pra LLMs e modelos de linguagem: esqueça o ANE. Use GPU puro (MLComputeUnits.cpuAndGPU) ou frameworks como llama.cpp e MLX que já sabem disso e direcionam tudo pro Metal (GPU da Apple).

Pra treinamento local: o ANE não é oficialmente suportado pra isso, mas o trabalho de engenharia reversa mostra que é tecnicamente possível. Se você é pesquisador e quer explorar, o código da Eileen Yoon está disponível no GitHub.

Pra o futuro: fique de olho no M5 e nos chips seguintes. Se a Apple realmente está fundindo ANE e GPU, isso pode significar um framework unificado de compute que não exija mais a escolha manual entre processadores.

Funções de ativação: tabelas em vez de cálculos

Um detalhe elegante descoberto pela engenharia reversa é como o ANE implementa funções de ativação como tanh, sigmoid e GELU. Em vez de calcular essas funções matematicamente (como faz uma GPU), o ANE usa tabelas de lookup com interpolação linear.

Cada função de ativação é representada por uma tabela de 33 coeficientes. O chip pega o valor de entrada, encontra os dois coeficientes mais próximos na tabela, e interpola linearmente entre eles. É uma aproximação, não o cálculo exato, mas é rápida e consome pouquíssima energia.

Isso funciona perfeitamente pra inferência, onde pequenas imprecisões numéricas são aceitáveis. Pra treinamento, onde os gradientes precisam ser mais precisos, essa aproximação pode causar instabilidade. Mais um motivo pelo qual a Apple nunca posicionou o ANE pra treinamento.

O elefante na sala: por que a Apple não documenta isso?

A Apple tem um histórico longo de manter hardware proprietário fechado. Mas o caso do ANE é particularmente chamativo. Nvidia publica documentação detalhada das suas GPUs. AMD tem o ROCm aberto. Até a Intel documenta seus NPUs em certo nível.

A Apple? Oferece o Core ML e diz “confia”. Se o modelo for compatível, o Core ML decide sozinho onde executar. Se não for, azar.

A teoria mais aceita na comunidade é que a Apple mantém o ANE fechado por duas razões: proteger propriedade intelectual do design do chip e manter controle total sobre a experiência do desenvolvedor. Se desenvolvedores pudessem programar o ANE diretamente, inevitavelmente encontrariam as limitações que esse paper expôs, e isso poderia prejudicar a narrativa de marketing do “chip mais avançado do mundo”.

Só que, ironicamente, manter o ANE fechado também significa que ninguém pode otimizar modelos pra ele. O chip fica subutilizado, desenvolvedores migram pro GPU (ou pior, pra Nvidia), e o investimento bilionário em silicon design não entrega o retorno que poderia.

O que esperar dos próximos chips

Com base nos padrões identificados pela engenharia reversa, algumas previsões são possíveis:

O M5 provavelmente vai ser o último chip com um ANE claramente separado. A partir do M6 ou M7, espere ver as capacidades de aceleração de IA completamente integradas no GPU, com um scheduler unificado que não exija mais a divisão manual de workloads.

A Apple também vai precisar resolver o gargalo de bandwidth da memória. Os 38 a 60 GB/s do ANE simplesmente não são suficientes pra modelos grandes. A memória unificada do Apple Silicon é uma vantagem enorme (sem cópia CPU para GPU), mas a largura de banda total precisa crescer pra acompanhar modelos que dobram de tamanho a cada ano.

E, se a Apple for esperta, vai olhar pro que o MLX team (da própria Apple Research) está fazendo e integrar esse nível de controle direto no Metal. Um framework onde o desenvolvedor diz “quero rodar esse modelo” e o runtime decide, com transparência, quais partes vão pro compute de matrix e quais vão pro shader, sem a caixa preta do Core ML.

Enquanto isso, o trabalho da Eileen Yoon fica como prova de que a comunidade open source pode fazer o que a Apple se recusa a fazer: documentar seu próprio hardware. E que, às vezes, os chips mais interessantes são os que ninguém te deixa ver por dentro.

—

Fonte de inspiração: Retrospectively Reverse-Engineering Apple’s Neural Engine e Apple Neural Engine: Architecture, Programming, and Performance (arXiv)