Capítulo 14 — Economia de Tokens e Precificação de APIs

Décimo quarto post do passeio capítulo a capítulo pelo LLM Primer VI: Escalando Sistemas de IA. O capítulo que conecta a física do Capítulo 1 aos itens da fatura — e explica por que a conta do primeiro mês costuma não ter nenhuma semelhança com o que o time modelou.

Por que este capítulo existe

Os capítulos anteriores trataram o custo da inferência como um fato físico — bytes movidos pela HBM, FLOPs gastos em um matmul, GPU-segundos consumidos por uma requisição. Esse enquadramento está correto para o time que é dono do silício. Para a população muito maior de times que compra inferência de uma API, a superfície de custo é remodelada pela unidade que o provedor cobra: o token. O Capítulo 14 é sobre por que o token é precificado do jeito que é, por que o lado de input e o lado de output da mesma chamada têm preços tão diferentes, e como o histórico de conversa de um chatbot e o pensamento invisível de um modelo de reasoning acabam, sem alarde, na fatura.

14.1 Output custa 4 a 8× o input porque a decodificação é limitada por banda de memória

Um token de input percorre o caminho do prefill — denso, compute-bound, paralelo por todas as posições do prompt, exatamente o tipo de carga para o qual as GPUs foram projetadas. Em um modelo de 70B, uma H100 processa dezenas de milhares de tokens de input por segundo porque a operação é um matmul largo com alta intensidade aritmética. Um token de output percorre o caminho do decode — sequencial, limitado pela banda de memória, um token por forward pass, e cada passo lê o cache KV inteiro da HBM. A mesma H100 produz 50 a 100 tokens de output por segundo por requisição. A razão entre esses dois throughputs é a razão que a tabela de preços reflete. Modelos de fronteira em 2025 cobram de dois a cinco dólares por milhão de tokens de input e de dez a trinta dólares por milhão de output — uma assimetria de 4:1 a 8:1 que não é escolha de margem, mas repasse direto da assimetria de compute subjacente. Input em cache é ainda mais barato porque o provedor já pagou o custo de prefill em uma requisição anterior. Batch APIs custam metade do preço porque o provedor pode encaixar o trabalho em janelas de capacidade ociosa. Tokens de reasoning são tokens de output porque é isso que eles são dentro do engine.

14.2 A alavanca de otimização depende do formato de input e output

O erro é modelar custo com um único número mental — "token custa X" — em vez de decompor input e output separadamente. Uma triagem de atendimento ao cliente pesada em retrieval, enviando 8.500 tokens de input e recebendo uma resposta de 600 tokens, é dominada pelo custo de input na precificação de fronteira (algo como US$ 255 de input contra US$ 90 de output por 10.000 requisições por dia). Um sistema de redação de textos longos no mesmo volume — 2.200 tokens de input, 3.000 de output — é dominado pelo output (US$ 66 de input contra US$ 450 de output). A orientação de otimização é oposta nos dois casos: encurtar o prompt no primeiro, encurtar a resposta no segundo, e rotear para um modelo cuja curva de preço favoreça o eixo dominante. Uma segunda decomposição que vale rodar é por tenant ou workload. Sistemas multi-tenant quase sempre exibem um viés de lei de potência em que os 10 por cento maiores tenants respondem por metade ou mais do gasto — e trabalho de otimização de custo direcionado a esses tenants paga várias vezes mais do que trabalho uniforme espalhado pela cauda longa.

14.3 A acumulação de contexto e os tokens invisíveis de reasoning compõem a fatura

O token mais caro é o que o time esqueceu que estava sendo enviado. APIs são stateless; toda requisição envia o histórico completo da conversa como input em cada chamada. O custo acumulado de input ao longo de uma conversa de N turnos cresce quadraticamente em N, descontado o crédito de prefix cache. Um time que precificou o sistema em uma baseline de turno único descobre, seis meses depois, que a conversa média agora tem oito turnos e o custo de input por conversa se multiplicou aproximadamente pelo quadrado. O segundo multiplicador silencioso são os tokens de reasoning. Modelos como o1/o3, o extended thinking da Anthropic, o DeepSeek R1 e as variantes de reasoning do Google produzem um volume grande de pensamento interno antes da resposta visível — muitas vezes 4.000 a 8.000 tokens por trás de uma resposta visível de 500 tokens. Esses tokens percorrem o mesmo loop de decode do output e são cobrados como output; eles não são devolvidos ao chamador a menos que o código peça. A mitigação é instrumentar corretamente o objeto usage da resposta da API — prompt_tokens, cached_prompt_tokens, completion_tokens, reasoning_tokens e quaisquer categorias específicas do provedor — e sinalizar categorias desconhecidas em vez de descartá-las em silêncio. Toda nova dimensão faturada que o provedor introduzir precisa aparecer no schema de uso do time, ou a próxima fatura será uma surpresa.

O que o Capítulo 14 prepara

Uma vez que o time consegue ler a própria fatura com a decomposição input-versus-output, por tenant e por categoria, a próxima pergunta — a que finanças fará — é se o time deveria estar pagando por token. O Capítulo 15 percorre a alternativa: trazer a inferência para casa, alugar ou comprar GPUs, e pagar por GPU-hora. A matemática do ponto de equilíbrio é limpa. O que é menos limpo, e o que a maioria dos times subestima, é tudo o que está do lado dedicado do balanço e não aparece na fatura da GPU: a engenharia de plataforma, os patches de segurança, a coreografia de upgrade de modelo, o plantão que atende quando um nó cai da frota.

Próximo — Capítulo 15: APIs Serverless vs Infraestrutura Dedicada. A fórmula do ponto de equilíbrio, o item oculto e as posturas híbridas em que os dois lados são a resposta certa.