Publicado em Deixe um comentário

Executando um Servidor Ollama em um VPS sem GPU: Seu Próprio Assistente de IA sem Pagar Caro por Hardware

AI on a low-end VPS.

Divulgação: Este site pode conter links afiliados. Se você fizer uma compra por meio desses links, poderei receber uma comissão sem nenhum custo adicional para você. No entanto, todas as opiniões são minhas.

Este guia prático é voltado para microempresas, proprietários de pequenas lojas virtuais, webmasters e estudantes — qualquer pessoa que controle seu orçamento e não esteja disposta a gastar centenas de euros em infraestrutura excessiva.

Vamos alinhar as expectativas desde já: não é possível rodar um modelo de linguagem pesado em um hardware modesto e obter respostas instantâneas. Se o seu projeto exige velocidade em tempo real (como chatbots de suporte ao vivo no site), não faça concessões — vá direto para soluções de Hospedagem GPU e Servidores de IA (servidores prontos para produção costumam começar em €300/mês).

No entanto, pequenas empresas têm diversas tarefas que não exigem resposta imediata. Gerar relatórios, analisar dados de vendas, processar informações estruturadas ou automatizar fluxos de trabalho repetitivos podem ser enfileirados para execução em segundo plano. Abaixo, veremos como implantar um servidor Ollama local em um VPS comum sem placa de vídeo para lidar com essas cargas de forma eficiente e sem custos desnecessários.

Conteúdo do artigo

Por que Rodar IA Self-Hosted (Servidor Próprio)?

Surge uma pergunta natural: por que configurar um modelo em um VPS se existem ChatGPT, Claude, Gemini e dezenas de APIs de IA na nuvem?

A principal vantagem de rodar em sua própria infraestrutura (um PC do escritório ou um VPS) é o controle. A maioria das tarefas de IA em servidores não exige a escrita de romances ou a resolução de olimpíadas de matemática. Para um VPS com 1 vCPU e 4 GB de RAM, o objetivo é outro: utilizar modelos quantizados superleves para automação em segundo plano.

Ao utilizar um modelo local, o fluxo da requisição funciona assim:

usuário → meu servidor → Ollama → modelo local

Não há necessidade de enviar cada requisição para um provedor externo de IA. Isso abre várias possibilidades interessantes:

Você pode processar dados privados, criar ferramentas internas, automatizar o processamento de texto, classificar dados ou executar milhares de pequenas tarefas de IA sem pagar por chamada de API a terceiros. Autonomia: permite rodar IA localmente em dispositivos (smartphones, terminais PDV, caixas) sem depender de conexão constante com a nuvem.

Ao mesmo tempo, o modelo local não precisa substituir o ChatGPT ou o Claude. Na prática, uma arquitetura híbrida é muito mais interessante:

  • Tarefa simples → modelo local
  • Tarefa complexa → modelo na nuvem

Por exemplo, o modelo local pode realizar: classificação de texto, detecção de idioma, geração de tags, extração de entidades, resumos curtos, normalização de dados e conversão de texto para JSON. Enquanto isso, tarefas complexas podem continuar sendo enviadas para um modelo robusto na nuvem. É exatamente esse cenário que torna os modelos locais leves tão atraentes.

Cenário Prático e Exemplo Real (Live Demo)

A maioria das tarefas de IA em servidores não exige redação avançada ou raciocínio profundo. Para pequenas empresas e projetos web, a automação em segundo plano resume-se a centenas de pequenas rotinas repetitivas.

Worker em Segundo Plano: Processando uma Fila de Tarefas

Imagine um projeto de conteúdo que processa 500 registros diariamente (artigos, produtos ou mensagens). Para cada item, você precisa:

  1. Identificar o idioma do texto.
  2. Selecionar a categoria correta.
  3. Extrair as principais entidades.
  4. Gerar 5 meta tags.
  5. Retornar o resultado no formato JSON estrito.

Se essas operações não exigem resposta imediata (o usuário não está aguardando o carregamento da página no navegador), o servidor pode processar a fila de forma assíncrona ao longo do dia. A uma velocidade de geração de 15 a 20 tokens por segundo em 1 vCPU, um modelo pequeno processará todo o volume com facilidade. É por isso que um VPS modesto não é um “computador ruim para o ChatGPT”, mas sim um worker de IA perfeitamente funcional para tarefas em segundo plano.

Com isso, você obtém:

  • Custo zero por chamada: sem taxas por requisição de API para OpenAI ou Claude.
  • Privacidade: dados confidenciais nunca saem do seu VPS.
  • Independência: livre de limites de taxa (rate-limits), bloqueios geográficos ou mudanças repentinas de regras dos provedores em nuvem.

