A fatura da API chegou maior que a do mês passado outra vez, e ninguém consegue prever a do mês que vem. Ou aconteceu o oposto: a empresa comprou máquina cara para treinar modelo, colocou o serviço em produção nela e descobriu que, com doze pessoas perguntando ao mesmo tempo, a resposta trava. Os dois casos têm a mesma raiz, dimensionar gpu para inferência de ia com a régua do treinamento.

Servir um modelo tem outra economia: o que decide é quanto o usuário espera pelo primeiro token, quantas requisições simultâneas a máquina aguenta e quanto custa cada mil chamadas. Abaixo está a conta da inferência, da fórmula de VRAM ao comparativo entre máquina local, API paga e nuvem.

Treinar e servir são dois problemas diferentes

O treinamento é limitado por cálculo e por memória de estado: além dos pesos, a placa guarda gradientes, estados do otimizador e ativações. Em ajuste completo com precisão mista e otimizador Adam a conta fica em torno de 16 bytes por parâmetro, então um modelo de 7 bilhões pede perto de 112 GB antes das ativações.

A inferência não tem gradiente nem estado de otimizador. Sobram os pesos e o cache de atenção, e o mesmo modelo ocupa cerca de 14 GB em FP16, quase oito vezes menos. Só que ela troca um gargalo por outro: passa a ser limitada por largura de banda de memória, e uma GPU com o dobro de desempenho bruto em ponto flutuante, mas a mesma banda, entrega ganho quase nulo na geração de texto.

Por que a inferência é limitada por memória

A geração é autorregressiva: o modelo produz um token, devolve esse token para a entrada e produz o próximo. A cada token a placa lê todos os pesos saindo da VRAM rumo aos núcleos de cálculo. Daí sai um teto teórico simples, dividir a largura de banda pelo tamanho do modelo em bytes: uma placa de cerca de 1 TB/s servindo um modelo de 14 GB tem teto perto de 70 tokens por segundo, e na prática você colhe de 50% a 70% disso.

As duas fases do atendimento se comportam de forma oposta. O processamento do prompt de entrada, chamado de preenchimento, é paralelo e usa cálculo de verdade; a geração da resposta é limitada por banda. Resumir documento longo com resposta curta é dominado pela primeira fase, e um chat com pergunta curta e resposta longa, pela segunda.

A consequência aparece na compra. Ao avaliar uma placa de vídeo para workstation para servir modelo, olhe primeiro a VRAM, depois a largura de banda em GB/s, depois o suporte a baixa precisão nos núcleos tensores, e só então o desempenho bruto.

A conta de VRAM da inferência, parcela por parcela

Parcela 1: os pesos. É o número de parâmetros vezes os bytes de cada um, mais 10% a 20% de metadados e alinhamento.

Parcela 2: o cache de atenção. Para não recalcular tudo a cada token, o servidor guarda as chaves e os valores já processados. A fórmula é 2 (chaves e valores) vezes camadas, vezes cabeças de chave e valor, vezes dimensão por cabeça, vezes bytes de precisão, vezes tokens de contexto. Um modelo de 7 bilhões com 32 camadas e atenção clássica em FP16 gasta cerca de 0,5 MB por token: uma sessão de 8 mil tokens ocupa perto de 4 GB e vinte sessões simultâneas pedem 80 GB, quase seis vezes os pesos. Atenção agrupada leva isso a cerca de 128 KB por token, ou 20 GB nas mesmas vinte sessões.

Parcela 3: a folga de execução. Buffers do servidor, fragmentação, contexto de CUDA e ativações do preenchimento: reserve de 2 a 4 GB, ou de 10% a 15% da placa. Para uso individual em uma única máquina, o raciocínio está no guia sobre quanta VRAM para rodar LLM local.

Quantização: o que se ganha e o que se perde

Quantizar é representar os pesos com menos bits, e a memória cai na mesma proporção. O ganho não para na VRAM: como a inferência é limitada por banda, ler metade dos bytes por token significa quase o dobro de tokens por segundo.

O preço existe e varia. Em 8 bits com escalas bem calibradas o resultado é difícil de distinguir do original em conversa, classificação e extração. Em 4 bits ainda é utilizável, mas a degradação aparece antes em raciocínio de várias etapas, código, matemática exata e contexto longo, onde pequenos desvios se acumulam. Teste com 50 a 100 casos reais do seu fluxo, e lembre que um modelo maior em 4 bits costuma render mais que um pequeno em 16 bits na mesma VRAM. A Hugging Face descreve os métodos no guia de quantização do Transformers.

Latência e taxa de transferência: o efeito do lote

• Tempo até o primeiro token: a espera para a resposta começar. Abaixo de 1 segundo parece instantâneo, acima de 3 segundos parece travamento.
• Tempo por token de saída: o ritmo depois que ela começa. De 20 a 30 tokens por segundo já supera a leitura confortável de uma pessoa.
• Taxa de transferência: o total somando todos os usuários. É a métrica de custo.

O processamento em lote liga as três. Quando o servidor agrupa requisições e as processa juntas, os pesos são lidos da VRAM uma vez só e servem a todas, e a taxa de transferência sobe porque a leitura cara foi amortizada. Em compensação cada requisição espera a formação do lote e divide a placa, então a latência individual piora. Servidores modernos atenuam o conflito com lote contínuo, que insere e remove requisições a cada passo: a documentação do vLLM descreve essa mecânica e a paginação do cache de atenção, a NVIDIA cobre terreno equivalente na documentação do TensorRT-LLM e a AMD, na documentação do ROCm.

