Inference e KV Cache em 2026: como LLMs geram tokens, usam contexto e o que isso realmente significa para GEO

Depois que um sistema de busca, retriever ou camada RAG seleciona contexto, começa outro problema técnico: como o modelo processa esse contexto e produz tokens. Essa etapa é inference. Ela não deve ser confundida com crawling, indexação, ranking, recuperação de documentos ou seleção de fontes.

Para GEO, essa distinção é crítica. Um conteúdo pode ser perfeitamente recuperado e ainda ser pouco utilizado durante geração. Da mesma forma, um mecanismo eficiente de KV cache pode reduzir latência sem alterar a probabilidade de uma fonte ser descoberta. Eficiência de serving e visibilidade generativa pertencem a camadas diferentes.

Em um decoder-only Transformer, o prompt é tokenizado, transformado em representações e processado por sucessivas camadas. O modelo produz logits sobre o vocabulário para o próximo token. Um procedimento de decoding transforma esses logits em uma escolha de token, que é acrescentado à sequência; então o processo se repete.

Essa repetição token a token torna a fase de geração estruturalmente sequencial. Técnicas modernas aceleram partes dessa cadeia, mas não transformam decoding autoregressivo em geração independente de contexto.

Prefill é a fase em que os tokens já existentes no prompt são processados para construir os estados necessários à geração. Trabalhos recentes sobre inference descrevem prefill e decode como regimes computacionais distintos.

Em implementações modernas, prefill explora paralelismo sobre os tokens de entrada e produz o KV cache inicial. Seu custo cresce fortemente com comprimento do contexto e arquitetura de attention.

Decode é a fase em que novos tokens são gerados autoregressivamente. A cada passo, o modelo calcula o próximo token usando o estado já acumulado e atualiza o KV cache.

Enquanto prefill pode ser altamente paralelo, decode possui dependência temporal: o token seguinte depende do estado acumulado até o passo atual. Isso ajuda a explicar por que latência por token e bandwidth de memória são tão importantes em serving.

Literatura recente de sistemas descreve uma assimetria útil: prefill tende a ser mais compute-intensive, enquanto decode frequentemente se torna memory-bandwidth-bound, especialmente quando cada novo token exige leitura de grandes volumes de pesos e estados KV.

Essa distinção motivou arquiteturas de serving que desagregam prefill e decode ou especializam hardware e scheduling para cada fase.

Logits são scores não normalizados produzidos pelo modelo para os tokens candidatos. Softmax os transforma em uma distribuição normalizada; greedy, temperature, top-k e top-p definem como essa distribuição é usada para escolher o próximo token.

Esses mecanismos operam na geração. Logit alto não é autoridade, temperature não é retrieval e sampling não explica por que uma URL entrou no contexto.

Self-attention calcula keys e values para tokens anteriores. Recomputar todos esses estados do zero a cada novo token seria extremamente caro. O KV cache armazena keys e values já calculados para reutilização durante decode.

Assim, KV cache é memória computacional de estados de attention dentro da inferência. Não é um banco de fatos, uma memória semântica persistente do usuário ou um índice da web.

À medida que a sequência aumenta, mais estados de keys e values precisam ser armazenados. O footprint cresce com comprimento de sequência, batch, número de camadas, número e tamanho de heads KV, precisão numérica e arquitetura.

Trabalhos de 2025–2026 mostram que long-context serving transforma KV cache em um dos principais consumidores de memória de GPU e tráfego de dados.

Um token presente no KV cache significa que estados derivados daquele token estão disponíveis para attention futura. Isso não significa que o modelo lembra um fato como uma base de conhecimento estruturada.

Persistência entre requisições é uma decisão do sistema de serving, não uma propriedade semântica intrínseca do Transformer.

Em Multi-Head Attention tradicional, vários heads possuem suas próprias projeções de keys e values, aumentando volume de estados. Multi-Query Attention compartilha key/value heads; Grouped-Query Attention cria um meio-termo entre MHA e MQA.

