A quantização disagregada deixa a geração mais rápida depois do primeiro token?

Não. O decodificador de 1 bit continua o mesmo, e o paper afirma que a velocidade de streaming de tokens não muda. O ganho está todo na espera antes da primeira palavra.

Funciona em Mac ou em GPU mais antiga?

Não com o pré-processador lançado. Ele exige GPU Blackwell, seja um GB10 (DGX Spark) ou uma placa da série RTX 50 da NVIDIA.

Preciso retreinar o modelo?

Não. O decodificador de 1 bit é usado exatamente como foi distribuído; o pré-processador NVFP4 é uma segunda cópia treinada apenas para a leitura do prompt.

Os números de 1,78x e 61,54% são independentes?

Não. São medições dos próprios autores em um DGX Spark, com três execuções por ponto e cache de prompt desligado. Nenhuma reprodução independente foi publicada até outubro de 2026.

Posso usar com prompts curtos?

Desaconselhável. No DGX Spark, o break-even fica perto de 8 mil tokens, e o paper admite que prompts curtos podem sair mais lentos porque a computação não esconde o carregamento do SSD.

como usar quantização disagregada em LLM local

12,27 segundos. É o que os autores mediram antes do primeiro token em um modelo denso de 27 bilhões de parâmetros comprimido para 1 bit, com um prompt de 8 mil tokens. Com quantização disagregada, o mesmo tempo caiu para 6,90 segundos, sem retreinar o gerador.

Quantização disagregada: o que muda no seu LLM local

A quantização disagregada é uma técnica de um paper de setembro de 2026, escrito por pesquisadores do ISTA e da NVIDIA, que dá ao mesmo modelo dois formatos de pesos: um decodificador de 1 bit residente na memória para gerar a resposta e um pré-processador de 4 bits (NVFP4) que lê o seu prompt. O ganho aparece no tempo até o primeiro token, não na velocidade de digitação.

A tese central é simples: ler o prompt e escrever a resposta são trabalhos diferentes, com gargalos diferentes. Comprimir tudo para 1 ou 2 bits, como manda o conselho tradicional de quantização, acelera só a escrita e cobra a conta em precisão. A técnica desse paper arXiv:2609.26333 trata os dois lados separadamente.

No teste principal, sobre o Qwen3 denso de 27 bilhões de parâmetros da Alibaba, os autores relatam o tempo até o primeiro token caindo de 12,27 s para 6,90 s (1,78x) e a precisão no MMLU-Pro subindo de 29,04% para 61,54% — com o decodificador de 1 bit exatamente como foi baixado, sem retreino.

Por que prefill e decode têm gargalos diferentes?

Prefill e decode são as duas fases de qualquer inferência, e cada uma bate em uma parede diferente do hardware. Entender essa divisão explica por que um único conjunto de pesos quantizados sempre deixa um dos lados com a ferramenta errada.

Prefill (leitura do prompt): cada peso sai da memória uma vez e é reutilizado em milhares de tokens. O que limita a velocidade é a computação — o paper chama isso de compute-bound. Aritmética de baixa precisão, como o NVFP4, acelera essa fase.

Decode (escrita da resposta): para cada novo token, o modelo busca todos os pesos novamente. Em batch de 1, cada peso serve a uma única multiplicação, e a viagem até a memória domina. Pesos menores, como os de 1 bit, tornam cada viagem mais leve.

O paper resume a regra em uma linha: matemática de baixa precisão acelera a leitura, pesos compactos aceleram a escrita. Quantizar tudo para um lado só deixa o outro lento ou impreciso.

Dimensão	Prefill (leitura)	Decode (escrita)
Reuso dos pesos	Reutilizado em milhares de tokens	Buscado uma vez por token
Gargalo dominante	Computação	Largura de banda de memória
Formato que ajuda	NVFP4 (4 bits)	IQ1_S (1 bit)
Métrica afetada	Tempo até o primeiro token	Velocidade de geração

Como funciona o offloaded disaggregated prefill (ODP)

O offloaded disaggregated prefill, ou ODP, é a implementação prática da ideia no fork dos autores do llama.cpp. Duas cópias de 27 bilhões de parâmetros soariam como desperdício de memória, e é aqui que o design se diferencia: o pré-processador nunca entra na memória do dispositivo.

O funcionamento tem três passos, conforme descrito no paper:

Mantenha na memória unificada o decodificador de 1 bit (nos testes, o checkpoint IQ1_S da Unsloth), intocado, responsável por gerar os tokens.

2. Transmita o pré-processador NVFP4 de 12,8 GiB direto do SSD, um bloco de camadas por vez, para dois buffers pequenos. Enquanto um bloco processa o prompt, o próximo já está sendo carregado no outro buffer; depois eles trocam.

3. Aplique o tratamento apenas às multiplicações de matrizes grandes (as projeções lineares), que dominam o custo do prefill.

Os dois buffers não ocupam memória nova: segundo o model card, eles são esculpidos dentro do espaço já reservado para o output head, a última camada que pontua os próximos tokens possíveis. O que você paga em troca são leituras extras no SSD — e é o SSD que passa a definir parte do desempenho.

Quanto ganha em velocidade e precisão — e em qual setup

