Uma VPS comum consegue rodar LLM self-hosted?

Consegue em cenários limitados, principalmente laboratório, automações internas e modelos pequenos ou quantizados. Uma VPS com 4 vCPUs e 8 GB de RAM pode rodar Ollama ou llama.cpp com modelos compactos, mas a latência tende a subir quando há contexto longo ou usuários simultâneos. Para produção, o problema não é só iniciar o modelo. É manter API, banco vetorial, filas, logs e segurança funcionando juntos. Se houver RAG, documentos grandes ou exigência de resposta rápida, Cloud Server com mais RAM, NVMe e arquitetura separada costuma ser mais adequado.

Quando Cloud Server para IA precisa de GPU?

GPU faz sentido quando a aplicação precisa de baixa latência, maior volume de requisições ou modelos maiores. Em CPU, modelos pequenos e embeddings podem funcionar bem, mas a geração de texto com LLM médio fica lenta rapidamente. Uma GPU com VRAM suficiente acelera a inferência e melhora throughput, desde que o modelo, o framework e os drivers sejam compatíveis. Antes de contratar uma instância cara, rode benchmark com prompts reais, medindo tempo até o primeiro token, tokens por segundo, uso de VRAM, latência p95 e taxa de erro.

Quanta RAM é recomendada para RAG self-hosted?

Para um RAG pequeno em laboratório, 8 GB de RAM podem bastar, mas com pouca folga. Para uso interno mais estável, 16 GB é um ponto de partida melhor. Se a mesma máquina roda API, worker, banco vetorial, Redis e inferência, 32 GB costuma ser uma faixa mais realista. O consumo depende do tamanho da coleção, do modelo de embeddings, do contexto enviado ao LLM e da concorrência. Também planeje espaço para cache, reindexações e picos de uso, evitando depender de swap em produção.

NVMe é obrigatório para IA self-hosted?

NVMe não é obrigatório para todo projeto, mas ajuda bastante em RAG, bancos vetoriais e cargas com muitos arquivos pequenos. Ele reduz tempo de carregamento de modelos, melhora ingestão de documentos e torna reindexações menos dolorosas. Ainda assim, NVMe não corrige falta de RAM, CPU saturada ou modelo grande demais. Para laboratório, SSD pode servir. Para produção com pgvector, Qdrant, logs e documentos, NVMe com folga de capacidade é uma escolha mais segura, especialmente quando há backups e reprocessamentos frequentes.

É melhor rodar tudo em um servidor ou separar componentes?

Rodar tudo em um servidor é aceitável no início, pois simplifica deploy e reduz custo. Em produção, separar componentes melhora estabilidade. A API pública pode ficar em um servidor menor, o banco vetorial em uma máquina com mais RAM e NVMe, e a inferência em CPU forte ou GPU. Essa divisão evita que uma tarefa pesada de embeddings derrube o endpoint principal. Também facilita backups, monitoramento e segurança, já que banco e workers podem ficar em rede privada, sem portas expostas diretamente à internet.

Quais métricas devo acompanhar em uma API de inferência?

Acompanhe CPU, RAM, swap, disco, I/O wait e rede, mas não pare aí. Para IA, meça tempo até o primeiro token, tokens por segundo, latência p50, p95 e p99, tamanho médio de prompt, tamanho de resposta, erros de timeout e tempo de fila. Em RAG, registre tempo de busca vetorial, reranking e geração final. Se houver GPU, monitore VRAM, utilização e temperatura quando disponível. Essas métricas mostram se o gargalo está no modelo, no banco, no disco ou na concorrência.

Cloud Server para IA: onde VPS comum falha

Resposta direta

