Ollama Cloud GPU: ejecuta un servidor API remoto seguro

Ollama Cloud GPU: ejecuta un servidor API remoto seguro

Ejecutar un servidor de Ollama cloud GPU te da control directo sobre el modelo, la cuantización, el tiempo de ejecución y la ruta de datos. También te asigna una responsabilidad operativa que una instalación en un portátil oculta: la API local de Ollama no es una frontera de autenticación orientada al público. Una configuración remota segura mantiene Ollama en un puerto de bucle local privado y coloca TLS más autenticación del llamante en un proxy perimetral.

Esta guía muestra una implementación práctica con NVIDIA/Docker para un servidor de Ollama cloud GPU, un perímetro HTTPS de Caddy que acepta un token bearer de estilo OpenAI y una configuración de cliente remoto. Está dirigida a desarrolladores independientes y pequeños equipos de IA que quieren ejecutar un modelo de pesos abiertos en capacidad de GPU alquilada sin publicar el puerto 11434 en internet.

La versión corta: ejecuta Ollama con su puerto de host vinculado a 127.0.0.1, bloquea el acceso público al puerto 11434 en el firewall de la nube y expón solo un proxy inverso HTTPS en los puertos 80/443. Haz que ese proxy valide un token antes de reenviar el tráfico a Ollama.

Ollama documenta 127.0.0.1:11434 como su enlace predeterminado e indica que las solicitudes a la API de un servidor local no requieren autorización. Esto es conveniente para el desarrollo local, pero significa que un endpoint básico accesible de forma remota es una frontera de seguridad incorrecta. Conviene tener abiertas las preguntas frecuentes de Ollama y la introducción a la API mientras realizas la implementación.

Qué protege esta arquitectura de Ollama cloud GPU

La arquitectura tiene cuatro fronteras, cada una con una función distinta:

Cliente remoto / SDK de OpenAI
        |
        | HTTPS + token Bearer
        v
Proxy perimetral público (Caddy, solo puertos 80/443)
        |
        | HTTP de localhost
        v
API de Ollama (127.0.0.1:11434)
        |
        v
Tiempo de ejecución de GPU y volumen del modelo

El proxy perimetral es el único componente que acepta tráfico de internet. Ollama sigue siendo accesible solo desde el mismo host. Esto evita que un error en el firewall de la nube, una asignación de Docker abierta accidentalmente o un llamante sin autenticar se conviertan en acceso directo a tu servidor de modelos.

Para un sistema de producción con varios usuarios, utiliza una red superpuesta privada o un proxy con reconocimiento de identidad, identidades individuales y revocación. El ejemplo de token bearer único que aparece a continuación es un punto de partida práctico para servidor a servidor, no un sustituto de SSO, registros de auditoría por usuario, límites de tasa ni aplicación de políticas.

Antes de alquilar una GPU: dimensiona la carga de trabajo, no la descarga

Una Ollama cloud GPU es una opción sensata cuando necesitas controlar los archivos del modelo, una cuantización específica, un tiempo de ejecución privado o el uso sostenido de una familia de modelos. No es automáticamente la opción de menor coste para tráfico irregular o un producto que cambia de modelo con frecuencia.

Empieza con la etiqueta real del modelo, la cuantización, la ventana de contexto y el número de solicitudes simultáneas. Los pesos del modelo son solo una parte del presupuesto de memoria: el contexto y las solicitudes paralelas consumen VRAM adicional. La documentación de Ollama señala que el procesamiento de solicitudes en paralelo incrementa la asignación efectiva de contexto, y su salida de ollama ps muestra si un modelo está completamente en la GPU, completamente en la CPU o dividido entre ambas. Consulta las guías sobre requisitos de VRAM de modelos Ollama 70B y requisitos de memoria GPU para LLM antes de comprometerte con una configuración de GPU.

Cómo elegir una nube de GPU económica para Ollama en 2026

