Ollama Cloud o servidor propio: 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 opción que elija determina dónde se almacena la credencial, qué nombre de modelo debe escribir y qué mostraría una captura de paquetes en su 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

Algunos modelos en la nube llevan en su lugar una etiqueta cloud sin sufijo adicional, como gemma4:cloud. Esa es la forma que muestran actualmente la documentación de Ollama para la aplicación y la CLI. Considere cualquiera de las terminaciones, -cloud o :cloud, como un modelo en la nube.

ollama signin vincula esta máquina a su cuenta de ollama.com. ollama signout la desvincula. Después de iniciar sesión, su 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 y la inferencia no se realiza allí. El daemon local reconoce el sufijo -cloud, reenvía la solicitud a ollama.com y le transmite la respuesta. 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 una cadena 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 indica 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 del 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 a 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 autohospedado es un cambio de configuración, no una reescritura. La interfaz compatible con OpenAI funciona igual de forma local: apunte un SDK de OpenAI a http://localhost:11434/v1/ con api_key='ollama', un marcador de posición que el SDK exige y que el servidor local 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 de forma local

Esta es la diferencia que afecta a quienes asumen que un modelo se comporta igual en ambas rutas. 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"
  }
]

Una VPS sin GPU queda 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 grande empieza con 262,144. Los modelos en la nube ignoran estos niveles: Ollama los documenta con su 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 con un modelo local en un equipo pequeño. Aumente explícitamente el límite local:

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Con systemd, establézcalo 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 más grande, y esa caché usa RAM adicional a la que necesita el modelo para sus pesos. 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 de los pesos.

Qué sale realmente de su máquina

Sea preciso con esto, porque es la razón principal por la que la mayoría de los lectores alojan sus propios servicios.

Si se ejecuta de forma local, 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 modelos 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 de modelos» y su dirección IP entre los datos recopilados. El registro sabe qué modelos ha descargado. No sabe qué les ha preguntado.

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 la promesa de cualquier proveedor y vuelva a leerla antes de enviar datos que esté obligado contractual o legalmente a 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 determina el enrutamiento. Una URL de localhost no le dice dónde se realizó la inferencia. El nombre del modelo sí. Esto importa especialmente cuando el prompt contiene datos que aloja usted mismo para mantenerlos privados: si ejecuta un rastreador de ubicación autohospedado para que su historial de movimientos nunca llegue a un tercero, pedir a un modelo -cloud que resuma una semana de ese historial lo envía igualmente a ollama.com.

En un servidor que nunca debe reenviar un prompt, elimine por completo esa posibilidad. Ollama documenta un modo exclusivo local: establezca OLLAMA_NO_CLOUD=1 en el entorno del servicio o "disable_ollama_cloud": true en ~/.ollama/server.json y reinicie. El daemon pierde el acceso a los modelos cloud y a la búsqueda web, por lo que un nombre de modelo cloud introducido por error no puede filtrar ningún dato.

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 verá realmente

La API documenta los códigos de estado y cada uno apunta a un problema distinto. 429 Too Many Requests significa que ha alcanzado un límite de tasa, por lo que debe esperar y reintentar 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, así que en la ruta uno significa que el daemon funciona correctamente y que el servicio ascendente no. 404 Not Found aplicado a un nombre de modelo significa que el modelo no existe en el host solicitado: normalmente se ha enviado un nombre -cloud directamente a https://ollama.com, o se trata de un modelo local que nunca se descargó. El inicio de sesión no interviene en los modelos locales, porque la API local no requiere autenticación. Los errores llegan como JSON y, durante la transmisión, aparecen como una línea similar a {"error":"an error was encountered while running the model"} dentro de la respuesta NDJSON. Por eso, un cliente de streaming sencillo puede mostrar una respuesta parcial y detenerse después sin explicación. Analice cada línea recibida y compruebe si contiene una clave error.

En el lado local, el caso clásico es un error de conexión rechazada en el puerto 11434, lo que significa que no hay ningún proceso escuchando allí: compruebe systemctl status ollama y, si el daemon está en ejecución, compruebe si OLLAMA_HOST lo cambió a otro puerto. El otro caso clásico es una petición que funciona desde el shell pero falla desde un contenedor, porque el localhost del contenedor no es el del host.

También existe un modo de fallo sin ningún mensaje de error: no hay conexión a Internet. La ruta de la nube deja de funcionar por completo, mientras que la ruta local no lo detecta. Si el equipo se conecta desde otra ubicación o el proveedor sufre una incidencia de enrutamiento, esa diferencia afecta a 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 usted mismo cuando las solicitudes no deban salir de su infraestructura, cuando el equipo tenga que funcionar sin conexión o cuando la carga sea lo bastante estable para mantener ocupada una GPU alquilada. La carga estable es el indicador más claro: la inferencia con tarifa por uso resulta cara precisamente cuando se ejecuta de forma continua. Si llega a ese punto y el rendimiento de Ollama con solicitudes individuales se convierte en el cuello de botella, vLLM gestiona mejor la carga concurrente que Ollama, y eso implica cambiar de motor, no de servidor. Si prefiere comprar esa instalación privada en lugar de crearla, comparar un servidor de IA privado con presupuesto bajo demanda con crear uno propio en una GPU alquilada muestra lo que implica realmente el montaje y cuándo conviene más comprar una API sencilla.

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 u 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 si el modelo se ejecuta en la nube?

Porque el daemon local actúa como proxy. Cuando ejecutas ollama signin y después solicitas un modelo cloud cuyo nombre termina en -cloud o :cloud, el daemon reenvía esa solicitud a ollama.com y transmite la respuesta a través del puerto 11434. La URL de la aplicación no cambia. Ese es el objetivo: no hace falta modificar 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. Una etiqueta cloud en el nombre indica que el prompt atravesó Internet.

¿Por qué el mismo modelo tiene un contexto mucho más corto en local?

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

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

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