Runpod muestra cómo desplegar Llama 3.1 8B en vLLM sin servidores propios

Runpod ha publicado una guía paso a paso para desplegar Llama 3.1 8B Instruct con el motor vLLM dentro de su plataforma Serverless. El modelo, de 8000 millones de parámetros y con un contexto de hasta 128 mil tokens, se convierte en un endpoint de API que se activa cuando llegan peticiones y no requiere una tarjeta gráfica alquilada las 24 horas. Es una guía, no el lanzamiento de un producto nuevo. Pero el tema es práctico: así es como hoy los equipos pequeños llevan modelos abiertos a producción sin montar su propia infraestructura.

Llama 3.1 salió en julio de 2024 en tres tamaños: 8B, 70B y 405B. La versión de 8000 millones de parámetros es la más accesible. En FP16 sus pesos ocupan unos 16 GB, por lo que cabe en una sola tarjeta con 24 GB de memoria. Aun así, hay que reservar aparte un margen para la KV-cache en contextos largos.

Cómo funciona la combinación

vLLM es hoy uno de los motores de inferencia más extendidos para modelos abiertos. Se basa en PagedAttention: la memoria de la KV-cache se asigna por bloques, como las páginas en un sistema operativo, y la fragmentación disminuye. Junto con el continuous batching, en el que las nuevas peticiones se incorporan a un lote que ya está en marcha, esto aumenta el rendimiento en una sola tarjeta. Para los desarrolladores hay una ventaja añadida: el servidor de vLLM es compatible con el formato de la API de OpenAI, de modo que el código del cliente apenas cambia.

Runpod Serverless añade una capa de gestión. El modelo se empaqueta en un contenedor worker, las peticiones entran en una cola, la plataforma levanta y apaga los workers por sí sola, y la factura se calcula por el tiempo que funcionan, con precisión de segundo. Para vLLM, Runpod ofrece una plantilla lista que se configura con variables de entorno: el nombre del modelo, el token de Hugging Face y la longitud máxima de contexto.

Parámetros clave del esquema:

• Modelo: Meta Llama 3.1 8B Instruct, unos 8000 millones de parámetros.
• Contexto: hasta 128K tokens.
• Pesos en FP16: en torno a 16 GB.
• Motor: vLLM con PagedAttention y continuous batching.
• Interfaz: API compatible con OpenAI.
• Plataforma: Runpod Serverless, con autoescalado de workers, incluso hasta cero.

Los escollos

El principal es el arranque en frío. Si el worker está apagado, con la primera petición tiene que cargar unos 16 GB de pesos en la memoria de la GPU, y el usuario lo notará. El problema se mitiga de tres maneras: incluir el modelo en la imagen del contenedor, usar el almacenamiento en caché de la plataforma o mantener al menos un worker activo. Esta última opción se come parte del ahorro por el que se elige serverless.

La segunda cuestión es el acceso. Llama 3.1 se distribuye bajo la licencia de Meta y el modelo en Hugging Face está restringido: hay que aceptar las condiciones y pasar al worker un token. La tercera tiene que ver con la memoria. Por defecto, vLLM puede reservar espacio para todo el contexto de 128K, así que conviene limitar max model len a las necesidades reales de la aplicación. Así quedará más espacio para peticiones en paralelo.

La rentabilidad de serverless depende del perfil de carga. El material no incluye precios concretos, así que habrá que calcularlos por cuenta propia con las tarifas vigentes de Runpod. La referencia es sencilla: con peticiones poco frecuentes y en picos, el pago por segundo sale mejor que una tarjeta dedicada; con una carga alta y estable, un servidor dedicado suele resultar más barato.

Por dónde empezar

Para una prueba inicial basta una secuencia corta de pasos:

1. Aceptar la licencia de Llama 3.1 en Hugging Face y crear un token de acceso. 2. Crear un endpoint Serverless con la plantilla de vLLM e indicar el modelo y el token. 3. Elegir una GPU con margen, a partir de 24 GB, y limitar la longitud máxima de contexto. 4. Configurar el número mínimo y máximo de workers, así como el tiempo de inactividad antes del apagado. 5. Apuntar el cliente de OpenAI existente al nuevo endpoint y medir la latencia del primer token con un worker en frío y con uno en caliente.

Si el arranque en frío es crítico para su producto, mídalo antes de migrar, no después. Para herramientas internas y tareas en segundo plano suele ser tolerable. Para interfaces de chat con usuarios reales, lo más probable es que haya que mantener un worker en caliente.