Pular para conteúdo

Capítulo 2.1 — Fundamentos de LLMs

🎯 Objetivo

Dar o vocabulário e o modelo mental mínimos sobre o que existe dentro de um LLM para sustentar decisões de arquitetura, custo e operação. Este capítulo não ensina a treinar um LLM; ele explica por que reduzir um prompt de 8k para 2k tokens muda mais do que a fatura, ou por que dois modelos do "mesmo tamanho" podem ter custos de inferência radicalmente diferentes.

Cada conceito é apresentado com uma definição operacional, uma consequência prática e, quando aplicável, um limite que ele impõe sobre arquitetura ou orçamento.

🧠 Tokenização

Um LLM moderno não enxerga texto bruto: ele opera sobre tokens, que são unidades subword aprendidas pelo tokenizer. Os esquemas mais comuns são BPE (Byte Pair Encoding) e variantes de SentencePiece (BBPE, Unigram).

Implicações práticas:

  • Tokens ≠ palavras. Uma palavra pode virar 1, 2 ou mais tokens, dependendo do idioma e do vocabulário do modelo.
  • Português e idiomas com morfologia rica tendem a gerar mais tokens por caractere do que inglês. O mesmo texto custa mais e ocupa mais janela de contexto em PT-BR.
  • Caracteres não-ASCII, emojis, código fonte e nomes próprios geram tokenização irregular. Documentos com muito código, JSON ou XML têm contagem de tokens difícil de estimar de cabeça.
  • Cada provedor tem seu tokenizer. Contar tokens com a régua do modelo A para estimar custo no modelo B é uma fonte recorrente de surpresa em FinOps.

Decisão arquitetural típica: medir o tokenizer real do modelo-alvo sobre amostras representativas do tráfego antes de fechar contrato ou estimar custo de janela.

🧠 Embeddings internos vs embeddings de retrieval

Há dois tipos de "embedding" no ecossistema, e confundi-los gera problemas em RAG.

  • Embeddings internos do LLM. São as representações vetoriais que o modelo usa internamente, aprendidas no treino conjunto com a rede. Existem na camada de input e nas representações intermediárias. Não são exportadas como "vetor de embedding" para retrieval.
  • Embeddings de retrieval. São saídas de modelos de embedding específicos (por exemplo text-embedding-3-small, bge-large, nomic-embed-text), treinados para que similaridade vetorial reflita similaridade semântica entre trechos de texto.

Consequências práticas:

  • O modelo de embedding usado em RAG é uma decisão separada do LLM de geração. Trocar o LLM gerador não invalida o índice; trocar o modelo de embedding invalida o índice e exige reembedding.
  • "Embedding do GPT-4" como conceito genérico não existe da forma que pessoas frequentemente assumem. Para retrieval, use modelos de embedding declarados, com dimensão conhecida (ver Cap. 2.8).

🧠 Arquitetura Transformer (vista de produção)

O Transformer (Vaswani et al., 2017) é composto por blocos empilhados de:

  • Self-attention. Para cada posição da sequência, o modelo calcula pesos sobre todas as outras posições e combina as representações. Custa O(n²) em compute e memória quando feito de forma ingênua, onde n é o número de tokens.
  • Feed-forward (MLP). Camadas densas aplicadas posição-a-posição.
  • Normalização e residuals. Estabilizam o treino e a inferência.

O que isso significa para arquitetura:

  • Quanto maior o prompt, mais caro o prefill. Não linearmente: parte cresce com n² (atenção ingênua). Variantes modernas (FlashAttention, sparse attention, sliding window) reduzem o custo absoluto, mas o trade-off prompt × custo × latência continua existindo.
  • Modelos com mesma "contagem de parâmetros" podem ter custos de inferência muito diferentes por causa do número de camadas, número de cabeças, head dim, mixture-of-experts e estratégia de attention. "70B" não é uma medida operacional suficiente.
  • Long-context (>100k tokens) é feito com técnicas como attention truncation, sparse/local attention e memory tokens. Cada técnica tem custo e qualidade próprios; janela grande não é grátis, mesmo quando o provedor não cobra explicitamente por tokens de contexto.

🧠 Context window

A context window é o número máximo de tokens que o modelo aceita por chamada, prompt + resposta. É um limite duro do modelo, não uma sugestão.

Consequências:

  • Tudo que entra no contexto compete por janela: instruções, documentos (RAG), histórico, tool descriptions, tool results, plano interno, contrato de saída.
  • Estourar a janela costuma resultar em truncamento silencioso: partes do contexto desaparecem sem aviso explícito. Em RAG, isso é fonte recorrente de "o modelo ignorou a evidência".
  • "Mais janela" não substitui context engineering (Cap. 2.3). Encher contexto é frequentemente pior do que selecionar bem.

