Los modelos de pesos abiertos han mejorado tanto que ejecutar un LLM en tu propio hardware es una opción realista, no un proyecto de investigación. Familias como Llama, Qwen, Mistral, Gemma y DeepSeek ofrecen modelos desde unos pocos miles de millones hasta cientos de miles de millones de parámetros, muchos con licencias que permiten el uso comercial. Para la mayoría de las empresas, la pregunta ya no es "¿podemos?", sino "¿deberíamos y cómo?". Esta guía cubre la decisión, las herramientas, el dimensionado del hardware y el trabajo operativo que los blogs de los proveedores suelen saltarse.

Cuándo tiene sentido alojar el modelo tú mismo

El self-hosting se justifica por uno de estos cuatro motivos:

  1. Los datos no pueden salir de tu infraestructura. Datos regulados, contratos con clientes que prohíben el tratamiento por terceros, trabajos clasificados o relacionados con defensa. Es el motivo más habitual y más sólido; consulta privacidad en aplicaciones LLM.
  2. Volumen alto y constante de una tarea acotada. Clasificación, extracción o embedding de millones de elementos al día, donde un modelo pequeño con fine-tuning en GPUs propias gana al precio por token. Consulta fine-tuning vs RAG vs prompting.
  3. Requisitos de latencia o de funcionamiento sin conexión. Despliegues en el edge, fábricas, productos on-premises sin internet fiable.
  4. Control. Fijar una versión exacta del modelo durante años, personalizar la decodificación o evitar los cambios de política de los proveedores.

El self-hosting normalmente no se justifica para asistentes generales, agentes complejos y tareas de programación, donde los modelos de frontera por API siguen siendo bastante más potentes, ni para volúmenes bajos e irregulares, donde las GPUs ociosas cuestan más que las llamadas a la API. Muchos equipos acaban con un enfoque híbrido: APIs de frontera para las tareas difíciles y modelos self-hosted para las sensibles o de gran volumen.

Elegir un servidor de inferencia

Herramienta Ideal para Notas
vLLM Servir en producción con GPUs PagedAttention, batching continuo, API compatible con OpenAI, paralelismo de tensores, salida estructurada
SGLang Servicio de alto rendimiento, programas de prompting complejos Caché de prefijos RadixAttention (Zheng et al., 2023)
Hugging Face TGI Servir en producción dentro del ecosistema HF Maduro, buena integración con HF Hub
Ollama Máquinas de desarrollo, pequeñas herramientas internas Instalación con un comando, biblioteca de modelos, basado en llama.cpp
llama.cpp CPU, Apple Silicon, dispositivos edge Modelos cuantizados GGUF, dependencias mínimas

La innovación clave de vLLM es PagedAttention, que gestiona la caché clave-valor de la atención en páginas, como la memoria virtual, reduciendo la fragmentación y permitiendo lotes mucho mayores; el artículo informa de un rendimiento de 2 a 4 veces superior al de sistemas anteriores con la misma latencia (Kwon et al., 2023). Combinado con el batching continuo —añadir peticiones nuevas a un lote en curso en lugar de esperar—, es la razón por la que un servidor dedicado atiende a muchos más usuarios por GPU que un script ingenuo.

Mi opción por defecto: Ollama para el desarrollo local y vLLM para producción. Ambos exponen endpoints compatibles con OpenAI, así que el código de la aplicación no cambia.

# Production-style vLLM server with an OpenAI-compatible API
vllm serve Qwen/Qwen2.5-14B-Instruct \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --api-key "$VLLM_API_KEY"

Dimensionar la memoria de GPU

La memoria de GPU es la restricción que manda. Dominan dos componentes:

Pesos del modelo: parámetros × bytes por parámetro.

Tamaño del modelo FP16/BF16 INT8 4 bits
8B ~16 GB ~8 GB ~5 GB
14B ~28 GB ~14 GB ~9 GB
32B ~64 GB ~32 GB ~18 GB
70B ~140 GB ~70 GB ~40 GB

Caché KV: crece con la longitud del contexto × las secuencias concurrentes. Con contextos largos y muchos usuarios, la caché KV puede superar a los pesos. La atención de consultas agrupadas (GQA) de los modelos actuales la reduce; la caché de prefijos la comparte entre peticiones con el mismo prompt de sistema.

Reglas generales: deja un 20–30% de la memoria de GPU para la caché KV y las activaciones, además de los pesos; una sola GPU de 24 GB sirve con holgura un modelo cuantizado de 8–14B a un equipo pequeño; los modelos de 32B caben en una GPU de 80 GB en FP16 o en una de 48 GB cuantizados; los modelos de la clase de 70B necesitan varias GPUs o una cuantización agresiva.

Cuantización

La cuantización guarda los pesos con menos bits, reduciendo la memoria y a menudo aumentando la velocidad:

  • GPTQ y AWQ son métodos posteriores al entrenamiento para inferencia en GPU a 4 bits con pequeñas pérdidas de calidad (Frantar et al., 2022; Lin et al., 2023).
  • FP8 tiene buen soporte en las GPUs recientes de centro de datos y se acerca a no tener pérdidas en muchos modelos.
  • Los niveles de cuantización GGUF (Q4_K_M, Q5_K_M, Q8_0…) son el formato de llama.cpp/Ollama para CPU y Apple Silicon.

La pérdida de calidad depende del modelo y de la tarea: el razonamiento y el texto en idiomas distintos del inglés pueden sufrir más que el chat en inglés. Evalúa siempre el modelo cuantizado con tu propio conjunto de evals, incluido el español si es relevante; consulta evals de LLM.