Caso Real ao Vivo: Gerador Interativo de Desculpas DevOps

Para demonstrar esse conceito na prática, integrei um microserviço baseado nessa estrutura diretamente na página inicial do projeto dieg.net.

Como funciona a arquitetura:

  1. Ao clicar no botão interativo, o frontend do cliente envia uma requisição AJAX para o backend do site.
  2. O backend envia a requisição via conexão criptografada HTTPS (com autenticação Nginx Basic Auth) para o Ollama em um VPS isolado com 1 vCPU e 4 GB de RAM.
  3. O modelo Qwen3 1.7B com o modo de raciocínio desativado (--think=false) gera em tempo real um motivo irônico para a queda ou travamento do servidor.
  4. A resposta é entregue ao usuário em 1,5 a 2 segundos em formato de texto simples.

Esse exemplo demonstra claramente que até mesmo um VPS barato de $5 a $7 por mês é capaz de atender microserviços públicos interativos sem sobrecarregar a estrutura principal do site.

O Que É o Ollama e Como Ele Se Difere de um Modelo de IA

Quando se fala em rodar inteligência artificial em um servidor próprio, o nome Ollama surge rapidamente. À primeira vista, pode parecer que o Ollama é apenas mais uma rede neural como ChatGPT, Qwen ou Gemma. Na realidade, são coisas completamente diferentes.

Ollama ≠ Modelo de IA.

O Ollama não é um modelo de linguagem. Ele é um ambiente de software para baixar, executar e gerenciar modelos de IA em seu próprio hardware. Fazendo uma analogia com um servidor web tradicional: o modelo representa os dados e o algoritmo, enquanto o Ollama é a camada de infraestrutura que permite executar o modelo facilmente e acessá-lo via API. O Ollama pode ser instalado no Linux, Windows e macOS.

O Que o Ollama Realmente Faz

Um grande modelo de linguagem por si só é um conjunto de pesos que varia de centenas de megabytes a dezenas ou centenas de gigabytes. Apenas baixar esse arquivo não é suficiente. É necessário um mecanismo de inferência (inference engine) — um software que carregue o modelo na memória, execute os cálculos e retorne o resultado.

De forma simplificada, a arquitetura funciona assim:

Seu site / aplicativo / script → API → Ollama (Motor) → Modelo Qwen/Gemma → CPU / GPU

Por isso, “instalar o Ollama” e “instalar o modelo Qwen” são operações distintas. Aqui: Ollama é o programa que gerencia os modelos e sua execução, enquanto Qwen é a família de modelos da Alibaba. Você pode substituir o Qwen por outro modelo suportado sem alterar o Ollama. Após a inicialização, o Ollama se torna um serviço de IA local acessível por aplicações, permitindo integrações com sites, CMS, sistemas internos, bots do Telegram ou fluxos de automação próprios.

Como Funciona Internamente no Ollama

O comando ollama ps exibe apenas os modelos que estão carregados na memória RAM e processando requisições no momento exato.

  1. Modo de Espera (Idle): Quando não há requisições, o Ollama roda como um processo leve do sistema, consumindo o mínimo de recursos. O modelo qwen3:1.7b permanece descarregado da RAM e armazenado no disco.
  2. Recebimento da Requisição: Assim que uma chamada de API chega do seu site, o Ollama carrega instantaneamente o qwen3:1.7b do disco para a RAM. Nesse momento (durante a geração), o comando ollama ps mostrará o modelo na lista.
  3. Descarregamento Automático (Unload): Após gerar e entregar a resposta via API, o Ollama mantém o modelo na memória RAM por mais 5 minutos (timeout padrão) e depois o descarrega para liberar memória.

Você pode verificar isso pessoalmente. Abra dois terminais. No primeiro, execute: watch -n 1 ollama ps. No segundo, envie uma requisição cURL. Você verá o modelo aparecer na lista durante a geração e desaparecer em seguida. Esta é uma grande vantagem para VPS com 1 vCPU / 4 GB RAM: não é necessário manter um modelo pesado preso na memória RAM o tempo todo.

Comandos para Gerenciar o Serviço Ollama

  • Reiniciar o Ollama: systemctl restart ollama
  • Verificar o status do Ollama: systemctl status ollama
  • Verificar modelos ativos na RAM: ollama ps
  • Listar modelos baixados e seus tamanhos: ollama list
  • Remover um modelo: ollama rm qwen2.5:3b

VPS Testados