🧠 Inferência: prefill e decode

Inferência em LLM autoregressivo tem duas fases com economias muito diferentes:

Fase O que faz Limitada por O que dominam
Prefill Processa o prompt inteiro em paralelo, monta o KV cache Compute (FLOPs) TTFT (Time To First Token), tamanho do prompt
Decode Gera tokens um a um, reaproveitando o KV cache Memory bandwidth TPOT (Time Per Output Token), tamanho da resposta

Por isso:

  • Um prompt grande tende a aumentar TTFT (latência até o primeiro token) sem necessariamente afetar o TPOT (latência por token gerado).
  • Uma resposta longa aumenta TPOT acumulado, mesmo com prompt pequeno.
  • Otimização errada vai para o lugar errado. Reduzir prompt em cenário de resposta longa não cura o problema de UX percebida durante o decode.

Este capítulo serve de base para o Cap. 6.3 (sizing de AI server), que trata do raciocínio quantitativo.

🧠 KV cache

Durante o decode, o modelo precisa ler as chaves e valores (K/V) das camadas de atenção para todos os tokens anteriores. Recalcular isso a cada token seria proibitivo.

A solução é o KV cache: as chaves/valores são calculadas no prefill e armazenadas, e o decode só calcula o token novo.

Consequências práticas:

  • O KV cache cresce com o tamanho da sequência e com o número de sequências simultâneas. Em produção, ele frequentemente é o maior consumidor de VRAM, mais até do que os próprios pesos.
  • Técnicas como PagedAttention (vLLM) e continuous batching existem para gerir esse cache com eficiência. Sem isso, batching grande quebra por falta de memória ou por fragmentação.
  • Sequências longas têm custo escondido em VRAM, não só em tokens cobrados. Em self-hosting, ignorar KV cache é o erro de sizing mais clássico.

🧠 Sampling, temperatura e determinismo limitado

A saída do LLM é uma distribuição de probabilidade sobre o próximo token. O que sai depende da estratégia de sampling:

  • Greedy / temperature 0. Pega sempre o token mais provável. Menos criativo, mais previsível.
  • Temperature > 0. Suaviza ou aguça a distribuição antes de amostrar.
  • Top-k. Restringe a amostragem aos k tokens mais prováveis.
  • Top-p (nucleus). Restringe ao menor conjunto cuja probabilidade acumulada atinge p.
  • Repetition penalty, frequency/presence penalties. Ajustes para evitar repetição patológica.

Um detalhe importante e mal-entendido:

Temperatura 0 não garante determinismo. Em produção, a saída ainda varia por: ordem não-determinística de operações em GPU, batch dinâmico, mudanças de versão do modelo no provedor, diferenças de hardware, e ocasionalmente bugs de quantização.

Para reduzir variação (não eliminá-la) em produção:

  • Pin de modelo + versão.
  • Sempre que possível, mesmo provedor e mesma região.
  • Eval contínuo para detectar deriva de comportamento.
  • Não construir testes de produção que assumem strings idênticas; use semantic equivalence ou contratos sobre estrutura.

🚨 Limites reais de LLMs

Combinando o que apareceu acima, fica claro o que um LLM não é:

  • Não é fonte de verdade. A distribuição de treino é fixa, o modelo não conhece o "agora", e mesmo no que conhece pode errar com confiança.
  • Não é base de conhecimento dinâmica. Alterar conhecimento via fine-tuning é caro, frágil e demora; RAG ou tools mudam conhecimento sem retreinar.
  • Não é raciocínio simbólico. LLM imita padrões; "chain-of-thought" e técnicas afins ajudam, mas não convertem o modelo num solver formal.
  • Não é mecanismo de autorização. "Não faça X" no prompt é instrução, não política.
  • Não é determinístico. Mesmo com temperatura 0.
  • Não é estável entre versões. Provedores trocam modelos; comportamentos mudam sem aviso suficiente.

Cada um desses limites é endereçado por algum mecanismo determinístico ao redor do modelo (validação de schema, RAG, policy-as-code, IAM, eval contínuo). É essa engenharia que torna o LLM operável.

🏢 Hermes Logística - onda 1.5

No primeiro experimento de LLM, o time da Hermes estimou custo com tokenizer de inglês sobre tickets em PT-BR. A fatura real, no fim do primeiro mês, ficou cerca de 40% acima da projeção - sem mudança de tráfego. Diagnóstico: o tokenizer real produzia mais tokens por ticket. Correção: medir com o tokenizer do modelo-alvo sobre amostra representativa antes de fechar a próxima janela orçamentária. Lição: aritmética de tokens só vale com o tokenizer certo.

📚 Referências