Calculadora de VRAM

A velocidade é uma estimativa limitada pela largura de banda para decodificação de fluxo único, não um benchmark. O processamento de prompt é limitado pelo poder computacional e se comporta de forma diferente.

Como ler o detalhamento de três partes

Quase toda discussão na internet sobre "vai caber" é, na verdade, uma discussão sobre qual dos três números alguém esqueceu. O tamanho do download no card do modelo é um deles. Os outros dois só existem quando o modelo é carregado e está respondendo, que é exatamente quando a falta de memória causa problemas.

Pegue o Llama 3.1 8B em Q4_K_M com contexto de 8K, uma requisição por vez, cache F16. Essa é a configuração local mais comum que existe, e aqui está cada byte dela:

weights  = 8.03e9 params x 4.85 bits / 8      = 4.87e9 bytes = 4.53 GB
kv       = 2 x 32 layers x 8 kv-heads x 128 dim
           x 8192 tokens x 2 bytes             = 1.07e9 bytes = 1.00 GB
overhead = 0.65 + 0.08 x (4.53 + 1.00)                        = 1.09 GB
                                                                -------
total                                                            6.63 GB

Os pesos são a única parte que você pode consultar. Eles são pura aritmética: contagem de parâmetros vezes bits por peso, dividido por oito. Nada na sua carga de trabalho os altera. Se você nunca tocasse nos outros dois números, concluiria que um modelo de 8B a 4 bits precisa de 4,5 GB e cabe confortavelmente em uma placa de 6 GB. Não cabe.

O KV cache é a parte que se move. Cada token no contexto tem um vetor de chave e valor armazenado para cada camada, para que o modelo possa atender ao passado sem recomputá-lo. É isso que torna a geração rápida, e é por isso que o cache não é opcional. Ele escala linearmente com o contexto, linearmente com requisições simultâneas, e é decidido pelo layout de attention em vez da contagem de parâmetros. Aqui ele custa exatamente 0,125 GB por 1024 tokens, o que é pequeno porque o Llama 3.1 usa oito cabeças de chave-valor para trinta e duas cabeças de consulta.

A sobrecarga de runtime é a parte que ninguém orça e todos encontram. Kernels compilados, contexto CUDA ou Metal, buffers de ativação e logit, o alocador que não consegue empacotar blocos perfeitamente e o conjunto de trabalho do sampler. Esta calculadora a modela como um valor fixo de 0,65 GB mais 8 por cento de todo o resto. É uma aproximação deliberada, mas a forma está correta: a sobrecarga não desaparece em modelos pequenos e não permanece constante em modelos grandes.

Uma nota sobre unidades, porque causa confusão real. Cada GB nesta página é calculado dividindo por 1024 elevado à terceira potência, então é tecnicamente um gibibyte. Essa é a mesma unidade que seu driver de GPU relata, por isso uma placa vendida como 24 GB mostra cerca de 24564 MiB. Arquivos de modelo no Hugging Face geralmente são listados em gigabytes decimais, então um download de 5,0 GB aparece aqui como aproximadamente 4,65 GB. A diferença é de cerca de 7 por cento e joga a seu favor, não contra você.

Escolhendo um nível de quantização

A quantização armazena cada peso em menos bits. Um modelo lançado em BF16 gasta dois bytes por parâmetro; uma quantização de 4 bits gasta pouco mais de meio byte. Nada mais no modelo muda, por isso a quantização é a maior alavanca que você tem para decidir se algo cabe.

Aqui está um modelo, Llama 3.3 70B, em todos os níveis que esta calculadora oferece. Pesos são o arquivo no disco; as outras duas colunas são o footprint total carregado, incluindo cache e sobrecarga em um único fluxo com cache F16.

Três pontos nessa tabela merecem atenção. Primeiro, a contagem nominal de bits é uma estimativa imprecisa. Q4_K_M não tem 4 bits por peso, mas sim 4,85, pois os formatos K-quant mantêm tensores de attention e embedding em precisão maior, onde o dano é mais crítico. Q2_K tem média de 3,35 bits pelo mesmo motivo. Se você calcular o tamanho de um modelo como parâmetros vezes quatro sobre oito, subestimará o valor em cerca de um quinto.