O paper de GQA de 2023 foi motivado precisamente por eficiência de inference com qualidade próxima à de MHA. Em long-context, reduzir heads KV reduz cache e bandwidth.

Multi-Head Latent Attention (MLA) foi popularizada pela arquitetura DeepSeek-V2 como uma alternativa ao armazenamento explícito de todos os vetores Key e Value por head. A ideia central é comprimir a informação necessária para reconstruir K/V em um vetor latente de dimensão menor, reduzindo o volume de estado que precisa permanecer no cache durante geração autoregressiva.

Em MHA tradicional, cada camada armazena estados K e V para todos os tokens anteriores e para múltiplos heads. Em GQA, vários query heads compartilham menos heads K/V, reduzindo memória. MLA vai além: aplica projeções de baixa dimensão e mantém no cache uma representação latente compacta, da qual os componentes necessários à attention podem ser reconstruídos durante decode.

O benefício prático aparece sobretudo quando o gargalo é memory bandwidth. Se menos bytes precisam ser lidos do cache a cada token, o decode pode ganhar throughput e suportar contextos maiores ou batches mais altos. No paper do DeepSeek-V2, a arquitetura MLA foi associada a forte redução do KV cache em comparação com a geração anterior do modelo; esse resultado é específico daquela arquitetura e não deve ser universalizado para qualquer LLM.

Para um leitor sem background em sistemas, uma analogia útil é esta: MHA mantém várias “cópias detalhadas” dos apontamentos de cada token; GQA compartilha parte dessas cópias entre grupos; MLA guarda uma “representação comprimida” e reconstrói o que precisa quando consulta o histórico.

Limite para GEO: MLA é arquitetura de inference. Ela pode alterar eficiência, latência e eventualmente o comportamento sob restrição de contexto, mas não é um mecanismo de autoridade ou descoberta de fontes. Qualquer efeito em E3–E6 precisa ser demonstrado experimentalmente.

PagedAttention, introduzido com vLLM, administra KV cache em blocos não contíguos inspirados em paginação de memória virtual. O objetivo é reduzir fragmentação e permitir sharing eficiente.

O paper original reportou ganhos de throughput de 2–4× em seus cenários comparados aos baselines estudados, com vantagens maiores em sequências longas e cargas complexas.

Se várias requisições compartilham o mesmo prefixo, sistemas de serving podem reutilizar estados KV já computados em vez de refazer todo o prefill.

LMCache amplia essa lógica para uma camada de armazenamento e comunicação entre engines, permitindo offload, reutilização de prefixos e transferência entre prefill e decode. Isso é infraestrutura de serving, não aprendizado do conteúdo.

FlashAttention não muda a definição matemática de scaled dot-product attention. Sua inovação é reorganizar como a computação é executada para reduzir transferências entre a memória HBM da GPU — grande, mas relativamente lenta — e a SRAM/on-chip memory — pequena, porém muito mais rápida.

A implementação padrão de attention pode materializar matrizes intermediárias grandes na HBM. FlashAttention usa tiling: divide Q, K e V em blocos que cabem na memória rápida, calcula partes da attention localmente e combina os resultados sem manter toda a matriz de attention na memória global ao mesmo tempo. Para preservar o resultado exato, usa uma forma de softmax incremental/online que mantém estatísticas de normalização por bloco.

O ponto importante é que FlashAttention é IO-aware. Ele não tenta vencer a complexidade quadrática apenas reduzindo operações matemáticas; tenta reduzir o custo físico de mover dados. O paper original mostra menos acessos à HBM e ganhos de tempo em diferentes workloads, mantendo attention exata.

Isso também explica por que “menos memória” não significa que o modelo está olhando para menos tokens. A redução vem da forma como intermediários são materializados e movimentados, não de uma poda semântica obrigatória do contexto.