Cloud Server para IA é indicado quando você quer rodar modelos de linguagem, embeddings, RAG ou APIs de inferência com mais controle sobre dados, versões e custos operacionais. Uma VPS comum pode servir para testes, embeddings leves e modelos quantizados pequenos, mas costuma falhar quando há concorrência, muitos documentos, contexto longo ou baixa tolerância a latência. Para produção, pense em pelo menos 4 vCPUs, 16 GB de RAM e disco NVMe para workloads de CPU, ou instâncias com GPU quando a inferência precisa responder rápido para vários usuários. O ponto central não é apenas escolher mais RAM ou uma GPU cara. Você precisa dimensionar modelo, quantização, banco vetorial, filas, logs, backups, rede e segurança como partes da mesma arquitetura.

Resumo rápido

Rodar IA self-hosted parece simples quando o teste local funciona no notebook, mas a lógica muda quando entra tráfego real. O servidor precisa manter modelo carregado, responder requisições simultâneas, consultar embeddings, gravar logs, proteger dados e continuar operacional após deploys. Por isso, Cloud Server para IA exige uma decisão mais cuidadosa do que uma VPS usada apenas para site, painel administrativo ou API simples.

Modelos pequenos e quantizados podem rodar em CPU, mas a latência cresce rápido com usuários simultâneos.
Embeddings e RAG dependem muito de RAM, NVMe e organização do banco vetorial.
Uma VPS de 2 vCPUs e 4 GB de RAM serve para laboratório, não para inferência estável com LLM médio.
GPU faz diferença quando a prioridade é baixa latência, maior throughput ou modelos maiores.
Separar API, banco vetorial e worker de inferência reduz risco de travamento total.
Backups precisam cobrir banco, documentos, índices vetoriais e configurações, não apenas arquivos da aplicação.
Dados de preço, disponibilidade de GPU, região e tipo de storage variam por provedor e devem ser revisados antes da publicação.

Se você já dimensiona servidores para APIs, a base técnica é parecida, mas o consumo de memória e disco é bem menos previsível. Um bom ponto de partida é revisar critérios de CPU, RAM e NVMe em servidores cloud no artigo sobre como escolher CPU, RAM e NVMe, depois aplicar esses critérios ao tamanho do modelo, ao volume de documentos e ao padrão de uso da aplicação de IA.

Por que IA self-hosted muda a escolha do servidor

Hospedar um LLM, uma API de embeddings ou uma stack de RAG não é a mesma coisa que colocar uma aplicação Node.js, Laravel ou Python no ar. Em uma API comum, a maior parte das requisições consome CPU por poucos milissegundos, consulta banco, retorna JSON e libera memória. Em inferência, o servidor pode manter vários gigabytes carregados por processo, usar CPU por segundos e gerar resposta token por token. Isso muda a conta de capacidade.

Inferência não é igual a hospedagem web

Um exemplo simples ajuda. Uma API REST com 2 vCPUs e 4 GB de RAM pode atender milhares de requisições leves por dia se o banco estiver bem indexado. O mesmo servidor, tentando rodar um modelo de 7B quantizado com Ollama ou llama.cpp, pode ficar no limite apenas para responder uma pessoa por vez. A memória livre some, o load average sobe e qualquer consulta simultânea ao banco vetorial começa a disputar I/O com o modelo.

Além disso, IA self-hosted costuma trazer dados mais sensíveis. Prompts internos, documentos de clientes, transcrições, contratos, tickets de suporte e bases de conhecimento podem passar pelo pipeline. A escolha por infraestrutura própria geralmente nasce de três motivos: privacidade, previsibilidade de custo e controle técnico. Só que esse controle vem com responsabilidades, como atualizar dependências, limitar acesso, auditar logs e testar restauração.

Quando a VPS comum ainda funciona

Uma VPS comum ainda pode ser uma boa escolha para laboratório, automações internas e serviços auxiliares. Dá para rodar um endpoint de embeddings leve, um banco vetorial pequeno, uma API FastAPI e um painel de testes em uma máquina de 4 vCPUs e 8 GB de RAM, desde que o modelo seja modesto e a concorrência seja baixa. Para protótipos com modelos quantizados de 1B a 3B, ou para gerar embeddings em lote durante a madrugada, CPU pode ser suficiente.

