Apple reabre un debate sobre hardware: ingeniería inversa retrospectiva del Neural Engine de Apple

El Neural Engine M1 de Apple ha vuelto a ser objeto de análisis, pese a una pausa de tres años en el proyecto de controlador de Linux creado para entenderlo. La ingeniería inversa retrospectiva del Neural Engine de Apple documenta por qué ese acelerador destacó con redes neuronales anteriores, pero tiene dificultades con las cargas de trabajo de transformers actuales.

Eileen Yoon, antigua colaboradora de Asahi Linux, retomó el trabajo abandonado después de que Apple cambiara su dirección de hardware. El M5 integra un Neural Accelerator dentro de cada núcleo de GPU, al tiempo que conserva un Neural Engine independiente de 16 núcleos. Esa combinación pone en duda la idea de que un único acelerador de función fija deba asumir las crecientes cargas de trabajo de IA generativa de Apple.

Esto es más que un análisis de hardware tardío. La investigación conecta las decisiones tomadas para las redes neuronales convolucionales de 2017, o CNN, con la respuesta de Apple a los modelos de lenguaje modernos. Las GPU presionan ahora al Neural Engine independiente porque los transformers dependen de una planificación flexible y de un movimiento sostenido de memoria.

Un controlador M1 inactivo se convirtió en una autopsia de hardware

El nuevo trabajo convierte un controlador de Linux sin terminar en una explicación de lo que Apple esperaba originalmente que llegara a ser el aprendizaje automático.

Yoon creó anteriormente un controlador Linux para ANE que podía comunicarse con el Neural Engine de los chips M1. El proyecto incluía un módulo de kernel, una biblioteca de espacio de usuario, pruebas y enlaces de Python. Ofrecía una vía alternativa a la abstracción pública de software de Apple, aunque no hacía que el hardware fuera ampliamente programable.

El proyecto quedó inactivo durante tres años. Yoon escribe que el ANE parecía demasiado especializado como para justificar más trabajo en el controlador. Abrir su interfaz de hardware no cambiaría qué operaciones podía ejecutar eficientemente su ruta de datos fija.

Esa distinción importa. Un controlador convencional puede exponer capacidades que el hardware ya contiene. No puede convertir un acelerador de flujo de datos diseñado para un propósito específico en un procesador general.

Por eso, la retrospectiva sobre la arquitectura de Yoon plantea una pregunta distinta de la del esfuerzo original del controlador. En vez de preguntar cómo Linux puede enviar trabajo, examina la matriz de cómputo, el planificador, el sistema de memoria y el modelo de ejecución. Esos componentes revelan las suposiciones sobre las cargas de trabajo integradas en el diseño del M1.

La investigación describe 16 núcleos de cómputo dispuestos alrededor de un bloque central de memoria local. Cada núcleo contiene unidades paralelas de multiplicación-acumulación, o MAC, que multiplican entradas y suman los resultados en acumuladores. Estas operaciones sustentan las convoluciones, la multiplicación de matrices y los productos escalares utilizados por los mecanismos de atención.

Las unidades MAC no explican por sí solas la especialización del Neural Engine. Tanto las CNN como los transformers necesitan multiplicación y acumulación. La diferencia decisiva reside en cómo los pesos y las activaciones llegan a esas unidades, permanecen disponibles y se desplazan por el chip.

Apple presentó su primer Neural Engine con el A11 Bionic en 2017. En ese momento, las redes neuronales de consumo se centraban en la clasificación de imágenes, el análisis facial y otras cargas de trabajo densas de CNN. Esas redes ofrecían formas de tensor regulares y reutilización predecible.

El M1 heredó ese linaje de diseño cuando Apple llevó sus propios procesadores al Mac. Su Neural Engine estaba optimizado para modelos compilados cuyas dimensiones y patrones de movimiento se conocían en gran medida de antemano. Esa especialización reducía la latencia y el consumo de energía para el trabajo compatible.

La retrospectiva no sostiene que el Neural Engine M1 no pueda ejecutar operaciones de transformer. Argumenta que el flujo de datos circundante vuelve ineficientes algunos patrones de transformer, especialmente la decodificación autorregresiva. Ese proceso genera un token a la vez mientras relee repetidamente los pesos del modelo y una caché de atención en crecimiento.