Os números que valem são os do próprio paper, medidos pelos autores e ainda sem reprodução independente. Todos vêm de um NVIDIA DGX Spark com 128 GB de memória unificada a 273 GB/s, rodando o fork deles no llama.cpp, com prompt de 8 mil tokens, três execuções por ponto após um aquecimento e cache de prompt desligado.

Tempo até o primeiro token: de 12,27 s para 6,90 s no prompt de 8K, ou 1,78x mais rápido. Entre prompts de 4K a 32K, o ganho variou de 1,38x a 1,78x.

MMLU-Pro: o par decodificador congelado mais pré-processador NVFP4 subiu de 29,04% para 61,54%.

MMMU-Pro (avaliação com imagens): de 24,39% para 59,65%.

A explicação dos autores para os 32 pontos: com o escritor congelado em 1 bit, boa parte do dano acontecia durante a leitura. Um prompt lido com precisão limpa faz o mesmo decodificador 'desajeitado' acertar muito mais. O paper também mostra o reverso: comprimir só a escrita perde duas a quatro vezes mais precisão do que comprimir só a leitura na maioria dos modelos, e até sete vezes no Gemma 3 1B.

Um detalhe honesto: o IQ1_S já é compressão quase no limite. Em 2 bits, os ganhos de precisão relatados caem para algo entre 4,5 e 7,4 pontos, dependendo do benchmark. Quanto mais comprimido está o seu decodificador, maior o retorno de um leitor limpo.

Quais são as limitações e requisitos de hardware

A técnica tem limites concretos, e o próprio paper os lista. Antes de testar, confira se o seu caso se encaixa neles.

GPU Blackwell obrigatória: o pré-processador lançado exige um chip GB10 (como o do DGX Spark) ou uma placa da série RTX 50. Em Mac ou em GPUs NVIDIA mais antigas, ele não ajuda.

Prompts curtos podem ficar mais lentos: abaixo de cerca de 8 mil tokens no DGX Spark, a computação não consegue esconder o tempo de streaming do SSD. O paper indica que o break-even fica em torno de 8K para os modelos Qwen3, e que abaixo de 4K as medições nem existem — não presuma ganho.

Decodificadores compatíveis: quatro checkpoints da Unsloth, IQ1_S, IQ1_M, IQ2_XXS e IQ2_S.

Modelos mixture-of-experts não são cobertos: os autores afirmam que o ODP não transpõe de forma limpa para essa arquitetura.

Chat multi-turno não foi testado: decodificador e pré-processador mantêm notas separadas sobre a conversa (o KV cache de cada um), e os autores marcam um possível descompasso entre elas como não avaliado. Batch alto também ficou de fora da avaliação.

Outra lacuna prática: o paper não diz qual SSD foi usado nem a taxa de leitura. Pela lógica do próprio método, um drive mais lento empurraria o ponto de equilíbrio para prompts ainda mais longos.

Para quem a técnica vale a pena hoje

Vale a pena se, e somente se, você soma três condições no mesmo setup: roda um modelo denso local em GPU Blackwell, usa um dos decodificadores de 1 ou 2 bits da Unsloth e cola regularmente prompts de 8 mil tokens ou mais. O Qwen3 denso de 27B, distribuído sob licença Apache 2.0 com contexto nativo de 262.144 tokens, é o alvo declarado dos autores.

O cenário ideal é o paste longo: um documento inteiro, uma pilha de logs, um pedaço grande do seu codebase. Nesses casos, o paper relata primeiro token quase duas vezes mais rápido e um modelo consideravelmente mais preciso, no mesmo hardware.

Pule a técnica por enquanto se você usa Mac, GPU mais antiga ou um modelo MoE. E pule também se seus prompts são curtos — para um 'conserte esse typo', esperar o SSD despejar 12,8 GiB é um jeito elaborado de perder tempo. Uma exceção: se você já vive no 1 bit e aceita pesos extras em troca de um salto grande de precisão, o teste pode compensar mesmo com prompts medianos.

A pergunta em aberto que define o futuro da ideia é o chat longo. Turno após turno, leitor e escritor mantêm registros próprios da conversa, e ninguém mediu ainda se esses registros divergem. Esse é o experimento que faltaria para transformar o ODP de truque de documento longo em ferramenta do dia a dia.

Perguntas frequentes

A quantização disagregada deixa a geração mais rápida depois do primeiro token? Não. O decodificador de 1 bit continua o mesmo, e o paper afirma que a velocidade de streaming de tokens não muda. O ganho está todo na espera antes da primeira palavra.

Funciona em Mac ou em GPU mais antiga? Não com o pré-processador lançado. Ele exige GPU Blackwell, seja um GB10 (DGX Spark) ou uma placa da série RTX 50 da NVIDIA.

Preciso retreinar o modelo? Não. O decodificador de 1 bit é usado exatamente como foi distribuído; o pré-processador NVFP4 é uma segunda cópia treinada apenas para a leitura do prompt.

Os números de 1,78x e 61,54% são independentes? Não. São medições dos próprios autores em um DGX Spark, com três execuções por ponto e cache de prompt desligado. Nenhuma reprodução independente foi publicada até outubro de 2026.

Posso usar com prompts curtos? Desaconselhável. No DGX Spark, o break-even fica perto de 8 mil tokens, e o paper admite que prompts curtos podem sair mais lentos porque a computação não esconde o carregamento do SSD.

Source video