TurboQuant: quantizar modelos grandes para fazê-los caber em local

#Por que usar o TurboQuant?

Os K-quants GGUF (Q4_K_M, Q5_K_M…) são a referência desde 2023: universalmente suportados por llama.cpp, Ollama, LM Studio, e fáceis de produzir. Mas eles atingem seu limite nos modelos muito grandes. Um modelo denso de 70B em Q4_K_M exige aproximadamente 40 GB de VRAM — fora do alcance de uma RTX 4090 de 24 GB. Reduzir para Q3 ou Q2 faz a qualidade colapsar.

A quantização TurboQuant aborda especificamente essa lacuna. Trata-se de uma família de técnicas que combinam calibração em um conjunto de dados, alocação de bits não uniforme por camada e compressão por blocos com dicionário compartilhado. O resultado: 2,5 a 3 bits efetivos por peso com perda de qualidade inferior à de um Q3_K_M GGUF.

#Como funciona a compressão

Três mecanismos se acumulam. Nenhum é revolucionário sozinho; é a combinação que faz a diferença.

Calibração com dados

Algumas centenas de prompts representativos são processados pelo modelo para medir quais pesos realmente influenciam as saídas. Os demais podem ser quantizados de forma agressiva.

Alocação de bits por camada

Em vez de um orçamento fixo (4 bits em todos os lugares), o TurboQuant atribui 5 a 6 bits às camadas de atenção críticas e reduz para 2 bits em MLP redundantes. A média total cai para 2,7 a 3,2 bpw.

Compressão por blocos

Os pesos são agrupados em blocos de 32 ou 64 valores que compartilham um fator de escala e um deslocamento, com um codebook comprimido por grupo. Isso evita o overhead por parâmetro dos K-quants.

#TurboQuant vs GGUF clássico

Para um modelo denso de 70B, esta é a ordem de grandeza típica:

GGUF Q4_K_M (~4,5 bpw)

~40 GB, qualidade quase FP16, compatível em todos os lugares. A referência.

GGUF Q3_K_M (~3,4 bpw)

~32 GB, perda significativa em raciocínios longos, surgem alucinações.

GGUF Q2_K (~2.6 bpw)

~26 GB, modelo claramente degradado, evitar para uso sério.

TurboQuant ~3.0 bpw

~28 GB, qualidade próxima à do Q4_K_M. Cabe em 1×RTX 3090 ou 1×4090 com contexto curto.

TurboQuant ~2.5 bpw

~23 GB, ligeiramente abaixo do Q4 mas bem acima do Q3. Permite o 70B em 24 GB de VRAM.

#Economia de VRAM medida por tamanho do modelo

Os números abaixo são apenas ordens de grandeza para modelos densos recentes (Qwen 3.5, Granite 4.2), em contexto de 4k, sem Flash Attention. Adicione 10-20% de margem para o cache KV e o overhead de tempo de execução.

7B — Q4_K_M: 4,4 GB

TurboQuant 3.0 bpw: ~2,9 GB. Benefício limitado, o 7B já cabe em qualquer configuração.

13B — Q4_K_M: 7,8 GB

TurboQuant 3.0 bpw: ~5,1 GB. Permite 16k+ de contexto em 8 GB de VRAM.

32B — Q4_K_M: 19 GB

TurboQuant 3.0 bpw: ~13 GB. Cabe confortavelmente em uma RTX 4080 de 16 GB com contexto de 8k.

70B — Q4_K_M : 40 GB

TurboQuant 2.5 bpw: ~23 GB. Permite o 70B em 1×RTX 4090 24 GB ou 1×3090 24 GB.

120B MoE — Q4_K_M : ~70 GB

TurboQuant 2.7 bpw: ~42 GB. Possível em 2×3090 ou em um Mac Studio 64 GB.

#Impacto na qualidade

Nos benchmarks comuns (MMLU, HellaSwag, HumanEval), um modelo de 70B quantizado com TurboQuant a 3,0 bpw fica entre 0,5 e 1,5 ponto de distância do FP16. No raciocínio em múltiplas etapas e em código longo, começamos a ver diferenças mais claras. O teste que distingue mais claramente os métodos: um longo trecho de código Python com dependências cruzadas.

Conhecimentos gerais

Quase imperceptível. Se você fizer perguntas sobre cultura geral, não perceberá a diferença.

Raciocínio curto

Perda pequena. As cadeias de pensamento permanecem coerentes em 5 a 10 etapas.

Raciocínio longo (matemática/demonstrações)

Perda visível. O modelo pode pular uma etapa ou se perder após 20 ou mais rodadas de raciocínio. Prefira 3,5 bpw ou mais se esse for o seu uso.

Código

Sensível às quantizações agressivas. Abaixo de 3,0 bpw, espere mais erros sutis (índices errados, condições invertidas). Mantenha Q4_K_M ou TurboQuant ≥3,5 bpw para Aider/Continue.

Idiomas raros

O francês funciona bem até 2,5 bpw. Idiomas com pouca representação no corpus de calibração sofrem mais.

#Pré-requisitos de hardware e software

Quantizar você mesmo um modelo continua sendo uma operação pesada. Baixá-lo já quantizado do Hugging Face é quase sempre mais simples. Se ainda assim quiser produzir sua própria versão:

GPU para a calibração

É necessário poder carregar o modelo em FP16 ou BF16 durante a análise. Para um 70B, isso exige 2×A100 de 80 GB ou um Mac Studio M2 Ultra de 192 GB. Para um 32B, uma RTX 4090 de 24 GB é suficiente com offload parcial.

Modelo base

Pesos não quantizados (safetensors) baixados do repositório original no Hugging Face. Conte com 140 GB para um 70B FP16.

Dataset de calibração

256 a 1024 amostras representativas do seu uso. Wikipedia FR, código, seus próprios prompts. Evite datasets genéricos se você tem um domínio específico.

Runtime de destino

Decida de antemão: ExLlamaV3 (o mais rápido em Nvidia), llama.cpp com backend turbo ou um fork específico. O formato de arquivo difere entre os runtimes.

Python 3.10+ e CUDA 12+

Conjunto de ferramentas padrão. No caso da AMD, o ROCm 6.x funciona com o llama.cpp, mas ainda não com todos os forks turbo.

#Workflow para você mesmo quantizar

O fluxo típico, desde um modelo Hugging Face FP16 até um arquivo executável no Ollama ou llama.cpp.

1. 01
   Recuperar os pesos originais

   Clonar o repositório do modelo não quantizado no Hugging Face. Prever pelo menos uma hora para um modelo de 70B com uma boa conexão. Use huggingface-cli download para poder retomar o download após uma interrupção.
2. 02
   Preparar o conjunto de dados de calibração

   Criar um arquivo JSONL com 256 a 1024 prompts. A diversidade é mais importante que a quantidade: código, prosa em francês, diálogos, perguntas técnicas. Um arquivo de 5 a 20 MB é mais do que suficiente.
3. 03
   Iniciar a calibração

   A ferramenta (por exemplo, o script quantize fornecido pelo projeto TurboQuant escolhido) carrega o modelo, realiza uma passagem de propagação direta para cada prompt e coleta estatísticas de ativação camada por camada. Conte com 1 a 4 horas em um modelo de 70B, dependendo da GPU.
4. 04
   Quantizar e exportar

   A alocação de bits é calculada com base em estatísticas e depois cada tensor é codificado. Saída: um arquivo .safetensors ou .gguf conforme o runtime. Adicione 30 minutos a 2 horas de tempo extra.
5. 05
   Converter para o formato de execução

   Para Ollama: criar um Modelfile apontando para o arquivo quantizado, depois executar ollama create monmodele -f Modelfile. Para llama.cpp: o binário main aceita o .gguf diretamente.
6. 06
   Validar a qualidade

   Iniciar uma pequena bateria de testes: 20 a 30 prompts abrangendo seus usos. Comparar lado a lado com a versão GGUF Q4_K_M de referência. Se a degradação for muito acentuada, repetir com mais bits ou um conjunto de dados melhor.

# Une fois le .gguf TurboQuant produit
cat > Modelfile <<EOF
FROM ./glm-4.7-turboquant-3.0bpw.gguf
PARAMETER num_ctx 8192
PARAMETER temperature 0.7
EOF

ollama create glm-4.7-turbo -f Modelfile
ollama run glm-4.7-turbo "Explique le théorème de Bayes en 3 phrases."

#Armadilhas comuns e solução de problemas

O runtime não reconhece o arquivo

TurboQuant não é um formato padrão único. Verifique se está carregando o arquivo com o runtime correspondente ao método usado (ExLlamaV3 para EXL3, versão recente do llama.cpp para GGUF turbo).

Capacidade da VRAM excedida durante a inferência, embora o arquivo coubesse nela

Você esquece o cache KV. Em um contexto de 32k, o KV pode ocupar 4 a 8 GB a mais. Reduza num_ctx ou ative o Flash Attention via OLLAMA_FLASH_ATTENTION=1.

Qualidade catastrófica no seu caso de uso

O conjunto de dados de calibração não abrange seu domínio. Repita adicionando 100 a 200 prompts representativos. É, de longe, o recurso mais poderoso.

O modelo quantizado é mais lento que o Q4_K_M

É normal em certas arquiteturas: a descompressão turbo tem um custo adicional de processamento. Em placas antigas (RTX 20xx), a economia de VRAM pode vir à custa de uma redução nos tokens por segundo. Meça antes de adotar.

Diferenças entre execuções

A calibração introduz não determinismo. Duas quantizações do mesmo modelo com o mesmo conjunto de dados podem divergir ligeiramente em qualidade. Faça várias execuções e mantenha a melhor.

#Para se aprofundar

TurboQuant é uma ferramenta entre outras para ampliar o limite do que cabe localmente. Algumas opções complementares:

Escolher sua quantização (Q4, Q5, Q8, FP16)

Para situar bem o TurboQuant em relação aos K-quants GGUF clássicos e escolher caso a caso.

Fine-tuning local de LLMs: LoRA e QLoRA

Se você quiser ir além da quantização e adaptar um modelo ao seu domínio — muitas vezes uma estratégia mais eficaz do que uma quantização mais agressiva.

Escolher sua GPU para IA local

Para decidir qual placa escolher, sabendo que a VRAM continua sendo a principal restrição, mesmo com TurboQuant.