Tokens nas LLMs: entenda o consumo e controle os custos da sua aplicação

As ferramentas de inteligência artificial fazem tarefas impressionantes com poucos comandos. Podemos gerar textos, analisar documentos, revisar códigos e até criar agentes capazes de executar várias etapas de um processo.

Para o usuário comum, tudo parece simples: escrevemos uma pergunta e recebemos uma resposta. Porém, quando integramos uma inteligência artificial em uma aplicação, descobrimos que existe um “taxímetro” funcionando por trás dessa conversa.

Esse taxímetro utiliza tokens.

Entender como eles funcionam é importante para evitar surpresas na fatura e também para desenvolver aplicações mais rápidas, eficientes e escaláveis.

O que é um token?

Uma LLM — sigla para Large Language Model ou Modelo de Linguagem de Grande Escala — não processa um texto exatamente da maneira como nós o lemos.

Antes de interpretar uma frase, o modelo divide seu conteúdo em pequenas unidades chamadas tokens. Um token pode representar uma palavra completa, parte de uma palavra, um número, um espaço ou um sinal de pontuação.

De maneira apenas ilustrativa, uma frase poderia ser dividida assim:

A divisão real depende do tokenizador utilizado pelo modelo. Portanto, não podemos considerar que um token seja sempre igual a uma palavra.

Segundo a documentação da OpenAI, em textos escritos em inglês, um token corresponde aproximadamente a quatro caracteres ou três quartos de uma palavra. Essa proporção é apenas uma estimativa e pode mudar conforme o idioma, os acentos, o código-fonte e o modelo escolhido.

A palavra “desenvolvimento”, por exemplo, pode ser separada em mais de um token. Estruturas JSON, códigos PHP, nomes de variáveis e textos em português também podem apresentar resultados diferentes.

Por isso, contar palavras não é uma forma confiável de calcular o consumo de uma API.

Tokens de entrada e saída

Quando fazemos uma requisição, existem dois consumos principais.

Os tokens de entrada representam tudo o que enviamos ao modelo: a pergunta do usuário, as instruções do sistema, o histórico da conversa, documentos, exemplos e até a descrição das ferramentas que a IA poderá utilizar.

Os tokens de saída são aqueles utilizados para gerar a resposta.

Em alguns modelos também existem os tokens de raciocínio, utilizados internamente antes da resposta ser apresentada. Eles nem sempre aparecem para o usuário, mas podem fazer parte do consumo cobrado como saída.

Além deles, alguns fornecedores trabalham com tokens de entrada em cache. Nesse caso, instruções ou contextos repetidos podem ser reaproveitados por um preço menor.

O consumo total de uma requisição pode envolver:

  • tokens enviados pelo usuário;
  • instruções definidas pelo desenvolvedor;
  • histórico da conversa;
  • documentos e dados recuperados;
  • descrição de funções e ferramentas;
  • tokens internos de raciocínio;
  • conteúdo gerado na resposta.

Ou seja, aquela pergunta de uma linha pode carregar uma verdadeira mudança de apartamento escondida no histórico.

A janela de contexto

Todo modelo possui uma janela de contexto, que representa a quantidade máxima de tokens que ele consegue processar em uma requisição.

Essa janela precisa acomodar a entrada, a resposta e, dependendo do modelo, os tokens de raciocínio.

Uma janela grande permite analisar documentos extensos e manter conversas longas, mas não significa que devemos enviar tudo o que estiver disponível. Quanto maior o contexto, maior poderá ser o custo e o tempo de processamento.

Em uma conversa, o histórico também merece atenção. Na API da OpenAI, por exemplo, os tokens anteriores continuam sendo contabilizados como entrada mesmo quando usamos o identificador da resposta anterior para manter a conversa.

Imagine um atendimento que começou com 500 tokens. Depois de várias mensagens, o histórico pode atingir 20 mil tokens. A próxima pergunta do usuário pode conter apenas cinco palavras, mas o modelo precisará receber e processar todo o contexto necessário para respondê-la.

Sem controle, o custo cresce junto com a conversa.

Como a cobrança é calculada?

Os fornecedores normalmente apresentam seus preços por milhão de tokens. Entrada, saída e conteúdo em cache podem ter valores diferentes.

O cálculo básico é:

Considere um exemplo hipotético:

O cálculo seria:

Dois centavos parecem insignificantes. Porém, cem mil requisições iguais custariam US$ 2 mil.

Também é importante verificar cobranças adicionais. Pesquisas na internet, geração de imagens, armazenamento de arquivos, execução de códigos e outras ferramentas podem ter preços separados do consumo de texto.

Os valores mudam conforme o modelo e o fornecedor. Portanto, consulte sempre a página oficial de preços antes de calcular o custo de um projeto.

ChatGPT e API não são a mesma coisa

Existe uma confusão comum entre utilizar uma ferramenta de inteligência artificial e integrar seu modelo em um sistema.

No ChatGPT, o usuário pode pagar uma assinatura mensal e utilizar os recursos de acordo com os limites do plano. Na API, a cobrança é feita separadamente e depende dos modelos, tokens e ferramentas utilizados.

Ter uma assinatura do ChatGPT não significa possuir créditos para utilizar a API da OpenAI.