Despliegue en Kubernetes

En producción, ejecuta los servidores de inferencia como cargas de Kubernetes en nodos con GPU:

  • Grupo de nodos con GPU con el device plugin o el GPU operator de NVIDIA; taints para que solo los pods de inferencia acaben ahí.
  • Almacenamiento de modelos: descarga los pesos de antemano en un volumen persistente o en una caché local del nodo; descargar más de 30 GB al arrancar el pod hace el escalado dolorosamente lento.
  • Readiness probes sobre el endpoint del modelo: cargar un modelo grande lleva minutos.
  • Autoescalado según la longitud de la cola o el uso de GPU en lugar de la CPU; escala a cero solo si los arranques en frío son aceptables.
  • Un gateway delante (un router compatible con OpenAI o un proxy tipo LiteLLM) para autenticación, límites de frecuencia, routing entre modelos y fallback a APIs externas; consulta fiabilidad de las APIs de LLM.

Los servidores con GPU de proveedores europeos pueden ser mucho más baratos que los de los hiperescaladores para cargas constantes.

Seguridad y cumplimiento

El self-hosting traslada la responsabilidad a ti:

  • Autentica cada endpoint. Los puertos de inferencia abiertos se encuentran y se abusan con regularidad.
  • Aislamiento de red. Los servidores de inferencia no deberían necesitar salida a internet en producción.
  • Cadena de suministro. Descarga los pesos de fuentes oficiales, verifica las sumas de comprobación, prefiere safetensors a los formatos basados en pickle y escanea los contenedores.
  • Licencias. Las licencias de pesos abiertos difieren: algunas restringen el uso comercial por encima de un umbral de usuarios o para determinados fines. Registra la licencia de cada modelo que despliegues.
  • Registros. Los prompts pueden contener datos personales; aplica los mismos controles de retención y acceso que a cualquier otro sistema que los contenga; consulta observabilidad de LLM.
  • Ley de IA de la UE. Desplegar un modelo abierto dentro de tu producto puede conllevar obligaciones según el uso; consulta la guía de la Ley de IA de la UE.

Coste total: una comparación honesta

Compara el coste total de propiedad, no el precio por hora de la GPU con el precio por token:

Partida de coste API Self-hosted
Inferencia Por token Servidores con GPU 24/7 (o reservados), con independencia del uso
Ingeniería Solo la integración Instalación, actualizaciones, monitorización, guardias
Calidad Modelos de frontera Modelos abiertos; puede requerir más trabajo de prompts o fine-tuning
Escalado Instantáneo Planificación de capacidad, compras
Cumplimiento DPA del proveedor, evaluación de transferencias Tus propios controles, a menudo más sencillo legalmente

Un análisis aproximado del punto de equilibrio: estima los tokens al mes, multiplícalos por los precios de API de un modelo de calidad comparable y compáralos con el coste de las GPUs más 0,25–0,5 personas a tiempo completo de ingeniería. Para muchas cargas de pymes, las APIs ganan en coste; el self-hosting gana en control de los datos y con volúmenes muy altos. Repite las cuentas cada seis meses: tanto los precios de las APIs como la calidad de los modelos abiertos cambian deprisa.

Un camino de despliegue

  1. Prototipa con una API para validar el caso de uso y construir los evals.
  2. Haz una lista corta de modelos abiertos que encajen con tu hardware y tus restricciones de licencia; consulta cómo elegir un LLM.
  3. Ejecútalos en local con Ollama contra el conjunto de evals.
  4. Despliega vLLM en un nodo con GPU para un grupo piloto; mide latencia, rendimiento y calidad.
  5. Endurece: gateway, autenticación, monitorización, autoescalado, copias de seguridad de la configuración.
  6. Optimiza: cuantización, caché de prefijos, decodificación especulativa —un modelo borrador pequeño propone tokens que el modelo grande verifica en paralelo, reduciendo la latencia sin cambiar las salidas (Leviathan et al., 2022)— y fine-tuning de un modelo más pequeño si el volumen lo justifica.

Preguntas frecuentes

¿Podemos ejecutar un modelo útil sin GPU? Los modelos pequeños cuantizados (hasta unos 8B) funcionan en CPUs modernas y Apple Silicon con llama.cpp u Ollama: bien para herramientas internas de poco volumen, demasiado lentos para muchos usuarios concurrentes.

¿Los modelos abiertos son lo bastante buenos en español? Los modelos abiertos multilingües grandes manejan bien el español; los pequeños son notablemente más débiles. Prueba con tus propias tareas.

¿El self-hosting cumple automáticamente el RGPD? No. Elimina las transferencias a terceros, pero sigues necesitando una base jurídica, límites de retención, control de acceso y seguridad para los datos que tratas.

¿Cómo nos mantenemos al día con los modelos nuevos? Mantén la aplicación detrás de una interfaz compatible con OpenAI, mantén actualizado tu conjunto de evals y evalúa los lanzamientos nuevos cada trimestre.

Fuentes

  1. Kwon et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention; documentación de vLLM.
  2. Zheng et al. (2023). SGLang: Efficient Execution of Structured Language Model Programs.
  3. Ollama y llama.cpp en GitHub.
  4. Frantar et al. (2022). GPTQ; Lin et al. (2023). AWQ.
  5. Leviathan et al. (2022). Fast Inference from Transformers via Speculative Decoding.
  6. Hugging Face. safetensors.