Quando Contratar Cada Servidor GPU para Inferência de LLM

O que é inferência de LLM em GPU dedicada e quando ela se torna necessária

Inferência de LLM em GPU dedicada é o processo de executar um modelo de linguagem pré-treinado em uma unidade de processamento gráfico exclusiva de um servidor, sem compartilhamento de recursos com outros usuários, para gerar respostas a partir de prompts enviados por aplicações ou usuários finais. Diferente do treinamento, que ajusta os pesos do modelo, a inferência apenas consulta os pesos já estabelecidos; mas mesmo assim exige memória de vídeo suficiente para carregar o modelo inteiro e memória adicional para a cache de atenção, que armazena o contexto da conversa.

A inferência é onde a IA encontra o usuário final. Um modelo pode ter sido treinado por semanas em clusters de centenas de GPUs, mas se a inferência for lenta, imprecisa ou instável, o projeto fracassa na adoção. A GPU dedicada entra nesse momento como o componente que determina se a experiência do usuário será fluida ou frustrante. Quando a latência passa de 5 segundos por resposta, a taxa de adoção cai drasticamente. Quando a GPU fica sem memória, o modelo simplesmente não carrega ou trava.

A decisão de quando contratar cada tipo de servidor GPU para inferência não é apenas técnica: é estratégica. Uma GPU excessivamente poderosa para um modelo pequeno representa desperdício de capital. Uma GPU insuficiente para um modelo grande representa impossibilidade operacional. O ponto ótimo depende de três fatores que mudam ao longo do ciclo de vida de um projeto de IA: o tamanho do modelo que está sendo implantado, o número de usuários simultâneos e a criticidade da latência para o negócio.

Quando uma GPU entry-level de 16-24 GB já é suficiente

As GPUs entry-level para inferência de LLM, como a NVIDIA T10 (16 GB) e a L4 (24 GB), fazem sentido em quatro cenários específicos. O primeiro é a fase de prototipagem, quando o time de IA ainda experimenta diferentes modelos, frameworks e pipelines sem compromisso com produção. Nessa fase, o objetivo é validar que um modelo de 7 bilhões de parâmetros resolve o problema de negócio, não otimizar latência para milhares de usuários.

O segundo cenário é a inferência de modelos pequenos em produção com baixa concorrência. Um modelo de 7B parâmetros quantizado para INT4 ocupa cerca de 4-5 GB de VRAM, deixando espaço para cache de contexto e múltiplas requisições sequenciais. Se a aplicação atende dezenas de usuários por hora, e não milhares por minuto, uma GPU com 16-24 GB entrega latência aceitável sem superdimensionamento.

O terceiro cenário é o edge deployment interno: departamentos que querem um assistente de IA para consulta de documentos internos, geração de e-mails ou automação de relatórios. Nesses casos, o volume de tokens processados é baixo, o contexto é curto e a concorrência é limitada ao time local. Uma GPU entry-level atende perfeitamente.

O quarto cenário é o fine-tuning leve com LoRA ou QLoRA, técnicas que congelam a maioria dos pesos do modelo e treinam apenas camadas adaptadoras. Isso reduz drasticamente o consumo de VRAM durante o ajuste, permitindo que modelos de até 13B parâmetros sejam personalizados em GPUs de 24 GB.

Cenário	Modelo Típico	VRAM Necessária	GPU Indicada	Quando Não Serve
Prototipagem e PoC	Llama 3 8B, Mistral 7B	16-24 GB	NVIDIA T10, L4	Modelos acima de 13B em FP16
Assistência interna (baixa concorrência)	Llama 3 8B INT4	16-20 GB	NVIDIA T10, L4	Múltiplos usuários simultâneos
Fine-tuning leve (LoRA/QLoRA)	Llama 3 8B-13B	20-24 GB	NVIDIA L4	Fine-tuning full-parameter

Quando a escolha recai sobre GPU mid-range de 24-48 GB

As GPUs de categoria intermediária, como a NVIDIA A10 (24 GB), A40 (48 GB) e L40S (48 GB), representam o sweet spot para a maioria das empresas que já validaram seu caso de uso e estão levando o LLM para produção. Elas fazem sentido quando o modelo de 13B a 30B parâmetros precisa rodar em precisão FP16 ou BF16, sem as perdas de qualidade que a quantização agressiva introduz.