O problema aparece quando o protótipo vira produto. Se cinco usuários pedem respostas ao mesmo tempo, se o contexto inclui dezenas de trechos recuperados do RAG, ou se cada requisição precisa gerar 500 a 1000 tokens, o servidor deixa de ser apenas uma máquina web. Ele vira uma pequena plataforma de processamento. Nesse ponto, Cloud Server com upgrade previsível, snapshots, rede consistente e possibilidade de separar componentes passa a fazer mais sentido do que uma VPS mínima escolhida só por preço.

CPU, RAM e disco: o trio que define o limite real

A primeira dúvida de quem procura Cloud Server para IA costuma ser: quantas vCPUs e quanta RAM eu preciso? A resposta depende do modelo, da quantização, do framework e do padrão de uso. Mesmo assim, dá para trabalhar com faixas práticas. Para laboratório com modelos pequenos, 4 vCPUs e 8 GB de RAM podem bastar. Para RAG interno com embeddings, banco vetorial e API na mesma máquina, 4 a 8 vCPUs e 16 a 32 GB de RAM são mais realistas. Para inferência com LLM de 7B quantizado atendendo usuários simultâneos, 32 GB de RAM já deixa de ser exagero.

Memória pesa mais do que muita gente imagina

A RAM não é usada apenas pelo modelo. O sistema operacional, o runtime Python, o servidor web, o banco vetorial, cache, workers e logs também entram na conta. Um modelo quantizado em 4 bits pode ocupar menos memória do que sua versão original, mas o processo de inferência ainda precisa de espaço para contexto, buffers e concorrência. Se você usa contexto de 8k tokens, múltiplos workers e reranking, a folga desaparece rápido.

Um cenário comum é tentar economizar com 8 GB de RAM e compensar com swap. Funciona para testes, mas piora muito a latência. Swap em NVMe é menos doloroso do que em SSD SATA, porém ainda é memória em disco. Para uma aplicação interativa, cada segundo extra pesa. Uma resposta que leva 3 segundos no ambiente local pode passar de 20 segundos quando o servidor começa a paginar memória.

NVMe ajuda, mas não faz milagre

Disco NVMe é relevante para carregar modelos, reindexar documentos, persistir bancos vetoriais e processar lotes de embeddings. Em RAG, coleções com milhares ou milhões de chunks podem gerar muitos arquivos pequenos, metadados e leituras aleatórias. Um storage lento aumenta o tempo de inicialização e prejudica tarefas de ingestão. Ainda assim, NVMe não resolve falta de RAM nem CPU saturada.

Uma configuração equilibrada para RAG pequeno seria 4 vCPUs, 16 GB de RAM e 100 GB NVMe. Para uma base documental maior, com PDFs, páginas HTML, transcrições e histórico de tickets, pense em 8 vCPUs, 32 GB de RAM e 200 GB NVMe, com backup separado. Se a aplicação também expõe APIs públicas, vale comparar com a lógica de dimensionamento apresentada em Cloud Server para APIs e automações, porque filas, rate limit e observabilidade continuam necessários mesmo quando o produto usa IA.

GPU, quantização e modelos: quando acelerar faz sentido

A GPU é a parte mais desejada e mais mal dimensionada em projetos de IA self-hosted. Ela pode reduzir bastante a latência de inferência, aumentar a quantidade de tokens gerados por segundo e permitir modelos maiores. Mas nem todo projeto precisa começar com GPU. Se o uso principal é gerar embeddings em lote, testar prompts, classificar textos curtos ou atender poucos usuários internos, uma instância CPU com boa RAM pode entregar resultado aceitável por uma fração do custo operacional.

CPU serve para embeddings e modelos pequenos

