Guia de Quantização de LLM: 7 Métodos Comparados (Com os Números de Benchmark)

Guia de Quantização de LLM: 7 Métodos Comparados (Com os Números de Benchmark)

O Llama 3.3 70B em FP16 precisa de 140 GB só para os pesos. Duas H100s. Em Q4_K_M, o mesmo modelo cabe em aproximadamente 42 GB, o que é uma RTX A6000 usada comprada no eBay. Essa diferença é a razão inteira pela qual a quantização de LLM existe, e escolher o método errado custa a você ou qualidade visível ou VRAM que você não tem.

Este guia de quantização de LLM compara os 7 métodos que importam em 2026, com cada número rastreado até uma fonte publicada.

Principais Conclusões

• A quantização troca memória e banda por uma perda de qualidade mensurável e geralmente pequena.
• GPTQ e AWQ são métodos para GPU; GGUF é o formato que também roda em CPU.
• O Q4_K_M fica perto de 4,8 bits por peso, não 4. O nome esconde a sobrecarga.
• A quantização de 6 bits fica a ~0,1% da perplexidade do FP16, segundo o PR de k-quants do llama.cpp.

O Que a Quantização de LLM Realmente Faz com o Seu Modelo?

A quantização de LLM armazena os pesos do modelo com precisão numérica menor, reduzindo memória e banda ao custo de erro de arredondamento. Um modelo de 70B parâmetros cai de 140 GB em FP16 para cerca de 42 GB em 4 bits. A inteligência fica; as casas decimais vão embora. Todo método deste guia é uma variante dessa troca.

A escada de precisão vai do FP32 (32 bits) passando por FP16 e BF16 (16 bits cada), depois INT8, depois INT4. Cada degrau corta os bytes por parâmetro pela metade. O padrão IEEE 754 define os formatos de ponto flutuante; o paper de Mark Horowitz de 2014, "Computing's Energy Problem", mostrou por que mover esses bytes, e não a aritmética sobre eles, domina o custo de energia. Essa é a razão física pela qual a quantização acelera a inferência.

Dois parâmetros fazem a quantização funcionar: um fator de escala (multiplicador que mapeia o intervalo de inteiros de volta para valores reais) e um zero-point (o inteiro que representa 0,0). A quantização simétrica centraliza o intervalo em zero e dispensa o zero-point; a quantização assimétrica o desloca para usar o intervalo completo de inteiros quando os pesos se concentram longe do zero.

Os pesos quantizam bem porque são estáticos e têm distribuição normal. As ativações, não. Ativações atípicas, às vezes 100x a mediana, explodem o erro de arredondamento se você as quantizar de forma ingênua. Essa assimetria é o motivo pelo qual a maioria dos métodos aqui quantiza apenas os pesos (W4A16) e deixa as ativações em FP16.

A quantização pós-treinamento (PTQ) converte um modelo pronto depois do treinamento. O treinamento consciente de quantização (QAT) simula o arredondamento durante o treinamento para que o modelo se adapte. Tudo neste post é PTQ. O QAT custa mais computação e uma rodada de treinamento; é uma decisão separada.

As linhas INT4 e NF4 são o 4-bit puro teórico: 4 bits por peso e nada mais. Os formatos 4-bit reais carregam escalas e mínimos de bloco por cima, então ficam mais altos. Um modelo 70B em Q4_K_M fica em cerca de 42 GB, não 35. A tabela de VRAM mais abaixo usa as taxas efetivas.

A quantização não encolhe a inteligência do modelo. Ela encolhe o número de casas decimais em que essa inteligência é armazenada. E se você paga por token na inferência de API, cortar sua conta de API de LLM muitas vezes começa com rodar você mesmo um modelo quantizado.

Os 7 Métodos de Quantização, Lado a Lado

Os sete métodos abaixo cobrem todos os caminhos de produção para quantizar um LLM em 2026. Dois são só para GPU (GPTQ, AWQ), um roda em qualquer lugar (GGUF), um quantiza no momento do carregamento (BitsandBytes), dois miram serving de alta vazão (SmoothQuant, FP8) e um é nativo do PyTorch (TorchAO). A escolha certa depende do seu hardware, não de qual método pontua mais alto em um leaderboard.

