Ollama Cloud: cuenta, autenticación y modelos en la nube

Qué es Ollama Cloud

Ollama Cloud es el servicio en la nube de Ollama: los modelos se ejecutan en servidores gestionados por Ollama, no en tu máquina. Resulta útil cuando no tienes GPU o RAM suficiente para el modelo que quieres usar, cuando prefieres no administrar infraestructura o cuando quieres probar modelos grandes sin descargarlos.

Desde el punto de vista del usuario, la CLI y la API se usan igual que en local. La diferencia está en que indicas que quieres usar un modelo en la nube añadiendo el sufijo :cloud al nombre del modelo (por ejemplo, qwen3.5:cloud o llama3.2:cloud). Para que eso funcione, necesitas una cuenta y estar autenticado.

flowchart LR
    A["Crear cuenta<br/>en ollama.com"] --> B["ollama signin<br/>en la terminal"]
    B --> C["CLI vinculada<br/>a tu cuenta"]
    C --> D{"¿Uso desde código?"}
    D -->|"Sí"| E["Generar API key<br/>en ollama.com"]
    D -->|"No (solo CLI)"| F["ollama run<br/>modelo:cloud"]
    E --> G["Header Authorization<br/>Bearer API_KEY"]

Crear cuenta e iniciar sesión

Para usar Ollama Cloud debes tener una cuenta en el servicio. Puedes crearla desde la web de Ollama o durante el primer uso de la función de nube.

Una vez tengas cuenta, la autenticación desde la terminal se hace con:

ollama signin

Este comando abre el navegador (o te muestra un enlace si no puede abrirlo) para que inicies sesión con tu cuenta. Tras completar el proceso, la CLI queda asociada a tu usuario y podrás usar modelos con el sufijo :cloud sin tener que repetir el login en cada comando.

En el navegador suele mostrarse un flujo para vincular la CLI con tu cuenta: inicio de sesión, conexión del dispositivo y confirmación.

Si trabajas en un entorno sin navegador (por ejemplo, un servidor remoto), el flujo puede incluir enlaces o códigos que debes completar en otro dispositivo. Consulta la documentación oficial de Ollama para los detalles según tu versión.

API key para programas y servicios

Cuando quieres que una aplicación o un script use Ollama Cloud (por ejemplo, llamando a la API REST desde tu código), no puedes depender del login interactivo. En ese caso se usa una API key.

La API key se genera desde la configuración de tu cuenta en el sitio de Ollama. Es un token secreto que identifica y autoriza las peticiones a los modelos en la nube. Debes tratarla como una contraseña: no la incluyas en el código que subes a un repositorio ni la compartas.

En las peticiones a la API de Ollama Cloud sueles enviar la API key en un header de autenticación (por ejemplo, Authorization: Bearer <tu-api-key>). Así los clientes (navegador, Postman, tu aplicación) pueden usar modelos remotos sin tener que ejecutar ollama signin en esa máquina.

La autenticación en la nube en llamadas desde código o desde clientes HTTP se hace enviando esa API key en el header de autorización correspondiente.

Uso del sufijo :cloud

En la línea de comandos, cuando quieres usar un modelo que está en la nube en lugar del modelo local, añades :cloud al nombre del modelo.

Ejemplos:

• qwen3.5:cloud: usa la familia Qwen 3.5 en los servidores de Ollama Cloud.
• llama3.2:cloud: usa Llama 3.2 en la nube.

Si escribieras solo llama3.2, Ollama usaría el modelo local (si lo tienes descargado). El sufijo :cloud es lo que indica que la ejecución debe hacerse en la nube. El resto de la interacción (chat, generación, parámetros) es conceptualmente igual, y solo cambia dónde corre el modelo.

Esto permite mezclar en el mismo flujo de trabajo modelos locales y en la nube: unos los tienes en disco y otros los ejecutas vía Ollama Cloud según necesidad y recursos.

Desactivar el uso de la nube

En algunos entornos (empresa, compliance, redes aisladas) puede requerirse que la aplicación nunca intente conectar con Ollama Cloud. Para eso existe la variable de entorno OLLAMA_NO_CLOUD.

Si defines OLLAMA_NO_CLOUD=1 (o un valor considerado "truthy" por tu sistema), Ollama no usará los servicios en la nube. Las peticiones a modelos con sufijo :cloud fallarán o no se enviarán a los servidores remotos, según el diseño del cliente. Así te aseguras de que todo el tráfico quede en local.

Ejemplo en Linux/macOS:

export OLLAMA_NO_CLOUD=1
ollama run llama3.2

En Windows (PowerShell):

$env:OLLAMA_NO_CLOUD = "1"
ollama run llama3.2

En la documentación de Ollama se menciona también la opción disable_ollama_cloud en el archivo de configuración del servidor (por ejemplo en ~/.ollama/server.json) para desactivar la nube de forma persistente en esa instalación. Si necesitas una política fija en una máquina, revisa la documentación actual de tu versión para el nombre exacto del parámetro y la ruta del fichero.

Cuándo usar Cloud y cuándo no

Ollama Cloud compensa cuando:

• No tienes hardware suficiente para el modelo que necesitas.
• Quieres probar modelos grandes sin descargarlos.
• Prefieres no gestionar actualizaciones ni servidores.

Mantener todo en local (y usar OLLAMA_NO_CLOUD si hace falta) compensa cuando:

• Los datos no pueden salir de tu red.
• Necesitas trabajar sin conexión a internet.
• La política de tu organización exige que no se use ningún servicio externo para inferencia.

Con una cuenta, ollama signin y, si aplica, una API key, puedes usar modelos en Ollama Cloud añadiendo :cloud al nombre del modelo. Con OLLAMA_NO_CLOUD o la opción equivalente en la configuración del servidor puedes garantizar que solo se use la instalación local.

Llamar a Ollama Cloud desde código

La gran ventaja de Ollama Cloud es que su API es compatible con la API local: cambias la URL base, añades la cabecera Authorization y el resto del código sigue funcionando. En Python con la librería oficial basta con inyectar la clave al crear el cliente:

import os
from ollama import Client

cliente = Client(
    host="https://ollama.com",
    headers={"Authorization": f"Bearer {os.environ['OLLAMA_API_KEY']}"},
)

respuesta = cliente.chat(
    model="llama3.2:cloud",
    messages=[
        {"role": "system", "content": "Respondes en español formal."},
        {"role": "user", "content": "Explica en tres frases qué es un embedding."},
    ],
)

print(respuesta["message"]["content"])

El mismo patrón funciona con curl para pruebas rápidas:

curl https://ollama.com/api/chat \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.2:cloud",
    "messages": [
      {"role": "user", "content": "Dame tres ideas para un proyecto con LLMs."}
    ],
    "stream": false
  }'

La cabecera Authorization es obligatoria: sin ella el servicio responde con 401 Unauthorized. La variable OLLAMA_API_KEY es una convención habitual, pero puedes llamarla como quieras siempre que no la pongas en el código fuente.

Tabla comparativa: modo local, modo cloud y modo híbrido

| Criterio | Solo local | Solo cloud | Híbrido (recomendado) | |----------|-----------|-----------|----------------------| | Privacidad de los datos | Máxima | Depende del proveedor | Máxima para datos sensibles, relajada para los demás | | Requisito de hardware | GPU/RAM según modelo | Ninguno | Mínimo (para modelos pequeños) | | Coste mensual | Solo energía | Según uso | Mixto, pero optimizable | | Velocidad en modelos pequeños | Muy alta | Media | Muy alta | | Velocidad en modelos grandes | Baja si no hay GPU potente | Alta | Alta cuando se delega a cloud | | Funciona sin internet | Sí | No | Parcialmente | | Complejidad de despliegue | Media | Baja | Media |

El patrón híbrido es la opción más versátil: dejas en local los modelos rápidos para los prompts frecuentes y reservas la nube para los modelos grandes que usas de forma puntual.

Buenas prácticas con la API key

• Nunca subas la clave al repositorio: guárdala en un gestor de secretos (1Password, Bitwarden, Vault) o en variables de entorno en CI/CD.
• Rota la clave cada pocos meses y de forma inmediata si sospechas que se ha filtrado.
• Usa claves distintas para desarrollo, staging y producción; así puedes revocar una sin afectar a las otras.
• Limita el alcance de cada clave si el servicio lo permite (por ejemplo, a ciertos modelos o a ciertas IPs).
• Registra las llamadas que haces a Ollama Cloud desde tu backend: te permite detectar picos anómalos y cuadrar la factura.
• Centraliza las llamadas en un único servicio interno en lugar de repartir la clave por todos los microservicios; así controlas el uso y aplicas rate limits.

Errores comunes con Ollama Cloud

• 401 Unauthorized al lanzar el primer curl: casi siempre es un Bearer mal formateado o una variable vacía. Verifica con echo $OLLAMA_API_KEY antes de enviar la petición.
• «El modelo :cloud no está disponible»: puede que tu cuenta no tenga permisos sobre ese modelo o que aún no esté publicado en tu región. Consulta el catálogo vigente en la web de Ollama.
• Latencia muy alta en la primera petición: es normal mientras el servicio «calienta» el modelo en su lado. Las siguientes respuestas serán más rápidas.
• Mezclar :cloud con OLLAMA_NO_CLOUD=1: si activas el bloqueo pero sigues pidiendo modelos con sufijo :cloud, las peticiones fallarán. Ajusta tu código para elegir el modelo según el entorno.
• Dependencia total de la nube: si tu aplicación cae cuando hay un corte en el servicio, no tienes plan de contingencia. Considera caer a un modelo local más pequeño como respaldo.
• Fuga de datos sensibles: revisa los prompts que envías a :cloud; los datos de clientes, tokens o contraseñas no deben salir nunca de tu infraestructura.

Con estas pautas, Ollama Cloud se convierte en una extensión natural del flujo local: el mismo lenguaje, las mismas llamadas y la misma experiencia de desarrollo, con la flexibilidad de elegir caso por caso dónde se ejecuta cada modelo.