LLM VRAM Calculator: Dimensione a GPU antes de baixar o modelo.

Some três partes. Os pesos são o número de parâmetros multiplicado pelos bits por peso da quantização escolhida, dividido por 8 para obter bytes e por 2^30 para obter GiB — um modelo de 8B ocupa cerca de 15 GiB em FP16, 8 GiB em Q8_0 e 4,6 GiB em Q4_K_M. O cache KV cresce com o tamanho do contexto (próxima pergunta), e o runtime acrescenta um buffer fixo, que esta calculadora fixa em 1,5 GiB. O total precisa caber na memória da placa com alguma folga; se não couber, escolha uma quantização menor ou um contexto mais curto antes de partir para uma GPU maior.

A quantização guarda cada peso em menos bits do que os 16 com que ele foi treinado. FP16 mantém 16 bits por peso (bpw); Q8_0 usa cerca de 8,5 bpw e é praticamente sem perdas; Q4_K_M usa cerca de 4,89 bpw — mais ou menos um terço do tamanho FP16 — com um pequeno custo de qualidade que a maioria não percebe num chat. Os valores fracionários vêm dos layouts mistos do llama.cpp, que mantêm alguns tensores sensíveis em precisão maior e guardam um fator de escala por bloco; por isso um arquivo «de 4 bits» não é exatamente metade de um de 8 bits.

Cada token do contexto guarda um vetor chave e um vetor valor em cada camada, então o cache KV é 2 × camadas × cabeças KV × dimensão da cabeça × tokens × 2 bytes em FP16. Para o Llama 3.1 8B (32 camadas, 8 cabeças KV, dimensão da cabeça 128) são 128 KiB por token: 1 GiB com 8.192 tokens e 16 GiB com os 131.072 completos — mais do que os próprios pesos em Q4_K_M. A atenção de consulta agrupada (8 cabeças KV em vez de 32) divide o cache por quatro, e é por isso que o Llama 3 aguenta contextos longos onde o Llama 2 não aguentava. O controle deslizante de contexto desenha o cache como um segmento próprio da barra para você ver para onde a memória vai.

Memória de GPU é vendida em gigabytes binários: uma RTX 4090 «de 24 GB» tem 24 GiB, que são 25,77 GB. Um GB são 10^9 bytes e um GiB são 2^30 = 1.073.741.824 bytes, 7,37% a mais, então dividir por 10^9 faria cada modelo parecer 7,4% maior do que é e erraria os veredictos bem no limite. A calculadora divide por 2^30 em todo lugar, para que um veredicto compare coisas iguais.

Pesos e cache KV não são tudo: o runtime (llama.cpp, Ollama, vLLM) aloca buffers de computação para as ativações, o contexto CUDA ou Metal ocupa algumas centenas de MiB e o driver reserva um pouco de memória própria. 1,5 GiB é uma estimativa redonda que cobre isso para a maioria dos modelos em uma única placa; o valor real varia com o runtime, o tamanho do lote e a GPU. Trate como margem, não como medida — se um veredicto cair a menos de meio GiB de um degrau, espere problemas.

Não inteiramente na GPU. O Llama 3.1 70B em Q4_K_M precisa de cerca de 40 GiB só para os pesos, antes do cache KV e do overhead do runtime, então uma única placa de 24 GiB não consegue guardá-lo. Ele cabe em uma placa de 48 GiB (RTX 6000 Ada, A6000) ou dividido entre duas placas de 24 GiB com divisão por camadas; Q2_K, com cerca de 3,16 bpw, baixa os pesos para uns 26 GiB, ainda demais para uma placa e com custo de qualidade visível. Os runtimes podem descarregar as camadas restantes para a RAM do sistema, mas a velocidade de tokens cai então para o que a largura de banda de memória da CPU permite, normalmente poucos tokens por segundo.

O Apple Silicon compartilha um único pool de memória entre CPU e GPU, então um Mac com 64 GB carrega modelos que nenhuma placa de 24 GiB aceita. Por padrão o macOS deixa a GPU usar cerca de 75% da memória unificada (uns 48 GiB numa máquina de 64 GB) e guarda o resto para o sistema; o sysctl iogpu.wired_limit_mb pode elevar o limite por sua conta e risco. Informe como orçamento cerca de três quartos da memória do Mac, e lembre que a largura de banda, não a capacidade, define a velocidade de tokens: um M-series Max move cerca de 400 GB/s, uma RTX 4090 perto de 1 TB/s.

Não. A calculadora roda 100% no cliente: os presets de arquitetura e a aritmética chegam junto com a página, e cada número é calculado na aba do seu navegador. Nada é enviado a um servidor, não há conta nem cadastro, e o link de compartilhamento codifica sua seleção no fragmento da URL, que os navegadores nunca enviam a um servidor.

Só para os pesos: um modelo de 8B precisa de cerca de 4,6 GiB em Q4_K_M, 7,9 GiB em Q8_0 e 14,9 GiB em FP16 (um de 7B, cerca de 4,0, 6,9 e 13,0 GiB); um de 14B, cerca de 8,0, 13,9 e 26,1 GiB; um de 70B, cerca de 39,9, 69,3 e 130,4 GiB. Some o cache KV do seu contexto — com 8.192 tokens é 1 GiB para o Llama 3.1 8B e 2,5 GiB para o Llama 3.1 70B — mais o overhead de 1,5 GiB do runtime, de modo que um 8B em Q4_K_M com 8k de contexto fica perto de 7,1 GiB no total. Cada modelo popular tem sua própria página com o número real de camadas e de cabeças KV, para você ler direto o veredicto daquele modelo.

Os pesos têm tamanho fixo, mas o cache KV cresce a cada token: custa 2 × camadas × cabeças KV × dimensão da cabeça × 2 bytes por token em FP16. Para o Llama 3.1 8B são 2 × 32 × 8 × 128 × 2 = 128 KiB por token, então o contexto completo de 131.072 tokens precisa de 16 GiB de cache contra cerca de 4,6 GiB de pesos em Q4_K_M. É a atenção de consulta agrupada que o mantém pequeno assim — 8 cabeças KV em vez de 32 reduzem o cache a um quarto —, enquanto modelos antigos com atenção multicabeça, com uma cabeça KV por cabeça de consulta, estouram a memória em contextos bem mais curtos.