Pare de pagar para armazenar embeddings: um guia de quantização assimétrica para CTOs

Você está pagando para armazenar ar. Um embedding float32 de 1.536 dimensões tem ~6 KB. Com 50 milhões de itens, isso dá 300 GB de vetores brutos — antes da sobrecarga de índice e das réplicas. A maioria das equipes então adiciona um grafo HNSW em RAM para ganhar velocidade, inflando a memória para as altas centenas de gigabytes. As faturas mensais de cloud acompanham. Enquanto isso, resultados recentes em quantização assimétrica mostram que você pode reduzir esse footprint em 90–97% com qualidade de recuperação quase sem perdas. Tradução: menos máquinas, mais baratas; cold starts mais rápidos; e a opção de rodar em CPUs de prateleira ou até na borda.

Isto não é curiosidade de pesquisa. Em 2026, está pronto para produção com bibliotecas maduras como FAISS e ScaNN, e com suporte nos sistemas vetoriais populares. Se você mantém um sistema de RAG, busca por similaridade, recomendações ou deduplicação em escala, a quantização assimétrica (AQ) deveria entrar já no seu roadmap.

O que é, de fato, a quantização assimétrica (e por que funciona)

Quantização comprime vetores float de alta dimensionalidade em códigos compactos. Com quantização assimétrica, você mantém a consulta em float, mas armazena os vetores do banco como códigos comprimidos e, então, calcula as distâncias usando o cálculo de distância assimétrico (ADC). Como a consulta não é quantizada, você evita o maior precipício de acurácia e ainda colhe quase todo o ganho de armazenamento e de largura de banda.

Os cavalos de batalha são:

• Product Quantization (PQ): Divide um vetor de dimensão D em m subvetores; aprende um pequeno codebook por subespaço (por exemplo, 256 centróides = 8 bits). Um vetor vira m bytes de códigos. Configurações típicas: D=1.536, m=96, 8 bits → 96 bytes por vetor.
• Optimized PQ (OPQ): Aprende uma rotação do espaço para espalhar o sinal de forma mais uniforme pelos subespaços, melhorando o recall para o mesmo tamanho de código.
• IVF‑PQ: Um índice em duas etapas: o quantizador grosseiro (IVF) estreita a busca para alguns clusters; dentro de cada um, o PQ comprime os resíduos. Isso produz latência amigável a CPU em escala massiva.

Resultados públicos recentes mostram até ~97% de redução de armazenamento com perda mínima de recall em tarefas padrão de recuperação. Na prática, vemos regularmente 90–95% de redução com 0,95–0,99 de recall@10 em relação ao baseline em float, se você:

• Treinar OPQ com dados suficientes (≥ 1–5 milhões de amostras representativas).
• Ajustar a contagem de listas do IVF e o número de probes ao seu orçamento de latência.
• Usar reranking (por exemplo, dot‑product ou um cross‑encoder) nos candidatos top‑K.

Por que isso importa para o seu TCO

Vamos usar uma configuração comum e sem firulas para ilustrar a conta:

• Embedding: float32 de 1.536 dimensões (≈ 6 KB/vetor).
• Corpus: 50 milhões de itens → 300 GB de vetores brutos.
• Sobrecarga do índice HNSW: frequentemente 1–2× o tamanho do vetor, dependendo de M/ef. Assuma 1,5× → 450 GB em RAM.
• HA/fator de replicação de 2–3× entre nós → 900–1.350 GB de footprint efetivo.

Resultado: você aluga várias instâncias com 256–512 GB de RAM (CPU ou GPU) o ano todo para manter latência abaixo de 100 ms sob carga. Dependendo da região e da geração, isso dá facilmente $6k–$12k/mês só de compute, muitas vezes mais do que a conta de armazenamento do banco de dados vetorial.

Agora inverta o desenho:

