Ollama Cloud: local y nube híbridas
¿La VRAM local no alcanza y quieres usar modelos masivos de cientos de B de parámetros? Ollama Cloud ofrece una tercera opción: el modelo se ejecuta en GPU en la nube, pero tu código y cadena de herramientas no notan ningún cambio.
Este capítulo presenta el modo de ejecución de los modelos Cloud, la conexión directa a la API, el modo puramente local y el mecanismo de retiro; al final ofrece una estrategia de selección para el uso híbrido.
Qué es el modelo Cloud
Los modelos Cloud son un nuevo tipo de modelo en Ollama: los pesos se almacenan en la nube de Ollama, la inferencia se realiza en el clúster de GPU oficial, y el lado local solo se encarga de reenviar las solicitudes.
El punto de dolor que resuelve es muy concreto: los modelos insignia de código abierto de cientos de B suelen requerir cientos de GB de VRAM, por lo que es imposible para individuos y pequeños equipos implementarlos localmente, aunque la necesidad de usarlos es real.
Los modelos Cloud disponibles llevan la etiqueta cloud en la biblioteca de modelos. Tomando como ejemplo la familia qwen3.5, la especificación insignia es qwen3.5:cloud.
Cuatro formas de ejecutar modelos Cloud
Primero realiza una preparación única: regístrate e inicia sesión en tu cuenta de Ollama, y luego descarga la etiqueta cloud (es solo un "puntero", no descarga los pesos).
Usa la cuenta de Ollama para iniciar sesión (necesaria para los modelos Cloud):
ollama signin
En la ventana de inicio de sesión que se abre en el navegador, introduce tu correo electrónico (si luego se necesita verificación por teléfono móvil, basta con un teléfono móvil nacional):
Descargar la etiqueta cloud se completa casi al instante:
ollama pull qwen3.5:cloud
La ejecución es una experiencia exactamente igual a la de los modelos locales:
ollama run qwen3.5:cloud
En la interfaz puede verse un icono de nube:
Llamada con Python
Ejemplo
# La única diferencia con el modelo local: el nombre del modelo lleva :cloud
stream = chat(
model='qwen3.5:cloud',
messages=[{'role': 'user', 'content': 'Presenta en una frase el tutorial para novatos de EJEMPLO'}],
stream=True,
)
for chunk in stream:
print(chunk.message.content, end='', flush=True)
Llamada con JavaScript
Ejemplo
const response = await ollama.chat({
model: 'qwen3.5:cloud',
messages: [{ role: 'user', content: 'Presenta en una frase el tutorial para novatos de EJEMPLO' }],
stream: true,
})
for await (const chunk of response) {
process.stdout.write(chunk.message.content)
}
Llamada con curl
Ejemplo
"model": "qwen3.5:cloud",
Presenta el tutorial para novatos de EJEMPLO en una frase.
"stream": false
}'
Reenvío transparente: la API local también puede llamar a modelos Cloud
Lo elegante de Cloud es que la lógica de reenvío está completamente gestionada por el servicio local.
Al solicitar un modelo :cloud en localhost:11434, el servicio local completa automáticamente la autenticación y el reenvío a la nube, y tu código de aplicación, herramientas de agente e integraciones de editor no notan nada.
Esto significa que las integraciones existentes pueden disfrutar inmediatamente de la capacidad de los modelos grandes: cambia el nombre del modelo de Claude Code a qwen3.5:cloud y la misma cadena de herramientas cambiará a la especificación insignia.
Actualmente hay un límite de capacidad conocido: los modelos Cloud no admiten por el momento salida estructurada (parámetro format); las tareas que requieren restricciones de JSON Schema deben asignarse a modelos locales, o analizarse en la capa de aplicación.
Conexión directa a ollama.com/api
Además del reenvío a través del servicio local, también puedes omitir el entorno local y llamar directamente a la API en la nube, adecuado para escenarios donde el servidor no tiene Ollama instalado.
Primero crea una API Key en la página de configuración del sitio oficial y luego pásala en el encabezado mediante Bearer:
Ejemplo
curl https://ollama.com/api/chat \
-H "Authorization: Bearer $OLLAMA_API_KEY" \
-d '{
"model": "qwen3.5",
Presenta el tutorial para novatos de EJEMPLO en una frase.
"stream": false
}'
# La nube también puede enumerar los modelos disponibles
curl https://ollama.com/api/tags
El SDK oficial también admite especificar el host y el encabezado de autenticación. Para la forma de conexión, consulta el ejemplo Client(host=...) en el capítulo de integración mediante programación; solo cambia el host a https://ollama.com.
La API Key no expira por ahora, pero puedes revocarla en cualquier momento desde la página de configuración del sitio oficial; equivale a tu credencial de uso en la nube, así que no la subas al repositorio de código.
Modo puramente local: apagar completamente la nube
Los equipos con tolerancia cero a que los datos salgan del dominio pueden desactivar por completo las funciones en la nube de Ollama, convirtiéndolo en un software puramente local.
Puedes elegir cualquiera de las dos formas de desactivación; tras el cambio, reinicia Ollama para que surta efecto:
Ejemplo
# { "disable_ollama_cloud": true }
# Forma 2: variable de entorno
OLLAMA_NO_CLOUD=1 ollama serve
# Después de aplicar el cambio, aparecerá en el registro: Ollama cloud disabled: true
Al desactivar las funciones en la nube, se pierden los modelos Cloud y la capacidad de búsqueda en línea, pero todas las funciones de los modelos locales no se ven afectadas. Combinado con el bloqueo del tráfico saliente mediante un cortafuegos, se puede construir un servicio de modelos completamente aislado físicamente.
Mecanismo de retiro de los modelos Cloud
Los modelos Cloud tienen un ciclo de vida: conforme se publican modelos de código abierto más potentes, el equipo oficial retira periódicamente los modelos Cloud antiguos y lo notifica con antelación por correo electrónico y anuncios en el sitio oficial, ofreciendo además una alternativa recomendada.
El anuncio oficial consiste en una tabla de asignación "fecha de retiro - modelo - alternativa recomendada"; por ejemplo, un modelo Cloud se dará de baja en cierta fecha o migrará a una nueva versión; solo tienes que cambiar el nombre del modelo en consecuencia.
Dos recomendaciones de ingeniería:
Primero, al hacer referencia a modelos Cloud en flujos automatizados, convierta el nombre del modelo en un elemento de configuración en lugar de escribirlo directamente en el código; al cambiar por retiro, solo hay que modificar la configuración.
Segundo, para servicios críticos prepare un modelo local alternativo con la misma capacidad, de modo que pueda degradarse de inmediato cuando un modelo Cloud se retire o haya anomalías de red.
El retiro solo afecta a los modelos Cloud: los pesos descargados localmente siempre estarán disponibles, por eso este tutorial siempre enfatiza la ruta principal local.
Estrategia de selección: cuándo usar cada uno
| Escenario | Solución recomendada | Motivo |
|---|---|---|
| Tareas diarias que caben en la VRAM | Modelo local | Cero coste, cero latencia, los datos no salen del dispositivo |
| Datos sensibles | Modelo local (o modo puramente local) | Cumplimiento y control |
| Necesidad de modelos extragrandes / Sin GPU | Modelo Cloud | Sin inversión en hardware, cadena de herramientas sin cambios |
| Probar modelos nuevos | Probar primero con Cloud, confirmar el valor y luego implementar localmente | Evita comprar hardware solo para probar |
| Flujos de automatización a largo plazo | Local como principal + nube de respaldo | La nube tiene mecanismo de retiro; el modelo local no tiene ese riesgo |
La mejor práctica de la arquitectura híbrida en una frase: el tráfico diario va a local, para tareas pesadas usa :cloud según demanda, y pon todos los nombres de modelos en el archivo de configuración.
Otras extensiones