FinOps para IA no BigQuery: quotas diárias de tokens para controlar custos

Um pipeline de classificação de chamados pode começar com uma amostra pequena e terminar processando todo o histórico porque um filtro foi removido. Quando a transformação envolve modelos de linguagem, revisar apenas os bytes consultados deixa parte do problema fora do radar.

Em publicação de 14 de outubro de 2026, o Google destacou a disponibilidade geral dos controles diários de tokens para funções generativas do BigQuery. O recurso permite estabelecer limites de consumo por projeto e por usuário. (cloud.google.com)

A proposta deste artigo é transformar esse mecanismo em uma prática operacional: definir orçamento, configurar limites, executar lotes recuperáveis e decidir antecipadamente o que deve acontecer quando a capacidade financeira do dia acabar.

1. O que as quotas controlam

As quatro quotas separam entrada e saída nos escopos de projeto e usuário:

Esses controles não substituem limites de requisições ou de throughput dos modelos. Consulte os valores efetivos do projeto, em vez de assumir que os defaults publicados representam seu orçamento. (docs.cloud.google.com)

O escopo documentado cobre inferência generativa com Gemini, como AI.CLASSIFY e AI.GENERATE_TEXT, mas não embeddings como AI.EMBED. O consumo é global entre regiões; o reset ocorre à meia-noite do horário do Pacífico. Tokens em cache não entram nessas quotas, e a contabilização agregada em milhões reduz a precisão de limites muito pequenos. (docs.cloud.google.com)

Minha recomendação é tratar a quota como uma barreira operacional, não como um medidor financeiro exato. Para produção, mantenha uma margem entre o gasto planejado e o orçamento máximo aprovado.

Quota, alerta e limite de consulta não são equivalentes

Um orçamento configurado apenas para alertas no Cloud Billing não bloqueia automaticamente o consumo. Spend cap budgets são outro mecanismo, cuja cobertura precisa ser verificada para os serviços envolvidos. (docs.cloud.google.com)

Da mesma forma, maximum_bytes_billed e dry runs pertencem ao controle de processamento de consultas. Não interprete uma estimativa de bytes como uma estimativa completa da inferência generativa. (docs.cloud.google.com)

Organize a governança em três camadas: volume de dados consultados, consumo de inferência e despesa consolidada.

2. Arquitetura proposta

Para um enriquecimento assíncrono de chamados, proponho o seguinte fluxo:

Agendador → seleção de pendências → tabela de lote → função generativa → tabela de tentativas → validação → resultados publicados

Em paralelo:

Política FinOps → quotas → controle de admissão do pipeline → alertas → reconciliação financeira

O controle de admissão é uma decisão da aplicação, não uma funcionalidade adicional atribuída ao BigQuery. Ele deve decidir se há margem para iniciar outro lote, levando em conta consumo estimado, concorrência e prioridade.

Separe três responsabilidades:

• Plataforma: administra quotas, identidades e políticas de execução.
• Time de dados: mantém SQL, prompts, validações e reprocessamento.
• Responsável pelo produto: aprova orçamento, atraso tolerável e critérios de qualidade.

Para workloads críticos e experimentais, recomendo projetos de execução separados. A intenção é criar fronteiras explícitas de orçamento, não multiplicar projetos para contornar limites.

Este desenho usa serviços gerenciados e jobs SQL. Kubernetes não é necessário; adicionar um cluster apenas para submeter consultas aumentaria o escopo operacional sem resolver o controle de tokens.

3. Como converter orçamento em tokens

Comece por uma amostra representativa. Separe documentos curtos e longos, idiomas, categorias e casos que exigem respostas maiores. Não dimensione o pipeline apenas pela média de uma amostra conveniente.

Um modelo simplificado de planejamento é:

C_inferencia = (T_entrada / 1.000.000) × P_entrada
             + (T_saida / 1.000.000) × P_saida

Use preços do modelo, modalidade e contrato efetivamente adotados. Cache, armazenamento de cache e outras cobranças aplicáveis devem ser calculados separadamente; exclusão de tokens da quota não significa gratuidade. (cloud.google.com)

Exemplo inteiramente hipotético

Considere as seguintes premissas didáticas, que não representam preços atuais do Google Cloud:

• Orçamento de inferência: US$ 90 por dia.
• Margem operacional escolhida: 20%.
• Valor destinado ao planejamento: US$ 72.
• Entrada fictícia: US$ 1 por milhão de tokens.
• Saída fictícia: US$ 4 por milhão de tokens.
• Relação esperada: cinco tokens de entrada para cada token de saída.

Se I e O representam milhões de tokens:

I = 5 × O
I + 4 × O = 72
O = 8
I = 40

Nesse cenário, o ponto de partida seria 40 milhões de tokens de entrada e 8 milhões de saída por dia. Não é uma recomendação universal nem garantia de fatura máxima.

Uma carga hipotética de 50 mil chamados, com 800 tokens de entrada e 160 de saída por chamado, consumiria exatamente essa previsão. Isso também revela um problema de capacity planning: faltaria margem dentro da quota para retries e documentos maiores. Antes da implantação, reduza a carga admitida ou renegocie a capacidade.

Para vários modelos, prefiro estimativas separadas. Uma média ponderada só deve orientar limites se a distribuição entre modelos estiver controlada. Recalcule a política quando mudar prompt, modelo, tamanho dos documentos ou proporção de reprocessamento.

4. Configuração das quotas

Pelo console

Selecione o projeto correto e abra IAM & Admin → Quotas & System Limits. Filtre por BigQuery API, localize as quatro quotas e use a edição de quota para solicitar os valores desejados. Reduções permitem restringir consumo; aumentos podem exigir análise. (cloud.google.com)

Antes da mudança, registre em uma solicitação versionada:

• Valor atual e valor proposto.
• Justificativa financeira.
• Workloads e identidades afetados.
• Responsável pela aprovação.
• Plano para workloads já em execução.
• Condições para restaurar o limite anterior.

Descoberta pela CLI

Com a Google Cloud CLI autenticada e acesso à Cloud Quotas API, consulte os metadados antes de automatizar:

PROJECT_ID='seu-projeto-de-execucao'

gcloud quotas info list --service=bigquery.googleapis.com --project="$PROJECT_ID" --billing-project="$PROJECT_ID" --format=json

Verifique quotaId, unidade, dimensões e valor efetivo. O projeto usado para consumir a Cloud Quotas API pode ser diferente do projeto administrado; aqui eles são iguais por simplicidade. (docs.cloud.google.com)

Exemplo de preferência para entrada

O comando abaixo cria uma preferência de 40 milhões para a quota de entrada do projeto. Execute somente depois de confirmar o identificador retornado pela API e a inexistência de uma preferência que deva ser atualizada:

gcloud quotas preferences create --project="$PROJECT_ID" --billing-project="$PROJECT_ID" --service=bigquery.googleapis.com --quota-id=GenAiInputTokensPerDay --preferred-value=40000000 --preference-id=finops-genai-input-daily --allow-high-percentage-quota-decrease

A opção --allow-high-percentage-quota-decrease autoriza uma redução superior a 10%. Não acrescente automaticamente --allow-quota-decrease-below-usage: reduzir abaixo do consumo atual exige uma decisão consciente sobre interrupção. (docs.cloud.google.com)

Configure também saída e limites por usuário. Após cada alteração, confira o valor efetivo. Transforme a automação em um processo de reconciliação do estado desejado, não em uma sequência de criações cegas.

5. Exemplo SQL: primeiro delimite, depois gere

O exemplo pressupõe um modelo remoto Gemini existente chamado gemini_model, conexão autorizada e datasets compatíveis com a localização escolhida. A criação da conexão e a autorização da sua service account fazem parte da preparação do ambiente. (docs.cloud.google.com)

Considere a tabela tickets, com ticket_id, body e created_at. O lote abaixo é didático e deve ser executado uma única vez com esses nomes:

CREATE TABLE `seu-projeto.support.ai_batch_20261014_001` AS
SELECT
  ticket_id,
  CONCAT(
    'Classifique o chamado como billing, technical ou other. ',
    'Responda apenas com a categoria. Chamado: ',
    body
  ) AS prompt
FROM `seu-projeto.support.tickets`
WHERE DATE(created_at) = DATE '2026-10-13'
  AND body IS NOT NULL