• PQ com m=96, 8 bits → ~96 bytes/vetor (mais um pequeno metadata do IVF). Isso dá ~4,8 GB para 50 milhões de vetores (códigos brutos), tipicamente 10–20× menor do que o baseline em float quando você inclui as sobrecargas do índice.
• Use IVF‑PQ em CPU. Mantenha os códigos em NVMe; faça cache das listas quentes e das LUTs (lookup tables) em memória. Com tuning sensato, espere p95 abaixo de 20–40 ms em CPUs modernas com 95% de recall@10 em escala de 50–200 milhões.
• O footprint de compute cai para uma ou duas instâncias de 64–128 GB por réplica, muitas vezes $1,5k–$3k/mês por nó. Cold starts ficam mais rápidos; rebuilds não exigem volumes efêmeros de classe petabytes.

Nem todo workload verá exatamente essa curva, mas a direção é consistente: PQ tira você do bound de memória e leva para designs equilibrados entre cache e storage, que são mais baratos, elásticos e fáceis de operar entre regiões (ou on‑prem) sem escassez de GPU.

Quando você deve (e quando não deve) usar quantização assimétrica

Adote AQ se você marcar a maioria destes itens:

• Corpus ≥ 10 milhões de itens ou busca multi‑tenant com muitos tenants ativos.
• SLOs de latência ≥ 20 ms p95 para a etapa vetorial (você pode baixar mais com cache e menos probes).
• Modelo de embedding estável por pelo menos 3–6 meses. Trocas frequentes de modelo aumentam o custo de manutenção dos codebooks.
• Distância por dot‑product ou L2. Se você precisa de uma métrica específica, verifique o suporte da biblioteca.
• Etapa de reranking disponível para recuperar qualidade no long tail (por exemplo, top‑200 candidatos → cross‑encoder@K=50).

Pense duas vezes se:

• Você roda corpora pequenos (≤ 1 milhão) que já cabem em RAM com HNSW a custo irrisório.
• Seu SLO é de latência ultra‑baixa (por exemplo, 5 ms p95) e você pode bancar GPUs/índices em RAM afinados à mão.
• Seus embeddings mudam semanalmente e você não pode arcar com rebuilds de índice duplos.

A arquitetura: IVF‑PQ com ADC, mais reranking

Para a maioria dos CTOs, um padrão seguro em 2026 é assim:

1. Partição grosseira (IVF): Treine k‑means com k entre 16k–262k, dependendo do tamanho do corpus. Regra de bolso: comece em k ≈ sqrt(N) e refine conforme probes/latência.
2. Codificação residual com OPQ+PQ: Aprenda uma rotação OPQ; treine PQ sobre os resíduos com m escolhido de modo que m bytes/vetor atinja sua meta de armazenamento. Comum: m=64–128 com códigos de 8 bits.
3. Cálculo de distância assimétrico: Mantenha a consulta em float; para cada lista sondada, construa uma tabela de consulta (LUT) de distâncias entre a consulta e cada codebook dos subquantizadores. Distâncias ADC se reduzem a somas em LUT, que são amigáveis à cache em CPUs.
4. Conjunto de candidatos + rerank: Retorne 500–2.000 candidatos do ADC; rerankeie com os floats originais se você guardar um pequeno cache de floats para itens de cabeça, ou use um cross‑encoder para precision@K.

Esse padrão está implementado no FAISS (IndexIVFPQ, IndexIVF{HNSW,PQ}) e no fluxo de particionamento + hashing assimétrico do ScaNN. Muitos bancos vetoriais expõem isso por baixo dos panos. Você não precisa reescrever seu stack.

Um plano concreto de implantação em 60–90 dias

Dias 0–15: baseline e meta

• Defina seu critério: Fixe um benchmark representativo: 10–20 consultas reais por tópico de cabeça, 10k–100k pares anotados, avaliação como recall@10 e nDCG@10.
• Registre os custos atuais: Footprint de RAM do HNSW (ou seu ANN atual), SKUs das instâncias, QPS, latência p95/p99 e $/QPS mensal.
• Escolha um orçamento de risco: por exemplo, ≥ 0,97 de recall@10 do baseline e ≤ 10 ms extras de p95 para a etapa vetorial. Coloque por escrito.

Dias 15–45: treinar, construir, ajustar