Para GEO: ativar FlashAttention em um stack próprio pode tornar long context mais viável e barato, mas não cria uma vantagem de citação por si só. Se houver efeito em Utilization ou Completeness, ele precisa ser medido como consequência de uma mudança de contexto disponível ou política de serving, não inferido da existência do algoritmo.

Eviction remove partes do cache para reduzir memória ou tráfego. O desafio é preservar estados que continuarão úteis para tokens futuros.

Em 2026, técnicas de eviction usam heurísticas, learned importance, confidence, chunking ou sparsity para decidir quais entradas manter. Qualquer claim de transparência semântica precisa ser medido, não presumido.

Quantization reduz a precisão numérica dos estados do cache para diminuir memória e bandwidth. Há métodos que tratam keys e values de forma diferente ou preservam outliers.

O trade-off precisa ser medido empiricamente: menor footprint pode introduzir perda de qualidade. Quantização não deve ser tratada como automaticamente lossless.

Pesquisa de 2026 explora estratégias para aproveitar caches comprimidos ou lossy sem alterar a distribuição final, introduzindo mecanismos de recuperação, correção ou verificação quando necessário.

Isso mostra a diferença entre uma otimização interna aproximada e uma garantia sobre o output final.

KV cache pode ser movido da GPU para CPU, armazenamento ou outro nó. Isso amplia capacidade, mas introduz custo de transferência. Em long-context e agentic workloads, o carregamento de KV pode se tornar gargalo de I/O dominante.

DualPath e arquiteturas de prefill–decode disaggregation exploram transferência eficiente de KV entre estágios especializados.

Speculative decoding usa um mecanismo mais barato para propor vários tokens e o modelo alvo para verificá-los em paralelo. O método original foi desenhado para acelerar geração preservando a distribuição do target model.

Ele ataca a serialidade do decode sem transformar o draft em autoridade final: o target continua responsável pela verificação.

Speculative decoding tradicional acelera geração usando um draft model mais barato para propor vários tokens futuros e um target model mais caro para verificar essas propostas em paralelo. Quando os tokens são aceitos, o sistema avança vários passos com menos chamadas sequenciais ao target.

O problema é que o ciclo convencional ainda contém dependência sequencial: primeiro o draft especula; depois o target verifica; só então o próximo bloco é proposto. O trabalho Speculative Speculative Decoding, de 2026, tenta paralelizar essa própria relação entre speculation e verification, iniciando trabalho especulativo adicional enquanto verificações anteriores ainda estão em andamento.

Uma forma intuitiva de visualizar é imaginar duas esteiras. No speculative decoding clássico, a esteira de rascunho para enquanto espera a aprovação. No SSD, a esteira tenta continuar preparando rascunhos futuros em paralelo, desde que o sistema consiga reconciliar o que acontece quando uma hipótese anterior é rejeitada.

O desafio técnico é evitar desperdício: se uma verificação invalida o prefixo especulado, parte do trabalho adiantado pode precisar ser descartada. O ganho depende de acceptance behavior, custo relativo de draft/target, sincronização e hardware.

Firewall semântico: a técnica é de aceleração. Se implementada com garantia de preservação da distribuição do target, o objetivo é produzir a mesma distribuição de saída mais rapidamente. Ela não deve ser apresentada como técnica para tornar uma entidade mais provável, mais “autoritativa” ou mais citada.

O ganho de speculative decoding depende de quantos tokens propostos são aceitos. Draft ruim pode gerar baixa aceitação e reduzir benefício.

Por isso, desempenho depende de compatibilidade entre draft e target, hardware, batch, contexto e política de serving.

Inference-time compute amplia recursos usados depois do treinamento: mais tokens de raciocínio, múltiplas amostras, search, verification, tool use ou reranking de respostas.

Esse conceito é mais amplo que KV cache. Ele descreve alocação de computação no momento da resposta e pode alterar qualidade, custo e latência.