Modelos de embeddings como BGE pequeno, MiniLM e outras opções compactas podem rodar em CPU com desempenho razoável para volumes moderados. Um servidor com 4 a 8 vCPUs consegue processar documentos em filas, especialmente se a ingestão não precisa ser em tempo real. Para uma empresa que indexa 20 mil artigos internos uma vez por semana, por exemplo, talvez faça sentido rodar o processamento fora do horário comercial e manter a API de consulta em uma máquina separada.

Modelos de linguagem pequenos também podem funcionar em CPU quando quantizados. Um modelo de 3B ou 7B em Q4 pode ser útil para sumarização simples, extração de campos, classificação e assistentes internos com baixa concorrência. O cuidado está na expectativa. Se o usuário espera uma experiência parecida com serviços comerciais de LLM, com respostas longas em poucos segundos, CPU dificilmente será suficiente para muitos acessos simultâneos.

GPU muda latência e concorrência

GPU começa a fazer sentido quando o serviço precisa responder rápido, lidar com múltiplos usuários ou rodar modelos maiores. Uma instância com GPU de 16 GB de VRAM pode atender bem muitos casos com modelos de 7B quantizados, enquanto modelos maiores ou contextos longos pedem mais VRAM. O gargalo passa a ser VRAM, throughput e custo por hora. Também entra a complexidade de drivers, CUDA, compatibilidade do framework e monitoramento específico.

Para evitar desperdício, teste antes com um modelo menor e métricas simples: tempo até o primeiro token, tokens por segundo, uso de RAM, uso de VRAM, CPU steal, latência p95 e taxa de erro. Não publique promessa de performance sem benchmark controlado, porque dois provedores com a mesma quantidade nominal de vCPU podem ter resultados diferentes. Em Cloud Server para IA, a pergunta correta não é apenas se existe GPU, mas se a GPU combina com o modelo, o volume de requisições e a tolerância de custo do produto.

RAG, embeddings e bancos vetoriais em produção

Muitos projetos de IA self-hosted não começam pelo LLM, começam pelo RAG. A empresa quer consultar documentos internos, manuais, contratos, chamados de suporte ou páginas de conhecimento com mais precisão do que uma busca tradicional. Nesse caso, o servidor precisa lidar com ingestão, chunking, geração de embeddings, armazenamento vetorial, recuperação, reranking e chamada ao modelo gerador. Cada etapa tem um perfil de consumo diferente.

Arquitetura típica de RAG self-hosted

Uma stack simples pode ter Nginx na frente, uma API Python com FastAPI, um worker Celery ou RQ, Redis para fila, PostgreSQL com pgvector ou Qdrant para vetores, além de Ollama, vLLM ou llama.cpp para inferência. Em laboratório, tudo roda na mesma máquina. Em produção, isso cria risco. Se a inferência consome toda a RAM, a API cai junto. Se a ingestão de PDFs dispara CPU, as consultas ficam lentas. Se o banco vetorial cresce sem controle, o backup vira um problema.

Um exemplo de configuração inicial para RAG interno seria: Cloud Server 1 com 4 vCPUs e 8 GB de RAM para API, autenticação e painel administrativo; Cloud Server 2 com 8 vCPUs, 32 GB de RAM e 200 GB NVMe para banco vetorial e processamento de embeddings; instância separada com GPU apenas se a inferência local for requisito. Essa separação permite escalar o componente que dói sem migrar tudo de uma vez.

Separar componentes evita gargalos

A separação também melhora segurança. O banco vetorial pode ficar em rede privada, sem porta pública. A API expõe apenas HTTPS. O worker acessa documentos em um bucket ou volume protegido. Logs sensíveis podem ser mascarados antes de ir para uma ferramenta externa. Essa arquitetura parece mais trabalhosa, mas reduz o risco de uma falha simples derrubar o produto inteiro.

Para quem atende usuários no Brasil, latência de rede também entra na decisão. Se a API fica longe do usuário, o tempo de ida e volta soma com a latência da inferência. Em aplicações conversacionais, 150 ms a mais por chamada não parece muito, mas pipelines de RAG podem fazer várias chamadas internas. O artigo sobre VPS para APIs e microsserviços no Brasil aprofunda essa discussão de localização, latência e arquitetura distribuída, que também se aplica a produtos com IA.

