Summary

  • À partir du 30 octobre 2026, Google prévoit de facturer les jetons TabFM en plus du travail BigQuery hors modèle, mesuré en slots ou octets.
  • Les formules publiées relient les jetons aux lignes, aux colonnes et à n_ensembles; doubler ce dernier double la composante modèle à données identiques.

Une syntaxe simple, une addition divisée

AI.PREDICT fait entrer la prédiction tabulaire dans une requête BigQuery. On fournit des exemples étiquetés, des lignes à prédire, et le modèle TabFM renvoie une classification ou une régression. Aucun déploiement séparé ne vient rappeler au responsable du budget qu'un nouveau produit vient d'être acheté. La documentation de la fonction apporte ce rappel : à compter du 30 octobre 2026, les jetons consommés par TabFM seront facturés, tandis que le reste de la requête continuera d'utiliser des slots ou des octets traités. Au 28 octobre, c'est une règle annoncée pour une date future.

Pendant la préversion, le calcul suit les slots pour Enterprise et Enterprise Plus, ou les octets traités à la demande. Le changement ne supprime pas ce compteur de l'entrepôt pour le travail hors inférence. Il ajoute le compteur du modèle. C'est une manière élégante de vendre deux choses au sein d'un seul geste technique. Pour l'utilisateur, la prédiction reste une ligne SQL. Pour le contrôle des coûts, elle devient deux décisions.

Le multiplicateur est écrit dans la formule

La grille tarifaire de Google fixe le prix à 0,05 dollar par million de jetons d'entrée et 0,20 dollar par million de jetons de sortie. Les entrées sont calculées ainsi : (lignes d'entraînement × colonnes + lignes à prédire × (colonnes − 1)) × n_ensembles. Les sorties valent lignes prédites × n_ensembles. Le nombre de colonnes comprend les caractéristiques et la colonne cible retenues dans le calcul. n_ensembles représente les versions réordonnées des données dont les prédictions sont moyennées. Ce paramètre multiplie les deux volumes de jetons. Google limite par ailleurs les caractéristiques à 50 colonnes dans la documentation produit.

Prenons un exemple construit pour lire la formule : un million de lignes étiquetées, vingt colonnes, 100 000 lignes à prédire, quatre ensembles. Le modèle compterait 87,6 millions de jetons d'entrée et 400 000 de sortie. Aux tarifs affichés, cela représente 4,46 dollars pour le modèle. Porter le nombre d'ensembles à huit porte cette composante à 8,92 dollars. Il ne s'agit ni d'une facture client ni du coût total : il manque les slots ou octets de la requête et les conditions commerciales propres au compte. L'exemple montre où se trouve la manette, pas combien paie un client réel.

La dépense quitte le seul bureau des achats

Le choix des ensembles peut être fait par une personne qui cherche une meilleure prédiction, pas par celle qui négocie la capacité BigQuery. Une requête récurrente peut ainsi doubler sa composante modèle sans modification de contrat ni nouvelle infrastructure. La facilité de TabFM a une conséquence organisationnelle : le budget doit suivre la requête jusqu'à ses paramètres, et non s'arrêter au volume de calcul de l'entrepôt.

Pour une expérience isolée, quelques dollars attirent peu l'attention. Pour une application qui relance les prédictions à chaque mise à jour, la fréquence transforme cette ligne en dépense régulière. Il faut donc noter les lignes d'apprentissage, les lignes prédites, les colonnes, les ensembles et la cadence des appels avant de promettre un coût stable. Un ensemble supplémentaire mérite une amélioration mesurée, pas seulement l'enthousiasme pour une option disponible.

Google a publié le tarif, la formule et la date; aucune facture rattachée à une charge de travail identifiable n'est fournie ici. Une facture après le 30 octobre, rapprochée des paramètres et du plan de requête, montrera l'effet réel. Pour l'heure, le déplacement de pouvoir est visible : la ligne SQL reste unique, mais son auteur peut désormais actionner deux compteurs.

Sources