Ollama Cloud GPU: Execute um servidor de API remota seguro

Ollama Cloud GPU: Execute um servidor de API remota seguro

Executar um servidor de Ollama cloud GPU dá a você controle direto sobre o modelo, a quantização, o runtime e o caminho dos dados. Isso também traz uma responsabilidade operacional que uma instalação em notebook oculta: a API local do Ollama não é uma fronteira de autenticação voltada ao público. Uma configuração remota segura mantém o Ollama em uma porta de loopback privada e coloca TLS e autenticação de chamadores em um proxy de borda.

Este guia mostra uma implantação prática com NVIDIA/Docker para um servidor de Ollama cloud GPU, uma borda HTTPS com Caddy que aceita um token bearer no estilo OpenAI e uma configuração de cliente remoto. Ele é voltado a desenvolvedores independentes e pequenas equipes de IA que desejam executar um modelo de pesos abertos em capacidade de GPU alugada sem publicar a porta 11434 na internet.

Em resumo: execute o Ollama com a porta do host vinculada a 127.0.0.1, bloqueie o acesso público à porta 11434 no firewall da nuvem e exponha apenas um proxy reverso HTTPS nas portas 80/443. Faça esse proxy validar um token antes de encaminhar o tráfego ao Ollama.

O Ollama documenta 127.0.0.1:11434 como sua vinculação padrão e informa que solicitações de API a um servidor local não exigem autorização. Isso é conveniente para o desenvolvimento local, mas significa que um endpoint simples acessível remotamente é a fronteira de segurança errada. Vale a pena manter abertas as páginas de perguntas frequentes do Ollama e de introdução à API durante a implantação.

O que esta arquitetura de Ollama cloud GPU protege

A arquitetura tem quatro fronteiras, cada uma com uma função distinta:

Remote client / OpenAI SDK
        |
        | HTTPS + Bearer token
        v
Public edge proxy (Caddy, ports 80/443 only)
        |
        | localhost HTTP
        v
Ollama API (127.0.0.1:11434)
        |
        v
GPU runtime and model volume

O proxy de borda é o único componente que aceita tráfego da internet. O Ollama permanece acessível apenas a partir do mesmo host. Isso evita que um erro no firewall da nuvem, um mapeamento Docker aberto acidentalmente ou um chamador não autenticado se transformem em acesso direto ao seu servidor de modelos.

Para um sistema de produção com múltiplos usuários, use uma rede de sobreposição privada ou um proxy com reconhecimento de identidade, com identidades individuais e revogação. O exemplo de token bearer único abaixo é um ponto de partida prático para comunicação servidor a servidor, não um substituto para SSO, trilhas de auditoria por usuário, limites de taxa ou aplicação de políticas.

Antes de alugar uma GPU: dimensione a carga de trabalho, não o download

Uma Ollama cloud GPU é uma escolha sensata quando você precisa controlar os arquivos do modelo, uma quantização específica, um runtime privado ou o uso contínuo de uma família de modelos. Ela não é automaticamente a escolha de menor custo para tráfego irregular ou para um produto que muda de modelo com frequência.

Comece com a tag real do modelo, a quantização, a janela de contexto e o número de solicitações simultâneas. Os pesos do modelo são apenas parte do orçamento de memória: o contexto e as solicitações paralelas consomem VRAM adicional. A documentação do Ollama observa que o processamento de solicitações paralelas aumenta a alocação efetiva de contexto, e a saída de ollama ps mostra se um modelo está totalmente na GPU, totalmente na CPU ou dividido entre ambas. Consulte os guias sobre requisitos de VRAM para modelos Ollama 70B e requisitos de memória de GPU para LLMs antes de se comprometer com uma configuração de GPU.

Como escolher uma nuvem de GPU barata para Ollama em 2026

A consulta “best cheap gpu cloud for ollama 2026” não tem uma única resposta duradoura. Uma GPU barata por hora que força offload para CPU, fica sem margem de contexto ou passa a maior parte do dia ociosa não é barata na prática. Compare os candidatos com a mesma tag de modelo e o mesmo conjunto de prompts e, em seguida, registre:

• tempo de GPU faturado, armazenamento, saída de dados e tempo de configuração;
• tempo de carregamento do modelo e residência na GPU a partir de ollama ps;
• tempo até o primeiro token, latência de ponta a ponta e solicitações com falha;
• a janela de contexto e a simultaneidade realmente suportadas; e
• custo por saída aceita, não apenas custo por hora de GPU.