GPTQ quantiza camada por camada usando a Hessiana inversa para redistribuir o erro de arredondamento entre os pesos restantes. Precisa de um conjunto de calibração e de uma GPU. O paper do GPTQ relata a quantização de um modelo 175B para 3-4 bits em cerca de 4 GPU-horas.

AWQ identifica o ~1% dos pesos que mais importam (pesos salientes, encontrados pelas magnitudes das ativações) e os escala para protegê-los do arredondamento. O paper do AWQ (melhor paper do MLSys 2024) relata mais de 3x de aceleração sobre a implementação FP16 da HuggingFace, tanto em GPUs de desktop quanto móveis.

GGUF é um formato de arquivo, não um algoritmo. O algoritmo dentro dele é o esquema de blocos k-quant do llama.cpp PR #1684. É o único método aqui que roda em CPU, o que o torna o padrão para inferência local. Veja modelos open-weight que valem a pena quantizar para saber o que colocar nele.

BitsandBytes quantiza no carregamento, e não com antecedência. O NF4 (4-bit NormalFloat) é o seu formato característico e é a espinha dorsal do fine-tuning com QLoRA. Não precisa de conjunto de calibração.

SmoothQuant migra os outliers de ativação para os pesos, de modo que ambos possam rodar em INT8. O paper relata até 1,56x de aceleração e 2x de redução de memória, e mira a vazão no serving com lotes grandes, onde os métodos W4A16 deixam desempenho na mesa.

FP8 (W8A8) é o caminho nativo nas GPUs H100 e B200. Quase sem perdas em 8 bits, sem dor de cabeça com calibração, e o vLLM o suporta diretamente.

TorchAO é a biblioteca de quantização do próprio PyTorch, feita para funcionar com o torch.compile. Se o seu pipeline já é PyTorch, é o caminho de menor resistência.

Só existem duas perguntas de verdade: o seu hardware roda o método, e você consegue viver com a qualidade que ele custa?

O Que os Benchmarks Publicados Realmente Mostram?

Os benchmarks publicados dizem que a quantização de 4 bits custa 1-2% de perplexidade em um modelo 7B, e a de 6 bits custa menos de 0,1%. Esses números vêm do llama.cpp PR #1684 (2023), medidos pelos mantenedores do llama.cpp em um único modelo 7B numa RTX 4080. São os números mais citados no espaço da quantização e são reais. Também são n = 1.

Fonte: llama.cpp PR #1684 (2023). Modelo 7B, RTX 4080, medido pelos mantenedores do llama.cpp. n = 1 modelo.

Uma nota sobre a coluna de bits/peso: essas são as taxas nominais do tipo k-quant base, e as misturas _K elevam a taxa efetiva. O Q2_K é um exemplo perfeito. Aplique a fórmula do próprio post ao 2,5625 nominal e a um modelo de 6,74B parâmetros e você obtém ~2,0 GB, mas a linha relata um arquivo de 2,67 GB, o que, calculando de trás para frente, dá ~3,4 bits por peso. O resto deste post usa as taxas efetivas, derivadas desses tamanhos de arquivo.

Os números dos métodos para GPU vêm diretamente dos papers. O GPTQ relata acelerações de inferência de ponta a ponta sobre o FP16 de aproximadamente 3,25x numa A100 e ~4,5x numa A6000, com um modelo 175B quantizado para 3-4 bits em cerca de 4 GPU-horas. O AWQ relata "mais de 3x de aceleração sobre a implementação FP16 da Huggingface, tanto em GPUs de desktop quanto móveis", além do primeiro deployment de um Llama-2 70B numa GPU móvel via TinyChat. Citamos a redação do paper em vez de parafrasear um número com falsa precisão.

A contribuição original aqui é aritmética. A memória para os pesos segue: pesos (GB) ≈ parâmetros (B) × bits por peso ÷ 8. A pegadinha é qual número de bits por peso você coloca nela. O PR #1684 publica a taxa do tipo k-quant base (Q4_K = 4,5), e as misturas _S/_M/_L ficam acima dessa taxa base porque entregam bits extras aos tensores de atenção e feed-forward. Então derivamos as taxas efetivas dos tamanhos de arquivo que o próprio PR publica, num modelo 7B que na verdade tem 6,74B parâmetros: o Q2_K com 2,67 GB resulta em ~3,4 bpw de trás para frente, o Q4_K_S com 3,56 GB em ~4,5, o Q6_K com 5,15 GB em ~6,6. O Q4_K_M fica perto de 4,8.

