Velocidade IA GPU parâmetros tokens: o que decide?

TL;DR

A velocidade observada de uma IA é o resultado do gargalo entre quatro eixos: velocidade IA GPU parâmetros tokens define a equação operacional: capacidade computacional da GPU, largura de banda da VRAM, formato de execução do modelo (parâmetros + quantização) e estratégia de atendimento (batching, paralelismo, cache). Nenhum eixo sozinho define a latência ou o throughput. A escolha de modelo é importante, mas é apenas uma das variáveis da equação de velocidade IA GPU parâmetros tokens.

• Capacidade do modelo ≠ velocidade do modelo. Um modelo com mais parâmetros tende a ser mais capaz, mas tende a ser mais lento por token. A conta é feita em latência por token, não em benchmark de qualidade isolado.
• GPU define o teto, VRAM define o gargalo real. Em inferência, a maior parte do tempo o hardware não está esperando a GPU calcular; está esperando a memória entregar os pesos. Quem domina isso domina o throughput.
• Quantização troca precisão por velocidade de forma não-linear. 4-bit pode dar 2-4x mais tokens por segundo do que 16-bit, com queda pequena de qualidade na maioria dos workloads — mas não em todos.
• Batching e KV-cache determinam 80% da vazão em produção. Dois modelos idênticos no mesmo hardware podem ter throughput 10-20x diferente dependendo da estratégia de atendimento.
• Treinar, inferir e operar agentes têm custos em ordens de grandeza diferentes. Quem confunde os três planeja errado.

~ 19 min de leitura · 3333 palavras

A equação de velocidade IA GPU parâmetros tokens: separar capacidade de execução

A discussão pública sobre IA gira em torno de qual modelo é mais inteligente. A discussão operacional sobre IA gira em torno de qual modelo atende ao orçamento de latência, custo e throughput. A primeira pergunta é fácil de responder com benchmark; a segunda, não. A maioria das equipes que escolhe modelo olha só para a primeira, e descobre a segunda quando o sistema vai para produção. Resultado: modelo bom que ninguém consegue usar, ou modelo fraco rodando em hardware bom demais. A equação de velocidade IA GPU parâmetros tokens é o que separa os dois campos.

O equívoco tem duas raízes. A primeira é tratar “modelo maior = modelo melhor” como axioma. Em qualidade de resposta, isso geralmente é verdade dentro de uma mesma família. Em velocidade, a relação é inversa: dobrar os parâmetros geralmente multiplica a latência por mais de 1.5x e multiplica a VRAM consumida por mais de 1.8x. A segunda raiz é confundir a métrica de marketing com a métrica de produção. Benchmarks como MMLU, GSM8K e HumanEval medem capacidade em tarefas estáticas. Produção mede tokens por segundo sob uma distribuição de prompts, latência até o primeiro token (TTFT), e custo por milhão de tokens.

A consequência prática é que a pergunta “qual o melhor modelo” raramente é a pergunta certa. A pergunta certa é: dado um orçamento de latência, custo e qualidade mínima aceitável, qual a maior capacidade que cabe nesse orçamento? Em muitos casos, a resposta é um modelo médio rodando em hardware bom, não um modelo grande rodando em hardware ruim. A equação de velocidade IA GPU parâmetros tokens indica onde está a folga.

O tripé conceitual deste blog sobre o tema é o seguinte: a unidade de cobrança é o token, o tamanho do modelo determina a capacidade bruta, e a velocidade observada é a função que liga capacidade a infraestrutura. Os três eixos se entrelaçam, e este post isola o terceiro, mostrando que a equação de velocidade IA GPU parâmetros tokens é dominada pela infraestrutura, não pela contagem de parâmetros isolada.

GPU: o motor que define o teto

A GPU é o primeiro eixo a olhar porque define o limite superior físico. Uma A100 entrega, em operações de matriz otimizadas para inferência, uma ordem de grandeza a mais de FLOPs por segundo do que uma RTX 4090. Uma H100 entrega cerca de 3x a A100 em workloads típicos de LLM. A primeira vista, isso sugere que a GPU é o fator dominante. Não é — mas é o teto da equação de velocidade IA GPU parâmetros tokens, e o primeiro eixo a ser dimensionado em qualquer arquitetura de inferência.

