Hace tres años, Eileen Yoon comenzó a hacer ingeniería inversa del Neural Engine de Apple (ANE) —el acelerador dedicado de aprendizaje automático dentro de los chips serie M de Apple— y publicó un controlador para Linux. Se detuvo, convencida de que el bloque era demasiado especializado para ser útil en general. Ahora ha vuelto, no para hacer que el ANE ejecute nuevas cargas de trabajo, sino para mapear exactamente cómo su arquitectura interna revela en qué apostó Apple cuando comprometió por primera vez la aceleración neuronal al silicio en el A11 Bionic (2017).

El hallazgo central es que el ANE fue diseñado para redes neuronales convolucionales (CNN), la arquitectura de procesamiento de imagen que dominó el aprendizaje automático anterior a 2018, no para los modelos de transformador que impulsan los LLM actuales. La densa y predecible reutilización de datos de una CNN se mapea perfectamente al flujo de datos del ANE; la decodificación autoregresiva de un transformador no lo hace. La propia respuesta de Apple, argumenta Yoon, fue plegar los núcleos ANE dentro de clústeres GPU en el M5 (2025) —retirando efectivamente el NPU independiente en lugar de adaptarlo.

Cada uno de los 16 núcleos de cómputo del ANE del M1 contiene 128 carriles paralelos de multiplicación-acumulación (MAC) —2048 en todo el chip— que realizan la recurrencia s ← s + a × b. El MAC es una unidad de reducción escalar: no sabe nada sobre qué dimensión de un tensor está reduciendo; ese significado proviene de cómo se programan los operandos en el núcleo. El acumulador es un registro de punto fijo de 32 bits en formato Q16.16, saturando en 2¹⁵, con el producto leído como FP16. Esta elección —multiplicación de 16 bits, acumulación de 32 bits, lectura de 16 bits— es una consecuencia directa de las cargas de trabajo CNN a las que Apple apuntó: activaciones acotadas, rango predecible, amigable con punto fijo.

Para las no linealidades, el ANE no calcula tanh en hardware. Usa una tabla de búsqueda lineal por tramos de 33 entradas con interpolación lineal, espaciando nudos en intervalos de 1/8. Una ReLU es modo 1 (identidad), tanh es modo 2 (la LUT). El compilador de CoreML pliega el sesgo y la activación en la misma ruta post-MAC en tiempo de compilación —el registro de sesgo y el modo no lineal se establecen por capa, y la salida del MAC alimenta directamente la búsqueda sin un viaje intermedio de ida y vuelta a memoria.

Diagrama que muestra cómo Core ML pliega la escala constante y el desplazamiento en los pesos y el sesgo de la convolución antes de la activación ReLU
El compilador de Core ML pliega el sesgo y la activación en la ruta post-MAC en tiempo de compilación, evitando un viaje intermedio de ida y vuelta a memoriaeiln.github.io

El artículo explica que el compilador de CoreML pliega el sesgo y la activación en la misma ruta post-MAC en tiempo de compilación, con el registro de sesgo y el modo no lineal establecidos por capa, y la salida del MAC alimenta directamente la búsqueda sin un viaje intermedio de ida y vuelta a memoria

Una entrada no nula de la tabla de búsqueda produce dos segmentos de línea recta en la aproximación lineal por tramos de tanh del ANE
Una sola entrada LUT no nula genera dos segmentos de línea recta, ilustrando el esquema de interpolación lineal por tramos del ANEeiln.github.io

El artículo describe el enfoque de no linealidad del ANE: una tabla de búsqueda lineal por tramos de 33 entradas con interpolación lineal, espaciando nudos en intervalos de 1/8, donde tanh es modo 2 y ReLU es modo 1

tanh de Core ML superpuesto con tanh de doble precisión, seguido de gráfico de error con signo
Salida tanh de Core ML superpuesta contra tanh de doble precisión, con el error con signo debajoeiln.github.io

El artículo discute la implementación tanh del ANE como modo 2 de la tabla de búsqueda lineal por tramos; esta figura valida la precisión de la aproximación contra una referencia de doble precisión

El planificador, según la descripción de Yoon, es decepcionantemente simple. El controlador nunca envía códigos de operación CONV o MATMUL. Todas las operaciones neuronales se precompilan en un flujo de comandos de descriptores de tarea de tamaño fijo; el controlador carga el flujo en memoria, apunta TM_ADDR/TM_SIZE a él y activa TM_PUSH. El hardware entonces toma posesión del envío hasta la finalización, generando una interrupción al núcleo ARM64 cuando termina. Ocho colas de tareas (qid 0–7) proporcionan puesta en escena ping-pong —un hueco de descriptor ejecuta mientras el software llena el otro— y cada cola lleva una tabla de registros de dirección base de 32 entradas que mapea el trabajo a nivel de tesela.

El repositorio de GitHub de Yoon (eiln/ane) contiene el módulo del kernel, la biblioteca de espacio de usuario y los enlaces de Python —193 commits, 537 estrellas. El trabajo explícitamente no trata sobre hacer útil el ANE hoy; se trata de leer las suposiciones arquitectónicas que Apple grabó en silicio en 2017 y rastrear qué ocurrió cuando esas suposiciones se encontraron con la era del transformador.

Lo que queda incierto: si los bloques ANE del M4 y posteriores exponen capacidades más allá del diseño del M1 que documenta Yoon (una señal de discusión indica que Apple aparentemente duplicó los bloques ANE para M6/A20, y que los «Neural Accelerators» del M5 dentro de núcleos GPU son un subsistema diferente). La fuente de Yoon cubre solo el ANE del M1, y el artículo no verifica independientemente las afirmaciones sobre M4/M5. De manera similar, si los desarrolladores independientes pueden acceder al ANE en absoluto —frente a que Apple lo restrinja a tuberías de fotografía computacional— no se resuelve con el material suministrado; un comentarista afirma la restricción, pero el controlador suministrado es en sí evidencia de que existe acceso en Linux, aunque solo sea mediante ingeniería inversa.