A escolha é de negócio. Atendimento em tempo real prioriza latência e aceita placa ociosa parte do dia; fila noturna, classificação de acervo e embeddings priorizam taxa de transferência com lote grande.

Tabela: carga de inferência, VRAM e a métrica que manda

Faixas para operação com folga, de 5 a 20 requisições simultâneas.

Se o seu uso é mais análise e experimentação do que serviço em produção, veja o guia de GPU para data science.

Máquina local, API paga ou instância em nuvem

A nuvem ganha em três situações: carga intermitente, com a máquina parada a maior parte do tempo; necessidade pontual de uma placa que você jamais compraria; e ausência de equipe ou local para manter equipamento de pé.

O ponto de equilíbrio é aritmético. Pegue o gasto mensal recorrente, multiplique por 36 e compare com o custo total da máquina equivalente no mesmo período. Uso estável cujo recorrente de três anos supera o custo da máquina puxa para a compra; uso que oscila é melhor absorvido pelo aluguel. E há o caminho misto: volume constante na máquina local, pico na nuvem.

Quando a workstation resolve e quando a carga pede servidor

Uma workstation bem dimensionada resolve mais inferência de produção do que a maioria das empresas imagina: público interno ou controlado, concorrência real em dezenas e não em centenas de requisições simultâneas, um único modelo principal e uma janela de manutenção de algumas horas que não quebra ninguém. É o desenho do guia de workstation para inteligência artificial, aplicado ao lado de servir.

A carga pede infraestrutura de servidor quando entra qualquer um destes elementos: disponibilidade contratada em acordo de nível de serviço, redundância com máquina reserva quente, mais de duas placas sobre o mesmo modelo, vários modelos em paralelo com isolamento, ou usuários externos pagantes. A comparação está no artigo sobre servidor para machine learning.

Erros comuns ao dimensionar GPU para inferência de IA

Dimensionar pelo pico teórico e não pela concorrência real. Ter 500 usuários cadastrados não significa 500 requisições simultâneas. Meça quantas chamadas coexistem no mesmo segundo: dimensionar pelo total de cadastros é o jeito mais rápido de comprar o triplo do que você precisa.

Esquecer o cache de contexto. É o erro mais frequente e o mais caro. A máquina passa nos testes com sessão curta e derruba a placa por falta de memória quando dez pessoas abrem conversas longas ao mesmo tempo. Fixe um limite de contexto por sessão e um teto de sessões antes de calcular a VRAM.

Ignorar fonte e refrigeração em operação contínua. Inferência de produção é carga sustentada por horas, não render noturno que começa e termina. Duas placas de 300 a 450 W cada, mais processador e periféricos, pedem fonte com folga de 20% a 30% sobre o pico medido e fluxo de ar planejado. Placa que reduz frequência por calor derruba a taxa de transferência em silêncio, e isso aparece como lentidão que ninguém explica.

Medir com lote 1 e projetar de forma linear. O comportamento sob lote não é proporcional. Teste com o tráfego esperado, prompts reais e o servidor de produção.

Configuração Zenion recomendada

A Zenion especifica a máquina a partir do modelo servido, do contexto máximo e da concorrência medida, não de uma lista pronta de peças.

A memória de sistema deve ficar entre 1,5 e 2 vezes a VRAM instalada, porque carregar e trocar modelo passa pela RAM antes de chegar à placa. O processador não precisa ser o mais rápido do catálogo, mas precisa de linhas PCIe para alimentar as placas em x16 real.

Perguntas frequentes

Quanta VRAM é preciso para inferência de IA?

Some os pesos, o cache de atenção, que cresce com contexto e requisições, e 10% a 15% de folga. Para um modelo de 7 bilhões em FP16 com 8 mil tokens de contexto e dez sessões, 24 GB é o piso e 32 GB dá conforto.

Por que a inferência de modelo de linguagem é limitada por memória?

Porque a geração é token a token e cada token exige ler todos os pesos saindo da VRAM. Essa leitura satura a largura de banda antes dos núcleos de cálculo, e por isso duas placas com banda parecida entregam velocidade parecida mesmo com cálculo diferente.

Quantizar em 4 bits estraga a qualidade do modelo?

Não estraga, mas degrada de forma desigual. Conversa, classificação e extração sobrevivem bem; raciocínio de várias etapas, código e matemática exata sentem mais. Teste com casos reais do seu fluxo, porque a resposta muda a cada modelo.

Dá para rodar um modelo de 70 bilhões de parâmetros em uma placa de 24 GB?

Não com margem operacional. Em 4 bits os pesos ocupam de 36 a 40 GB, já acima da placa antes do cache de contexto. O caminho é uma placa de 48 GB para uso leve, duas para produção, ou um modelo de 30B quantizado.

Compensa mais alugar GPU na nuvem ou comprar a máquina?

Depende da estabilidade do uso. Multiplique o gasto mensal por 36 e compare com o custo total da máquina equivalente no mesmo período, energia e manutenção incluídas. Uso constante e dado sensível puxam para a máquina própria; picos sazonais, para o aluguel.

O próximo passo

Antes de cotar qualquer placa, levante três números: o modelo que vai rodar e em qual precisão, o contexto máximo por sessão e o pico real de requisições simultâneas, medido e não estimado. Com eles a conta de VRAM fecha em minutos e a discussão deixa de ser sobre qual placa é mais forte.

Se quiser essa conta feita junto com quem especifica máquina de inferência todo mês, a equipe da Zenion analisa o seu fluxo, dimensiona a configuração e mostra o ponto de equilíbrio frente ao que você paga hoje de nuvem ou API.