ProvedorCPURAMDisco
Aeza1 vCPU, AMD Ryzen 9 5950X @ 3.39 GHz4 GB10 GB
AlexHost2 vCPU @ 2.30 GHz, QEMU Virtual CPU4 GB40 GB
AMHG2 vCPU, QEMU Virtual CPU 2.5+ GHz4 GB77 GB

Todos os servidores utilizaram virtualização KVM, Ubuntu 24.04 LTS (x86-64), sem GPU (hospedagem com GPU) e sem swap configurado. Os dados foram coletados através do meu script bash ai-vps-check.

Parâmetro / O que testamosAezaAlexHostAMHG
CPU — qual processador o VPS identificaAMD Ryzen 9 5950XQEMU Virtual CPU 2.5+QEMU Virtual CPU 2.5+
vCPU — quantos núcleos virtuais estão disponíveis122
RAM — memória RAM total do sistema3.8 GiB3.8 GiB3.8 GiB
RAM Disponível — memória livre para o modelo durante os testes3.5 GiB2.7 GiB2.2 GiB
Swap — reserva em caso de falta de RAMNãoNão1.4 GiB
AVX — instruções vetoriais aceleradas do CPUSimNãoSim
AVX2 — instruções SIMD modernas para inferência no CPUSimNãoSim
FMA — aceleração de operações matemáticasSimNãoSim
F16C — operações com números de 16 bitsSimNãoSim
AVX-512 — conjunto expandido de instruções SIMDNãoNãoSim
Disco Livre — espaço disponível para modelos6.1 GB30 GB59 GB
Steal time* — tempo de CPU retirado pelo hipervisor0%7.7%0%

* Steal time (st) — porcentagem de tempo em que o CPU virtual está pronto para trabalhar, mas o hipervisor não aloca ciclos de processamento. Valores constantes acima de 10% indicam necessidade de abrir chamado no suporte da hospedagem.

O Que Observar ao Escolher um VPS

Nosso teste mostrou que a quantidade de vCPUs isoladamente é um péssimo critério para escolher um VPS de IA. Dois núcleos virtuais podem ser significativamente mais lentos que um único núcleo se o processador físico for fraco, se o hipervisor limitar as instruções do CPU ou se o servidor físico estiver sobrecarregado.

Primeiro, verifique qual CPU a máquina virtual reconhece e se as instruções AVX, AVX2 e FMA estão ativas. O llama.cpp, utilizado pelo Ollama para inferência no CPU, aproveita otimizações SIMD de processadores x86 modernos. Portanto, a presença de AVX, AVX2 e FMA é essencial para VPS sem GPU.

Modelos genéricos como “QEMU Virtual CPU” exigem atenção, especialmente se acompanhados da ausência de AVX/AVX2/FMA. Isso não significa necessariamente que o processador físico seja antigo: o provedor pode expor um modelo genérico para facilitar a migração entre nós físicos. Mas para IA local, o importante são as instruções realmente disponíveis para sua máquina virtual (VPS).

Na prática, ao escolher um VPS para IA self-hosted, a ordem de prioridades é: RAM suficiente → CPU moderno com AVX2/FMA → Steal time baixo e estável → Desempenho single-core → Quantidade de vCPUs.

A quantidade de memória RAM é o primeiro filtro: o modelo e os buffers de trabalho devem caber inteiramente na memória física. Se a memória for insuficiente, as outras especificações perdem o sentido. Depois, priorize um CPU de alto desempenho com AVX2/FMA e só então avalie a quantidade de núcleos virtuais. Nosso teste comprovou que um vCPU moderno e rápido é muito mais eficiente para LLMs leves do que dois núcleos virtuais lentos.

Em nosso teste, a diferença foi enorme. Um VPS com 1 vCPU Ryzen 9 5950X e suporte a AVX2/FMA concluiu 10 requisições simultâneas do Qwen3 1.7B em 2:09. Já o VPS com 2 vCPUs, CPU QEMU genérico e sem AVX/AVX2/FMA precisou de 15:18 — cerca de 7 vezes mais tempo. O llama-server utilizou quase 100% dos dois vCPUs, e o steal time chegou a ~25% durante o teste. Portanto, essa diferença de 7x decorre da combinação entre arquitetura de CPU, instruções disponíveis e carga do servidor físico.

Metodologia de Teste do VPS

Para testar 10 requisições simultâneas (o número de requisições pode ser ajustado em {1..10}), utilizamos o seguinte script em bash:

time (
  for i in {1..10}; do
    curl -s http://127.0.0.1:11434/api/generate \
      -d '{
        "model":"qwen3:1.7b",
        "prompt":"Sugira 3 nomes de domínio para uma cafeteria usando letras latinas.",
        "stream":false,
        "think":false
      }' > /tmp/ollama-$i.json &
  done
  wait
)

