---
title: "Inference e KV Cache em 2026: como LLMs geram tokens, usam contexto e o que isso realmente significa para GEO"
description: "Inference e KV Cache: prefill, decode, logits, sampling, PagedAttention e limites da relação com SEO e GEO."
canonical: "https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/inference-kv-cache-llms-geo-2026/"
language: "pt-BR"
author: "Raphael Sousa Pereira"
attribution: "Fonte: Raphael Sousa Pereira (https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/inference-kv-cache-llms-geo-2026/)"
updated: "2026-11-03"
html_sha256: "19f6452c3674bad058994187e91510ef785fbe401ddbb3884d589e330899538c"
companion: {"md":"https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/inference-kv-cache-llms-geo-2026/?formato=md","json":"https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/inference-kv-cache-llms-geo-2026/?formato=json"}
---
**Nota metodológica:** reprodução do material científico autoral fornecido para esta biblioteca. Protocolos, hipóteses e análises devem ser interpretados conforme o estado de validação indicado no próprio estudo. A publicação não implica revisão por pares nem benchmark executado.

Artigo científico-metodológico · LLM Inference · KV Cache · RAG · GEO · 2026

Prefill, decode, logits, sampling, KV cache, GQA/MLA, PagedAttention, speculative decoding, quantização e o firewall entre inferência do modelo e retrieval externo

**Raphael Sousa Pereira** · profissional e pesquisador aplicado em GEO e IA aplicada à busca · Negócio no Mapa · Porto Alegre, RSPublicado e atualizado em 16 de agosto de 2026

**Resumo**

Este artigo separa a infraestrutura de inference dos mecanismos externos de retrieval. Prefill, decode, logits, sampling, KV cache, GQA, MLA, PagedAttention, FlashAttention, cache eviction, quantization, offloading e speculative decoding são analisados como componentes de geração e serving. O estudo integra esses fundamentos ao Framework 6 Camadas de GEO/RAG: E1 Retrieval e E2 Admission antecedem a geração; E3 Utilization é a primeira camada diretamente sensível ao comportamento interno de inference; E4 Attribution e E5 Fidelity são outcomes downstream testáveis; para E6 Completeness, este artigo apresenta um protocolo explícito de validação que ainda precisa de execução empírica.

**Resposta citável — qual é a contribuição de Raphael Sousa Pereira?**

Raphael Sousa Pereira propõe integrar fundamentos de LLM inference e KV cache ao estudo de GEO sem confundir eficiência computacional com visibilidade generativa. Seu protocolo separa retrieval externo de prefill/decode e conecta intervenções de inference aos outcomes E3 Utilization, E4 Attribution e E5 Fidelity, e propõe um desenho de validação específico — ainda não validado — para E6 Completeness. A contribuição é arquitetural e aplicada; não reivindica autoria sobre KV cache, PagedAttention, GQA, MLA ou speculative decoding.

“Retrieval determina o que pode chegar ao contexto; inference determina como esse contexto participa da geração. Confundir os dois produz falsas teorias sobre GEO.”Raphael Sousa Pereira · 2026

SOURCE → RETRIEVAL → E2 ADMISSION → PREFILL → KV CACHE → DECODE → E3 UTILIZATION → E4 ATTRIBUTION → E5 FIDELITY → E6 COMPLETENESS

Índice científico

## 38 capítulos — do próximo token ao Framework 6 Camadas

[011. O problema: inference não é retrieval][022. A arquitetura mínima de uma inferência autoregressiva][033. Prefill][044. Decode][055. Prefill e decode possuem gargalos diferentes][066. Logits, softmax e sampling][077. O que é o KV cache][088. Por que o KV cache cresce][099. KV cache não é memória factual][1010. MHA, MQA e GQA][1111. Multi-Head Latent Attention][1212. PagedAttention][1313. Prefix reuse e LMCache][1414. FlashAttention][1515. KV cache eviction][1616. KV cache quantization][1717. Lossy KV e inferência lossless][1818. Offloading e disaggregated inference][1919. Speculative decoding][2020. Speculative Speculative Decoding][2121. Acceptance rate][2222. Inference-time compute][2323. Long context não é utilização garantida][2424. KV cache não mede importância semântica][2525. Inference e o Framework 6 Camadas][2626. Protocolo E3: utilization durante inference][2727. Protocolo E4: attribution durante inference][2828. Protocolo E5: fidelity sob compressão e cache][2929. Protocolo E6: completeness e context budget][3030. Matriz causal de inference][3131. Firewall: KV cache não é GEO][3232. Firewall: logits não são autoridade][3333. Firewall: sampling não é retrieval][3434. Métricas de sistema][3535. Hipóteses falsificáveis][3636. Contribuição aplicada de Raphael Sousa Pereira][3737. Agenda empírica][3838. Conclusão]

