Implementación de LLMS a escala

La implementación de modelos de lenguaje grande (LLM) de código abierto a escala y, al mismo tiempo, garantizar la confiabilidad, la baja latencia y la rentabilidad puede ser una tarea difícil. Basándome en nuestra amplia experiencia en la construcción de infraestructuras de LLM y en su implementación exitosa para nuestros clientes, he compilado una lista de los principales desafíos a los que suelen enfrentarse las personas en este proceso.

Cuestiones clave en la implementación de LLM

Encuentre la forma más óptima de alojar una instancia del modelo

Hay varias opciones para que los servidores modelo alojen LLM y varios parámetros de configuración que se pueden ajustar para obtener el mejor rendimiento para su caso de uso. TGI, VOLM, Abrir LLM son algunos de los marcos más comunes para alojar estos LLM. Puedes encontrar un análisis detallado en este blog. Para elegir el marco adecuado para su alojamiento, es importante comparar el rendimiento de estos marcos para su caso de uso y elegir el que mejor se adapte a su caso de uso. Además, estos marcos tienen sus únicos parámetros ajustables que pueden ayudarte a obtener los mejores resultados de evaluación comparativa.

Encontrando la flota de GPU

Las GPU son caras y difíciles de encontrar. Hay varios proveedores de GPU en la nube que van desde nubes prominentes como AWS, GCP y Azure hasta proveedores de nube a pequeña escala como Runpod, Fluidstack, Paperspace y Coreweave. Hay una gran variación en los precios y las ofertas de cada uno de estos proveedores. La confiabilidad también sigue siendo un problema para algunos de los nuevos proveedores de GPU en la nube.

Mantener la confiabilidad

En la práctica, esto es más difícil de lo que parece. Según nuestra experiencia en la ejecución de LLM en entornos de producción, deberías estar preparado para detectar errores puntuales y extraños en los servidores modelo que pueden provocar que tu proceso se interrumpa y que se agoten todas las solicitudes. Es muy importante disponer de gestores de procesos y de sondeos de disponibilidad y funcionamiento adecuados para que los servidores modelo puedan recuperarse de los errores o para que el tráfico pase sin problemas de una instancia en mal estado a otra en buen estado.

Garantizar un alto rendimiento con baja latencia

Al realizar una evaluación comparativa, es muy importante determinar el equilibrio entre la latencia y el rendimiento. A medida que aumentemos el número de solicitudes simultáneas al modelo, la latencia aumentará ligeramente hasta cierto punto, tras lo cual la latencia se deteriorará drásticamente. Encontrar el equilibrio correcto entre la latencia, el rendimiento y el coste puede llevar mucho tiempo y ser propenso a errores. Tenemos algunos blogs en los que se describen estos puntos de referencia para Llama 7B y Llama 13B.

Benchmarking Llama-2-70B

This blog captures Llama-2-70B benchmarks - where a model excels and the areas where it struggles. Make informed decisions about its practical deployment.

TrueFoundry Blog Truefoundry

‍

Benchmarking Falcon-40B

This blog captures Falcon-40B-Instruct benchmarks - where a model excels and the areas where it struggles. Make informed decisions about its practical deployment.

TrueFoundry Blog Truefoundry

‍

Garantice un tiempo de inicio rápido del modelo

Los modelos LLM tienen un tamaño enorme, desde 10 GB hasta 100 GB. Puede llevar mucho tiempo descargar el modelo una vez que el servidor modelo esté listo y, a continuación, cargarlo del disco a la memoria. Es esencial que guardes el modelo en caché en el disco para que no acabemos descargando el modelo nuevamente en caso de que el proceso se reinicie. Además, para ahorrar costes de red, es mejor descargar el modelo una vez y compartir el disco entre varias réplicas en lugar de que cada réplica descargue el modelo repetidamente a través de Internet.

Configurar el ajuste de escala automático

El escalado automático es complicado en el caso del alojamiento de LLM debido al alto tiempo de inicio de otra réplica. Si la carga es muy alta, normalmente necesitamos aprovisionar la infraestructura de acuerdo con los picos de réplicas; sin embargo, si se espera que el pico llegue a ciertas horas del día, el escalado automático basado en el tiempo funciona bien.

¿Cómo llevar los LLM a la producción?

1. Comience comparando el LLM con diferentes modelos de servidores, GPU y parámetros para ver dónde obtiene el mejor rendimiento. Lo ideal sería disponer de datos obtenidos a partir de evaluaciones comparativas similares a los que tenemos en este blog para Llama7B.
2. Puedes configurar modelos en varias GPU en Kubernetes o en instancias sin sistema operativo. Lo ideal sería recomendar Kubernetes, ya que te ofrece todas las comprobaciones de estado, enrutamiento y conmutación por error de forma gratuita.
3. Coloque el modelo en un volumen compartido como EFS para que los modelos no se descarguen repetidamente y monte el volumen en todos los pods.
4. Configure la supervisión y las alertas en las instancias.
5. Lo ideal es tener una capa que pueda hacer el recuento de los tokens por ti en cada solicitud, ya que es más fácil entender el patrón del tráfico entrante.
6. Observe el patrón de tráfico y ajuste la política de escalado automático en consecuencia.
7. Conserve una combinación de instancias puntuales y bajo demanda para reducir los costos.