Este replanteamiento crea la tensión central del artículo. Apple construyó un motor eficiente al restringir el movimiento de datos en torno a una carga de trabajo prevista. La IA moderna cambió la carga de trabajo dominante más rápido de lo que podía cambiar una arquitectura de hardware fija.

La ingeniería inversa retrospectiva del Neural Engine de Apple expone la verdadera restricción

La limitación definitoria del Neural Engine M1 no es la capacidad aritmética; es la ruta que los datos deben seguir alrededor de esa aritmética.

El controlador sometido a ingeniería inversa nunca envía directamente al hardware comandos de alto nivel como CONV, MATMUL o RELU. El compilador de Apple ya ha convertido esas operaciones neuronales en descriptores de tareas antes de que comience la ejecución.

Un descriptor de tarea es un bloque estructurado de datos de configuración. Programa grupos de registros que controlan las dimensiones de los tensores, las direcciones de memoria, las funciones de activación, las dependencias y las transferencias de datos. El controlador coloca el descriptor en memoria, dirige el gestor de tareas hacia él y activa un "timbre" de hardware.

Tras ese envío, el Neural Engine controla el trabajo hasta su finalización. Genera una interrupción cuando la tarea termina. El procesador anfitrión no dirige cada instrucción matemática mientras la operación está en marcha.

Yoon concluye que el ANE carece de un conjunto de instrucciones en el sentido habitual de una CPU o GPU. Sus descriptores de tareas configuran una ruta de datos específica de un dominio en lugar de proporcionar un programa arbitrario. Cada descriptor representa un recorrido por esa ruta de datos.

La tarea comienza cargando registros de configuración. A continuación, bloques de transferencia dedicados desplazan los pesos y las activaciones de entrada desde la memoria principal hacia almacenes locales separados. Los núcleos de cómputo realizan reducciones, el posprocesamiento aplica una activación y otro bloque de transferencia devuelve el resultado.

Esa secuencia favorece operaciones con reutilización predecible. Una convolución puede aplicar el mismo conjunto compacto de filtros aprendidos en muchas regiones de una imagen. El acelerador puede mantener ocupados sus carriles aritméticos sin recuperar repetidamente un nuevo conjunto grande de pesos.

La decodificación de transformers cambia ese equilibrio. Cada token nuevo puede requerir transmitir una parte sustancial de los parámetros del modelo. La aritmética sigue siendo reconocible, pero el movimiento de datos se convierte en el coste limitante.

La disposición del M1 agrava el problema porque separa la memoria utilizada para pesos de la memoria local utilizada para mosaicos de activaciones. Yoon identifica aproximadamente 1 MiB de memoria de kernel y 2 MiB de memoria de mosaicos en el diseño. La investigación sostiene que la arquitectura no estaba organizada para reinterpretar eficientemente como pesos los tensores producidos localmente.

Esa era una suposición razonable para los modelos a los que Apple apuntaba en 2017. La inferencia de CNN generalmente trata los pesos aprendidos como kernels fijos y las activaciones como datos que fluyen entre capas. La atención de transformer difumina esa distinción porque los valores producidos durante la ejecución pueden alimentar operaciones matriciales posteriores.

Una caché clave-valor ilustra el problema. La caché almacena representaciones de tokens anteriores para que el modelo pueda reutilizarlas durante la generación. Su contenido crece a medida que la conversación o el documento se alarga, lo que hace cada vez más importante un acceso eficiente a la memoria.

Las dimensiones fijas de los tensores no son el obstáculo central. Una tarea compilada puede recorrer en bucle una longitud de caché cambiante, y la sobrecarga del envío de tareas puede seguir siendo pequeña. El problema más difícil es alimentar repetidamente datos a través de rutas diseñadas en torno a la reutilización de CNN.

Por eso, las cifras brutas de operaciones por segundo ofrecen una comparación incompleta. El rendimiento aritmético máximo describe la rapidez con que la matriz MAC puede trabajar en condiciones favorables. No revela cuántas veces esas unidades esperan pesos, activaciones o resultados intermedios.

Investigaciones independientes han llegado a una conclusión compatible desde otra dirección. El artículo de investigación Orion de 2026 describe 20 restricciones encontradas al programar el ANE mediante interfaces privadas. Sus autores identifican la compilación, la disposición de memoria y el comportamiento numérico como barreras prácticas.

