Enviar cada prompt a la API de otro está bien — hasta que no lo está. Quizá los datos son sensibles y preferirías que nunca salieran de tu servidor. Quizá estás cansado de los límites de tasa, o de que una versión del modelo cambie bajo tus pies, o de un contador por token corriendo mientras experimentas. En algún punto «¿y si simplemente ejecutara el mío?» deja de ser un experimento mental.
Ollama hace eso genuinamente fácil. La pregunta más difícil es qué cabe en un VPS — y aquí la respuesta honesta importa más que el hype.
Qué puedes ejecutar de verdad en CPU
¿Sin GPU? Entonces estás haciendo inferencia en CPU, y el tamaño del modelo lo es todo. La quantización (comprimir los pesos a 4-bit) es lo que hace esto práctico — pierdes un pedacito de calidad y ahorras un montón de memoria.
Números aproximados, los que importan:
- Modelo de 3B, 4-bit — ~3 GB de RAM. Lo bastante ágil para chat y tareas simples.
- Modelo de 7B, 4-bit — ~5 GB de RAM. El sweetspot: notablemente más listo, aún corre a un ritmo legible.
- 13B y más — 8-10 GB+ y lento en CPU. Técnicamente posible, prácticamente molesto.
Velocidad, con honestidad: en unos pocos vCPUs verás un puñado de tokens por segundo. Perfectamente bien para un chatbot o un asistente de código donde lees mientras escribe. No está bien para procesar por lotes un millón de documentos — eso es un trabajo de GPU, y no fingimos lo contrario. No ofrecemos instancias de GPU. Si tu plan necesita un modelo de 70B o throughput pesado, un VPS de CPU — el nuestro o el de nadie — es la herramienta equivocada, y deberías saberlo antes de gastar un céntimo.
Pero ¿un 7B privado que responde tus preguntas y nunca telefonea a casa? Eso corre cómodamente en una máquina de 6 GB.
La instalación — tres comandos
Levanta el servidor, conéctate por SSH, y:
curl -fsSL https://ollama.com/install.sh | sh # instala Ollama
ollama run llama3.2:3b # descarga + ejecuta un modelo de 3B
Eso es todo — estás chateando en el terminal. Para usarlo desde tu propio código, Ollama ya sirve una API HTTP en el puerto 11434:
curl http://localhost:11434/api/generate -d '{
"model": "llama3.2:3b",
"prompt": "Summarize this changelog in two lines: ...",
"stream": false
}'
Un detalle que vale la pena conocer de antemano: por defecto esa API se ata a localhost. Mantenlo así y tuneliza por SSH, o queda expuesto a internet. Si lo quieres accesible, ponlo detrás de auth — no dejes un endpoint de modelo abierto en una IP pública.
Elegir la máquina
Casa el plan con el modelo, no al revés:
| Lo que quieres ejecutar | RAM que necesitas | Plan sensato |
|---|---|---|
| Modelo de 3B, uso ligero | ~3 GB | Small (4 GB) |
| Modelo de 7B, cómodamente | ~5-6 GB | Medium (6 GB) |
| Más grande / alto throughput | Terreno de GPU | no un VPS de CPU |
Para la mayoría de los autoalojadores, Medium (6 GB) es la recomendación honesta — suficiente margen para un modelo de 7B más tu app y el OS. Small (4 GB) funciona si te quedas en 3B. Cualquier cosa por debajo es demasiado justo una vez que el OS y el contexto entran a comer.
Por qué hacerlo aquí
Si estás autoalojando un LLM, la privacidad suele ser la mitad de la razón — así que sería raro entregar tu documento para alquilar la máquina. No tienes que hacerlo: puedes pagar en USDC o USDT (o una tarjeta vía el on-ramp), sin KYC, y el servidor es tuyo en aproximadamente un minuto. Cripto-nativo, amigable con agentes, y los datos se quedan en una máquina que controlas.
El compromiso es el que hemos sido honestos sobre: solo CPU, un techo de 6 GB, modelos pequeños. Dentro de eso, autoalojar es genial. Fuera de eso, no dejes que nadie te venda una máquina de CPU para un trabajo que necesita una GPU.
¿Listo para probar? Elige un plan, paga, y tendrás root en unos 60 segundos — luego son tres comandos hasta tu propio modelo privado.
Comentarios
Aún no hay comentarios. Sé el primero.