Servidor para rodar IA na empresa — como dimensionar

A pergunta chega quase sempre na forma errada: “que servidor eu preciso comprar para rodar IA?”. A forma útil é outra: quantos gigabytes de memória de vídeo o modelo que eu quero rodar precisa ter disponíveis, ao mesmo tempo, para o número de pessoas que vão usar.

A diferença não é retórica. Um servidor com muitos núcleos e muita memória RAM, mas sem placa de vídeo com memória suficiente, não roda o modelo — ou roda a uma velocidade que ninguém aceita. Já um servidor modesto com a placa certa roda.

Esta é a parte de infraestrutura da decisão. A parte de perímetro — se o dado pode ou não sair da empresa — está em outro texto, e é ela que determina se este aqui é sequer necessário.

Duas leituras imediatas dessa tabela. A primeira: um modelo de 70B em precisão plena não cabe em uma única placa de nenhuma geração atual — exige várias placas ou quantização agressiva. A segunda: um modelo de 8B em INT4 cabe folgado em hardware que muita empresa já tem.

É a conta que separa “projeto de infraestrutura” de “roda no que existe”.

Os pesos são o piso, não o total. Enquanto o modelo gera a resposta, ele mantém em memória um cache com o estado do que já foi lido e escrito — o KV cache. Essa memória é adicional aos pesos, e é ela que costuma explicar por que um servidor que rodava bem em teste passa a falhar em produção.

A NVIDIA publica a fórmula e um exemplo: para um modelo de sete bilhões de parâmetros em FP16, com uma requisição de quatro mil tokens de contexto, o cache fica em torno de 2 GB — e cresce linearmente com o tamanho do contexto e com o número de requisições simultâneas.

Traduzindo para decisão: dez pessoas usando ao mesmo tempo, com documentos longos, é um dimensionamento bem diferente de uma pessoa testando com perguntas curtas. O teste com uma pessoa não prevê o comportamento com dez.

A documentação do vLLM, um dos servidores de inferência mais usados, expõe exatamente esses dois controles: o comprimento máximo de contexto e o número máximo de sequências simultâneas são os parâmetros que se ajustam para caber na memória disponível. São eles que, na prática, decidem quantas pessoas o servidor atende.

Duas observações sobre essa tabela, ambas de ordem prática.

A primeira é a diferença de potência. A L4, com 24 GB, declara até 72 W — cabe em servidor comum, sem alteração de energia nem de refrigeração. A H100 declara até 700 W por placa. Não são o mesmo projeto de sala.

A segunda: placa de vídeo de consumo aparece na tabela porque funciona tecnicamente e é usada em laboratório. Antes de usá-la em produção, vale ler a licença de uso do fabricante e confirmar o que ela permite em ambiente de datacenter — é uma restrição contratual, não técnica, e passa despercebida com frequência.

Quantizar é reduzir a precisão dos números do modelo para que ele ocupe menos memória. É a alavanca mais eficaz do dimensionamento — e é uma troca, não um almoço grátis.

A documentação da Hugging Face enquadra a troca como “eficiência contra acurácia” e registra o essencial: a quantização para int4 normalmente causa queda de acurácia maior que a int8. Não diz quanto, porque depende do modelo e da tarefa — e é por isso que a etapa de avaliação não pode ser pulada.

Os métodos diferem no que protegem. O GPTQ ajusta cada linha da matriz de pesos para minimizar o erro da conversão, restaurando para 16 bits durante a inferência. O AWQ preserva seletivamente a fração de pesos mais importante para o desempenho do modelo, em vez de tratar todos igualmente. O formato GGUF, usado por llama.cpp e Ollama, oferece uma escala contínua de níveis — de precisão plena até 1,75 bit por peso — em que cada nível é um ponto diferente na mesma troca.

A regra operacional que usamos: quantização é decisão que se valida com a tarefa real da empresa, não com teste genérico. Um modelo quantizado que responde bem sobre conhecimento geral pode degradar exatamente na extração estruturada que o processo depende.

Repare no padrão de mistura de especialistas, presente em Llama 4, Qwen3, Gemma 4 e DeepSeek: o modelo tem muitos parâmetros no total, mas ativa só uma fração por token. Isso melhora a velocidade — e não reduz a memória necessária, porque os pesos precisam estar carregados para que o roteamento possa escolher entre eles. É a confusão mais comum no dimensionamento de modelo MoE.