Isso muda o número da manchete. Um modelo 70B em Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. A maioria dos posts diz 35 GB. Eles estão usando 4,0 bpw e ignorando totalmente a sobrecarga das escalas de bloco. A verificação cruzada leva um clique: o Llama-3.3-70B-Instruct-Q4_K_M.gguf é distribuído com 42,5 GB no HuggingFace, nos repositórios bartowski, lmstudio-community e second-state igualmente. Recalculamos cada célula da tabela de VRAM abaixo com essa base.

Nossa leitura desses números: a diferença de perplexidade entre o Q6_K (5,9110) e o F16 (5,9066) é 0,0044, o que é menor que a diferença entre dois fine-tunes diferentes do mesmo modelo base. É por isso que "use simplesmente Q4_K_M ou Q5_K_M" é o conselho que sobrevive ao contato com hardware real. A coluna de ms/token também mostra que o Q2_K não compra velocidade nenhuma sobre o Q4_K_S (ambos 15,5 ms/token) enquanto custa 0,75 de perplexidade. O Q2_K é a pior troca da tabela.

O que os números não contam: a perplexidade no wikitext não é o mesmo que qualidade nos seus prompts. Um modelo numa GPU é n = 1. Os números de velocidade dependem do tamanho do lote. Trate-os como direcionais, não universais.

A quantização de 6 bits fica a cerca de 0,1% da perplexidade do modelo em precisão total. A compressão é quase grátis nesse nível.

GPTQ vs AWQ: Escolhendo Entre os Dois Métodos para GPU

GPTQ e AWQ produzem checkpoints de 4 bits para GPU a partir de um conjunto de calibração, e ambos são bem suportados no vLLM. A diferença está em como tratam o erro de arredondamento. O GPTQ o redistribui entre os pesos restantes usando a Hessiana inversa. O AWQ protege o 1% dos pesos que as ativações sinalizam como importantes. Os dois funcionam. A escolha depende do seu padrão de serving.

GPTQ trabalha camada por camada. Para cada camada, quantiza um peso por vez e depois ajusta os pesos restantes daquela camada para compensar o arredondamento que acabou de fazer. O ajuste usa informação de segunda ordem da matriz Hessiana, e é por isso que precisa de um conjunto de calibração para ser calculado. O resultado é forte para inferência em lote, onde a vazão importa mais que a latência por token.

AWQ parte de outro ângulo. Identifica os pesos salientes olhando as magnitudes das ativações ao longo do conjunto de calibração, aproximadamente o 1% superior dos canais. Esses pesos recebem um fator de escala por canal que os mantém numa faixa de precisão mais alta durante o arredondamento. O conjunto de calibração pode ser menor que o do GPTQ, e o AWQ sofre menos overfitting nele porque protege características estruturais em vez de se ajustar a entradas específicas. O paper relata resultados fortes em serving sensível a latência.

Escolha GPTQ se: você faz inferência em lote numa GPU, tem um bom conjunto de calibração que corresponde ao seu domínio e a métrica é vazão.

Escolha AWQ se: você serve requisições de usuário único com baixa latência, quer um conjunto de calibração menor ou está implantando em GPUs de borda/móveis.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Se você também está escolhendo entre engines de serving, vLLM contra SGLang cobre essa decisão separadamente.

GGUF e K-Quants: O Que Q4_K_M Realmente Significa

GGUF é um formato de arquivo, não um algoritmo de quantização. A especificação GGUF define um contêiner para pesos de modelo, metadados e dados de tokenizador. O algoritmo de quantização dentro de um arquivo GGUF é o esquema de blocos k-quant (ou i-quant) do llama.cpp PR #1684. Confundir o contêiner com o algoritmo é o erro mais comum neste espaço, e leva a perguntas como "qual é melhor, GGUF ou GPTQ?" que não fazem muito sentido.

