Un modelo de 8.000 millones de parámetros cabe en 4,9 GB de disco. Es el caso de llama3.1:8b en formato GGUF cuantizado a 4 bits, el tamaño exacto que descarga Ollama con un solo comando. En precisión FP16, ese mismo modelo ocupa unos 16 GB y descarta media mesa de GPUs domésticas; cuantizado, arranca en un portátil corriente. Toda la discusión sobre VPS, hardware y costes del self-hosting de IA parte de esa diferencia. Y si aún te lo estás planteando, la comparativa de IA local vs SaaS explica por qué el coste plano y el control de datos pesan más que la potencia bruta.
La cuantización lo cambió todo (y Ollama lo puso fácil)
Gracias a GGUF, que comprime los pesos a 4 bits casi sin pérdida apreciable, Ollama consigue ese salto con un solo comando.
De 16 GB a 4,9 GB con un comando
El formato GGUF, heredado del proyecto llama.cpp, comprime los pesos a 4 bits con una pérdida de calidad que, para la mayoría de tareas cotidianas, es difícil de apreciar. Ollama se apoya en ese motor y añade lo que faltaba: un gestor de modelos con comandos de una línea (ollama pull, ollama run) y una API HTTP en el puerto 11434. En su librería conviven familias como Llama, Mistral, Gemma, Phi o Qwen, todas descargables sin registro.
La escalera de tamaños
La escalera de tamaños es tu herramienta de planificación: llama3.2:3b ocupa unos 2 GB, llama3.1:8b ronda los 4,9 GB y llama3.1:70b supera los 40 GB. Antes de gastar un euro en infraestructura, ejecuta ollama run llama3.1:8b en tu propia máquina, cronometra los tokens por segundo y decide si el resultado te sirve. Esa medición de cinco minutos basta para fijar el grueso del presupuesto que viene después.
La regla del hardware: el modelo vive en la memoria
Para entender ese cuello de botella conviene distinguir dónde viven los pesos y cómo crece el KV cache con el contexto.
VRAM, RAM y KV cache
Lo primero que hay que interiorizar es que los pesos del modelo residen en VRAM (con GPU) o en RAM (solo CPU), y que el KV cache crece con el tamaño de contexto. Si el conjunto no cabe, el sistema recurre a memoria más lenta y el rendimiento se desploma. La VRAM disponible es la variable que condiciona todo: modelo grande y contexto largo piden mucha memoria, y no hay atajo de software que evite esa aritmética.
De un 8B en 8 GB a un 70B en 48
Un caso concreto: llama3.1 admite contextos de hasta 128k tokens, y cada token de contexto se paga en el KV cache. Un 8B cuantizado cabe en una GPU de 8 GB para contextos razonables, mientras que un 70B en Q4 pide alrededor de 48 GB de VRAM, es decir, dos RTX 3090 de 24 GB o un Mac Studio con 96 GB de memoria unificada. Con una GPU de 24 GB, un 8B cuantizado se mueve en decenas de tokens por segundo; en CPU pura, el cuello de botella es el ancho de banda de memoria y las cifras bajan a unidades.
Elige primero el modelo y el tamaño de contexto que necesitas; la máquina se deriva de ahí, no al revés.
VPS con CPU: el punto de entrada barato
Qué cabe en un plan básico
Un VPS de 4 a 8 vCPU, 16 GB de RAM y disco NVMe ejecuta un 7B u 8B cuantizado sin drama para un solo usuario. En Europa, Hetzner, OVHcloud y Contabo cubren ese rango con planes que cuestan menos de diez euros al mes; DigitalOcean o Linode hacen lo propio si tu operación vive en EE. UU. Para embeddings, clasificación o tareas en segundo plano, esta opción es más que suficiente.
El límite: la concurrencia
El límite aparece con la concurrencia: todos los usuarios compiten por los mismos vCPU, y con dos o tres personas escribiendo a la vez la cola se nota. Aun así, es la mejor forma de aprender la parte operativa (Docker, volúmenes, proxies, actualizaciones de modelos) con riesgo financiero cercano a cero.
Si tu caso es un chat personal o un RAG con poco tráfico, empieza aquí y sube de RAM antes que de proveedor. Un plan de entrada te sirve para aprender la parte operativa sin prisa: puedes desplegar tu primer VPS hoy y probarlo con tu modelo por el precio de un café a la semana.
GPUs por horas: la nube como banco de pruebas
Cuando el alquiler gana
Para modelos de 30B o más, o simplemente para decidir cuál encaja con tu caso, alquilar GPU por horas resuelve el dilema sin comprar hardware. RunPod, Vast.ai o Lambda alquilan GPUs de 24 GB por debajo del euro la hora, con oscilaciones según la demanda del mercado. Encender una, cargar tu modelo candidato, medir velocidad y calidad, y apagarla cuesta céntimos.
Cuando pierde
El cálculo cambia si la carga es permanente: a modo de ejemplo, una GPU a 0,50 €/h encendida 24/7 ronda los 350-360 € al mes. Ahí el análisis se traslada a los servidores GPU dedicados que venden Hetzner u OVHcloud, con tarifa fija mensual y mejor precio por hora de uso sostenido. La regla práctica: horas sueltas para experimentar, servidor dedicado solo cuando la carga es constante y predecible.
Reserva una GPU durante una tarde, prueba tus dos o tres modelos candidatos y anota resultados antes de comprometerte a nada fijo.
Tu propia máquina: el coste que casi nadie calcula
El caso de la RTX 3090
Un sobremesa con una RTX 3090 de 24 GB sigue siendo la referencia del self-hosting casero, y su TDP de 350 W es solo la GPU; el equipo completo puede rondar los 450 W en inferencia. Con un uso de 4 horas diarias, eso son 657 kWh al año, que a 0,20 €/kWh (tarifa de ejemplo) equivalen a unos 130 € anuales. Suma esa cifra a la amortización del hardware antes de comparar con cualquier suscripción.
Ruido y disponibilidad
Hay dos fricciones que las hojas de costes ignoran: el ruido y la disponibilidad. Si el servidor es tu PC de escritorio, apagarlo por la noche significa que no hay servicio cuando lo necesitas de madrugada. Para cargas ligeras (embeddings, resúmenes automáticos, clasificación), un mini PC sin GPU dedicada cubre el trabajo con un consumo marginal.
Antes de decidir, enchufa el equipo a un medidor de consumo y obtén vatios reales; las estimaciones mentales casi siempre pecan de optimistas.
Ollama y Open WebUI en Docker: el stack mínimo
Los dos contenedores
Si administras servidores, ya sabes la respuesta: todo en contenedores. Ollama publica imagen oficial (ollama/ollama), y Open WebUI, la interfaz que convierte el motor en un chat multiusuario con historial, se conecta a él mediante la variable OLLAMA_BASE_URL. Con GPU NVIDIA necesitas el NVIDIA Container Toolkit en el host y el flag --gpus all; con AMD, Ollama distribuye una variante de imagen con ROCm (ollama/ollama:rocm).
La versión en una línea
La versión rápida en una línea:
docker run -d --gpus all -v ollama:/root/.ollama
-p 127.0.0.1:11434:11434 --name ollama ollama/ollama
Compose para mantener en el tiempo
Para algo que puedas mantener en el tiempo, un compose es más honesto:
services:
ollama:
image: ollama/ollama
volumes:
- ollama:/root/.ollama
ports:
- "127.0.0.1:11434:11434"
open-webui:
image: ghcr.io/open-webui/open-webui:main
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama:11434
depends_on:
- ollama
volumes:
ollama:
Fíjate en el detalle de publicar el 11434 solo en 127.0.0.1: así el motor queda inaccesible desde fuera y solo Open WebUI habla con él. Si quieres el despliegue paso a paso con capturas y opciones de configuración, ya lo documentamos en su momento: Open WebUI: monta tu chat de IA privada sobre Ollama en tu propio servidor.
Levanta el compose, entra por el puerto 3000 y deja el 11434 sin exponer públicamente desde el minuto uno. Si tu VPS va a quedarse, elige el tamaño pensando en el modelo más grande que quieras servir este año; la guía de agentes de IA locales con Hermes y Docker Compose muestra qué necesita el siguiente paso cuando el chat se convierte en agente.
Cuando el VPS se queda corto
Los tres techos
Tres límites aparecen con el crecimiento: la VRAM tiene techos fijos (no puedes meter un 70B en un VPS de CPU por mucho que optimices), las peticiones concurrentes se encolan, y los contextos largos disparan el consumo de memoria. Ollama procesa las solicitudes en cola por defecto, y la variable OLLAMA_NUM_PARALLEL permite paralelizar solo si la memoria disponible lo consiente. Saber cuándo has llegado a ese punto es cuestión de observar latencias y tiempos de cola, no de adivinar.
Los tres arreglos habituales
Los arreglos habituales pasan por tres caminos. Uno: bajar de modelo y compensar con RAG, indexando tus documentos con un modelo de embeddings ligero como nomic-embed-text (menos de 300 MB) y un vector store como Qdrant, de modo que un modelo pequeño responda con contexto relevante. Dos: enrutar por tipo de tarea, con el modelo local para lo rutinario y una API comercial para lo que exige músculo. Tres: montar un túnel (Cloudflare Tunnel tiene capa gratuita) que exponga la GPU de tu oficina o casa sin abrir puertos en el router.
Si quieres ver el patrón de modelo pequeño más RAG aplicado sobre un stack real, lo contamos con Ollama, Qdrant y plugins en IA local en WordPress. Define tu patrón de tráfico antes de escalar; el hardware correcto depende del percentil de carga, no de la media.
Seguridad: no publiques tu puerto 11434
Trátalo como un servicio interno
Un endpoint de inferencia abierto a internet recibe escaneos automatizados en cuestión de horas, igual que cualquier panel de administración olvidado. La postura correcta es tratar el stack como un servicio interno: Ollama escuchando solo en localhost o en la red interna de Docker, Open WebUI con cuentas de usuario y registro cerrado, y todo el acceso externo detrás de un proxy inverso con HTTPS (Caddy renueva certificados de Let’s Encrypt sin configuración extra).
Los dos controles que importan
Ollama aporta dos controles de recursos que conviene conocer: OLLAMA_KEEP_ALIVE, que define cuánto tiempo permanece un modelo cargado en memoria tras cada petición (cinco minutos por defecto), y OLLAMA_MAX_LOADED_MODELS, que limita cuántos modelos simultáneos conviven en memoria. Ajustar ambos evita que un pico de consumo deje tu VPS sin RAM para el resto de servicios.
Abre ahora mismo una terminal y comprueba tu firewall: si el 11434 está expuesto al mundo, ciérralo hoy, no mañana.
Conclusión: elige por patrón de uso, no por especificaciones
Tres patrones, tres presupuestos
Tres patrones de uso dibujan tres presupuestos distintos. El chat personal y el RAG ligero se resuelven con un VPS CPU de menos de diez euros al mes; el uso diario intensivo con modelos grandes justifica la compra de una GPU de 24 GB, cuya factura eléctrica ya sabes estimar; la experimentación irregular se alquila por horas sin compromiso. El error más caro es cruzar los patrones: pagar una GPU dedicada en la nube para usarla cuatro horas al mes, o intentar servir producción desde un portátil sin GPU.
El primer paso, hoy
El primer paso concreto sigue siendo el mismo para todos los casos: ollama pull llama3.1:8b, un cronómetro y cinco minutos de pruebas en tu propia máquina. Con esos números sobre la mesa, el resto de decisiones de hardware y costes se vuelve aritmética en lugar de intuición.