Segundo, os retornos diminuem drasticamente à medida que a precisão cai. Passar de BF16 para Q8_0 reduz o modelo pela metade sem perda mensurável. Passar de Q8_0 para Q4_K_M reduz quase pela metade novamente, com uma perda de qualidade que a maioria não percebe no uso comum. Passar de Q4_K_M para Q3_K_M economiza 7,8 GB, mas começa a resultar em pior seguimento de instruções, código mais fraco e mais erros aritméticos. Abaixo disso, você sacrifica capacidade de processamento de forma perceptível.

Terceiro, o dano da quantização agressiva não é distribuído uniformemente entre os tamanhos de modelo. Um modelo de 70B em Q2_K ainda é utilizável devido à enorme redundância. Um de 3B em Q2_K frequentemente produz saídas corrompidas. A regra prática: prefira um modelo maior com quantização menor até cerca de 4 bits, e prefira um modelo menor em 4 bits ou mais abaixo disso. Um 70B em Q4_K_M supera um 32B em Q8_0 na maioria das tarefas; um 70B em IQ2_XXS geralmente não.

Um caso especial importante: alguns modelos são publicados nativamente em formato de poucos bits, em vez de serem quantizados posteriormente. O gpt-oss é distribuído em MXFP4 a 4,25 bits por peso e, como o treinamento considerou isso, a qualidade não é comparável a uma compressão de 4 bits de uma versão BF16. Por isso, a calculadora só oferece MXFP4 para modelos que já vêm nesse formato, e por isso o gpt-oss 120B ocupa 63,4 GB em vez dos 250 GB que um modelo de 117B precisaria em precisão total.

Por que o tamanho do contexto é uma decisão de hardware

Muitos tratam o tamanho do contexto como uma flag de funcionalidade: se o model card diz 128K, configuram 128K. Não é uma flag, é uma alocação de memória e, em algumas arquiteturas, é o maior item no orçamento de recursos. Abaixo, quatro modelos em Q4_K_M, stream único, cache F16, com o footprint total carregado em quatro tamanhos de contexto.

O Llama 3.1 8B quadruplica de tamanho entre 2K e 128K, de 5,8 GB para 22,8 GB, o que define se ele roda em quase qualquer lugar ou se não cabe em uma placa de 24 GB. O Command R 35B é o caso extremo: começa menor que o Qwen3 32B em 2K e termina quase quatro vezes maior em 128K, pois usa multi-head attention completa com 64 heads de key-value, consumindo 1,25 GB de cache a cada 1024 tokens. O Gemma 3 27B quase não muda, pois cinco de cada seis camadas focam apenas em uma janela de 1024 tokens, parando de crescer quase imediatamente.

A consequência prática é que o tamanho do contexto configurado deve ser o que você realmente usa, não o máximo suportado. Se seus prompts têm 3000 tokens e respostas 800, configurar 32K desperdiça memória que poderia ser usada em uma quantização melhor. O Llama 3.1 8B em Q4_K_M em uma placa de 24 GB suporta contexto de 64K, mas não 128K, pois 128K exige 22,8 GB e a placa só libera cerca de 22,3 GB após o uso do sistema. Reduzir o cache para Q8 resolve. Nada mais precisa mudar.

O runtime utilizado também importa. O llama.cpp aloca cache apenas para o tamanho de contexto definido, liberando memória com contextos menores. O vLLM reserva uma fração da placa antecipadamente e gerencia um pool paginado, fazendo com que o nvidia-smi mostre a placa quase cheia independentemente da configuração. O valor desta calculadora é o working set necessário, que mapeia diretamente o comportamento do llama.cpp e o pool que o vLLM precisa alocar.

O cache é definido pela arquitetura, não pelo tamanho

O fato mais útil sobre o KV cache é que a contagem de parâmetros quase não o prevê. O que o prevê é quantas key-value heads o modelo mantém, a largura de cada uma, o número de camadas e se há otimizações. Abaixo, o custo de cache por 1024 tokens para modelos que variam em três ordens de magnitude em parâmetros.

