Quanto custa servir um LLM para 100 usuários ao mesmo tempo

"Preciso atender 100 usuários. Quantas GPUs?" É a pergunta errada, e ela leva a orçamentos absurdos ou a servidores que caem na primeira semana. A pergunta certa é: quantos tokens por segundo esses 100 usuários geram no pico?

Cem pessoas com um chat aberto numa aba, digitando de vez em quando, é um problema pequeno. Cem pessoas disparando resumos de documento de dez páginas ao mesmo tempo é outro planeta. O mesmo número de usuários, dez vezes a infraestrutura.

Por que uma GPU aguenta mais gente do que parece

A intuição diz que a GPU atende um pedido de cada vez, e que dez pedidos simultâneos são dez vezes mais lentos. Não é assim, e entender o porquê muda todo o dimensionamento.

Gerar texto é, a cada passo, multiplicar a matriz de pesos do modelo por um vetor pequeno. A GPU é boa demais nisso — tão boa que fica esperando a memória, não calculando. Com um pedido só, você usa uma fração ridícula da capacidade da placa.

O lote contínuo (continuous batching) explora isso: o servidor junta os pedidos que estão em andamento e gera o próximo token de todos eles na mesma passada. Como o custo dominante era carregar os pesos da memória — e você carrega uma vez para o lote inteiro —, atender 20 pedidos juntos custa quase o mesmo tempo que atender um.

📈 O número que importa

Numa RTX 4090 servindo um modelo de 8B quantizado em 4 bits, é razoável esperar da ordem de 1.500 a 2.500 tokens por segundo no total, somando todos os usuários. O mesmo hardware entrega uns 80 a 120 tokens por segundo se você mandar um pedido de cada vez.

Ou seja: o lote não é uma otimização de 10%. É a diferença entre viável e inviável.

Isso só funciona com um servidor que implemente lote contínuo de verdade — vLLM, TGI, SGLang. Rodar um laço em Python chamando model.generate() por pedido joga fora 90% da placa que você está pagando.

A fórmula de dimensionamento

Três passos, com números que você consegue estimar sem ter o sistema pronto.

1. Calcule a demanda em tokens por segundo

Demanda = usuários ativos no pico × pedidos por minuto × tokens gerados por pedido ÷ 60

Um caso de atendimento interno: 100 pessoas, mas no pico só 15 estão de fato esperando resposta; cada uma faz 2 pedidos por minuto; cada resposta tem 300 tokens.

15 × 2 × 300 ÷ 60 = 150 tokens por segundo. Uma placa de R$ 2,78 a hora dá conta com folga de dez vezes.

Um caso de processamento: os mesmos 100 usuários, mas cada um dispara um resumo de documento que gera 1.500 tokens, e 40 fazem isso na mesma janela de dois minutos.

40 × 1.500 ÷ 120 = 500 tokens por segundo. Ainda cabe numa placa, mas a folga sumiu e a fila vai aparecer nos picos.

⚠️ O erro de dimensionamento mais caro

Contar "usuários cadastrados" em vez de "usuários simultâneos no pico". Numa ferramenta interna, a razão costuma ficar entre 5% e 15% — de 100 cadastrados, algo entre 5 e 15 estão realmente esperando resposta ao mesmo tempo.

Quem dimensiona pelos 100 compra sete vezes mais GPU do que precisa. E paga por ela todo mês.

2. Cheque se a VRAM aguenta o número de conversas

Cada pedido em andamento ocupa cache de atenção. É o limite que aparece primeiro em conversas longas:

VRAM = modelo + (pedidos simultâneos × contexto médio × custo por token)

Para um modelo de 8B, o cache custa mais ou menos 0,12 MB por token de contexto. Vinte pedidos simultâneos com 4.000 tokens de conversa cada: 20 × 4.000 × 0,12 MB ≈ 9,6 GB, além dos ~6 GB do modelo quantizado. Numa placa de 24 GB, funciona; numa de 16 GB, o servidor começa a enfileirar.

3. Escolha a placa

Carga (tokens/s no total)	Modelo	Placa	Preço/hora
Até 400	8B em 4 bits	RTX 4090 24 GB	R$ 2,78
400 a 1.200	8B–14B em 4 bits	L40S 45 GB	R$ 7,08
1.200 a 3.000	32B em 4 bits	A100 80 GB	R$ 11,05
Acima disso	70B ou várias placas	H100 80 GB	R$ 13,91