ORDER BY ticket_id
LIMIT 1000;

CREATE TABLE `seu-projeto.support.ai_attempt_20261014_001` AS
SELECT *
FROM AI.GENERATE_TEXT(
  MODEL `seu-projeto.ai.gemini_model`,
  TABLE `seu-projeto.support.ai_batch_20261014_001`,
  STRUCT(128 AS max_output_tokens)
);

A tabela materializada delimita as linhas enviadas à inferência. A função retorna, entre outros campos, result, status e statistics; status vazio indica sucesso da chamada. O parâmetro max_output_tokens limita a resposta. (docs.cloud.google.com)

No exemplo, LIMIT pertence à etapa de preparação, não ao resultado externo da função. Os nomes fixos e CREATE TABLE, sem substituição, são intencionais: uma repetição não deve sobrescrever silenciosamente a evidência anterior.

Para produção, recomendo:

1. Gerar identificadores únicos para lote e tentativa.
2. Selecionar somente pendências e excluir resultados já aceitos.
3. Associar cada resultado a documento, versão do conteúdo, prompt e modelo.
4. Separar sucesso técnico de aprovação semântica.
5. Publicar apenas categorias permitidas.
6. Manter retenção limitada para prompts e respostas brutas.

Uma resposta com chamada bem-sucedida, mas categoria inválida, deve continuar pendente de tratamento. Não transforme ausência de resultado em uma classificação padrão silenciosa.

6. O que acontece quando a quota acaba

Se a quota necessária já estiver esgotada, a consulta é rejeitada com QuotaExceeded. Se o limite for atingido durante a execução, novas chamadas ao modelo são recusadas. (docs.cloud.google.com)

Em funções compatíveis, como AI.IF, max_error_ratio influencia a possibilidade de resultados parciais. Não suponha que esse argumento exista em todas as funções. (cloud.google.com)

Minha recomendação de recuperação é:

• Quota diária esgotada: suspender novas submissões e aguardar a renovação ou uma alteração aprovada.
• Falha transitória de capacidade: usar tentativas limitadas, atraso exponencial e aleatoriedade no intervalo.
• Erro de permissão ou configuração: interromper retries e corrigir a causa.
• Resposta inválida: encaminhar para validação ou estratégia alternativa previamente aprovada.

Planeje o agendador com America/Los_Angeles, em vez de assumir uma diferença fixa para UTC. Na retomada, libere lotes gradualmente; não dispare todo o backlog simultaneamente.

7. Produção: confiabilidade antes da velocidade

Cenário: problema → solução → implementação → resultado esperado

Problema: um time precisa classificar chamados diariamente, enquanto analistas executam experimentos no mesmo domínio de dados.

Solução proposta: separar experimentação e operação, atribuir orçamento a cada workload e manter o enriquecimento fora do caminho síncrono de atendimento.

Implementação: lotes persistentes, quotas revisadas, identidade dedicada, validação das categorias e checkpoints de resultados aceitos.

Resultado esperado: capacidade de interromper inferência sem interromper a abertura de chamados e de retomar apenas o trabalho pendente. Isso é uma expectativa arquitetural, não uma métrica observada.

Alta disponibilidade e recuperação

Defina um objetivo de nível de serviço, ou SLO, para a idade máxima do backlog. Para esse cenário, a disponibilidade do atendimento e a atualização da classificação devem ser objetivos distintos.

Recomendo persistir o estado do pipeline fora do processo que submete os jobs. Se houver múltiplos executores, coordene a posse dos lotes para evitar submissões duplicadas.

Documente restauração de resultados, retenção de entradas e recuperação de checkpoints. Faça exercícios de falha com orçamento pequeno antes de autorizar reprocessamentos extensos.

Rollback e upgrades

Versione SQL, prompts, referências de modelo e políticas de quota em revisão de código. Para uma mudança, execute um lote canário e compare custo estimado, distribuição das categorias e taxa de rejeição.

O rollback deve interromper novos lotes e restaurar a configuração validada. Não planeje rollback como forma de desfazer consumo já realizado. Ao trocar modelos, revise também os contratos de saída e os critérios de qualidade.