Use a comparação de nuvens de GPU da Flatkey para avaliar a adequação do provedor e seu guia de preços de aluguel de GPU para evitar deixar de considerar os itens de custo relacionados à própria instância. Faça um piloto curto e repetível antes de reservar capacidade.

Etapa 1: preparar o host NVIDIA

Este guia pressupõe um host Linux com GPU compatível, Docker, um driver NVIDIA e uma instalação do NVIDIA Container Toolkit. Primeiro, confirme que o host detecta sua GPU:

nvidia-smi

Em seguida, configure o runtime NVIDIA do Docker e verifique se um contêiner consegue detectar o mesmo 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

A documentação do Docker do Ollama usa o NVIDIA Container Toolkit e --gpus=all para contêineres com suporte da NVIDIA. Se este comando de validação falhar, pare aqui e corrija a camada de driver/runtime; a solução de problemas do modelo apenas ocultará a causa raiz.

Antes de iniciar o contêiner, configure o firewall da nuvem ou o grupo de segurança:

1. Permita SSH somente a partir de um intervalo de origem aprovado, de um bastion ou de uma rede privada.
2. Permita TCP 80 e 443 somente se este servidor usar um nome de host HTTPS público.
3. Não permita TCP 11434 a partir da internet pública.
4. Se você usar um firewall de host, como o UFW, faça com que suas regras correspondam às do firewall da nuvem, em vez de depender de apenas uma camada.

Etapa 2: executar o Ollama de forma privada no host com GPU

Use um volume nomeado para que os arquivos do modelo sobrevivam à recriação de um contêiner. O endereço de loopback no lado esquerdo de -p é intencional: ele permite que o Caddy na mesma máquina acesse o Ollama, enquanto impede uma conexão externa direta ao serviço.

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>

Substitua <verified-ollama-tag> pela tag de lançamento que sua equipe testou; não promova silenciosamente um serviço de produção ao baixar uma imagem não revisada no momento da reinicialização. O Ollama também oferece suporte a uma instalação Linux nativa e a um serviço systemd, mas o mesmo limite se aplica: mantenha a associação ao loopback e coloque o acesso remoto atrás de um proxy autenticado. O guia oficial para Linux documenta tanto o fluxo de trabalho do serviço quanto seu mecanismo de substituição por variáveis de ambiente.

Baixe um modelo de teste pequeno que caiba na GPU selecionada. Este exemplo usa uma tag atual dos exemplos de compatibilidade com OpenAI do Ollama; substitua pelo modelo e pela quantização exatos que você pretende disponibilizar.

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 é uma verificação de aceitação útil para uma implantação de GPU em nuvem do Ollama. Uma indicação de processador 100% GPU significa que o modelo carregado está inteiramente na GPU; uma divisão entre CPU/GPU pode ser aceitável para um teste, mas indica que você deve medir a compensação entre latência e memória antes da produção.

Etapa 3: adicionar uma borda de API HTTPS com um token de portador

O Ollama pode expor sua API por meio de um proxy e fornece tanto sua interface nativa /api quanto uma interface local compatível com OpenAI em /v1. Seus exemplos locais de cliente OpenAI usam um valor de chave de API que o Ollama ignora, e é exatamente por isso que o proxy abaixo realiza a verificação de autorização antes de encaminhar o tráfego. A documentação de compatibilidade com OpenAI do Ollama também deixa claro que a compatibilidade é parcial; portanto, planeje um teste de integração real, em vez de fazer uma suposição generalizada.

Este padrão do Caddy permite que um cliente no estilo OpenAI use Authorization: Bearer <token>. O Caddy valida esse cabeçalho, remove-o antes que a solicitação chegue ao serviço local e encaminha a solicitação pelo loopback.

Primeiro, gere um token de alta entropia e salve-o no gerenciador de segredos da sua equipe. Não o coloque no controle de código-fonte nem em um histórico de shell que você não controla.

openssl rand -hex 32

Crie uma substituição systemd para o Caddy e defina o valor gerado como OLLAMA_API_TOKEN:

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

