TL;DR
Genie a deux coûts, et un seul est facile à contrôler. Les budgets Unity AI Gateway couvrent la partie usage LLM. Le compute déclenché par Genie, SQL warehouses et jobs serverless, ne dispose d'aucun contrôle équivalent ni d'aucun tag Genie dans vos données de facturation. La solution ne réside pas dans un meilleur rapport : elle consiste à donner aux workloads Genie leur propre compute et à le taguer de manière cohérente, afin que l'attribution soit intégrée dès le départ au lieu d'être reconstituée après réception de la facture.
L'optimisation des coûts Databricks se résume généralement à redimensionner les clusters ou à corriger les politiques d'arrêt automatique. Genie ajoute une subtilité que ces playbooks ne couvrent pas : un workload capable de déclencher du compute bien réel sans jamais apparaître comme une ligne identifiable sur la facture. Nous avons présenté les quatre outils de Genie dans le premier article de cette série et détaillé ce que Genie coûte réellement dans le second, avec un test réel où l'usage IA était facile à mesurer, contrairement au compute. Cet article explique comment combler cet écart avant qu'il ne vous coûte bien plus qu'un simple exercice de recherche.
Cet écart, Databricks ne le comblera probablement pas de lui-même. La plupart des réponses des Genie Agents et la plupart des sessions Genie Code génèrent du SQL ou du code puis l'exécutent, et exécuter, c'est précisément le rôle du compute — mais pas toujours : un Genie Agent peut parfois répondre à une question générale sans toucher à une table, et Genie Code génère souvent du code sans l'exécuter. Lorsqu'il y a exécution, l'usage IA qui l'a générée est clairement identifié. L'exécution elle-même, non. Cette séparation reflète la conception du produit par Databricks, pas un oubli, et cela signifie que la solution doit elle aussi être architecturale.
Pourquoi votre facture ne montre-t-elle pas le coût de Genie ?
Databricks tague explicitement l'usage LLM de Genie. Chaque enregistrement porte billing_origin_product = 'GENIE' : vous pouvez donc filtrer, regrouper et totaliser sans deviner. Le compute déclenché par Genie n'a pas droit au même traitement. Une facture de SQL warehouse indique qu'un warehouse a exécuté des requêtes. Elle ne dit pas si c'est une personne qui a saisi ce SQL ou un Genie Agent qui l'a généré.
Gartner prévoit que d'ici 2027, 40 % des entreprises rétrograderont ou mettront hors service leurs agents IA autonomes, les lacunes de gouvernance n'apparaissant qu'une fois qu'un incident s'est déjà produit en production. La visibilité des coûts fait partie de cette même lacune de gouvernance. Attendre que la direction financière pose une question à laquelle vous ne savez pas répondre pour résoudre l'attribution, c'est la façon la plus coûteuse d'apprendre cette leçon.
Que couvre réellement le contrôle de la partie LLM ?
Les budgets Unity AI Gateway, définis au niveau d'un compte, d'un workspace, d'un groupe d'utilisateurs ou d'utilisateurs individuels et tagués databricks-product: genie, vous offrent une réelle maîtrise des dépenses LLM de Genie. Genie One, Agents et Code sont tous mesurés via le même mécanisme : un seul budget couvre donc toute la famille. Les tags sont additifs, en ajouter davantage ne casse pas le suivi. Vous obtenez simplement une vue plus granulaire des mêmes dépenses Genie.
C'est un problème résolu, et il faut le dire clairement : si vous vous contentez de configurer des budgets Genie et que vous vous arrêtez là, vous n'avez couvert qu'environ la moitié du risque. La moitié la plus importante reste à traiter.
Pourquoi la partie compute est-elle tellement plus difficile ?
Les Genie Agents exécutent du SQL sur le warehouse vers lequel ils pointent, généralement celui que tout le reste du workspace utilise déjà. Genie Code démarre du compute serverless pour exécuter le code qu'il écrit. Ni l'un ni l'autre ne reçoit de tag spécifique à Genie par défaut. Si vous cherchez a posteriori le coût compute de Genie, vous voilà contraint de corréler system.billing.usage avec system.query.history et system.compute.warehouse_events, d'aligner les horodatages et d'espérer que rien d'autre ne tournait au même moment. Cela fonctionne pour un test isolé. Cela s'effondre dès que plusieurs workloads touchent le même warehouse, c'est-à-dire dans tout environnement réel.
McKinsey a constaté que 93 % des organisations exécutant des workloads IA ont déjà dépassé leurs budgets IA, et le compute non suivi contribue directement à ce phénomène. Impossible de piloter un chiffre que l'on ne peut que reconstituer après coup.
C'est précisément le mur contre lequel nous nous sommes heurtés en testant Genie nous-mêmes. Notre ebook, Databricks Genie Explained, détaille le test complet, y compris la requête utilisée pour extraire l'usage DBU réel de Genie directement depuis les tables de facturation.
Comment rendre le compute de Genie attribuable ?
Donnez à Genie son propre compute partout où c'est possible, plutôt que de partager un warehouse avec les dashboards, le SQL ad hoc et tout le reste. Un SQL warehouse dédié aux Genie Agents transforme une question insoluble en calcul simple : le warehouse Genie, multiplié par son tarif DBU, donne le coût SQL lié à Genie. Pas de corrélation nécessaire, pas d'alignement d'horodatages, pas de devinettes.
Taguez ce compute comme vous tagueriez tout ce que vous devez suivre : des tags de warehouse cohérents et des tags de budget policy serverless, appliqués avant l'exécution du workload, pas reconstitués après. La pratique d'allocation de la FinOps Foundation considère le tagging et les conventions de nommage au niveau des ressources comme le mécanisme de base pour attribuer les coûts partagés ou ambigus, et le compute de Genie est exactement le type de coût ambigu que cette pratique vise à résoudre. Le compute dédié isole le workload. Les tags l'identifient. Il vous faut les deux, pas l'un à la place de l'autre.
Tous les Agents n'ont pas besoin de leur propre warehouse. Réservez-le aux Agents à fort volume ou critiques pour le métier, là où la visibilité des coûts compte vraiment, et laissez les Agents plus modestes ou occasionnels partager l'espace jusqu'à ce que leur usage justifie un warehouse dédié.
Et Genie Code en particulier ?
Genie Code est plus difficile à isoler que les Genie Agents, car une partie de son exécution tourne sur du compute serverless plutôt que sur un warehouse que vous provisionnez et nommez vous-même. Impossible de le pointer vers un warehouse dédié de la même manière. L'attribution par utilisateur, les budget policies serverless et des tags cohérents font ici l'essentiel du travail. Identifiez l'utilisateur ou le service principal qui exécute Genie Code, appliquez une budget policy ciblée sur cet usage, et taguez les jobs serverless qu'il démarre pour qu'ils apparaissent comme du compute Genie plutôt que comme une ligne anonyme.
À quoi cela ressemble-t-il concrètement une fois en place ?
Un warehouse Genie dédié, tagué et isolé, transforme une question qui exigeait auparavant une requête de corrélation en une réponse lisible directement sur un dashboard. C'est tout l'intérêt. Vous ne cherchez pas à construire un rapport a posteriori plus intelligent. Vous changez l'endroit où le workload s'exécute pour que la facture contienne déjà la réponse. Au lieu de joindre system.billing.usage à l'historique des requêtes et aux événements de warehouse chaque fois que quelqu'un demande combien coûte Genie, vous filtrez sur un seul tag de warehouse et lisez le chiffre directement.
Même chose pour Genie Code : une fois que les jobs serverless portent un tag cohérent et un propriétaire connu, combien nous coûte Genie Code cesse d'être une question de recherche pour devenir un simple filtre. Aucune de ces solutions ne touche à la partie LLM, et c'est précisément le but. Les budgets Genie s'en chargent déjà. Il s'agit uniquement de rendre l'autre moitié aussi facile à voir.
Une plateforme comme SELECT for Databricks est conçue exactement pour ce type de réconciliation : elle rapproche les frais DBU du coût de l'infrastructure cloud sous-jacente, pour que la partie compute de Genie n'ait pas à être reconstituée manuellement chaque fois que quelqu'un pose la question.
Que faire concrètement, et dans quel ordre ?
Commencez par le budget. Définissez un budget Unity AI Gateway sur l'usage LLM de Genie, tagué databricks-product: genie et rien d'autre, avec un seuil d'alerte partagé plus des seuils par utilisateur pour les usages anormalement intensifs. Les alertes valent mieux qu'un blocage strict : épuiser un budget partagé stoppe Genie pour tout le périmètre concerné, pas seulement pour la personne à l'origine du dépassement.
Corrigez ensuite la partie compute. Attribuez un SQL warehouse dédié à vos Genie Agents les plus sollicités ou les plus critiques. Taguez ce warehouse et toutes les budget policies serverless liées à Genie Code de manière cohérente, avant que l'usage ne dépasse une poignée d'utilisateurs pilotes. Surveillez les service principals séparément : ils ne bénéficient d'aucune allocation gratuite sur les produits Genie, et leur usage monte en charge d'une manière qu'une personne cliquant dans une interface de chat n'atteindra jamais.
Rien de tout cela n'est propre à Genie. C'est la même discipline que toute bonne optimisation des coûts Databricks exige déjà : du compute correctement dimensionné, des tags cohérents et des workloads qui ne se cachent pas les uns dans les autres. Genie ajoute simplement une source de demande supplémentaire vers laquelle diriger cette discipline.
Envie de connaître la suite de l'histoire : ce qu'est réellement Genie, ce que coûte une vraie session et comment garder le tout attribuable ? Retrouvez les trois volets au même endroit dans notre ebook, Databricks Genie Explained.
Questions fréquentes
Qu'est-ce que l'optimisation des coûts de Databricks Genie ?
C'est la pratique consistant à rendre les dépenses de Genie, son usage LLM comme le compute qu'il déclenche, visibles et contrôlables plutôt que reconstituées après réception de la facture. Cela passe par des budgets Unity AI Gateway pour l'usage LLM et par du compute dédié et tagué pour les jobs SQL et serverless lancés par Genie.
Les budgets Genie contrôlent-ils les coûts de compute ?
Non. Les budgets Unity AI Gateway, tagués databricks-product: genie, ne couvrent que l'usage LLM. Le SQL warehouse et le compute serverless déclenchés par Genie sont facturés séparément et nécessitent leur propre compute dédié et leur propre tagging pour rester attribuables.
Pourquoi les Genie Agents devraient-ils disposer d'un SQL warehouse dédié ?
Parce qu'un warehouse partagé mélange les requêtes de Genie avec tout ce qui s'exécute dessus : la facture ne peut pas vous dire quelle part provient de Genie. Un warehouse dédié transforme cela en calcul direct : le coût DBU du warehouse est le coût de Genie, sans rien à reconstituer.
Genie Code est-il plus difficile à attribuer que les Genie Agents ?
Oui. Genie Code s'exécute sur du compute serverless plutôt que sur un warehouse que vous provisionnez vous-même, et ne peut donc pas être isolé de la même manière. L'attribution par utilisateur, les budget policies serverless et un tagging cohérent comptent davantage pour Genie Code que le compute dédié.
Comment SELECT for Databricks aide-t-il à optimiser les coûts de Genie ?
Il réconcilie au même endroit les frais DBU de Databricks avec le coût de l'infrastructure cloud sous-jacente, ce qui répond au même problème que le compute Genie dédié et le tagging : rendre des dépenses normalement invisibles dans les données de facturation standard attribuables au workload qui les a générées.