TL;DR
Genie verursacht zwei Arten von Kosten – und nur eine davon lässt sich leicht kontrollieren. Budgets über das Unity AI Gateway decken die LLM-Nutzung ab. Für das Compute, das Genie auslöst – SQL Warehouses und Serverless-Jobs –, gibt es keine vergleichbare Kontrolle und keinen Genie-Tag in Ihren Abrechnungsdaten. Die Lösung ist kein besserer Report, sondern eigenes Compute für Genie-Workloads mit konsistentem Tagging. So ist die Zuordnung von Anfang an eingebaut, statt nachträglich rekonstruiert zu werden, wenn die Rechnung längst da ist.
Databricks-Kostenoptimierung bedeutet meist: Right-Sizing von Clustern oder das Korrigieren von Auto-Termination-Policies. Genie bringt eine Besonderheit mit, die diese Playbooks nicht abdecken: einen Workload, der echtes Compute auslösen kann, ohne jemals als Position aufzutauchen, nach der Sie suchen könnten. Im ersten Beitrag dieser Serie haben wir Genies vier Tools vorgestellt, im zweiten haben wir gezeigt, was Genie tatsächlich kostet – inklusive eines echten Tests, bei dem die KI-Nutzung leicht messbar war, das Compute aber nicht. In diesem Beitrag geht es darum, diese Lücke zu schließen, bevor sie Sie mehr kostet als eine Rechercheübung.
Diese Lücke wird Databricks voraussichtlich nicht von selbst schließen. Die meisten Antworten eines Genie Agents und die meisten Genie-Code-Sessions generieren SQL oder Code und führen ihn anschließend aus – und genau dafür ist Compute da. Aber nicht immer: Ein Genie Agent kann eine allgemeine Frage mitunter beantworten, ohne eine Tabelle anzufassen, und Genie Code generiert oft Code, ohne ihn auszuführen. Wo tatsächlich ausgeführt wird, bekommt die KI-Nutzung, die den Code erzeugt hat, ein sauberes Label. Die Ausführung selbst nicht. Diese Trennung ist kein Versehen, sondern spiegelt das Produktdesign von Databricks wider – und deshalb muss auch die Lösung architektonisch sein.
Warum sehen Sie Genies Kosten nicht einfach auf der Rechnung?
Databricks taggt Genies LLM-Nutzung explizit. Jeder Datensatz trägt billing_origin_product = 'GENIE', sodass Sie filtern, gruppieren und summieren können, ohne zu raten. Das von Genie ausgelöste Compute bekommt diese Behandlung nicht. Eine SQL-Warehouse-Rechnung sagt: Ein Warehouse hat Queries ausgeführt. Sie sagt nicht, ob eine Person dieses SQL getippt oder ein Genie Agent es generiert hat.
Gartner prognostiziert, dass bis 2027 40 % der Unternehmen autonome KI-Agenten zurückstufen oder abschalten werden, weil Governance-Lücken erst dann sichtbar werden, wenn in der Produktion bereits etwas schiefgelaufen ist. Kostentransparenz ist Teil genau dieser Governance-Lücke. Mit der Zuordnung zu warten, bis Finance eine Frage stellt, die Sie nicht beantworten können, ist der teure Weg, das zu lernen.
Was deckt die Kontrolle der LLM-Seite tatsächlich ab?
Unity-AI-Gateway-Budgets – auf Account, Workspace, Benutzergruppe oder einzelne User beschränkt und mit databricks-product: genie getaggt – geben Ihnen einen echten Hebel für Genies LLM-Ausgaben. Genie One, Agents und Code laufen alle über denselben Mechanismus, ein Budget deckt also die ganze Produktfamilie ab. Tags sind additiv: Weitere Tags brechen das Tracking nicht, sondern liefern lediglich eine granularere Sicht auf dieselben Genie-Ausgaben.
Das ist ein gelöstes Problem – und das sollte man klar sagen: Wer nur Genie-Budgets aufsetzt und dann aufhört, hat vielleicht die Hälfte des Risikos abgedeckt. Die größere Hälfte bleibt offen.
Warum ist die Compute-Seite so viel schwieriger?
Genie Agents führen SQL gegen das Warehouse aus, auf das sie zeigen – in der Regel dasselbe, das ohnehin schon alles andere im Workspace nutzt. Genie Code startet Serverless Compute, um den geschriebenen Code auszuführen. Keines von beidem bekommt standardmäßig einen Genie-spezifischen Tag. Wer Genies Compute-Kosten im Nachhinein sucht, muss system.billing.usage mit system.query.history und system.compute.warehouse_events korrelieren, Zeitstempel abgleichen und hoffen, dass im selben Moment nichts anderes lief. Für einen einzelnen Test funktioniert das. Es bricht in dem Moment zusammen, in dem mehr als ein Workload dasselbe Warehouse nutzt – also in jeder realen Umgebung.
McKinsey hat ermittelt, dass 93 % der Organisationen mit KI-Workloads ihre KI-Budgets bereits überschritten haben – und nicht erfasstes Compute trägt direkt zu diesem Muster bei. Eine Zahl, die Sie nur nachträglich rekonstruieren können, lässt sich nicht managen.
Genau auf dieses Problem sind wir bei unseren eigenen Genie-Tests gestoßen. Unser E-Book Databricks Genie Explained führt durch den kompletten Test – inklusive der Query, mit der wir Genies tatsächliche DBU-Nutzung direkt aus den Billing-Tabellen gezogen haben.
Wie machen Sie Genies Compute zuordenbar?
Geben Sie Genie, wo immer möglich, eigenes Compute, statt ein Warehouse mit Dashboards, Ad-hoc-SQL und allem anderen zu teilen. Ein dediziertes SQL Warehouse für Genie Agents macht aus einer unbeantwortbaren Frage eine einfache: Genie-Warehouse mal DBU-Rate gleich Genie-bedingte SQL-Kosten. Keine Korrelation, kein Zeitstempel-Abgleich, kein Raten.
Taggen Sie dieses Compute so, wie Sie alles andere taggen würden, das Sie nachverfolgen müssen: konsistente Warehouse-Tags und Tags für Serverless-Budget-Policies – angewendet, bevor der Workload läuft, nicht nachträglich rekonstruiert. Die Allocation-Practice der FinOps Foundation behandelt Tagging und Namenskonventionen auf Ressourcenebene als Basismechanismus, um geteilte oder mehrdeutige Kosten zuzuordnen – und Genies Compute ist genau die Art mehrdeutiger Kosten, für die diese Practice existiert. Dediziertes Compute isoliert den Workload. Tags identifizieren ihn. Sie brauchen beides, nicht das eine statt des anderen.
Nicht jeder Agent braucht ein eigenes Warehouse. Reservieren Sie das für die volumenstarken oder geschäftskritischen Agents, bei denen Kostentransparenz wirklich zählt – und lassen Sie kleinere, gelegentlich genutzte Agents sich den Platz teilen, bis sie sich durch ihre eigene Nutzung ein dediziertes Warehouse verdient haben.
Und wie sieht es speziell bei Genie Code aus?
Genie Code lässt sich schwerer isolieren als Genie Agents, weil ein Teil der Ausführung auf Serverless Compute läuft statt auf einem Warehouse, das Sie selbst provisionieren und benennen. Sie können Genie Code also nicht einfach auf dieselbe Weise an ein dediziertes Warehouse binden. User-Attribution, Serverless-Budget-Policies und konsistente Tags tragen hier deutlich mehr Gewicht. Halten Sie fest, welcher User oder Service Principal Genie Code ausführt, wenden Sie eine auf diese Nutzung beschränkte Budget-Policy an und taggen Sie die gestarteten Serverless-Jobs, damit sie als Genie-Compute erscheinen statt als anonyme Position.
Wie sieht das Ganze aus, wenn es einmal eingerichtet ist?
Ein dediziertes, getaggtes und isoliertes Genie-Warehouse macht aus einer Frage, für die Sie früher eine Korrelations-Query brauchten, eine Frage, die Sie mit einem Blick aufs Dashboard beantworten. Genau darum geht es. Sie bauen keinen schlaueren nachträglichen Report, sondern verlagern, wo der Workload läuft – damit die Rechnung die Antwort bereits enthält. Statt system.billing.usage jedes Mal mit Query-History und Warehouse-Events zu joinen, wenn jemand nach Genies Kosten fragt, filtern Sie auf einen Warehouse-Tag und lesen die Zahl direkt ab.
Dasselbe gilt für Genie Code: Sobald Serverless-Jobs einen konsistenten Tag und einen bekannten Owner haben, ist "Was kostet uns Genie Code?" keine Recherchefrage mehr, sondern ein Filter. Beide Maßnahmen berühren die LLM-Seite überhaupt nicht – und genau das ist der Punkt. Genie-Budgets haben das bereits abgedeckt. Hier geht es allein darum, die andere Hälfte genauso sichtbar zu machen.
Eine Plattform wie SELECT for Databricks ist genau für diese Art von Abgleich gebaut: Sie verknüpft DBU-Kosten mit den zugrunde liegenden Cloud-Infrastrukturkosten, damit die Compute-Seite von Genie nicht jedes Mal manuell zusammengestückelt werden muss, wenn jemand danach fragt.
Was sollten Sie konkret tun – und in welcher Reihenfolge?
Beginnen Sie mit dem Budget. Setzen Sie ein Unity-AI-Gateway-Budget auf Genies LLM-Nutzung, getaggt mit databricks-product: genie und sonst nichts, mit einer gemeinsamen Alert-Schwelle plus User-spezifischen Schwellen für ungewöhnlich intensive Nutzer. Alerts sind hier einer harten Sperre vorzuziehen, denn ein erschöpftes gemeinsames Budget stoppt Genie für alle im Geltungsbereich – nicht nur für die Person, die es ausgelöst hat.
Dann kümmern Sie sich um die Compute-Seite. Geben Sie Ihren volumenstärksten oder geschäftskritischsten Genie Agents ein dediziertes SQL Warehouse. Taggen Sie dieses Warehouse und alle mit Genie Code verknüpften Serverless-Budget-Policies konsistent – und zwar bevor die Nutzung über eine Handvoll Pilotanwender hinauswächst. Behalten Sie Service Principals separat im Blick, denn sie erhalten bei keinem Genie-Produkt ein Freikontingent, und ihre Nutzung skaliert anders als die einer Person, die sich durch ein Chat-Interface klickt.
Nichts davon ist Genie-spezifisch. Es ist dieselbe Disziplin, die gute Databricks-Kostenoptimierung ohnehin erfordert: Compute mit konsequentem Right-Sizing, konsistente Tags und Workloads, die sich nicht ineinander verstecken. Genie kommt lediglich als weitere Bedarfsquelle hinzu, auf die Sie diese Disziplin anwenden.
Sie möchten den Rest der Geschichte – was Genie eigentlich ist, was eine echte Session kostet und wie Sie die Kosten zuordenbar halten? Alle drei Themen an einem Ort finden Sie in unserem E-Book Databricks Genie Explained.
Häufig gestellte Fragen
Was bedeutet Databricks-Genie-Kostenoptimierung?
Die Praxis, Genies Ausgaben – sowohl die LLM-Nutzung als auch das ausgelöste Compute – sichtbar und steuerbar zu machen, statt sie nach Eintreffen der Rechnung zu rekonstruieren. Das heißt: Unity-AI-Gateway-Budgets für die LLM-Nutzung und dediziertes, getaggtes Compute für die SQL- und Serverless-Jobs, die Genie startet.
Kontrollieren Genie-Budgets die Compute-Kosten?
Nein. Unity-AI-Gateway-Budgets mit dem Tag databricks-product: genie decken nur die LLM-Nutzung ab. Das von Genie ausgelöste SQL-Warehouse- und Serverless-Compute wird separat abgerechnet und braucht eigenes dediziertes Compute und Tagging, um zuordenbar zu bleiben.
Warum sollten Genie Agents ein dediziertes SQL Warehouse bekommen?
Weil ein geteiltes Warehouse Genies Queries mit allem anderen vermischt, das darauf läuft – die Rechnung kann Ihnen also nicht sagen, welcher Anteil von Genie stammt. Ein dediziertes Warehouse macht daraus eine direkte Rechnung: Die DBU-Kosten des Warehouse sind Genies Kosten, ohne dass etwas rekonstruiert werden muss.
Ist Genie Code schwerer zuzuordnen als Genie Agents?
Ja. Genie Code läuft auf Serverless Compute statt auf einem selbst provisionierten Warehouse und lässt sich daher nicht auf dieselbe Weise isolieren. User-Attribution, Serverless-Budget-Policies und konsistentes Tagging sind bei Genie Code wichtiger als dediziertes Compute.
Wie hilft SELECT for Databricks bei der Genie-Kostenoptimierung?
Es gleicht Databricks-DBU-Kosten an einem Ort mit den zugrunde liegenden Cloud-Infrastrukturkosten ab und adressiert damit dasselbe Problem wie dediziertes Genie-Compute und Tagging: Ausgaben, die in Standard-Abrechnungsdaten normalerweise unsichtbar sind, dem Workload zuzuordnen, der sie verursacht hat.