Fundamentos de LLMs e uso de APIs
Como funcionam a tokenização, a janela de contexto e a geração de respostas, além de custos, streaming, raciocínio, batch e cache.
O que é uma LLM? Por que uma resposta pode ser interrompida mesmo quando você configura um limite maior de saída? E como uma aplicação mantém uma conversa se cada chamada à API é independente?
Para responder a essas perguntas, vamos acompanhar o caminho do texto pela API, da tokenização até a geração da resposta. Depois, entram os recursos que ajudam a gerenciar contexto, custo e tempo de espera.
1. O que é uma LLM
LLM significa Large Language Model, ou modelo de linguagem de grande escala. É um tipo de inteligência artificial treinado com grandes conjuntos de dados para reconhecer padrões e produzir conteúdo a partir do contexto que recebe.
Uma LLM pode responder perguntas, resumir e classificar informações, gerar e revisar textos, auxiliar na programação, extrair dados de documentos e apoiar tarefas de análise e planejamento.
Em um banco de dados, uma consulta recupera registros armazenados. Uma LLM gera uma resposta com base nos padrões que aprendeu e nas informações disponíveis na chamada. Por isso, pode produzir uma resposta incorreta, mesmo quando o texto parece convincente. O cuidado na verificação deve acompanhar o risco da aplicação.
2. Como o texto é processado — tokenização
Tokenização é o processo de dividir o texto em unidades chamadas tokens. Um token pode representar uma palavra inteira, parte de uma palavra, um sinal de pontuação ou uma combinação de espaços e caracteres. Cada token corresponde a um identificador numérico no vocabulário do modelo.
O processo acontece em quatro etapas.
- O texto de entrada é convertido em tokens.
- O modelo processa esses tokens considerando o contexto recebido.
- A resposta é gerada um token de cada vez, com base nas probabilidades dos próximos tokens possíveis.
- Os tokens gerados são convertidos de volta em texto legível.
A quantidade de tokens depende do idioma, do conteúdo e do tokenizador utilizado. As configurações de geração também influenciam o resultado, então a mesma pergunta pode produzir respostas diferentes.
3. Janela de contexto — Context Window
A janela de contexto é a quantidade máxima de tokens que o modelo consegue considerar em uma chamada. Em geral, ela abrange a entrada e a saída, com regras de contabilização que variam conforme o modelo e o provedor.
Imagine uma janela de 200.000 tokens. Se a entrada ocupa 190.000, sobram, em teoria, 10.000 tokens para a saída. Uma resposta de 20.000 tokens ultrapassaria o espaço disponível nesse exemplo.
4. Limite de saída — Max Output Tokens
O limite de saída é o teto de geração que a aplicação configura para uma resposta. Na prática, a saída fica sujeita ao menor de três valores.
- O limite configurado na requisição.
- O máximo de saída suportado pelo modelo.
- O espaço disponível na janela de contexto depois de contabilizar a entrada e os demais elementos da chamada.
No exemplo anterior, se restam 10.000 tokens na janela e a aplicação configura um teto de 16.000, o espaço restante limita a geração. Em outro cenário, se restam 20.000 tokens e a aplicação configura um teto de 5.000, o limite configurado prevalece, desde que o modelo o suporte.
Quando a geração alcança o teto, a API pode devolver uma resposta incompleta e informar o motivo da parada. Na API da Anthropic, por exemplo, stop_reason com o valor max_tokens indica que a geração atingiu o limite configurado. Documentação da Anthropic sobre motivos de parada.
5. Custos e consumo de tokens
Muitos provedores cobram pelo uso da API por milhão de tokens, com tarifas separadas para entrada, que é o conteúdo enviado ao modelo, e saída, que é o conteúdo gerado.
Em muitos modelos, cada token de saída custa mais do que um token de entrada. A diferença varia conforme o modelo, o provedor e a modalidade de processamento, como cache ou lote.
Para estimar o custo de uma aplicação, considere o tamanho médio da entrada, o tamanho esperado da resposta e a frequência das chamadas. Aplique a cada tipo de token a tarifa vigente do modelo escolhido.
6. Chamadas independentes — Stateless API
Em chamadas independentes, o modelo trabalha com o contexto disponível naquela execução. Imagine que a aplicação envie “Meu nome é Ana” e, em uma segunda chamada, pergunte “Qual é meu nome?”. Para responder com base na primeira mensagem, o modelo precisa ter acesso a ela na segunda chamada.
A aplicação pode guardar o histórico em um banco de dados e reenviar as partes relevantes ou usar um mecanismo de conversa oferecido pelo provedor. É assim que ela mantém a continuidade entre chamadas.
7. Gerenciamento de contexto — Context Management
À medida que a conversa cresce, o histórico pode consumir mais tokens de entrada, aumentar o custo e deixar menos espaço para a resposta. Três estratégias ajudam a controlar esse crescimento.
- Sumarização. Substituir parte do histórico por um resumo que preserve fatos e decisões importantes.
- Compactação. Condensar o contexto e remover redundâncias, mantendo o que será útil nas próximas etapas. O termo pode ter um significado específico conforme a ferramenta.
- Truncamento. Remover mensagens ou trechos do histórico, como mensagens antigas que perderam a relevância.
A escolha depende do que a próxima tarefa exige. Um resumo que omite uma decisão importante pode economizar tokens e, ao mesmo tempo, prejudicar a resposta seguinte.
8. Streaming — entrega progressiva da resposta
Com streaming, a API entrega partes da resposta à medida que são geradas. A interface pode exibir o primeiro trecho enquanto o modelo ainda produz o restante. Isso reduz o tempo de espera até o usuário começar a ler, mesmo quando o tempo total de geração continua igual.
Há também diferentes tipos de timeout. O de conexão limita o tempo para estabelecer a conexão. O de leitura ou inatividade limita quanto tempo pode passar sem receber dados. O timeout total limita a duração da operação.
O fluxo de dados pode ajudar a evitar um timeout de inatividade enquanto os fragmentos continuam chegando. O prazo total da operação e a possibilidade de queda de conexão continuam valendo.
9. Thinking e Extended Thinking — esforço adicional de raciocínio
Alguns modelos permitem dedicar processamento adicional ao raciocínio antes de apresentar a resposta final. Uma pergunta como “Quanto é 2 + 2?” exige pouco esforço. Já analisar uma arquitetura, identificar gargalos e comparar estratégias de escalabilidade pode se beneficiar desse recurso.
Em APIs compatíveis, o esforço pode ser configurado por um parâmetro como effort, com níveis como low, medium e high. As opções variam conforme o modelo e a API. Um esforço maior pode aumentar a latência, o consumo de tokens e o custo. Quando o provedor contabiliza tokens de raciocínio como saída, eles entram na cobrança dessa categoria.
10. Batch API — processamento assíncrono em lote
A Batch API permite enviar várias requisições independentes de uma vez para processamento assíncrono. É uma opção quando você pode aguardar os resultados.
Imagine um conjunto de 100 mil registros que precisam ser classificados por uma LLM. A aplicação pode dividir os registros em grupos, montar requisições dentro dos limites do modelo, enviá-las em lote e consultar os resultados depois.
Cada requisição continua sujeita à sua janela de contexto. O volume de tokens pode ser semelhante ao das chamadas convencionais, e a economia, quando oferecida, vem da tarifa por token. A Anthropic, por exemplo, informa um desconto de 50% nas tarifas de entrada e saída para requisições elegíveis da Message Batches API. Documentação da Anthropic sobre processamento em lote.
11. Prompt Caching — reutilização de partes do prompt
O Prompt Caching permite reaproveitar o processamento de trechos que se repetem entre chamadas, como instruções, regras de negócio, documentação e definições de ferramentas.
Imagine uma aplicação que envia a mesma documentação em todas as chamadas e muda apenas a pergunta do usuário. Quando o trecho reutilizável corresponde ao que está no cache e ainda está dentro da validade, o provedor pode reaproveitar seu processamento. Alterações depois desse trecho podem preservar o reaproveitamento, dependendo das regras da API.
A gravação e a leitura podem ter tarifas diferentes. Em alguns casos, gravar custa mais do que processar a entrada normalmente, enquanto ler do cache custa menos. A Anthropic, por exemplo, documenta opções de validade de 5 minutos e 1 hora. Documentação da Anthropic sobre cache de prompt.
A aplicação continua responsável por fornecer o contexto necessário em cada chamada. O cache ajuda a processar conteúdo repetido, enquanto o histórico da conversa precisa ser gerenciado pela aplicação ou por um recurso de estado da API.
12. Como esses conceitos se conectam
A tokenização define as unidades que o modelo processa. A janela de contexto determina quanto cabe em uma chamada, e o limite de saída define até onde a geração pode ir. O gerenciamento de contexto decide o que vale a pena carregar de uma chamada para a seguinte.
Os demais recursos atendem a necessidades diferentes. O streaming entrega a resposta progressivamente. O thinking dedica mais processamento a tarefas complexas. O batch organiza requisições que podem rodar de forma assíncrona. O cache reaproveita o processamento de trechos repetidos.
Esses fundamentos ajudam a responder às próximas perguntas de quem constrói uma aplicação com LLMs. Qual modelo atende melhor à tarefa? Que instruções ele precisa receber? E quais informações devem entrar no contexto para que a resposta seja útil?