O resultado exibirá:

real    0mXX.XXXs
user    ...
sys     ...

O dado principal a analisar é o real.

Para monitorar a RAM, abra uma segunda sessão SSH durante a geração e execute:

watch -n 0.5 'ps -eo pid,comm,%cpu,%mem,rss --sort=-rss | head -10'

O valor RSS representa a RAM física consumida pelo processo em KiB. Você também pode utilizar o comando `top` para acompanhar o uso de CPU, memória e a métrica `st` (steal time).

Tabela Comparativa: Qual Modelo Escolher para o Seu VPS

Em vez de cálculos complexos, vamos analisar quais modelos realmente rodam em um servidor de entrada (1 vCPU, 4 GB RAM).

O segredo está na quantização — uma técnica de compressão que torna o modelo de IA mais leve (formato Q4_K_M). A precisão diminui ligeiramente, mas o modelo passa a rodar em CPUs comuns.

Ao executar o comando ollama list, você verá o tamanho do modelo baixado. Exemplo: NAME: qwen3:1.7b | SIZE: 1.4 GB. Lembre-se de que, além desse espaço em disco, o modelo exigirá espaço adicional na memória RAM para o contexto (KV-cache).

Matriz de seleção de modelos:

ModeloParâmetrosTamanho em Disco (Quantização Q4)Requisitos de RAMVeredito para VPS (1 vCPU / 4 GB RAM)
Qwen 2.5 / 3 (7B-8B)7–8 Bilhões~4.7 – 5.2 GB8+ GB❌ Memória insuficiente.
Qwen 3 (4B)4 Bilhões~2.5 GB~4 GB⚠️ No limite. Irá rodar, mas o servidor ficará muito lento.
Qwen 2.5 (3B)3 Bilhões~1.9 GB~3 GB✅ Boa opção se o SO estiver leve. Ótimo desempenho multilíngue.
Qwen 3 (1.7B)1.7 Bilhão1.4 GB~2.5 GB🔥 Ideal! Melhor equilíbrio entre velocidade e qualidade para segundo plano.
Gemma 3 (1B)1 Bilhão<1 GB~1.5 GB✅ Opção excelente e muito rápida.
Qwen 3 (0.6B)0.6 Bilhão~523 MB~1 GB✅ Ultra-leve. Recomendado para classificação simples e criação de tags.

Conclusão: Em um servidor com 4 GB de RAM, o limite prático são modelos quantizados de até 3 bilhões de parâmetros (3B). Deixe modelos maiores (7B, 14B) para servidores com suporte a GPU.

Como Implantar em 10 Minutos (Sem Docker) Otimizado para 1 vCPU

Infraestrutura no VPS: Ubuntu 24.04 + Ollama + Nginx + SSL + Autenticação + IPv4/IPv6.

Instalação do Ollama:

# curl -fsSL https://ollama.com/install.sh | sh

O sistema exibirá um aviso: WARNING: No NVIDIA/AMD GPU detected. Ollama will run in CPU-only mode. Isso é normal.

Baixando o modelo base Qwen3 1.7B:

ollama pull qwen3:1.7b

Testando o modelo diretamente pelo terminal:

ollama run qwen3:1.7b "Hi, suggest 3 domain names for a coffee shop"

Thinking...

O Ollama disponibiliza uma API REST local na porta 11434, permitindo o envio de requisições JSON diretamente via PHP/JS.

~# lsof -i:11434
COMMAND  PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
ollama  2406 ollama    3u  IPv4  25832      0t0  TCP localhost:11434 (LISTEN)

Modo Non-Thinking: Desativando o Bloco de Raciocínio

Para obter respostas imediatas, desative o bloco de raciocínio interno. O Ollama permite desativar esse comportamento utilizando a flag --think=false:

ollama run qwen3:1.7b --think=false "Hi, suggest 3 domain names for a coffee shop"

O bloco de raciocínio é útil para tarefas lógicas complexas, mas traz duas desvantagens em rotinas automatizadas:

  1. Texto Extra na API: O bloco de raciocínio é incluído na resposta da API, o que pode quebrar a leitura de JSON em scripts PHP/Node.
  2. Uso Desnecessário de CPU: O modelo gasta até 80% do tempo gerando monólogos internos (Thinking...) em vez da resposta final. Em 1 vCPU, isso adiciona de 10 a 15 segundos de espera desnecessária.

O modo non-thinking é ideal para tarefas práticas como classificação, tradução, extração de dados e geração de textos curtos. Deixe o modo thinking ativo apenas para tarefas lógicas avançadas ou geração de código.

É Necessário Usar Arquivo de Swap para IA?