La consulta “mejor nube de GPU barata para Ollama en 2026” no tiene una única respuesta duradera. Una GPU barata por hora que obliga a descargar trabajo en la CPU, se queda sin margen de contexto o pasa la mayor parte del día inactiva no es barata en la práctica. Compara candidatos con la misma etiqueta de modelo y conjunto de prompts, y luego registra:

• tiempo de GPU facturado, almacenamiento, salida de datos y tiempo de configuración;
• tiempo de carga del modelo y permanencia en la GPU según ollama ps;
• tiempo hasta el primer token, latencia de extremo a extremo y solicitudes fallidas;
• la ventana de contexto y la concurrencia realmente admitidas; y
• coste por salida aceptada, no solo coste por hora de GPU.

Usa la comparativa de nubes GPU de Flatkey para evaluar la adecuación del proveedor, y su guía de precios de alquiler de GPU para no pasar por alto los costes asociados a la instancia. Realiza un piloto breve y repetible antes de reservar capacidad.

Paso 1: prepara el host NVIDIA

Este procedimiento supone que dispones de un host Linux con GPU compatible, Docker, un controlador NVIDIA y una instalación de NVIDIA Container Toolkit. Confirma primero que el host detecta su GPU:

nvidia-smi

A continuación, configura el runtime NVIDIA de Docker y verifica que un contenedor pueda ver el mismo dispositivo:

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Example CUDA image; use a tag compatible with your host driver and OS.
docker run --rm --gpus all \
  nvidia/cuda:12.6.0-base-ubuntu22.04 nvidia-smi

La documentación de Docker de Ollama utiliza NVIDIA Container Toolkit y --gpus=all para los contenedores respaldados por NVIDIA. Si este comando de validación falla, detente aquí y corrige la capa del controlador/runtime; solucionar problemas del modelo solo ocultará la causa raíz.

Antes de iniciar el contenedor, configura el firewall de la nube o el grupo de seguridad:

1. Permite SSH únicamente desde un rango de origen aprobado, un bastión o una red privada.
2. Permite TCP 80 y 443 solo si este servidor utilizará un nombre de host HTTPS público.
3. No permitas TCP 11434 desde Internet pública.
4. Si utilizas un firewall del host, como UFW, haz que sus reglas coincidan con las del firewall de la nube en lugar de depender de una sola capa.

Paso 2: ejecuta Ollama de forma privada en el host GPU

Utiliza un volumen con nombre para que los archivos de los modelos sobrevivan a la recreación del contenedor. La dirección de loopback situada a la izquierda de -p es intencionada: permite que Caddy, en la misma máquina, acceda a Ollama, al tiempo que impide una conexión externa directa al servicio.

docker pull ollama/ollama:<verified-ollama-tag>

docker run -d \
  --name ollama \
  --restart unless-stopped \
  --gpus all \
  -v ollama:/root/.ollama \
  -p 127.0.0.1:11434:11434 \
  ollama/ollama:<verified-ollama-tag>

Sustituye <verified-ollama-tag> por la etiqueta de versión que tu equipo haya probado; no promociones silenciosamente un servicio de producción extrayendo una imagen no revisada al reiniciarse. Ollama también admite una instalación nativa en Linux y un servicio systemd, pero se aplica el mismo límite: conserva el enlace de loopback y coloca el acceso remoto detrás de un proxy autenticado. La guía oficial de Linux documenta tanto el flujo de trabajo del servicio como su mecanismo de sustitución mediante variables de entorno.

Descarga un modelo de prueba pequeño que quepa en la GPU seleccionada. Este ejemplo utiliza una etiqueta actual de los ejemplos de compatibilidad con OpenAI de Ollama; sustituye el modelo y la cuantización exactos que pretendas servir.

docker exec ollama ollama pull qwen3:8b

curl -sS http://127.0.0.1:11434/api/chat \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen3:8b",
    "messages": [{"role": "user", "content": "Reply with a three-word GPU health check."}],
    "stream": false
  }'

