Databricks integriert Entscheidungsmodelle in SQL: Make-or-Buy im Praxistest

Jeder Head of Data, der einen GenAI-Budgetposten für 2026 im Blick hat, sollte den aktuellen Databricks-Beitrag zweimal lesen. Eine neue Klasse sogenannter „System One"-Entscheidungsmodelle – günstige, schnelle Klassifikatoren, die aus einer festen Auswahl an Optionen wählen – ist jetzt aus einer SQL-Zelle heraus gegen geregelte Lakehouse-Daten aufrufbar. Das kollabiert einen Workflow, den die meisten Teams derzeit an einen externen Anbieter-Endpunkt auslagern, in einen einzigen ai_query-Aufruf – und das, ohne dass jemand eine GPU bereitstellen muss.

Was passiert ist

Am Wochenende erschienen eine Reihe sogenannter System-One-Entscheidungsmodelle, mit Jev als Flaggschiff. Wie Databricks beschreibt, handelt es sich um Foundation-Modelle, die darauf ausgelegt sind, gut kalibrierte Entscheidungen aus einer diskreten Menge von Optionen zu liefern – also für Klassifikation und Routing gebaut, nicht für offene Textgenerierung. Sie gelten als extrem schnell und günstig, was genau das Merkmal ist, das zählt, wenn Millionen von Zeilen bewertet werden müssen.

Die Open-Source-Community folgte nahezu unmittelbar und veröffentlichte Open-Weight-Varianten wie Smelf-open-jev, Laya und Kev. Databricks hat anschließend eine davon – SemIf-OpenJev – in ein Demo-Notebook eingebunden, das Hotelbewertungen als gut oder schlecht klassifiziert, und zwar gegen Daten, die bereits im Lakehouse liegen.

Die Mechanik ist bewusst unspektakulär: Ein Nutzer importiert das Notebook, wählt einen Modellnamen und ein Schema, wählt Serverless GPU und klickt auf „Run All". Das Notebook lädt die Modelldateien herunter, registriert das Modell über Express Deployments und richtet automatisch einen GPU-Model-Serving-Endpunkt ein. Kein Infrastruktur-Ticket, kein Kapazitätsplanungsmeeting, kein Terraform-Review.

Das Interessante ist die Abfrageoberfläche. Der Endpunkt muss keine Chat-Completions-API bereitstellen, da ai_query beliebige benutzerdefinierte Modell-APIs unterstützt. Das bedeutet, dass das SemIf-spezifische Anfrageformat unverändert durchgeleitet wird und die Antwort als strukturierte Spalten zurückkommt, die die ausgewählte Klassifikation und die Optionswahrscheinlichkeiten enthalten. Aus Sicht des Analysten sieht ein Entscheidungsmodell wie eine UDF aus. Aus Sicht der Plattform ist es ein weiterer verwalteter Endpunkt, der denselben Catalog-Regeln unterliegt wie jedes andere Objekt im Workspace. AI Runtime ergänzt das Bild, indem Teams diese Modelle auf Basis ihres eigenen Unternehmenskontexts anpassen oder nachtrainieren können.

Technische Architektur

Der architektonische Schritt verdient eine klare Benennung. Databricks hat die zwei schwierigsten Teile des Betriebs eines Open-Weight-Modells in der Produktion – den Serving-Layer und den Invocation-Layer – genommen und beide in Primitive eingebettet, die auf der Plattform bereits existieren. Model Serving übernimmt den Endpunkt. ai_query übernimmt den Aufruf. Unity Catalog übernimmt die Governance rund um beides. Die Neuerung ist nicht das Modell, sondern das Routing.

