How do I calculate the VRAM a self-hosted LLM needs?

Three terms. Model weights are parameters multiplied by bytes per parameter — a 70B model at FP16 is about 140GB, at INT8 about 70GB, at INT4 about 35GB. The KV cache is 2 (one key, one value) x layers x KV heads x head dimension x bytes per element, per token, and that whole figure is multiplied again by your context length and by the number of sequences in flight. Then subtract 10-20% for CUDA context, activations, fragmentation and the runtime itself. Weights are a fixed cost you pay once; the KV cache is the term that scales with traffic, and it is the one that decides your concurrency ceiling.

Why does grouped-query attention matter so much for concurrency?

Because the KV cache scales with the number of KV heads, not attention heads. A model with 64 attention heads but only 8 KV heads — standard grouped-query attention in current open-weight models — has an eight-times smaller KV cache than the equivalent multi-head model, which translates almost one-for-one into eight times the concurrent sequences on identical hardware. This is why a modern 70B model can serve more simultaneous users than an older 13B model in some configurations. If you are sizing hardware from a parameter count alone you will get the answer badly wrong; enter the KV head count from the model's config file.

When is self-hosting actually cheaper than paying per token?

Only at high, sustained utilisation. A rented GPU bills every hour whether or not a request arrives, so your effective cost per million tokens is the hourly rate divided by the tokens you actually generate in that hour. At full saturation the economics are often excellent; at 20% duty cycle your real cost per million tokens is five times the headline figure and almost always loses to an API. The break-even throughput shown by this calculator is the number of tokens per second you must sustain, on average and not at peak, for self-hosting to beat the API rate you entered. If your traffic is bursty, compare against that average rather than your peak.

LLM VRAM e calculadora de simultaneidade | Dimensionamento de cache KV para tokens de US$/1 milhão

LLM VRAM e calculadora de simultaneidade

✓ Última verificação: 23/07/2026· Fonte: configurações do modelo publicado + taxas públicas de aluguel de GPU· relatar alteração →

Cada decisão de auto-hospedagem começa com a mesma pergunta e quase ninguém a responde adequadamente: quantas pessoas esta GPU pode realmente atender ao mesmo tempo e quanto custa realmente um milhão de tokens quando o hardware é cobrado por hora, quer você o use ou não.

Os pesos são a parte fácil. Ajustar o modelo é um cálculo de uma linha e não diz quase nada. O que decide se você pode atender oito ou oitenta usuários é o cache KV – memória que se adapta ao comprimento do contexto e com todas as sequências simultâneas em vôo. Essa ferramenta dimensiona ambos e, em seguida, converte a capacidade resultante em um custo por milhão de tokens que você pode manter em relação a uma conta de API.

Ajustar o modelo não é o mesmo que servi-lo

O conselho que você encontra em todos os lugares é que um modelo 70B no INT4 precisa de cerca de 35 GB, portanto cabe em um único cartão de 80 GB com espaço de sobra. Isso é verdade e é quase inútil, porque descreve um modelo ocioso. No momento em que as solicitações chegam, cada sequência em voo aloca seu próprio cache KV: dois tensores por camada, dimensionados pelas cabeças KV vezes a dimensão da cabeça, mantidos para cada token no contexto dessa sequência. Com 80 camadas, cabeçotes de 8 KV, 128 dimensões e FP16 que equivale a 327.680 bytes por token – um terço de megabyte – que em um contexto de 8K equivale a cerca de 2,7 GB por solicitação simultânea. Os 45 GB de espaço que pareciam tão confortáveis equivalem a cerca de uma dúzia de usuários, e o décimo terceiro fica na fila. O planejamento de capacidade para inferência é o planejamento de cache KV; os pesos apenas definem a taxa de entrada.

A contagem de cabeças KV é o número que realmente se move

