Quanto custam realmente os tokens LLM e como pagar por menos deles

Cada fatura de API para um modelo de linguagem é uma fatura de tokens, e quase ninguém tem uma intuição de quantos tokens possui um determinado trecho de texto. O resultado é a mesma surpresa duas vezes por mês: um recurso que parecia barato nos testes custa quarenta vezes mais na produção, ou uma janela de contexto que "deveria caber" rejeita a solicitação. Ambos são problemas aritméticos, e vale a pena aprender aritmética uma vez.

Um token não é uma palavra

Os modelos não leem caracteres ou palavras. Eles leem tokens – pedaços produzidos por um codificador de pares de bytes que aprendeu, durante o treinamento, quais sequências ocorrem com frequência suficiente para merecer seu próprio símbolo. Palavras comuns em inglês são um símbolo. Os raros se dividem. Então token é um e tokenization é três, enquanto uma string aleatória como x7Qp2 pode custar cinco.

As regras básicas que vale a pena seguir:

• Prosa inglesa: aproximadamente quatro caracteres por token, ou cerca de 0,75 tokens por palavra. Um artigo de mil palavras equivale a cerca de 1.300 tokens.
• Código: consideravelmente pior. Recuo, pontuação e identificadores camelCase, todos fragmentados. Faça um orçamento próximo de três caracteres por token e trate o código minificado como seu próprio desastre – ele tokeniza mal precisamente porque é incomum.
• Escritas não latinas: muito pior novamente. Chinês, japonês e coreano geralmente chegam perto de um token por um ou dois caracteres, então o mesmo conteúdo em japonês pode custar várias vezes mais que a versão em inglês. O cirílico e o grego ficam no meio.
• JSON: a pontuação é dinheiro real. Cada aspa, chave, dois pontos e vírgula é pelo menos parte de um token, e estruturas profundamente aninhadas com nomes de chave longos podem gastar mais em sintaxe do que em valores.

As regras práticas servem para estimar. Quando for importante, conte: o Token LLM e calculadora de custos tokeniza o que você cola e imprime a contagem, e também pode mostrar o texto com os limites do token marcados, que é a maneira mais rápida de entender por que um de seus prompts é inesperadamente caro. Ver seus próprios nomes de identificadores se quebrarem em quatro pedaços explica muito.

A produção custa várias vezes mais do que a entrada

O detalhe do preço que as pessoas não percebem: os provedores cobram separadamente pelos tokens que você envia e pelos tokens que o modelo gera, e a saída normalmente é de quatro a oito vezes a taxa de entrada. Um prompt com 10.000 tokens de contexto e uma resposta de 200 tokens é dominado pela entrada. Um prompt com 500 tokens de instrução que produz uma redação de 4.000 tokens é dominado – fortemente – pelo resultado.

Isso inverte muitos instintos de otimização. Cortar um prompt do sistema de 900 para 600 tokens economiza muito pouco se o modelo estiver escrevendo respostas longas a cada chamada. Dizer ao modelo para responder em três frases em vez de três parágrafos economiza muito. Pergunte em que lado da transação sua carga de trabalho realmente reside antes de otimizar o lado errado.

A calculadora avalia o mesmo texto em relação a cada modelo em sua tabela, tanto nas taxas de entrada quanto na de saída, para que você possa comparar um modelo barato que faz todo o trabalho com um modelo caro que faz parte dele. Os preços de referência são armazenados localmente e verificados periodicamente nas páginas do fornecedor – trate-os como uma ajuda de planejamento e confirme na própria página de preços do fornecedor antes de se comprometer com um orçamento, porque as taxas mudam.

O bate-papo é quadrático e é aí que os orçamentos morrem

Uma chamada única de API custa o que custa. Uma conversa reenvia todo o histórico a cada turno, portanto, um bate-papo de vinte turnos não custa vinte vezes um turno – custa aproximadamente a soma de uma série crescente. O turno vinte paga pelos turnos um a dezenove novamente.