Compare as linhas superior e inferior. Um modelo de 671B tem cache menor que um de 35B, e um de 3,8B tem cache quatro vezes e meia maior que um de 27B. O Phi-3.5 mini em contexto de 128K precisa de 54,8 GB no total, sendo apenas 2,2 GB de pesos. É um modelo descrito como pequeno que precisa de mais memória que um de 32B.

Quatro mecanismos explicam a tabela. O Grouped-query attention compartilha uma key-value head entre várias query heads, padrão atual da indústria que reduz o cache de quatro a oito vezes. O Sliding-window attention dá às camadas uma janela fixa, impedindo o crescimento do cache, por isso Gemma 3 e gpt-oss estabilizam. O Multi-head latent attention, usado pelo DeepSeek, comprime keys e values em um vetor de 576 elementos por token/camada em vez de armazená-los integralmente. O multi-head attention simples, usado em versões antigas como Command R e Phi-3.5, não faz nada disso e paga por cada head.

Se você deseja a versão detalhada deste argumento com as derivações, ela está documentada separadamente em por que a contagem de parâmetros é um mau preditor de VRAM.

Quando a quantização de KV cache vale a pena

O cache pode ser quantizado como os pesos. F16 gasta 2 bytes por elemento; a opção Q8 tem média de 1,06 bytes e Q4 de 0,56, com o overhead vindo de escalas por bloco. Runtimes sérios suportam: llama.cpp expõe como cache-type-k e cache-type-v, vLLM como flag kv-cache-dtype.

A questão não é se economiza memória, mas se a economia é relevante, o que depende de quanto do seu footprint é cache. Em um contexto de 32K com pesos Q4_K_M:

O Command R ganha 20,3 GB com uma única flag, a diferença entre precisar de duas placas de 48 GB ou apenas uma. O Llama 3.3 70B ganha 5,1 GB, pois o grouped-query attention já torna seu cache pequeno. O padrão é geral: a quantização de KV é transformadora em modelos multi-head com contexto longo e marginal em modelos grouped-query com contexto curto. Verifique o segmento de KV cache acima antes de usar. Se a barra for fina, a flag não ajudará.

O custo é real, mas limitado. O cache Q8 é quase gratuito em termos de qualidade e deve ser ativado por padrão em cargas de contexto longo. O cache Q4 degrada o propósito do contexto longo: o recall preciso de fatos específicos. Resumos e chat funcionam bem; busca em documentos longos, consultas tipo 'agulha no palheiro' e raciocínio de código em múltiplos arquivos, não. Há uma assimetria: keys são mais sensíveis à quantização que values. Se o runtime permitir, usar cache de keys Q8 com values Q4 é geralmente melhor que Q4 em ambos.

Uma regra infalível: quantize pesos primeiro, cache depois. Pesos Q4_K_M com cache F16 superam pesos Q6_K com cache Q4 no mesmo tamanho total, quase sempre, pois a quantização de pesos foi muito mais estudada e ajustada que a de cache.

Duas placas de 24 GB não equivalem a uma de 48 GB

Dividir um modelo entre GPUs funciona, e para modelos grandes é a única rota viável. Mas a matemática não é simples adição, e a diferença aparece em dois pontos: capacidade utilizável e velocidade de decodificação.

Sobre capacidade, uma placa única perde uma fatia para o driver, a saída de exibição e a fragmentação do alocador. Esta calculadora assume cerca de 93% como utilizável em uma placa de consumo e 95% em uma estação de trabalho ou placa de datacenter sem saída de exibição. Uma divisão multi-placas perde mais, cerca de 90%, porque cada placa carrega seu próprio contexto de execução e sua própria cópia dos buffers de ativação, e porque a divisão de camadas quase nunca é uniforme. Portanto, duas RTX 4090s oferecem cerca de 43,2 GB de espaço de trabalho, enquanto uma única RTX 6000 Ada com os mesmos 48 GB nominais fornece 45,6 GB.

Essa diferença de 2,4 GB decide casos reais. O Llama 3.3 70B no Q4_K_M com contexto de 8K precisa de 46,4 GB, então não cabe em nenhuma das opções. Mudar o cache para Q8 reduz para 45,1 GB, que cabe em uma placa de 48 GB, mas ainda não cabe no par. Para rodar em duas 4090s, é necessário reduzir também para pesos Q4_0, totalizando 42,5 GB. Mesma memória nominal, duas concessões extras.

