Como analisar o seu ficheiro de uso de LLM

De onde exportar o uso

Comece onde o fornecedor guarda os números. A OpenAI expõe o uso em dois lugares: a página de uso da consola do fornecedor, que resume a atividade por dia e modelo do período de faturação em curso, e a API de uso, que devolve os mesmos dados como JSON — intervalos de tempo, cada um com resultados por modelo, com tokens de contexto, tokens gerados e contagens de pedidos. Vale a pena conhecer essa forma JSON porque é a que pode arquivar, comparar e alimentar a ferramentas sem capturas de ecrã. Um hábito que vale a pena começar hoje: extraia a resposta da API uma vez por mês e guarde-a. Os fornecedores mantêm apenas uma janela limitada de histórico na consola; o seu próprio arquivo é o único registo completo do que realmente gastou, mês a mês.

A Anthropic expõe relatórios de uso e custo através da sua consola e das suas APIs de relatórios no mesmo espírito: agregados por dia e modelo, exportáveis como dados tabulares. Outros fornecedores variam no polimento mas não no tipo — um download CSV de uma página de uso ou faturação, ou um endpoint de API que devolve linhas datadas. A forma genérica é tudo o que qualquer análise precisa: uma data, um nome de modelo, tokens de entrada, tokens de saída e, com sorte, tokens em cache, contagens de pedidos e uma coluna de custo. Se o seu fornecedor oferece várias exportações, fique com a mais granular: diária por modelo ganha à mensal por projeto, porque a agregação que você faz pode sempre ser desfeita, e a que o fornecedor fez não.

O que o ficheiro realmente contém

Uma linha de uso é uma afirmação pequena e densa: nesta data, este modelo atendeu tantos pedidos, leu tantos tokens de entrada — dos quais tantos estavam em cache — e escreveu tantos tokens de saída. Leia um ficheiro com essas colunas e poderá reconstruir quase tudo sobre a forma de uma carga: se os prompts são longos ou curtos, se as respostas são verbosas, se o tráfego é estável ou em rajadas, e que modelos fazem o trabalho real. O que o ficheiro deliberadamente não contém importa igualmente: nenhum texto de prompt, nenhuma conclusão, nenhum conteúdo do utilizador. São contagens e nomes, e é por isso que pode ser tratado com mais liberdade do que o tráfego que descreve — embora, como argumenta a última secção, “com mais liberdade” não seja “em qualquer lugar”.

Duas colunas merecem suspeita antes de qualquer análise. A primeira é o custo: algumas exportações trazem o custo faturado, outras uma estimativa a preço de tabela, e outras nenhum, e o ficheiro raramente rotula qual. Trate uma coluna de custo como o número do fornecedor, mas verifique o intervalo de datas e as linhas ignoradas ou parciais antes de confiar num total. A segunda é a coluna de tokens em cache, que os fornecedores nomeiam de pelo menos cinco maneiras diferentes e por vezes dobram dentro da contagem de entrada em vez de a desdobrar. Se os tokens de entrada parecerem implausivelmente baratos ou caros para o modelo, os cabeçalhos são o primeiro lugar a olhar — e é por isso que o analisador lhe mostra o seu mapeamento de colunas, detetado a partir dos cabeçalhos, e lhe permite corrigi-lo antes de qualquer cálculo.

O que procurar: três padrões

Primeiro, a proporção de tokens em cache. Divida a entrada em cache pela entrada total, por modelo. Cargas com qualquer estrutura repetida — um prompt de sistema, um prefixo de documento, um esquema fixo de ferramentas — deveriam colocar em cache uma grande parte da sua entrada, porque esse prefixo é idêntico em cada chamada. Uma proporção perto de zero numa carga assim significa que a cache está desligada, que a cache expira entre chamadas, ou que algo no prefixo muda em cada pedido — um carimbo de tempo, um id aleatório, um campo reordenado — e a derrota silenciosamente. Corrigir esse único número vale rotineiramente mais do que renegociar o modelo, porque a entrada em cache é faturada a uma fração da tarifa completa em cada grande fornecedor.

