IA generativa nos seus próprios servidores: quanta memória de GPU um modelo de linguagem privado precisa

Para rodar um modelo de IA generativa (GenAI) nos seus próprios servidores, some duas coisas: os pesos do modelo e a memória ocupada pelas requisições que ele está respondendo no mesmo momento. Na precisão usual de 16 bits, os pesos precisam de cerca de 2 GB de memória de GPU por bilhão de parâmetros, então um modelo com 32,8 bilhões de parâmetros precisa de cerca de 66 GB antes de responder a qualquer pessoa. Depois, cada requisição acrescenta memória na proporção do seu tamanho, e é essa parte que decide quantas requisições o servidor consegue atender ao mesmo tempo.

O que ocupa a memória da GPU quando um modelo de linguagem roda?

Um modelo de linguagem normalmente roda em GPUs, processadores feitos para o tipo de cálculo que os modelos fazem, e o modelo precisa ficar na memória das próprias GPUs enquanto trabalha. Essa memória guarda:

• Os pesos, os números que o modelo aprendeu no treinamento, carregados uma vez e mantidos lá
• O cache KV, a memória de trabalho do modelo para cada requisição que ele está respondendo
• Espaço de trabalho para o software que serve o modelo

Os pesos ficam fixos assim que você escolhe um modelo e uma precisão. O cache KV cresce com o número de requisições respondidas ao mesmo tempo e com o tamanho delas. As duas coisas podem ser calculadas antes de você comprar qualquer coisa.

Quanta memória os pesos do modelo ocupam?

O tamanho de um modelo é contado em parâmetros, e a precisão é o número de bits usados para guardar cada um. O guia do Hugging Face para rodar modelos com eficiência, consultado em 27 de outubro de 2026, observa que “quase todos os modelos são treinados em bfloat16 hoje em dia”, um formato de 16 bits que ocupa 2 bytes por parâmetro. A regra prática dele: “carregar os pesos de um modelo com X bilhões de parâmetros exige cerca de 2 * X GB de VRAM em precisão bfloat16/float16”, em que VRAM é a memória da GPU.

O exemplo do próprio guia é o Llama 2 70B, com cerca de 140 GB só para os pesos. O Qwen3-32B, um modelo de pesos abertos lançado sob a licença Apache 2.0, tem 32,8 bilhões de parâmetros segundo o model card, então os pesos dele ocupam cerca de 66 GB. Pesos abertos quer dizer que o criador publica os arquivos do modelo para qualquer pessoa rodar.

A quantização guarda os pesos em menos bits. Em 8 bits, um parâmetro ocupa 1 byte, e em 4 bits, meio byte, então o mesmo modelo precisa de cerca de 33 GB ou de pouco mais de 16 GB. O time do Qwen publica uma versão em 8 bits, o Qwen3-32B-FP8.

O guia do Hugging Face diz que os pesos “podem ser quantizados para 8 ou 4 bits sem uma perda significativa de desempenho”. Ele também avisa que a quantização em 4 bits “na prática pode, muitas vezes, levar a resultados diferentes” dos de 8 ou 16 bits, e acrescenta: “Cabe ao usuário testar.” Passe as suas próprias perguntas de teste por qualquer versão comprimida antes de confiar nela.

Quanta memória cada requisição acrescenta?

Enquanto o modelo escreve uma resposta, ele guarda valores para cada token que já leu e escreveu, para não ter de calculá-los de novo a cada palavra nova. Um token é um pedaço de palavra. Esses valores guardados são o cache KV, abreviação de key-value cache. Um post de 2023 dos criadores do vLLM, um programa open source para servir modelos, observa que o cache “ocupa até 1,7 GB para uma única sequência no LLaMA-13B”.

Você pode calcular o tamanho para o seu próprio modelo a partir das configurações publicadas. Para cada token, o cache guarda dois conjuntos de números, chaves e valores, para cada camada. O Qwen3-32B tem 64 camadas e guarda no cache 8 cabeças de atenção de 128 números cada, segundo o model card e o arquivo de configuração dele. A 2 bytes por número, isso dá 2 × 64 × 8 × 128 × 2 bytes, cerca de 262 KB por token.

Portanto, uma requisição de 8.000 tokens, como uma pergunta longa com trechos encontrados nos seus documentos mais a resposta, ocupa cerca de 2,1 GB até a resposta terminar. O contexto nativo completo do modelo, de 32.768 tokens, ocupa cerca de 8,6 GB.

Conte as requisições respondidas no mesmo momento, não as pessoas com acesso. Quem usa um assistente passa a maior parte do tempo lendo respostas e digitando perguntas, enquanto um sistema que processa um acúmulo de documentos pode manter cada GPU ocupada a noite inteira.

Quantas GPUs isso significa?

GPUs de data center vêm com uma quantidade fixa de memória. As páginas de especificações da Nvidia, consultadas no mesmo dia, informam 80 GB para a H100 na versão SXM e 94 GB na versão NVL, 141 GB para a H200 e 48 GB para a L40S.