A relação entre capacidade de GPU e velocidade de inferência é aproximadamente linear para modelos que cabem inteiros na VRAM, até o ponto em que o modelo deixa de caber. Quando o modelo não cabe, a conta muda radicalmente: parte dos pesos é despejada para a RAM do sistema, e cada token passa a exigir transferência PCIe a cada camada. O resultado é uma queda de 5-10x na latência por token, e a GPU fica ociosa esperando memória. É aqui que a equação de velocidade IA GPU parâmetros tokens muda de patamar.

Por isso o primeiro corte na escolha de GPU é o de “o modelo inteiro cabe?”. Para um modelo de 7B em FP16 (16 bits por parâmetro), são necessários 14 GB de VRAM só para os pesos — antes de KV-cache, batch e overhead. Para 70B em FP16, 140 GB. Uma A100 de 80 GB comporta o 70B com folga para inferência; uma A100 de 40 GB não. O modelo pode rodar, mas com offload, e a velocidade observada não é a que o marketing da A100 sugere. Nessa decisão, a equação de velocidade IA GPU parâmetros tokens se materializa como orçamento de VRAM.

Outro ponto crítico: GPUs diferentes têm perfis diferentes para inferência versus treinamento. As três variáveis operacionais que mais importam são:

• Capacidade de FLOPs (FP16/BF16/FP8): mede o cálculo por segundo. Importa para atenção, projeção e forward pass denso. Favorece treinamento e inferência em batch.
• Largura de banda de memória (HBM/GDDR): mede bytes por segundo entre VRAM e registradores. Domina inferência autorregressiva, que é o regime de produção típico.
• Tamanho da VRAM: mede o maior modelo que cabe inteiro. Abaixo desse limite, offload e degradação severa.

A A100 tem alta largura de banda de memória (2 TB/s na versão SXM) e é boa em inferência de modelos médios. A H100 tem mais FLOPs e largura de banda ainda maior, mas o ganho marginal em inferência de modelos pequenos é menor do que em treinamento de modelos grandes. Para inferência pura de modelos até 13B, uma RTX 4090 de 24 GB tem o melhor custo por token em muitos cenários. Cada uma dessas escolhas recalibra a equação de velocidade IA GPU parâmetros tokens do sistema.

VRAM e largura de banda: o gargalo real

Em inferência autorregressiva, a operação que domina o tempo é a leitura dos pesos da VRAM para os registradores da GPU. O cálculo (multiplicação de matrizes) é rápido. A transferência de memória é lenta. Por isso a métrica que importa não é FLOPs, é bytes por segundo de largura de banda, e por isso a equação de velocidade IA GPU parâmetros tokens é dominada por memória, não por cálculo.

A aritmética é direta. Para gerar um token com um modelo de 7B em FP16, é preciso ler 14 GB de pesos. Em uma A100 com 2 TB/s de largura de banda, isso dá um piso teórico de 7 milissegundos por token, ou cerca de 140 tokens por segundo se o resto do pipeline for instantâneo. Na prática, atenção, KV-cache e overhead tiram o sistema desse teto — mas a largura de banda é o limitante central. A equação de velocidade IA GPU parâmetros tokens se resolve aqui antes de qualquer software.

É por isso que técnicas como FlashAttention, PagedAttention (do vLLM) e grouped-query attention importam para a equação de velocidade IA GPU parâmetros tokens: elas reduzem o tráfego de memória por token, não aumentam o cálculo. Aceleradores que multiplicam FLOPs sem mexer em largura de banda produzem ganho marginal; otimizações que reduzem bytes movidos produzem ganho proporcional ao tráfego economizado.

VRAM também limita o tamanho do batch, e o tamanho do batch tem impacto direto na vazão (tokens por segundo no agregado, não por requisição). Um batch de 1 entrega latência baixa mas não aproveita a GPU. Um batch de 32 entrega latência maior por requisição, mas pode multiplicar a vazão total por 5-10x. O ponto ótimo depende do caso de uso: chat interativo favorece batch pequeno; processamento em lote favorece batch grande. A VRAM disponível determina onde esse ponto ótimo cai na equação de velocidade IA GPU parâmetros tokens. As três alavancas sobre o gargalo de memória são:

• Aumentar VRAM efetiva: usar GPU com mais memória, sharding entre GPUs, descarregamento de partes frias para host.
• Reduzir pressão de memória por token: quantização, atenção eficiente, sliding window, FlashAttention, grouped-query attention.
• Reduzir bytes movidos por token: continuous batching, prefill e decode desacoplados, speculative decoding.

A combinação dessas alavancas é onde a maioria dos ganhos de produção acontece — não na troca de GPU. A equação de velocidade IA GPU parâmetros tokens se otimiza no software, não no hardware, e essa é a alavanca de maior impacto em produção.

Parâmetros, quantização e o efeito no throughput

O número de parâmetros define o tamanho do modelo em bytes e, portanto, o tráfego de memória por token. É a variável mais direta sobre a velocidade observada — antes da GPU, antes do batching, antes de qualquer otimização de software. Dentro da equação de velocidade IA GPU parâmetros tokens, o número de parâmetros ocupa o eixo da quantidade de bytes que a GPU precisa ler por token para cada camada.

A quantização reduz a precisão dos pesos, tipicamente de 16 bits para 8, 4 ou até 2 bits. O efeito é mecânico: 4 bits em vez de 16 bits significa 4x menos bytes para mover, o que se traduz em aproximadamente 4x mais tokens por segundo no limite da largura de banda. Na prática, o ganho fica entre 2x e 4x dependendo do método (GPTQ, AWQ, bitsandbytes) e do modelo. A equação de velocidade IA GPU parâmetros tokens mostra aqui um de seus efeitos mais subestimados: a quantização é uma alavanca de ordem de grandeza.

O custo da quantização varia. Em modelos de instrução modernos, a queda de qualidade entre FP16 e INT4 costuma ser pequena em benchmarks de produção — perda de 1-3% em MMLU, frequentemente imperceptível em uso real. Em modelos de raciocínio ou em tarefas numéricas, a degradação pode ser maior. A regra prática é testar no workload real, não assumir que 4-bit é sempre aceitável. A decisão de quantização é parte da equação de velocidade IA GPU parâmetros tokens e não deve ser tomada por default.

A escolha de quantização não é binária. As opções comuns em produção são:

• FP16 (16 bits): baseline. Sem perda de qualidade, sem ganho de velocidade.
• INT8 (8 bits): aproximadamente 1.5-2x de ganho. Queda de qualidade marginal na maioria dos workloads.
• INT4 (4 bits): aproximadamente 2-4x de ganho. Funciona bem na maioria dos casos, com exceções.
• INT2 / métodos extremos: domínio de pesquisa. Raramente usado em produção.

O ganho marginal decresce à medida que se quantiza mais. A curva não é linear: ir de FP16 para INT8 rende 2x; ir de INT8 para INT4 rende mais 1.5-2x. Ir de INT4 para INT2 não rende quase nada porque os métodos começam a comprometer a qualidade de forma severa. O ponto ideal de Pareto para a maioria das aplicações é INT4 ou INT8, dependendo do orçamento de qualidade. A escolha final depende de onde a equação de velocidade IA GPU parâmetros tokens está apertada para a aplicação.

Batching, paralelismo e cache: extraindo mais do mesmo hardware

Dado o mesmo hardware e o mesmo modelo, três técnicas determinam a maior parte da vazão observada: continuous batching, paralelismo entre GPUs e gestão eficiente do KV-cache.

Continuous batching é a evolução do batching estático tradicional. Em vez de esperar um batch inteiro terminar antes de iniciar o próximo, o servidor insere novas requisições em slots liberados a cada iteração. O resultado, documentado em produção pela Anyscale, é um ganho de até 23x em throughput sobre batching ingênuo. Frameworks como vLLM, TGI e TensorRT-LLM implementam continuous batching por padrão; servidores que não o fazem desperdiçam a maior parte da capacidade da GPU em workloads de produção. Nenhuma outra técnica tem impacto tão grande sobre a equação de velocidade IA GPU parâmetros tokens em produção.

Paralelismo entre GPUs entra quando o modelo não cabe em uma única GPU. As duas estratégias são tensor parallelism (dividir cada camada entre várias GPUs) e pipeline parallelism (dividir camadas entre GPUs). Tensor parallelism é mais rápido por token, mas exige comunicação intensiva via NVLink; pipeline parallelism é mais fácil de escalar, mas introduz bolhas. Para inferência, tensor parallelism em 2 ou 4 GPUs é a configuração mais comum; pipeline parallelism entra quando o modelo tem centenas de bilhões de parâmetros. A escolha de paralelismo é parte da equação de velocidade IA GPU parâmetros tokens quando o modelo ultrapassa a capacidade de uma única GPU.