Orion aún informa de resultados significativos con transformers. En un M4 Max, el sistema produjo más de 170 tokens por segundo para GPT-2 con 124 millones de parámetros. También entrenó un modelo de 110 millones de parámetros durante 1.000 pasos en 22 minutos.

Estas mediciones muestran que el ANE puede ejecutar cargas de trabajo de modelos de lenguaje. No lo establecen como el mejor objetivo para todos los modelos grandes ni para cada etapa de la inferencia. La distinción entre la posibilidad técnica y el ajuste arquitectónico sigue siendo esencial.

El software público de Apple mantiene el hardware a distancia

Los desarrolladores pueden solicitar el Neural Engine mediante Core ML, pero Apple sigue controlando cómo se compilan, dividen y despachan las cargas de trabajo.

Apple expone el Neural Engine principalmente mediante Core ML, su framework público para desplegar modelos de aprendizaje automático. Los desarrolladores proporcionan un modelo compatible, mientras que el framework decide si las operaciones individuales deben usar la CPU, la GPU o el Neural Engine.

Los controles de unidades de cómputo de Apple permiten que una aplicación habilite combinaciones de esos procesadores. Un desarrollador puede permitir todas las unidades disponibles o excluir la GPU o el Neural Engine. La interfaz pública no ofrece programación directa de los descriptores de tareas del ANE.

Este modelo protege la portabilidad entre dispositivos Apple. Una aplicación puede describir la predicción que necesita sin codificar la disposición de registros de una generación específica de chips. Apple puede revisar compiladores y políticas de planificación mientras mantiene estable la interfaz de la aplicación.

La contrapartida es la visibilidad. Los desarrolladores no pueden confiar en que Core ML coloque cada operación compatible en un motor específico. Tampoco pueden inspeccionar el programa final de bajo nivel con el control esperado de las API de cómputo de GPU.

Apple explica que la ejecución de Core ML puede usar la CPU, la GPU y el Neural Engine al tiempo que reduce el consumo de memoria y energía. Este enfoque resulta apropiado para aplicaciones que buscan una inferencia eficiente en el dispositivo sin ajustes específicos de hardware.

Es menos satisfactorio para investigadores que examinan límites arquitectónicos. Un benchmark podría recurrir a otro procesador, dividir un grafo entre procesadores o encontrarse con transformaciones del compilador que ocultan el comportamiento subyacente del hardware.

El trabajo de ingeniería inversa elimina parte de esa incertidumbre. Examina descriptores de tareas, escrituras de registros, colas, interrupciones y rutas de memoria por debajo de Core ML. Esta perspectiva ayuda a distinguir las restricciones impuestas por el software de las limitaciones creadas por el silicio.

Sin embargo, las interfaces privadas generan su propia incertidumbre. Carecen de las garantías públicas de compatibilidad de Apple y pueden cambiar con una actualización del sistema operativo. El código de investigación que funciona hoy podría fallar después de que cambie el compilador, el formato del modelo o el servicio de tiempo de ejecución.

Esta brecha sitúa a Apple en una posición inusual. La empresa distribuye hardware dedicado al aprendizaje automático en teléfonos, tabletas, Mac y visores. Sin embargo, los desarrolladores independientes tienen un control limitado sobre uno de los bloques más distintivos dentro de esos procesadores.

Para las aplicaciones convencionales, esa limitación puede ser una elección deliberada de producto. Apple optimiza el dispositivo completo y decide dónde se ejecuta cada operación. La mayoría de los desarrolladores se benefician más de un despliegue predecible que del acceso directo a registros.

Los desarrolladores de IA generativa suelen necesitar lo contrario. Experimentan con formatos de cuantización, kernels de atención, disposiciones de caché y operaciones fusionadas. También comparan el rendimiento entre arquitecturas de modelos que cambian rápidamente.

Las GPU permiten esa experimentación porque sus modelos de programación exponen cómputo más general. Los desarrolladores pueden implementar nuevos kernels sin esperar una ruta de compilación dedicada. El coste es una mayor responsabilidad sobre la sincronización, el acceso a memoria y el ajuste del rendimiento.