O esquema de nomes se decodifica assim. Q significa esquema de blocos k-quant; IQ significa i-quant com matriz de importância (uma variante mais nova que usa uma matriz de importância para qualidade melhor na mesma profundidade de bits). O número é a profundidade nominal de bits. _K marca a família k-quant em oposição a formatos legados como o Q4_0. _S, _M, _L controlam quais grupos de tensores recebem bits extras: small, medium, large. Sufixo mais alto significa mais bits alocados aos tensores de atenção e feed-forward, que são os que mais importam.

Taxas efetivas, calculadas de trás para frente a partir dos tamanhos de arquivo do 7B (6,74B parâmetros) publicados no PR #1684, não dos números do tipo base. As linhas legadas são exatas por construção: um bloco Q4_0 tem 32 pesos em 4 bits mais uma escala FP16, o que dá 4,5 bits por peso, e o Q8_0 tem 32 pesos em 8 bits mais uma escala FP16, o que dá 8,5. O PR corrobora isso, listando os arquivos Q4_0 e Q4_K_S do 7B com os mesmos 3,56 GB.

O Q4_K_M não tem 4 bits por peso. Tem cerca de 4,8. As escalas e mínimos de bloco precisam morar em algum lugar, e a mistura _M então gasta bits extras nos tensores de atenção e feed-forward, o que é exatamente o motivo pelo qual o Q4_K_M fica acima do Q4_K_S e o Q3_K_M fica acima do Q3_K_S em vez de igualá-lo.

Por que o GGUF roda onde o GPTQ não pode: ele suporta inferência em CPU e offload de camadas entre a VRAM da GPU e a RAM do sistema. Um modelo 32B que não cabe inteiro na sua GPU pode rodar com metade das camadas em offload, devagar, mas funcionalmente. O GPTQ não tem caminho em CPU.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Novo em modelos locais? Comece com colocar seu primeiro modelo local para rodar antes de quantizar qualquer coisa. E se você quer uma interface no navegador, Open WebUI sobre o Ollama leva uns dez minutos. A documentação GGUF do HuggingFace explica como o Hub expõe os nomes dos tipos de quant.

BitsandBytes, Marlin, SmoothQuant e TorchAO

Esses quatro cobrem os caminhos de produção restantes. Nenhum é um "GPTQ melhor". Eles resolvem problemas diferentes.

BitsandBytes quantiza no momento do carregamento, e não com antecedência. Você o aponta para um checkpoint FP16 e ele converte na hora para NF4 ou FP4. Sem conjunto de calibração, sem etapa offline. Sua principal fama é o QLoRA: um modelo base congelado de 4 bits com adaptadores LoRA treinados por cima, o que torna possível o fine-tuning de um modelo 65B numa única GPU com 48 GB de VRAM. O QLoRA é uma técnica de treinamento, não de inferência, mas é o motivo pelo qual a maioria das pessoas encontra o BitsandBytes primeiro.

Marlin não é um método de quantização. É um kernel GEMM de precisão mista INT4xFP16 que torna os checkpoints de 4 bits existentes mais rápidos em tamanhos de lote moderados. O paper do Marlin relata acelerações em A100 e H100. Se a sua stack de serving o suporta, você o ativa num modelo já quantizado. Você não "quantiza com Marlin".

SmoothQuant desloca os outliers de ativação para os pesos por meio de um fator de escala por canal, tornando o W8A8 (pesos e ativações ambos em INT8) viável. O paper mira o serving com lotes grandes, onde os métodos W4A16 deixam vazão na mesa. Se você serve centenas de requisições simultâneas, essa é a jogada.

TorchAO é a quantização nativa do PyTorch que funciona com o torch.compile. Sem dependências externas, sem conversão de formato. Se o seu pipeline de inferência já é PyTorch, é a opção de menor atrito. Para rodar modelos de embedding localmente, o caminho do Ollama costuma ser mais simples, mas o TorchAO se encaixa em stacks PyTorch personalizadas.

Quanta VRAM um Modelo Quantizado Precisa?

A fórmula é pesos (GB) ≈ parâmetros (B) × bits por peso ÷ 8. Um modelo 70B em Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. As taxas abaixo são as efetivas, calculadas de trás para frente a partir dos tamanhos de arquivo que o llama.cpp PR #1684 publica, e não dos números do tipo base, porque as misturas _M sempre rodam acima da sua taxa k-quant base. Recalculamos em vez de copiar o atalho usual de 4,0 bpw.

