Em infraestrutura de IA, a memória da GPU não é uma característica entre outras. É o limite que decide o que você consegue rodar e o que fica fora de alcance.
A regra base: para inferência, um modelo precisa de aproximadamente 2 GB de VRAM por bilhão de parâmetros em precisão de 16 bits, caindo para cerca de 0,5 GB por bilhão quando quantizado em 4 bits. Para treinamento completo, multiplique por três a quatro — pesos, gradientes e estados do otimizador ocupam memória simultaneamente. Ajuste fino com técnicas como LoRA reduz drasticamente esse custo, permitindo adaptar modelos grandes em hardware modesto. Comece pela pergunta de qual modelo você precisa rodar; a VRAM sai dessa conta, não do orçamento.
Em quase toda outra área da computação, memória é uma questão de conforto: mais memória permite trabalhar com folga, menos memória obriga a otimizar. Em infraestrutura de IA, a memória da placa de vídeo funciona de outro jeito.
Ela é binária. Ou o modelo cabe, ou não roda. Não existe versão degradada, não existe "roda devagar". Se os pesos não entram na VRAM, o processo simplesmente falha.
Por isso, toda especificação de máquina para IA deveria começar por essa conta — e não pelo orçamento disponível, como costuma acontecer.
Um modelo é essencialmente um conjunto de parâmetros numéricos. A memória que ele ocupa depende de quantos parâmetros são e de quantos bytes cada um usa.
Em precisão de 16 bits — o padrão para inferência de qualidade —, cada parâmetro ocupa 2 bytes. Daí sai a regra prática:
| Modelo | 16 bits | 8 bits | 4 bits |
|---|---|---|---|
| 7 bilhões de parâmetros | ~14 GB | ~7 GB | ~4 GB |
| 13 bilhões | ~26 GB | ~13 GB | ~7 GB |
| 34 bilhões | ~68 GB | ~34 GB | ~18 GB |
| 70 bilhões | ~140 GB | ~70 GB | ~37 GB |
Os valores são aproximados e não incluem a memória do contexto — o espaço ocupado pela conversa ou pelo documento sendo processado, que cresce com o tamanho da janela e com o número de requisições simultâneas. Reserve de 15 a 25% acima do número da tabela para operação real.
Reduzir a precisão dos parâmetros permite rodar modelos muito maiores em hardware acessível. É uma técnica legítima e amplamente usada.
Mas ela não é gratuita. Há perda de qualidade, e a magnitude dessa perda depende do modelo, da tarefa e do método de quantização. Em alguns casos é imperceptível; em outros, degrada justamente o comportamento que você precisava.
A recomendação honesta: meça no seu caso. Rode o seu conjunto de avaliação com o modelo em precisão cheia e quantizado, e compare. Aceitar a perda deve ser uma decisão informada, não uma suposição.
A linha é a capacidade da placa. As colunas mostram o que precisa caber abaixo dela em cada modo de uso.
Aqui está o erro de dimensionamento mais frequente que encontramos.
Alguém verifica que o modelo de 7 bilhões cabe em 16 GB, compra a placa, e descobre que não consegue treinar nada. Porque treinamento não guarda apenas os pesos.
Durante o treinamento, a memória precisa acomodar simultaneamente:
Somando tudo, treinamento completo consome tipicamente de três a quatro vezes a memória da inferência. O modelo que roda em 16 GB pode exigir 60 GB ou mais para ser treinado do zero.
A maioria das empresas não precisa treinar um modelo do zero. Precisa adaptar um modelo existente ao seu domínio — vocabulário do setor, formato de resposta, conhecimento específico.
Foi para isso que surgiram as técnicas de adaptação por baixo posto, das quais LoRA é a mais conhecida. A ideia é elegante: em vez de atualizar todos os bilhões de parâmetros, você congela o modelo original e treina um conjunto pequeno de matrizes adicionais que se somam ao comportamento dele.
O efeito na memória é dramático. Como o modelo original não é atualizado, não é preciso guardar gradientes e estados do otimizador para ele — apenas para a fração adicionada, que costuma representar menos de 1% dos parâmetros.
Na prática, isso viabiliza ajuste fino de modelos grandes em uma única placa profissional, algo que exigiria um servidor inteiro se feito por treinamento completo. Combinado com quantização, o alcance aumenta ainda mais.
Você precisa criar um modelo novo, adaptar um existente ao seu domínio, ou apenas servir um modelo pronto? As três respostas apontam para máquinas muito diferentes. A maioria dos projetos corporativos está na segunda ou terceira categoria — e frequentemente é dimensionada como se estivesse na primeira.
Essa pergunta aparece sempre, e a resposta depende do que limita você.
Se o modelo cabe em uma placa, uma GPU maior quase sempre vence. Dividir um modelo entre placas exige comunicação constante entre elas, e essa comunicação vira o novo gargalo. A soma de VRAM de duas placas não equivale a uma placa com o dobro.
Se o modelo não cabe, não há escolha: é preciso distribuir. E aqui a qualidade da interconexão entre as placas passa a determinar o desempenho tanto quanto a capacidade individual delas. Placas ligadas por um barramento lento escalam mal, independentemente de quão boas sejam isoladamente.
Se o objetivo é atender muitas requisições simultâneas, várias placas fazem sentido de outra forma: cada uma serve um conjunto de requisições de forma independente, sem precisar conversar com as outras. É o cenário mais simples de escalar.
Três itens que costumam ficar de fora da especificação e aparecem como problema depois da entrega:
Se o seu uso é esporádico e imprevisível, nuvem provavelmente custa menos que hardware próprio ocioso. A conta vira favorável ao equipamento local a partir de uso contínuo — e o ponto de virada depende do seu padrão real de utilização.
Se você trabalha com modelos pequenos e especializados, e não com modelos de linguagem grandes, toda essa conversa muda de escala: uma placa modesta pode ser mais que suficiente.
E se o seu gargalo hoje é qualidade e organização de dados — como é para a maioria dos projetos —, comprar mais GPU não vai resolver. Vai apenas produzir resultados ruins mais rápido.
A sequência que recomendamos inverte a ordem habitual:
Fazer o caminho contrário — escolher a placa pelo orçamento e depois descobrir o que cabe nela — é como comprar um caminhão sem saber o peso da carga. Às vezes dá certo. Frequentemente não.
O SmartSpec Optimizer mede o seu workload real e devolve arquitetura recomendada com estimativa de TCO — antes de qualquer aquisição.
Solicitar avaliação técnica →Ajuste as categorias abaixo. Cookies essenciais não podem ser desativados porque garantem o funcionamento do site. Sua escolha vale por 12 meses e pode ser alterada a qualquer momento pelo link "Preferências de cookies" no rodapé.
Registro do consentimento: guardamos localmente a data, a versão desta política e as categorias escolhidas, como evidência de conformidade. Nenhum dado é enviado a terceiros por este controle.