Cuando Menos Es Más: Una Visión Técnica de los LLMs y la Fuerza de los Modelos Más Pequeños

Hola chicos, soy Lugari Karasen. Soy un defensor de desarrolladores en Red Hat AI, y hoy vamos a hablar sobre una visión técnica de los modelos de lenguaje grandes y las fortalezas de los modelos más pequeños. Así que lo que vamos a tocar hoy y los próximos 10 minutos, vamos a ver la recopilación de datos para el pre-entrenamiento de estos modelos, la tokenización de esos datos, cómo se ven los aspectos internos de una red neuronal. Y luego la inferencia de estos modelos una vez que es el momento de llevarlos a producción. A través de eso, luego tocaremos las fortalezas de los modelos más pequeños.

Así que primero, la recopilación de datos para el pre-entrenamiento. Si alguna vez has publicado en internet, probablemente hayas ayudado a contribuir al entrenamiento de estos modelos. Aquí podemos ver el gráfico estadístico de Common Crawl de cómo se ve una jerarquía web. Common Crawl es un raspador web que aloja un montón de páginas de internet y los datos que están en ellas. Cada laboratorio tiene algún conjunto de datos similar a lo que Common Crawl ha capturado para entrenar estos modelos.

Así que una vez que extraes del sitio web, la gente típicamente filtra las URLs que van a llevar predictivamente a malos resultados. Van a extraer el texto de estos sitios web, ignorar cosas que no son texto, filtrar por el tipo de lenguaje que deseas. Tal vez quieras que sea 65% inglés, algún otro porcentaje de un idioma diferente. Al final del día, todo se va a convertir en representaciones matemáticas. A partir de ahí, vas a eliminar duplicados y, con suerte, cualquier información personal identificable, como números de seguridad social, contraseñas, etc. A partir de ahí, vamos a tokenizar esos datos.

Así que esto es convertir el lenguaje humano en matemáticas. Si vemos este extracto de Alice in Wonderland, podemos pensar, hmm, sabemos que una red neuronal necesita una entrada 1D de símbolos. Así que vamos a convertir esto en binarios con una codificación UTF-8.

Y luego, a partir de ahí, agrupar estos binarios en 8 bits o un byte. Y eso nos dejará con 256 combinaciones posibles de binarios. Y luego, si ejecutamos un algoritmo de codificación de pares de bytes, hará que esta lista sea más corta y nos dará más símbolos agrupando partes comúnmente encontradas.

Luego nos quedaremos con la versión tokenizada del lenguaje humano. Esta aplicación en la que conecté este extracto ha resaltado cada palabra en el lenguaje humano con el token que le corresponde. Se corresponde libremente con una palabra por token, pero no uno a uno.

Entonces, ¿qué está sucediendo durante el entrenamiento? Para tener un modelo mental de esto, debo decir que cada algoritmo va a ser diferente y esto es altamente complejo. Pero, en términos generales, el entrenamiento consiste en encontrar los parámetros correctos para que el modelo tenga salidas que sean representativas de los patrones en los datos con los que fue entrenado. Así que vamos a tomar los tokens que creamos y los pesos o parámetros que corresponden con ellos y ajustar esos pesos y parámetros a través de un proceso iterativo. Comienzan al azar y luego, lentamente, al reducir la pérdida, se vuelven más representativos del conjunto de datos.

Un espacio de incrustación de vectores me ayuda a visualizar cómo se ve esto. Nuevamente, esta es una representación vaga. Esto es muy, muy complejo. En realidad, un modelo puede tener miles de millones de parámetros, casi debe tener miles de millones de parámetros. Es raro ver algún modelo con menos de mil millones de parámetros. Y Chat2BT5, por ejemplo, fue entrenado, creo, con tres billones de parámetros. Pero si miramos esto y tenemos cada punto representando un token, podemos ver que en este espacio de dimensiones infinitas, estos tokens o palabras se colocarán cerca de palabras que correspondan con ellos. Y reina podría estar a la misma distancia de mujer que rey está a la misma distancia de hombre.