Arquitectura para hospedar LLMs a escala

Empezamos con el enfoque anterior, pero pronto migramos a la arquitectura que se muestra a continuación, lo que nos permite hospedar LLM con costos muy bajos y alta confiabilidad.

Básicamente, creamos varios grupos de GPU en diferentes proveedores de nube en diferentes regiones y, por lo general, utilizamos instancias puntuales si se trata de AWS, GCP o Azure, o nodos bajo demanda de los proveedores de nube más pequeños. También colocamos una cola en el medio que recibe todas las solicitudes y los distintos grupos de GPU que consumen de la cola y devuelve la respuesta a la cola desde la que se devuelve la respuesta HTTP al usuario. Algunas ventajas de esta arquitectura:

1. Alta confiabilidad con instancias puntuales: Como distribuimos la carga entre instancias puntuales de varios proveedores de nube y regiones, las probabilidades de que todas las instancias puntuales se caigan son extremadamente lentas y cada uno de los grupos puede crecer para absorber la carga cuando un grupo deja de funcionar.
2. Queue agrega confiabilidad adicional bajo cargas elevadas: Un servicio HTTP comenzará a devolver 503 si hay picos repentinos. Debido a la cantidad de espera que hay en el medio, podemos tolerar picos de carga de trabajo: hay un ligero aumento en la latencia de las solicitudes durante los picos, pero no fallan. Si se añade la cola en el medio, se obtiene una latencia global de unos 10 a 20 ms, lo que está bien para las inferencias de LLM, ya que la latencia total de las inferencias es del orden de segundos.
3. Reducción de costos: Esto ayuda a reducir drásticamente el costo en comparación con el alojamiento de LLM en instancias bajo demanda; a continuación, haremos una comparación detallada de los costos.
4. Análisis detallados: La capa de pasarela LLM nos ayuda a calcular los análisis detallados sobre las solicitudes entrantes y también puede calcular la distribución de los tokens entre las solicitudes. También podemos empezar a registrar las solicitudes para poder realizar ajustes más adelante.
5. Sin dependencia de un solo proveedor de nube: Esta arquitectura nos permite cambiar fácilmente nuestro proveedor de GPU por otro si encontramos un precio mejor en algún lugar sin tiempo de inactividad. Además, en caso de que un proveedor deje de funcionar, ¡los otros grupos mantienen el sistema en funcionamiento sin problemas!

Reducción de costos para hospedar LLMs

Tomemos un escenario en el que se aloja un LLM con 10 solicitudes por segundo en el pico y 7 solicitudes por segundo en promedio. Supongamos que, mediante una evaluación comparativa, calculamos que una máquina GPU A100 de 80 GB puede generar 0,5 RPS. Consideremos también que el tráfico es mayor durante 12 horas al día (alrededor de 9-10 RPS) y bajo durante las 12 horas restantes del día (7-8 RPS).

Basándonos en los datos anteriores, podemos encontrar la cantidad de máquinas GPU necesarias en el período pico de 12 horas y en el período de 12 horas no pico:

Periodo máximo de 12 horas: 20 GPU
Periodo no pico de 12 horas: 15 GPU

Compararemos el costo de ejecutar el LLM con Sagemaker, hospedar ingenuamente en máquinas bajo demanda en AWS, GCP y Azure y usar nuestra propia arquitectura con escalado automático.

Costo de hospedaje en Sagemaker (región us-east-1):

Costo de 8 máquinas A100 de 80 GB (ml.p4de.24xlarge) -> 47,11$ por hora

Necesitaremos 2 máquinas durante las horas no pico y 3 máquinas durante las horas pico.

Coste mensual total: 85 000$

Coste del alojamiento directo en los nodos de AWS:

Coste de 8 máquinas A100 de 80 GB (p4de.24xlarge) -> 40,966$ por hora

Necesitaremos 2 máquinas durante las horas no pico y 3 máquinas durante las horas punta:

Coste mensual total: 73 000$

Costo de alojamiento en Truefoundry

Con las instancias puntuales y otros proveedores de GPU, podemos reducir el precio promedio de las GPU a 2,5 USD por hora. Suponiendo 15 GPU durante las horas de menor actividad y 20 GPU durante las horas de mayor demanda, el coste total será de:

2,5$ * (15*12 + 20*12) * 30 (días al mes) = 31 MIL DÓLARES

Como podemos ver, podemos organizar el mismo LLM a casi un 30% del precio del Sagemaker con una alta confiabilidad. Sin embargo, será necesario realizar esfuerzos para construir y mantener esta arquitectura. True Foundry puede ayudarlo a alojarlo por usted o a alojarlo en su propia cuenta en la nube sin problemas y, al mismo tiempo, ahorrar costos.