É possível, está documentado, e tem limite claro.

O llama.cpp foi construído exatamente para isso: implementação em C e C++ sem dependências, com suporte a instruções vetoriais de x86 e ARM, e com inferência híbrida entre CPU e GPU para acelerar parcialmente modelos maiores que a memória de vídeo disponível. O vLLM também mantém backend de CPU suportado em x86, ARM, Apple Silicon e IBM Z, com ressalvas registradas na própria documentação — em processadores AMD Zen, por exemplo, float16 não é suportado.

O Ollama publica orientação de memória por tamanho de modelo: 8 GB de RAM para modelos de 7B, 16 GB para 13B e 64 GB para 70B. E permite forçar execução somente em CPU.

O que a documentação não promete é velocidade. Em CPU, a geração é mais lenta por um fator que depende do modelo e do hardware. Para uso interativo — alguém esperando a resposta na tela — costuma ser insuficiente. Para processamento em lote, à noite, sem ninguém esperando, costuma bastar. É uma decisão de tipo de uso, não de orçamento.

Entre “usar API pública” e “comprar servidor” existe um terceiro arranjo: instância com placa de vídeo em nuvem, dedicada à empresa. Os três grandes provedores documentam famílias de máquina com GPU para inferência — a AWS nas famílias G e P, a Azure na série NC, o Google Cloud nas famílias A e G.

Esse arranjo mantém o controle sobre qual modelo roda e qual versão, sem exigir sala, energia nem compra de equipamento. Em compensação, o dado passa a residir na infraestrutura do provedor de nuvem — o que reabre a questão de perímetro e de região que motivou a discussão em primeiro lugar.

Não existe arranjo que resolva os três eixos ao mesmo tempo: controle total, esforço mínimo de operação e perímetro fechado. O diagnóstico serve para descobrir qual dos três a empresa realmente precisa priorizar.

1. NVIDIA Technical Blog, “Mastering LLM Techniques: Inference Optimization”
2. NVIDIA Technical Blog, “Mastering LLM Techniques: Inference Optimization” (seção de KV cache)
3. Hugging Face Transformers, “Quantization concepts”
4. Hugging Face Transformers, “GPTQ”
5. Hugging Face Transformers, “AWQ”
6. Hugging Face Hub, “GGUF”
7. vLLM, “Conserving Memory”
8. vLLM, “Installation — GPU”
9. vLLM, “Installation — CPU”
10. Ollama, “Hardware support”
11. Ollama, biblioteca de modelos — página do Llama 2
12. llama.cpp — repositório oficial (ggml-org)
13. NVIDIA, “L4”
14. NVIDIA, “L40S”
15. NVIDIA, “A100 Tensor Core GPU — Data Sheet”
16. NVIDIA, “H100 Tensor Core GPU”
17. NVIDIA, “H200 Tensor Core GPU”
18. NVIDIA, “GeForce RTX 5090”
19. NVIDIA DGX SuperPOD Data Center Design (DGX H100), “Planning a Data Center Deployment”
20. NVIDIA, “DGX B200 User Guide”
21. Meta AI, “Introducing Llama 3.1: Our most capable models to date”, 23 de julho de 2024
22. Meta, model card “Llama-3.3-70B-Instruct”
23. Hugging Face, “Welcome Llama 4 Maverick & Scout on Hugging Face”
24. Alibaba, model card “Qwen2.5-72B-Instruct”
25. Alibaba — anúncio oficial do Qwen3, 29 de abril de 2025
26. Google AI for Developers, “Gemma releases”
27. Google, “Gemma 4: Byte for byte, the most capable open models”, 2 de abril de 2026
28. Mistral AI, model card “Mistral-7B-v0.3”
29. Mistral AI, model card “Mixtral-8x7B-v0.1”
30. DeepSeek, model card “DeepSeek-V3”
31. DeepSeek, repositório oficial “DeepSeek-R1”
32. AWS, “Amazon EC2 Instance Types — Accelerated computing”
33. Microsoft Learn, “NC family VM size series”
34. Google Cloud, “GPU machine types” (Compute Engine)