Comparação prática de configurações

A tabela abaixo organiza perfis comuns de Cloud Server para IA. Ela não substitui benchmark, mas ajuda a evitar dois erros frequentes: comprar um servidor pequeno demais para produção ou contratar GPU antes de validar o modelo de uso. Os números são faixas técnicas, não recomendações comerciais fechadas. Preço, disponibilidade de região, GPU, bandwidth e storage variam por provedor e precisam de revisão humana nas páginas oficiais antes de publicação.

Perfil de uso	Configuração sugerida	Workloads adequados	Limites prováveis	Observações operacionais
Laboratório e protótipo	4 vCPUs, 8 GB RAM, 80 GB SSD ou NVMe	Testes com Ollama, embeddings pequenos, API interna, modelos 1B a 3B quantizados	Baixa concorrência, respostas lentas em LLM 7B, pouca folga para banco vetorial	Use Docker Compose, limite workers e monitore swap desde o primeiro teste
RAG interno em CPU	8 vCPUs, 32 GB RAM, 200 GB NVMe	pgvector ou Qdrant, ingestão de documentos, embeddings em fila, API para time interno	Inferência de LLM médio pode ficar lenta se rodar na mesma máquina	Separe banco e inferência quando p95 passar de 5 a 8 segundos
Inferência com GPU	8 a 16 vCPUs, 32 a 64 GB RAM, GPU com 16 GB ou mais de VRAM, 200 GB NVMe	LLM 7B quantizado, vLLM, múltiplos usuários, baixa latência	Custo por hora, disponibilidade regional, drivers e compatibilidade CUDA	Meça tokens por segundo, tempo até primeiro token e uso de VRAM
Produção segmentada	2 ou 3 servidores, API separada, banco vetorial separado, GPU opcional	Produto SaaS, chatbot com documentos, automações com IA, auditoria e logs	Mais complexidade de rede, deploy e backup	Use rede privada, snapshots testados, filas e rate limit por usuário

Como interpretar os números

Se você está no início, não precisa montar a arquitetura mais cara. Comece com CPU, modelo pequeno e métricas claras. Rode um conjunto fixo de prompts, simule 5, 10 e 20 requisições simultâneas, registre latência p50, p95 e p99, depois compare com a experiência esperada. Se o objetivo é atendimento interno, talvez 8 segundos seja aceitável. Se é uma API paga para clientes, 8 segundos pode ser um problema comercial.

Outro ponto é o armazenamento. Bases vetoriais crescem com chunks, metadados, versões de embeddings e documentos originais. Uma coleção de 100 mil chunks pode não parecer grande, mas reindexações, backups e ambientes de staging duplicam espaço. Planeje folga de 2 a 3 vezes o tamanho inicial. Para logs, defina retenção. Sem retenção, uma aplicação de IA com prompts longos pode ocupar dezenas de gigabytes em poucas semanas.

Provedores como DigitalOcean, Vultr, Linode, AWS Lightsail, Google Cloud, Azure, Oracle Cloud, Hetzner, Contabo, Locaweb, HostGator, Hostinger e LetsCloud podem aparecer em diferentes etapas da análise, mas os recursos exatos variam. LetsCloud pode ser considerada em cenários em que localização, pagamento local ou operação no Brasil sejam fatores relevantes, desde que storage, snapshots, backups, regiões e suporte sejam confirmados por plano. Para GPU, muitos projetos precisarão avaliar clouds com oferta específica de aceleradores.

Segurança, backups e operação contínua

IA self-hosted amplia a superfície de risco. Não é só proteger o servidor contra login SSH indevido. Você também precisa proteger prompts, documentos carregados por usuários, embeddings, chaves de API, logs e resultados gerados. Em muitos casos, a base vetorial contém pedaços de documentos sensíveis. Mesmo que os embeddings não sejam uma cópia legível do texto original, eles fazem parte do pipeline de dados e devem entrar na política de segurança.