O software que serve o modelo deixa parte de cada GPU livre. A documentação do vLLM descreve a configuração como “a fração da memória da GPU a ser usada pelo executor do modelo” e dá 0,92 como padrão na versão atual. Em uma H100 NVL de 94 GB, isso dá cerca de 86 GB. Os pesos do Qwen3-32B em 16 bits ocupam cerca de 66 GB disso. Sobram uns 21 GB para o cache KV e o restante da memória de trabalho do software, o que dá espaço para menos de dez requisições de 8.000 tokens ao mesmo tempo.

Com os pesos em 8 bits, sobram cerca de 54 GB, o suficiente para umas 25 requisições assim. Em uma H100 de 80 GB, os pesos em 16 bits deixam cerca de 8 GB, espaço para menos de quatro.

Quando os pesos não cabem em uma GPU, o modelo é dividido entre várias GPUs no mesmo servidor. A documentação do vLLM diz que, “se o modelo for grande demais para uma única GPU, mas couber em um único nó com várias GPUs, use paralelismo de tensores”, que é o nome que ela dá a essa divisão. Um modelo de 70 bilhões de parâmetros em precisão de 16 bits não cabe em uma GPU de 94 GB, e em duas delas sobram cerca de 33 GB para as requisições.

Esses números dizem se um modelo cabe. A velocidade com que ele responde depende das GPUs, do tamanho das respostas e da carga, e só um teste com as suas próprias requisições pode mostrar isso.

Devemos alugar GPUs na nuvem ou comprar servidores?

Alugar primeiro é um jeito mais barato de descobrir do que você precisa. A tabela pública de preços da Microsoft para o Azure, consultada no mesmo dia, traz estes preços de pagamento por uso para máquinas virtuais Linux na região East US:

• Uma H100 NVL de 94 GB (Standard_NC40ads_H100_v5): US$ 6,98 por hora, cerca de US$ 5.100 por um mês de 730 horas
• Duas H100 NVL de 94 GB (Standard_NC80adis_H100_v5): US$ 13,96 por hora, cerca de US$ 10.200 por mês
• Oito H100 de 80 GB (Standard_ND96isr_H100_v5): US$ 98,32 por hora, cerca de US$ 71.800 por mês

Esses são preços de tabela para pagamento por hora, e a capacidade reservada é vendida em outras condições. Os preços mudam, então peça cotações a mais de um fornecedor para a configuração que os seus testes indicarem.

Servidores próprios fazem sentido quando a carga é estável e você sabe qual modelo vai rodar, ou quando as suas regras exigem que o hardware fique no seu próprio prédio. O custo, então, inclui as pessoas que mantêm esses servidores funcionando, assunto do artigo sobre quem opera um sistema de LLM sem um time de ML.

Como dimensionamos o sistema para o nosso próprio uso?

• Teste um ou dois modelos candidatos com perguntas reais do seu trabalho e fique com aquele cujas respostas forem aprovadas
• Estime quantas requisições o sistema vai responder ao mesmo tempo no horário de pico e qual é o tamanho de uma requisição típica, contando a pergunta, os trechos encontrados nos seus documentos e a resposta
• Calcule a memória para os pesos e para o cache KV como mostrado acima e deixe uma margem
• Alugue GPUs por alguns dias e rode um teste de carga com os seus próprios prompts nesse pico
• Compre ou reserve capacidade depois que o teste terminar

O vLLM inclui um comando para esse tipo de teste, o vllm bench serve. Ele pode reportar percentis de “ttft” e “tpot”, o tempo até o primeiro token e o tempo por token de saída. Antes do teste, decida quanto a sua equipe vai esperar pelas primeiras palavras de uma resposta e avalie os resultados pelo horário de pico.

Quem pode montar isso?

O seu time de infraestrutura pode operar os servidores com GPU se já cuida de servidores próprios, e o fornecedor de hardware ou de nuvem pode ajudar com as máquinas. Conectar o modelo aos seus documentos, ao login e às permissões, e testar as respostas dele, é trabalho de quem constrói o sistema em torno do modelo.

A empresa ou o time que você contratar deve mostrar as contas: qual modelo e qual precisão, quanta memória vai para os pesos e quanta para o cache KV, que carga o teste usou e o que ele mediu. Peça esses números antes de aprovar um orçamento de hardware.

Onde a amBrain se encaixa?

O único projeto com modelo de linguagem que a amBrain descreve publicamente é este: “Levamos à produção uma integração de LLM dentro do perímetro de FinTech de um cliente: extração e normalização de avisos não estruturados de corretoras e de venues — eventos corporativos, alterações de instrumentos e de margem — em registros estruturados que o sistema de trading consome.”

Este artigo não é um estudo de caso e não descreve nenhum trabalho para clientes. A frase citada não diz qual modelo esse sistema usa, em que hardware nem onde ele roda. Os números acima são cálculos feitos a partir de especificações e tabelas de preços publicadas, não medições desse projeto nem de nenhum outro trabalho da amBrain.

As empresas, os modelos e os produtos citados aqui são citados com base nas páginas que publicaram, e o artigo não afirma nenhuma relação entre a amBrain e qualquer um deles. Ele não traz preços, prazos nem condições da amBrain.

A amBrain constrói software desde 2019. Ela trabalha em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time. A frase dela sobre propriedade é: “O cliente mantém a propriedade integral do produto e do código, exceto dos nossos componentes reutilizáveis.” Se a amBrain estiver na sua lista curta, peça a ela as mesmas contas que a qualquer outra empresa.