What actually runs: a measurement study of language model placement and decode speed on the Apple Neural Engine
A través de un riguroso estudio de medición sobre la ubicación de los modelos de lenguaje y la velocidad de decodificación en el Apple Neural Engine, el autor demuestra que la expresión computacional y la codificación de pesos, más que la arquitectura del modelo por sí sola, dictan la residencia en el acelerador y el rendimiento, lo que conduce a un procedimiento de diseño que prioriza la eficiencia de codificación para lograr modelos ternarios significativamente más pequeños y rápidos.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
Imagina que un teléfono inteligente intenta comprender una conversación. Para hacerlo, debe ejecutar un cerebro digital masivo, un modelo de lenguaje, directamente en el dispositivo. Para que esto funcione sin problemas, el teléfono necesita utilizar un procesador especial y ultrarrápido construido precisamente para este tipo de pensamiento, en lugar de su cerebro principal de propósito general. El desafío es que este procesador especial es exigente; solo ejecutará ciertos tipos de cálculos y se niega a ejecutar otros, incluso si esos otros son matemáticamente idénticos. Durante años, los desarrolladores han intentado adivinar qué cálculos funcionarán y cómo hacerlos rápidos, basándose a menudo en reglas empíricas que resultan ser erróneas. Han asumido que si un modelo es lo suficientemente pequeño, funcionará en el procesador rápido, o que hacer los números más pequeños siempre ayudará. Pero nadie había observado realmente al procesador para ver qué estaba haciendo realmente, ni había medido exactamente cómo el tamaño del modelo y la forma en que se almacenan sus números cambiaban su velocidad.
Un investigador llamado Shahir M A decidió dejar de adivinar y empezar a observar. Utilizando una computadora Apple con un chip M1, construyó una serie de experimentos para ver exactamente qué sucede cuando un modelo de lenguaje intenta ejecutarse en el procesador especial del teléfono, conocido como Neural Engine. No se limitó a mirar lo que el software decía que haría; midió la electricidad y los datos reales moviéndose a través del chip para ver qué estaba pasando realmente. Probó docenas de formas diferentes de construir la misma operación matemática, entrenó modelos reales de diferentes tamaños y cambió la forma en que se almacenaban los números dentro de ellos, variando desde la precisión estándar hasta formatos de baja precisión muy comprimidos. Su objetivo era simple: descubrir qué es lo que realmente logra que un modelo entre en el procesador rápido y qué tan rápido puede hablar una vez que llega allí.
Lo primero que descubrió fue que al procesador no le importa lo que signifique un cálculo, sino cómo está escrito. Descubrieron que si escribes un tipo específico de normalización —un paso que ayuda al modelo a mantener sus números estables— de una manera, el procesador lo acepta de inmediato y lo ejecuta a máxima velocidad. Pero si escribes exactamente el mismo paso matemático utilizando un conjunto de instrucciones diferente y ligeramente más complicado, el procesador se niega a tocarlo y obliga al teléfono a usar su cerebro de propósito general más lento en su lugar. Es como si el procesador hablara un dialecto específico de las matemáticas; si usas el dialecto correcto, te escucha, pero si usas uno diferente, aunque el significado sea el mismo, se aleja. Esto significa que la forma en que un desarrollador escribe el código es tan importante como la matemática misma.
El segundo hallazgo, y quizás el más sorprendente, fue que el tamaño del modelo no es lo único que decide si puede ejecutarse en el procesador rápido. Los investigadores descubrieron que un modelo con unos veintiséis millones de parámetros, escrito en precisión estándar, era demasiado pequeño para ejecutarse en el procesador especial en absoluto. Se vio obligado a ejecutarse en el cerebro lento, tardando más de un segundo en generar cada palabra. Sin embargo, cuando tomaron ese mismo modelo y comprimieron los números dentro de él para usar menos bits, el procesador de repente lo aceptó. La versión comprimida se ejecutó en el procesador rápido y generó palabras en menos de un segundo. De hecho, para los modelos más pequeños, comprimir los números era la única forma de lograr que entraran en el procesador rápido. El procesador tenía una regla oculta: no ejecutaría modelos pequeños a menos que estuvieran comprimidos. Esto invirtió la suposición común de que los modelos más grandes son siempre los que necesitan el procesador rápido; aquí, los pequeños necesitaban la compresión para poder entrar por la puerta.
Una vez que el modelo estaba dentro del procesador rápido, la velocidad estaba determinada casi por completo por la cantidad de datos que tenían que moverse, no por la complejidad de las matemáticas. Los investigadores midieron el flujo de datos y descubrieron que, por cada palabra que el modelo generaba, tenía que transmitir todo el conjunto de sus pesos —los números que compon la base de su conocimiento— a través del procesador. Esto sucedía por cada palabra, sin importar cuán larga fuera la conversación. Debido a esto, la velocidad estaba directamente ligada a cuántos bits había en esos pesos. Un modelo con números comprimidos de baja precisión movía muchos menos datos y, por lo tanto, era mucho más rápido. Descubrieron que un modelo que utilizaba números de dos bits era casi tres veces más rápido que un modelo con números estándar, simplemente porque tenía que mover menos datos. El tipo de matemáticas que el modelo utilizaba, como si se centraba más en la atención o en la convolución, importaba muy poco para la velocidad una vez que ya estaba funcionando en el procesador. Lo único que importaba era el tamaño de los datos que se movían.
Los investigadores concluyeron que la mejor manera de construir un modelo de lenguaje para un teléfono es empezar con la compresión, no con el tamaño. En lugar de construir un modelo grande y luego intentar encogerlo, se debe elegir primero el formato más comprimido posible y luego dedicar el presupuesto de memoria disponible a añadir más parámetros. Descubrieron que un modelo con veinticinco millones de parámetros, utilizando un tipo específico de matemáticas comprimidas, podía caber en solo diez megabytes de espacio y generar palabras en aproximadamente seis décimas de milisegundo. Esto era casi diez veces más pequeño y tres veces más rápido que los modelos estándar no comprimidos con los que los desarrolladores suelen empezar. El estudio demostró que el camino hacia un modelo de lenguaje rápido en el dispositivo no consiste en hacer el modelo más grande o complejo, sino en elegir la forma correcta de escribir las matemáticas y la forma correcta de almacenar los números. Al medir el flujo real de datos, demostraron que la clave de la velocidad no es solo tener un procesador rápido, sino saber exactamente cómo alimentarlo.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.