A pergunta chega sempre no mesmo formato: quanto de máquina eu preciso para rodar isso? E a resposta honesta, antes de qualquer número, é outra pergunta: rodar o quê, exatamente?
Dimensionar servidor para IA é diferente de dimensionar servidor para site. Num site, a variável dominante é quantas pessoas acessam ao mesmo tempo. Num projeto de IA, a variável dominante é o que acontece dentro de cada requisição, e requisições aparentemente idênticas podem ter custos computacionais que diferem em uma ordem de grandeza.
Três cargas diferentes, três contas diferentes
Antes de olhar qualquer especificação, é preciso saber em qual destes três grupos o seu projeto se encaixa. Eles não competem entre si, e muitos projetos têm os três ao mesmo tempo.
1. Orquestração
A aplicação recebe um pedido, chama um modelo externo por API, trata a resposta e devolve. O trabalho pesado acontece na casa do fornecedor. Aqui o seu servidor faz o que qualquer aplicação web faz: receber, aguardar, responder. O gargalo é rede e tempo de espera, não processamento.
2. Processamento auxiliar
A aplicação lê arquivos, quebra documentos em pedaços, gera embeddings, consulta banco, monta contexto. Não roda o modelo grande, mas faz bastante trabalho de CPU e usa memória de forma irregular, com picos quando um documento grande entra. O gargalo é memória.
3. Inferência local
O modelo roda na sua máquina. Aqui a conta muda de natureza, porque o modelo inteiro precisa caber na memória disponível antes de responder qualquer coisa. O gargalo é quanto o modelo pesa.
Memória: a única conta que não perdoa
Nas outras dimensões, faltar recurso deixa lento. Na memória, faltar recurso simplesmente não funciona. Se o modelo não cabe, ele não carrega.
A regra prática para estimar um modelo aberto é multiplicar a quantidade de parâmetros pelo espaço que cada parâmetro ocupa, que depende da precisão usada. Em quantização de 4 bits, cada bilhão de parâmetros ocupa aproximadamente meio gigabyte. Em 8 bits, aproximadamente um gigabyte. A partir daí:
- Some o peso do modelo.
- Some a memória do contexto, que cresce com o tamanho da conversa e pode ser significativa em prompts longos.
- Some o que o sistema operacional e os outros serviços já consomem.
- Deixe folga. Servidor que opera no limite da memória não degrada aos poucos, ele morre de uma vez.
Para orquestração e processamento auxiliar, a conta é mais simples, mas o princípio é o mesmo: meça o pico, não a média. Um fluxo que consome pouco durante o dia e explode quando processa um lote de arquivos precisa ser dimensionado pelo lote.
CPU: núcleos importam menos do que parece
Existe uma tentação de resolver tudo comprando mais núcleos. Para a maioria dos projetos de IA que não fazem inferência local, isso é dinheiro mal gasto. Aplicações que passam o tempo esperando resposta de API não ficam mais rápidas com mais núcleos, ficam mais rápidas com mais concorrência bem configurada.
Onde o núcleo pesa de verdade é no processamento auxiliar, que costuma ser trabalho sequencial e intenso: ler arquivo, converter, dividir, gerar embedding. E, quando não há placa de vídeo, na própria inferência, que passa a depender inteiramente do processador e fica lenta de um jeito que assusta quem testou antes no notebook.
Disco: velocidade antes de tamanho
Aqui o erro mais comum é olhar só a capacidade. Um projeto de IA guarda modelos, que são arquivos grandes, e guarda índices de banco vetorial, que são arquivos acessados o tempo todo. As duas coisas pedem coisas diferentes.
Modelo pede espaço e é lido uma vez, no carregamento. Índice vetorial pede velocidade de leitura aleatória, porque cada consulta bate em posições diferentes do arquivo. É por isso que armazenamento NVMe muda tanto a percepção de desempenho num projeto desse tipo: não é o tamanho do disco que aparece para o usuário, é o tempo de cada busca.
Como medir sem chutar
A forma mais confiável de dimensionar é medir o que o projeto já faz, mesmo rodando no seu computador. Três medições resolvem quase tudo:
- Memória no pico. Rode a operação mais pesada que o projeto faz e observe o consumo máximo, não o médio.
- Tempo por operação. Cronometre uma execução completa. Isso diz se o gargalo é espera de rede ou processamento próprio.
- Crescimento do armazenamento. Processe um volume conhecido de dados e meça quanto o índice cresceu. Multiplique pelo volume total previsto.
Com esses três números, a escolha do servidor deixa de ser opinião. Sem eles, qualquer recomendação é chute, inclusive as que vêm em tabela comparativa bonita.
Comece menor do que o medo pede
Há uma assimetria útil a favor de quem começa modesto: aumentar recurso num servidor virtual é rápido, e diminuir também. O custo de começar pequeno e crescer é algumas horas de ajuste. O custo de começar grande é pagar meses por capacidade ociosa enquanto o projeto ainda está descobrindo o que é.
A exceção é a memória em inferência local. Nesse caso específico, subdimensionar não deixa lento, impede de funcionar, e vale acertar de primeira.
Se você já tem os três números e quer ver o que eles significam em máquina real, dá para comparar as opções de VPS da StayCloud com o que mediu.
