Ollama Cloud frente a tu servidor: qué cambia

Qué cambia Ollama Cloud y qué no

Ollama Cloud ejecuta el modelo en ollama.com en lugar de hacerlo en su propio hardware, pero mantiene el mismo comando ollama y la misma API REST que ya utiliza. Cambian dos cosas: el nombre del modelo que solicita y la ubicación de la credencial. El resto de la aplicación permanece exactamente igual.

Esa comodidad también implica un riesgo. En el código, una solicitud a un modelo en la nube tiene el mismo aspecto que una solicitud a un modelo local. Por eso es fácil perder de vista qué prompts se ejecutan en una máquina que controla y cuáles se envían a una empresa que no controla. Esta guía establece esa diferencia y muestra cómo mantener un modelo local como alternativa, de modo que un único valor de configuración determine qué opción utiliza.

Si todavía no ha preparado el entorno local, empiece por ejecutar Ollama en su propio VPS. Todo lo que sigue presupone que dispone de un ollama operativo en un sistema Linux.

Dos formas de acceder a Ollama Cloud

Hay dos rutas para acceder a los modelos alojados y no son intercambiables. La ruta que elija determina dónde se almacena la credencial, qué nombre de modelo debe escribir y qué mostraría una captura de paquetes en el servidor.

Ruta uno: el daemon local reenvía la solicitud. Inicie sesión una vez y, después, solicite un modelo cuyo nombre termine en -cloud.

ollama signin
ollama pull gpt-oss:120b-cloud
ollama run gpt-oss:120b-cloud

ollama signin vincula esta máquina con su cuenta de ollama.com. ollama signout la desvincula. Después de iniciar sesión, la aplicación sigue comunicándose con el puerto local que ya utilizaba:

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss:120b-cloud",
  "messages": [{"role": "user", "content": "Why is the sky blue?"}],
  "stream": false
}'

Vuelva a leer esa URL. Indica localhost, pero la inferencia no se realiza allí. El daemon local reconoce el sufijo -cloud, reenvía la solicitud a ollama.com y devuelve la respuesta mediante streaming. Este es el objetivo de la ruta uno: una aplicación que ya apunta a la API de Ollama en el puerto 11434 no necesita ningún cambio de código, sólo un nombre de modelo diferente.

Ruta dos: el cliente llama directamente a ollama.com. En este caso, el daemon local no interviene. Cree una clave en https://ollama.com/settings/keys y envíela como un token bearer.

export OLLAMA_API_KEY=your_api_key
curl https://ollama.com/api/chat \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -d '{
    "model": "gpt-oss:120b",
    "messages": [{"role": "user", "content": "Why is the sky blue?"}],
    "stream": false
  }'

Observe el nombre del modelo. En la ruta dos es gpt-oss:120b, sin el sufijo -cloud. El sufijo existe para indicar al daemon local que reenvíe la solicitud al servicio ascendente, por lo que sólo corresponde a la ruta uno. Cuando llama a https://ollama.com ya está allí y debe escribir el nombre sin modificaciones. La lista autorizada de esos nombres procede del propio host:

curl https://ollama.com/api/tags

Ejecute ese comando en lugar de confiar en cualquier lista de modelos publicada en un artículo, incluido este. El catálogo cambia y api/tags siempre está actualizado.

Qué llamadas de cliente cambian y cuáles no

Las bibliotecas oficiales de Python y JavaScript reciben el host y las cabeceras al construir el cliente. Después de esa línea, nada más cambia. En la primera opción, el constructor está vacío porque el valor predeterminado es el daemon local:

from ollama import Client

client = Client()

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b-cloud', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

En la segunda opción, el constructor incluye el host y el token:

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={'Authorization': 'Bearer ' + os.environ.get('OLLAMA_API_KEY')}
)

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

