Introducción A medida que las tecnologías LLM ganan una adopción más generalizada y el ecosistema comienza a madurar, las organizaciones comienzan a reconocer los límites y costos del uso de tecnologías LLM. Muchas empresas, originalmente entusiasmadas con la aplicación de , han abandonado las iniciativas centralizadas y, en cambio, han seguido una estrategia de fomentar esfuerzos descentralizados para incorporar servicios como ChatGPT y Claude en sus flujos de trabajo. tecnologías LLM Hay varias razones para este fenómeno. La falta de experiencia en LLM, los requisitos de MLOps y la dependencia de una infraestructura de GPU especializada son barreras para implementar iniciativas de IA a gran escala. De estos, sin embargo, el tema más espinoso es la dependencia de las GPU. En este artículo, discutiremos las dificultades específicas que plantea la dependencia de GPU, exploraremos una solución potencial y veremos un ejemplo interesante de una de las empresas pioneras que trabajan en esta área. Disponibilidad de GPU como limitaciones para los LLM La mayoría de los modelos disponibles públicamente y de alto rendimiento, como GPT-4, Llama 2 y Claude, dependen de una infraestructura de GPU altamente especializada. GPT-4, uno de los modelos más grandes disponibles comercialmente, se ejecuta en un grupo de 8 GPU A100. El modelo 70B de Llama 2, que es mucho más pequeño, aún requiere al menos una GPU A40 para funcionar a una velocidad razonable. Este nivel de requisito de GPU prácticamente excluye la posibilidad de ejecutar estos modelos localmente: una GPU A100, suponiendo que pueda encontrar un vendedor, cuesta cerca de $25,000. Una vez que obtenga las GPU, necesitará habilidades especializadas para configurar y mantener los servidores. Muy pocas organizaciones estarían dispuestas a realizar tal desembolso para experimentar con tecnologías LLM. Para resolver este problema, varias empresas emergentes y proveedores de la nube han desarrollado amplias ofertas de PaaS. Algunos servicios como Replicate, que he utilizado en artículos y proyectos anteriores, permiten a los usuarios alquilar servidores GPU y pagar por el tiempo de cálculo utilizado. Otros proveedores, como OpenAI y Anthropic, ofrecen sus modelos como una API por token, abstrayendo aún más las complejidades de infraestructura. Sin embargo, estos servicios requieren que los datos se envíen a una red externa, lo que hace que el uso de estos servicios sea imposible para las organizaciones preocupadas por la privacidad. Además, muchos de estos servicios sufren escasez durante los picos de demanda a medida que el uso de GPU supera la disponibilidad, lo que los convierte en opciones poco confiables para cargas de trabajo críticas para la producción. Además, el tiempo de GPU, sin importar cómo se cobre por él, es costoso para tareas informáticas grandes; después de todo, las empresas que poseen y operan estas GPU necesitan un retorno de su inversión. Si bien estos costos son casi insignificantes para los casos de uso experimentales, los casos de uso comercial a menudo requieren incorporar contextos grandes, ajustes o ejemplos de múltiples tomas. Estos costos representan una barrera importante para la adopción, especialmente para organizaciones con grandes conjuntos de datos o aquellas que carecen de los recursos financieros de las grandes empresas estadounidenses. En un artículo anterior, exploramos la compresión de parámetros como una estrategia para reducir la dependencia de las GPU. En el artículo de hoy, exploraremos otra técnica interesante llamada cuantización. Sin embargo, antes de sumergirnos en la exploración, es posible que deseemos aprender un poco sobre la cuantificación. Cuantización (lectura opcional) En esta sección, repasaremos brevemente los conceptos básicos de la cuantización. Sin embargo, si simplemente está buscando una manera de ejecutar potentes LLM localmente en su computadora, puede omitir esta sección por ahora y volver más tarde. LLMWare, la empresa cuya tecnología usaremos hoy, ha creado algunas herramientas sorprendentes que le permiten comenzar con modelos cuantificados sin tener que profundizar en las detrás de todo. implementaciones esenciales de C/C++ ¿Qué es la cuantización? La cuantificación es una técnica que busca reducir los requisitos computacionales y de memoria para ejecutar un LLM mediante el uso de tipos numéricos de menor precisión. Muchos modelos populares de código abierto, como Llama, Falcon y Alpaca, utilizan PyTorch como marco subyacente. De forma predeterminada, los modelos PyTorch utilizan puntos flotantes de 32 bits, lo que significa que un solo parámetro ocupa 32 "bits" en la memoria de la GPU. La cuantificación tiene como objetivo reemplazar estos parámetros con puntos flotantes de 16 bits, enteros de 8 bits o incluso enteros de 4 bits. Una cuantificación exitosa conduce a mejoras dramáticas en la velocidad computacional y reducciones en el uso de memoria, lo que significa que los modelos grandes se pueden ejecutar en GPU de gama baja, chips gráficos integrados o incluso CPU. Esta idea ha existido por un tiempo: el propio PyTorch ha agregado soporte para puntos flotantes de 16 bits y compilaciones de modelos a medida que la tecnología maduró, pero el progreso ha sido lento debido a las primeras decisiones de diseño en el marco de PyTorch. ¿La cuantización degrada el rendimiento? En este punto, es natural preguntarse: ¿no degradaría esto gravemente la precisión del modelo? La respuesta corta es sí, pero sólo si lo haces descuidadamente. Cada optimización conlleva compensaciones inherentes, pero con algunas técnicas especializadas, los investigadores han podido obtener un rendimiento increíblemente estable de modelos altamente cuantificados. Si bien no entraremos en detalles técnicos extremos, repasemos a grandes rasgos las estrategias más comunes que se utilizan en este momento. Si desea obtener más información, puede obtener más información al respecto en una de HuggingFace. guía Cuantización calibrada Durante el proceso de cuantificación, se ejecuta un conjunto de datos de calibración a través del modelo. Se registra el valor de cada parámetro y el rango se utiliza para determinar cómo se cuantifican los parámetros. Suponiendo que el conjunto de datos de calibración es representativo de las entradas que encontrará el modelo, esto da como resultado una precisión mejorada del modelo resultante. Consciente de la cuantificación Mientras que la cuantificación calibrada ocurre después del entrenamiento, el entrenamiento consciente de la cuantificación intenta optimizar el modelo durante el entrenamiento. Mientras el modelo se entrena, las activaciones se someten a una "cuantización falsa", que simula errores que probablemente se introducirán en el proceso de cuantificación. Luego, el modelo puede adaptarse a los errores, lo que da como resultado un modelo más robusto que puede adaptarse específicamente a las posibles distorsiones. Llama.cpp y GGUF Si bien la cuantificación y las optimizaciones de PyTorch han estado bloqueadas durante mucho tiempo por el diseño del marco, dos tecnologías recientes de código abierto rompieron estas barreras e hicieron que las tecnologías de cuantificación fueran mucho más accesibles para el público en general. Vamos a cubrirlos brevemente a continuación. llama.cpp Llama.cpp fue un proyecto de Georgi Gerganov para portar el modelo Llama a C/C++. Esto eliminó la complejidad introducida por PyTorch y la implementación nativa permitió que la cuantificación se implementara directamente. Por lo tanto, el modelo resultante podría ejecutarse con una cuantificación de enteros de hasta 4 bits, lo que permitiría ejecutar modelos Llama con un alto número de parámetros sin una GPU especializada. Desde entonces, la comunidad ha ampliado el proyecto para incluir una lista de modelos de código abierto, incluidos los populares como Falcon y Mistral. GGUF GGUF es el formato de archivo de Llama.cpp para almacenar y transferir información del modelo. Los modelos cuantificados se almacenan en este formato para que el usuario final pueda cargarlos y ejecutarlos. GGUF es el formato sucesor de GGML y tiene como objetivo mejorar GGML proporcionando más extensibilidad, compatibilidad con versiones anteriores y estabilidad al mismo tiempo que permite un desarrollo rápido. El desarrollo de un formato de archivo universal abrió la puerta para que la comunidad de código abierto extendiera Llama.cpp para optimizar otros modelos, e innovadores como TheBloke y LLMWare han estado trabajando durante los últimos meses para miniaturizar modelos populares de código abierto. Modelo de dragón cuantificado de LLMWare En el ejemplo de hoy, utilizaremos bibliotecas de código abierto y modelos cuantificados proporcionados por LLMWare, que proporciona herramientas convenientes para crear rápidamente flujos de trabajo RAG especializados. ¿Quién es LLMWare? LLMWare, una empresa de inteligencia artificial generativa especializada en las industrias legal y financiera, ha participado activamente en la comunidad de cuantificación. Como he escrito antes, su enfoque en sectores preocupados por la privacidad los convierte en candidatos naturales para experimentar e innovar en tecnologías de miniaturización. Anteriormente, escribí sobre sus modelos BLING optimizados para RAG que obtienen un rendimiento increíble de entre 1 y 3 mil millones de modelos de parámetros para tareas especializadas como revisión de contratos y análisis financiero. Si bien la mayoría de los modelos de código abierto con tales recuentos de parámetros tienden a ser útiles solo para problemas de juguetes, LLMWare puede generar un rendimiento listo para producción a partir de estos modelos capacitándolos para tareas específicas. Estos modelos miniaturizados pueden funcionar sin una GPU externa, lo que permite una mayor privacidad y escalabilidad. ¿Qué es Dragón? Dragon es una colección de LLM que pueden considerarse versiones más poderosas de sus primos BLING. La intención original de Dragon era entrenar un modelo de parámetros más altos utilizando las mismas técnicas de ajuste de instrucciones, brindando una opción a los usuarios que necesitan más rendimiento y tienen acceso a GPU de gama baja. El recuento de parámetros agregado dio como resultado modelos más potentes que podían aprovechar ventanas de contexto más grandes y generar resultados más complejos, pero requerían que el usuario tuviera hardware más especializado, como una computadora portátil con GPU integrada o un contenedor de computación en la nube con una GPU adjunta. Sin embargo, todavía representaban una mejora con respecto a los modelos extremadamente grandes, que requerirían esperar para acceder a las escasas GPU A40 o A100. Dragón cuantificado, lo mejor de ambos mundos Teniendo en cuenta lo anterior, es fácil ver por qué la cuantificación dio un impulso significativo al conjunto de herramientas de inteligencia artificial de LLMWare. Con la cuantificación, un usuario podría ejecutar modelos Dragon-tier en el mismo entorno que los modelos BLING, lo que permitiría un análisis mucho más potente en computadoras básicas. A lo largo del último mes, LLMWare ha publicado versiones cuantificadas de varios modelos de Dragon. Hoy, evaluaremos el modelo Dragon de LLMWare construido sobre Llama con un problema RAG de análisis legal y lo compararemos con un modelo BLING similar. Los interesados también pueden explorar otros modelos: un modelo basado en Mistral y un modelo basado en Yi están disponibles en LLMWare al momento de escribir este artículo. Además, ha facilitado la ejecución de inferencias en modelos Llama.cpp con sus estrechas integraciones con la biblioteca ctransformers, que permite intercambiar modelos guff sin problemas con modelos basados en PyTorch. LLMWare Usaremos una Macbook Air con chip M1 para este experimento, lo que significa que solo usaremos hardware ampliamente disponible para este ejercicio. Probando el Dragón Cuantizado Recuerde que en mi artículo anterior creamos una aplicación RAG enfocada en la búsqueda de legislación. Utilizamos la búsqueda vectorial para buscar rápidamente en varias legislaciones importantes, encontramos secciones relevantes para nuestra pregunta sobre el interés de asociación en zonas de oportunidad calificadas y ejecutamos la pregunta a través de un modelo BLING. En el artículo de hoy, analizaremos la misma pregunta a través del modelo Dragon cuantificado de LLMWare y determinaremos si funciona mejor que los modelos BLING. Para centrarnos en la comparación de modelos y reducir la cantidad de conocimientos previos necesarios, realizaremos gran parte del análisis de PDF y la búsqueda de vectores manualmente. Esto tiene el beneficio adicional de hacer que el problema sea artificialmente más difícil para el modelo: la búsqueda de incrustación predeterminada de LLMWare divide el material fuente en aproximadamente 1000 tokens, pero manejar el análisis manualmente nos permite aumentar el contexto hasta alrededor de 3000 tokens. Esto nos ayudará a demostrar claramente la diferencia entre los modelos Dragon y BLING. Sin embargo, debería poder integrarse fácilmente con el resto del ecosistema de LLMWare si desea aprovechar sus herramientas siguiendo los pasos de configuración de mi último artículo sobre LLMWare. De hecho, si simplemente reemplazas el nombre de los modelos BLING con el modelo Dragon cuantificado de este artículo, todo debería funcionar sin problemas. Sin más preámbulos, ¡comencemos! Primero, importemos las dependencias requeridas: import sklearn import sklearn.metrics # for cosine similarity from llmware.prompts import Prompt import time import os from openai import OpenAI from PyPDF2 import PdfReader client = OpenAI() # the library now loads the key automatically as an environment variable. Ya podemos cargar el PDF. En el ejemplo anterior, cargamos varias legislaciones importantes, pero por hoy solo nos centraremos en la versión PDF de la Ley de Empleos y Reducción de Impuestos de 2017. reader = PdfReader([path to PDF of tax cuts and jobs act]) Ahora podemos generar las incrustaciones para cada página: embeddings = [] for pg in reader.pages: text = pg.extract_text() embeddings.append(client.embeddings.create( input=text, model="text-embedding-ada-002" ).data[0].embedding) Generemos también las incrustaciones para la pregunta que vamos a hacer: question = 'What is a qualified opportunity zone partnership interest?' q_embed = client.embeddings.create( input=question, model="text-embedding-ada-002" ).data[0].embedding Con la incrustación en mano, podemos realizar una búsqueda vectorial. Debido a que nuestro espacio de búsqueda es pequeño, podemos hacerlo manualmente. cos_sim = [(idx, sklearn.metrics.pairwise.cosine_similarity([e], [q_embed])[0][0]) for idx, e in enumerate(embeddings)] Ahora podemos tomar la página más relevante (que es el índice 132 o la página 133 si quieres verificar los resultados): most_relevant = sorted(cos_sim, key=lambda x: x[1], reverse=True)[0][0] Y con eso, hemos llegado al paso más crucial. Crearemos una instancia de un objeto LLMWare Prompter con el modelo cuantificado de Llama Dragon. La clase Prompter es clave aquí porque maneja la ingeniería de avisos por nosotros y se asegura de que nuestro aviso sea consistente con la estructura de los datos de entrenamiento de Dragon. La clase de solicitud también maneja automáticamente el enlace llamacpp, por lo que puede usar el modelo Dragon cuantificado exactamente como otros modelos. model_name = "llmware/dragon-llama-7b-gguf" prompter = Prompt().load_model(model_name) response = prompter.prompt_main(question, context='\n\n'.join([reader.pages[132].extract_text()]), prompt_name="default_with_context", temperature=0.3) Espere un poco y debería ver regresar la llamada a la función. Ahora imprima los resultados: print(response['llm_response']) Y deberías ver algo como lo siguiente: • A capital or profits interest acquired by the qualified opportunity fund after December 31, 2017, from the partnership solely in exchange for cash; •As of the time such interest was acquired, the partnership was a qualified opportunity zone business (or, in the case of a new partnership, it was being organized for purposes of being a qualified opportunity zone business); •During substantially all of the qualified opportunity fund's holding period for such interest, the partnership qualified as a qualified opportunity zone business. ¡Esta es una muy buena respuesta! A modo de comparación, veamos cómo se comportaría un modelo BLING en el mismo problema. Uno de los problemas que podemos esperar es que el gran tamaño del contexto pueda "abrumar" a un modelo de parámetros más bajos y conducir a una respuesta menos informativa. En mis experimentos anteriores, la llama esquilada 2.7b fue una de las que mejor desempeño tuvo para este problema, así que decidí usarla como representante de los modelos BLING. model_name_2 = "llmware/bling-sheared-llama-2.7b-0.1" prompter2 = Prompt().load_model(model_name_2) response = prompter2.prompt_main(question, context='\n\n'.join([reader.pages[132].extract_text()]), prompt_name="default_with_context", temperature=0.3) Después de un poco de procesamiento, deberías ver algo como esto. A qualified opportunity zone partnership interest is a capital or profits interest in a domestic partnership if such interest is acquired by the qualified opportunity fund after December 31, 2017, from the partnership solely in exchange for cash. La respuesta sigue siendo buena, pero omite algunos de los detalles capturados por el modelo Dragon. Específicamente, la respuesta omite el requisito del período de tenencia y el nuevo caso de negocio. Esto se ajusta a nuestras expectativas sobre la dificultad de los modelos de parámetros más bajos para procesar contextos más amplios. Los lectores interesados pueden ampliar este experimento utilizando modelos de parámetros aún más bajos o aumentando el tamaño del contexto dado. Debería ver que el efecto se vuelve cada vez más pronunciado, después de lo cual el modelo dará una respuesta breve y confusa. A partir de este experimento, debería quedar claro que los modelos Dragon cuantificados pueden superar a los modelos de parámetros más bajos para los casos de uso previstos sin comprometer notablemente la precisión del modelo. Y con eso, utilizamos un modelo cuantificado para resolver un caso de uso del mundo real y aprendimos sobre sus características de rendimiento en el proceso. Conclusión Hoy exploramos el apasionante campo de la cuantificación de LLM y observamos cómo empresas como LLMWare están aprovechando estos desarrollos para mejorar sus modelos de lenguajes especializados. Como he argumentado antes, la miniaturización representa uno de los caminos más prometedores hacia la adopción generalizada de tecnologías de IA. Al combinar especialización, ajuste y cuantificación, los innovadores en el espacio de la IA pueden crear modelos escalables y de alto rendimiento que resuelvan problemas del mundo real. Puede encontrar el marco RAG de LLMWare en y sus modelos DRAGON y BLING en de LLMWare. Github el repositorio Hugging Face Por cierto, estoy trabajando en un proyecto apasionante que busca utilizar la inteligencia artificial del lenguaje y la miniaturización para revolucionar la educación en el mundo en desarrollo. Estamos trabajando con activistas y educadores increíbles en todo el mundo y estamos trabajando para cerrar la brecha digital global. Si desea obtener más información sobre mi proyecto o simplemente quiere hablar sobre desarrollos interesantes en el espacio LLM, no dude en comunicarse conmigo en o . Github LinkedIn

This story contains new, firsthand information uncovered by the writer.

Este audio es producido en el idioma original de la historia!

¡Ejecute Llama sin GPU! LLM cuantificado con LLMWare y Quantized Dragon

Demasiado Largo; Para Leer

Shanglun Wang

STORY’S CREDIBILITY

Original Reporting

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...