GGUF, quantização e VRAM: calcule a memória para executar modelos localmente

A quantização reduz o espaço dos pesos, mas não toda a memória necessária

A quantização representa os pesos de um modelo com menor precisão numérica para reduzir o espaço ocupado e, em alguns equipamentos, acelerar a inferência. Em arquivos GGUF, você encontrará nomes como Q4_K_M, Q5_K_M ou Q8_0. Eles dão pistas sobre a quantização, mas não especificam todo o uso de memória nem garantem determinada qualidade ou velocidade.

GGUF é um formato de contêiner de modelos usado com frequência pelo llama.cpp e por ferramentas baseadas nesse mecanismo. Não é sinônimo de quantização: pode armazenar pesos em diferentes tipos e níveis de precisão. Além disso, “Q4” não significa que cada parâmetro ocupe exatamente quatro bits. Metadados, escalas e partes armazenadas com outra precisão aumentam o tamanho. Por isso, quando disponível, consulte o tamanho real do arquivo quantizado que será carregado.

Para dimensionar uma implantação, é preciso separar pelo menos quatro componentes: pesos, cache de chaves e valores (KV), memória temporária de cálculo e sobrecarga do mecanismo. A soma depende da arquitetura do modelo, do contexto, do lote, da distribuição entre dispositivos e do software. Um cálculo baseado apenas no número de parâmetros pode descartar uma configuração que caberia ou aprovar outra que falhará quando for necessário reservar memória para a conversa.

A primeira pergunta não é “qual GPU é melhor?”, mas “de qual modelo, contexto, concorrência e latência eu preciso?”. Com isso definido, estime a memória e teste configurações compatíveis. Para comparar mecanismos ou modelos diferentes, consulte uma comparação e defina uma carga de trabalho comum. Para explorar alternativas de inferência local, organize a busca conforme a tarefa e o hardware disponível.

O que significam Q4_K_M, Q5_K_M e Q8_0

Em termos gerais, quantizar significa reduzir a precisão com que os pesos são armazenados. O benefício esperado é usar menos memória para esses pesos; o possível custo é que as respostas se afastem das produzidas pelo modelo de referência. Essa relação não é igual para todos os modelos e não pode ser resumida responsavelmente em uma porcentagem fixa de perda.

Nas variantes GGUF, o número indica uma classe de quantização, mas não descreve toda a composição do arquivo. Os sufixos distinguem métodos e atribuições de precisão. Em nomes como Q4_K_M, a família K e a variante M fazem parte do esquema; não devem ser interpretadas como um multiplicador uniforme de quatro bits. O tamanho do arquivo é um dado mais confiável do que calcular bytes exatos apenas pelo nome.

Como orientação qualitativa, uma configuração Q4 costuma exigir menos espaço para os pesos do que uma Q5 ou Q8 do mesmo modelo. Em contrapartida, Q5 e Q8 preservam mais precisão nos pesos, mas consomem mais memória. Isso não prova que sempre responderão melhor: é preciso medir o desempenho na aplicação específica. Um classificador, um gerador de código e um modelo de conversa geral podem reagir de maneiras diferentes à mesma quantização.

O GGUF também permite escolher formatos de quantização distintos para uma mesma família de modelos, mas a compatibilidade depende do mecanismo e da implementação. Não presuma que dois arquivos com rótulos parecidos serão executados com a mesma velocidade ou produzirão os mesmos resultados. Verifique se o modelo está preparado para o mecanismo, se o backend esperado foi carregado e se a avaliação compara a mesma revisão do modelo.

Calcule separadamente os pesos, o cache KV e a margem

Para uma primeira aproximação, o tamanho dos pesos residentes pode ser estimado a partir do arquivo de modelo que será realmente carregado. Se você conhece apenas o número de parâmetros, uma conta orientativa é multiplicar os parâmetros pelos bytes médios por parâmetro. Mas esse valor médio precisa corresponder à quantização real, e não ao número do nome tratado como exato. No GGUF, a mistura de precisões pode fazer essa simplificação resultar em erro.

O cache KV mantém informações sobre os tokens anteriores de que o modelo precisa durante a geração. Seu tamanho costuma crescer com o comprimento da sequência e o tamanho do lote, e depende da arquitetura: camadas, cabeças KV, dimensão da cabeça e tipo de dado do cache. Uma expressão geral é: duas vezes o número de camadas, multiplicado pelas cabeças KV, pela dimensão da cabeça, pelos tokens armazenados, pelo lote e pelos bytes por elemento. A fórmula deve ser adaptada à implementação e a arquiteturas que utilizem outros mecanismos de atenção.

Para obter as dimensões pertinentes, consulte a configuração do modelo e a documentação do mecanismo, em vez de inferi-las apenas pelo número de parâmetros ou de cabeças de consulta. Em atenção agrupada, o número de cabeças KV pode ser menor que o de cabeças de consulta. Portanto, calcular como se cada cabeça de consulta tivesse seu próprio cache pode superestimar o resultado. Outros projetos de arquitetura podem exigir uma fórmula diferente.