KV-cache é a memória que armazena as ativações das camadas de atenção para cada token já gerado. Em uma conversa longa, o KV-cache cresce quadraticamente com o número de tokens. Técnicas como PagedAttention, sliding window attention e grouped-query attention reduzem o custo de memória e tornam possível atender a requisições longas sem saturar a VRAM. A equação de velocidade IA GPU parâmetros tokens muda substancialmente quando o KV-cache cabe ou não cabe na VRAM.

O impacto combinado dessas três técnicas é maior do que qualquer upgrade de hardware isolado. Dois sistemas com a mesma A100 e o mesmo modelo de 70B podem entregar 5 a 20 tokens por segundo ou 200 a 500 tokens por segundo dependendo apenas da sofisticação do servidor de inferência. A escolha do servidor importa mais do que muitas equipes imaginam, e é onde a equação de velocidade IA GPU parâmetros tokens se decide em produção. As opções maduras em produção em 2026 são:

• vLLM: open source, PagedAttention, continuous batching nativo, suporte amplo a modelos. Bom para a maioria dos workloads.
• TensorRT-LLM: otimizado para GPUs NVIDIA, mais rápido em benchmarks, mas específico de hardware e mais complexo de operar.
• TGI (Text Generation Inference): servidor da Hugging Face, integração nativa com o ecossistema, bom DX.
• llama.cpp / GGUF: quantização CPU-friendly, ideal para inferência local em hardware modesto.

Tokens por segundo, latência e TTFT: o que medir de verdade

Três métricas definem a velocidade observada do ponto de vista do usuário e do operador. Confundi-las é o terceiro erro mais comum depois de escolher GPU errada e ignorar quantização.

Tokens por segundo (TPS) por requisição mede a velocidade de geração vista pelo usuário final de uma única requisição. É a métrica de UX: em chat interativo, abaixo de 20 TPS a experiência fica perceptivelmente lenta; acima de 60 TPS, a leitura humana é o gargalo. Em geração de código ou análise longa, o limiar cai para 30-50 TPS. A métrica captura a velocidade IA GPU parâmetros tokens percebida por uma única sessão.

Time to first token (TTFT) mede o tempo entre o envio do prompt e o primeiro token da resposta. Para prompts longos, TTFT domina a percepção de velocidade. Um modelo que gera 200 TPS mas leva 3 segundos para começar a responder frustra mais do que um que gera 80 TPS em 200 milissegundos. TTFT é sensível ao comprimento do prompt, ao tamanho do batch e à estratégia de prefill. A métrica é o termômetro de UX da equação de velocidade IA GPU parâmetros tokens.

Tokens por segundo agregados (throughput) medem a vazão total do sistema, somando todas as requisições simultâneas. É a métrica de custo: quanto mais tokens por segundo por GPU, menor o custo por milhão de tokens servidos. Throughput depende criticamente do batch size efetivo, do paralelismo e do servidor de inferência. Throughput é a métrica pela qual a equação de velocidade IA GPU parâmetros tokens se traduz em custo unitário.

A métrica errada é aquela que parece intuitiva mas não corresponde ao caso de uso. Para um chat interativo, a pergunta certa é “qual a latência P95 do TTFT + tempo de geração até a primeira frase utilizável?”. Para um pipeline de processamento em lote, a pergunta certa é “quantos tokens por segundo por dólar consigo entregar?”. A confusão entre as duas perguntas é frequente e custosa. Em qualquer dos casos, a equação de velocidade IA GPU parâmetros tokens é o referencial.

Benchmarks sintéticos (MLPerf, vLLM benchmark) servem como referência, mas não substituem medição no workload real. A distribuição de comprimentos de prompt, a proporção de prefill versus decode, e o padrão de concorrência mudam a conta completamente. A recomendação operacional é medir com seu próprio tráfego, em ambiente próximo ao de produção, antes de fechar a escolha de modelo e hardware. A equação de velocidade IA GPU parâmetros tokens se calibra no campo, não no whitepaper.

Três custos: treinar, inferir e executar agentes