La llamada client.chat(), el bucle de streaming, la lista de mensajes y la estructura de la respuesta son idénticos en ambas opciones. Por eso, pasar de un servicio alojado a uno autogestionado es un cambio de configuración, no una reescritura. La interfaz compatible con OpenAI funciona igual localmente: apunte un SDK de OpenAI a http://localhost:11434/v1/ con api_key='ollama', que el servidor local requiere y después ignora.

Dónde se almacena la credencial y quién puede usarla

En la ruta dos, la credencial está en OLLAMA_API_KEY dentro del entorno. Manténgala fuera del historial del shell y del repositorio. En un servicio de systemd, colóquela en una línea Environment= o en un archivo de entorno propiedad de root con permisos 600.

La ruta uno es la que suele sorprender. La identidad de inicio de sesión pertenece al daemon, no a usted. La FAQ de Ollama documenta la identidad del servicio en Linux en /usr/share/ollama/.ollama/id_ed25519.pub, cuyo propietario es el usuario de servicio ollama. La API local no tiene autenticación por solicitud, por lo que cualquier proceso que pueda acceder al puerto 11434 hereda su cuenta y consume su cuota. Esto es correcto mientras el daemon escuche en loopback. En cuanto configure OLLAMA_HOST=0.0.0.0:11434 para acceder desde otra máquina, un puerto abierto se convierte en una relación de facturación abierta. Por eso, antes de ampliar la dirección de enlace, debe leer cómo colocar autenticación delante de un endpoint de Ollama.

Por qué el mismo modelo ofrece menos contexto en local

Esta es la diferencia que sorprende a quienes suponen que un modelo se comporta igual por ambos medios. No es así, y la causa es la memoria.

Ollama elige una longitud de contexto local predeterminada según la memoria de vídeo que detecta en el equipo.

[
  {
    "label": "Under 24 GiB VRAM",
    "default_context_tokens": "4,096"
  },
  {
    "label": "24 to 48 GiB VRAM",
    "default_context_tokens": "32,768"
  },
  {
    "label": "48 GiB VRAM or more",
    "default_context_tokens": "262,144"
  }
]

Un VPS sin GPU se encuentra en el nivel inferior, por lo que un modelo local empieza con 4,096 tokens de contexto, mientras que una máquina con una tarjeta de gran capacidad empieza con 262,144. Los modelos en la nube ignoran estos niveles: Ollama los documenta con la longitud de contexto máxima de forma predeterminada, porque la memoria que contiene ese contexto no es suya.

Por tanto, el mismo prompt que funciona con gpt-oss:120b-cloud puede truncarse silenciosamente al usar un modelo local en un equipo pequeño. Aumente explícitamente el límite local:

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Con systemd, configúrelo como Environment="OLLAMA_CONTEXT_LENGTH=32768" mediante systemctl edit ollama.service y, después, systemctl daemon-reload && systemctl restart ollama. Tenga en cuenta lo que implica: un contexto más largo requiere una caché key-value mayor, y esa caché necesita RAM adicional a los pesos del modelo. Si lo aumenta demasiado, la generación se ralentiza o el modelo no puede cargarse. Configurar correctamente num_ctx y OLLAMA_CONTEXT_LENGTH explica los cálculos, y qué modelos caben en la memoria disponible trata la parte correspondiente a los pesos.

Qué sale realmente de su máquina

Sea exacto con esto, porque es la razón principal por la que la mayoría de los lectores eligen alojar estos servicios por su cuenta.

Si se ejecuta localmente, no sale nada. La política de privacidad de Ollama lo indica claramente: para el uso local, «No recopilamos, almacenamos, transmitimos ni tenemos acceso a sus prompts, respuestas, interacciones con el modelo ni a ningún otro contenido que procese localmente». Hay una salvedad: descargar un modelo sigue siendo una descarga desde ollama.com, y la política incluye los «metadatos de descarga del modelo» y su dirección IP entre los datos recopilados. El registro de modelos sabe qué modelos descargó. No sabe qué les preguntó.