Duas consequências. Primeiro, os loops de agente de longa duração são a forma mais cara de uso do LLM e a que tem maior probabilidade de ser prototipada sem medição. Em segundo lugar, o cache de prompt é mais importante do que qualquer mudança de texto: os provedores descontam tokens que repetem um prefixo que já viram, o que significa colocar seu conteúdo estável – o prompt do sistema, o esquema, os exemplos – bem na frente e a parte variável no final. Reordene o mesmo prompt para que um carimbo de data/hora alterado fique no topo e você invalide o cache em cada chamada sem alterar mais nada.

Reduzindo um prompt antes de enviá-lo

A maioria dos prompts superdimensionados são superdimensionados por motivos enfadonhos: alguém colou um arquivo inteiro quando três funções eram relevantes, e o arquivo contém metade de comentários e linhas em branco. O Compressor de contexto LLM visa exatamente isso - remove comentários de código, recolhe execuções de linhas em branco, diminui e remove palavras de preenchimento da prosa e, em seguida, relata quantos tokens o corte salvou. Em um arquivo de origem real que roda rotineiramente de 20 a 40% sem tocar em nada que o modelo precise.

Os cortes manuais que vale a pena fazer antes disso:

1. Envie trechos, não arquivos. A atenção do modelo também não é gratuita; contexto irrelevante degrada mensuravelmente as respostas, além de custar dinheiro.
2. Retirar os logs para a região com falha. Dez mil linhas de resultados de inicialização bem-sucedidos não contribuem em nada para um diagnóstico.
3. Abandone o clichê repetido. Cabeçalhos de licença, importações geradas, a mesma isenção de responsabilidade em todos os registros.
4. Resuma em vez de reenviar. Em uma longa conversa, substituir as passagens de um a quinze por um parágrafo de estado é a maior economia disponível.

Quando a entrada realmente não se ajusta

As janelas de contexto são grandes agora, mas “grande” ainda é finito, e um livro, um ano de registros ou uma transcrição completa excederá um. A divisão é a resposta padrão, e onde você divide as questões: cortar no meio da frase ou no meio da função produz pedaços que o modelo precisa adivinhar. O divisor de alerta divide o texto em pedaços no tamanho que você escolher, respeitando os limites, e numera as partes para que você possa alimentá-las em sequência com uma instrução consistente anexada a cada uma.

Uma observação sobre unidades: tokens não são bytes. O Contador de bytes UTF-8 responde a uma pergunta diferente - quanto espaço o texto ocupa na transmissão ou em uma coluna do banco de dados - e os dois números divergem acentuadamente para texto não latino, onde os bytes por caractere aumentam ao mesmo tempo que os caracteres por token diminuem. Use bytes para limites de armazenamento e tokens para limites de modelo e nunca substitua um pelo outro.

Um exemplo trabalhado

Suponha que você responda vinte perguntas em um documento de trinta páginas. Trinta páginas equivalem a cerca de 15.000 palavras, ou seja, cerca de 20.000 tokens. Ingenuamente, você envia o documento com cada pergunta: 20 × 20.000 = 400.000 tokens de entrada, mais talvez 20 × 300 tokens de saída.

Coloque o documento primeiro e mantenha-o com bytes idênticos nas chamadas, e a maioria dos provedores servirá o prefixo repetido do cache por uma fração da taxa. Apare o documento padrão primeiro e a base também encolherá. Agrupe cinco perguntas por ligação em vez de uma e você enviará o documento quatro vezes em vez de vinte. A mesma tarefa, o mesmo modelo e uma ordem de grandeza entre a versão descuidada e a cuidadosa - que é o ponto principal de contar antes de enviar.

Tanto o contador quanto o compressor funcionam inteiramente no seu navegador: o prompt que você está precificando não é carregado em nenhum lugar para ser medido.