docker exec ollama ollama ps

ollama ps es una comprobación de aceptación útil para una implementación de Ollama cloud GPU. Una indicación de procesador 100% GPU significa que el modelo cargado está completamente en la GPU; una división entre CPU y GPU puede ser aceptable para una prueba, pero es una señal para medir el equilibrio entre latencia y memoria antes de pasar a producción.

Paso 3: añade un extremo de API HTTPS con un token bearer

Ollama puede exponer su API a través de un proxy y proporciona tanto su superficie nativa /api como una superficie local compatible con OpenAI, /v1. Sus ejemplos de clientes OpenAI locales utilizan un valor de clave de API que Ollama ignora, precisamente por lo que el proxy siguiente realiza la comprobación de autorización antes de reenviar el tráfico. La documentación de compatibilidad con OpenAI de Ollama también deja claro que la compatibilidad es un subconjunto, así que planifica una prueba de integración real en lugar de asumirla de forma generalizada.

Este patrón de Caddy permite que un cliente de estilo OpenAI utilice Authorization: Bearer <token>. Caddy valida esa cabecera, la elimina antes de que la solicitud llegue al servicio local y sirve de proxy para la solicitud a través de loopback.

Primero genera un token de alta entropía y guárdalo en el gestor de secretos de tu equipo. No lo guardes en el control de código fuente ni en un historial de shell que no controles.

openssl rand -hex 32

Crea una anulación de systemd para Caddy y establece el valor generado como OLLAMA_API_TOKEN:

# sudo systemctl edit caddy
[Service]
Environment="OLLAMA_API_TOKEN=replace-with-your-secret-manager-value"

A continuación, configura /etc/caddy/Caddyfile con un nombre de host cuyo DNS apunte al servidor:

ollama.example.com {
    @authorized {
        header Authorization "Bearer {$OLLAMA_API_TOKEN}"
    }

    handle @authorized {
        reverse_proxy 127.0.0.1:11434 {
            # The edge checked this header; Ollama does not need the token.
            header_up -Authorization
        }
    }

    handle {
        respond "Unauthorized" 401
    }
}

Use un nombre DNS real en lugar de ollama.example.com. Caddy trata una dirección de sitio de dominio como un sitio HTTPS con un certificado gestionado; asegúrese de que el DNS y los puertos de entrada previstos estén listos antes de recargarlo. El selector de solicitudes de Caddy, los bloques handle mutuamente excluyentes y los controles de encabezados del proxy inverso documentan las directivas utilizadas anteriormente.

Valide y recargue la configuración:

sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl daemon-reload
sudo systemctl reload caddy

Pruebe ambos lados del límite. La primera solicitud debe completarse correctamente desde el host. La segunda debe completarse correctamente mediante TLS solo cuando el token sea correcto. Una tercera solicitud sin él debería devolver 401.

# Host-local health check
curl -sS http://127.0.0.1:11434/api/chat \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3:8b","messages":[{"role":"user","content":"health check"}],"stream":false}'

# Remote request through the edge
curl -sS https://ollama.example.com/api/chat \
  -H "Authorization: Bearer $OLLAMA_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3:8b","messages":[{"role":"user","content":"health check"}],"stream":false}'

# Expected: HTTP 401
curl -i https://ollama.example.com/api/chat

No sustituya la autenticación básica para este patrón de cliente exacto sin cambiar el diseño del cliente. Tanto HTTP Basic como los SDK de OpenAI usan el encabezado Authorization. El perímetro con token de portador anterior conserva la estructura habitual del SDK de OpenAI y mantiene privado el endpoint local de Ollama.

Paso 4: llame a la API remota de Ollama desde un cliente de OpenAI

Ollama documenta http://localhost:11434/v1 como su URL base local compatible con OpenAI. Con el perímetro HTTPS configurado, cambie solo el host y use el token del proxy como clave de API del cliente:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://ollama.example.com/v1/",
    api_key=os.environ["OLLAMA_API_TOKEN"],
)

