TL;DR
Genie ha due costi, e solo uno dei due è facile da controllare. I budget di Unity AI Gateway gestiscono il lato utilizzo LLM. Il compute che Genie attiva, SQL warehouse e job serverless, non ha un controllo equivalente né un tag Genie nei dati di fatturazione. La soluzione non è un report migliore. È assegnare ai workloads di Genie un compute dedicato e taggarlo in modo coerente, così che l'attribuzione sia integrata fin dall'inizio invece di essere ricostruita dopo l'arrivo della fattura.
L'ottimizzazione dei costi Databricks di solito significa dimensionare correttamente i cluster o sistemare le policy di auto-terminazione. Genie aggiunge una complicazione che questi playbook non coprono: un workload in grado di attivare compute reale senza mai comparire come una voce di costo che si possa cercare. Abbiamo presentato i quattro strumenti di Genie nel primo articolo di questa serie e analizzato quanto costa davvero Genie nel secondo, incluso un test reale in cui l'utilizzo AI era facile da misurare e il compute no. Questo articolo spiega come colmare quel divario prima che costi più di un esercizio di ricerca.
È improbabile che Databricks colmi questo divario da sé. La maggior parte delle risposte di Genie Agent e delle sessioni di Genie Code genera SQL o codice e poi lo esegue, ed eseguire è esattamente ciò a cui serve il compute, ma non sempre: a volte un Genie Agent può rispondere a una domanda generica senza toccare una tabella, e Genie Code spesso genera codice senza eseguirlo. Dove l'esecuzione avviene, l'utilizzo AI che l'ha generata riceve un'etichetta pulita. L'esecuzione in sé no. Questa separazione riflette il modo in cui Databricks ha progettato il prodotto, non una svista, e significa che anche la soluzione deve essere architetturale.
Perché non basta guardare la fattura per vedere il costo di Genie?
Databricks tagga esplicitamente l'utilizzo LLM di Genie. Ogni record riporta billing_origin_product = 'GENIE', quindi è possibile filtrarlo, raggrupparlo e sommarlo senza tirare a indovinare. Il compute che Genie attiva non riceve lo stesso trattamento. La fattura di un SQL warehouse dice che un warehouse ha eseguito query. Non dice se quell'SQL l'ha digitato una persona o l'ha generato un Genie Agent.
Gartner prevede che entro il 2027 il 40% delle aziende declasserà o dismetterà gli agenti AI autonomi dopo che le lacune di governance saranno emerse solo quando qualcosa è già andato storto in produzione. La visibilità dei costi fa parte della stessa lacuna di governance. Aspettare a risolvere l'attribuzione finché il reparto finance non pone una domanda a cui non si sa rispondere è il modo più costoso di imparare questa lezione.
Cosa copre davvero il controllo del lato LLM?
I budget di Unity AI Gateway, applicabili a livello di account, workspace, gruppo di utenti o singoli utenti e taggati databricks-product: genie, offrono un controllo reale sulla spesa LLM di Genie. Genie One, Agents e Code vengono misurati tutti attraverso lo stesso meccanismo, quindi un unico budget copre l'intera famiglia. I tag sono additivi, quindi aggiungerne altri non compromette il tracciamento: si ottiene semplicemente una vista più granulare della stessa spesa di Genie.
È un problema risolto, e vale la pena dirlo chiaramente: chi si limita a impostare i budget di Genie e si ferma lì ha coperto forse metà del rischio. La metà più grande resta aperta.
Perché la parte compute è molto più difficile?
I Genie Agents eseguono SQL sul warehouse a cui puntano, di solito lo stesso già usato da tutto il resto del workspace. Genie Code avvia compute serverless per eseguire il codice che scrive. Nessuno dei due riceve di default un tag specifico per Genie. Chi va a cercare il costo del compute di Genie a posteriori si ritrova a correlare system.billing.usage con system.query.history e system.compute.warehouse_events, cercando di allineare i timestamp e sperando che nient'altro stesse girando nello stesso momento. Funziona per un singolo test. Crolla nel momento in cui più di un workload tocca lo stesso warehouse, cioè in qualsiasi ambiente reale.
McKinsey ha rilevato che il 93% delle organizzazioni che eseguono workloads AI ha già superato il proprio budget AI, e il compute non tracciato contribuisce direttamente a questo schema. Non si può gestire un numero che si riesce solo a ricostruire a posteriori.
È esattamente il muro contro cui ci siamo scontrati testando Genie in prima persona. Il nostro ebook, Databricks Genie Explained, ripercorre l'intero test, inclusa la query che abbiamo usato per estrarre l'utilizzo DBU reale di Genie direttamente dalle tabelle di fatturazione.
Come rendere attribuibile il compute di Genie?
La soluzione è dare a Genie un compute dedicato ovunque possibile, invece di condividere un warehouse con dashboard, SQL ad hoc e tutto il resto. Un SQL warehouse dedicato ai Genie Agents trasforma una domanda a cui era impossibile rispondere in una domanda banale: il warehouse di Genie, moltiplicato per la sua tariffa DBU, dà il costo SQL legato a Genie. Nessuna correlazione necessaria, nessun allineamento di timestamp, nessuna congettura.
Quel compute va taggato come si taggherebbe qualsiasi altra cosa da tracciare: tag coerenti sul warehouse e tag delle budget policy serverless, applicati prima che il workload venga eseguito, non ricostruiti dopo. La pratica di allocazione della FinOps Foundation considera il tagging e le convenzioni di denominazione a livello di risorsa come il meccanismo di base per attribuire costi condivisi o ambigui, e il compute di Genie è esattamente il tipo di costo ambiguo che quella pratica esiste per risolvere. Il compute dedicato isola il workload. I tag lo identificano. Servono entrambi, non l'uno al posto dell'altro.
Non tutti gli Agent hanno bisogno di un proprio warehouse. Meglio riservarlo a quelli ad alto volume o business-critical, dove la visibilità dei costi conta davvero, lasciando che gli Agent più piccoli e occasionali condividano lo spazio finché il loro utilizzo non giustifica un warehouse dedicato.
E Genie Code nello specifico?
Genie Code è più difficile da isolare rispetto ai Genie Agents, perché parte della sua esecuzione avviene su compute serverless anziché su un warehouse di cui si gestisce in autonomia il provisioning e il nome. Non è possibile semplicemente puntarlo su un warehouse dedicato allo stesso modo. L'attribuzione per utente, le budget policy serverless e i tag coerenti pesano di più in questo caso. Occorre sapere quale utente o service principal sta eseguendo Genie Code, applicare una budget policy circoscritta a quell'utilizzo e taggare i job serverless che avvia, in modo che compaiano come compute di Genie e non come una voce anonima.
Che aspetto ha tutto questo una volta configurato?
Un warehouse Genie dedicato, taggato e isolato, trasforma una domanda che prima richiedeva una query di correlazione in una a cui si risponde leggendo una dashboard. È esattamente questo il punto. Non si tratta di costruire un report a posteriori più intelligente, ma di cambiare dove gira il workload, così che la fattura contenga già la risposta. Invece di fare join tra system.billing.usage, la cronologia delle query e gli eventi del warehouse ogni volta che qualcuno chiede quanto costa Genie, si filtra un tag del warehouse e si legge il numero direttamente.
Lo stesso vale per Genie Code: una volta che i job serverless hanno un tag coerente e un owner noto, "quanto ci sta costando Genie Code" smette di essere un lavoro di ricerca e diventa un filtro. Nessuna di queste soluzioni tocca minimamente il lato LLM, ed è proprio questo il punto. I budget di Genie lo coprono già. Qui si tratta solo di rendere l'altra metà altrettanto facile da vedere.
Una piattaforma come SELECT for Databricks è costruita esattamente per questo tipo di riconciliazione: incrocia gli addebiti DBU con il costo dell'infrastruttura cloud sottostante, così il lato compute di Genie non deve essere ricostruito a mano ogni volta che qualcuno lo chiede.
Cosa fare concretamente, e in quale ordine?
Si parte dal budget. Impostare un budget Unity AI Gateway sull'utilizzo LLM di Genie, taggato databricks-product: genie e nient'altro, con una soglia di alert condivisa più soglie per utente per chi fa un uso insolitamente intenso. Gli alert sono preferibili a un blocco rigido, perché esaurire un budget condiviso ferma Genie per tutti gli utenti inclusi, non solo per chi l'ha fatto scattare.
Poi si sistema il lato compute. Assegnare ai Genie Agents a più alto volume o più business-critical un SQL warehouse dedicato. Taggare in modo coerente quel warehouse e qualsiasi budget policy serverless legata a Genie Code, prima che l'utilizzo cresca oltre una manciata di utenti pilota. Monitorare separatamente i service principal, perché non hanno alcuna quota gratuita su nessun prodotto Genie e il loro utilizzo scala in modi diversi da quelli di una persona che clicca in un'interfaccia chat.
Niente di tutto questo è specifico di Genie. È la stessa disciplina che una buona ottimizzazione dei costi Databricks richiede già: compute dimensionato correttamente, tag coerenti e workloads che non si nascondono gli uni dentro gli altri. Genie aggiunge solo un'altra fonte di domanda a cui applicare quella disciplina.
Vuole il resto della storia: cos'è davvero Genie, quanto costa una sessione reale e come mantenere tutto attribuibile? Trova le tre risposte in un unico posto nel nostro ebook, Databricks Genie Explained.
Domande frequenti
Cos'è l'ottimizzazione dei costi di Databricks Genie?
È la pratica di rendere la spesa di Genie, sia l'utilizzo LLM sia il compute che attiva, visibile e controllabile, anziché ricostruita dopo l'arrivo della fattura. Significa budget Unity AI Gateway per l'utilizzo LLM e compute dedicato e taggato per i job SQL e serverless avviati da Genie.
I budget di Genie controllano i costi di compute?
No. I budget Unity AI Gateway, taggati databricks-product: genie, coprono solo l'utilizzo LLM. Il compute attivato da Genie, SQL warehouse e serverless, viene fatturato separatamente e richiede un proprio compute dedicato e un proprio tagging per restare attribuibile.
Perché i Genie Agents dovrebbero avere un SQL warehouse dedicato?
Perché un warehouse condiviso mescola le query di Genie con tutto il resto che gira su di esso, quindi la fattura non può indicare quale parte provenga da Genie. Un warehouse dedicato lo trasforma in un calcolo diretto: il costo DBU del warehouse è il costo di Genie, senza nulla da ricostruire.
Genie Code è più difficile da attribuire rispetto ai Genie Agents?
Sì. Genie Code gira su compute serverless anziché su un warehouse di cui si gestisce il provisioning in autonomia, quindi non può essere isolato allo stesso modo. Per Genie Code, l'attribuzione per utente, le budget policy serverless e il tagging coerente contano più del compute dedicato.
In che modo SELECT for Databricks aiuta con l'ottimizzazione dei costi di Genie?
Riconcilia gli addebiti DBU di Databricks con il costo dell'infrastruttura cloud sottostante in un unico posto, affrontando lo stesso problema risolto da compute dedicato e tagging per Genie: rendere attribuibile al workload che l'ha generata una spesa normalmente invisibile nei dati di fatturazione standard.