Stellen Sie sich vor, wie ein Entscheidungsmodell-Workload vor sechs Monaten aussah: Man wählte einen gehosteten Inference-Anbieter, verhandelte einen Per-Token-Vertrag, schrieb einen Batch-Job, der Zeilen aus dem Lakehouse zog, rief den REST-Endpunkt des Anbieters auf, parste das JSON und schrieb die Ergebnisse zurück. Irgendwo in dieser Pipeline gab es einen Secrets Manager, einen Rate Limiter, eine Retry-Richtlinie und ein Finanzgespräch über Egress-Kosten. Die Databricks-Dokumentation beschreibt nun einen Weg, bei dem das Modell innerhalb der Governance-Grenze liegt und die SQL-Engine es direkt aufruft – was den Großteil dieser Infrastruktur überflüssig macht.

Die Wahrscheinlichkeitsausgabe ist wichtiger als die Klassifikation selbst. Gut kalibrierte Wahrscheinlichkeiten ermöglichen es der nachgelagerten Logik, Schwellenwerte auf Basis von Konfidenz zu setzen, mehrdeutige Fälle zur menschlichen Überprüfung weiterzuleiten und das Monitoring auf Drift in der Verteilung aufzubauen, nicht nur auf Genauigkeit. Für ein Analytics-Team, das bereits dbt-Modelle zur Feature-Erzeugung betreibt, wird das Hinzufügen einer Entscheidungsspalte zu einer inkrementellen Transformation statt zu einem neuen Subsystem. Wer ein dbt-Projekt betreibt, kann sich die Veränderung leicht vorstellen: Der Modellaufruf sitzt dort, wo früher ein CASE-Statement stand – nur dass die Falllogik jetzt gelernt ist.

Serverless GPU ist der stille Ermöglicher. On-Demand-Compute bedeutet, dass der Endpunkt im Leerlauf kein Geld verbrennt – das ist die Einheitswirtschaftlichkeit, die System-One-Modelle für breite Deployments plausibel macht. Ein Klassifikator, der Bruchteile eines Cents pro Zeile kostet und nur dann hochfährt, wenn die Abfrage läuft, ist eine ganz andere Budgetierungsübung als ein dedizierter GPU-Cluster, der auf Spitzendurchsatz ausgelegt ist.

Wer unter Druck gerät

Am stärksten exponiert ist die mittlere Schicht von KI-Anbietern, die gehostete Klassifikations- und Routing-Endpunkte verkaufen. Wenn der Kernwert Ihres Produkts eine REST-API vor einem fein abgestimmten Klassifikator ist und die Daten Ihres Kunden bereits in Databricks oder Snowflake liegen, ist die Reibung Ihrer Integration zu einer Wettbewerbsschwäche geworden. Der CFO des Käufers wird feststellen, dass derselbe Workload innerhalb des bestehenden Lakehouse-Vertrags ohne neue Bestellung läuft.

Der CFO eines Series-B-Fintechs oder iGaming-Betreibers, der auf verwaltete Entscheidungssysteme setzt, sollte seinem VP Engineering diese Woche eine konkrete Frage stellen: Wie viel unseres aktuellen Inference-Budgets entfällt auf Workloads, die sich als „wähle eine von N Optionen gegen eine Zeile in unserem Warehouse" ausdrücken lassen? Wenn die Antwort mehr als ein Viertel der Rechnung ausmacht, hat sich das Erneuerungsgespräch mit dem aktuellen Anbieter für 2026 grundlegend verändert – und die Initiative liegt beim Plattform-Team, das eine Alternative in einem Notebook prototypisieren kann.

Zweite Risikogruppe: interne ML-Plattform-Teams, deren Auftrag es war, eine eigene Serving-Infrastruktur aufzubauen. Die Make-or-Buy-Rechnung verschiebt sich, wenn die „Buy"-Seite des Hauptbuchs aufhört, eine Drittanbieter-SaaS zu bedeuten, und stattdessen ein Feature im bestehenden Data-Warehouse-Vertrag wird. Head-of-Platform-Rollen, die auf Kubernetes-basiertem Model Serving aufgebaut wurden, werden sich vor der Aufgabe sehen, Komplexität zu rechtfertigen, die ein serverloser Endpunkt bereits eliminiert hat.