Si se ejecuta mediante la ruta cloud, el prompt completo y la respuesta completa se envían a un tercero. No existe una versión parcial de esto. Cada token que envía y cada token que recibe se procesa en ollama.com. La política indica que la empresa procesa «sus prompts y respuestas de forma transitoria para prestar el servicio», que «no utiliza sus entradas ni salidas para entrenar modelos de IA» y que aplica «medidas técnicas diseñadas para minimizar la retención del contenido de prompts y respuestas». Es un compromiso razonable. Sigue siendo un compromiso de otra entidad sobre los datos que usted le entrega, no una propiedad de su propia máquina. Evalúelo como evaluaría cualquier promesa de un proveedor y vuelva a leerla antes de enviar información que, por contrato o por ley, deba conservar en su propia infraestructura.

La trampa está en la ruta uno. Su código indica http://localhost:11434, las reglas del firewall no han cambiado y el prompt sigue atravesando Internet, porque el sufijo -cloud del nombre del modelo se encarga del enrutamiento. Una URL localhost no indica dónde se realizó la inferencia. El nombre del modelo sí lo indica.

Mantener un modelo local como alternativa

Como ambas rutas usan la misma API, puede convertir la elección en un ajuste de ejecución en lugar de bifurcar el código.

La versión más sencilla no requiere código. Mantenga la aplicación apuntando al daemon local y defina el nombre del modelo en la configuración. Establézcalo en llama3.2 para ejecutarlo en su propio equipo. Establézcalo en gpt-oss:120b-cloud y el mismo daemon reenviará las peticiones a ollama.com. Basta con una variable de entorno y no es necesario volver a desplegar.

Si quiere que el modelo local sea el predeterminado y que la nube atienda el exceso de carga, construya ambos clientes y elija uno por petición:

import os
from httpx import ConnectError
from ollama import Client, ResponseError

LOCAL_MODEL = os.environ.get("LOCAL_MODEL", "llama3.2")
CLOUD_MODEL = os.environ.get("CLOUD_MODEL", "gpt-oss:120b")

local = Client(host="http://127.0.0.1:11434")
cloud = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

def chat(messages):
    try:
        return local.chat(LOCAL_MODEL, messages=messages)
    except (ConnectError, ResponseError) as err:
        print(f"local inference failed ({err}); sending this prompt to ollama.com")
        return cloud.chat(CLOUD_MODEL, messages=messages)

httpx llega como dependencia del paquete ollama, por lo que no hay nada adicional que instalar. ConnectError cubre el caso en que el daemon está detenido. ResponseError cubre el caso en que el daemon está activo pero rechaza la petición, por ejemplo, porque nunca se descargó el modelo local.

La línea print no es decorativa. Una alternativa silenciosa hace que un prompt que pretendía mantener en su propio hardware se envíe a un tercero sin avisar la primera vez que el daemon se reinicia durante una actualización. Registre cada uso de la alternativa y, para cualquier dato sensible, genere el error en lugar de usarla. La política más segura para un despliegue que prioriza la privacidad es fallar de forma explícita.

Hay otro aspecto que convierte al modelo local en un valor predeterminado fiable: manténgalo residente en memoria. Cargarlo en frío en un VPS que sólo usa CPU puede tardar decenas de segundos. Eso es lo que suele llevar a los usuarios a elegir la ruta de nube. Mantener el modelo en memoria con keep_alive elimina esa penalización de la primera petición.

Qué comparar antes de comprometerte

No compares sólo por precio ni confíes en un precio que hayas leído en un artículo, incluida la fecha de este. Compara cuatro aspectos y comprueba cada uno en las páginas del propio proveedor:

