¿Cómo es posible LLaMA.cpp?

• Gracias a LLaMA.cpp, que reescribe el código de inferencia de LLaMA en C++ puro, puede ejecutarse en hardware diverso como Pixel 5, MacBook Pro con M2 y Raspberry Pi
• Los modelos grandes normalmente requieren GPUs costosas, así que ¿cómo es posible esto?
• Las GPUs son favorables para deep learning por su gran ancho de banda de memoria y capacidad de cómputo, pero el ancho de banda de memoria suele ser el cuello de botella en la inferencia
  • Esto se debe a que, para el cálculo real, los datos deben moverse desde la memoria HBM (RAM) hacia la memoria on-chip
• La cuantización es importante en el uso de RAM para los pesos de LLaMA
  • Si se reduce la precisión, se puede disminuir drásticamente la cantidad de memoria necesaria para almacenar el modelo
  • Mediante la cuantización, se reduce la memoria necesaria para almacenar el modelo, lo que permite que quepa en la memoria de GPUs estándar de centros de datos y GPUs de consumo de gama alta
• El ancho de banda de memoria es el factor limitante en casi todas las tareas relacionadas con el muestreo de transformers
• Si se reducen los requisitos de memoria con métodos como la cuantización, el servicio del modelo se vuelve mucho más fácil
• Esta es otra razón para la destilación o para "entrenar modelos más pequeños durante más tiempo"

[breezymind]

Probé una prueba de embeddings cargando llama2 con LlamaCpp en una máquina local.

https://breezymind.com/llamacpp-embedding

[xguru]

El primer comentario de HN es útil.

"Para quienes tengan curiosidad, hay un costo al cuantizar un modelo.
https://oobabooga.github.io/blog/posts/perplexities/

Básicamente, la precisión baja un poco y pueden aparecer respuestas extrañas, con más posibilidades de desviarse de lo esperado o alucinar. Pero cuanto más parámetros tiene, menor es la pérdida de calidad. Así que, si el modelo es muy grande, la diferencia es prácticamente despreciable. Además, esto es solo el costo de la inferencia. El entrenamiento es un problema completamente distinto y requiere mucha más potencia.

Aun así, estamos viendo rendimiento a nivel de GPT-3 en un solo rack de servidores. Es un logro increíble si pensamos que, hace apenas 1 año, este tipo de IA era literalmente magia y solo podía ejecutarse en grandes centros de datos. Probablemente sea más fácil aumentar el ancho de banda y el tamaño de la memoria que la capacidad de cómputo bruta, según mi entendimiento limitado, así que quizá pronto tengamos dispositivos realmente "inteligentes"."

[GN⁺]

Comentarios de Hacker News

• Un artículo sobre el costo de cuantizar el modelo, la pérdida de precisión resultante y la posibilidad de respuestas anómalas. Sin embargo, cuanto más parámetros tiene el modelo, menos importante se vuelve esa pérdida.
• Un artículo que destaca el excelente rendimiento de GPT3, que ahora puede ejecutarse en un solo rack de servidor, una gran mejora frente a la IA del año pasado que requería un centro de datos a gran escala.
• Un texto que señala que la generación de tokens es serial y está limitada por el ancho de banda, pero la inserción del prompt no lo está y puede ejecutarse en lotes de 512+.
• Llama.cpp ahora tiene una cuantización de ~4 bits que casi no afecta la complejidad. Q6_K tiene una complejidad casi igual a FP16, pero es mucho más pequeño.
• La verdadera magia de Llama.cpp es la partición del modelo, que permite que una GPU discreta pequeña descargue por completo la inserción del prompt y parte de la inferencia del modelo. Esto es algo único en el área de la IA generativa.
• Los backends de GPU (OpenCL, Metal, CUDA, próximamente ROCm y Vulkan) son la forma preferida de ejecutar Llama.cpp. Sin ellos, es imposible ejecutar 70B en un escritorio, o 33B en una laptop con 16 GB de RAM.
• El proyecto es elogiado por la facilidad para extenderse con Go, Python y otros runtimes. Con esto se crean herramientas para cargar y ejecutar múltiples modelos en Go y ofrecerlos desde una API REST.
• Ejecutar inferencia en una CPU moderna con AVX2 es más lento que en una GPU, pero ofrece la ventaja de poder tener una sola región larga y contigua de RAM. Sin embargo, no tener opción de cuantizar a 4 bits y ejecutar inferencia con algo distinto de fp32 en CPU x86_64 es una gran desventaja.
• El artículo menciona una réplica exitosa de un dataset de 13B en una sola Pi4 de 8 GB y de un dataset de 65B en tres nodos pi4, mostrando la accesibilidad de esta técnica.
• Se critica al artículo por tratar con poca precisión las unidades al hablar de cifras de latencia.
• El artículo plantea por qué los fabricantes de chips incluyen tantas unidades funcionales en los chips cuando la mayoría de las cargas de trabajo están limitadas por memoria.
• El artículo es elogiado por su contenido único, algo que no suele encontrarse fuera de Hacker News.
• El texto habla de las limitaciones de la generación de tokens restringida por memoria en el decoder transformer y espera modelos futuros más amigables con el hardware.
• El artículo cuestiona por qué el hardware especializado fue diseñado de esa manera considerando el importante cuello de botella del ancho de banda de memoria, y si un cambio en el paradigma de software podría modificar ese equilibrio.