O primeiro cenário é a produção de modelos médios com contexto longo. Modelos de 13B a 20B parâmetros em FP16 ocupam 26-40 GB de VRAM apenas nos pesos. Adicione a cache KV para contextos de 4.000 a 8.000 tokens, e o consumo sobe para 35-45 GB. Uma GPU de 48 GB como a A40 ou L40S dá folga confortável sem estourar o orçamento de uma A100.

O segundo cenário é a inferência com múltiplos modelos simultâneos. Muitas arquiteturas de IA não usam um único LLM: usam um modelo de 7B para classificação de intenção, um de 13B para geração de resposta e um modelo de embedding para recuperação de contexto (RAG). Cada modelo consome VRAM simultaneamente. Uma GPU de 48 GB permite hospedar dois modelos médios ou um grande mais um pequeno, enquanto uma de 24 GB força o carregamento e descarregamento sequencial, que gera latência inaceitável.

O terceiro cenário é o fine-tuning completo de modelos pequenos. Diferente do LoRA, o fine-tuning full-parameter ajusta todos os pesos do modelo, exigindo VRAM suficiente para manter os gradientes, os estados do otimizador e os pesos originais simultaneamente. Para um modelo de 7B parâmetros em FP16, o fine-tuning exige aproximadamente 56-60 GB de VRAM, o que torna a A40 (48 GB) o piso mínimo, e a L40S (48 GB) com suporte a precisão mista uma opção viável.

O quarto cenário é a inferência batchada para processamento assíncrono. Quando a aplicação não exige resposta em tempo real (por exemplo, análise de documentos em lote, sumarização de contratos, extração de entidades de milhares de registros), uma GPU mid-range processa batches maiores com eficiência de custo superior a uma GPU enterprise subutilizada.

Quando só uma GPU enterprise de 48-80 GB atende o cenário

As GPUs enterprise, como a NVIDIA A100 (40/80 GB) e H100 (80 GB), deixam de ser luxo e se tornam obrigatórias em cenários onde não há espaço para compromisso. O primeiro e mais óbvio é a inferência de modelos grandes (70B+ parâmetros) em precisão plena. Um modelo de 70B parâmetros em FP16 ocupa 140 GB de VRAM, o que exige duas GPUs de 80 GB em paralelo, ou quantização para INT8/INT4 em uma única GPU de 80 GB. Para empresas que não aceitam perda de qualidade, como as que processam documentos jurídicos, laudos médicos ou análises de risco, a GPU enterprise é inegociável.

O segundo cenário é a inferência de alta concorrência com latência rigorosa. Quando dezenas ou centenas de usuários acessam o mesmo modelo simultaneamente, a cache KV de cada sessão consome VRAM adicional. Uma GPU de 80 GB pode manter mais sessões ativas simultaneamente do que uma de 48 GB, reduzindo filas e melhorando o tempo de resposta percebido. Em atendimento ao cliente ou assistentes médicos, onde cada segundo conta, essa capacidade se traduz diretamente em satisfação do usuário.

O terceiro cenário é o fine-tuning de modelos grandes. Mesmo com técnicas eficientes, ajustar um modelo de 30B a 70B parâmetros exige VRAM de sobra. A H100, com sua arquitetura Hopper e suporte a precisão FP8, pode reduzir o consumo de memória em até 50% comparado à A100, tornando o fine-tuning de modelos grandes economicamente viável.

O quarto cenário é a execução de modelos multimodais. LLMs que processam imagens, áudio e texto simultaneamente (como Llama 3.2 Vision ou modelos de visão computacional acoplados a linguagem) consomem VRAM de forma multiplicativa. A representação visual de uma imagem em alta resolução pode adicionar dezenas de milhares de tokens equivalentes ao contexto, explodindo o consumo de memória. GPUs enterprise são o piso para esses casos.

