Quando você introduce um texto no ChatGPT, Claude ou DeepSeek e o modelo começa a responder palavra a palavra em apenas algumas centenas de milissegundos—na prática, este processo é uma das engenharias mais finas e exigentes da computação moderna. Este artigo organiza a análise completa do fluxo de inferência do engenheiro de IA Akshay Pachaar, desde tokenization, embedding, attention, até às duas fases prefill/decode, KV cache, quantização, e explica por que razão o DeepSeek V4 consegue reduzir o volume de cache para apenas 10% do original.
Modelo mental central: os LLM apenas “adivinham o token seguinte” e repetem
Por natureza, os grandes modelos de linguagem fazem apenas uma coisa: prever o token seguinte. Recebem a sequência de tokens da tua entrada, calculam a distribuição de probabilidades para o token seguinte, amostram e geram um token, anexam esse token ao fim da entrada e voltam a prever o próximo—sem parar, até o modelo emitir um token de paragem ou atingir o limite.
A questão-chave de todo o processo de inferência não é “como é que ele prevê”, mas sim “porque é que o segundo token é muito mais rápido do que o primeiro?” Esta resposta conduz a dois conceitos fundamentais na prestação de serviços de LLM: as duas fases prefill e decode, e o KV cache.
Step 1：Tokenization transforma texto em números
As redes neuronais não “lêem” texto, apenas vetores. Por isso, o teu prompt passa primeiro por tokenization, é dividido em pedaços—os “tokens”—e cada token corresponde a um ID inteiro. A maioria dos LLM modernos utiliza BPE (Byte Pair Encoding, codificação por pares de bytes): partindo de caracteres originais, vai fundindo de forma iterativa os pares de caracteres que aparecem com mais frequência, até obter uma lista (vocabulário) com cerca de 50 mil tokens comuns.
Esta etapa tem um impacto maior do que a maioria imagina. Em línguas que, nos dados de treino do tokenizer, têm menos peso relativo, o texto acaba por ser dividido em mais tokens, aumentando o custo da inferência e tornando-a mais lenta. O chinês e o chinês tradicional, em muitos tokenizers orientados para inglês, frequentemente fazem com que cada caractere seja dividido em 2 a 3 tokens—e esta é uma das razões fundamentais para o custo de inferência mais elevado dos utilizadores chineses.
Step 2：Embedding transforma inteiros em vetores e injecta informação de posição
O ID inteiro de cada token procura numa grande “tabela de embedding”. Se o vocabulário do modelo tiver 50K e a dimensão oculta for 4096, então o formato dessa tabela é [50000, 4096]. Cada token recolhe uma linha dessa tabela, que corresponde à sua representação em 4096 dimensões.
Estes vetores não são aleatórios—durante o treino, o modelo aproxima no espaço semântico tokens com significados semelhantes: king e queen ficam próximos numa certa direcção; python (linguagem) e javascript noutra; e python e snake (cobra) noutra terceira.
A informação de posição também é injectada nesta etapa, porque o mecanismo de attention, por si só, não sabe quais tokens vêm antes e quais vêm depois. Os modelos dominantes actualmente adoptam RoPE (Rotary Position Embedding, codificação posicional rotativa): roda os vetores consoante a posição do token, fazendo com que a ordem fique embutida no próprio vetor.
Step 3：Self-Attention é o coração do Transformer
A sequência de vetores entra então em 32 camadas de transformer (ou mais). Em cada camada, são feitas duas coisas: usar self-attention para misturar informação entre tokens e usar feed-forward para misturar informação dentro de cada token.
Como funciona a self-attention: cada token passa por três matrizes aprendidas Wq, Wk, Wv, gerando três vectores—query (consulta), key (chave) e value (valor). Para cada token, a sua query é feita o produto interno com as key de todos os outros tokens, obtendo pesos que dizem “quanto dessa informação deve ser puxada de outros tokens” e, depois, usa esses pesos para misturar as value.
É este o truque da attention: cada token decide por si mesmo que posições no contexto deve observar e puxa para o seu vetor a informação útil. Ao empilhar 32 camadas, o modelo consegue seguir referências através de milhares de tokens. As redes feed-forward que vêm depois da attention suportam grande parte do “conhecimento” do modelo; a attention é responsável por transportar informação, enquanto o feed-forward trata do processamento dessa informação.
Prefill e Decode：no mesmo GPU, dois gargalos completamente diferentes
Este é o corte mais importante do artigo. Gerar uma resposta de 200 palavras, na prática, são dois tipos de tarefas com propriedades totalmente diferentes, a correr na mesma GPU.
Fase prefill—quando envias o prompt, o modelo precisa primeiro de passar todos os tokens de entrada por uma vez antes de conseguir gerar o primeiro token. Esta etapa pode ser “paralelizada” para todos os tokens de entrada: as Q, K, V de cada token são calculadas em simultâneo; a attention é uma multiplicação de matrizes grande a grande. As GPUs foram feitas para este tipo de operação—as unidades de computação (Tensor Cores) ficam ocupadas e o gargalo está na “capacidade de computação”. O indicador de latência desta fase chama-se TTFT (Time to First Token, latência até ao primeiro token).
Fase decode—depois de sair o primeiro token, o modelo muda de modo. Ao gerar o token 51, ele só precisa de calcular as Q, K, V deste token novo; as K e V dos anteriores 50 tokens já foram calculadas e não precisam de ser refeitas. O problema é que, embora o trabalho de cada token seja pequeno, a GPU ainda tem de carregar os pesos completos do modelo e todo o histórico KV da memória de vídeo (VRAM) para fazer um cálculo minúsculo e depois devolver o resultado. O gargalo muda de “capacidade de computação” para “largura de banda de memória”. O indicador de latência desta fase chama-se ITL (Inter-Token Latency, latência entre tokens), e é ele que determina se a sensação de “digitação” do modelo é rápida ou lenta.
Assim, prefill é compute-bound (limitada por computação) e decode é memory-bound (limitada por memória)—o mesmo modelo, o mesmo hardware, mas características de desempenho totalmente diferentes.
KV Cache：a optimização-chave que torna a inferência de LLM viável
Na fase decode, “não recalcular tokens passados” depende do KV cache. Em cada camada do transformer, são mantidos dois tensores: K e V de todos os tokens históricos. Depois de calcular K e V do token novo, é feito append e, durante a attention, lê-se directamente todo o histórico.
Sem KV cache, gerar uma resposta com 1.000 tokens obriga a recalcular a sequência em crescimento em cada passo—e a complexidade explode com crescimento quadrático (explosão de complexidade quadrática). Com KV cache, a geração longa pode acelerar 5 vezes ou mais. Mas há um custo: o cache ocupa VRAM na GPU e, por cada token adicional gerado, o cache aumenta mais uma fatia. Em modelos de 13B, cada token ocupa cerca de 1MB; um contexto de 4K consome 4GB de VRAM apenas para guardar esse cache.
Esta é a verdadeira razão de “contextos longos serem lentos e caros”—não é que o modelo “não consiga pensar” o suficiente, é que o cache esgota a VRAM e, por isso, o número simultâneo de utilizadores que uma única GPU consegue servir cai drasticamente. Entre métodos comuns de optimização estão: quantizar o cache para INT8 ou INT4, usar sliding window para descartar tokens demasiado antigos, aplicar grouped-query attention (GQA) para partilhar K e V entre múltiplas attention heads, ou usar PagedAttention (como no vLLM) para gerir o cache por páginas (semelhante à gestão de memória por um sistema operativo).
Revolução do cache do DeepSeek V4：de 1M de contexto para 10% do original
A quantização e a paginação optimizam o KV cache como se fosse “custo fixo”. A série V4, em pré-visualização no fim de 2025, segue uma via ainda mais agressiva: redesenhar directamente a attention para que o cache seja pequeno desde o início.
O V4 adopta um mecanismo híbrido, combinando variantes de attention compactadas densas e esparsas; ambas operam em fluxos de KV altamente comprimidos. Com contexto de milhão de tokens, o V4-Pro reporta que o volume do KV cache é apenas cerca de 10% do da geração anterior, e o custo de computação por token é apenas cerca de 27%. O significado não é apenas “o DeepSeek ficou mais barato”—é que o KV cache passou a ser um gargalo que todo o domínio de LLM procura optimizar. Quando o mecanismo de attention é redesenhado para reduzir o cache, isso significa que as “condições limitantes” da comunidade técnica se deslocaram de forma definitiva.
Para leitores em Taiwan, a informação mais útil é: o DeepSeek V4-Flash já está disponível no Ollama Cloud e em servidores nos EUA (ver a reportagem da abmedia de 24/4), o Claude Code e o OpenClaw já permitem ligação com um clique, sem precisar de montar um sistema, para validar as vantagens da nova geração de attention em cenários de contexto longo.
Quantization：trocar precisão por velocidade e memória
O treino precisa de alta precisão, mas a inferência não. A maioria das implementações formais passa de FP32 para FP16 ou BF16, duplicando imediatamente a memória de vídeo e o throughput. Mais agressivamente, os pesos podem ser quantizados para INT8 e até INT4.
Em números: um modelo de 7B de parâmetros em FP32 precisa de 28GB; em FP16, 14GB; em INT8, 7GB; e em INT4 apenas 3,5GB. É por isso que placas gráficas de portáteis conseguem correr modelos de 7B. Métodos como GPTQ e AWQ escolhem coeficientes de escala em cada canal, minimizando a perda de qualidade causada pela compressão com perdas—um INT4 bem desenhado, em muitos benchmarks, fica apenas 1 ponto percentual ou menos atrás do original.
Unir todos os passos: a viagem completa de um prompt
Unindo todas as etapas acima, o percurso completo de uma inferência é: (1) Tokenize—transformar texto em IDs inteiros. (2) Embed—converter IDs em vectores e injectar informação de posição. (3) Prefill—cálculo paralelo em todas as camadas para todos os tokens de entrada; é compute-bound, cria-se o KV cache e gera-se o primeiro token de saída. (4) Loop de Decode—em cada passo, projecta apenas o token novo’s Q; faz attention com K e V no cache; corre feed-forward; faz amostragem e produz a saída; escreve K e V novos de volta para o cache; é memory-bound. (5) Detokenize—converter IDs de token de volta em caracteres e fazer o output em streaming para o ecrã.
Frameworks de serviço como vLLM, TensorRT-LLM e Text Generation Inference acrescentam fora deste ciclo: lotes contínuos (os tokens de diferentes utilizadores podem ser entrelaçados no mesmo step de GPU), speculative decoding (um modelo pequeno rascunha e o modelo grande valida) e gestão de memória mais fina—esta é a forma de uma única GPU servir dezenas de utilizadores.
Pontos práticos para developers: deves preocupar-te com TTFT ou com ITL?
Com o panorama completo do processo de inferência, surgem naturalmente algumas decisões práticas:
Prompts longos amplificam TTFT; outputs longos amplificam ITL—são fontes de pressão diferentes, por isso não desperdices recursos de optimização nos indicadores errados. Contexto não é “grátis”: dobrar o contexto não só duplica o cálculo, como também comprime o tamanho do lote que o KV cache consegue acomodar. A quantização é o botão de maior alavancagem actualmente: trocar FP16 por INT8 frequentemente corta metade da latência, com perdas de qualidade extremamente pequenas. A utilização da GPU (utilization) também costuma ser um indicador enganador—na fase prefill a GPU pode ficar cheia, mas na fase decode pode usar apenas 30%; a solução não é ter mais capacidade de computação, mas sim memória mais rápida ou cache menor.
A arquitectura Transformer chama mais atenção, mas a performance de inferência vive, na verdade, em “detalhes aborrecidos”: configuração de memória, gestão de cache, largura de bits (bit-width). Quando alguém diz “este modelo é lento”, a próxima pergunta que deves fazer não é “trocar de GPU”, mas sim “está lento no ‘arranque’ ou no ‘streaming’?”—a resposta define o caminho inteiro de optimização.
Este artigo é uma aula completa sobre inferência de LLM：KV cache e revolução do cache do DeepSeek V4, e foi publicado primeiro em Cadeia de Notícias ABMedia.