O swap não substitui a memória RAM física e não é necessário para o funcionamento normal de um LLM local, desde que o modelo caiba na RAM do VPS. Além disso, o uso intenso de swap reduz drasticamente a velocidade de geração, pois o disco é muito mais lento que a RAM.

Em nossos testes, o Qwen3 1.7B rodou perfeitamente sem swap em um VPS com 4 GB de RAM. Trate o swap apenas como uma proteção contra erros de memória (OOM), e não como uma forma de rodar modelos pesados.

Segurança no Ollama: Como Configurar Acesso Remoto Seguro

Riscos de expor o Ollama diretamente:

  1. Tráfego Não Criptografado (HTTP): Se a porta 11434 do Ollama for exposta publicamente, prompts, dados e respostas trafegarão pela internet sem criptografia SSL.
  2. Ausência de Autenticação Nativa: O Ollama não possui controle de acesso embutido (login/senha). Se regras de firewall falharem ou o Docker sobrescrever regras do UFW no iptables, a porta 11434 ficará aberta a qualquer usuário na internet.

Se suas aplicações estão em outro servidor, nunca exponha a porta 11434 do Ollama diretamente sem proteção. Sem autenticação, seu VPS pode se tornar um proxy aberto para terceiros.

Utilize o Nginx como proxy reverso para proteger o servidor de IA. A latência adicional de 1 ms é imperceptível diante do tempo de resposta do modelo, garantindo criptografia HTTPS, autenticação por chave de API e tratamento estável de conexões.

O Nginx resolve dois pontos principais:

  1. Protege o Ollama com autenticação (via chave de API no cabeçalho `Bearer` ou Basic Auth).
  2. Aplica criptografia HTTPS (certificado SSL) nas requisições entre servidores.

Instalação do Nginx e Utilitários de Segurança

Neste exemplo, utilizaremos o domínio ai.dieg.net. Substitua-o pelo seu domínio durante a configuração.

apt update && apt full-upgrade
apt install -y nginx apache2-utils certbot python3-certbot-nginx

Configuração de Autenticação (Basic Auth)

Crie o arquivo de senhas. Substitua MINHA_CHAVE_SECRETA por uma senha forte:

htpasswd -bc /etc/nginx/.ollama_pass api_user MINHA_CHAVE_SECRETA

Configuração do Nginx para IPv4 e IPv6

Remova a configuração padrão do Nginx e crie um novo arquivo de bloco de servidor:

rm -f /etc/nginx/sites-enabled/default
nano /etc/nginx/sites-available/ai.dieg.net

Cole a configuração abaixo (ajustada para escutar conexões IPv4 na porta 80 e IPv6 em [::]:80):

server {
    listen 80;
    listen [::]:80;
    server_name ai.dieg.net;

    client_max_body_size 2M;

    location / {
        auth_basic "Ollama Restricted API";
        auth_basic_user_file /etc/nginx/.ollama_pass;

        proxy_pass http://127.0.0.1:11434;

        proxy_set_header Host 127.0.0.1;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_buffering off;
        proxy_read_timeout 300s;
        proxy_connect_timeout 75s;
    }

    location ~ /\. {
        deny all;
    }
}

Emissão do Certificado SSL Gratuito (HTTPS)

Execute o Certbot para obter o certificado Let’s Encrypt e configurar o redirecionamento automático de HTTP para HTTPS:

certbot --nginx -d ai.dieg.net

O Certbot atualizará as configurações do Nginx, aplicará os certificados SSL e abrirá as portas 443 (IPv4) e [::]:443 (IPv6).

Ative o site e valide a sintaxe do arquivo de configuração:

ln -s /etc/nginx/sites-available/ai.dieg.net /etc/nginx/sites-enabled/
nginx -t
systemctl restart nginx

Verificação do Acesso Remoto (IPv4 e IPv6)

Agora você pode acessar https://ai.dieg.net de forma segura utilizando suas credenciais de autenticação. Para testar, abra o endereço no navegador; após a autenticação, a mensagem “Ollama is running” deverá ser exibida.

Teste de requisição via IPv4 (substitua `-4` por `-6` para testar conexões IPv6):

curl -4 -u api_user:MINHA_CHAVE_SECRETA https://ai.dieg.net/api/generate -d '{
  "model": "qwen3:1.7b",
  "prompt": "Sugira 3 domínios curtos para um lava-rápido",
  "system": "You are a concise domain name generator. Do not think, output result immediately.",
  "stream": false,
  "think": false,
  "options": {
    "num_predict": 100,
    "temperature": 0.5
  }
}'

