Summary

  • Google planeja cobrar tokens do TabFM separadamente a partir de 30 de outubro de 2026; o restante da consulta continua sujeito a slots ou bytes processados.
  • A fórmula oficial faz n_ensembles multiplicar tokens de entrada e de saída; dobrar esse valor dobra a parcela do modelo com os demais dados constantes.

A facilidade de uso tem uma segunda tarifa

AI.PREDICT entrega classificação ou regressão sobre dados tabulares dentro do BigQuery. O usuário fornece exemplos rotulados, linhas para prever e recebe o resultado sem montar uma operação separada de treinamento e implantação. É uma proposta comercial poderosa: menos etapas entre a pergunta e a previsão. A documentação da função mostra a outra metade do negócio. A partir de 30 de outubro de 2026, os tokens consumidos pelo TabFM serão cobrados à parte; slots ou bytes processados continuarão a remunerar o restante da consulta. Escrevo em 28 de outubro, antes da data anunciada. A regra está publicada, mas ainda não é uma fatura observada após sua entrada em vigor.

Na prévia, o uso nas edições Enterprise e Enterprise Plus é medido em slots; na modalidade sob demanda, em bytes processados. A nova estrutura mantém essa medida para o trabalho que não é inferência do modelo e acrescenta uma medida de tokens. O SQL não ficou com duas linhas por isso. O orçamento, sim, precisará de duas colunas.

O fator que multiplica a parcela do modelo

Na tabela oficial de preços, cada milhão de tokens de entrada custa US$ 0,05; o milhão de saída, US$ 0,20. A fórmula de entrada é (linhas de treinamento × colunas + linhas de previsão × (colunas − 1)) × n_ensembles. A saída equivale a linhas previstas × n_ensembles. As colunas incluem os atributos e o rótulo-alvo usados no cálculo. O parâmetro de ensembles conta versões embaralhadas dos dados cujas previsões são combinadas. Ele aparece nas duas fórmulas. Mantidos os demais valores, dobrá-lo dobra o preço de tokens do modelo. A página do TabFM limita o número de colunas de atributos a 50.

Um exemplo deixa a alavanca visível. Com um milhão de linhas rotuladas, vinte colunas, cem mil linhas de previsão e quatro ensembles, a fórmula gera 87,6 milhões de tokens de entrada e 400 mil de saída. Pela tabela, a parcela do modelo seria US$ 4,46. Oito ensembles levariam essa parcela a US$ 8,92. É uma simulação aritmética, não a conta de um cliente: faltam slots ou bytes da consulta, armazenamento e termos comerciais específicos. Ela mostra como uma escolha de configuração vira despesa.

Quem autoriza o parâmetro autoriza a despesa

A equipe de infraestrutura pode controlar a capacidade contratada do BigQuery. Outra equipe pode escolher a quantidade de ensembles, ampliar as colunas ou aumentar a população prevista. Um aplicativo pode repetir a mesma consulta a cada hora. Todas essas decisões fazem a cobrança do modelo crescer sem alterar o contrato de capacidade do depósito de dados. A fronteira do orçamento passa pela função SQL e por sua cadência de execução.

Um teste de poucos dólares parece barato, e pode ser. Numa rotina de produção, a multiplicação pela frequência é a verdadeira história. Se mais ensembles elevam a qualidade da previsão, essa melhora precisa ser medida e comparada com o custo adicional. Se ninguém mede, a empresa comprou um parâmetro porque ele existia. A fórmula pública permite registrar antes do lançamento quantas linhas, colunas, ensembles e execuções o processo terá; depois, permite conferir a conta.

Google informou data, fórmula e preço. Ainda faltam faturas de uma carga identificável após 30 de outubro para medir o peso real dessa mudança. O mecanismo, porém, já está à vista: a previsão entrou no SQL como atalho técnico e sai da cobrança com um taxímetro próprio.

Fontes