GPU	VRAM	Cenário Ideal	Limite Prático
NVIDIA T10	16 GB	Prototipagem, modelos 7B INT4	Não roda modelos 13B em FP16
NVIDIA L4	24 GB	Produção 7B-13B, fine-tuning LoRA	Modelos 70B mesmo quantizados
NVIDIA A10 / L40S	24-48 GB	Produção 13B-30B FP16, múltiplos modelos	70B sem quantização
NVIDIA A100	40-80 GB	70B INT8, alta concorrência	70B FP16 (precisa de 2x)
NVIDIA H100 / H200	80-141 GB	70B+ FP16, fine-tuning, multimodal	Modelos 405B+ sem multi-GPU

Quando faz sentido partir para multi-GPU com NVLink

A configuração multi-GPU, especialmente com NVLink para comunicação de alta velocidade entre as placas, faz sentido em três momentos específicos do ciclo de vida de um projeto de IA. O primeiro é quando um único modelo exige mais VRAM do que qualquer GPU individual pode oferecer. Um modelo de 70B parâmetros em FP16 precisa de 140 GB. Mesmo a H200 com 141 GB fica no limite, sem espaço para cache de contexto. Duas GPUs de 80 GB com NVLink resolvem o problema com folga.

O segundo momento é o throughput horizontal. Quando o gargalo não é o tamanho do modelo, mas a quantidade de requisições simultâneas, adicionar GPUs em paralelo permite distribuir o tráfego. Frameworks como vLLM e TensorRT-LLM suportam pipeline parallelism e tensor parallelism, que dividem o modelo entre GPUs para atender mais usuários ao mesmo tempo. Uma configuração HGX com 8x H200 pode atender centenas de requisições simultâneas de um modelo de 70B parâmetros, algo impossível para uma única GPU.

O terceiro momento é o treinamento e fine-tuning distribuído de modelos grandes. Embora este artigo foque em inferência, muitas empresas mantêm o mesmo cluster para ambas as fases. O treinamento de modelos de 30B+ parâmetros exige necessariamente multi-GPU, e manter a mesma infraestrutura para inferência posterior reduz custos de migração e compatibilidade.

Quando escolher bare metal em vez de nuvem privada para inferência

O servidor bare metal faz sentido para inferência de LLM em quatro situações. A primeira é quando a carga de trabalho é estável e previsível. Se o modelo já está em produção, o número de usuários é relativamente constante e não há picos sazonais abruptos, o bare metal oferece o melhor custo por token processado, porque você paga pelo hardware, não pelo uso.

A segunda situação é quando a performance é absolutamente crítica. O bare metal elimina o overhead de virtualização, por menor que seja. Em cargas de inferência, onde cada milissegundo de latência importa, rodar diretamente no host pode reduzir a latência em 5-15% comparado a uma máquina virtual equivalente. Para aplicações de trading, atendimento de emergência ou cirurgia assistida, essa diferença pode ser decisiva.

A terceira situação é o compliance máximo. Em bare metal, não há hypervisor compartilhado, nem risco de noisy neighbors, nem abstração que dificulte a auditoria. O time de segurança tem acesso físico e lógico completo ao servidor, o que simplifica a comprovação de conformidade para auditorias do Banco Central, ANS ou CGU.

A quarta situação é o controle total de drivers e bibliotecas. Alguns frameworks de inferência exigem versões específicas de CUDA, cuDNN ou drivers NVIDIA que podem conflitar com as imagens padrão de um ambiente virtualizado. No bare metal, você controla cada camada da stack.

Quando a nuvem privada é mais estratégica que o bare metal

A nuvem privada se torna a escolha mais inteligente quando a elasticidade importa mais que o custo unitário absoluto. O primeiro cenário é o de cargas variáveis: uma empresa que processa lotes de documentos em certos dias do mês, ou que tem picos de atendimento em campanhas sazonais, precisa escalar para cima e para baixo sem comprometer hardware ocioso.

O segundo cenário é a experimentação paralela. Times de IA frequentemente precisam testar múltiplos modelos, hyperparâmetros e pipelines simultaneamente. A nuvem privada permite clonar ambientes, isolar experimentos e destruir recursos quando o teste termina, sem reinstalar sistema operacional ou reconfigurar rede.

O terceiro cenário é a recuperação de desastres. Em nuvem privada, snapshots, backups automatizados e replicação entre zonas de disponibilidade são nativos. Se um servidor bare metal sofre falha de hardware, a recuperação pode levar horas. Em nuvem privada bem arquitetada, a migração para outro host leva minutos.