Sobre velocidade, a expectativa comum é que duas placas sejam duas vezes mais rápidas. Para decodificação de fluxo único, não é o caso, e muitas vezes são mais lentas do que uma única placa seria se o modelo coubesse. A divisão padrão no llama.cpp e na maioria das configurações de nó único é o paralelismo de pipeline: as camadas 0 a 39 ficam na placa um, 40 a 79 na placa dois. Ao gerar um token, ele percorre todas as oitenta camadas em ordem, então exatamente uma GPU está realizando trabalho útil a qualquer momento enquanto a outra espera, além de uma transferência de estado oculto via PCIe na fronteira. Você comprou capacidade, não throughput. Esta calculadora modela isso como uma queda na eficiência de largura de banda de 0,75 em uma placa única para 0,6 em uma divisão, o que coloca duas RTX 4090s em cerca de 13 tokens por segundo em um modelo 70B e uma única RTX 6000 Ada em cerca de 16, apesar do par ter maior largura de banda bruta por placa.

O paralelismo de tensor, usado pelo vLLM e TensorRT-LLM, é a alternativa: cada camada é dividida entre todas as placas e elas trabalham simultaneamente. Isso realmente escala a velocidade de decodificação, mas requer uma operação all-reduce entre placas a cada camada, então precisa de NVLink ou pelo menos x16 PCIe completos para cada placa. Em uma placa-mãe de consumo com a segunda placa em x4, o paralelismo de tensor pode ser mais lento que o de pipeline. Também requer que o número de cabeças de atenção seja divisível pelo número de placas, o que torna configurações com três placas problemáticas.

Resumindo de forma prática: adicione placas para rodar um modelo que, de outra forma, não seria possível executar, não para tornar um modelo já executável mais rápido. E se você está escolhendo entre uma placa grande e duas pequenas pelo mesmo preço, a placa única vence em simplicidade, consumo de energia, capacidade utilizável e latência de fluxo único. Múltiplas placas vencem quando você está servindo requisições concorrentes, onde o agrupamento mantém todas as placas ocupadas.

O que acontece ao transferir para a RAM do sistema

Se um modelo não cabe, o llama.cpp e o Ollama mantêm algumas camadas na RAM do sistema e as executam na CPU. Funciona. Mas é também nesse ponto que as pessoas concluem que seu hardware está quebrado, porque a velocidade não degrada suavemente.

O motivo é que a decodificação é limitada pela largura de banda de memória, não pelo processamento. Para produzir um token, o tempo de execução lê todos os pesos ativos e todo o cache uma vez. Para o Llama 3.3 70B no Q4_K_M com contexto de 8K, isso representa cerca de 45,5 GB de leituras por token. Divida isso pela largura de banda da memória que o armazena e você terá seu limite antes que qualquer processamento ocorra.

Uma RTX 4090 lê a 1008 GB/s. DDR5 de canal duplo em um desktop típico lê cerca de 90 GB/s. Isso é uma diferença de onze vezes, e é a história toda. Se o modelo 70B coubesse inteiramente na 4090, decodificaria a cerca de 17 tokens por segundo. Mas não cabe: 22,3 GB dos 46,4 GB residem na placa, então 52% de cada leitura de token vêm da RAM do sistema a um nono da velocidade. O resultado é cerca de 2,6 tokens por segundo. Você manteve 48% do modelo no dispositivo rápido e perdeu 84% da velocidade.

A mesma lógica se aplica em todas as escalas. O Llama 3.1 8B lê 5,9 GB por token; em uma 4090, isso representa cerca de 127 tokens por segundo, e inteiramente na CPU com 90 GB/s de RAM, cerca de 11. O Qwen3 32B no Q4_K_M precisa de 22,8 GB, então em uma RTX 5080 de 16 GB cerca de 65% permanece residente e a estimativa cai de cerca de 33 tokens por segundo para cerca de 8.