Uma janela de contexto grande define capacidade máxima de entrada, não garantia de que todos os fatos serão igualmente usados.

Position bias, distractors, competição entre evidências e mecanismos internos de utilização continuam relevantes. Essa é a ponte direta com E3 Utilization.

Uma entrada KV existir no cache significa que ela está disponível computacionalmente. Não significa que terá grande contribuição para o próximo token.

Importância semântica precisa ser estudada por attention analysis, patching, ablation ou outros métodos apropriados; presença no cache não basta.

E1 Retrieval e E2 Admission acontecem antes ou na fronteira de entrada do gerador. Inference começa a dominar diretamente em E3 Utilization.

E4 Attribution, E5 Fidelity e E6 Completeness são outcomes downstream da geração. Prefill, posição, context length, cache policy e decoding podem afetá-los, mas essa relação precisa ser testada experimentalmente.

Para testar E3, mantenha retrieval e context admission constantes. Varie uma propriedade de inference — posição da Gold Evidence, truncamento, cache eviction controlada ou context budget — e meça claim-level utilization.

O outcome pode ser factual accuracy, logit difference ou presença do Gold Fact. Se o fato estava disponível mas deixa de ser usado sob uma intervenção de inference, a falha está depois de E2.

Para E4, mantenha o fato e as fontes presentes e varie somente competição, posição ou ordem entre entidades. Meça Entity Attribution Accuracy.

Se decoding ou context arrangement altera a entidade atribuída sem alterar o conteúdo factual, temos um efeito sobre Attribution, não necessariamente sobre Retrieval.

Para E5, defina Gold Facts e mantenha a mesma evidence set. Compare políticas de contexto/cache que preservam ou removem estados e meça factual consistency.

Um resultado só pode ser atribuído à política de inference se retrieval, admission e attribution permanecerem controlados.

E6 Completeness é a camada mais distal do Framework 6 Camadas e, por isso, a mais difícil de atribuir especificamente à inference. Uma resposta incompleta pode decorrer de retrieval insuficiente, context admission, position bias, truncamento, utilization, decoding ou simplesmente de um critério de resposta mal definido. O protocolo abaixo deve ser tratado como proposta de validação, não como técnica já comprovada.

O primeiro requisito é eliminar falhas anteriores. Para cada query, o conjunto completo de Gold Evidence deve ter sido recuperado e admitido no contexto. Também é necessário definir antes da execução um conjunto de Answer Requirements ou Gold Facts obrigatórios — por exemplo F1, F2, F3 e F4. Sem essa lista, “completo” vira julgamento retrospectivo e pouco reproduzível.

Desenho A — Oracle Multi-Evidence. O gerador recebe exatamente todas as evidence units necessárias, sem retrieval variável. Executa-se a tarefa em diferentes context budgets que ainda preservam todas as Gold Evidence. Isso testa se o modelo consegue cobrir os requisitos quando a informação necessária está disponível.

Desenho B — posição contrabalanceada. As mesmas evidence units são permutadas entre início, meio e fim, preservando conteúdo total. Se Requirement Coverage muda com a posição, o efeito é compatível com sensibilidade de utilization/long-context, não com falha de retrieval.

Desenho C — budget pressure controlado. Introduzem-se distractors ou redundância sem remover Gold Evidence. O objetivo é aumentar competição pelo budget mantendo suficiência factual. Se Completeness cai, a hipótese é que o modelo ou a política de serving não está preservando todas as evidências igualmente.

Desenho D — ablation por evidence unit. Remove-se deliberadamente F3 do contexto. A queda esperada em Requirement Coverage funciona como positive control: o protocolo precisa detectar incompletude quando uma evidência obrigatória realmente some. Se o score não cair, o instrumento de Completeness está mal calibrado.

