LLM Calculadora de VRAM para Auto-hospedagem
Auto-hospedar um LLM significa executar a inferência em hardware controlado pelo operador, em vez de via uma API de terceiros, o que altera o custo, o controlo dos dados e o perfil de privacidade. O facto de um modelo conseguir sequer correr depende da memória.
Calculadora de Compatibilidade de LLM
A calculadora estima a VRAM ou a memória unificada de que um modelo necessita para correr localmente, com base no modelo, na sua precisão, no comprimento do contexto e no hardware alvo. Devolve se uma configuração cabe, a divisão da memória entre pesos, cache KV e overhead, 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 dos Transformers da Hugging Face. 1
Consulte a nossa metodologia de cálculo de VRAM para LLM auto-hospedado para ver toda a matemática por detrás destas estimativas.
Hardware para auto-hospedagem: GPUs e Apple Silicon
Dois números decidem o hardware. A capacidade é o portão de ajuste e a descodificação é limitada pela largura de banda da memória, pelo que os tokens por segundo escalam aproximadamente com os GB/s da placa.
As linhas acima representam uma amostra de cada nível. No total, a calculadora inclui 34 placas, adicionando a A100, L40S, RTX A6000, AMD Radeon RX 7900 XTX e a linha AMD Instinct. Com 24 a 32 GB, um modelo 70B exige quantização pesada e contexto curto, ou duas placas. Um modelo 671B precisa de 640 GB (8×80 GB) como mínimo padrão. A RTX PRO 6000 é a melhor placa individual de classe workstation, e o seu preço de rua subiu para cerca de 13 000 dólares em meados de 2026, a partir de um PVP de 8 565 dólares.2
Apple Silicon e memória unificada: No Apple Silicon, a CPU e a GPU partilham um único conjunto de memória, e a GPU endereça cerca de 75% do total de RAM por defeito através do recommendedMaxWorkingSetSize do Metal, um pouco menos em Macs mais pequenos. O limite pode ser aumentado com sudo sysctl iogpu.wired_limit_mb=, deixando 8 a 16 GB para o macOS. 3 4 Um Mac com 128 GB expõe cerca de 96 GB para a GPU. O M3 Ultra, com até 512 GB, expõe cerca de 384 GB, suficiente para um modelo da classe 400B a 4 bits com margem para KV num ú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 NVIDIA DGX Spark (128 GB) ofereçam agora também memória unificada grande e barata. 6
Motores de inferência de LLM
A escolha do motor de inferência divide-se por carga de trabalho, em vez de haver uma única ferramenta melhor. Os motores de produção usam atenção paginada e agrupamento contínuo para muitos utilizadores simultâneos em GPUs de centro de dados, enquanto os runtimes locais visam um único utilizador num desktop, portátil ou uma única GPU. A diferença surge sob carga. Com 64 pedidos concorrentes, o vLLM serviu cerca de 44 vezes mais tokens por segundo do que o llama.cpp, cujo tempo até ao primeiro token ultrapassou os 3 minutos. Para um único utilizador, os dois são comparáveis. 7
A calculadora modela oito motores nos dois campos:
Dentro do nível de produção, o RadixAttention do SGLang reutiliza prefixos entre pedidos, o TensorRT-LLM congela o seu orçamento de ativação quando o motor é construído, e o LMDeploy serve W4A16 e MXFP4 de forma económica para InternLM, Qwen e DeepSeek. 8 No lado local, o ExLlamaV2 com TabbyAPI ajusta uma largura de bits média fracionária para encher exatamente uma placa, e o MLX usa memória unificada da Apple, pelo que a RAM total é o orçamento. O Hugging Face TGI é a única saída. Passou para modo de manutenção em dezembro de 2025 e o seu repositório no GitHub foi arquivado (apenas leitura) em 21 de março de 2026, com os utilizadores encaminhados para vLLM, SGLang e llama.cpp. 9 10
A maioria das pessoas encontra estes motores através de aplicações de utilizador final que os envolvem. O Ollama, LM Studio e AnythingLLM funcionam todos sobre o llama.cpp (o LM Studio também sobre MLX), adicionando modelos de um comando, uma API localhost compatível com OpenAI e, no caso do AnythingLLM, RAG de documentos sobre PDFs e bases de código. Pelas estrelas no GitHub como proxy aproximado de adoção em 11-07-2026, o Ollama tem 175 925 e o vLLM 85 979, ambos open source, e o AnythingLLM 63 120. As 5 053 do LM Studio provêm do seu repositório CLI open source (lmstudio-ai/lms) em vez da aplicação de código fechado, pelo que subestima a adoção real no desktop. 11 12 13 14
Um componente interativo de paisagem mapeia estas ferramentas para casos de uso. As integrações e a compatibilidade alargada vão para o Ollama, o alto desempenho e os programadores para o vLLM, as aplicações locais de RAG para o AnythingLLM, e a experimentação amigável para principiantes para o LM Studio.
Modelos de linguagem grandes open source
Os modelos de pesos abertos publicam a sua arquitetura e os ficheiros de pesos, pelo que qualquer pessoa pode descarregá-los, modificá-los e executá-los, normalmente a partir do Hugging Face. A fronteira dos modelos auto-hospedáveis em meados de 2026 já ultrapassou largamente a era do Qwen2.5 e do Llama-3:
As colunas do total e dos ativos são a distinção fundamental. Os parâmetros totais determinam a memória e o número de GPUs, e os parâmetros ativos determinam a computação. O DeepSeek-V4-Flash e o GLM-5.2 chegaram como pesos abertos em 2026, a família Gemma 4 foi relicenciada sob Apache 2.0, e o GPT-OSS distribui especialistas MoE em MXFP4 nativo. 15 16 17 18 19
Os modelos emblemáticos proprietários (OpenAI’s GPT-5.6, Google’s Gemini 3.1 Pro, Anthropic’s Claude Opus 4.8, xAI’s Grok 4.5) não podem ser descarregados nem auto-hospedados; são apenas por API, normalmente atrás de um endpoint compatível com OpenAI. Uma implementação apenas local abdica daquilo que esses modelos fazem melhor numa determinada tarefa. 20 21 22
Quantização e dimensionamento de MoE
A quantização em 2026 é menos sobre arredondar pesos após o treino e mais sobre checkpoints que já nascem com baixo número de bits, aliada a escolhas de arquitetura que cortam a cache antes de a quantização sequer entrar.
Checkpoints nativos de baixo número de bits: Cada vez mais, os modelos abertos de fronteira são distribuídos com quantização consciente. O GPT-OSS distribui os seus especialistas MoE em MXFP4 (E2M1 com uma escala partilhada de 8 bits, 4,25 bits por parâmetro), pelo que o 120B cabe em cerca de 63 GB, uma GPU de 80 GB, onde uma estimativa ingénua em BF16 exigiria cerca de 234 GB em três GPUs. O DeepSeek-V3 e o R1 são distribuídos nativamente em FP8 a cerca de 1 byte por parâmetro. Os pesos devem ser dimensionados com base no dtype real do checkpoint, e não na contagem de parâmetros. 23 24
A armadilha dos bits efetivos do GGUF: Os ficheiros GGUF misturam precisão, com escalas FP16 por bloco e tensores de embedding e saída não quantizados, pelo que o nome é um piso e não o tamanho efetivo. 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 apenas no número de bits subdimensiona os pesos em cerca de 20% no Q4 e 6% no Q8. As variantes IQ, como o IQ4_XS (cerca de 4,25 bits), já igualam a qualidade do Q4_K_M com um tamanho menor. 25
Quantização da cache KV: Reduzir o dtype da KV escala linearmente toda a cache e é independente da precisão dos pesos. FP8 (e4m3) reduz a KV para metade (Llama-3-8B com 128k, batch 1, de 16,0 GiB BF16 para 8,0 GiB FP8) com qualidade praticamente gratuita. INT4 reduz para um quarto, mas precisa de avaliação. No vLLM é uma flag (--kv-cache-dtype fp8). 26
Attention como poupança de memória: A Multi-head Latent Attention (MLA, usada pela DeepSeek) guarda em cache um único latente partilhado de baixo rank (cerca de 576 elementos por token por camada) em vez de chaves e valores por cabeça, aproximadamente 30 vezes mais pequeno do que a leitura nominal de 128 cabeças. É isso que permite que um modelo de 671B sirva 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 de contexto total, reduzindo a KV de contexto longo entre 10 a 40 vezes face a uma estimativa ingénua toda global. Estas são fixas por família de arquitetura, não sã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 utilizados, entre a memória da GPU e a RAM do sistema, mais lenta, trocando tokens por segundo pela capacidade de correr de todo. 28 O sharding divide um modelo por vários dispositivos ou níveis de memória, que é como um modelo de 671B se estende por um nó de 8 GPUs. Ambos alargam o alcance de hardware fixo com um custo de largura de banda.
Benefícios e compromissos da auto-hospedagem
O argumento a favor da auto-hospedagem é o controlo dos dados, o custo em volume e a liberdade de configuração. O argumento contra é o custo do hardware, o fardo operacional e a diferença para os modelos proprietários.
Residência dos dados e conformidade: A transferência transfronteiriça de dados é o motor da conformidade. Ao abrigo do RGPD, o envio de dados pessoais para fora da UE pode desencadear salvaguardas legais, obrigações contratuais ou restrições. O Regulamento da IA da UE acrescenta uma segunda camada, mas está a ser implementado de forma faseada e não totalmente em vigor. Em meados de 2026, as proibições (aplicáveis desde 2 de fevereiro de 2025) e as obrigações dos modelos de IA de finalidade geral (GPAI) (desde 2 de agosto de 2025) já se aplicam, enquanto os requisitos de alto risco em matéria de gestão de riscos, auditabilidade e governação estão diferidos, para 2 de dezembro de 2027 para os sistemas autónomos de alto risco do Anexo III e 2 de agosto de 2028 para os sistemas incorporados do Anexo I, ao abrigo do Pacote Digital Omnibus de 2025-26. 29 30 31 Executar a inferência na jurisdição, numa rede controlada, mantém os dados sensíveis fora das mãos de terceiros, que é o argumento da IA soberana para as finanças, a saúde e o setor público.
Custo e controlo: A auto-hospedagem começa cara, com GPUs de consumo ou um pequeno servidor, mas a inferência local pode reduzir as taxas recorrentes de API para equipas que geram elevados volumes de pedidos. Também elimina a dependência de fornecedor e os limites impostos à janela de contexto, às definições de inferência e à integração, e dá acesso direto aos pesos para afinação com dados privados.
Os compromissos: A memória da GPU é o limite vinculativo, e algumas cargas de trabalho ainda precisam de 16 a 48 GB de VRAM, fora do alcance de equipas mais pequenas. A implementação acrescenta gestão de dependências, resolução de problemas de CUDA e kernels, monitorização e atualizações que um fornecedor de cloud normalmente trataria. O desempenho é da responsabilidade do operador, desde o agrupamento e sharding até à utilização do hardware. E os modelos proprietários mais fortes mantêm-se apenas por API, pelo que uma implementação local aceita uma diferença de capacidades nas tarefas em que lideram.
Metodologia 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 de forma independente e somados, não um valor único escalado a partir da contagem de parâmetros:
VRAM_total = Weights + KV cache + Activations + Overhead
O erro de estimativa mais comum reduz os três últimos termos a uma margem fixa de 20% sobre os pesos. Isso é próximo para um tamanho de modelo e errado para os outros, porque os três termos escalam de forma 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 está nos 4 bits, que não são 0,5 bytes por parâmetro. O INT4 agrupado real (GPTQ, AWQ) fica em 0,52 a 0,55, e o GGUF Q4_K_M é 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 cabimento. 33
A mistura de especialistas dimensiona todos os especialistas, não os ativos: Todos os pesos dos especialistas permanecem residentes em VRAM, mesmo que apenas alguns sejam ativados por token. O Mixtral-8x7B precisa de cerca de 28 GB em Q4 para o total de 46,7B parâmetros, 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 dimensione pelos parâmetros ativos faria caber falsamente grandes modelos MoE.
Cache KV: A cache 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), onde muitas cabeças de consulta partilham algumas cabeças KV, pelo que são armazenados em cache pares n_kv_heads, o que reduz a cache 4 vezes (Llama-3-8B) a 8 vezes (Llama-3-70B) face à atenção multi-cabeça completa. Tanto head_dim como n_kv_heads são lidos do config.json de cada modelo, em vez de derivados do tamanho oculto e da contagem de cabeças, uma vez que famílias como Gemma (head_dim 256) e Qwen3 (128) seriam mal dimensionadas por um fator de cerca de 2. A cache cresce linearmente tanto com o comprimento do contexto como com o tamanho do batch, e em contexto longo rivaliza ou excede os pesos. O Llama-3-8B armazena em cache 128 KiB por token, pelo que a 128k de contexto e batch 1 uma cache KV FP16 é de 16,0 GiB, igual aos 16 GB de pesos em BF16. Uma cache KV em FP8 reduz isso para metade. 34
O overhead é um piso, não uma percentagem: O overhead da 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 parte dos pesos. Um valor fixo de 20% subestima os modelos pequenos, onde só o contexto CUDA pode exceder 20% de um modelo de 6 GB, e sobrestima os grandes, onde 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. 35
Ativações e o motor de inferência: O termo de ativação é transitório. Durante a descodificação, um token de cada vez, é pequeno e dilui-se no piso de overhead, mas o prefill processa todo o prompt de uma vez, pelo que o seu pico de ativação escala com o tamanho do batch e o comprimento do prompt. O próprio piso depende do motor. Os servidores paginados (vLLM, SGLang) reservam uma parte fixa de cada placa através de uma definição de utilização de memória, cerca de 10% no valor padrão de 0,90, e encaixam os pesos e a KV no restante. Os 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 resulta num desvio de alguns GB.
Múltiplas GPUs não dividem de forma limpa: Duas placas de 24 GB não são 48 GB de espaço utilizável. Com paralelismo de tensores, os pesos e a cache KV dividem-se pelas 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 cada placa, pelo que a pegada somada é maior do que uma estimativa de dispositivo único com o mesmo total. Esse custo de replicação é a razão pela qual um 70B que precisa de 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 cabimento. Uma configuração é classificada como "Cabe" quando a memória necessária é igual ou inferior a 90% da utilizável, "Apertada" nos 10% superiores da capacidade, e "Não cabe" acima da utilizável. Os servidores paginados já reservam esses 10% através da definição de utilização. Os exemplos abaixo usam Llama-3 em hardware comum, com llama.cpp nas placas de consumo:
A 128k de contexto, a cache KV iguala os pesos, pelo que o comprimento do contexto, e não a contagem de parâmetros, decide o cabimento. A última linha cabe porque os pesos Q4 (~405 GB) ficam abaixo de 640 GB a 8k de contexto. O benefício da MLA está no contexto longo, onde mantém a KV de um modelo de 671B suficientemente pequena para servir 128k.
Adicionar como fonte preferencialLeitura adicional
- Quantização de LLM: BF16 vs FP8 vs INT4
- Motores de Inferência de LLM: vLLM vs LMDeploy vs SGLang
- Benchmark de Concorrência de GPU: H100 vs H200 vs B200 vs MI300X
- Benchmark Multi-GPU: B200 vs H200 vs H100 vs MI300X
- Top 60+ Fornecedores de GPU na Cloud
- Cloud LLM vs LLMs Locais
- Preços de LLM: Top 15+ Fornecedores Comparados
- Guia de Fine-Tuning de LLM para Empresas
Perguntas frequentes
Um LLM auto-hospedado é um modelo de linguagem grande utilizado em aplicações de LLM que é executado inteiramente em hardware que controla (como o seu computador pessoal ou servidor privado), em vez de depender de um serviço de cloud de terceiros.
As técnicas incluem a utilização de frameworks como llama.cpp, bibliotecas como os transformers da Hugging Face, aplicações amigáveis (Ollama, LM Studio), quantização de modelos (ex: GGUF, GPTQ) para reduzir as necessidades de recursos, paralelismo de modelos para distribuir grandes modelos por 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 múltiplos pedidos (frequentemente concorrentes). Isto é semelhante ao funcionamento das APIs na cloud, recorrendo frequentemente ao agrupamento para eficiência.
Não, não precisa de permissão de acesso externo nem de chaves de API de um fornecedor para um LLM auto-hospedado. Uma vez que o aloja você mesmo, tem acesso direto; pode, opcionalmente, configurar a sua própria autenticação para o seu servidor local, se necessário.
Ligações Externas
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 = jul,
howpublished = {\url{https://aimultiple.com/self-hosted-llm}},
note = {AIMultiple. Acessado em 12 Julho 2026}
}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.