Essa diferença também existe em outros serviços. Ao planejar uma aplicação, o desenvolvedor precisa avaliar o preço da API utilizada, e não apenas o plano disponível para o usuário final.

Como controlar o consumo

A primeira atitude é parar de trabalhar com estimativas e começar a registrar o consumo real.

As APIs normalmente retornam informações sobre a quantidade de tokens utilizados. Esses dados devem ser armazenados junto com o modelo, usuário, funcionalidade, tempo de resposta e custo estimado.

Com isso, podemos identificar qual recurso da aplicação está consumindo mais e quanto custa atender cada usuário.

Também existem outras medidas importantes.

Limite o tamanho das respostas

Se o sistema precisa apenas de uma classificação, não faz sentido permitir que o modelo escreva um artigo.

Utilize o parâmetro de limite de saída oferecido pelo fornecedor e descreva claramente o formato esperado. Quando possível, solicite respostas estruturadas e objetivas.

Não envie histórico desnecessário

Em conversas longas, mantenha apenas as mensagens relevantes. Outra possibilidade é resumir as partes antigas antes de continuar o atendimento.

O resumo também consome tokens, mas pode reduzir bastante o custo das próximas requisições.

Escolha o modelo de acordo com a tarefa

Nem toda atividade precisa do modelo mais avançado.

Um modelo menor pode ser suficiente para classificar mensagens, extrair campos, padronizar textos ou identificar intenções. Modelos mais poderosos podem ser reservados para análises complexas ou para os casos em que o modelo menor não atingir a qualidade necessária.

O melhor modelo não é simplesmente o mais barato ou o mais inteligente. É aquele que entrega a qualidade esperada pelo menor custo total.

Utilize cache para conteúdos repetidos

Instruções do sistema, documentos, exemplos e descrições de ferramentas costumam se repetir em várias requisições.

O prompt caching permite reaproveitar partes estáveis do contexto, reduzindo custo e latência nos modelos compatíveis. Para aproveitar melhor esse recurso, o conteúdo fixo deve permanecer no início do prompt, enquanto as informações variáveis ficam no final.

Alterar uma data, um identificador ou qualquer trecho do prefixo pode impedir o reaproveitamento do cache.

Envie somente os documentos necessários

Se o usuário fizer uma pergunta sobre uma cláusula contratual, não é eficiente enviar centenas de páginas em todas as requisições.

Uma estratégia de RAG — Retrieval-Augmented Generation — pode localizar primeiro os trechos relacionados à pergunta e enviar apenas esse conteúdo ao modelo.

Porém, também é necessário controlar o tamanho e a quantidade de trechos recuperados. Buscar vinte partes de um documento quando apenas três seriam suficientes continuará desperdiçando tokens.

Controle repetições e tentativas automáticas

Sistemas com agentes podem realizar várias chamadas para concluir uma única tarefa. Um erro de programação pode criar um ciclo de tentativas que consome tokens sem produzir resultado.

Defina:

  • quantidade máxima de etapas;
  • limite de novas tentativas;
  • tempo máximo de execução;
  • orçamento por tarefa;
  • limite diário ou mensal por usuário;
  • alertas de consumo anormal.

Em uma integração tradicional, um loop incorreto pode gerar registros duplicados. Em uma integração com IA, ele também pode transformar dinheiro em tokens com bastante eficiência.

Registrando o custo com PHP

Os nomes dos campos mudam conforme o fornecedor, mas podemos utilizar as informações de consumo retornadas pela API para calcular uma estimativa.

Os preços do exemplo são hipotéticos e devem ser mantidos em uma configuração atualizável, nunca espalhados pelo código.

Em uma aplicação Laravel, podemos registrar esses dados em uma tabela de uso e criar relatórios por usuário, modelo e funcionalidade. Dessa forma, o custo deixa de ser uma surpresa no cartão e passa a ser uma métrica da aplicação.

Economizar sem prejudicar o resultado

Reduzir tokens é importante, mas remover contexto indiscriminadamente pode piorar a resposta.

Se o modelo começar a errar e a aplicação precisar repetir a requisição, a suposta economia desaparecerá. Uma resposta correta utilizando três mil tokens pode custar menos do que três respostas incorretas utilizando dois mil tokens cada.

Além do custo por requisição, devemos acompanhar:

  • custo por tarefa concluída;
  • quantidade de tentativas;
  • tempo de resposta;
  • taxa de erro;
  • qualidade do resultado;
  • consumo médio por usuário.

O objetivo não é utilizar a menor quantidade possível de tokens. É utilizar apenas os tokens que realmente contribuem para a resposta.

Conclusão

Os tokens não são apenas uma unidade técnica criada pelos fornecedores de inteligência artificial. Eles afetam a arquitetura, o desempenho e o custo de qualquer aplicação que utilize uma LLM.

Durante o desenvolvimento, alguns centavos podem parecer irrelevantes. Em produção, com milhares de usuários, históricos extensos e agentes executando várias etapas, esses valores crescem rapidamente.

Antes de publicar uma integração, registre o consumo, limite as respostas, controle o histórico, escolha o modelo adequado e crie alertas de orçamento.

Tokens não são o problema. O problema é consumi-los sem saber onde, como e por quê.

Fontes consultadas