Em seguida, configure /etc/caddy/Caddyfile com um nome de host cujo DNS aponte para o 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 um nome DNS real no lugar de ollama.example.com. O Caddy trata um endereço de site de domínio como um site HTTPS com um certificado gerenciado; verifique se o DNS e as portas de entrada pretendidas estão prontos antes de recarregá-lo. O correspondente de solicitações do Caddy, os blocos handle mutuamente exclusivos e os controles de cabeçalho do proxy reverso documentam as diretivas usadas acima.

Valide e recarregue a configuração:

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

Teste ambos os lados do limite. A primeira solicitação deve ser bem-sucedida a partir do host. A segunda deve ser bem-sucedida por TLS somente quando o token estiver correto. Uma terceira solicitação sem ele deve retornar 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

Não substitua a autenticação básica por esse padrão exato de cliente sem alterar o design do cliente. O HTTP Basic e os SDKs da OpenAI usam o cabeçalho Authorization. A borda com token bearer acima preserva a estrutura usual do SDK da OpenAI e mantém o endpoint local do Ollama privado.

Etapa 4: chame a API remota do Ollama a partir de um cliente OpenAI

O Ollama documenta http://localhost:11434/v1 como sua URL base local compatível com OpenAI. Com a borda HTTPS instalada, altere apenas o host e use o token do proxy como a chave de API do 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 é uma API remota de GPU em nuvem do Ollama, mas não é automaticamente uma substituição direta para todos os recursos da OpenAI. Antes de mover tráfego de produção, teste os endpoints e comportamentos exatos que seu aplicativo usa: streaming, chamadas de ferramentas, saídas estruturadas, embeddings, entradas de visão, tratamento de erros, limites de contexto e tempos limite do cliente. O próprio modelo também determina o que é significativo ou compatível.

Etapa 5: ajuste deliberadamente a simultaneidade e a residência do modelo

Evite aumentar o paralelismo porque um servidor está ocioso durante um único teste com curl. O Ollama documenta uma janela de contexto padrão de 4096 tokens, uma configuração de fila de solicitações e o processamento paralelo de modelos dependente da memória. Cada solicitação paralela adicional aumenta a alocação efetiva de contexto; portanto, uma GPU em nuvem do Ollama que comporta uma solicitação ainda pode falhar sob tráfego simultâneo.

Use esta ordem de implantação controlada:

1. Carregue um modelo na quantização pretendida e execute um conjunto de prompts representativo.
2. Registre VRAM, latência e residência na GPU com nvidia-smi e ollama ps.
3. Aumente o comprimento do contexto ou as solicitações paralelas, um de cada vez.
4. Defina uma política explícita de sobrecarga: enfileirar, rejeitar ou encaminhar para uma alternativa.
5. Repita após cada alteração de modelo, driver, runtime ou janela de contexto.

As perguntas frequentes do Ollama documentam OLLAMA_CONTEXT_LENGTH, OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE e OLLAMA_KEEP_ALIVE. Elas também observam que respostas 503 podem indicar uma fila sobrecarregada. Mantenha um runbook para esses sinais, em vez de tratá-los como falhas aleatórias de API.

Para um padrão mais geral de servidor auto-hospedado, veja como criar um servidor de inferência compatível com OpenAI. Esse guia aborda questões mais amplas de borda, fallback e testes de aceitação; este artigo permanece focado em um fluxo de trabalho remoto seguro com Ollama.

Quando não executar um servidor Ollama em GPU na nuvem

A auto-hospedagem é valiosa quando a própria infraestrutura faz parte do requisito do produto. Ela é menos atraente quando o objetivo é simplesmente chamar o melhor modelo disponível para uma carga de trabalho variável. Considere uma API de modelo gerenciada ou um fallback híbrido quando:

• o tráfego é irregular e a GPU ficará ociosa;
• você precisa de várias famílias de modelos ou de mudanças frequentes de modelo;
• sua equipe não consegue manter drivers, volumes de modelos, TLS, rotação de tokens, observabilidade e resposta a incidentes; ou
• o caminho com GPU tem um custo por saída aceita maior depois de considerar novas tentativas e o tempo dos operadores.

O Flatkey pode servir como esse caminho de comparação ou fallback: uma chave e um saldo para mais de 300 modelos oficiais e mais de 1.000 ferramentas de pagamento por chamada. Mantenha o cliente em um formato compatível com OpenAI e meça a rota auto-hospedada em relação a uma alternativa gerenciada usando os mesmos prompts, critérios de sucesso e política de timeout.