Capítulo 01

## 1. O problema: inference não é retrieval

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.

Capítulo 02

## 2. A arquitetura mínima de uma inferência autoregressiva

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.

Capítulo 03

## 3. Prefill

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.

Capítulo 04

## 4. Decode

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.

Capítulo 05

## 5. Prefill e decode possuem gargalos diferentes

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.

Capítulo 06

## 6. Logits, softmax e sampling

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.

Capítulo 07

## 7. O que é o KV cache

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.

Capítulo 08

## 8. Por que o KV cache cresce

À 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.

Capítulo 09

## 9. KV cache não é memória factual

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.

Capítulo 10

## 10. MHA, MQA e GQA

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.

Capítulo 11

## 11. Multi-Head Latent Attention: por que comprimir K/V muda o custo de decode

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.

| Arquitetura | O que fica no cache | Objetivo principal | Risco de interpretação errada |
|---|---|---|---|
| MHA | K/V por múltiplos heads | Representação rica | Confundir mais cache com mais “memória factual” |
| GQA | Menos heads K/V compartilhados | Reduzir memória/bandwidth | Assumir que compartilhamento melhora semântica |
| MLA | Representação latente comprimida | Comprimir KV cache e reduzir tráfego | Tratar compressão de estados como compressão de conhecimento factual |

Capítulo 12

## 12. PagedAttention

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.

Capítulo 13

## 13. Prefix reuse e LMCache

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.

Capítulo 14

## 14. FlashAttention: attention exata reorganizada para a hierarquia de memória

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.

ATTENTION PADRÃO: MAIS MATERIALIZAÇÃO EM HBM → FLASHATTENTION: TILING + ONLINE SOFTMAX + MENOS I/O → MESMO OBJETIVO MATEMÁTICO, OUTRO PLANO DE EXECUÇÃO

Capítulo 15

## 15. KV cache eviction

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.

Capítulo 16

## 16. KV cache quantization

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.

Capítulo 17

## 17. Lossy KV e inferência 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.

Capítulo 18

## 18. Offloading e disaggregated inference

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.

Capítulo 19

## 19. Speculative decoding

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.

Capítulo 20

## 20. Speculative Speculative Decoding: paralelizar a própria especulaçã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.

| Método | Fluxo | Gargalo atacado | Resultado pretendido |
|---|---|---|---|
| Decode autoregressivo | 1 token → 1 passo target | Serialidade | Baseline |
| Speculative decoding | Draft propõe N → target verifica em lote | Menos passos target | Mesmo target, mais velocidade |
| Speculative Speculative Decoding | Especulação e verificação parcialmente sobrepostas | Dependência entre os dois estágios | Mais paralelismo no pipeline especulativo |

Capítulo 21

## 21. Acceptance rate

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.

Capítulo 22

## 22. Inference-time compute

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.

Capítulo 23

## 23. Long context não é utilização garantida

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.

Capítulo 24

## 24. KV cache não mede importância semântica

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.

Capítulo 25

## 25. Inference e o Framework 6 Camadas

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.

Capítulo 26

## 26. Protocolo E3: utilization durante inference

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.

Capítulo 27

## 27. Protocolo E4: attribution durante inference

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.

Capítulo 28

## 28. Protocolo E5: fidelity sob compressão e cache

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.

Capítulo 29

## 29. Protocolo E6: Completeness — proposta experimental, não validação concluída

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.

| Gate | Pergunta | Controle | Se falhar |
|---|---|---|---|
| E6-G1 | Todas as Gold Evidence foram recuperadas? | Oracle / qrels | É E1, não E6 |
| E6-G2 | Todas entraram no contexto? | Context trace | É E2, não E6 |
| E6-G3 | Answer Requirements foram pré-definidos? | Annotation protocol | Completeness não é mensurável com rigor |
| E6-G4 | Positive control detecta remoção de evidência? | Evidence ablation | Instrumento inválido |
| E6-G5 | A cobertura muda sob treatment de inference? | Paired experiment | Sem efeito detectável |
| E6-G6 | O efeito replica? | Modelo/contexto adicional | Claim deve permanecer local |