Dois detalhes tornam a experiência real pior do que esses números sugerem. O processamento de prompt em camadas de CPU é limitado por processamento, não por largura de banda, então um prompt longo pode levar minutos antes que o primeiro token apareça, mesmo quando a taxa de streaming posterior parece aceitável. E a transferência para a RAM não é gratuita do lado da GPU, pois o tempo de execução ainda precisa de buffers de trabalho para as camadas que hospeda.

Quando transferir para a RAM ainda é a escolha certa: jobs em lote nos quais você não está esperando, modelos onde alguns tokens por segundo são suficientes, e casos onde apenas algumas camadas são transferidas. Transferir 10% custa muito menos do que 50%. Quando não é a escolha certa: qualquer coisa interativa. Um modelo menor com boa quantização quase sempre atenderá melhor do que um maior rastejando pela sua RAM, e se precisar da capacidade do modelo maior, chamá-lo via API é mais rápido e barato do que fazer seu desktop fingir.

Apple Silicon e memória unificada

Apple Silicon não tem VRAM separada. A CPU e a GPU compartilham um pool de LPDDR no mesmo pacote, o que significa que um Mac com 128 GB de memória pode carregar um modelo que nenhuma GPU de consumo no mercado consegue armazenar. Essa é uma vantagem real e é por isso que Macs são comuns no meio de inferência local. Mas há duas ressalvas que as pessoas descobrem tarde demais.

A primeira é que você não obtém tudo. O macOS reserva memória para tudo o mais que a máquina está fazendo e limita o que a GPU pode alocar; esta calculadora assume que cerca de 75% está disponível para um modelo, então 128 GB de memória unificada se tornam cerca de 96 GB de orçamento e um Mac mini de 16 GB se torna cerca de 12 GB. O limite pode ser aumentado com a configuração iogpu wired limit, mas aproximá-lo do total físico arrisca o sistema fazer swap, e swapar um modelo é pior do que não carregá-lo.

A segunda é a largura de banda. Memória unificada é ampla, mas não é tão rápida quanto GDDR. Um M4 Max lê cerca de 546 GB/s contra 1008 GB/s em uma RTX 4090 e 1792 GB/s em uma RTX 5090, e o M4 base em um Mac mini lê cerca de 120 GB/s, um terço do que uma RTX 3060 de cinco anos consegue. No Llama 3.1 8B no Q4_K_M, isso resulta em cerca de 60 tokens por segundo em um M4 Max, cerca de 13 em um Mac mini base M4 e cerca de 45 na RTX 3060. Capacidade e velocidade são compras separadas, e a Apple vende muito mais da primeira por dólar e relativamente pouco da segunda.

O processamento de prompt é a parte mais crítica. A decodificação é limitada por largura de banda, onde a Apple está apenas atrás; o preenchimento (prefill) é limitado por processamento, onde a lacuna em relação a uma placa NVIDIA moderna com núcleos tensor dedicados é muito maior. Um documento de 30.000 tokens colado em um chat no Mac pode ficar parado por um tempo perceptível antes que algo seja transmitido, mesmo que o streaming posterior pareça bom. Se seu workload envolve prompts longos e respostas curtas, esse é o número a testar antes de comprar.

Onde um Mac vence claramente é na faixa intermediária que placas discretas não alcançam por preços razoáveis. O Llama 3.3 70B no Q4_K_M cabe confortavelmente em um M4 Max de 128 GB a cerca de 8 tokens por segundo, e um M2 Ultra de 192 GB o executa a cerca de 11 enquanto também consegue armazenar modelos que precisam de mais de 100 GB. Para chegar lá com hardware NVIDIA, são necessárias várias placas, uma placa-mãe com as lanes para alimentá-las e uma fonte de energia compatível. Use o MLX em vez de um backend genérico quando possível, pois ele é escrito para esse modelo de memória e consistentemente supera as alternativas na mesma máquina.

Atendendo mais de uma pessoa por vez

Tudo acima assume uma requisição por vez. No momento em que você coloca o modelo atrás de um endpoint que outras pessoas usam, os pesos permanecem compartilhados, mas cada requisição concorrente carrega seu próprio cache KV. Isso transforma o cache de um item secundário no custo dominante. Llama 3.1 8B no Q4_K_M com contexto de 8K, em níveis crescentes de concorrência:

Com dezesseis usuários concorrentes, o cache é maior que o modelo. Com trinta e dois, um modelo 8B precisa de mais memória do que um 70B para um único usuário. Esse é o número que surpreende equipes que prototiparam em um laptop e depois se perguntaram por que o servidor travou com oito pessoas usando.

A vantagem é que a concorrência é onde as GPUs deixam de ser desperdiçadas. A decodificação de fluxo único deixa a maior parte do processamento ociosa porque está esperando pela memória; o agrupamento amortiza uma leitura de peso entre muitas sequências, então o throughput total sobe muito mais rápido do que o uso de memória. Esse também é o caso em que um cache paginado vale a pena, já que o vLLM aloca o cache em blocos conforme as sequências realmente crescem, em vez de reservar o pior caso para cada slot. Se você estiver dimensionando um servidor, dimensione-o para o cache na sua concorrência real e no comprimento real mediano do prompt, não para o contexto máximo multiplicado pelo número máximo de usuários.

Erros comuns ao dimensionar uma GPU

Perguntas que as pessoas realmente fazem

Quanta VRAM preciso para rodar um modelo de 7B ou 8B?

Cerca de 6,6 GB em Q4_K_M com um contexto de 8K, o que cabe em uma placa de 8 GB com uma pequena margem. Em BF16, o mesmo modelo precisa de 17,9 GB e requer uma placa de 24 GB. Se você quiser o contexto completo de 128K, o valor sobe para 22,8 GB, portanto, o contexto é tão importante quanto a precisão aqui.

Por que meu modelo de 8 GB se recusa a carregar em uma placa de 8 GB?

Três motivos se acumulam. O driver e a área de trabalho já ocupam cerca de 7 por cento da placa, o KV cache é alocado sobre os pesos e o runtime precisa de aproximadamente 0,65 GB de espaço de contexto e kernel antes de realizar qualquer tarefa. O tamanho do arquivo é o único número que não inclui nada disso.

Uma placa de 24 GB consegue rodar um modelo de 70B?

Não apenas na VRAM. O Llama 3.3 70B precisa de 46,4 GB em Q4_K_M e 8K, e mesmo em IQ2_XXS com um contexto de 2K, ele ainda precisa de 22,5 GB contra aproximadamente 22,3 GB disponíveis. Você pode descarregar para a RAM do sistema e obter alguns tokens por segundo, ou rodar um de 32B e obter trinta.

Q4_K_M é realmente bom o suficiente?

Para quase tudo, sim, e é o padrão por um bom motivo. Ele armazena 4,85 bits por peso em vez de 4 fixos, mantendo os tensores de attention e embedding em uma precisão maior. A diferença mensurável para Q8_0 é pequena e a economia de memória é de quase metade. Reduza abaixo disso apenas quando a alternativa for não rodar o modelo de forma alguma.

Um modelo maior em baixa precisão é melhor do que um menor em alta precisão?

Até cerca de 4 bits, sim. Um 70B em Q4_K_M supera um 32B em Q8_0 na maioria das tarefas com um footprint similar. Abaixo de 3 bits, a ordem se inverte para modelos pequenos e médios, porque há menos redundância para descartar. Modelos muito grandes toleram formatos de 2 bits muito melhor do que os pequenos.

Por que o KV cache em um modelo de 3,8B é maior do que em um de 27B?

Porque o Phi-3.5 mini usa multi-head attention completa com 32 cabeças de key-value, a 0,375 GB por 1024 tokens, enquanto o Gemma 3 27B dá a cinco de cada seis camadas uma janela deslizante de 1024 tokens. Em 128K, isso representa 48 GB contra 10,4 GB. O tamanho do cache segue o layout de attention, não a contagem de parâmetros.

Devo quantizar o KV cache?

Ative Q8 sempre que seu contexto for longo; o custo é quase nulo. Use Q4 apenas quando o cache representar uma grande parte do seu footprint e sua carga de trabalho não exigir alta capacidade de recall. No Command R 35B em 32K, o Q8 economiza 20,3 GB. No Llama 3.3 70B no mesmo contexto, ele economiza 5,1 GB, porque o grouped-query attention já realizou o trabalho.

Duas placas de 24 GB equivalem a uma placa de 48 GB?

