LLM Calculadora de VRAM para Auto-Hospedagem
Auto-hospedar um LLM significa executar a inferência em hardware que o operador controla, em vez de via uma API de terceiros, o que altera o custo, o controle de dados e o perfil de privacidade. O fato de um modelo executar ou não depende da memória.
LLM Calculadora de Compatibilidade
A calculadora estima a VRAM ou memória unificada que um modelo precisa para executar localmente, com base no modelo, na sua precisão, no comprimento do contexto e no hardware de destino. Ela indica se uma configuração cabe, a divisão de memória entre pesos, cache KV e sobrecarga, e os modelos que uma determinada GPU ou Mac pode executar. Os formatos de quantização e as larguras de precisão seguem a documentação do Transformers da Hugging Face. 1
Consulte nossa metodologia de cálculo de VRAM de LLM auto-hospedado para ver toda a matemática por trás dessas estimativas.
Hardware para auto-hospedagem: GPUs e Apple Silicon
Dois números decidem o hardware. A capacidade é o fator de compatibilidade, e a decodificação é limitada pela largura de banda da memória, portanto os tokens por segundo escalam aproximadamente com os GB/s da placa.
As linhas acima exemplificam cada camada. A calculadora inclui 34 placas no total, adicionando a A100, L40S, RTX A6000, AMD Radeon RX 7900 XTX e a linha AMD Instinct. Com 24 a 32 GB, um modelo de 70B exige quantização pesada mais contexto curto, ou duas placas. Um modelo de 671B exige 640 GB (8×80 GB) como mínimo padrão. A RTX PRO 6000 é a principal placa única de classe workstation, e seu preço de mercado subiu para cerca de $13,000 em meados de 2026, ante um preço sugerido de $8.565.2
Apple Silicon e memória unificada: No Apple Silicon, a CPU e a GPU compartilham um único pool de memória, e a GPU endereça cerca de 75% da RAM total por padrão por meio do recommendedMaxWorkingSetSize da Metal, um pouco menos em Macs menores. O limite pode ser aumentado com sudo sysctl iogpu.wired_limit_mb=, deixando de 8 a 16 GB para o macOS. 3 4 Um Mac de 128 GB expõe cerca de 96 GB para a GPU. O M3 Ultra, com até 512 GB, expõe cerca de 384 GB, suficientes para um modelo da classe 400B em 4 bits com folga de KV em um único dispositivo, sem o custo de replicação multi-GPU. 5 Esse caminho de dispositivo único para modelos grandes é a vantagem da Apple, embora o AMD Strix Halo (128 GB) e o NVIDIA DGX Spark (128 GB) agora também ofereçam memória unificada grande e barata. 6
LLM motores de serving
A escolha do motor de serving se divide por carga de trabalho, e não por uma única melhor ferramenta. Os motores de serving em produção usam atenção paginada e batching contínuo para muitos usuários simultâneos em GPUs de data center, enquanto os runtimes local-first visam um único usuário em um desktop, laptop ou uma única GPU. A diferença aparece sob carga. Em 64 solicitações simultâneas, o vLLM serviu cerca de 44 vezes mais tokens por segundo do que o llama.cpp, cujo tempo até o primeiro token ultrapassou 3 minutos. Para um único usuário, os dois são comparáveis. 7
A calculadora modela oito motores entre os dois campos:
Dentro da camada de produção, o RadixAttention do SGLang reutiliza prefixos entre solicitações, o TensorRT-LLM congela seu orçamento de ativação quando o motor é compilado, e o LMDeploy serve W4A16 e MXFP4 com eficiência de custo para InternLM, Qwen e DeepSeek. 8 No lado local, o ExLlamaV2 com TabbyAPI ajusta uma largura média fracionária de bits para preencher uma placa exatamente, e o MLX usa a memória unificada da Apple, de modo que a RAM total é o orçamento. O TGI da Hugging Face é a única saída. Ele entrou em modo de manutenção em dezembro de 2025 e seu repositório no GitHub foi arquivado (somente leitura) em 21 de março de 2026, com os usuários direcionados para vLLM, SGLang e llama.cpp. 9 10
A maioria das pessoas conhece esses motores por meio de aplicativos de usuário final que os empacotam. Ollama, LM Studio e AnythingLLM rodam sobre llama.cpp (LM Studio também sobre MLX), adicionando modelos com um comando, uma API localhost compatível com OpenAI e, no caso do AnythingLLM, RAG de documentos sobre PDFs e bases de código. Por estrelas no GitHub como um proxy aproximado de adoção em 2026-07-11, o Ollama tem 175.925 e o vLLM 85.979, ambos de código aberto, e o AnythingLLM 63.120. As 5.053 do LM Studio vêm do seu repositório CLI de código aberto (lmstudio-ai/lms) e não do aplicativo de código fechado, portanto subestimam a adoção real em desktops. 11 12 13 14
Um componente interativo de panorama mapeia essas ferramentas para casos de uso. Integrações e ampla compatibilidade vão para o Ollama; desenvolvedores e alto desempenho para o vLLM; aplicações locais de RAG para o AnythingLLM; e experimentação amigável para iniciantes para o LM Studio.
Modelos de linguagem grandes de código aberto
Modelos de pesos abertos publicam sua arquitetura e arquivos de pesos, de modo que qualquer pessoa pode baixá-los, modificá-los e executá-los, geralmente a partir do Hugging Face. A fronteira auto-hospedável de meados de 2026 já ultrapassou em muito a era do Qwen2.5 e do Llama-3:
As colunas total e ativos são a distinção estrutural. Os parâmetros totais determinam a memória e o número de GPUs, e os parâmetros ativos determinam a computação. DeepSeek-V4-Flash e GLM-5.2 chegaram como pesos abertos em 2026, o Gemma 4 relicenciou a família sob Apache 2.0, e o GPT-OSS envia especialistas MoE em MXFP4 nativo. 15 16 17 18 19
Os carros-chefe proprietários (da OpenAI GPT-5.6, da Google Gemini 3.1 Pro, da Anthropic Claude Opus 4.8, da xAI Grok 4.5) não podem ser baixados nem auto-hospedados; eles são somente API, geralmente atrás de um endpoint compatível com OpenAI. Uma implantação somente local abre mão daquilo que esses modelos fazem melhor em uma determinada tarefa. 20 21 22
Quantização e dimensionamento de MoE
A quantização em 2026 tem menos a ver com arredondar pesos após o treinamento e mais com checkpoints que já são distribuídos em bits baixos por design, juntamente com escolhas de arquitetura que reduzem o cache antes de a quantização entrar em cena.
Checkpoints nativos em bits baixos: Os modelos abertos de fronteira cada vez mais já vêm com consciência de quantização. O GPT-OSS envia seus especialistas MoE em MXFP4 (E2M1 com escala compartilhada de 8 bits, 4.25 bits por parâmetro), de modo que o 120B cabe em cerca de 63 GB, uma GPU de 80 GB, enquanto uma estimativa ingênua em BF16 exigiria cerca de 234 GB em três GPUs. O DeepSeek-V3 e o R1 enviam FP8 nativo a cerca de 1 byte por parâmetro. Os pesos devem ser dimensionados pelo dtype real do checkpoint, e não pela contagem de parâmetros. 23 24
A armadilha dos bits efetivos no GGUF: Os arquivos GGUF misturam precisão, com escalas FP16 por bloco e tensores de embedding e saída não quantizados, portanto o nome é um piso, e não o tamanho. O Q4_K_M tem cerca de 4.9 bits efetivos (0.61 bytes por parâmetro), não 4.0. O Q8_0 tem 8.5 bits (1.06 bytes por parâmetro), não 8.0. Uma calculadora baseada no número de bits subdimensiona os pesos em cerca de 20% em Q4 e 6% em Q8. Os IQ-quants, como IQ4_XS (cerca de 4.25 bits), agora igualam a qualidade do Q4_K_M em um tamanho menor. 25
Quantização do cache KV: Reduzir o dtype do KV dimensiona todo o cache linearmente e é independente da precisão dos pesos. O KV em FP8 (e4m3) o reduz pela metade (Llama-3-8B em 128k, batch 1, de 16.0 GiB BF16 para 8.0 GiB FP8) com qualidade amplamente gratuito. O INT4 o reduz a um quarto, mas exige uma avaliação. No vLLM é uma flag (--kv-cache-dtype fp8). 26
Atenção como economia de memória: A Multi-head Latent Attention (MLA, usada pela DeepSeek) armazena um único latente compartilhado de baixa ordem (cerca de 576 elementos por token por camada) em vez de chaves e valores por cabeça, aproximadamente 30 vezes menor do que a leitura nominal de 128 cabeças. É isso que permite a um modelo de 671B servir contexto de 128k com cerca de 8.6 GiB de KV. A atenção de janela deslizante e local-global (Gemma 2 e 3, GPT-OSS, Llama 4) limita a maioria das camadas a uma janela fixa em vez do contexto completo, reduzindo o KV de contexto longo em 10 a 40 vezes em comparação com uma estimativa ingênua toda global. Esses valores são fixos por família de arquitetura, não parâmetros ajustáveis. 27
Offloading e sharding: Quando os pesos excedem a memória da GPU, o offloading move partes inativas, como especialistas MoE não usados, entre a memória da GPU e a RAM do sistema, mais lenta, trocando tokens por segundo pela capacidade de executar. 28 O sharding divide um modelo em vários dispositivos ou camadas de memória, que é como um modelo de 671B se estende por um nó de 8 GPUs. Ambos estendem o alcance do hardware fixo com um custo de largura de banda.
Benefícios e compensações da auto-hospedagem
O argumento a favor da auto-hospedagem é o controle de dados, o custo em volume e a liberdade de configuração. O argumento contra é o custo de hardware, a carga operacional e a lacuna dos modelos proprietários.
Residência de dados e conformidade: A transferência transfronteiriça de dados é o vetor de conformidade. Sob o GDPR, enviar dados pessoais para fora da UE pode acionar salvaguardas legais, obrigações contratuais ou restrições. O EU IA Act adiciona uma segunda camada, mas está sendo implementado gradualmente, em vez de estar totalmente em vigor. Em meados de 2026, as proibições (aplicáveis desde 2 de fevereiro de 2025) e as obrigações para modelos de IA de uso geral (GPAI) (desde 2 de agosto de 2025) já se aplicam, enquanto os requisitos de alto risco em torno de gerenciamento de riscos, auditabilidade e governança estão adiados para 2 de dezembro de 2027 para sistemas autônomos de alto risco do Anexo III e para 2 de agosto de 2028 para sistemas embarcados do Anexo I, no âmbito do pacote Digital Omnibus 2025-26. 29 30 31 Executar a inferência na jurisdição, em uma rede controlada, mantém os dados sensíveis fora das mãos de terceiros, o que é o caso da IA soberana para finanças, saúde e setor público.
Custo e controle: A auto-hospedagem começa cara, com GPUs de consumidor ou um servidor pequeno, mas a inferência local pode reduzir as taxas de API recorrentes para equipes que geram altos volumes de solicitações. Ela também elimina a dependência de fornecedor e os limites impostos à janela de contexto, às configurações de inferência e à integração, e dá acesso direto aos pesos para fine-tuning em dados privados.
As compensações: A memória da GPU é o limite determinante, e algumas cargas de trabalho ainda exigem de 16 a 48 GB de VRAM, fora do alcance de equipes menores. A implantação adiciona gerenciamento de dependências, solução de problemas de CUDA e kernels, monitoramento e atualizações que um provedor de nuvem normalmente cuidaria. O desempenho é responsabilidade do operador, desde batching e sharding até a utilização do hardware. E os modelos proprietários mais fortes permanecem somente via API, portanto uma implantação local aceita uma lacuna de capacidade nas tarefas em que eles lideram.
Adicionar como fonte preferencialMetodologia de cálculo de VRAM para LLM auto-hospedado
A pegada de memória de um modelo é a soma de quatro termos que são calculados independentemente e somados, não um valor único dimensionado a partir da contagem de parâmetros:
VRAM_total = Weights + KV cache + Activations + Overhead
O erro de estimativa mais comum colapsa os três últimos termos em um acréscimo fixo de 20% sobre os pesos. Isso é próximo em um tamanho de modelo e errado nos outros, porque os três termos escalam de maneira diferente. 32
Pesos: A memória dos pesos é parâmetros vezes bytes por parâmetro. BF16 e FP16 armazenam 2.0 bytes por parâmetro, e FP8 e INT8 armazenam cerca de 1.0. A armadilha é o 4 bits, que não é 0.5 bytes por parâmetro. O INT4 agrupado real (GPTQ, AWQ) fica entre 0.52 e 0.55, e o GGUF Q4_K_M tem cerca de 0.61 bytes por parâmetro (4.9 bits efetivos, não 4.0). O GGUF Q8_0 tem 8.5 bits (1.06 bytes por parâmetro), não 8.0. Assumir 0.5 subestima um modelo de 70B em cerca de 8 GB, o que inverte um veredito de compatibilidade. 25
MoE dimensiona todos os especialistas, não apenas os ativos: Todos os pesos dos especialistas permanecem residentes na VRAM, mesmo que apenas alguns disparem por token. O Mixtral-8x7B precisa de cerca de 28 GB em Q4 para os 46.7B parâmetros totais, não os 13B ativos. Os parâmetros totais definem a memória e o número de GPUs, e os parâmetros ativos definem a computação. Uma calculadora que dimensiona pelos parâmetros ativos encaixa falsamente modelos MoE grandes.
Cache KV: O cache de chave-valor é 2 x n_layers x n_kv_heads x head_dim x seq_len x batch x bytes_per_element. A maioria dos modelos atuais usa atenção de consulta agrupada (GQA), em que muitas cabeças de consulta compartilham algumas cabeças KV, portanto pares n_kv_heads são armazenados, o que reduz o cache em 4 vezes (Llama-3-8B) a 8 vezes (Llama-3-70B) em comparação com a atenção multi-head completa. Tanto head_dim quanto n_kv_heads são lidos do config.json de cada modelo, em vez de derivados do tamanho oculto e do número de cabeças, já que famílias como Gemma (head_dim 256) e Qwen3 (128) seriam dimensionadas incorretamente em cerca de 2 vezes. O cache cresce linearmente com o comprimento do contexto e o tamanho do batch e, em contexto longo, rivaliza ou excede os pesos. O Llama-3-8B armazena 128 KiB por token, portanto, em contexto de 128k e batch 1, um cache KV FP16 tem 16.0 GiB, igual aos 16 GB de pesos BF16. Um cache KV FP8 reduz isso pela metade. 33
A sobrecarga é um piso, não uma porcentagem: A sobrecarga do framework é um piso fixo por GPU (contexto CUDA e kernels, cerca de 1 a 2 GB por GPU) mais uma pequena fração limitada, não uma parcela dos pesos. Um valor fixo de 20% subestima modelos pequenos, em que só o contexto CUDA pode exceder 20% de um modelo de 6 GB, e superestima os grandes, em que um modelo de 140 GB não precisa de 28 GB de contexto. O piso por partes é o modelo preciso, e os 20% fixos funcionam como estimativa rápida. 34
Ativações e o motor de serving: O termo de ativação é transitório. Durante a decodificação, um token por vez, ele é pequeno e se incorpora ao piso de sobrecarga, mas o prefill processa todo o prompt de uma vez, portanto seu pico de ativação escala com o tamanho do batch e o comprimento do prompt. O piso em si depende do motor. Servidores paginados (vLLM, SGLang) reservam uma parcela fixa de cada placa por meio de uma configuração de utilização de memória, cerca de 10% no padrão 0.90, e encaixam os pesos e o KV no restante. Runtimes não paginados (llama.cpp, Ollama) mantêm um buffer de computação fixo de cerca de 1 a 2 GB. Dimensionar ambos da mesma forma erra por alguns GB.
Múltiplas GPUs não se dividem de forma exata: Duas placas de 24 GB não são 48 GB de espaço utilizável. Sob paralelismo de tensores, os pesos e o cache KV se dividem entre as N placas (W/N e KV/N), mas as ativações, o contexto CUDA e os buffers de comunicação NCCL são replicados em todas as placas, portanto a pegada somada é maior do que uma estimativa de dispositivo único com o mesmo total. Esse custo de replicação é o motivo pelo qual um 70B que exige 43 GB de pesos cabe em duas placas de 24 GB com contexto curto, e por que a verificação segura é o total por GPU, e não o total dividido pela contagem de GPUs.
Os quatro termos interagem na fronteira de compatibilidade. Uma configuração aparece como Cabe quando a memória necessária está em ou abaixo de 90% da utilizável, Apertada nos 10% superiores da capacidade e Não cabe acima da utilizável. Os servidores paginados já retêm esses 10% por meio da configuração de utilização. Os exemplos abaixo usam o Llama-3 em hardware comum, com llama.cpp nas placas de consumidor:
Em contexto de 128k, o cache KV é igual aos pesos, portanto o comprimento do contexto, e não a contagem de parâmetros, decide a compatibilidade. A última linha cabe porque os pesos Q4 (~405 GB) ficam abaixo de 640 GB em contexto de 8k. O ganho da MLA está em contexto longo, onde ela mantém o KV de um modelo de 671B pequeno o suficiente para servir 128k.
Leitura adicional
- LLM Quantização: BF16 vs FP8 vs INT4
- LLM Motores de Inferência: vLLM vs LMDeploy vs SGLang
- GPU Benchmark de Concorrência: H100 vs H200 vs B200 vs MI300X
- Benchmark Multi-GPU: B200 vs H200 vs H100 vs MI300X
- Top 60+ Provedores de GPU na Nuvem
- Nuvem LLM vs LLMs locais
- LLM Preços: Top 15+ Provedores Comparados
- LLM Guia de Fine-Tuning para Empresas
Perguntas frequentes
Um LLM auto-hospedado é um modelo de linguagem grande usado para aplicações de LLM que executa inteiramente em hardware que você controla (como seu computador pessoal ou servidor privado), em vez de depender de um serviço de nuvem de terceiros.
As técnicas incluem o uso de frameworks como llama.cpp, bibliotecas como os transformers da Hugging Face, aplicativos amigáveis (Ollama, LM Studio), quantização de modelos (por exemplo, GGUF, GPTQ) para reduzir as necessidades de recursos, paralelismo de modelos para distribuir modelos grandes entre vários dispositivos e motores de inferência otimizados (como vLLM).
Sim, ferramentas como vLLM, Ollama e LM Studio podem executar servidores locais capazes de lidar com várias solicitações (muitas vezes simultâneas). Isso é semelhante a como as APIs de nuvem operam, muitas vezes usando batching para eficiência.
Não, você não precisa de permissão de acesso externo nem de chaves de API de um provedor para um LLM auto-hospedado. Como você mesmo o hospeda, tem acesso direto; você pode, opcionalmente, configurar sua própria autenticação para o servidor local, se necessário.
Cite esta pesquisa
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{LLM Calculadora de VRAM para Auto-Hospedagem}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/self-hosted-llm}},
note = {AIMultiple. Acessado em 31 Agosto 2026}
}Registro de alterações
2 atualizações- 2026
Adicionada uma seção, Privacidade e conformidade, a Vantagens de LLMs auto-hospedados.
- 2025
Adicionada uma lista das 4 principais ferramentas auto-hospedadas à introdução.
Links de referência
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.