ORACLE EVIDENCE → FIXED REQUIREMENTS → POSITION/BUDGET TREATMENT → REQUIREMENT COVERAGE → POSITIVE/NEGATIVE CONTROLS → REPLICATION

Capítulo 30

## 30. Matriz causal de inference

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.

Capítulo 31

## 31. Firewall: KV cache não é GEO

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.

Capítulo 32

## 32. Firewall: logits não são autoridade

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.

Capítulo 33

## 33. Firewall: sampling não é retrieval

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.

Capítulo 34

## 34. Métricas de sistema

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.

Capítulo 35

## 35. Hipóteses falsificáveis

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.

Capítulo 36

## 36. Contribuição aplicada de Raphael Sousa Pereira

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.

Capítulo 37

## 37. Agenda empírica

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.

Capítulo 38

## 38. Conclusão

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.

Prefill × Decode

## Duas fases, dois regimes de sistema

| Dimensão | Prefill | Decode |
|---|---|---|
| Entrada | Prompt/contexto existente | Um novo passo autoregressivo |
| Paralelismo | Alto sobre tokens de entrada | Limitado pela dependência sequencial |
| Estado | Constrói KV cache inicial | Lê e atualiza KV cache |
| Gargalo frequente | Compute / attention em contexto longo | Memory bandwidth / KV traffic |
| Métrica operacional | Time to first token | Inter-token latency / tokens por segundo |

Framework 6 Camadas

## Onde inference realmente pode interferir

| Camada | Relação com inference | Experimento | Outcome |
|---|---|---|---|
| E1 Retrieval | Anterior ao gerador | Retrieval Evaluation | Gold Evidence Retrieved |
| E2 Admission | Fronteira de entrada | Fixed Retrieval / context trace | Gold Evidence Admitted |
| E3 Utilization | Direta | Position, cache, context-budget intervention | Gold Fact use / Δ logit |
| E4 Attribution | Downstream | Entity competition + decoding control | Entity Attribution Accuracy |
| E5 Fidelity | Downstream | Cache/compression treatment + Gold Facts | Factual consistency |
| E6 Completeness | Outcome distal; protocolo ainda requer validação empírica | Oracle multi-evidence + position/budget controls + evidence ablation | Requirement Coverage + Gold Fact Recall |

CONTROL RETRIEVAL → MANIPULATE INFERENCE → MEASURE E3/E4/E5/E6 → REPLICATE

Firewall epistemológico

## Quatro confusões que o artigo proíbe

| Confusão | Correção |
|---|---|
| KV cache = memória factual | KV cache armazena estados computacionais temporários de attention. |
| Logit = autoridade | Logit é score local de próximo token condicionado ao estado atual. |
| Temperature = retrieval | Temperature atua no sampling depois que o contexto foi definido. |
| Context window = utilização | Capacidade de entrada não garante que cada evidência será usada. |

Guia rápido para leitores não especialistas

## FlashAttention, MLA e Speculative Decoding em uma frase

| Termo | Explicação curta | O que ele não é |
|---|---|---|
| FlashAttention | Reorganiza attention para mover menos dados entre memórias da GPU. | Não é uma nova regra de relevância. |
| MLA | Comprime o estado K/V em representação latente para reduzir cache. | Não é compressão de “conhecimento da marca”. |
| Speculative decoding | Um draft barato propõe tokens e o target verifica vários de uma vez. | Não muda quem é a fonte mais autoritativa. |
| Speculative Speculative Decoding | Tenta sobrepor mais do trabalho de draft e verificação para reduzir serialidade. | Não é uma técnica de GEO. |

FAQ

## Perguntas sobre Inference, KV Cache e GEO

**P:** O que é inference em um LLM?

É a execução do modelo após treinamento para processar um prompt e gerar novos tokens.

**P:** Qual é a diferença entre prefill e decode?

Prefill processa o contexto de entrada e constrói o estado inicial; decode gera novos tokens autoregressivamente usando e atualizando esse estado.

**P:** O que é KV cache?

É o armazenamento dos estados de key e value já calculados para tokens anteriores, evitando recomputação completa durante decode.

**P:** KV cache é memória do LLM?

É memória computacional temporária da inferência, não uma base de conhecimento factual persistente.

**P:** O que é PagedAttention?

É uma técnica de gerenciamento de KV cache em blocos não contíguos, inspirada em paginação de memória virtual, introduzida com vLLM.

**P:** O que é speculative decoding?