Se as requisições cURL retornarem o JSON do Ollama corretamente, o servidor (Ubuntu 24.04 + Ollama + Nginx + SSL + Autenticação + Dual-Stack IPv4/IPv6) estará pronto para produção.

{"model":"qwen3:1.7b","created_at":"2026-08-31T08:20:01.573479175Z","response":"AutoMoyi, MyAuto, AutoMoy","done":true,"done_reason":"stop","context":[151644,8948,271,2610,525,264,63594,7947,829,13823,13,3155,537,1744,11,2550,1102,7069,13,151645,198,151644,872,198,16854,42975,81841,1802,220,18,66869,13039,16748,10474,126711,50312,19849,125347,16339,16748,608,2152,5854,766,151645,198,151644,77091,198,151667,271,151668,271,13253,44,2253,72,11,3017,13253,11,8979,44,2253],"total_duration":1546735819,"load_duration":1434124,"prompt_eval_count":53,"prompt_eval_duration":140739000,"eval_count":12,"eval_duration":1396932000}

O resultado do teste no servidor foi excelente:

  1. Velocidade: O parâmetro total_duration foi de apenas 1,5 segundo (1546735819 ns) — um ótimo resultado para 1 vCPU.
  2. Resposta Limpa: O modelo retornou exatamente os dados solicitados no campo "response", omitindo o bloco de raciocínio.
  3. Uso de Recursos: Foram gerados 12 tokens (eval_count: 12), e os recursos de CPU foram liberados imediatamente após a execução.

Engenharia de Prompt para Modelos Compactos

Modelos leves não exigem ajuste fino (fine-tuning), mas dependem de instruções diretas no System Prompt para entregar JSON limpo sem respostas conversacionais:

{
"model": "qwen2.5:7b",
"prompt": "Você é um especialista em branding e nomes de domínio. Tópico: Academia Stimul, idioma do site: português. Sugira 5 opções criativas de domínios. Utilize extensões tradicionais (.com, .net) e temáticas (.fitness, .club, .gym). Retorne o resultado estritamente no formato JSON.",
"stream": false
}

Para evitar respostas genéricas em modelos de 3B parâmetros, estruture o prompt de forma direta:

Você é um gerador de nomes de domínio. Sua tarefa é sugerir 5 opções de domínios curtos e memoráveis para um projeto.

Dados de entrada: Tema: {entrada}, Idioma: {idioma}

Regras:
1. Utilize extensões tradicionais (.com, .net) e temáticas (.fitness, .online, .store, .tech, .shop).
2. Aplique domain hacks (ex: word.press, stimul.fitness) quando apropriado.
3. Não inclua frases de introdução ou conclusão. Exiba apenas a lista de domínios com uma breve explicação do conceito.

Automação da Resiliência do Serviço

O principal risco ao rodar LLMs em instâncias com 4 GB de RAM é a interrupção do processo pelo OOM-Killer do Linux durante picos de memória. Não é necessário instalar utilitários adicionais como o Monit; o próprio Systemd gerencia o reinício automático do serviço em até 3 segundos.

Para configurar o reinício automático do Ollama, edite as configurações do serviço:

sudo systemctl edit ollama

Adicione as diretivas de reinício no bloco `[Service]`:

[Service]
Restart=always
RestartSec=3

Aplique as alterações:

systemctl daemon-reload
systemctl restart ollama

systemctl cat ollama # Confirme se o Systemd carregou as alterações corretamente

Dessa forma, em caso de falha por estouro de memória, o Systemd reiniciará o Ollama automaticamente.

Identificação de Gargalos de Desempenho

Ao testar seus prompts, monitore estes 3 indicadores essenciais:

MétricaCausa do GargaloComo Resolver
Uso de RAMSe o modelo exceder a RAM física, o sistema usará swap intensivamente. A velocidade pode cair para ~0,1 token/seg.Utilize um modelo mais leve. Migre do qwen2.5:3b para o qwen2.5:1.5b.
Uso de CPU (100%)Comportamento esperado para inferência via CPU. O foco deve ser a otimização do Time to First Token (TTFT).Reduza o tamanho da janela de contexto (num_ctx) na requisição do Ollama para 1024 ou 2048 tokens.
OOM-KillerRegistros do tipo Out of memory: Kill process no log do dmesg.Verifique se um arquivo de Swap (2 GB) está ativo como proteção do sistema.

FAQ e Conceitos Básicos

O que é um token? 1 token equivale a 1 palavra em inglês?

Um token em IA não equivale necessariamente a uma palavra. Essa associação é um equívoco comum.

