Cómo implementar un modelo de 27B en el servidor interno y controlar los costos de tokens
Debido a normativas de seguridad, existen situaciones en las que no se pueden utilizar APIs externas y es necesario desplegar un modelo de 27B en un servidor propio. No hay suficiente presupuesto para comprar una costosa H100, y los costos mensuales por tokens siguen creciendo como una bola de nieve. Este artículo aborda métodos prácticos y específicos para ahorrar más del 40% del presupuesto de hardware en un entorno local (on-premise) y bloquear el desperdicio de tokens por bucles infinitos.
Configuración de múltiples GPU para reducir el presupuesto de hardware
Para ejecutar un modelo de 27B sin OOM (Out of Memory), es necesario calcular con precisión los requisitos de VRAM. En lugar de comprar una sola NVIDIA H100 de 80GB, combine dos RTX 4090 de 24GB para crear una VRAM integrada de 48GB. Al utilizar este método, el costo inicial de construcción de hardware se puede reducir a menos de la mitad.
- Verifique que la VRAM total requerida no supere los 30GB sumando los pesos del modelo (aproximadamente 28GB en base a FP8) y la caché KV (1GB basado en un contexto de 8K).
- En entornos sin NVLink, especifique la opción
--tensor-parallel-size 2 al ejecutar vLLM para distribuir los cálculos dentro del ancho de banda PCIe.
- Para soportar el consumo pico de energía de más de 1000W que emiten dos RTX 4090, utilice una fuente de poder con certificación 80 Plus Titanium y evite el estrangulamiento térmico (thermal throttling) con ventiladores de admisión frontales.
No es necesario obsesionarse con un solo equipo de alto costo. Agrupar tarjetas gráficas económicas en paralelo es una alternativa realista para los equipos de infraestructura bajo presión presupuestaria.
Configuración del motor para evitar el consumo de tokens por bucle infinito
Recientemente, al procesar lógicas complejas, es común que los modelos de 27B no emitan un token de finalización y entren en un bucle infinito hasta alcanzar el número máximo de tokens. En entornos de API comerciales, este solo fenómeno hace que los costos operativos mensuales crezcan de forma insostenible. Incluso ajustando solo los parámetros en el motor de servicio local, este desperdicio se puede controlar con certeza.
- Asigne
repeat_penalty 1.15 y presence_penalty 0.1 en los parámetros de servicio para suprimir el fenómeno en el que se generan oraciones idénticas repetidamente.
- Inserte
<|im_end|>, <|eot_id|> y \nUser: en la matriz stop del archivo de configuración para forzar a que el modelo no continúe preguntándose y respondiéndose a sí mismo.
- Aplique
temperature 0.2 y min_p 0.05 para restringir que el modelo toque tokens con baja probabilidad.
Al aplicar estas configuraciones, el número promedio de tokens de salida se reduce de 4,000 a 800. Incluyendo los costos de energía y la depreciación del equipo, los costos operativos mensuales por unidad se pueden controlar alrededor de los 290 dólares.
Distribución de pesos y gestión de canalizaciones en entornos de "air-gap"
En un entorno de "air-gap" completamente aislado de la red externa, es esencial contar con una canalización que gestione y sirva los pesos de forma estable. Utilizando vLLM, es posible abrir un endpoint de API con una velocidad similar a la de un servicio comercial incluso en la red interna de la empresa.
- Descargue los pesos con
huggingface-cli en un host bastión con acceso a internet y utilice la opción --local-dir-use-symlinks False para descargarlos en una estructura de archivo único.
- Aplique
--enable-prefix-caching y --gpu-memory-utilization 0.92 al ejecutar vLLM para aumentar la reutilización del contexto RAG y prevenir la fragmentación de la VRAM.
- Monitoree constantemente el endpoint de Prometheus (
/metrics) y, si el indicador vllm:gpu_cache_usage_factor supera el 90%, reduzca inmediatamente --max-model-len de 16384 a 8192.
La única forma de controlar los costos sin dejar de cumplir con las políticas de seguridad internas es, al final, construir el sistema uno mismo y monitorear las métricas.