• Disponibilidad de modelos. Ejecuta curl https://ollama.com/api/tags para consultar el catálogo alojado actual. Los modelos que puedes ejecutar localmente están limitados por la RAM y la VRAM disponibles.
• Límites de contexto. Los modelos alojados usan de forma predeterminada su máximo. Los modelos locales usan de forma predeterminada el límite correspondiente a su nivel de VRAM, como se ha indicado arriba. Si tu carga de trabajo consiste en documentos largos, este aspecto resuelve la decisión por sí solo.
• Límites de solicitudes. La inferencia alojada se mide por consumo. Si superas el límite, la API responde con 429 Too Many Requests. Tu propio servidor no tiene un límite de solicitudes, sino un límite máximo de concurrencia; es un tipo de fallo distinto y, a menudo, peor.
• Política de retención. Lee el texto real de la política, anota la fecha en que lo has leído y vuelve a comprobarlo antes de cualquier renovación.

En cuanto al coste, no repitas aquí los cálculos. Cuándo una GPU VPS supera la facturación por token explica correctamente el punto de equilibrio, incluida la parte que muchos olvidan: un servidor GPU inactivo se factura igual que uno ocupado.

¿Y un router delante de varios proveedores?

La tercera opción es un router: un proxy que expone una sola API a la aplicación y distribuye las solicitudes entre varios backends. Un proxy LiteLLM autohospedado o un servicio alojado como OpenRouter hacen esto. La ventaja es clara: una sola configuración del cliente, varios modelos y conmutación por error cuando un proveedor tiene problemas. Es la extensión natural del patrón de fallback anterior, generalizado a más de dos backends. Sin embargo, tenga claro el coste. Un router alojado es otro operador que ve sus prompts, por lo que la pregunta sobre la retención que hizo a un proveedor ahora debe plantearse a dos. Un router autohospedado mantiene ese salto en su propia máquina, pero añade otro servicio que debe ejecutar, actualizar y monitorizar. Los routers resuelven la selección de modelos y la disponibilidad. No resuelven la privacidad, porque el prompt sigue llegando al destino al que lo envía la ruta.

Los errores que realmente verá

La API documenta los códigos de estado, y cada uno apunta a un problema diferente. 429 Too Many Requests significa que ha alcanzado un límite de tasa, así que espere y vuelva a intentarlo en lugar de reconectarse en un bucle. 502 Bad Gateway es el código específico de este tema: se devuelve cuando no se puede acceder a un modelo en la nube, por lo que en la ruta uno significa que el daemon funciona y que el servicio ascendente no. 404 Not Found en un nombre de modelo suele significar que el sufijo no coincide con el host, que se ha enviado un nombre -cloud directamente a https://ollama.com o que se ha enviado un nombre sin calificar a un daemon en el que nunca se inició sesión. Los errores llegan como JSON y, durante una respuesta en streaming, aparecen como una línea como {"error":"an error was encountered while running the model"} dentro de la respuesta NDJSON. Por eso, un cliente de streaming ingenuo puede imprimir una respuesta parcial y detenerse sin explicar el motivo. Analice cada línea recibida y compruebe si contiene una clave error.

En el lado local, el caso clásico es una conexión rechazada en el puerto 11434, lo que significa que el daemon no está en ejecución: compruebe systemctl status ollama. El otro caso clásico es una petición que funciona desde el shell y falla desde un contenedor, porque el localhost del contenedor no es el del host.

Y existe un modo de fallo sin ningún mensaje de error: no hay conexión a Internet. La ruta en la nube deja de funcionar por completo, mientras que la ruta local no lo detecta. Si lleva la máquina fuera de la red habitual o su proveedor sufre una incidencia de enrutamiento, esa diferencia es todo el producto.

Qué opción conviene en cada caso

Use Ollama Cloud cuando la carga sea irregular, cuando el modelo sea demasiado grande para su VPS o cuando todavía esté evaluando si merece la pena basar el sistema en ese modelo. Pagar por solicitud es mejor que pagar por una GPU inactiva que sólo funciona veinte minutos al día. Además, un modelo de 120-billion-parameter no cabe en un servidor que alquila por el precio de un almuerzo.

