BigQuery limite les requêtes IA pour éviter les dépassements de budget

BigQuery verrouille l’IA générative pour éviter les dérapages

Google Cloud renforce la gouvernance de BigQuery avec un système de quotas quotidiens destiné à encadrer l’usage des fonctions d’IA générative. L’enjeu est clair : permettre aux équipes d’exploiter des modèles de langage directement dans SQL, tout en gardant la main sur les coûts. Dans une entreprise, cela peut servir à classer des milliers de tickets support, analyser des avis clients ou extraire des informations métier sans déplacer les données vers un autre outil.

Pourquoi ce changement est important

• Limiter les dépenses liées aux appels de modèles génératifs.
• Protéger les projets contre une requête trop gourmande.
• Donner du contrôle aux administrateurs avant que la facture ne grimpe.

Des quotas qui s’appliquent par projet et par utilisateur

Le dispositif repose sur quatre limites journalières configurables depuis Google Cloud IAM. Deux concernent les tokens d’entrée, deux autres les tokens de sortie. Par défaut, BigQuery autorise jusqu’à 200 milliards de tokens par jour et par projet pour l’entrée, et 150 milliards par utilisateur dans un projet. Côté sortie, les plafonds sont fixés à 20 milliards par projet et 15 milliards par utilisateur. Cette logique permet de prévenir à la fois les excès globaux et les usages individuels trop intensifs.

Le point essentiel, c’est que BigQuery additionne la consommation sur toutes les régions. Impossible donc de contourner discrètement la règle en répartissant les traitements géographiquement. De plus, les administrateurs peuvent réduire les quotas immédiatement ou demander une hausse si l’activité de l’équipe le justifie.

Ce que ces quotas couvrent

• Tokens d’entrée consommés par les requêtes.
• Tokens de sortie générés par le modèle.
• Tokens de raisonnement, inclus dans le calcul de sortie.
• Consommation globale additionnée sur l’ensemble des régions.

Les fonctions d’IA les plus utilisées sont surveillées

Les garde-fous concernent plusieurs fonctions majeures de BigQuery : AI.GENERATE, AI.CLASSIFY, AI.IF, AI.SCORE et AI.AGG. Elles couvrent les usages de génération de texte et de tableaux fondés sur un grand modèle de langage. En revanche, les fonctions d’embedding ne sont pas incluses, Google considérant qu’elles reposent sur des modèles différents et généralement moins coûteux.

Si un quota est déjà atteint, la requête est rejetée avec une erreur QuotaExceeded. Si la limite est franchie en plein traitement, BigQuery stoppe l’envoi de nouveaux appels au modèle. Certaines lignes peuvent alors retourner des résultats partiels, tandis que d’autres restent marquées en erreur. Cette approche est plus ferme qu’une simple alerte budgétaire : le traitement s’arrête réellement au lieu de continuer jusqu’au prochain contrôle comptable.

Effets concrets sur l’exécution

• Blocage immédiat quand le quota est épuisé.
• Arrêt des appels en cours d’exécution si la limite est atteinte.
• Résultats partiels possibles sur certaines lignes.
• Traçabilité des éléments non traités grâce aux erreurs renvoyées.

AI.COUNT_TOKENS aide à anticiper la consommation

Google ajoute aussi AI.COUNT_TOKENS, une fonction pensée pour évaluer la taille d’un texte avant de lancer un traitement. Elle calcule le nombre de tokens que le tokenizer du modèle associerait à une entrée donnée, sans déclencher d’appel génératif facturable. Les équipes peuvent ainsi tester un échantillon ou analyser une colonne entière afin d’estimer le volume d’entrée avant production.

Cette estimation reste toutefois partielle. Elle ne prend pas en compte les réponses générées, les tokens de raisonnement, certaines instructions ajoutées par les fonctions ni les contenus non textuels. Google illustre cette logique avec Gemini 3.1 Flash-Lite, dont le coût en traitement par lots dans BigQuery est annoncé à 0,125 dollar par million de tokens d’entrée et 0,75 dollar par million de tokens de sortie.

Exemple de calcul budgétaire

• Un ratio moyen de 100 tokens d’entrée pour 1 token de sortie peut servir de repère.
• Un budget d’environ 100 dollars par jour correspondrait à des volumes très élevés.
• Dans l’exemple fourni, cela représenterait environ 754 millions de tokens entrants et 7,54 millions de tokens sortants.

Un vrai levier de gouvernance pour les équipes FinOps

Ces quotas ne remplacent pas les plafonds de dépenses classiques de Google Cloud, mais ils agissent plus tôt et de façon plus ciblée sur l’IA générative. Pour les équipes FinOps, l’intérêt est évident : mieux maîtriser les coûts avant qu’une campagne d’analyses massives ou une expérimentation mal calibrée ne fasse exploser la facture. Google recommande notamment de s’appuyer d’abord sur les limites par utilisateur, afin qu’un seul test ne monopolise pas le budget de tout un projet.

La vigilance doit aussi porter sur la sortie, souvent plus coûteuse que l’entrée. Réduire la longueur des réponses ou encadrer les requêtes peut faire baisser rapidement la consommation. Enfin, la gestion peut être automatisée avec l’API Cloud Quotas, gcloud ou Terraform, ce qui facilite l’application des mêmes règles à plusieurs projets dans les grandes organisations.

Les bonnes pratiques à retenir

• Fixer des quotas par utilisateur pour éviter les abus isolés.
• Surveiller les tokens de sortie, souvent les plus coûteux.
• Tester les volumes avec AI.COUNT_TOKENS avant déploiement.
• Automatiser les règles pour maintenir une gouvernance cohérente.

BigQuery gagne en puissance, mais aussi en prévisibilité

Avec ces nouveaux garde-fous, BigQuery ne rend pas l’IA moins chère par nature ; il la rend plus prévisible. Les entreprises peuvent désormais exploiter les fonctions génératives à grande échelle tout en conservant une visibilité fine sur l’usage réel. Entre performance, contrôle et maîtrise budgétaire, Google Cloud cherche clairement à rendre l’IA intégrée au SQL plus sûre pour les équipes techniques comme pour les responsables financiers.