Não. Você obtém aproximadamente 43,2 GB utilizáveis em vez de 45,6, porque cada placa carrega seu próprio contexto de runtime e a divisão de camadas é desigual. A velocidade de stream único também não melhora, já que o pipeline parallelism significa que uma placa calcula enquanto a outra espera. Duas placas oferecem capacidade e, sob concorrência, throughput.

Qual será a velocidade real?

Divida a largura de banda da memória pelos bytes lidos por token. O Llama 3.1 8B em Q4_K_M lê 5,9 GB por token, então uma RTX 4090 a 1008 GB/s chega a cerca de 127 tokens por segundo após as perdas de eficiência. Essa estimativa vale apenas para decodificação. O processamento de prompt é limitado pelo poder computacional e segue uma curva diferente.

O que acontece de fato se eu descarregar para a RAM do sistema?

A velocidade cai drasticamente em vez de diminuir gradualmente. O Llama 3.3 70B com 48 por cento de suas camadas em uma RTX 4090 e o restante em DDR5 decodifica a aproximadamente 2,6 tokens por segundo em vez dos 17 que conseguiria se estivesse totalmente residente. Um pequeno excesso é suportável; metade do modelo, não.

Um Mac é uma boa máquina para inferência local?

Para capacidade por dólar, sim: um M4 Max de 128 GB oferece cerca de 96 GB de orçamento utilizável e roda um 70B a cerca de 8 tokens por segundo. Para velocidade bruta, não: 546 GB/s de largura de banda contra 1792 em uma RTX 5090, e o processamento de prompt é ainda mais lento. Compre um para modelos grandes e operação silenciosa, não por latência.

Modelos mixture-of-experts economizam memória?

Eles economizam tempo, não espaço. O Qwen3 30B-A3B ainda precisa de 20,1 GB porque cada expert deve estar residente, mas ele lê apenas cerca de 3,3B de parâmetros por token, então decodifica várias vezes mais rápido do que um modelo denso de 32B no mesmo footprint. Avalie um modelo MoE pelo total para caber na memória e pelos parâmetros ativos para velocidade.

O flash attention reduz a VRAM?

Ele remove a grande matriz de attention intermediária, o que é uma economia real durante o prefill em prompts longos, e torna o processamento de prompt mais rápido. Ele não reduz o KV cache, que é a parte que cresce com o seu contexto. Ative-o de qualquer forma; apenas não espere que os totais nesta página mudem.

Por que o nvidia-smi mostra a placa cheia quando defino um contexto pequeno?

Você provavelmente está rodando o vLLM, que reivindica uma fração fixa da placa na inicialização e gerencia um pool de cache paginado dentro dela. O llama.cpp aloca apenas o que o contexto solicitado precisa. Os números aqui descrevem o working set, que é o que o vLLM precisa ser capaz de alocar e o que o llama.cpp relata diretamente.

Quanta VRAM preciso para fazer fine-tune em vez de apenas rodar um modelo?

Muito mais, e esta calculadora não modela isso. Um fine-tune completo mantém pesos, gradientes e estado do otimizador a aproximadamente 16 bytes por parâmetro, então um modelo de 8B chega perto de 130 GB antes das ativações. QLoRA em uma base de 4 bits é muito mais próximo do footprint de inferência mais a memória de ativação, por isso é a única opção realista em uma única placa de consumo.

Modelos de visão mudam o cálculo?

O vision encoder está incluído na contagem de parâmetros dos modelos multimodais listados aqui, então o valor dos pesos está correto. O que os totais não capturam é que as imagens são expandidas em um grande número de tokens antes de chegarem ao modelo de linguagem, portanto, algumas imagens de alta resolução podem consumir mais contexto e, consequentemente, mais cache do que uma página de texto.

E se nada couber?

Reduza o contexto primeiro, já que geralmente é a concessão mais barata, depois quantize o cache para Q8 e, em seguida, reduza os pesos em um nível. Se ainda não for suficiente, um modelo menor em uma quantização sensata supera um maior que está lento por usar a RAM do sistema. Ou chame os mesmos modelos de pesos abertos pela API gratuita e deixe que outra pessoa seja dona do hardware.