Gráfico de Concepto & Resumen usando Claude 3 Opus | Chat GPT4 | Gemini Adv | Llama 3:

Resumen:

1.-Facebook ha estado trabajando en mejorar el rendimiento de las redes neuronales convolucionales, enfocándose en hacer las convoluciones más eficientes.

2.-Las convoluciones son computacionalmente costosas, ocupando más del 80% del tiempo en redes convolucionales. Son la principal justificación para usar GPUs.

3.-El enfoque es realizar convoluciones más eficientemente en la base de Fourier usando la Transformada Rápida de Fourier (FFT).

4.-En el dominio de Fourier, las convoluciones se convierten en multiplicaciones puntuales, reduciendo el costo computacional de N^2 a NlogN al usar FFT.

5.-Contribuciones principales: Descomponer convoluciones en FFTs, transponer y multiplicaciones de matrices; añadir autoajuste; desarrollar implementaciones de FFT y multiplicación de matrices de mayor rendimiento.

6.-El problema ahora está limitado por el ancho de banda en lugar de por el cálculo. Los requisitos de ancho de banda pueden trasladarse de la memoria a la caché usando técnicas HPC.

7.-El techo de rendimiento alcanzable ha sido elevado de estar limitado por los FLOPs de GPU a ahora estar limitado por el ancho de banda de memoria.

8.-Las convoluciones se representan en el dominio de Fourier aplicando FFT a tensores de entrada, realizando operaciones y transformando de nuevo.

9.-Se utilizan buffers intermedios para almacenar valores temporales. Algunos son siempre necesarios mientras que otros dependen de si se realiza transposición explícita.

10.-La implementación inicial usó librerías de NVIDIA y añadió autoajuste para explorar el espacio de diseño de llamadas por lotes vs iteradas, interpolación FFT, etc.

11.-El autoajustador también consideró compensaciones entre eficiencia y consumo adicional de memoria para transposición y multiplicación de matrices (FBMM).

12.-Las librerías FFT del proveedor están ajustadas para grandes conjuntos de datos HPC, pero las ConvNets pueden funcionar bien con muchas FFTs pequeñas.

13.-Se desarrolló una nueva implementación FPFFT para reducir ineficiencias en la librería FFT de NVIDIA y permitir relleno cero sobre la marcha.

14.-La implementación FPFFT del documento trató la GPU como una máquina vectorial amplia, pero aún estaba limitada por el número de operaciones de permutación.

15.-Ver la GPU como una máquina vectorial amplia es menos efectivo debido al número limitado de permutaciones en comparación con multiplicaciones.

16.-El consumo de memoria es una compensación entre paralelismo, evitar colisiones, eficiencia y reutilización. Necesita equilibrarse con la memoria disponible.

17.-La versión del documento utilizó un aumento de memoria de 9x para la capa más grande, 3x cuando solo se usaba FBFFT y FBMM. El mosaico ayuda para entradas grandes.

18.-La clave es que las ConvNets solo necesitan FFTs de 16x16 o 32x32, con el costo siendo el mismo para tamaños de kernel de hasta 15x15.

19.-Enfocarse primero en el algoritmo, luego optimizar. El problema ahora está limitado por el ancho de banda de la memoria principal. Los números presentados son de una implementación de diciembre de 2014.

20.-Los mapas de calor comparan QFFT+QBLAST vs cuDNN. Para kernels de 3x3 ya hay regímenes donde QFFT+QBLAST gana, más para 5x5, 7x7, 9x9.

21.-Conteos de kernels muy pequeños (<100) están limitados por latencia en lugar de por ancho de banda y es poco probable que se beneficien del enfoque FFT.

22.-Los últimos números en Torch se basan en la implementación de diciembre de 2014, no en el trabajo más actual. El rendimiento es decente pero puede mejorarse.

23.-En VGG, el tamaño de entrada fuerza la interpolación en una gran base de Fourier, pero el mosaico ayuda significativamente en este caso.

24.-El trabajo reciente incluye FFT en mosaico, relleno implícito, reutilización de buffers, gestión de memoria para reutilizar FFTs calculados e implementación asincrónica.

25.-Se está trabajando en un FFT más rápido y los números seguirán mejorando. El mensaje principal es que, aunque el problema está limitado por el ancho de banda de memoria, todavía hay espacio para crecer.

26.-Usar float16 podría proporcionar hasta un 2x de mejora en el rendimiento ya que el problema está limitado por el ancho de banda de memoria.

27.-El mosaico permite descomponer una convolución grande en más pequeñas con menor huella de memoria. Los buffers pueden reutilizarse o expandirse para ajustarse a la memoria disponible.

28.-Si se detecta un error de memoria insuficiente, la implementación puede revertir a un modo de bajo consumo de memoria.

29.-El trabajo ha desplazado el cuello de botella del rendimiento del cálculo al ancho de banda de memoria, pero aún hay oportunidades para una mayor optimización.

30.-Se anticipan desarrollos futuros emocionantes, aprovechando técnicas como el cálculo de baja precisión (float16) para mejorar aún más el rendimiento dentro de las restricciones de ancho de banda de memoria.

Bóveda de Conocimiento construida porDavid Vivancos 2024