Los modelos de lenguaje energéticamente eficientes solo necesitan sumas

 (arxiv.org)
2 puntos por GN⁺ 2024-10-10 | 1 comentarios | Compartir por WhatsApp
  • L-Mul es un algoritmo de multiplicación de complejidad lineal que parte de la observación de que el gran costo energético de los LLM proviene de las multiplicaciones de punto flotante, e intenta aproximarlas con sumas enteras
  • Una multiplicación fp32 tiene un costo energético 37 veces mayor que una suma int32, por lo que aplicar L-Mul al hardware de procesamiento de tensores tiene el potencial de reducir el 95% de la energía de las multiplicaciones tensoriales de punto flotante elemento por elemento y el 80% de la energía de los productos punto
  • El método de cálculo omite la multiplicación de mantisas y el redondeo, procesa el signo con XOR y compone los bits restantes con una suma de la forma x[1:] + y[1:] - offset
  • En los experimentos, L-Mul con mantisa de 4 bits mostró una precisión similar a la multiplicación float8 e4m3, y L-Mul con mantisa de 3 bits produjo mejores resultados que float8 e5m2
  • Al aplicar atención L-Mul a LLM preentrenados sin entrenamiento adicional, la pérdida promedio en tareas de inferencia de lenguaje natural fue de 0.07%, y en tareas de visión la precisión promedio mejoró 0.12%

El cuello de botella al que apunta L-Mul

  • Las redes neuronales grandes destinan una gran parte del cómputo a las multiplicaciones tensoriales de punto flotante, y esta operación tiene un costo energético mayor que la suma
  • L-Mul es un algoritmo de multiplicación de complejidad lineal que aproxima la multiplicación de números de punto flotante mediante sumas enteras
  • Se puede aplicar a varias etapas de cálculo
    • multiplicaciones dentro del mecanismo de atención
    • multiplicación de matrices
    • multiplicación elemento por elemento
  • En los LLM basados en Transformer, la atención tiene complejidad O(N²) con respecto a la longitud del contexto de entrada N, y junto con las multiplicaciones tensoriales de alta dimensión se convierte en uno de los principales cuellos de botella de eficiencia computacional

Costo energético por operación aritmética

  • La tabla de costo operativo de Horowitz (2014) muestra directamente la diferencia de energía entre sumas y multiplicaciones
    • suma int8: 0.03 pJ
    • suma int32: 0.1 pJ
    • suma fp16: 0.4 pJ
    • suma fp32: 0.9 pJ
    • multiplicación int8: 0.2 pJ
    • multiplicación int32: 3.1 pJ
    • multiplicación fp16: 1.1 pJ
    • multiplicación fp32: 3.7 pJ
  • Una multiplicación fp32 usa 4 veces más energía que una suma fp32, y 37 veces más que una suma int32
  • En PyTorch, la precisión de acumulación predeterminada para los resultados de multiplicación de tensores está configurada en fp32
  • Excluyendo I/O y operaciones de control, al aproximar una multiplicación fp32 con una suma int32 el uso de energía queda en alrededor de 1/37 ≈ 2.7%
  • Incluso si se reduce la precisión de acumulación a fp16, la suma entera usa solo alrededor del 4.7% de la energía de una multiplicación de punto flotante

Cómo calcula L-Mul

  • Una multiplicación convencional de punto flotante para dos números x, y tiene la forma siguiente
    • (1 + xm) · 2^xe · (1 + ym) · 2^ye
    • el resultado se compone como (1 + xm + ym + xm · ym) · 2^(xe+ye) y el signo mediante XOR
  • El cuello de botella del cálculo es la multiplicación de mantisas de m bits con complejidad O(m²)
  • L-Mul elimina xm · ym y lo aproxima con la siguiente forma
    • (1 + xm + ym + 2^-l(m)) · 2^(xe+ye)
  • l(m) varía según el número de bits de la mantisa
    • si m ≤ 3, entonces m
    • si m = 4, un valor aparte
    • si m > 4, un valor aparte
  • La implementación a nivel de bits se resume en una fórmula más simple
    • bit de signo: x[0] ⊕ y[0]
    • bits restantes: x[1:] + y[1:] - offset
  • Como el formato de punto flotante maneja implícitamente 1 + xm, L-Mul puede implementarse en la práctica con un solo sumador
  • Si la suma de mantisas supera 2, el carry se transfiere automáticamente al exponente
  • Al omitir la multiplicación de mantisas y el proceso de redondeo requeridos en la multiplicación de punto flotante convencional, reduce la cantidad de cómputo

Aplicación a la atención Transformer

  • La atención basada en L-Mul genera Q, K, V y luego reemplaza la multiplicación de matrices del cálculo de atención por L-matmul
  • La forma del cálculo es la siguiente
    • K = H · Wk
    • Q = H · Wq
    • V = H · Wv
    • A = softmax[L-matmul(Q, Kᵀ) / √d]
    • H′ = L-matmul(A, H)
  • L-matmul es una multiplicación de matrices en la que todas las multiplicaciones convencionales de punto flotante se implementan con L-Mul
  • Esta estructura reemplaza multiplicaciones de punto flotante por sumas enteras para reducir el uso de recursos de cómputo

