Guia de VRAM para modelos 32B e 70B: opções com GPU única e múltiplas GPUs
A resposta prática para requisitos de VRAM do modelo 70b é: um modelo 70B pode ser carregado em cerca de 35GB a 45GB com quantização comum de 4 bits, em torno de 70GB a 90GB com quantização de 8 bits e overhead de runtime, e mais de 140GB antes do overhead em FP16 ou BF16. Um modelo 32B é mais fácil, mas ainda exige planejamento: cerca de 18GB a 24GB para inferência em 4 bits, 32GB a 45GB para inferência em 8 bits e mais de 64GB antes do overhead em FP16 ou BF16.
Esses números são apenas o mínimo. Os reais requisitos de VRAM do modelo 70b dependem do comprimento do contexto, tamanho do batch, KV cache, mecanismo de serving, paralelismo de tensor, adaptadores LoRA, estado do otimizador e de quanta margem de segurança você precisa antes de o tráfego de produção começar a falhar com erros de falta de memória.
Este guia é para engenheiros de IA, equipes de plataforma e compradores técnicos que estão decidindo se uma carga de trabalho 32B ou 70B cabe em uma única GPU, precisa de várias GPUs ou deve ser servida por meio de uma API de modelo em vez de capacidade de GPU alugada.
Verificado em 13 de outubro de 2026.
requisitos de VRAM do modelo 70b: a resposta rápida
Use isto como o primeiro dimensionamento e, depois, faça benchmark do seu modelo exato, janela de contexto e stack de serving.
| Workload | Ponto de partida para 32B | Ponto de partida para 70B | Observação prática |
|---|---|---|---|
| Inferência local em 4 bits | 24GB pode funcionar, 48GB é mais confortável | 48GB pode carregar alguns modelos quantizados, 80GB é mais seguro | Bom para desenvolvimento, demos, ferramentas internas e serving com baixa concorrência. |
| Inferência em 8 bits | 48GB ou 80GB | 80GB mínimo, 96GB ou 141GB mais seguro | Overhead de runtime e KV cache muitas vezes determinam se o endpoint é estável. |
| Inferência FP16/BF16 | 80GB | 2x80GB, 141GB, 180GB ou sistemas multi-GPU maiores | A memória dos pesos sozinha é de cerca de 2 bytes por parâmetro. |
| Serving local para usuário único no estilo Ollama | 24GB a 48GB | 48GB a 80GB | A questão dos requisitos de VRAM do modelo ollama 70b é principalmente sobre tamanho do modelo quantizado mais contexto. |
| Serving de produção com vLLM ou SGLang | 48GB a 80GB | 80GB, 96GB, 141GB ou multi-GPU | Deixe margem para KV cache, batching e recuperação de requisições com falha. |
| Fine-tuning com QLoRA | 48GB para execuções restritas, 80GB mais seguro | 48GB é um piso para pesquisa; 80GB ou multi-GPU é mais seguro | Os requisitos de VRAM do modelo qlora 70b dependem fortemente do comprimento da sequência e da estratégia de batch. |
Atalho para o comprador:
- Escolha 24GB apenas para experimentos quantizados de 32B ou fluxos de trabalho 70B com divisão CPU/GPU muito restrita.
- Escolha 48GB para conforto com 32B, inferência local 70B em 4 bits ou experimentos de QLoRA ajustados com precisão.
- Escolha 80GB para inferência séria em 70B, janelas de contexto maiores ou QLoRA mais confiável.
- Escolha 96GB, 141GB, 180GB ou multi-GPU quando precisar de margem de produção, contextos mais longos, maior concorrência ou FP16/BF16.
Se o produto só precisa de saídas do modelo e não de controle direto do hardware, compare uma rota de modelo/API antes de assinar um contrato de GPU. A Flatkey oferece às equipes uma chave, um saldo, uma fatura e um ledger de uso em centenas de modelos e ferramentas oficiais, o que pode ser uma base mais limpa quando a utilização é incerta.
Por que os pesos do modelo não são o requisito total de VRAM
A estimativa mais simples de memória é:
model_weight_memory = parameter_count x bytes_per_parameter
Isso fornece um piso útil:
| Tamanho do modelo | Piso FP16/BF16 | Piso em 8 bits | Piso em 4 bits |
|---|---|---|---|
| 32B | cerca de 64GB | cerca de 32GB | cerca de 16GB |
| 70B | cerca de 140GB | cerca de 70GB | cerca de 35GB |
Mas um LLM em execução precisa de mais do que pesos:
| Componente de memória | Por que importa |
|---|---|
| Metadados de quantização | Formatos de 4 bits e 8 bits precisam de escalas, metadados de grupo e buffers do framework. |
| KV cache | Janelas de contexto maiores e mais requisições concorrentes consomem memória adicional. |
| Buffers de runtime | vLLM, SGLang, TensorRT-LLM, llama.cpp e Ollama reservam memória de maneiras diferentes. |
| CUDA graphs e kernels | Mecanismos de serving podem reservar workspace para velocidade e estabilidade. |
| Adaptadores LoRA | Adaptadores ajustados adicionam menos memória do que pesos completos, mas ainda precisam de orçamento. |
| Margem de segurança | Endpoints de produção precisam de espaço para variação de prompt, retries e desvio de implantação. |
É por isso que requisitos de VRAM do modelo 70b quantizado não é o mesmo que "o arquivo de 4 bits tem 35GB." Um modelo 70B quantizado de 35GB a 45GB pode carregar em uma GPU de 48GB, mas um contexto mais longo, um batch maior ou um runtime mais pesado ainda podem falhar.
Opções com GPU única para modelos 32B e 70B
GPUs de 24GB
Placas de 24GB são úteis para modelos 32B em formato de 4 bits, testes menores de 70B com descarregamento parcial para CPU e experimentos de desenvolvedor em que a latência não é o objetivo principal.
Não trate 24GB como uma resposta confortável para requisitos de VRAM do modelo 70b. Pode ser útil com quantização agressiva, contexto reduzido, descarregamento para CPU ou testes locais no estilo llama.cpp, mas normalmente não é um tier de serving 70B de produção.
Melhor opção:
- Inferência 32B em 4 bits.
- Janelas de contexto pequenas.
- Testes locais de usuário único.
- Avaliação de protótipos antes de alugar GPUs maiores.
Cuidados:
- 70B muitas vezes exige offload para CPU ou configurações muito ajustadas.
- Prompts longos podem esgotar rapidamente o cache KV.
- A vazão será limitada.
GPUs de 48GB
48GB é o primeiro nível sério de GPU única para trabalho quantizado com 70B. Ele pode executar muitas cargas de trabalho de inferência 70B em 4 bits se o contexto e a concorrência forem controlados. Também é um piso prático para muitos experimentos de QLoRA, consistente com o resultado original do QLoRA, que mostrou fine-tuning de modelos grandes na classe 65B em uma única GPU de 48GB.
Melhor opção:
- Inferência local 70B em 4 bits.
- Inferência 32B em 8 bits.
- Fine-tuning 32B com espaço para adaptadores e contexto mais longo.
- Experimentos apertados de requisitos de VRAM do modelo 70B para fine-tuning QLoRA.
Cuidados:
- 70B em 8 bits normalmente não tem margem suficiente.
- Atendimento com contexto longo pode levar um modelo 70B em 4 bits ao limite.
- O tamanho do batch é limitado.
GPUs de 80GB
80GB é a resposta prática mais comum para trabalho sério com 70B. GPUs A100 80GB e H100 da classe 80GB podem lidar com muitas cargas de inferência 70B quantizadas com melhor margem de contexto do que 48GB, e são um ponto de partida muito mais confortável para QLoRA.
Melhor opção:
- Inferência 70B em 4 bits com testes de contexto semelhantes aos de produção.
- Inferência 70B em 8 bits, se o runtime e o contexto couberem.
- Inferência 32B em FP16/BF16 com overhead.
- QLoRA em 70B com configurações restritas, porém realistas.
Cuidados:
- 70B em FP16/BF16 normalmente precisa de mais de uma GPU de 80GB.
- Alta concorrência ainda exige planejamento cuidadoso do KV-cache.
- O formato do nó e o preço específicos do provedor podem importar tanto quanto a VRAM.
GPUs de 96GB, 141GB e 180GB
Os aceleradores mais novos e com maior memória mudam a questão da GPU única. Uma placa de 96GB oferece mais espaço para 70B em 8 bits ou contextos quantizados maiores. A memória de 141GB da classe H200 pode fazer com que muitas cargas de trabalho 70B caibam com muito mais margem. Configurações da classe B200 com 180GB ampliam ainda mais o teto de GPU única ou nó único, especialmente quando a pilha de serving consegue usar caminhos mais novos de baixa precisão.
Melhor opção:
- Inferência 70B com contexto longo.
- Tamanhos de batch e concorrência maiores.
- Serving em 8 bits ou com precisão mista.
- Redução da complexidade de sharding para modelos grandes.
Cuidados:
- Disponibilidade e preço de aluguel podem pesar mais do que o encaixe teórico.
- A maturidade do software difere entre gerações de GPU.
- Você ainda precisa de um benchmark de custo por saída aceita.
Para comparações adjacentes de hardware, veja B200 vs H200, H200 vs H100 e melhor GPU para inferência de LLM.
Opções multi-GPU para modelos 70B
Serving em várias GPUs não é apenas "mais VRAM". Ele também adiciona overhead de comunicação, preocupações com topologia, risco de posicionamento e complexidade de software.
Use múltiplas GPUs quando:
- O modelo não cabe em uma GPU na precisão de que você precisa.
- Contexto longo ou alta concorrência exigem mais espaço de KV-cache.
- Você precisa de serving 70B em FP16/BF16.
- Você precisa de vazão que uma GPU não consegue entregar.
- Você consegue validar o paralelismo tensorial e o desempenho da interconexão.
| Opção | Quando faz sentido | O que verificar |
|---|---|---|
| 2x48GB | Serving 70B quantizado com mais margem do que uma única placa de 48GB | Interconexão, suporte a tensor parallel, comportamento em caso de falha. |
| 2x80GB | Experimentos 70B em FP16/BF16 ou serving quantizado com alta margem | Se o sharding supera uma GPU maior em latência e custo. |
| 4x80GB | Serving 70B mais pesado, contextos maiores, múltiplas réplicas ou fine-tuning | NVLink/NVSwitch, política de batch, utilização, estratégia de checkpoint. |
| 8x80GB ou mais | Cluster de produção compartilhado, múltiplos endpoints ou modelos maiores que 70B | Agendador, armazenamento, observabilidade e alocação de custos. |
Para implantações multi-nó, o design do cluster é importante. Use o guia de arquitetura de cluster de GPU para revisar os requisitos de computação, rede, armazenamento e plano de controle antes de comprar capacidade.
Requisitos de VRAM do modelo Ollama 70B
A resposta para requisitos de VRAM do modelo 70B do Ollama depende da tag do modelo e da quantização. As páginas de modelos do Ollama normalmente listam artefatos 70B quantizados na casa das dezenas de gigabytes, não 140GB, porque o caminho padrão de serving local geralmente é quantizado, e não FP16.
Uma regra prática:
- 48GB pode ser suficiente para carregar e testar alguns modelos 70B quantizados.
- 64GB a 80GB oferecem mais espaço para contexto e menos surpresas de OOM.
- 24GB geralmente significa modelos menores, contextos mais curtos, offload pesado ou experimentos lentos.
- Se você precisa de latência de produção ou de múltiplos usuários, dimensione para margem de serving, e não apenas para o tamanho do modelo baixado.
Para testes locais, registre a tag exata do modelo, a quantização, o comprimento de contexto, as camadas na GPU e o uso de memória observado. Não escreva "70B funciona na minha GPU" sem esses detalhes. A mesma família 70B pode ter várias variantes quantizadas com comportamento de memória diferente.
Requisitos de VRAM do modelo 70B para fine-tuning QLoRA
A pergunta sobre requisitos de VRAM do modelo 70B para fine-tuning QLoRA tem duas respostas:
- O piso de pesquisa pode ser surpreendentemente baixo porque o QLoRA congela o modelo base, o quantiza e treina pequenos adaptadores de baixa classificação.
- A zona de conforto para produção é mais alta porque o comprimento de sequência, o tamanho do batch, o gradient checkpointing, o pipeline de dados, a cadência de avaliação e o gerenciamento de adaptadores acrescentam pressão prática de memória.
Use esta tabela de planejamento:
| Configuração de fine-tuning | Ponto de partida para 32B | Ponto de partida para 70B | Notas |
|---|---|---|---|
| Experimento mínimo de QLoRA | 24GB a 48GB | 48GB | Mantenha o comprimento de sequência e o tamanho do batch modestos. |
| Execução prática de QLoRA | 48GB a 80GB | 80GB | Mais espaço para dados, avaliação e menos reinicializações. |
| Sequência mais longa ou batch efetivo maior | 80GB ou multi-GPU | 2x80GB ou maior | A memória cresce com o comprimento da sequência e a estratégia de treinamento. |
| Fine-tuning completo | Multi-GPU | Cluster multi-GPU | O estado do otimizador torna o fine-tuning completo um problema diferente. |
Se sua consulta for qlora fine-tune 70b model vram requirements, comece provando uma execução com restrição em 48GB ou 80GB e, depois, aumente o comprimento da sequência e o batch efetivo somente após registrar o pico real de memória. Para um fluxo de trabalho de fine-tuning em produção, 80GB ou capacidade multi-GPU costuma ser mais fácil de operar do que uma configuração pontual de memória mínima.
O cache KV e o comprimento de contexto podem mudar a resposta
Um modelo de 70B que cabe em contexto de 4K pode não caber em contexto de 32K. O cache KV cresce com:
- Número de camadas.
- Cabeças KV e dimensão da cabeça.
- Comprimento de contexto.
- Tamanho do batch ou sequências ativas.
- Bytes por elemento do cache KV.
Os motores de serving lidam com isso de forma diferente. O vLLM expõe a utilização de memória e o comportamento do cache KV como preocupações centrais de serving. O llama.cpp e os estilos de serving local do Ollama expõem escolhas de contexto e de offload que podem fazer um modelo caber, mas com trade-offs de desempenho.
O fluxo de trabalho prático:
- Carregue o modelo na quantização pretendida.
- Defina o comprimento real de contexto, não o padrão.
- Execute uma distribuição de prompts que corresponda à produção.
- Aumente a concorrência até a latência ou a memória falhar.
- Registre o pico de VRAM, requisições falhas, tokens por segundo e a qualidade dos outputs aceitos.
Não dimensione os 70b model vram requirements a partir de um teste de carga vazio. Dimensione com base no contexto e na concorrência que você realmente vai executar.
Uma planilha simples de VRAM
Use esta planilha antes de alugar ou reservar capacidade.
model_family:
parameter_count: 32B | 70B | other
precision: fp16 | bf16 | int8 | 4-bit | mixed
serving_engine: Ollama | llama.cpp | vLLM | SGLang | TensorRT-LLM | other
target_context_window:
input_tokens_p50:
input_tokens_p95:
output_tokens_p50:
output_tokens_p95:
target_concurrency:
batching_policy:
fine_tuning_method: none | LoRA | QLoRA | full fine-tune
gpu_candidate:
gpu_memory:
observed_idle_load_vram:
observed_peak_vram:
oom_failures:
tokens_per_second:
accepted_outputs_per_hour:
cost_per_accepted_output:
Para o planejamento de custos, combine a planilha com preços de aluguel de GPU, custos ocultos da nuvem de GPU e TCO de cluster de GPU.
Quando uma API de modelo é melhor do que alugar GPUs
Capacidade de GPU faz sentido quando você precisa de controle direto sobre pesos, quantização, implantação, adaptadores personalizados, serving privado ou utilização sustentada.
Uma API de modelo pode ser melhor quando:
- O tráfego é intermitente.
- O produto muda de modelo com frequência.
- A equipe não quer operar a infraestrutura de serving.
- A economia unitária é mais fácil de gerenciar por requisição do que por hora de GPU.
- Você precisa de acesso rápido a várias famílias de modelos em vez de uma única implantação fixa.
A Flatkey pertence ao lado de API dessa decisão. Ela oferece aos desenvolvedores um endpoint compatível com OpenAI, uma chave, um saldo, uma fatura e um ledger de uso em modelos e ferramentas oficiais. Se sua planilha de 70b model vram requirements mostrar baixa utilização, margens frágeis de OOM ou grande sobrecarga operacional, faça um benchmark com uma linha de base de modelo/API antes de se comprometer com aluguel de GPU. O guia nuvem de GPU vs API de modelo fornece o quadro de decisão.
Fontes oficiais e documentação para manter abertas
| Fonte | Por que isso importa |
|---|---|
| artigo QLoRA e repositório QLoRA | Referência para ajuste fino de adaptadores com baixo uso de memória em modelos grandes. |
| documentação de quantização bitsandbytes da Hugging Face | Comportamento prático de carregamento em 8 bits e 4 bits no Transformers. |
| documentação do vLLM | Memória de serving, batching e comportamento do KV-cache. |
| repositório llama.cpp | GGUF, descarregamento CPU/GPU e comportamento de inferência local. |
| biblioteca de modelos do Ollama | Tags de modelos, tamanhos de artefatos quantizados e opções de serving local. |
| NVIDIA A100, H100, H200, e DGX B200 | Camadas oficiais de memória de GPU usadas nas decisões de dimensionamento. |
Recomendação final
Para modelos de 32B, comece com 24GB para experimentos em 4 bits, 48GB para inferência confortável e 80GB se quiser FP16/BF16, contexto maior ou margem para ajuste fino.
Para modelos de 70B, trate 48GB como o ponto de partida limitado para 4 bits, 80GB como a camada prática para inferência séria e 96GB a 180GB ou múltiplas GPUs como a camada de margem para produção. Para 70B em FP16/BF16, planeje usar múltiplas GPUs ou GPUs com memória muito alta.
A melhor resposta para requisitos de VRAM para modelo 70b não é um único número de GPU. É uma configuração medida: modelo, quantização, comprimento de contexto, concorrência, mecanismo de serving, método de ajuste fino e custo por saída aceita.
Perguntas Frequentes
Quanta VRAM um modelo 70B precisa?
Um modelo 70B precisa de cerca de 140GB apenas para pesos em FP16 ou BF16, de cerca de 70GB antes de overhead em 8 bits e de aproximadamente 35GB a 45GB para muitas variantes quantizadas em 4 bits. Na prática, os requisitos de VRAM para modelo 70b são maiores quando cache KV, buffers de runtime, comprimento de contexto e concorrência são incluídos.
Um modelo 70B pode rodar em uma GPU de 48GB?
Sim, um modelo 70B pode rodar em uma GPU de 48GB quando é agressivamente quantizado e quando contexto/concorrência são controlados. Essa é uma camada viável para inferência local e testes limitados, mas 80GB ou mais é mais seguro para serving em estilo de produção.
Quais são os requisitos de VRAM do modelo 70B no Ollama?
Para requisitos de VRAM do modelo 70b no Ollama, verifique a tag exata do modelo e o tamanho do artefato quantizado. 48GB pode ser suficiente para alguns modelos 70B quantizados, mas 64GB a 80GB dão mais margem para contexto e menos falhas de OOM.
Quais são os requisitos de VRAM do modelo 70B com QLoRA?
Para requisitos de VRAM do modelo 70b com qlora, 48GB é um piso prático para pesquisa em experimentos limitados, enquanto 80GB ou capacidade de múltiplas GPUs é mais seguro para comprimentos de sequência maiores, batches efetivos maiores e fluxos de trabalho de ajuste fino em produção.
24GB é suficiente para um modelo 70B?
24GB normalmente não é suficiente para inferência confortável de um 70B na GPU. Pode funcionar com quantização pesada, descarregamento para CPU, janelas de contexto pequenas ou experimentos lentos, mas é melhor tratá-lo como uma camada quantizada de 32B.
80GB é suficiente para um modelo 70B?
80GB é suficiente para muitas cargas de trabalho de inferência quantizada de 70B e execuções limitadas de QLoRA. Geralmente não é suficiente para inferência completa de 70B em FP16/BF16 em uma única GPU após overhead, e ainda pode falhar se a janela de contexto ou a concorrência forem muito grandes.