El Neural Engine independiente representa el otro extremo de ese espectro. Su compilador y ruta de datos fija pueden ofrecer una ejecución eficiente cuando un modelo encaja. Cuando la carga de trabajo cambia, la especialización se convierte en una limitación en lugar de una ventaja.

La estrategia de software de Apple impide que los desarrolladores resuelvan directamente esa tensión. Core ML puede ocultar las variaciones de hardware, pero no puede hacer que un sistema de memoria orientado a CNN se comporte como una GPU flexible. La ingeniería inversa expone el límite que el framework normalmente oculta.

El M5 convierte a la GPU en el principal rival

El M5 de Apple no elimina el Neural Engine independiente, pero otorga a la GPU un papel más directo en la hoja de ruta de IA de la compañía.

Apple anunció el M5 en octubre de 2025 con una GPU de 10 núcleos que incorpora un Neural Accelerator en cada núcleo. El chip también mantuvo un Neural Engine mejorado de 16 núcleos. Este diseño sitúa hardware especializado para matrices en ambos lados de la contienda arquitectónica.

Según el anuncio del chip M5 de Apple, la nueva GPU ofrece más de cuatro veces el rendimiento máximo de cómputo de IA de la GPU del M4. Apple también elevó el ancho de banda de memoria unificada a 153GB/s, casi un 30 por ciento por encima del M4.

Son mediciones controladas por Apple, y los detalles de la carga de trabajo determinan el rendimiento real de las aplicaciones. Aun así, la ubicación de los nuevos aceleradores resulta más reveladora que el multiplicador del titular. Apple los integró en núcleos de GPU programables en vez de depender únicamente del Neural Engine independiente.

La GPU combina ejecución especializada de matrices con un entorno ya adaptado a algoritmos cambiantes. Apple afirma que los desarrolladores pueden programar los Neural Accelerators mediante API de tensores en Metal 4. Esto ofrece una vía pública hacia cargas de trabajo de IA basadas en GPU sin exponer el formato privado de comandos del ANE independiente.

Yoon interpreta este cambio como el principio del fin para la NPU independiente, o unidad de procesamiento neuronal. La formulación es deliberadamente provocadora, y las decisiones de producto de Apple aún no confirman una retirada real.

El M5 sigue incluyendo un Neural Engine independiente. Apple lo describe como más rápido y lo vincula a funciones del sistema, incluido el procesamiento de fotos y la generación de Persona espacial. Estas tareas se asemejan a las cargas de trabajo de inferencia acotadas y predecibles que los aceleradores dedicados manejan bien.

La conclusión más defendible es más acotada. Apple ahora considera la GPU como un destino principal para cargas de trabajo exigentes de IA generativa, mientras que el Neural Engine conserva un papel en la inferencia eficiente del sistema.

Esa división coincide con la evidencia obtenida mediante ingeniería inversa. Una GPU puede combinar aceleración de matrices con operaciones de memoria flexibles, kernels generales y acceso directo para desarrolladores. Una NPU de función fija puede minimizar la sobrecarga para grafos estables con patrones de ejecución conocidos.

Ningún diseño gana en todas las cargas de trabajo. Un procesador general emplea área y energía para ofrecer una flexibilidad que una canalización fija evita. Un motor especializado pierde adaptabilidad cuando los modelos exigen nuevos patrones de movimiento.

El M5 sugiere que Apple quiere ambos. Su Neural Engine independiente puede respaldar funciones consolidadas en el dispositivo, mientras que los GPU Neural Accelerators se dirigen a modelos cuyos operadores y comportamiento de memoria siguen cambiando.

Esta estrategia híbrida también presiona la pila de software de Apple. Core ML debe elegir entre procesadores cada vez más capaces. Metal debe proporcionar a los desarrolladores suficiente control para aprovechar las nuevas unidades de GPU. El compilador debe evitar mover datos entre procesadores con tanta frecuencia que los costes de transferencia borren la aceleración.

Por tanto, la presión no es simplemente Nvidia frente a Apple, ni macOS frente a Linux. Es una contienda dentro del propio silicio de Apple entre eficiencia de función fija y aceleración programable.