A memória temporária e a sobrecarga não equivalem a uma porcentagem fixa dos pesos. O prefill de prompts longos pode exigir buffers maiores do que a geração token a token. Fragmentação, backend, reserva de memória, bibliotecas e quantidade de GPUs também influenciam. A estimativa da AIMultiple separa pesos, KV, ativações e sobrecarga; é útil como estrutura de cálculo, mas seus resultados devem ser confrontados com o modelo, o mecanismo e a configuração exatos.

Não há uma resposta verificável e única para “quanta VRAM um 7B Q4_K_M precisa com 4096 tokens?” sem especificar o modelo, o lote, o tipo de KV, o mecanismo, a distribuição e a margem. O contexto de 4096 indica o comprimento da sequência, mas, sozinho, não define o tamanho do cache: faltam as dimensões da arquitetura e outros detalhes. O tamanho do arquivo pode servir de referência para os pesos, mas não para a memória total necessária.

Como escolher entre VRAM, RAM e transferência parcial

A VRAM disponível determina quanto pode ficar residente na GPU, enquanto a RAM do sistema pode servir para carregar partes do modelo quando o mecanismo aceita transferência parcial. Mas ter muita RAM não transforma automaticamente uma configuração em uma experiência interativa: mover dados entre RAM e GPU pode reduzir o desempenho, e o resultado depende da conexão entre elas e de como as camadas são distribuídas.

Se a carga exige respostas rápidas e frequentes, priorize manter os pesos e o cache ativo na memória da GPU, com margem suficiente. Se o objetivo é executar um modelo que, de outra forma, não caberia, a transferência para a RAM pode resolver o problema de capacidade, mas com um custo de latência. Não confunda “carrega” com “atende ao requisito de velocidade”.

No Apple Silicon, a memória unificada é compartilhada entre CPU e GPU, mas também é usada pelo sistema e por outros aplicativos. A quantidade de RAM instalada não equivale necessariamente à memória disponível para o modelo. Em equipamentos com várias GPUs, também não basta somar suas capacidades: há custos de comunicação e reservas por dispositivo, e o software precisa oferecer suporte à distribuição prevista.

A largura de banda afeta especialmente a geração, quando os pesos são lidos repetidamente. A capacidade responde se os dados cabem; a largura de banda e a implementação influenciam a velocidade depois do carregamento. O mecanismo, o suporte a kernels, o tipo de quantização e a concorrência podem mudar o resultado. Escolher hardware apenas pela VRAM ou por uma estimativa teórica de largura de banda deixa de fora fatores decisivos.

Não há um mínimo universal para 7B Q4 com 4096 tokens

Um modelo de 7 bilhões de parâmetros em Q4_K_M costuma ocupar menos memória com os pesos do que a mesma família em Q5 ou Q8. Mas esse princípio não se traduz em um valor mínimo universal de VRAM ou RAM. O número de parâmetros não descreve completamente a arquitetura, os tensores que mantêm outra precisão nem o tamanho exato do arquivo.

Os 4096 tokens também não bastam para calcular o cache. Para estimá-lo, são necessários, no mínimo, a arquitetura, o número de camadas, as cabeças KV, a dimensão por cabeça, o tipo de dado da KV e o lote. Se houver uma janela de atenção ou outro mecanismo, o cálculo muda. A resposta responsável é medir uma configuração específica, não prometer que qualquer 7B Q4_K_M funcionará com uma quantidade fixa de memória.

Como procedimento prático, use o tamanho do arquivo específico como referência para os pesos, calcule a KV com os parâmetros da arquitetura e acrescente a memória temporária e a reserva do mecanismo. Depois, verifique o pico de uso ao carregar e gerar. Se o sistema tiver apenas RAM, a execução pode ser possível com um mecanismo compatível, mas não é possível deduzir a velocidade pelo tamanho do modelo.

Por isso, não é recomendável comprar uma placa com base em uma tabela genérica do tipo “7B = X GB”. Primeiro, defina o modelo exato e o objetivo do serviço: usuário único ou concorrência, contexto normal e máximo, respostas em tempo real ou processamento em lote. Um caso de uso bem definido permite dimensionar; o rótulo do número de parâmetros, sozinho, não.

Desempenho: meça velocidade, primeira resposta e concorrência

Tokens por segundo descreve uma parte do desempenho, mas é preciso esclarecer se a medida corresponde ao prefill do prompt ou à geração. A latência até o primeiro token inclui o recebimento, o prefill e a preparação. Ela pode aumentar com prompts extensos, mesmo que a geração posterior seja rápida. Em aplicações interativas, as duas medidas importam.

Para comparar, mantenha constantes o modelo, o prompt, o comprimento da saída, o contexto, o lote, o mecanismo, a versão do software e a temperatura do dispositivo. Faça várias repetições e registre a mediana e a variação, além do pico de memória. Não compare um teste com resposta curta a outro com contexto extenso: seriam cargas diferentes.