Dritte Risikogruppe: Compliance- und Rechtsteams bei regulierten Betreibern, die im Q3 damit beschäftigt waren, Datenverarbeitungsverträge mit externen Inference-Anbietern auszuhandeln. Wird das Modell auf geregelten Lakehouse-Daten ausgeführt, entfällt die DPA-Frage weitgehend, da die Daten die Vertrauensgrenze nie verlassen. Das ist ein Gewinn für den General Counsel – und ein Grund für den Einkauf, Vorgänge wieder zu öffnen, die man für abgeschlossen hielt.

Playbook für Datenteams

Beginnen Sie mit einer Bestandsaufnahme. Ziehen Sie die externen Inference-Ausgaben der letzten neunzig Tage und kennzeichnen Sie jeden Workload entweder als generativ (Langformausgabe) oder entscheidend (wähle eine von N). Der entscheidende Bucket ist Ihre Liste der Migrationskandidaten. Alles, was einen gehosteten Klassifikator für Sentiment, Intent, Routing, Betrugserkennung oder Content-Moderation trifft, gehört auf diese Liste.

Führen Sie als Nächstes das importierbare Notebook gegen einen echten Workload aus – nicht gegen ein Demo-Dataset. Wählen Sie einen Klassifikationsjob, bei dem Sie der Ground Truth bereits vertrauen, führen Sie SemIf-OpenJev darüber aus und vergleichen Sie die Wahrscheinlichkeitsverteilungen mit der Ausgabe Ihres bisherigen Anbieters. Die Kalibrierung entscheidet darüber, ob diese Modelle ihren Wert beweisen oder nicht – und diese Antwort brauchen Sie vor der Anbieterverlängerung, nicht danach.

Drittens: Setzen Sie AI Runtime Post-Training für Q1 auf die Roadmap. Standard-Open-Weights bewältigen generische Fälle, aber die differenzierten Gewinne entstehen durch die Anpassung des Modells an Ihre Taxonomie, Ihre Randfälle und Ihr regulatorisches Vokabular. Teams, die das als One-Click-Deployment behandeln, erhalten One-Click-Ergebnisse. Teams, die Budget für Post-Training einplanen, erhalten verteidigungsfähige Genauigkeit bei den Workloads, die wirklich zählen.

Überarbeiten Sie abschließend Ihr Governance-Modell. Ein über SQL aufgerufener Modell-Endpunkt ist eine neue Art von Objekt im Catalog, und die Audit-Geschichte darum, wer welches Modell gegen welche Zeilen aufgerufen hat, muss explizit sein, bevor ein Auditor fragt. Besser, diese Richtlinie in diesem Quartal zu schreiben, als sie unter Zeitdruck nachzurüsten.

Wichtigste Erkenntnisse

• System-One-Entscheidungsmodelle wie Jev und seine Open-Weight-Varianten (Smelf-open-jev, Laya, Kev) reduzieren Klassifikations-Workloads auf ein SQL-Primitiv in Databricks via ai_query.
• Serverless GPU in Kombination mit Express Deployments eliminiert den Infrastruktur- und MLOps-Aufwand, der In-House-Serving bislang zu einer Make-or-Buy-Abwägung machte.
• Strukturierte Ausgaben inklusive Optionswahrscheinlichkeiten ermöglichen es der nachgelagerten Analyse, Schwellenwerte auf Basis von Konfidenz zu setzen, statt einfach ein Label zu akzeptieren.
• Gehostete Klassifikationsanbieter geraten bei Verlängerungen unter Druck, da geregelte Lakehouse-Daten die Inference innerhalb der bestehenden Vertragsgrenze ziehen.
• Teams, die den Einsatz von Entscheidungsmodellen evaluieren, sollten jetzt prüfen, ob ihre aktuellen externen Inference-Ausgaben vertretbar sind, gemessen an einem Workload, der nativ im Warehouse läuft.