granite-4.2-30b: de quanta VRAM ele precisa?

Esta página foi escrita e traduzida automaticamente por IA e verificada por software em relação às suas fontes, sem edição humana. As especificações vêm das fontes listadas; os requisitos de memória e as velocidades são estimativas calculadas com fórmulas publicadas. Como usamos IA

granite-4.2-30b tem 29,3B parâmetros. Em Q4_K_M, com um contexto de 8.192 tokens, uma única GPU precisa de 20,5 GiB de memória disponível para que o resultado seja “Cabe”.

Valores atualizados em 19 de out. de 2026

Principais fatos

Arquivos GGUF e memória necessária

Todas as quantizações vêm de um único repositório GGUF em uma única revisão fixada: ibm-granite/granite-4.2-30b-GGUF@27b350a

Menor GPU para cada quantização

GPUs que podem executar granite-4.2-30b

“Cabe” significa que a verificação de carregamento padrão --fit do llama.cpp colocaria todas as camadas na GPU: nossa estimativa dos buffers do llama.cpp, mais a margem de erro, mais a reserva de 1 GiB por placa do llama.cpp, está dentro da memória contada como disponível. Isso não garante que a memória de pico durante a geração caiba. Como os resultados são definidos

GPUs no limite

GPUs em que não cabe em uma placa

GPUs sem veredito

• CUDA (NVIDIA): llama.cpp, back end CUDA (GPU dedicada NVIDIA), todas as camadas na GPU, Flash Attention ativada, micro-batch (-ub) 512, KV cache em F16, contexto (-c) conforme indicado; “Cabe” é avaliado com as 4 sequências paralelas padrão do llama-server (-np auto, KV cache unificado) e “Não cabe” com 1 sequência; GPU ociosa, sem outros programas usando sua memória.
• ROCm no Linux (AMD): llama.cpp, back end ROCm no Linux (GPU dedicada AMD), todas as camadas na GPU, Flash Attention ativada, micro-batch (-ub) 512, KV cache em F16, contexto (-c) conforme indicado; “Cabe” é avaliado com as 4 sequências paralelas padrão do llama-server (-np auto, KV cache unificado) e “Não cabe” com 1 sequência; GPU ociosa, sem outros programas usando sua memória.

O teto de velocidade é a largura de banda da memória dividida pelos bytes lidos por token gerado. É um limite superior teórico; os benchmarks públicos do llama.cpp normalmente atingem cerca de metade a quatro quintos desse valor, e modelos pequenos e modelos MoE (mistura de especialistas) costumam atingir menos. Benchmarks públicos

Pesos originais

Os arquivos de pesos originais do modelo (safetensors, contabilizados conforme descrito na metodologia) somam 54,5 GiB. Eles são listados apenas como referência; toda estimativa desta página refere-se aos arquivos GGUF acima, executados com o llama.cpp. ibm-granite/granite-4.2-30b · Metodologia

Fontes

• Hugging Face: ibm-granite/granite-4.2-30b@9e668ce
• Hugging Face (GGUF): ibm-granite/granite-4.2-30b-GGUF@27b350a
• Metodologia (llama.cpp 5aeac37a)