Calculado a partir dos bits por peso efetivos: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Derivados dos tamanhos de arquivo do 7B (6,74B parâmetros) no PR #1684 e depois verificados contra um build 70B publicado: o Llama-3.3-70B-Instruct-Q4_K_M.gguf tem 42,5 GB no HuggingFace, contra 42,0 GB previstos aqui.

A ressalva honesta: isso são apenas os pesos. Cache KV, comprimento de contexto e sobrecarga do framework se somam por cima. O cache KV escala com o comprimento de contexto e o tamanho do lote. Uma sessão com contexto de 32k num modelo 70B pode adicionar vários GB. A tabela de pesos é o piso, não o orçamento. Sua janela de contexto também aluga VRAM. Para o quadro completo, veja requisitos de VRAM por modelo em detalhe.

Qual Método de Quantização Você Deve Usar?

Seu hardware decide antes das suas preferências. Um método que não roda na sua GPU não é uma escolha, é um desejo. A tabela abaixo mapeia cenários comuns para o método que realmente funciona para eles, com base nas restrições de hardware e nas trocas de qualidade cobertas acima.

Para a maioria dos leitores em hardware de consumo, um GGUF Q4_K_M ou Q5_K_M pré-quantizado é a resposta certa. Baixe do HuggingFace, rode no Ollama ou no llama.cpp e pare de otimizar. A diferença de qualidade entre o Q4_K_M e o Q5_K_M é pequena o suficiente para que você deva escolher com base em se o arquivo cabe, e não numa tabela de perplexidade. Tudo além disso é otimização pela otimização, e só vale a pena depois que você confirmar que o modelo realmente resolve o seu problema em Q4.

O guia de ferramentas que rodam esses modelos localmente cobre o lado do serving depois que você escolhe o nível de quant.

Cinco Jeitos de Errar na Quantização

As falhas de quantização são quase sempre problemas de configuração, não de método. Estes cinco aparecem o tempo todo.

1. O conjunto de calibração não corresponde ao seu domínio. GPTQ e AWQ se ajustam aos dados de calibração. Se você calibra na Wikipedia e implanta em transcrições médicas, o modelo quantizado tem desempenho inferior nos tokens que nunca viu. Correção: use um conjunto de calibração extraído da sua distribuição real de entrada; até 128 amostras ajudam.

2. Tamanho de grupo grande demais. O tamanho de grupo do GPTQ controla quantos pesos compartilham um fator de escala. 128 é o padrão. 256 ou 512 economiza computação durante a quantização, mas bate num penhasco de qualidade em modelos menores. Correção: fique em 128 a menos que você tenha confirmado que a qualidade se mantém nos seus prompts.

3. Esperar que o Q2_K seja utilizável. Pelos dados do PR #1684, o Q2_K custa ~0,87 de perplexidade em relação ao F16 e não compra velocidade nenhuma sobre o Q4_K_S (ambos 15,5 ms/token no benchmark de 7B). Você ganha um arquivo menor e saída pior, sem ganho de latência. Correção: o Q4_K_S é o piso, a menos que o tamanho do arquivo seja uma restrição rígida.

4. Fazer benchmark na perplexidade do wikitext em vez dos seus próprios prompts. Perplexidade é uma métrica de modelagem de linguagem. Ela não mede se o modelo segue o seu prompt de sistema, formata JSON corretamente ou lida com o vocabulário do seu domínio. Correção: rode 20-30 dos seus prompts reais tanto no modelo quantizado quanto no não quantizado e compare as saídas.

5. Confundir o GGUF, o contêiner, com o algoritmo de quantização dentro dele. Isso leva a comparar "GGUF vs GPTQ" como se fossem da mesma categoria. Não são. GGUF é um formato de arquivo. O esquema k-quant dentro dele é o algoritmo. Correção: compare níveis k-quant (Q4_K_M vs Q5_K_M), não formatos de arquivo.

Perguntas Frequentes

O que é quantização de LLM?