response = client.chat.completions.create(
    model="qwen3:8b",
    messages=[
        {"role": "user", "content": "Give me a concise deployment checklist."}
    ],
)

print(response.choices[0].message.content)

Esta es una API remota de GPU en la nube de Ollama, pero no es automáticamente un reemplazo directo para todas las funciones de OpenAI. Antes de trasladar tráfico de producción, pruebe los endpoints y comportamientos exactos que utiliza su aplicación: streaming, llamadas a herramientas, salidas estructuradas, embeddings, entradas de visión, gestión de errores, límites de contexto y tiempos de espera del cliente. El propio modelo también determina qué es significativo o compatible.

Paso 5: ajuste la concurrencia y la residencia del modelo de forma deliberada

Evite aumentar el paralelismo porque un servidor esté inactivo durante una única prueba con curl. Ollama documenta una ventana de contexto predeterminada de 4096 tokens, una configuración de cola de solicitudes y un manejo de modelos paralelos que depende de la memoria. Cada solicitud paralela añadida aumenta la asignación efectiva de contexto, por lo que una GPU en la nube de Ollama que admite una solicitud aún puede fallar con tráfico concurrente.

Use este orden de despliegue controlado:

1. Cargue un modelo con la cuantización prevista y ejecute un conjunto de prompts representativos.
2. Registre la VRAM, la latencia y la residencia en la GPU con nvidia-smi y ollama ps.
3. Aumente la longitud de contexto o las solicitudes paralelas de una en una.
4. Establezca una política explícita de sobrecarga: encolar, rechazar o enrutar a una alternativa.
5. Repita el proceso después de cada cambio de modelo, controlador, tiempo de ejecución o ventana de contexto.

Las preguntas frecuentes de Ollama documentan OLLAMA_CONTEXT_LENGTH, OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE y OLLAMA_KEEP_ALIVE. También indican que las respuestas 503 pueden señalar una cola sobrecargada. Mantenga un manual operativo para esas señales en lugar de tratarlas como fallos aleatorios de la API.

Para un patrón más general de servidor autoalojado, consulta cómo crear un servidor de inferencia compatible con OpenAI. Esa guía cubre aspectos más amplios de perímetro, respaldo y pruebas de aceptación; este artículo se centra en un flujo de trabajo remoto seguro con Ollama.

Cuándo no ejecutar un servidor Ollama en una GPU en la nube

El autoalojamiento es valioso cuando la propia infraestructura forma parte del requisito del producto. Es menos convincente cuando el objetivo es simplemente llamar al mejor modelo disponible para una carga de trabajo cambiante. Considera una API de modelos gestionada o un respaldo híbrido cuando:

• el tráfico es irregular y la GPU permanecerá inactiva;
• necesitas varias familias de modelos o cambios frecuentes de modelo;
• tu equipo no puede mantener controladores, volúmenes de modelos, TLS, rotación de tokens, observabilidad y respuesta a incidentes; o
• la ruta de la GPU tiene un peor coste por salida aceptada una vez que se incluyen los reintentos y el tiempo de los operadores.

Flatkey puede servir como esa ruta de comparación o respaldo: una clave y un saldo para más de 300 modelos oficiales y más de 1000 herramientas de pago por llamada. Mantén el cliente con una interfaz compatible con OpenAI y mide la ruta autoalojada frente a una alternativa gestionada usando los mismos prompts, criterios de éxito y política de tiempo de espera.

Lista de verificación de producción para una GPU en la nube con Ollama