As fontes disponíveis não sustentam valores de tokens por segundo ou de latência esperados para um 13B Q5_K_M em uma GPU de 16 GB. O resultado depende da GPU específica, da largura de banda, do modelo e de sua arquitetura, do mecanismo, das camadas transferidas, do contexto e da configuração. Uma estimativa de capacidade não substitui um benchmark naquela máquina.

Para servir vários usuários, meça também o throughput agregado e a latência por solicitação sob concorrência. Um mecanismo otimizado para solicitações simultâneas pode se comportar de maneira diferente de um mecanismo local voltado a uma única conversa. A carga de teste deve refletir o uso real: um usuário gerando código não representa um servidor com várias sessões e prompts longos.

Avalie a perda de qualidade nas tarefas que importam

Não existe um valor único de degradação que descreva a passagem de Q8 para Q4 para todos os modelos e tarefas. A diferença depende da arquitetura, do método de quantização, do conjunto de avaliação e do critério de pontuação. Uma afirmação como “perde 2%” não é interpretável sem especificar a métrica, os dados, a versão e as condições comparadas.

Monte uma avaliação com exemplos representativos e respostas esperadas ou critérios de pontuação definidos antes do teste. Para classificação, use um conjunto rotulado e compare acurácia, precisão, revocação ou F1, conforme o custo de falsos positivos e falsos negativos. Para geração, avalie o cumprimento das instruções, a exatidão factual verificável, o formato e os erros críticos com uma rubrica consistente. Para código, execute testes automatizados nas saídas: não basta parecer correto em uma análise subjetiva.

Compare cada quantização com o mesmo modelo de referência, usando prompts, modelos de conversa e parâmetros de geração idênticos. Mantenha as sementes iguais quando o mecanismo permitir e repita as tarefas estocásticas. Informe tanto a média quanto as falhas graves: uma média semelhante pode esconder uma queda importante em um pequeno grupo de casos.

O trabalho apresentado no alphaXiv sobre o Qwen3.5-4B descreve um caso específico de inferência INT4 com destilação sensível à quantização, decodificação especulativa e uma GPU A10G. É uma evidência sobre aquele sistema e aquela configuração, não uma demonstração de que qualquer quantização Q4 em GGUF preservará a qualidade ou alcançará a mesma aceleração. O trecho disponível tampouco permite generalizar os resultados para um modelo de 13B ou outra GPU.

Critérios para escolher a quantização e o hardware

Comece pelo nível de qualidade exigido pela tarefa, não pela menor quantização que cabe. Se a qualidade de referência for indispensável e houver memória disponível, mantenha uma precisão maior e valide a diferença em relação a Q4. Se o limite for a memória, teste Q4_K_M, meça o desempenho e compare a qualidade. Se ela não for suficiente, considere Q5, reduzir o contexto ou usar outro modelo antes de concluir que a única solução é comprar hardware.

A escolha de hardware deve considerar capacidade de memória, largura de banda, compatibilidade com o mecanismo e facilidade de manutenção da implantação. Um equipamento com VRAM suficiente ainda pode ser lento se a quantização não tiver kernels eficientes ou se parte do modelo for transferida para a RAM. Por outro lado, um modelo que cabe na RAM pode ser útil em testes ou cargas não interativas, mesmo que não alcance a latência de uma GPU.

Avalie cada combinação em uma tabela própria: modelo, quantização, contexto, lote, pico de memória, latência do primeiro token, velocidade de geração e pontuação de qualidade. Essa tabela ajuda a justificar uma compra porque mostra qual requisito realmente não está sendo atendido. Também evita tratar o preço de uma placa como substituto de um teste.

Para comparar mecanismos e configurações, mantenha o mesmo protocolo e consulte uma comparação técnica. Para descobrir modelos compatíveis, filtre por arquitetura, formato, licença e tamanho real do arquivo; não presuma que todas as variantes terão o mesmo comportamento.

Conclusão: valide no equipamento real a estimativa inicial

GGUF facilita a distribuição de modelos locais com diferentes quantizações, mas o rótulo Q4, Q5 ou Q8 não basta para dimensionar uma implantação. Use o tamanho real do arquivo como referência para estimar os pesos, calcule o cache KV com a arquitetura e a configuração previstas e acrescente os buffers e a reserva do mecanismo.

Não existe um valor universal de VRAM para um modelo 7B Q4_K_M com 4096 tokens, nem uma previsão confiável de tokens por segundo para um 13B Q5_K_M em uma GPU de 16 GB sem mais detalhes. Apresentar esses números como garantias ocultaria as variáveis que determinam o resultado.

A decisão final exige duas validações: memória e desempenho na carga real, e qualidade nas tarefas que justificam a implantação. Registre contexto, lote, mecanismo, versões, pico de memória, latência e métricas de qualidade. Assim, você poderá escolher entre mudar a quantização, reduzir o contexto, transferir parte do modelo, usar outro modelo ou ampliar o hardware com base em evidências comparáveis.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.