Preços de agosto de 2026, para uma GPU avulsa, sem interrupção programada. O catálogo muda: confira a vitrine antes de fechar a conta.

A conta que decide entre servidor próprio e API por token

Esta é a comparação que interessa, e ela tem um ponto de virada bem definido.

Uma placa de R$ 2,78 por hora, ligada 24 horas por dia, custa cerca de R$ 2.000 por mês. Nessa mesma placa, um modelo de 8B em 4 bits entrega com folga 1.500 tokens por segundo — mas você não vai usar isso o tempo todo. Suponha uma utilização média honesta de 15% ao longo do mês (é o normal em ferramenta interna, com pico no horário comercial):

Tokens gerados no mês: 1.500 × 0,15 × 2.592.000 s ≈ 583 milhões
Custo por milhão de tokens de saída: 2.000 ÷ 583 ≈ R$ 3,43

Compare com a API por token, em que a saída de um modelo pequeno sai por R$ 1,09 por milhão. Ou seja: com 15% de utilização, o servidor próprio custa três vezes mais que a API.

Inverta a conta e ache o ponto de virada. Para o servidor próprio empatar a R$ 1,09 por milhão, ele precisaria entregar cerca de 1,8 bilhão de tokens no mês — o que exige utilização média perto de 50%. Traduzindo: a máquina precisa estar realmente ocupada metade do tempo, todos os dias, inclusive de madrugada e no fim de semana.

💡 A regra do ponto de virada

Servidor próprio ganha quando há volume alto e constante. API por token ganha quando há volume irregular — que é a situação de quase todo produto no primeiro ano.

Há dois casos em que o servidor próprio ganha mesmo com pouco volume: quando você precisa de um modelo específico que nenhuma API oferece, e quando o dado não pode sair da sua instância. Nesses, a decisão não é de custo.

Subir o servidor

pip install vllm

vllm serve TheOrg/Modelo-8B-AWQ \
  --quantization awq_marlin \
  --max-model-len 8192 \
  --max-num-seqs 32 \
  --gpu-memory-utilization 0.90 \
  --port 8000 \
  --api-key SUA_CHAVE

Os dois parâmetros que você vai mexer:

--max-num-seqs: quantos pedidos ele processa em paralelo. Mais alto = mais vazão total e mais espera individual. Comece em 32.
--max-model-len: teto de contexto. Cortar isso de 32.768 para 8.192 libera VRAM enorme e quase nunca prejudica — a maioria das conversas reais não passa de 4 mil tokens.

Meça antes de acreditar

vllm bench serve \
  --model TheOrg/Modelo-8B-AWQ \
  --num-prompts 200 \
  --request-rate 10

Olhe três números na saída: vazão total (tokens/s), tempo até o primeiro token e tempo entre tokens. O primeiro diz se a placa aguenta o volume; os outros dois dizem se o usuário vai achar rápido. São coisas diferentes e um servidor pode ir muito bem no primeiro e mal nos outros.

Meça na placa de verdade, não na planilha

Suba um servidor com o seu modelo, rode o teste de carga e desligue. Duas horas de GPU respondem o que uma semana de estimativa não responde.

Criar conta →

Cinco coisas que quebram em produção

Um usuário pede 100 mil tokens de contexto e trava a fila. Ponha teto de contexto por pedido no seu código, antes de chegar ao servidor.
Sem transmissão contínua, o usuário acha que travou. Ligue o modo stream: a resposta começa a aparecer em menos de um segundo mesmo que leve dez para terminar.
Sem limite por usuário, um cliente consome a máquina. Fila e teto por chave, sempre.
A GPU cai e não há para onde ir. Tenha um caminho alternativo por API configurado — quando o servidor próprio falhar, o produto degrada em vez de morrer.
A máquina fica ligada de madrugada sem ninguém usando. Esse é o custo silencioso mais comum; vale tratar como trabalho em lote o que não precisa ser instantâneo.

Conclusão

Cem usuários não é uma medida de carga. Estime tokens por segundo no pico, confira a VRAM contra o número de conversas simultâneas e escolha a placa a partir daí — na maioria dos casos internos, uma única GPU de 24 GB atende com folga uma equipe inteira.

E antes de comprar o mês inteiro de máquina, faça a conta do ponto de virada. Abaixo de 50% de utilização média, a API por token quase sempre sai mais barata que a sua própria placa parada esperando o pico das duas da tarde.

Continue: quantização e VRAM · latência percebida · vLLM em 1 clique