Ollama con API propia: cómo dejar de pagar por token y conectar tus apps a tu propio modelo de IA

Si tu app o tu script ya usa la API de OpenAI (o cualquier proveedor compatible), migrar a tu propio modelo no significa reescribir el código de integración — Ollama expone una API que habla el mismo formato, así que en la mayoría de los casos el cambio real es solo una URL. Vamos a instalarlo, exponer esa API y conectarla a una aplicación real.

Si todavía no tienes Ollama instalado en tu servidor, instálalo con el script oficial (ya cubrimos la instalación completa con más detalle en una guía anterior, esto es el mínimo para arrancar):

curl -fsSL https://ollama.com/install.sh | sh

Descarga un modelo. Elige uno del tamaño que tu servidor pueda correr cómodamente — si no sabes cuánta RAM necesitas, ya lo cubrimos en la guía de dimensionamiento. Para esta guía usamos Llama 3.1 de 8.000 millones de parámetros, un buen punto de partida:

ollama pull llama3.1:8b

Confirma que el servicio de Ollama está corriendo y escuchando — por defecto lo hace en el puerto 11434 de tu propio servidor:

sudo systemctl status ollama
curl http://localhost:11434/api/tags

Si la última línea te devuelve una lista con el modelo que acabas de descargar, la API ya está activa.

Ahora prueba el endpoint compatible con OpenAI directamente. Ollama expone /v1/chat/completions con el mismo formato de petición y respuesta que usa la API de OpenAI — esto es lo que te permite reutilizar cualquier librería o código ya escrito para GPT sin modificarlo:

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1:8b",
    "messages": [{"role": "user", "content": "Resume en una frase qué es un VPS"}]
  }'

Conecta una app real apuntando al nuevo endpoint. Si ya tienes código en Python usando la librería oficial de OpenAI, el cambio es de dos líneas — solo cambias la URL base y pones cualquier valor como API key (Ollama no la valida, pero la librería exige que el campo exista):

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="no-hace-falta-una-real"
)

respuesta = client.chat.completions.create(
    model="llama3.1:8b",
    messages=[{"role": "user", "content": "Resume en una frase qué es un VPS"}]
)
print(respuesta.choices[0].message.content)

Con eso, cualquier app que hoy le paga a OpenAI o a otro proveedor por cada token ya puede hablar con tu propio modelo sin tocar el resto del código.

No dejes el puerto 11434 abierto a internet. Por defecto, Ollama no pide autenticación — cualquiera que llegue a ese puerto puede usar tu modelo (y tu factura de cómputo). Si esa API solo la va a usar tu propia app corriendo en el mismo servidor, déjala escuchando en localhost únicamente. Si necesitas que otro servidor o servicio externo la consuma, ponla detrás de un proxy con autenticación real — ya cubrimos cómo hacerlo con Cloudflare Tunnel y ZTNA en una guía anterior.

¿Cuándo conviene de verdad dejar de pagar por token? No es una regla universal. Si tu uso es esporádico o bajo volumen, seguir pagando por token a un proveedor externo casi siempre sale más barato que mantener un servidor prendido 24/7 solo para eso. Donde el cálculo cambia a tu favor es cuando el volumen de peticiones es alto y constante — un chatbot interno que responde cientos de consultas al día, un proceso de clasificación que corre sobre miles de registros, una integración que llama al modelo en cada solicitud de tu app — porque ahí el costo de tu servidor se vuelve fijo mientras que el costo por token sigue subiendo con cada llamada adicional. Antes de migrar, mide cuánto estás gastando hoy en la API externa durante un mes típico y compáralo contra el costo del servidor que necesitarías: la respuesta te la va a dar esa cuenta, no una regla general.

Correr un modelo con tráfico constante de una aplicación en producción exige más estabilidad y recursos dedicados que un VPS de entrada compartiendo hardware con otras cuentas. Si tu app ya depende de esta API para funcionar, en /planes/vds tienes los recursos dedicados para que la latencia y la disponibilidad no se conviertan en el próximo problema.