Um token é o menor fragmento de texto (bloco de dados) processado por uma rede neural:

  • Palavras curtas em inglês (como cat, home, run) geralmente correspondem a 1 token.
  • Palavras longas ou complexas são divididas em subpalavras: por exemplo, unbelievable é dividida em 3 tokens (un-believ-able).
  • Palavras em português, sinais de pontuação e caracteres especiais consomem mais tokens por palavra devido à codificação UTF-8 e variações morfológicas.

De forma geral: 1 token equivale a cerca de 3 a 4 caracteres em inglês e 2 a 3 caracteres em português.

O que é Inferência (Inference) em Redes Neurais?

Inferência é a etapa em que um modelo já treinado recebe novos dados de entrada e processa a resposta final.

O que é Quantização (Quantization)?

Quantização é a compressão dos pesos de um modelo de IA (por exemplo, convertendo precisão de 16 bits para inteiros de 4 bits) para torná-lo mais leve, rápido e econômico, com uma perda mínima de precisão. Exemplo: O modelo é reduzido em 2x a 4x, permitindo sua execução em computadores comuns sem a necessidade de servidores de alto custo. Para tarefas como criação de posts ou resumos, a qualidade se mantém estável, embora tarefas que exijam lógica avançada possam apresentar queda de desempenho.

É Possível Rodar o Ollama em um VPS com 1 CPU e 4 GB de RAM?

Sim, mas é preciso separar duas questões:

  1. Executar o ambiente Ollama — é simples e leve.
  2. Rodar um modelo adequado com boa velocidade — exige escolha criteriosa.

O Ollama em si consome poucos recursos. O uso de memória e CPU é impulsionado pelo modelo carregado e pelo tamanho do contexto. Em um VPS com 1 vCPU / 4 GB RAM sem GPU, modelos das famílias 7B, 14B, 30B ou 70B devem быть descartados. No entanto, modelos compactos são adequados para essa estrutura: o Ollama disponibiliza versões do Qwen3 em tamanhos de 0.6B e 1.7B, enquanto o Gemma 3 possui variações de 1B, atendendo bem servidores de entrada.

Quanta Memória RAM É Realmente Necessária para Rodar um LLM?

O consumo de memória sempre supera o tamanho do arquivo do modelo: além do sistema operacional e do Ollama, a memória RAM é consumida pelo KV-cache (armazenamento do contexto da conversa). Quanto maior o contexto (32K/128K), maior será o consumo de RAM. Em um VPS de 4 GB, a janela de contexto deve ser limitada (ex: 2K–4K tokens). Mesmo com um modelo leve, a execução em 1 vCPU é limitada pela capacidade de processamento do CPU, sendo ideal para workers em segundo plano e não para chats interativos em tempo real.

  • Mecanismo do KV-Cache: Durante a geração de tokens, o modelo armazena os tensores de Key-Value dos tokens anteriores na RAM para evitar o reprocessamento de todo o histórico. O tamanho do KV-cache cresce linearmente de acordo com a extensão do contexto.
  • Limite Recomendado: Para VPS com 4 GB de RAM e modelos de ~2 GB, defina o parâmetro num_ctx no Ollama entre 2048 e 4096 tokens para evitar falhas por falta de memória.
  • Gargalo de Processamento: 1 vCPU atinge rapidamente o limite de operações de ponto flutuante (FLOPS), tornando o servidor adequado para filas de processamento assíncrono.

Quanto Texto Realmente Cabe em um Contexto de 32K (32.000 Tokens) em Inglês, Português, Russo e Ucraniano?

O tamanho do contexto é medido em tokens. Devido à estrutura dos tokenizadores e aos diferentes alfabetos, o volume real de texto varia segundo o idioma:

  • Inglês: ~24.000 palavras (~50 páginas A4). Cada palavra equivale em média a 1 token. Por ser o idioma principal no treinamento da maioria dos LLMs, o vocabulário em inglês é otimizado nos tokenizadores.
  • Português: ~20.000–22.000 palavras (~40–45 páginas A4). Cada palavra consome em média 1,4 a 1,6 token. O uso do alfabeto latino dá vantagem ao português em relação ao cirílico, mas caracteres especiais (ã, ç, é), acentuação e flexões gramaticais fazem o tokenizador dividir as palavras com mais frequência do que no inglês.
  • Russo: ~12.000–16.000 palavras (~25–30 páginas A4). O alfabeto cirílico utiliza mais bytes em UTF-8, e as palavras são divididas em subpalavras, resultando em 2,0 a 2,5 tokens por palavra.
  • Ucraniano: ~12.000–15.000 palavras (~25–30 páginas A4). Cada palavra consome em média 2,0 a 2,6 tokens. A eficiência de tokenização do ucraniano é semelhante à do russo devido ao uso do alfabeto cirílico. Em modelos recentes com vocabulários expandidos (Llama 3, Qwen 2.5), os caracteres específicos (є, ї, і, ґ) são processados adequadamente.