8. Observabilidade e segurança

Observe três planos diferentes

Minha proposta de dashboard reúne:

Use o histórico de quotas do console como uma das fontes de consumo. (cloud.google.com)

Para investigar jobs, a consulta abaixo usa metadados do projeto. Execute na localização correspondente e com permissão de listagem dos jobs:

SELECT
  creation_time,
  job_id,
  user_email,
  state,
  error_result.reason AS error_reason,
  total_bytes_billed,
  total_slot_ms
FROM `seu-projeto.region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND job_type = 'QUERY'
ORDER BY creation_time DESC
LIMIT 100;

Esses campos ajudam a investigar processamento SQL; total_bytes_billed não é um contador de tokens do modelo. Ajuste region-us à localização e correlacione jobs com a telemetria de inferência. (docs.cloud.google.com)

Como política inicial, proponho alertas em 60%, 80% e 90% de consumo, acompanhados de projeção de esgotamento. São limiares de exemplo: calibre-os pelo tempo necessário para reagir.

Menor privilégio

Separe a identidade que executa consultas daquela que altera quotas. Para Cloud Quotas, existem papéis específicos de leitura e administração, como roles/cloudquotas.viewer e roles/cloudquotas.admin. (docs.cloud.google.com)

Na configuração com modelo remoto, diferencie o principal que submete o job da service account da conexão usada para acessar o modelo. A preparação documentada inclui autorização de acesso ao serviço de modelos para essa conexão. (docs.cloud.google.com)

Recomendo remover dados pessoais desnecessários antes da inferência, não registrar prompts completos por padrão e não armazenar chaves de service account no repositório. Inclua conexões, tabelas intermediárias e observabilidade na revisão de acesso.

9. Desenvolvimento, produção e troubleshooting

Em desenvolvimento, use amostras reduzidas, dados sanitizados e limites conservadores. Em produção, exija checkpoints, dono do orçamento, alertas, aprovação de mudanças e procedimento de retomada.

As duas primeiras condições correspondem ao comportamento documentado de enforcement; as demais são hipóteses operacionais para orientar a investigação. (docs.cloud.google.com)

Evite quatro atalhos: aumentar quotas automaticamente após qualquer erro, repetir consultas completas sem analisar resultados anteriores, manter limites permissivos sem responsável e usar logs sensíveis como única evidência de execução.

10. Quando usar e quais alternativas considerar

Recomendo essa abordagem quando o processamento generativo ocorre próximo dos dados analíticos, há volume relevante e o negócio aceita processamento assíncrono com controle de backlog.

Para poucas regras estáveis, avalie primeiro SQL determinístico. Para aplicações que precisam de decisões de admissão por cliente, sessão ou requisição, considere uma camada de aplicação com contabilização própria, mantendo controles do provedor como defesa adicional.

Provisioned Throughput é uma alternativa de capacidade contratada com custo fixo. Nesse modelo, avalie utilização e compromisso contratado, não apenas tokens; um limite diário excessivamente baixo pode bloquear capacidade já reservada. (docs.cloud.google.com)

Minha orientação é comparar complexidade operacional, previsibilidade, necessidade de isolamento e dependência das funções específicas do BigQuery. Não adote uma plataforma adicional apenas porque ela oferece mais controles se a equipe não consegue operá-los de forma consistente.

Resumo prático

• Defina orçamento antes dos limites técnicos.
• Configure entrada e saída, por projeto e por usuário.
• Materialize lotes e preserve evidências das tentativas.
• Separe sucesso da chamada de qualidade do resultado.
• Planeje suspensão, retomada e rollback antes do primeiro incidente.
• Meça custo por resultado aceito, não apenas volume processado.

Conclusão

FinOps para funções generativas deve ser um contrato operacional entre produto, dados e plataforma. A quota representa uma fronteira; o pipeline precisa saber trabalhar dentro dela e falhar de maneira controlada quando a atingir.

Para DevOps, isso significa mudanças revisáveis e reproduzíveis. Para SRE, significa tratar orçamento e backlog como parte da confiabilidade. Para Platform Engineering, significa entregar um caminho padrão em que experimentar seja simples, mas ampliar o impacto financeiro exija intenção e responsabilidade.