當 você no ChatGPT, Claude ou DeepSeek digita um trecho de texto, e o modelo começa a responder palavra por palavra em questão de centenas de milissegundos — esse processo parece simples, mas na prática é uma das engenharias mais refinadas da computação moderna. Este artigo organiza a análise completa do fluxo de inferência do engenheiro de IA Akshay Pachaar, do tokenization, embedding, attention, até as duas etapas prefill/decode, com KV cache, quantização e por que o DeepSeek V4 reduz o tamanho do cache em 10% do que era antes.
Modelo mental central: LLM só “chuta” o próximo token — e repete
Modelos de linguagem grandes, na essência, fazem apenas uma coisa: prever o próximo token. Eles recebem a sequência de tokens da sua entrada, calculam a distribuição de probabilidade do próximo token, fazem a amostragem para gerar um token, anexam esse token ao fim da entrada e, então, prevêem o próximo — sem parar, até o modelo emitir um token de parada ou atingir o limite.
O ponto crítico do fluxo de inferência não é “como ele prevê”, mas sim “por que o segundo token fica muito mais rápido do que o primeiro?”. A resposta puxa dois conceitos mais importantes no serviço de LLM da era moderna: as duas etapas prefill e decode, e o KV cache.
Step 1：Tokenization transforma texto em números
Redes neurais não leem texto; elas só leem vetores. Então, seu prompt passa primeiro por tokenization, sendo dividido em “tokens” em pedaços, e cada token corresponde a um ID inteiro. A maioria dos LLMs modernos usa BPE (Byte Pair Encoding, codificação por pares de bytes): partindo de caracteres originais, fundindo sucessivamente os pares de caracteres que mais aparecem juntos e, no fim, obtém uma tabela de vocabulário com cerca de 50 mil tokens comuns.
Esse passo tem um impacto maior do que a maioria das pessoas imagina. Em idiomas com menor peso nos dados de treinamento do tokenizer, o texto é segmentado em mais tokens; o custo de inferência sobe e a velocidade cai. Chinês e chinês tradicional, em muitos tokenizers orientados a inglês, costumam ter cada caractere quebrado em 2 a 3 tokens — essa é uma das causas fundamentais do custo alto de inferência para usuários chineses.
Step 2：Embedding transforma IDs em vetores e injeta informação de posição
O ID inteiro de cada token é usado para consultar uma enorme “tabela de embedding”. Se o vocabulário do modelo tem 50K e a dimensão oculta é 4096, o formato dessa tabela é [50000, 4096]. Cada token pega uma linha dessa matriz e, com isso, seu vetor é uma representação de 4096 dimensões.
Esses vetores não são aleatórios — no treinamento, o modelo empurra tokens semanticamente próximos para áreas semelhantes no espaço: king e queen ficam próximos em alguma direção; python (linguagem) e javascript ficam próximos em outra; e python e snake (cobra) ficam próximos em outra terceira.
A informação de posição também é injetada nessa etapa, porque o mecanismo de attention em si não sabe qual token vem antes e qual vem depois. Os modelos mais atuais adotam RoPE (Rotary Position Embedding, codificação rotacional de posição): o vetor é rotacionado conforme a posição do token, embutindo a ordem diretamente no próprio vetor.
Step 3：Self-Attention é o núcleo do Transformer
A sequência de vetores entra então em 32 camadas (ou mais) de transformer; em cada camada, acontecem duas coisas: usar self-attention para misturar informações entre tokens e, em seguida, usar feed-forward para misturar informações dentro de cada token.
O self-attention funciona assim: cada token passa por três matrizes de pesos aprendidas Wq, Wk, Wv, gerando três vetores: query (consulta), key (chave) e value (valor). Para cada token, sua query faz um produto interno com as keys de todos os outros tokens, produzindo pesos que dizem “quanto daquele token deve entrar” na mistura; depois, esses pesos são usados para somar e misturar as value.
É aí que está a magia do attention: cada token decide por conta própria quais posições do contexto faz sentido “olhar”, puxando informações úteis para o seu vetor. Ao empilhar 32 camadas, o modelo consegue acompanhar referências através de milhares de tokens. A rede feed-forward após o attention lida com grande parte do “conhecimento” do modelo: o attention transporta informações, e o feed-forward processa essas informações.
Prefill e Decode：mesmo GPU, dois gargalos completamente diferentes
Este é o divisor mais importante do artigo. Gerar uma resposta de 200 palavras, na prática, são dois tipos de tarefa com propriedades totalmente diferentes, rodando na mesma GPU.
Etapa prefill — quando você envia o prompt, o modelo precisa primeiro passar por todos os tokens de entrada para conseguir gerar o primeiro token. Essa etapa consegue processar tudo “em paralelo” para os tokens de entrada: as Q, K e V de cada token são calculadas ao mesmo tempo; o attention vira uma multiplicação de matriz por matriz grande. GPU é feita para esse tipo de operação; as unidades (Tensor Cores) ficam ocupadas e o gargalo está no poder de computação. Esse indicador de latência na etapa é TTFT (Time to First Token, tempo até o primeiro token).
Etapa decode — depois que o primeiro token sai, o modelo muda de modo. Ao gerar o token 51, ele só precisa calcular Q, K e V desse novo token; as K e V dos 50 tokens anteriores já foram calculadas, então não precisa refazer. O problema é que, embora a quantidade de computação por token seja pequena, a GPU ainda precisa carregar da memória (VRAM) os pesos inteiros do modelo e todo o histórico do KV para fazer uma operação minúscula e depois devolver. Assim, o gargalo sai de “computação” e vira “largura de banda de memória”. Esse indicador de latência na etapa é ITL (Inter-Token Latency, latência entre tokens), e é ele que define se a sensação de “digitação” do modelo é rápida ou lenta.
Por isso, prefill é compute-bound e decode é memory-bound — mesmo modelo, mesmo hardware, mas características de desempenho totalmente diferentes.
KV Cache：a otimização-chave que torna a inferência de LLM viável
Na etapa decode, “não recalcular” K e V dos tokens passados é possível graças ao KV cache. Cada camada do transformer mantém dois tensores: K e V de todos os tokens anteriores; quando o novo token gera K e V, eles são apenas append (anexados). Durante o attention, ele lê diretamente todo o histórico.
Sem KV cache, gerar uma resposta com 1.000 tokens faria com que, em cada passo, tivesse de recalcular toda a sequência crescente — a complexidade explode quadraticamente. Com KV cache, a geração longa pode ficar pelo menos 5 vezes mais rápida. Mas o custo é este: o cache fica na VRAM; a cada token gerado, o cache aumenta uma “parcela” a mais. Em modelos de 13B, cada token ocupa cerca de 1MB; em um contexto de 4K, isso consome 4GB de VRAM só para armazenar o cache.
Esse é o motivo real de “contexto longo é lento e caro” — não é que o modelo “não consegue acompanhar”, e sim que o cache esgota a VRAM, fazendo cair o número de usuários simultâneos que aquela GPU consegue atender. Otimizações comuns incluem: quantizar o cache para INT8 ou INT4, usar sliding window para descartar tokens muito antigos, usar grouped-query attention (GQA) para fazer múltiplas heads compartilharem K e V, ou usar PagedAttention (como o vLLM) para gerenciar o cache por páginas (similar ao gerenciamento de memória por um sistema operacional).
Revolução do cache do DeepSeek V4：de 10% do original em 1M de contexto
Quantização e paginação transformam o KV cache em “custo fixo” para otimização. A série V4 do DeepSeek, com prévia no fim de 2025, segue um caminho mais agressivo: redesenhar o attention desde o início para deixar o cache pequeno.
O V4 usa um mecanismo híbrido, combinando duas variantes de attention — esparsa e densa — que funcionam em fluxos de KV altamente comprimidos. Com contexto de 1 milhão de tokens, o V4-Pro relata que o tamanho do KV cache é apenas cerca de 10% do dos antecessores, e o custo de cálculo por token é apenas cerca de 27%. O significado não é só “o DeepSeek ficou mais barato de novo”, mas que o KV cache já virou o gargalo otimizado no ecossistema de LLM — quando o mecanismo de attention é redesenhado para reduzir o cache, a “condição limitante” de toda a comunidade técnica é deslocada de forma definitiva.
Para leitores de Taiwan, a informação mais útil é: o DeepSeek V4-Flash já está disponível no Ollama Cloud e em servidores nos EUA (veja abmedia 4/24), o Claude Code e o OpenClaw já permitem integrar em um clique, sem precisar montar infraestrutura para validar as vantagens do novo attention em cenários de contexto longo.
Quantization：troque precisão por velocidade e VRAM
Treinar exige alta precisão; inferência não. Na maioria das implantações formais, troca-se FP16 ou BF16 no lugar de FP32, dobrando imediatamente a VRAM e o throughput. Uma abordagem mais radical é quantizar os pesos para INT8 e, até mesmo, INT4.
Números intuitivos: um modelo de 7B parâmetros precisa de 28GB em FP32, 14GB em FP16, 7GB em INT8 e apenas 3,5GB em INT4. É por isso que um GPU de placa de notebook comum consegue rodar um modelo de 7B. Métodos como GPTQ e AWQ escolhem fatores de escala por canal, minimizando a perda de qualidade causada pela compressão com perdas — um INT4 bem projetado costuma ficar com desempenho nos benchmarks apenas 1 ponto percentual abaixo do original.
Juntando todos os passos：a jornada completa de um prompt
Conectando todas as etapas acima, o caminho completo de uma inferência é: (1) Tokenize—texto vira IDs inteiros. (2) Embed—IDs viram vetores e a informação de posição é injetada. (3) Prefill—todas as camadas processam todos os tokens de entrada em paralelo; é compute-bound, o KV cache é criado e o primeiro token de saída é gerado. (4) Loop de Decode—cada vez projeta apenas o novo token em Q; faz attention com K e V do cache; roda feed-forward; amostra a saída e escreve o novo K e V de volta no cache; é memory-bound. (5) Detokenize—IDs de tokens voltam a virar caracteres e a saída é enviada em streaming para a tela.
Frameworks de serviço como vLLM, TensorRT-LLM e Text Generation Inference colocam camadas fora desse ciclo: batch contínuo (tokens de usuários diferentes podem ser intercalados no mesmo step de GPU), speculative decoding (um modelo menor rascunha e o modelo maior valida) e um gerenciamento sofisticado de memória—é assim que uma única GPU consegue servir dezenas de usuários.
Para desenvolvedores: o que você deve se importar mais — TTFT ou ITL？
Quando você entende o fluxo de inferência completo, algumas decisões práticas aparecem naturalmente:
Prompts longos aumentam TTFT; saídas longas aumentam ITL—elas vêm de fontes de estresse diferentes, então não desperdice recursos de otimização no indicador errado. Contexto não é “grátis”: dobrar o contexto não só dobra a computação; também comprime o tamanho de lote suportado pelo KV cache. Quantização é o botão de maior alavancagem hoje: trocar FP16 por INT8 frequentemente corta a metade da latência, com perda de qualidade extremamente pequena. Utilization de GPU também costuma ser um indicador enganador—no prefill a GPU pode ficar a 100%, enquanto no decode talvez só use 30%; a solução não é mais poder computacional, e sim memória mais rápida ou um cache menor.
A arquitetura Transformer chama mais atenção, mas o desempenho de inferência vive de “detalhes chatos”: configuração de memória, gerenciamento de cache, largura de bits. Quando alguém disser “esse modelo é lento”, a próxima pergunta correta não é “trocar de GPU”, e sim: “o que está lento — o ‘começar’ ou o ‘streaming’?” — a resposta define todo o caminho da otimização.
Este tutorial completo de inferência de LLM: KV cache e a revolução do cache do DeepSeek V4 apareceu pela primeira vez em 鏈新聞 ABMedia.