Proteja modelos, prompts e dados sensíveis

O básico continua obrigatório: SSH com chave, senha desativada, firewall permitindo apenas portas necessárias, atualizações regulares, usuário sem root para a aplicação e TLS válido. Para APIs de inferência, adicione autenticação forte, rate limit por token, limite de tamanho de prompt e validação de arquivos enviados. Um usuário mal-intencionado pode tentar enviar PDFs enormes, prompts longos ou cargas repetidas para consumir CPU, RAM ou GPU.

Também pense em isolamento. Se o banco vetorial não precisa ficar público, coloque em rede privada. Se o worker processa documentos, ele não deve expor endpoint externo. Se há chaves para serviços de terceiros, use variáveis de ambiente ou secret manager, nunca commit no repositório. Logs devem mascarar dados pessoais, tokens e trechos sensíveis. Em RAG corporativo, registrar tudo parece ótimo para auditoria, mas pode criar um segundo repositório de dados confidenciais.

Observabilidade antes do incidente

Monitoramento precisa ir além de CPU e RAM. Acompanhe uso de disco, I/O wait, swap, tempo de fila, latência por etapa do RAG, quantidade de tokens por resposta, erros de timeout, uso de VRAM quando houver GPU e tamanho das coleções vetoriais. Um alerta de disco em 90% pode salvar a aplicação de uma falha feia, especialmente durante reindexação.

Backups merecem teste de restauração. Salvar snapshot sem validar restore é confiança demais. Para uma stack de RAG, o plano mínimo deve incluir backup do banco relacional, backup do banco vetorial, cópia dos documentos originais, versionamento de configurações e procedimento para reconstruir índices. Em alguns casos, reconstruir embeddings pode custar horas de processamento. Em outros, pode custar dinheiro se usar API externa. Documente o tempo esperado de recuperação e faça um teste real antes de colocar usuários importantes na plataforma.

Recomendações por perfil

Dev solo e laboratório técnico

Para um dev solo testando IA self-hosted, comece simples. Um Cloud Server com 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe já permite rodar Docker Compose, Ollama, uma API FastAPI, Redis e um banco pequeno. Use modelos de 1B a 3B quantizados, ou um 7B apenas para testes sem pressa. O objetivo nessa fase é validar fluxo, não vencer benchmark. Meça latência, consumo de memória e tamanho dos arquivos gerados. Se o servidor começar a usar swap com frequência, reduza contexto, troque o modelo ou separe o banco antes de aumentar custo.

Time pequeno com produto em validação

Para um time pequeno, a recomendação muda para confiabilidade. Use pelo menos 8 vCPUs, 16 a 32 GB de RAM e 150 a 200 GB NVMe se a stack inclui RAG, embeddings e banco vetorial. Separe filas para ingestão de documentos e limite concorrência de inferência. Se a experiência do usuário depender de respostas rápidas, teste uma instância com GPU por período curto antes de assumir custo mensal. Nessa fase, também entram deploy automatizado, ambiente de staging, logs centralizados e backups diários com restauração testada. A economia de colocar tudo na mesma VPS pode sair cara quando uma reindexação derruba a API.

Produção com usuários reais

Para produção, trate IA como plataforma, não como processo isolado. Uma arquitetura mínima saudável costuma separar API pública, banco vetorial e inferência. A API pode rodar em 2 a 4 vCPUs com 4 a 8 GB de RAM, o banco vetorial em 8 vCPUs com 32 GB de RAM e NVMe, e a inferência em CPU forte ou GPU conforme o modelo. Use rede privada, firewall restritivo, rate limit, observabilidade e plano de rollback. Se há dados sensíveis, revise retenção de prompts e logs com o time jurídico ou de segurança. O melhor Cloud Server para IA é o que mantém previsibilidade quando o uso cresce, não o que apenas roda o demo no primeiro dia.