Análisis de precisión y complejidad, y resultados experimentales

  • El análisis de precisión evalúa a cuántos bits de la fracción de un número de punto flotante equivale conservar L-Mul
  • En el análisis basado en operandos con distribución uniforme, L-Mul es más preciso que fp8 e5m2
  • En un análisis práctico basado en la distribución de pesos combinados de 5 LLM preentrenados, puede alcanzar una precisión superior a fp8 e4m3 con operandos de mantisa de 5 bits
  • Los resultados experimentales coinciden con la estimación teórica del error
    • L-Mul con mantisa de 4 bits tiene una precisión similar a la multiplicación float8 e4m3
    • L-Mul con mantisa de 3 bits tiene una precisión mayor que float8 e5m2
  • En LLM preentrenados, la implementación estándar de atención se reemplazó directamente por atención L-Mul, sin entrenamiento adicional
    • pérdida promedio de rendimiento en tareas de commonsense, razonamiento estructurado y comprensión del lenguaje: 0.07%
    • cambio promedio de precisión en tareas de visual question answering, alucinación de objetos e instrucciones visuales de formato libre: mejora de 0.12%
  • En los experimentos de fine-tuning, un modelo en el que todas las multiplicaciones de atención, transformación lineal y multiplicación elemento por elemento se sustituyeron por L-Mul con mantisa de 3 bits mostró un rendimiento similar al de un modelo estándar que usa precisión de acumulación float8 e4m3
  • En la estimación del costo computacional a nivel de compuertas, la multiplicación convencional está en el siguiente orden
    • multiplicación fp16: aprox. 584
    • multiplicación fp8 e4m3: aprox. 325
    • multiplicación fp8 e5m2: aprox. 296
  • La estimación del costo computacional a nivel de compuertas para L-Mul es menor
    • fp16 L-Mul: aprox. 256
    • fp8 L-Mul: aprox. 157
  • Como no existe una implementación nativa de L-Mul en GPU, es difícil aprovechar completamente su eficiencia, y se recomienda entrenar y alojar modelos basados en L-Mul en dispositivos con arquitecturas especializadas que integren este diseño
  • Esta tecnología se encuentra en estado de patent pending

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-10-10
Comentarios en Hacker News

  • Recuerdo que antes, cuando el cálculo en coma flotante era caro en CPUs de Intel, los programadores usaban varios trucos con enteros para esquivarlo
    Chuck Moore, conocido por Forth, mostraba una técnica donde valores como 1.6 × 4.1 se trataban durante el cálculo intermedio como enteros, por ejemplo 16 × 41, y luego al mostrar el resultado se volvía a poner el punto decimal en la “posición correcta”. Si el rango de los valores en coma flotante no superaba 65536 incluso tras multiplicarlos por 10, funcionaba bien también con enteros de 16 bits, y encajaba muy bien en chips embebidos que tenían que calcular rápidamente valores analógicos de 10 bits varias veces por segundo
    Hace mucho también hablé con un ingeniero de Microsoft que había trabajado en Microsoft Streets and Trips, y me dijo que ellos también tomaban números y cálculos que normalmente habrían sido de coma flotante y los metían en algún formato empaquetado de enteros con solo la precisión realmente necesaria, para ejecutarlos más rápido en las CPUs de la época y comprimirlos más fácilmente para que cupieran en un CD-ROM. Hay capturas de pantalla en https://archive.org/details/3135521376_qq_CD1

    • Esta técnica se llama aritmética de punto fijo, y ojalá más programadores la conocieran, porque es muy buena
      El código financiero serio debería usar esto, pero en la industria financiera no lo vi tan seguido salvo cuando corrían en mainframes. Curiosamente, vi mucha más aritmética de punto fijo en rasterizadores por software como FreeType, GDI, WPF y WARP (rasterizador de referencia de D3D11)
    • Recuerdo haber usado el generador de fractales FRACTINT, de la época en que los coprocesadores de coma flotante todavía no eran comunes. Calculaba y mostraba fractales usando matemáticas de punto fijo, y en ese entonces los fractales parecían increíblemente geniales, así que todo el mundo quería montar un negocio de fractales y todos los Nobel iban para investigadores de fractales
    • Ozaki ha estado haciendo multiplicación de matrices fp64 con tensor cores int8
      https://arxiv.org/html/2306.11975v4
      Muy interesante
    • Hasta donde sé, sigue siendo la mejor manera de manejar dinero o cifras financieras incluso hoy
    • Ese truco en particular se conoce como aritmética de punto fijo. Es un concepto distinto del punto fijo de una función

  • La afirmación es algo como que “se puede reducir potencialmente en 95% el costo energético de la multiplicación de tensores elemento por elemento en coma flotante y en 80% el del producto punto”; si esto fuera sobre redes neuronales convolucionales, optimizar el cálculo tendría mucho más impacto
    Pero los transformers son livianos en cómputo y pesados en memoria. El cuello de botella es llevar los pesos del modelo al core, y los ahorros energéticos citados de 95% y 80% son cifras aisladas solo para la operación de multiplicación, no para toda la inferencia

    • El prefill sigue siendo dominante en cómputo incluso con batch único, y el decoding con múltiples batches también
      Esa frase repetida de que “la inferencia de transformers decoder-only está limitada por el ancho de banda de memoria” solo es rigurosamente cierta para decoding de batch único con tamaño de batch 1. Ahí es porque casi todo son productos vector-matriz
    • Peor aún. La ganancia energética está comparada contra cálculo fp32, pero en fp8 el multiplicador ya es muy pequeño, así que el sumador y el shifter pasan a representar una parte mayor del costo energético y del área del operador, por lo que la ganancia de este paper sería menor
      En fp8, el conteo estimado de compuertas es 296 para un multiplicador fp8 normal y 157 para esta técnica, así que la ganancia de potencia del multiplicador sería bastante menor. Un 50% parece una estimación más razonable, y de nuevo, en fp8 la suma representa una parte importante de la operación en el producto punto
      En general, afirmar una ganancia de potencia de 80% con una pequeña pérdida de precisión parece bastante deshonesto. La ganancia de potencia aplica solo a operaciones fp32, mientras que la pequeña pérdida de precisión aplica solo a operadores fp8. No analizaron la pérdida de precisión en fp32 ni mostraron cuánta potencia se ahorra realmente en productos punto fp8
    • fp8 es lo bastante pequeño como para que la multiplicación pueda hacerse con circuitos mucho más simples que en formatos de coma flotante más grandes
      En formatos todavía más pequeños como fp4, incluso se podría usar simplemente una tabla de búsqueda, y entonces en realidad se parecería bastante a una forma algo estandarizada de cuantización
    • Una arquitectura realmente buena para transformers parece ser una de co-ubicación de memoria y cómputo
    • Eso solo aplica para un usuario único o inferencia ligera. En entrenamiento e inferencia por lotes, muy rápido puede volverse un cuello de botella de cómputo

  • [2023] GradIEEEnt half decent: The hidden power of imprecise lines
    http://tom7.org/grad/murphy2023grad.pdf
    También hay video: https://www.youtube.com/watch?v=Ae9EKCyI1xU

  • No lo he leído, pero me da la impresión de que esto no es más que usar una tabla logarítmica de alguna forma
    No lo digo de forma despectiva; lo pregunto porque siento que no entiendo bien los logaritmos en un nivel más fundamental, como el de compuertas lógicas. Si puedes convertir multiplicación en consulta de tabla y suma, parecería que también debería existir un circuito, o una combinación intermedia, que dé una suma difícil y una multiplicación fácil

    • El espacio logarítmico está bueno. Puedes reemplazar multiplicación por suma
      Esa parte es fácil y cualquiera puede implementarla en hardware. Lo complicado es al acumular, especialmente si quieres acumular sobre un rango grande sin salirte del espacio logarítmico
    • Sí, así es como funciona un sistema numérico logarítmico

  • Me parece raro que el paper no tenga una derivación y discusión adecuadas del término de error. Todo se trata solo de forma indirecta a través de resultados de inferencia

    • A mí también me pareció un paper un poco raro. Cuando haces estimaciones de compuertas solo con descripción textual y sin diagramas, es demasiado fácil dejar fuera partes necesarias
      Aunque no llegara a una explicación completa a nivel de compuertas, al menos habría hecho falta una figura con bloques etiquetados como “sumador” y cosas así. Ver el nombre de Vries en el primer párrafo tampoco ayudó mucho a generar confianza

  • En una nota al pie de la sección de método dice: “Se recomienda que los modelos basados en L-Mul se entrenen y hospeden en dispositivos con diseño de arquitectura especial integrado. Patente en trámite”

  • Parece que reduce la cantidad de cómputo, pero como sigue usando 8 bits por valor, no reduce los requerimientos de memoria para ejecutar la inferencia
    Por eso no me parece que haga los modelos más accesibles para uso en inferencia. Si este formato de almacenamiento también sirviera para entrenamiento, ahí sí podría haber una aplicación potencialmente interesante

    • En realidad es aproximadamente 0.5 bits menos eficiente por peso en términos de precisión y rango, pero el paper no enfatiza esto en absoluto

  • Mover bytes consume más de 10 veces la energía que calcular. La eficiencia de cómputo no es un problema tan grande como la gente cree
    Ahora mismo el cómputo simplemente está en el lugar equivocado; al menos la agregación inicial del producto punto debería estar justo al lado de la celda de memoria para evitar el bus de memoria

    • Aun así, ¿no podría ser útil para dispositivos con restricciones de batería?

  • En mi experiencia, los verdaderos magos de las matemáticas de punto fijo fueron los diseñadores de videojuegos de 8 y 16 bits
    Las optimizaciones que hicieron fueron asombrosas, y por ejemplo permitieron calcular matemáticas de matrices 3D en tiempo real para crear los primeros simuladores de vuelo y juegos de disparos en primera persona

    • Redefinir el ángulo como 2π = 256 fue un truco bastante ingenioso