Checklist de produção para uma GPU Ollama na nuvem

• [ ] A GPU está visível tanto por meio de nvidia-smi quanto de um teste de GPU do Docker.
• [ ] A porta Docker do Ollama está mapeada apenas para 127.0.0.1:11434.
• [ ] A porta 11434 não é pública no firewall da nuvem nem no firewall do host.
• [ ] O proxy fornece HTTPS em um nome de host real e rejeita solicitações sem token.
• [ ] O token bearer é armazenado fora da base de código e tem um processo de rotação documentado.
• [ ] Uma solicitação remota para /api/chat é bem-sucedida com o token e falha sem ele.
• [ ] Um teste remoto de /v1/chat/completions é bem-sucedido a partir do SDK real usado pelo seu app.
• [ ] A tag exata do modelo, a quantização, a janela de contexto e a meta de concorrência estão documentadas.
• [ ] ollama ps, a telemetria da GPU, os logs do proxy e as taxas de 5xx fazem parte do runbook.
• [ ] Você testou cenários de sobrecarga, reinicialização e rotação de token.
• [ ] Você comparou a rota de GPU Ollama na nuvem com uma referência de API gerenciada quando a flexibilidade ou a disponibilidade do modelo é importante.

Perguntas frequentes

O Ollama autentica uma API remota por conta própria?

Não dependa da API local para autenticação remota. Os exemplos de servidor local do Ollama omitem a autorização ou usam um valor de chave de API que o servidor local ignora. Mantenha o serviço privado e exija autenticação em um proxy TLS, limite de rede privada ou gateway com reconhecimento de identidade.

Posso usar um SDK da OpenAI com uma GPU Ollama na nuvem?

Sim, o Ollama documenta uma URL base local /v1 compatível com OpenAI e exemplos de clientes comuns. Aponte o SDK para o caminho /v1/ do seu proxy HTTPS e deixe que esse proxy valide o token bearer. Teste os endpoints exatos que você usa, pois a compatibilidade é um subconjunto, e não uma garantia incondicional.

Qual é a melhor nuvem de GPU barata para Ollama em 2026?

A melhor nuvem de GPU barata para Ollama em 2026 é aquela que comporta seu modelo, contexto e concorrência reais sem tempo ocioso oculto ou descarregamento para CPU. Execute o mesmo benchmark curto em alguns candidatos e compare o custo por saída aceita, não a tarifa horária anunciada pelo provedor.

Por que meu contêiner Ollama é executado na CPU em vez da GPU?

Comece verificando o host com nvidia-smi, depois confirme que o Docker consegue ver a GPU após a configuração do NVIDIA Container Toolkit. Por fim, inspecione ollama ps: um modelo pode estar parcial ou totalmente na CPU quando não cabe na memória de GPU disponível.

Devo expor a porta 11434 diretamente para economizar um salto de proxy?

Não. O pequeno salto local pelo proxy é uma troca adequada por TLS, autenticação de chamadores, rotação de segredos e um limite público explícito. Expor um servidor de modelo local sem proteção transforma um atalho de infraestrutura em um risco desnecessário de segurança e abuso.

Recomendação final

A forma confiável de executar um servidor de GPU na nuvem com Ollama é simples: valide o runtime da GPU, vincule o Ollama ao loopback, use um proxy HTTPS com verificação de token bearer e teste chamadas nativas para /api e compatíveis com OpenAI para /v1 a partir do cliente que você realmente vai lançar.

Isso oferece o controle de um modelo auto-hospedado sem transformar um endpoint local não autenticado na sua API pública. Meça a adequação do modelo, o contexto, a simultaneidade e o custo por saída aceita antes de expandir o servidor — e mantenha uma referência de API gerenciada para as cargas de trabalho em que operar sua própria GPU acrescenta mais complexidade do que valor.

Fontes

• Instalação do Ollama no Linux e orientações sobre systemd
• Implantação do Ollama com Docker e GPU NVIDIA
• FAQ do Ollama: exposição de rede, residência na GPU, contexto, fila e simultaneidade
• Introdução à API do Ollama e URLs base locais
• Compatibilidade do Ollama com OpenAI
• Correspondências de cabeçalho do Caddy, blocos handle e configuração de proxy reverso