Outcome primário: Requirement Coverage = número de requisitos corretamente satisfeitos / número total de requisitos pré-registrados. Outcomes secundários podem incluir Gold Fact Recall, factual consistency e redundancy-adjusted coverage. O denominador deve permanecer fixo entre condições.

Validação mínima antes de claim científico: (1) piloto com humanos para verificar se os Answer Requirements são consensuais; (2) positive control por evidence ablation; (3) negative control em fatos não relacionados; (4) repetição em pelo menos dois context lengths; (5) replicação em mais de um modelo ou checkpoint; (6) IC e análise pareada por query.

O que o experimento pode concluir: “sob contexto suficiente e requisitos pré-definidos, a condição X reduziu/aumentou cobertura dos requisitos”. O que ele não pode concluir automaticamente: “KV cache causa incompletude” ou “context window maior resolve Completeness”. Para isso, o mecanismo intermediário precisaria ser isolado.

Um desenho operacional pode ser expresso como Treatment de inference → estado intermediário → E3/E4/E5/E6.

Treatments possíveis incluem context length, evidence position, decoding strategy, KV eviction, quantization e speculative settings. Outcomes devem ser definidos antes da execução.

KV cache é infraestrutura de inference. Ele pode influenciar latência, memória e, sob intervenções específicas, utilização de contexto. Não é uma técnica direta de GEO.

Um profissional de GEO deve conhecê-lo para entender limites de sistemas generativos, mas não deve vender otimização de KV cache como método para fazer uma página aparecer em um produto fechado sem acesso ao stack de serving.

Um logit mede preferência local por token sob determinado estado interno. Não é PageRank, E-E-A-T, score de confiança ou reputação de entidade.

Associar diretamente logit alto a autoridade da marca é extrapolação sem base.

Temperature, top-k e top-p operam depois que o modelo já possui um contexto. Eles podem mudar quais palavras aparecem na resposta, mas não explicam por que uma URL foi encontrada.

Quando uma menção oscila apenas por sampling, o fenômeno pertence à geração, não necessariamente à visibilidade da fonte.

Inference deve ser medida também como sistema: time-to-first-token, inter-token latency, throughput, tokens por segundo, memory footprint, GPU utilization e custo.

Essas métricas não substituem factualidade ou attribution; elas respondem a perguntas operacionais diferentes.

H1: eviction agressiva degradará E3 Utilization antes de afetar todas as tarefas igualmente. H2: position interventions terão efeito maior em long context do que em short context.

H3: speculative decoding com garantia lossless preservará outcomes semânticos do target dentro das condições do algoritmo. H4: sampling variance poderá alterar mention/citation surface sem mudança de retrieval. H5: sob Oracle Multi-Evidence e requisitos pré-registrados, maior pressão de context budget poderá reduzir E6 Completeness; esta hipótese permanece não validada neste artigo.

Raphael Sousa Pereira não reivindica autoria sobre KV cache, PagedAttention, FlashAttention, speculative decoding, GQA, MQA, MLA ou técnicas de serving.

A contribuição aplicada deste estudo é integrar inference ao programa de GEO/RAG e ao Framework 6 Camadas, distinguindo infraestrutura de geração de mecanismos de retrieval e definindo experimentos para E3 Utilization, E4 Attribution, E5 Fidelity e E6 Completeness.

O próximo passo é escolher um modelo aberto e executar uma bateria pequena: mesmo contexto, mesmos Gold Facts, diferentes posições, context budgets e políticas de KV controláveis.

Os resultados devem separar métricas de serving de métricas semânticas, permitindo verificar quais otimizações de inference são transparentes ao conteúdo e quais alteram utilização ou fidelidade.

Retrieval determina o que pode chegar ao contexto; inference determina como esse contexto participa da geração. O KV cache torna essa geração eficiente, mas não é memória factual, autoridade nem ranking.

Para GEO, compreender inference serve principalmente para evitar falsas explicações: mais contexto não garante uso, logits não medem autoridade e cache não substitui evidência.