Esa contienda comenzó mucho antes de la IA generativa. Los chips de Apple ya dividen el trabajo entre CPU, GPU, motores multimedia, procesadores de imagen y hardware de seguridad. La diferencia ahora es que el diseño de modelos de IA cambia a un ritmo que vuelve especialmente arriesgados los largos ciclos de planificación de hardware.

Un bloque dedicado puede requerir años para diseñarse y validarse. Las arquitecturas Transformer, las variantes de atención y las técnicas de cuantización pueden cambiar en cuestión de meses. Integrar aceleración más adaptable en la GPU reduce el coste de equivocarse al anticipar el futuro.

La ingeniería inversa no demuestra que el Neural Engine haya terminado

La retrospectiva explica una incompatibilidad arquitectónica, pero no puede establecer el futuro plan de producto de Apple ni medir cada implementación más reciente del ANE.

Los hallazgos más profundos se refieren a la generación M1. Desde entonces, Apple ha lanzado varias familias de procesadores, y los detalles internos pueden cambiar sin documentación pública. Las conclusiones sobre chips posteriores requieren mediciones directas, no similitudes visuales ni nombres de marketing.

Yoon reconoce la incertidumbre en partes del análisis de la disposición física. Las imágenes del chip pueden revelar grandes bloques de memoria y estructuras de cómputo repetidas, pero no explican cada decisión de enrutamiento. Algunas conclusiones siguen siendo interpretaciones fundamentadas.

La investigación también se centra en la estructura del hardware, no en un benchmark exhaustivo de aplicaciones. Muestra por qué el movimiento de memoria debería limitar determinadas cargas de trabajo. No compara todos los modelos entre ANE, GPU y CPU bajo límites de potencia idénticos.

Orion proporciona mediciones más recientes útiles, pero utiliza API privadas y software de investigación. Sus experimentos con GPT-2 y TinyStories demuestran acceso y capacidad, no una preparación amplia para producción con los modelos de lenguaje grandes actuales.

Otro proyecto abierto ha informado de entrenamiento directo mediante interfaces privadas obtenidas por ingeniería inversa. Sus mediciones del M4 sitúan el rendimiento FP16 en torno a 18,6 billones de operaciones por segundo y el rendimiento INT8 en torno a 35,1 billones de operaciones por segundo. Estas cifras dependen de configuraciones de convolución seleccionadas y no deben generalizarse a modelos completos.

La madurez del software importa tanto como el hardware. Un compilador muy optimizado puede reestructurar grafos, fusionar operaciones y reducir transferencias. Un controlador de investigación puede exponer correctamente el motor y, al mismo tiempo, dejar sin utilizar gran parte de su rendimiento.

También se aplica el riesgo opuesto. Los microbenchmarks máximos pueden mantener ocupadas las unidades aritméticas en condiciones ideales y ocultar los cuellos de botella de los modelos reales. La latencia de extremo a extremo, el uso de memoria, el consumo energético y el tiempo de compilación determinan si un acelerador beneficia a una aplicación.

Apple también podría rediseñar el Neural Engine independiente manteniendo su nombre de producto. Una memoria compartida más grande, rutas de datos revisadas o nuevos formatos de tareas podrían abordar las limitaciones encontradas en el M1. El anuncio del M5 no revela ese nivel de detalle.

La seguridad presenta otra razón para el acceso controlado. Apple utiliza hardware del Neural Engine en flujos de trabajo biométricos protegidos. Su documentación de seguridad de la plataforma describe reinicios de estado y controles de memoria para el funcionamiento seguro del Neural Engine en sistemas más recientes.

Ese papel no exige abrir el mismo hardware a cargas de trabajo Linux arbitrarias. También significa que la presencia continuada del bloque puede reflejar una arquitectura de sistema que va más allá de los modelos de lenguaje para consumidores.

La eficiencia energética sigue siendo otra comparación pendiente. La decodificación autorregresiva podría ejecutarse de forma más natural en hardware de GPU programable, pero un motor dedicado aún puede superarla en tareas de visión, audio y clasificación. Apple vende dispositivos alimentados por batería, donde esos ahorros importan.

Por tanto, la afirmación creíble no es que el Neural Engine haya muerto. Es que sus supuestos de diseño originales ya no cubren toda la gama de cargas de trabajo de IA estratégicamente importantes.