O quarto cenário é a governança multi-time. Quando diferentes departamentos (jurídico, financeiro, marketing, TI) compartilham a mesma infraestrutura de IA, a nuvem privada oferece isolamento de tenants, quotas de recursos e políticas de acesso centralizadas que o bare metal exigiria construir manualmente.

Em quais setores a escolha da GPU é uma decisão de compliance

Para a maioria das empresas, a escolha da GPU é uma decisão técnica e econômica. Mas para setores regulados, ela se torna uma decisão de compliance, onde a opção errada pode resultar em multa, suspensão de operações ou processo administrativo. Nesses setores, não basta a GPU ser potente: a infraestrutura inteira precisa ser auditável, localizada no Brasil e sob controle direto da organização.

Setor público: órgãos federais, estaduais e municipais estão sujeitos às diretrizes do CGI.br, do IN4 e do Decreto n 7.724/2012, que exigem que dados de cidadãos sejam processados em infraestrutura nacional. A escolha da GPU para inferência de LLM em atendimento ao público, análise de documentos ou automação de processos administrativos precisa obedecer a esse princípio. Isso elimina automaticamente qualquer opção de nuvem pública internacional, mesmo com região São Paulo, e direciona para bare metal ou nuvem privada em data centers brasileiros.

Setor de saúde: a Resolução Normativa n 467/2012 da ANS estabelece que dados de beneficiários e prontuários devem estar disponíveis para fiscalização no Brasil. Operadoras de planos de saúde, hospitais e clinics que usam LLMs para triagem, análise de laudos ou assistência diagnóstica precisam garantir que nenhum dado do paciente trafegue para fora da infraestrutura nacional. A GPU é apenas um componente dessa arquitetura: ela precisa estar em um servidor físico no Brasil, com logs imutáveis e acesso restrito.

Setor financeiro: a Resolução CMN n 4.893/2021 e as normas do Banco Central sobre governança cibernética exigem que instituições financeiras mantenham dados de clientes sob controles rigorosos de acesso e localização definida. O uso de LLMs para análise de crédito, atendimento a investidores ou detecção de fraudes exige que a inferência ocorra em ambientes que o Banco Central possa auditar. A LGPD reforça essa exigência para dados pessoais de clientes.

Nesses três setores, a escolha da GPU não começa pelo tamanho do modelo ou pela latência. Começa pela pergunta: "Esse servidor está fisicamente no Brasil, sob nosso controle contratual, com logs que podemos apresentar a um auditor?" Só depois de responder sim é que o tamanho da VRAM entra em discussão.

A abordagem da EVEO

A EVEO, com mais de 10 anos de mercado, 5.000 clientes e 130 colaboradores, oferece infraestrutura de GPU para inferência de LLM em data centers Tier III localizados em Cotia/SP, Osasco/SP, Curitiba/PR, Fortaleza/CE e Miami/FL. Todos os ambientes são operados mediante CNPJ, com foco corporativo e sem atendimento a pessoa física.

A carteira de GPU da EVEO cobre todo o espectro de necessidades de inferência: desde a NVIDIA T10 (16 GB) e L4 (24 GB) para prototipagem e modelos pequenos, passando pela A10 e L40S (24-48 GB) para produção de modelos médios, até a A100 (80 GB), H100 (80 GB) e H200 (141 GB) para cargas enterprise. Para cenários de throughput massivo, a EVEO oferece configurações HGX com múltiplas GPUs H200 interconectadas por NVLink.

O diferencial da EVEO não está apenas no hardware. Está no modelo de negócio: sem egress fee, custo previsível em reais e soberania de dados garantida por contrato. Para times de IA que precisam dimensionar infraestrutura sem surpresas na fatura, essa previsibilidade permite planejar o roadmap de hardware com a mesma clareza que se planeja o roadmap de produto.

Seja para começar uma prova de conceito com uma GPU entry-level ou para implantar um cluster multi-GPU para atender milhares de usuários, a EVEO tem a arquitetura adequada. O time de engenharia auxilia no dimensionamento correto, considerando não só o modelo de IA, mas o cenário de uso, a concorrência esperada e as obrigações regulatórias do setor.

Perguntas frequentes