Por que não utilizar o contexto completo de 32K em um VPS de 4 GB de RAM? Carregar um volume elevado de páginas em uma sessão exige um consumo alto de memória RAM para o KV-cache:

  • Consumo de RAM: O KV-cache para um contexto de 32K consome de 2 a 4 GB de RAM além do tamanho do modelo, provocando erros de memória (OOM).
  • Sobrecarga de CPU: Em 1 vCPU, o processamento inicial (prefill) de um prompt extenso pode levar vários minutos, inviabilizando o uso do servidor.

Qual tamanho de contexto é seguro para servidores de entrada? O limite ideal para um VPS com 4 GB de RAM é de 2048 a 4096 tokens (num_ctx). Essa faixa comporta de 3 a 6 páginas de texto, cobrindo a maioria das tarefas de automação em segundo plano e mantendo a estabilidade do sistema.

O Ollama É o “Docker” dos Modelos de IA?

Essa comparação é comum e ajuda a entender o conceito, embora existam diferenças técnicas. O Docker padroniza a execução de aplicações. O Ollama organiza o gerenciamento e a execução de modelos de IA de forma semelhante:

ollama pull ...
ollama run ...
ollama list
ollama rm ...

Com isso, o usuário não precisa configurar manualmente arquivos de pesos, motores de execução ou parâmetros complexos.

Uma definição técnica mais precisa:

O Ollama é um gerenciador de modelos, ambiente de execução de inferência e servidor de API para IA local.

O LocalAI É uma Alternativa ao Ollama?

LocalAI é uma plataforma de infraestrutura de IA com suporte a APIs compatíveis com os padrões da OpenAI e Anthropic. O projeto suporta múltiplos backends e atende tanto LLMs quanto outras tarefas de aprendizado de máquina. O LocalAI oferece uma estrutura ampla para diferentes cenários de implantação.

Essa flexibilidade traz vantagens e maior complexidade de configuração.

Se o objetivo for:

“Preciso de uma API local e simples para LLMs,”

O Ollama é a escolha mais direta.

Se o objetivo for:

“Estou construindo um backend de IA self-hosted completo para múltiplos tipos de modelos e APIs padronizadas,”

O LocalAI torna-se uma opção relevante.

É Possível Rodar IA Local Sem Usar o Ollama?

Sim, o uso do Ollama não é obrigatório. É possível utilizar diretamente o llama.cpp (motor em C++) ou servidores de inferência como vLLM, TGI (Text Generation Inference) e LocalAI. Para cenários que exigem menor latência e controle avançado de memória, o llama.cpp nativo, vLLM ou TGI oferecem bom desempenho. O Ollama atua como uma camada de abstração para facilitar o uso dos modelos.

O Que É o Ollama Cloud? Quando Utilizar e Quanto Custa?

A execução local de modelos de grande porte (como os de 70B+ parâmetros) exige hardware avançado que computadores pessoais ou VPS de entrada não conseguem suprir.

O Ollama Cloud conecta requisições locais a servidores em nuvem gerenciados:

  1. Modelos pequenos rodam localmente no seu computador ou VPS de forma gratuita.
  2. Modelos de grande porte podem ser redirecionados para servidores em nuvem. O redirecionamento dinâmico exige o uso de ferramentas intermediárias, como o LiteLLM, pois o Ollama padrão não faz o chaveamento automático com base na VRAM disponível.

Estrutura de custos do Ollama Cloud:

  • Local (no próprio servidor/PC): 100% gratuito.
  • Cloud Gratuito: Plano com limites de taxa e velocidade para testes básicos.
  • Cloud Pro / Max: Planos pagos (a partir de $20/mês) para acesso contínuo a servidores com GPU e limites expandidos.

Como Permitir que o Ollama Aceite Requisições Externas (CORS)

Por padrão, o Ollama aceita conexões vindas apenas de `localhost`. Para permitir que o Nginx faça o proxy de requisições externas de outros domínios, adicione a variável de ambiente `OLLAMA_ORIGINS=”*”`. Abra o editor do serviço Ollama:

sudo systemctl edit ollama

Insira as seguintes linhas no arquivo de configuração:

[Service]
Environment="OLLAMA_ORIGINS=*"
Environment="OLLAMA_HOST=127.0.0.1:11434"

Reinicie o serviço para aplicar as alterações:

systemctl daemon-reload
systemctl restart ollama

Dmytro Yakovenko
Leave a Reply

Your email address will not be published. Required fields are marked *