Ejecutar modelos de lenguaje dentro de la propia infraestructura permite reducir la dependencia de servicios externos, mantener datos sensibles dentro de la red corporativa y diseñar aplicaciones capaces de seguir funcionando incluso cuando no existe conectividad con proveedores cloud. Sin embargo, un modelo que funciona correctamente en una GPU de centro de datos puede resultar demasiado grande, lento o costoso para un servidor departamental, una estación de trabajo o un dispositivo Edge. La optimización de LLMs busca precisamente reducir esa distancia entre el modelo original y el hardware disponible mediante cuantización, ajuste eficiente y motores de inferencia especializados.
La cuantización reduce la precisión numérica utilizada para almacenar o procesar los pesos del modelo. En lugar de mantener todos los parámetros en FP16 o BF16, pueden emplearse representaciones INT8, INT4, FP8 o formatos especializados como AWQ, GPTQ y GGUF. El resultado habitual es una reducción significativa del consumo de memoria, aunque siempre existe un compromiso entre calidad, compatibilidad y rendimiento. No debe asumirse que un modelo de 4 bits será automáticamente más rápido que otro de 16 bits: el resultado real depende del hardware, los kernels disponibles, la longitud del contexto, el tamaño del lote y el motor de inferencia.
Para adaptar el comportamiento del modelo sin volver a entrenar todos sus parámetros pueden utilizarse técnicas PEFT como LoRA. LoRA mantiene congelado el modelo base e introduce matrices de bajo rango que representan las modificaciones aprendidas. QLoRA aplica la misma idea sobre un modelo base cargado en baja precisión, normalmente 4 bits, reduciendo la memoria necesaria durante el entrenamiento. Esto permite realizar ajustes especializados en hardware considerablemente más pequeño que el requerido por un fine-tuning completo. En PEFT, una configuración estilo QLoRA puede aplicar adaptadores a todas las capas lineales mediante target_modules="all-linear".
Para inferencia, vLLM está orientado principalmente a servidores de alto rendimiento. Incluye batching continuo, gestión eficiente de la memoria KV y soporte para múltiples esquemas de cuantización. También ofrece un servidor compatible con varias API habituales, incluida la API Chat Completions de estilo OpenAI. Ollama se orienta a una experiencia local y Edge más sencilla: permite importar modelos en Safetensors o GGUF, crear modelos a partir de un Modelfile, aplicar adaptadores LoRA compatibles y cuantizar modelos FP16 o FP32 mediante ollama create --quantize.
El procedimiento recomendable consiste en comenzar midiendo el modelo base, establecer un conjunto de pruebas representativo y elegir después el método de optimización. Si el problema principal es memoria, puede bastar con cuantizar. Si el modelo necesita aprender terminología, formato o comportamiento especializado, LoRA o QLoRA pueden ser más adecuados. Una vez preparado el modelo, debe medirse latencia inicial, tokens por segundo, consumo de VRAM o RAM, calidad de respuesta, uso del contexto y comportamiento bajo concurrencia. Solo después de estas pruebas tiene sentido decidir entre vLLM, Ollama u otro motor.
Las precauciones son importantes. Una cuantización agresiva puede degradar razonamiento, generación estructurada o precisión en dominios técnicos. Un adaptador LoRA debe utilizar exactamente la familia y versión de modelo base para la que fue entrenado. Los datos de entrenamiento deben limpiarse y gobernarse igual que cualquier otro activo corporativo. En producción, los endpoints de inferencia no deben exponerse directamente a Internet sin autenticación, reverse proxy, limitación de peticiones y controles de red. La inferencia local mejora la privacidad operativa, pero no elimina la necesidad de seguridad, monitorización y pruebas de calidad.
Guía completa: Leer la guía técnica completa en Jesanre Stack

0 Comentarios