• [ ] La GPU es visible tanto mediante nvidia-smi como mediante una prueba de GPU de Docker.
• [ ] El puerto Docker de Ollama está asignado solo a 127.0.0.1:11434.
• [ ] El puerto 11434 no es público en el firewall de la nube ni en el firewall del host.
• [ ] El proxy sirve HTTPS en un nombre de host real y rechaza las solicitudes sin token.
• [ ] El token bearer se almacena fuera del código base y cuenta con un proceso de rotación documentado.
• [ ] Una solicitud remota a /api/chat tiene éxito con el token y falla sin él.
• [ ] Una prueba remota de /v1/chat/completions tiene éxito desde el SDK real que usa tu aplicación.
• [ ] La etiqueta exacta del modelo, la cuantización, la ventana de contexto y el objetivo de concurrencia están documentados.
• [ ] ollama ps, la telemetría de GPU, los registros del proxy y las tasas de 5xx forman parte del manual operativo.
• [ ] Has probado un escenario de sobrecarga, reinicio y rotación de tokens.
• [ ] Has comparado la ruta de Ollama cloud GPU con una referencia de API gestionada cuando importan la flexibilidad o la disponibilidad del modelo.

Preguntas frecuentes

¿Ollama autentica por sí solo una API remota?

No dependas de la API local para la autenticación remota. Los ejemplos de servidor local de Ollama omiten la autorización o usan un valor de clave API que el servidor local ignora. Mantén el servicio privado y exige autenticación en un proxy TLS, un límite de red privada o una puerta de enlace con reconocimiento de identidad.

¿Puedo usar un SDK de OpenAI con una GPU en la nube de Ollama?

Sí, Ollama documenta una URL base local /v1 compatible con OpenAI y ejemplos de clientes comunes. Dirige el SDK a la ruta /v1/ de tu proxy HTTPS y deja que ese proxy valide el token bearer. Prueba los endpoints exactos que utilizas porque la compatibilidad es un subconjunto y no una garantía incondicional.

¿Cuál es la mejor nube de GPU económica para Ollama en 2026?

La mejor nube de GPU económica para Ollama en 2026 es la que se ajusta a tu modelo, contexto y concurrencia reales sin tiempo de inactividad oculto ni descarga a CPU. Ejecuta el mismo benchmark breve en varios candidatos y compara el coste por salida aceptada, no la tarifa horaria destacada de un proveedor.

¿Por qué mi contenedor de Ollama se ejecuta en CPU en lugar de GPU?

Empieza comprobando el host con nvidia-smi, luego confirma que Docker puede ver la GPU después de configurar NVIDIA Container Toolkit. Por último, inspecciona ollama ps: un modelo puede estar parcial o totalmente en la CPU cuando no cabe en la memoria de GPU disponible.

¿Debo exponer el puerto 11434 directamente para ahorrar un salto de proxy?

No. El pequeño salto de proxy local es una buena contrapartida para TLS, autenticación de llamantes, rotación de secretos y un límite público explícito. Exponer un servidor de modelos local sin protección convierte un atajo de infraestructura en un riesgo innecesario de seguridad y abuso.

Recomendación final

La forma fiable de ejecutar un servidor de GPU en la nube de Ollama es sencilla: valida el entorno de ejecución de la GPU, vincula Ollama a loopback, usa un proxy HTTPS con una comprobación de token de portador y prueba tanto las llamadas nativas /api como las compatibles con OpenAI /v1 desde el cliente que realmente vas a lanzar.

Eso te ofrece el control de un modelo autoalojado sin convertir un endpoint local no autenticado en tu API pública. Mide la adecuación del modelo, el contexto, la concurrencia y el coste de salida aceptada antes de ampliar el servidor, y mantén una referencia de API gestionada para las cargas de trabajo en las que operar tu propia GPU añade más complejidad que valor.

Fuentes

• Guía de instalación de Ollama en Linux y systemd
• Despliegue de Ollama Docker y GPU NVIDIA
• Preguntas frecuentes de Ollama: exposición de red, residencia en GPU, contexto, cola y concurrencia
• Introducción a la API de Ollama y URL base locales
• Compatibilidad de Ollama con OpenAI
• Comparadores de encabezados de Caddy, bloques handle y configuración de proxy inverso