Esta distinción mantiene la ingeniería inversa retrospectiva del Neural Engine de Apple anclada en la evidencia. El proyecto ilumina una bifurcación arquitectónica, mientras que los lanzamientos de productos de Apple determinarán hasta qué punto la compañía sigue cualquiera de las dos rutas.

Tres señales mostrarán qué arquitectura gana

Las próximas API, benchmarks y diseños de chips de Apple revelarán si el Neural Engine del M1 era una plantilla duradera o una rama especializada.

La primera señal es el acceso de los desarrolladores a los Neural Accelerators de la GPU del M5. Metal 4 debe exponer operaciones de tensores útiles sin ocultar tanta planificación que los investigadores se enfrenten a otra caja negra.

Las herramientas funcionales reforzarán la idea de que Apple ha elegido la aceleración de GPU programable para modelos que cambian rápidamente. Las API limitadas o el soporte reducido de operadores debilitarían esa interpretación y preservarían un papel mayor para el hardware gestionado por Core ML.

La segunda señal es el rendimiento de extremo a extremo en cargas de trabajo Transformer representativas. Las comparaciones útiles deben incluir el procesamiento de prompts, la generación de tokens, el comportamiento de memoria con contexto largo, el uso de energía y el tiempo de carga de modelos.

Los microbenchmarks por sí solos no resolverán la cuestión. Un procesador puede liderar el rendimiento de matrices mientras pierde tiempo en transferencias de pesos, movimiento de caché o compilación de grafos. Las mediciones también deberían identificar qué unidad de cómputo ejecutó cada operación.

Los resultados de aplicaciones en M5 serán especialmente importantes. Los modelos de lenguaje locales y el software de difusión pueden poner a prueba los nuevos aceleradores de GPU bajo las cargas de trabajo que Apple destacó explícitamente. Las mejoras consistentes validarían el avance hacia la aceleración dentro de núcleos programables.

La tercera señal es la arquitectura del próximo Neural Engine independiente de Apple. Apple puede conservar la etiqueta de 16 núcleos mientras cambia por debajo el tamaño de memoria, las interconexiones, la planificación y la precisión compatible.

Un sistema de memoria local rediseñado cuestionaría la idea de que el bloque independiente se acerca a su fin. Cambios mínimos, combinados con mayores inversiones en GPU, respaldarían la interpretación de Yoon.

El progreso de Linux ofrece una vía secundaria de verificación. La comunidad Asahi cuenta con una amplia experiencia documentando Apple silicon mediante observación y experimentación de sala limpia. Su trabajo de ingeniería inversa ya ha producido controladores abiertos para otros bloques no documentados.

Un controlador ANE utilizable permitiría a los investigadores comparar las decisiones de Core ML con el envío directo de tareas. También podría revelar si compiladores alternativos pueden recuperar rendimiento que el framework público de Apple deja inaccesible.

Sin embargo, la compatibilidad con Linux no debe confundirse con el principal resultado comercial. El controlador importa porque convierte el comportamiento oculto del hardware en evidencia comprobable. Los propios dispositivos, frameworks y cargas de trabajo de Apple decidirán el futuro de la arquitectura.

Los desarrolladores deberían observar dónde sitúa Apple la nueva programabilidad pública. También deberían separar el rendimiento teórico de la aplicación completa. El procesador con la cifra principal más alta no es necesariamente el que mueve los datos del modelo con mayor eficiencia.

Los equipos que realizan investigaciones técnicas similares necesitan un registro duradero de experimentos, hallazgos de registros, benchmarks e hipótesis descartadas. Una base de conocimientos de ingeniería con capacidad de búsqueda puede mantener esa evidencia conectada a medida que cambian las herramientas y las generaciones de chips.

La ingeniería inversa retrospectiva del Neural Engine de Apple captura, en última instancia, un momento poco común en el que el silicio antiguo explica una estrategia nueva. El M1 muestra los beneficios y costes de incorporar supuestos de CNN al hardware. El M5 muestra que Apple añade flexibilidad sin abandonar de inmediato la especialización.

La siguiente pregunta es concreta: ¿los futuros chips de Apple ampliarán la aceleración de GPU programable mientras dejan el Neural Engine para tareas estables del sistema, o Apple reconstruirá el bloque independiente para Transformers? Observe las API y el comportamiento de memoria, no solo la cifra de TOPS.