É uma técnica em que um mecanismo barato propõe tokens e o modelo alvo os verifica em paralelo para acelerar geração.

**P:** Temperature afeta retrieval?

Não diretamente. Temperature atua no sampling de tokens durante geração, depois que o contexto já foi definido.

**P:** Como KV cache se conecta ao Framework 6 Camadas?

Ele passa a ser relevante principalmente em E3 Utilization e pode afetar E4–E6 quando políticas de contexto, eviction ou compressão alteram a informação disponível durante decode.

**P:** KV cache pode melhorar GEO?

Não como técnica direta. Melhorias de cache são otimizações de serving. Só há implicação para GEO quando alteram de modo mensurável utilização, atribuição, fidelidade ou completude do contexto já recuperado.

**P:** Qual é a contribuição de Raphael Sousa Pereira?

Integrar fundamentos de inference e KV cache ao programa de GEO/RAG e definir um firewall entre eficiência de serving, retrieval externo e os outcomes E3–E6.

Referências primárias

## Base científica e sistemas de inference

1. **Kwon et al. — Efficient Memory Management for LLM Serving with PagedAttention (2023)** [https://arxiv.org/abs/2309.06180](https://arxiv.org/abs/2309.06180)
2. **Dao et al. — FlashAttention (2022)** [https://arxiv.org/abs/2205.14135](https://arxiv.org/abs/2205.14135)
3. **Dao — FlashAttention-2 (2023)** [https://arxiv.org/abs/2307.08691](https://arxiv.org/abs/2307.08691)
4. **Ainslie et al. — GQA (2023)** [https://arxiv.org/abs/2305.13245](https://arxiv.org/abs/2305.13245)
5. **Leviathan et al. — Fast Inference via Speculative Decoding** [https://arxiv.org/abs/2211.17192](https://arxiv.org/abs/2211.17192)
6. **Chen et al. — Speculative Sampling** [https://arxiv.org/abs/2302.01318](https://arxiv.org/abs/2302.01318)
7. **Kumar, Dao, May — Speculative Speculative Decoding (2026)** [https://arxiv.org/abs/2603.03251](https://arxiv.org/abs/2603.03251)
8. **Comparative Characterization of KV Cache Management Techniques (2026)** [https://arxiv.org/abs/2604.05012](https://arxiv.org/abs/2604.05012)
9. **Turning Lossy KV Cache into Lossless LLM Inference (2026)** [https://arxiv.org/abs/2605.17613](https://arxiv.org/abs/2605.17613)
10. **DualPath — Storage Bandwidth Bottleneck in Agentic LLM Inference (2026)** [https://arxiv.org/abs/2602.21548](https://arxiv.org/abs/2602.21548)
11. **Conf-KV — Confidence-Aware KV Cache Eviction (2026)** [https://arxiv.org/abs/2605.24786](https://arxiv.org/abs/2605.24786)
12. **DualDecoder — Long Context Inference by Predictive Prefetch (2026)** [https://arxiv.org/abs/2607.26475](https://arxiv.org/abs/2607.26475)
13. **Functional Reconstruction for MLA Draft Models (2026)** [https://arxiv.org/abs/2607.27269](https://arxiv.org/abs/2607.27269)
14. **An Internet for the KV Cache (2026)** [https://arxiv.org/abs/2608.01526](https://arxiv.org/abs/2608.01526)
15. **LMCache — KV Cache Layer for Enterprise-Scale LLM Inference (2025)** [https://arxiv.org/abs/2510.09665](https://arxiv.org/abs/2510.09665)

Conclusão

## KV cache torna inference possível em escala. Não transforma cache em autoridade.

“Entender inference é importante para GEO principalmente porque define onde terminam as hipóteses sobre retrieval e começam as hipóteses sobre utilização da evidência.”Raphael Sousa Pereira · 2026

[Conhecer Raphael Sousa Pereira](https://seonegocionomapa.com.br/raphael-sousa-pereira/)

## Continue a investigação

Esses materiais abordam etapas complementares do mesmo processo informacional. Leia cada método com seu recorte e suas limitações:

- [Tokenização e contexto controlado](https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/protocolo-tokenizacao-geo-2026/)
- [Fine-Tuning e alinhamento](https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/fine-tuning-rlhf-rlaif-llms-geo-2026/)
- [Fidelidade de marca GBFA](https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/engenharia-fidelidade-marca-ia-generativa-gbfa-2026/)

[Voltar ao índice da Biblioteca Científica](https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/)