• Amostre os dados de treino: 1–5 milhões de vetores cobrindo tenants/locais; mantenha um conjunto de validação separado.
• Treine OPQ e IVF: Comece com OPQ m=96 (8 bits). Para IVF, inicie em k ≈ sqrt(N); teste nprobe de 10–200.
• Construa o IVFPQ: Armazene os códigos em NVMe; pré‑compute estatísticas por lista; habilite mmap quando houver suporte.
• Meça os trade‑offs: Varra m ∈ {64, 96, 128}, bits de código ∈ {6, 8}, nprobe ∈ {8, 16, 32, 64, 128}. Plote recall vs p95 vs CPU%.
• Estratégia de rerank: Tente duas etapas: IVFPQ@1k → cross‑encoder@50 (ou dot‑product em float se você puder fazer cache dos floats para itens de cabeça). Valide o ganho em consultas de long tail.

Dias 45–75: shadow e segurança

• Dual‑run: Atenda usuários pelo caminho baseline; em paralelo, rode o caminho com PQ em shadow para 5–10% aleatórios do tráfego. Registre resultados intercalados para estimar recall online e deltas de CTR.
• Monitores de drift: Alerta para mudança na distribuição da similaridade do cosseno entre a consulta e o top‑K; é um indicador precoce de que seus codebooks estão envelhecendo.
• Plano de rebuild quente: Construa codebooks paralelamente toda semana; alterne o tráfego com uma feature flag. Mantenha os dois últimos codebooks ativos para rollback.

Dias 75–90: cutover e captura de custos

• Cutover gradual: 10% → 50% → 100% dos tenants. Mantenha o ANN baseline como fallback por uma janela definida.
• Dimensione certo as instâncias: Saia de 512 GB de RAM para 64–128 GB; escale horizontalmente por QPS, não por pressão de memória.
• Capture as economias: Acompanhe a redução de $/QPS. Na nossa experiência, um PQ bem ajustado pode cortar compute de busca vetorial em 2–5× e storage em 10–30× sem dano mensurável ao usuário.

Modos comuns de falha (e como evitá‑los)

• Treinar na distribuição errada: Seus codebooks aprendem o que você alimenta. Se você excluir certos idiomas, tenants ou modalidades, espere quedas de recall em produção. Correção: amostragem estratificada e re‑treinos periódicos.
• IVF subprovisionado: Poucas listas ou poucos probes sufocam o recall. Correção: aumente k ou nprobe; faça cache de LUTs e listas quentes; verifique afinidade NUMA.
• Pular o rerank com compressão alta: Abaixo de ~64–96 bytes/vetor, espere mais erro de aproximação. Correção: sempre rerankeie um pequeno conjunto de candidatos.
• Churn de modelo sem indexação dupla: Trocar o modelo de embedding invalida codebooks. Correção: mantenha dois índices completos; reconstrua em background; faça cutover com flags.
• Desalinhamento MIPS vs L2: Se você usa similaridade por dot‑product, garanta que seu índice e biblioteca otimizem para MIPS (maximum inner product search). Alguns stacks convertem MIPS→L2 com truques (por exemplo, aumento de norma). Verifique.

Escolhas de ferramentas que não envelhecem mal

• FAISS: Testado em batalha, GPU e CPU, suporte profundo a PQ/IVF, híbridos com HNSW. Use para máximo controle e portabilidade.
• ScaNN: Forte em performance de CPU com particionamento + hashing assimétrico; bons padrões.
• Bancos vetoriais: Milvus, Qdrant, Weaviate e serviços comerciais expõem IVF‑PQ/HNSW‑PQ. Cuidado com limites ocultos de configuração (por exemplo, tamanhos máximos de codebook) e recalls opacos.
• Rerankers: Para consultas multilíngues ou muito específicas de domínio, um cross‑encoder pequeno (por exemplo, classe MiniLM) em K=50–200 costuma recuperar os últimos 1–2 pontos de precisão por alguns milissegundos.

Um modelo de custos simples para explicar ao financeiro

Apresente o business case claramente:

• Baseline: 3× r5b.16xlarge (512 GB) para HNSW + 2× m6i.8xlarge para API + replicação de storage → $8k–$14k/mês all‑in, além de taxas de serviços de banco vetorial gerenciado.
• Com PQ: 2× m7i.4xlarge (64 GB) para IVFPQ + 2× m6i.8xlarge para API → $3k–$6k/mês, armazenamento 10–30× menor. Mesmo tráfego, mesmas métricas de usuário.
• Payback: 30–60 dias incluindo o tempo pontual de engenharia, assumindo redução de compute de 2–5× e rework moderado de infraestrutura.

Mesmo que seus SKUs e preços exatos variem, o financeiro vai entender a migração de réplicas limitadas por memória para nós balanceados em storage com os mesmos (ou melhores) SLOs.

E as GPUs?

GPUs brilham quando você precisa de latência ultra‑baixa em QPS muito alto ou quando você já está em GPU nas etapas upstream. Mas com IVFPQ+ADC, CPUs modernas alcançam p95 abaixo de 40 ms para dezenas a centenas de milhões de vetores. Se você mantiver GPUs, ainda pode quantizar para encaixar corpora maiores na memória do device ou para reduzir a banda de PCIe.

Edge e on‑device: o dividendo da opcionalidade

Compressão é uma escolha de arquitetura, não só um hack de custo. Com 96 bytes/vetor, um índice de 5 milhões de itens tem ≈ 480 MB de códigos. De repente:

• Replicação multi‑região vira algo razoável sem dramas de transferência de dados entre regiões.
• Implantações privadas on‑prem em contas reguladas cabem em 1–2 servidores de prateleira.
• Busca on‑device ou no navegador para corpora pequenos (≤ 500 mil) é viável com WASM ou bibliotecas de NN mobile, abrindo novas superfícies de produto com privacidade.

Ângulo nearshore no Brasil: quem vai fazer o tuning entediante?

Nada disso é ciência de foguetes, mas é trabalho de systems: amostragem, treinamento, construção de índices, instrumentação de observabilidade e iteração até a fronteira recall/latência ficar do seu jeito. É também o tipo de engenharia que fica para depois — até a conta chegar. Equipes nearshore com quilometragem em FAISS/ScaNN podem te entregar um rollout de PQ funcional em 6–10 semanas e, depois, voltar trimestralmente para re‑treinar codebooks e redimensionar clusters conforme seu corpus cresce. Você captura as economias sem montar uma equipe permanente de “infra vetorial”.

Compliance e privacidade: menor pode ser mais seguro

Códigos comprimidos vazam menos sinal bruto do que floats. Isso não é bala de prata de compliance, mas reduz a superfície de risco para exfiltração vetorial. Você ainda deve:

• Criptografar em repouso e em trânsito; gerenciar chaves por tenant.
• Remover PII antes de gerar embeddings quando viável.
• Construir pipelines de deleção que se propaguem tanto para caches de float quanto para os repositórios de PQ.

Uma nota sobre hype vs. realidade

O Hacker News está animado com “97% de redução de armazenamento com recuperação quase sem perdas”. Isso é alcançável — mas só se você tratar como recurso de produção, não como um truque de benchmark. A diferença está na sua amostragem, nos monitores de drift e em um reranker que cobre a última milha. Faça isso e você vai se perguntar por que um dia pagou para manter 600 GB de floats quentes em RAM.

Principais pontos

• A quantização assimétrica (IVF‑PQ + ADC) pode reduzir o armazenamento de vetores em 90–97% com 0,95–0,99 de recall@10 em relação aos baselines em float.
• Espere economia de compute de 2–5× e a migração de clusters limitados por RAM para nós em CPU, apoiados por NVMe.
• Adote com um plano de 60–90 dias: baseline, treine OPQ/PQ, rode em shadow com dual‑run e faça cutover com reranking.
• Fique atento ao drift de distribuição, a IVF subdimensionado e ao churn de modelo; corrija com amostragem estratificada, tuning de probes e rebuilds de índice duplo.
• A compressão destrava opções de edge/on‑prem e pode reduzir o risco de vazamento de dados em relação a floats brutos.