Como controlar custos e quotas de IA numa empresa
Uma empresa pode ter saldo disponível e, ainda assim, receber um erro de quota. Pode também ter um modelo barato que fica caro quando é chamado sem limites. Custos, billing, quotas e utilização são dimensões diferentes e precisam de ser observadas em conjunto.
Saldo, preço e quota não são a mesma coisa
O preço indica quanto uma operação pode custar. O saldo ou billing indica se a conta pode pagar. A quota limita quantos pedidos, tokens ou segundos podem ser usados num período.
Um erro HTTP 429 aponta normalmente para quota ou rate limit; não prova, por si só, que não existe saldo.
Estimar antes de executar
Antes de uma geração de imagem, áudio ou vídeo, a aplicação deve calcular uma estimativa usando modelo, duração, resolução e número de resultados. O utilizador deve confirmar operações pagas e o sistema deve rejeitar tarefas acima do orçamento máximo.
A estimativa e o valor efectivamente facturado devem ficar em campos diferentes.
Um orçamento por tarefa e por período
Defina um limite por pedido, por utilizador, por projecto e por mês. O limite mensal evita uma surpresa global; o limite por tarefa impede que um retry ou uma duração inesperada consuma todo o orçamento.
Para desenvolvimento, o modo mock deve ser o comportamento predefinido.
429 não deve provocar uma tempestade de retries
Repetir imediatamente um pedido que foi rejeitado por quota só aumenta a pressão sobre o limite. Use backoff, respeite Retry-After quando existir e diferencie 429 de 401, 403, 402, timeout e erro de validação.
Os erros de autenticação ou de formato devem ser corrigidos, não repetidos automaticamente.
O que registar sem guardar segredos
Registe provider, modelo, modalidade, duração, resolução, tokens quando fornecidos, custo estimado, custo real, latência, status, request_id e motivo de falha. Nunca registe API keys, prompts com dados pessoais desnecessários ou respostas sensíveis.
Um painel útil mostra consumo por equipa e tarefa, não apenas um total mensal.
A leitura da PontoTi
A arquitectura deve permitir trocar de fornecedor sem trocar toda a aplicação. LiteLLM pode centralizar aliases, routing e observabilidade; OpenRouter pode dar acesso a vários providers; APIs directas podem ser necessárias para modalidades específicas.
Em todos os casos, a aplicação deve verificar capacidades, limites e custo antes de executar.