Así que ahora inferencia. En su mayoría, no vamos a entrenar estos modelos, pero seremos responsables como desarrolladores de llevarlos a producción y asegurarnos de que las entradas de nuestros usuarios se procesen rápidamente y podamos generar nuevos datos a partir de estos modelos un token a la vez. Así que necesitamos un motor de inferencia para poner estos en producción. Es necesario. Las entradas requeridas para VLLM, que es un motor de inferencia de código abierto al que Red Hat ayuda a contribuir son una configuración, un tokenizador y tensores seguros. Todos estos se pueden encontrar en HuggingFace, que es un repositorio para modelos. Algunos motores de inferencia son compatibles con los archivos en HuggingFace. Algunos no lo son. VLLM sí lo es, lo que definitivamente aumenta su facilidad de uso. Así que hay compensaciones cuando estás desplegando estos LLMs. Si estás optimizando para baja latencia y alta precisión, probablemente también obtendrás un alto costo. Esa alta precisión a menudo proviene de un modelo muy grande, lo que a menudo significa un modelo costoso.

Por ejemplo, si aumentamos la precisión, podríamos estar añadiendo parámetros a nuestro modelo, lo que a su vez lleva a un descenso en el rendimiento de la inferencia. Así que este es el primer argumento algo obvio para modelos más pequeños, que es que los modelos más pequeños son más rápidos de inferir y cuestan menos de inferir. Aquí hay un gráfico que muestra cuánto pagaría una empresa para ejecutar cada uno de estos modelos de diferentes tamaños, 8 mil millones, 7 mil millones, 70 mil millones, 450 mil millones de modelos de parámetros, como instancias bajo demanda en la nube, también conocido como hacer ping a un endpoint para ejecutar estos modelos. Ahora puedes ver que los costos aquí son muy diferentes para un modelo cuya precisión podría no ser tan diferente. Así que solo para nivelar rápidamente, ¿qué es un modelo pequeño? Pensaría en un modelo pequeño como algo que es fácil para mí de ejecutar en mi entorno de desarrollo local on-prem, tradicionalmente 8 mil millones de parámetros o menos, mientras que grande va a ser de 70 mil millones a 1 billón. Necesitamos algún hardware potente en ese punto.

Entonces, ¿cómo podemos hacer nuestro modelo más pequeño pero aún así mantener la precisión? Una buena opción a considerar es la cuantización. Así que la cuantización es encoger y reducir la precisión de los números dentro del modelo. Así que estos pesos pueden ser números bastante precisos, pero similar a cómo pi tiene muchos puntos decimales y es muy preciso, sigue siendo pi en 3.145. Así que podemos reducir la precisión de los pesos de la misma manera, lo que hará que este modelo sea más pequeño.

Podemos reducir la precisión de los pesos, como mencioné, o las activaciones, que son los números que se están multiplicando en multiplicaciones de matrices para obtener nuestras salidas cuando estamos generando nuevos datos durante la inferencia. También podemos destilar los datos de estos modelos más grandes y entrenar modelos más pequeños con ellos. Enseñará a un modelo más pequeño a actuar como uno más grande. Y también podemos establecer algunos números a cero, algunos de estos pesos a cero, en un método llamado esparcidad. Así que aquí hay un gráfico para comparar cómo se ve un modelo más pequeño frente a un modelo cuantizado.

Un modelo más pequeño va a tener menos parámetros totales, pero un modelo cuantizado tendrá la misma cantidad de parámetros con menos precisión. Así que esta es una serie de gráficos interesante aquí que nos muestra un tamaño de modelo en un modelo que está en operaciones de punto flotante nativas de 16 aquí que luego se comprime para que sea bastante más pequeño. Pero puedes ver que aún mantiene el 99% de su precisión y es aproximadamente el doble de rápido para ejecutar con el modelo original tomando alrededor de cuatro segundos en inferencia y el modelo comprimido tomando alrededor de dos. Así que si te gustaría intentar comprimir tu propio modelo, puedes probar LLM Compressor que es un subconjunto del proyecto de código abierto VLLM.

Pero para muchos de nosotros el costo y la velocidad aún no son una restricción. Estamos usando endpoints y hardware en la nube. Pero si tienes datos sensibles es difícil ignorar la restricción. Si tienes datos sensibles, es difícil ignorar el control que obtienes sobre toda tu pila y de tus datos cuando estás ejecutando cosas localmente y on-prem, para lo cual estos modelos más pequeños son mejores.

Entonces, ¿por qué ejecutaríamos modelos locales? Bueno, uno, la privacidad de los datos y ese control, pero uno grande es nuestra capacidad de experimentar sin restricciones de infraestructura. Los modelos de lenguaje pequeños pueden servir como un sandbox para construir agentes o pipelines rag sin ese riesgo inicial de infraestructura de incurrir en mucho costo. Así que el argumento número tres para modelos más pequeños es la capacidad de ejecutar estos modelos on-prem para privacidad y control.