A atenção à consulta agrupada é a razão pela qual os modelos modernos de peso aberto são utilizáveis, e é rotineiramente ignorada por qualquer pessoa que dimensione o hardware a partir de uma contagem de parâmetros. Um modelo com 64 cabeçotes de atenção e cabeçotes de 8 KV armazena um oitavo do cache de um design de múltiplos cabeçotes equivalente, que converte quase linearmente em oito vezes a simultaneidade na mesma placa. Experimente a predefinição de múltiplos cabeçotes de 13B acima em comparação com a predefinição de 70B: o modelo menor geralmente é aquele que fica sem memória primeiro, o que não é intuitivo até que você veja para onde vão os bytes. Reduzir pela metade a precisão do KV para FP8 dobra a simultaneidade novamente por um custo modesto de precisão. Esses dois switches movimentam a capacidade muito mais do que comprar uma placa maior e não custam nada.

A utilização decide a economia, não o hardware

A mesa final é aquela que encerra honestamente a maioria dos projetos de auto-hospedagem. Um H100 alugado custa os mesmos US$ 2,50 por hora às 3h sem tráfego e no horário de pico, então seu custo real por milhão de tokens é o número principal dividido pelo seu ciclo de trabalho médio. Sirva com 20% de utilização e você estará pagando cinco vezes o que o número otimista da calculadora sugere – e em comparação com as taxas API de commodities para um modelo pequeno, isso não chega nem perto. A auto-hospedagem vence em volume sustentado, saturado e previsível, em cargas de trabalho com residência de dados ou restrições de latência que uma API não consegue atender e em modelos que ninguém vende por token. Perde no tráfego intenso e perde silenciosamente, porque a fatura é fixa e a capacidade desperdiçada nunca aparece como um item de linha. Cruze a conclusão com a calculadora LLM vs API auto-hospedada, avalie o próprio hardware com o Calculadora de custos de inferência de GPU, e se a resposta for marginal, observe um modelo menor destilado ou cache de prompt antes de comprar um rack.

Como funciona esta calculadora

Os pesos são parâmetros × bytes por parâmetro. O cache KV por token é 2 × camadas × cabeças KV × dimensão da cabeça × bytes KV; multiplicado pelo comprimento do contexto que fornece a memória que cada sequência simultânea contém. A memória utilizável é o VRAM total em suas GPUs menos a porcentagem de sobrecarga de tempo de execução e o que resta após os pesos serem divididos pelo valor por sequência para fornecer o teto de simultaneidade. O custo por milhão de tokens é a conta horária da GPU dividida pelos tokens que você realmente gera em uma hora, e é por isso que a tabela de utilização é tão importante quanto a de memória.

Perguntas frequentes

Como calculo a VRAM que um LLM auto-hospedado precisa?

Três termos: pesos do modelo (parâmetros × bytes por parâmetro), o cache KV (2 × camadas × cabeças KV × dimensão da cabeça × bytes, por token, vezes comprimento do contexto, vezes sequências simultâneas) e sobrecarga de 10-20% para contexto CUDA, ativações e fragmentação. Os pesos são uma taxa de entrada fixa; o cache KV é o termo que se adapta ao tráfego e define seu teto de simultaneidade.

Por que a atenção às consultas agrupadas é tão importante para a simultaneidade?

Porque o cache KV é dimensionado com cabeçotes KV, não com cabeçotes de atenção. Um modelo com 64 cabeças de atenção, mas 8 cabeças KV, tem um cache oito vezes menor do que o equivalente com múltiplas cabeças, que converte quase um por um em oito vezes as sequências simultâneas no mesmo cartão. Tamanho do arquivo de configuração do modelo, não da contagem de parâmetros.

Quando a auto-hospedagem é realmente mais barata do que pagar por token?

Somente com utilização elevada e sustentada. Uma GPU alugada cobra a cada hora, independentemente de uma solicitação chegar ou não, portanto, com um ciclo de trabalho de 20%, seu custo real por milhão de tokens é cinco vezes o valor principal. A taxa de transferência de equilíbrio acima são os tokens por segundo que você deve sustentar em média - não no pico - para que a auto-hospedagem supere a taxa de API inserida.