A quantização de LLM reduz a precisão numérica dos pesos de um modelo, tipicamente de ponto flutuante de 16 bits para inteiros de 4 ou 8 bits. Isso corta o uso de memória e acelera a inferência ao reduzir a banda. Um modelo 70B cai de 140 GB para cerca de 42 GB em 4 bits. O custo de qualidade costuma ser 1-2% de perplexidade em 4 bits, e menos em 6 bits.

A quantização reduz a precisão de um modelo?

Sim, mas menos do que a maioria espera. Pelos benchmarks do llama.cpp PR #1684, o Q4_K_S num modelo 7B custa cerca de 2% de perplexidade em relação ao F16, e o Q6_K custa menos de 0,1%. O impacto prático em prompts reais costuma ser menor do que o número de perplexidade sugere, especialmente em Q4_K_M e acima.

GPTQ ou AWQ é melhor?

Nenhum é universalmente melhor. O GPTQ usa redistribuição de erro por Hessiana inversa e serve para inferência em lote na GPU. O AWQ protege pesos salientes por meio de escala consciente de ativação e serve para serving sensível a latência. O AWQ precisa de um conjunto de calibração menor e sofre menos overfitting nele. Se você serve requisições de usuário único com baixa latência, comece com o AWQ.

O que significa Q4_K_M?

Q4_K_M é um nível de quantização k-quant do GGUF. "Q4" significa profundidade nominal de 4 bits, "K" marca o esquema de blocos k-quant (em oposição ao legado Q4_0) e "M" significa medium: os tensores de atenção e feed-forward recebem bits extras. Os bits por peso efetivos são cerca de 4,8, não 4,0, porque as escalas e mínimos de bloco adicionam sobrecarga e a mistura medium gasta mais por cima.

Posso rodar um modelo quantizado em CPU?

Sim, mas só via GGUF. GPTQ e AWQ são formatos só para GPU. Os modelos k-quant do GGUF rodam em CPU pelo llama.cpp ou Ollama e suportam offload de camadas entre a VRAM da GPU e a RAM do sistema. O Q4_K_M é o quant padrão para CPU. Espere geração de tokens mais lenta que na GPU, mas inferência funcional.

Qual é a diferença entre GGUF e GGML?

O GGML é a biblioteca de tensores e formato de arquivo mais antigo que o llama.cpp usava originalmente. O GGUF o substituiu em agosto de 2023 como um formato contêiner mais flexível, com melhor suporte a metadados. Os arquivos GGUF são o que você baixa do HuggingFace hoje. Os arquivos GGML são legados e raramente distribuídos.

Devo quantizar um modelo eu mesmo ou baixar um pré-quantizado?

Baixe um pré-quantizado primeiro. As comunidades do llama.cpp e do HuggingFace já quantizaram a maioria dos modelos populares em todos os níveis. Quantizar você mesmo só faz sentido se você precisa de um conjunto de calibração específico para o seu domínio, ou se não existe versão pré-quantizada para o seu modelo.

Quando devo usar quantização em vez de um modelo menor?

Use quantização quando você precisa da capacidade do modelo maior mas não consegue colocá-lo na memória. Um modelo 70B quantizado geralmente supera um modelo 13B não quantizado em tarefas de raciocínio complexo. Use um modelo menor quando a latência é a restrição, já que modelos menores geram tokens mais rápido independentemente da quantização.

Qual é a diferença entre quantização e destilação?

A quantização reduz a precisão numérica dos pesos de um modelo existente. A destilação treina um modelo menor para imitar um maior, produzindo uma arquitetura genuinamente diferente (menor). A quantização preserva a arquitetura do modelo original e é reversível em princípio. A destilação cria um modelo novo e requer uma rodada de treinamento.

A versão curta: a quantização é como você encaixa o modelo que quer no hardware que tem. Para a maioria das pessoas em GPUs de consumo ou Apple Silicon, um GGUF Q4_K_M pré-quantizado baixado do HuggingFace é a solução inteira. GPTQ e AWQ são as respostas para serving em GPU. FP8 e SmoothQuant são as respostas para vazão em produção. Todo o resto é otimização depois que você confirmou que o modelo funciona.

Se você está decidindo o que hospedar por conta própria e quer uma segunda opinião sobre o par hardware-método, estamos à disposição para conversar.