Segundo, a mistura de modelos. Ordene os modelos por custo, não por pedidos: a mistura é saudável quando a parcela de custo do nível caro corresponde aproximadamente à parte do trabalho que genuinamente precisa dele. A deriva a vigiar é a parcela de custo de um modelo de topo a subir mês após mês enquanto a sua parcela de pedidos se mantém estável — prompts mais longos, saídas mais longas, ou tráfego novo encaminhado silenciosamente para o modelo grande por um padrão que ninguém se lembra de ter definido. Terceiro, a concentração e os picos: uma chave de API, projeto ou modelo que domina o ficheiro é um facto de raio de explosão tanto como de custo, e um pico diário — sobretudo ao fim de semana ou durante a noite, quando ninguém trabalhava — é a assinatura de um ciclo de tentativas, um agente descontrolado ou uma chave vazada em uso. A tabela diária existe para tornar esse pico impossível de ignorar.

Valorar um ficheiro que não traz custos

Muitas exportações não têm nenhuma coluna de custo, e então a análise tem de valorar o próprio ficheiro. O analisador fá-lo da maneira transparente: cada linha é valorada a partir da tabela de preços de LLM deste site — as tarifas de tabela verificadas que a calculadora de custos também usa — com a própria fórmula do fornecedor: entrada sem cache à tarifa de entrada, entrada em cache à tarifa de cache quando existe, saída à tarifa de saída. Os nomes dos modelos são correspondidos com rigor: exatamente, depois de remover um prefixo de fornecedor, ou depois de retirar um sufixo final de data ou “latest”. Esse rigor é o ponto. Uma correspondência mais lata e difusa acabaria por valorar um ajuste fino como o seu modelo base ou uma pré-visualização como a versão final, e o total ganharia uma confiança que não mereceu.

É por isso que os modelos que não correspondem a nada são listados, não adivinhados. Os seus tokens e pedidos continuam a contar — pode ver o seu volume e julgar se a lacuna importa — mas o seu custo fica em branco, e o resultado é rotulado com a origem do seu dinheiro: o próprio ficheiro, calculado a partir da tabela, uma mistura, ou nenhum. Segure qualquer total calculado por esse padrão ao lê-lo: é aritmética a preço de tabela sem conhecimento dos seus descontos, créditos, tarifas em lote ou preços por níveis de contexto longo, por isso não reconciliará ao cêntimo com uma fatura. O que faz com fiabilidade é ordenar: que modelos, que dias, que padrões dominam a fatura. No trabalho de custos, a ordenação costuma ser a parte relevante para a decisão.

Privacidade, e uma rotina mensal

Um ficheiro de uso não contém texto de prompts, mas continua a ser operacionalmente sensível: nomeia cada modelo que executa, os seus volumes por dia, a sua curva de crescimento e os seus gastos — uma impressão digital competitiva e relevante para a segurança de como um sistema é construído. É por isso que o analisador de uso de LLM analisa o ficheiro localmente no seu navegador e nunca o envia. A regra geral viaja muito para além desta ferramenta: quanto mais um ficheiro resume a sua infraestrutura, pior ideia é colá-lo num chat alojado ou num conversor desconhecido, mesmo quando o ficheiro não contém segredos no sentido literal. Os agregados também vazam, só que mais silenciosamente.

Termine com uma rotina suficientemente pequena para acontecer de verdade. Uma vez por mês: exporte o ficheiro, analise-o e anote quatro números — o custo total e a sua fonte, a parcela de custo do modelo principal, a proporção de tokens em cache e o maior dia individual. Compare-os com os quatro números do mês passado. Essa diferença de cinco minutos apanha a deriva, o pico e a cache derrotada enquanto ainda são baratos, e ao longo de um ano constrói o arquivo que nenhuma consola de fornecedor guardará por si. As faturas surpreendem quem só lê faturas. Raramente surpreendem quem lê o uso.

Perguntas frequentes