A última distinção que estrutura a decisão de velocidade é entre três regimes de custo com ordens de grandeza diferentes.

Treinar um modelo de 7B em um corpus de 1 trilhão de tokens custa, com a configuração típica de 2025-2026, entre 50 mil e 500 mil dólares em horas de GPU H100. Modelos de 70B custam entre 1 e 10 milhões. Modelos de 400B+, acima de 50 milhões. Esse custo é pago uma vez pelo time que desenvolve o modelo, e amortizado sobre todos os usuários. Para a maioria das organizações, treinar do zero não faz sentido; o caminho é fine-tuning leve ou adaptação via LoRA sobre modelo pré-treinado, com custo entre 1 mil e 50 mil dólares. Em qualquer desses casos, a equação de velocidade IA GPU parâmetros tokens define o tempo de execução do treino, não só a inferência.

Inferir um modelo de 7B a 100 TPS em uma A100 custa aproximadamente 0.1 a 0.3 dólares por milhão de tokens gerados, dependendo do preço da GPU, da utilização e do overhead. O mesmo modelo rodando em uma H100 cai para 0.05-0.15. Modelos de 70B custam entre 5 e 20 vezes mais. Esse é o regime em que a maioria das aplicações opera: paga por token gerado, direta ou indiretamente. A equação de velocidade IA GPU parâmetros tokens se materializa aqui como custo por requisição, e define o orçamento de produto.

Executar agentes é o regime emergente. Um agente que faz 20 chamadas de LLM, cada uma com 5 mil tokens de contexto e 2 mil tokens de resposta, em uma tarefa de pesquisa e síntese, consome 140 mil tokens. Em um sistema multi-agente com 5 agentes cooperando, cada requisição de usuário pode custar 1 milhão de tokens ou mais de inferência. O custo não escala linearmente com a complexidade do problema — escala com a profundidade do raciocínio e a qualidade da engenharia de prompts.

A implicação operacional é que agentes impõem requisitos diferentes sobre latência e custo. Um agente que consome 1 milhão de tokens por tarefa não pode rodar em hardware de inferência barato. Ou se reduz o número de tokens consumidos (via caching, prompts menores, raciocínio mais eficiente), ou se aceita o custo de GPUs de ponta em regime de inferência pesada. Confundir o custo de inferir com o custo de executar agentes é o erro de planejamento mais frequente na transição de produtos LLM para produtos agentivos. Nessas arquiteturas, a equação de velocidade IA GPU parâmetros tokens é multiplicada pelo número de chamadas.

A separação dos três regimes também redefine a pergunta sobre o que otimizar. Para treino, o gargalo é largura de banda de memória entre GPUs e tempo de wall clock. Para inferir, o gargalo é largura de banda entre VRAM e registradores, mais gestão de batch. Para agentes, o gargalo é o número de tokens consumidos por tarefa — e a otimização é de engenharia de software, não de hardware. Em todos os casos, a equação de velocidade IA GPU parâmetros tokens é a moldura. A ordem de grandeza típica de custo em 2026 é a seguinte:

• Treino de 7B (1T tokens): 50 a 500 mil dólares em horas de H100.
• Inferência de 7B em A100: 0.1 a 0.3 dólares por milhão de tokens.
• Tarefa agentiva de 5 agentes: 1 a 5 milhões de tokens consumidos, equivalente a 0.1 a 1.5 dólares por tarefa.

A velocidade de uma IA é uma propriedade do sistema que atende ao modelo, do hardware que executa o sistema, e do padrão de uso que o sistema absorve. Inteligência suficiente custa menos computação que inteligência máxima. A equação de velocidade IA GPU parâmetros tokens é dominada pela infraestrutura, e é por isso que sistemas eficientes entregam mais valor do que modelos grandes em hardware medíocre. O futuro da IA depende de sistemas cada vez mais eficientes em entregar o mínimo de hardware necessário.

Leitura relacionada

• Token não é palavra: entenda a unidade que define memória, velocidade e custo da IA — base conceitual da unidade que define tudo o que este post mede.
• 7B, 70B, 400B: o tamanho de uma IA realmente determina sua inteligência? — complemento sobre o que tamanho decide e o que não decide.
• MCP virou infraestrutura. Agora vem a parte perigosa da segurança de agentes LLM — caso de uso agentivo, onde os três custos se acumulam.