Ejecute el modelo en su propia infraestructura cuando los prompts no deban salir de ella, cuando la máquina tenga que funcionar sin conexión o cuando la carga sea suficientemente constante para mantener ocupada una GPU alquilada. La carga constante es la señal más clara: la inferencia con tarificación por uso resulta cara precisamente cuando se ejecuta todo el tiempo. Si llega a ese punto y el rendimiento de Ollama para una sola solicitud se convierte en el cuello de botella, vLLM gestiona mejor la carga concurrente que Ollama, y eso implica cambiar el motor, no el host.

La mayoría de las implementaciones reales terminan usando ambos, lo cual está bien siempre que la división sea deliberada. Guarde el nombre del modelo en la configuración, registre cada fallback y siempre podrá responder a la única pregunta que importa aquí: ¿cuáles de estos prompts salieron de la infraestructura?

FAQ

¿Ollama Cloud ve mis prompts?

Sí. En la ruta alojada, el prompt completo y la respuesta completa se envían a ollama.com y se procesan allí. La política de privacidad de Ollama indica que procesa "tus prompts y respuestas de forma transitoria para prestar el servicio" y que "no utiliza tus entradas ni salidas para entrenar ningún modelo de IA". También describe medidas diseñadas para minimizar la retención. Este compromiso del proveedor se aplica a los datos que ya le has entregado. Para los modelos locales, la misma política indica que la empresa "no recopila, almacena, transmite ni tiene acceso a tus prompts, respuestas, interacciones con modelos ni a ningún otro contenido que proceses localmente". Si el requisito es que el contenido nunca salga de tu infraestructura, sólo la ruta local lo cumple.

¿Por qué mi aplicación sigue apuntando a localhost cuando el modelo se ejecuta en la nube?

Porque el daemon local actúa como proxy. Cuando ejecutas ollama signin y solicitas un modelo cuyo nombre termina en -cloud, el daemon reenvía esa solicitud a ollama.com y transmite la respuesta de vuelta a través del puerto 11434. La URL de la aplicación no cambia. Ese es precisamente el objetivo: no es necesario editar el código. También significa que la dirección localhost no indica dónde se ejecutó la inferencia. Comprueba el nombre del modelo, no la URL. Un sufijo -cloud significa que el prompt atravesó Internet.

¿Por qué el mismo modelo me proporciona un contexto mucho más corto localmente?

Ollama elige un valor local predeterminado según la memoria de vídeo disponible: unos 4k tokens por debajo de 24 GiB de VRAM, 32k entre 24 y 48 GiB, y 256k a partir de 48 GiB. Una VPS sin GPU pertenece al nivel inferior. Los modelos en la nube utilizan de forma predeterminada su longitud de contexto máxima, porque la memoria que la contiene pertenece al proveedor. Aumenta el valor local con OLLAMA_CONTEXT_LENGTH, ya sea como OLLAMA_CONTEXT_LENGTH=32768 ollama serve o como una línea Environment= dentro de systemctl edit ollama.service. Recuerda que un contexto más largo necesita una caché key-value mayor en la RAM. Por tanto, aumentarlo en un servidor pequeño puede ralentizar la generación o impedir que se cargue el modelo.

¿Puedo cambiar automáticamente a un modelo local cuando la nube no esté disponible?

Sí, y sólo requiere unas pocas líneas, porque ambas rutas utilizan la misma API. Crea dos objetos Client: uno sin el argumento host para el daemon local y otro con host="https://ollama.com" y una cabecera Authorization: Bearer. Después, captura httpx.ConnectError y ollama.ResponseError alrededor de la primera llamada. Decide deliberadamente la dirección del cambio. Usar primero el modelo local con la nube como alternativa significa que un prompt que pretendías mantener privado puede salir de la máquina durante un reinicio rutinario del daemon. Por tanto, registra cada cambio y, para cargas de trabajo sensibles, genera el error en lugar de cambiar automáticamente a la nube.