Wie Databricks Frontier-Modelle ab Tag 1 für 12.000 Mitarbeiter bereitstellt

Unseren Mitarbeitenden Zugang zu hochmodernen AI-Funktionen zu bieten, hat bei Databricks oberste Priorität. Daher ist es uns wichtig, dass sie neue Modelle sofort nutzen können, sobald diese verfügbar sind. Gleichzeitig ist es keine einfache Aufgabe, mehr als 12.000 Menschen schnellen Zugriff auf ein neues Modell zu gewähren, da:

1. Modelle, die als wegweisend vermarktet werden, sind es oft gar nicht. Beispielsweise war Opus 5.0 teurer und schnitt bei unseren Ingenieurinnen und Ingenieuren sowohl bei den quantitativen als auch bei den qualitativen Qualitätsbewertungen schlechter ab als Opus 4.8. Die Migration zu einem Modell, das hinter den aktuellen Stand der Technik zurückfällt, kann einem Unternehmen eher schaden als nützen. Unserer Erfahrung nach ist bei der Evaluierung von Modellen größte Sorgfalt geboten, bevor Workloads massenhaft auf neue Modelle migriert werden.
2. Die unbedachte Nutzung eines neuen Modells kann die Kosten explodieren lassen. Als wir GPT Astra für eine Kontrollgruppe ohne entsprechende Kostendämpfungsmaßnahmen freigaben, gaben Entwickler im Durchschnitt 60 % mehr aus als vor dem Zugriff auf Astra. Eine Kostensteigerung von 60 % über Nacht ist bei einer Nutzerschaft von über 10.000 Personen für ein Unternehmen nur sehr schwer einzuplanen. Als wir besser verstanden, für welche Aufgaben Astra besonders gut geeignet ist, konnten wir die Nutzung so steuern, dass die Gesamtkosten erheblich gesenkt wurden.

In diesem Beitrag stellen wir eine Reihe von Techniken vor, mit denen wir den meisten Mitarbeitenden bei Databricks ab dem ersten Tag („Day 1“) Zugriff auf neue Modelle gewähren. Gleichzeitig können wir so bewerten, ob sich diese Modelle auch langfristig bewähren. Diese Techniken stützen sich stark auf das Unity Gateway, um neue Modelle flexibel freizugeben, zu evaluieren und zu integrieren. Die Woche des 21. September war ein entscheidender Test für diese Fähigkeiten, als Opus 5, GPT-6 Sol und GPT-Luna in rascher Folge veröffentlicht wurden. In dieser Woche bot Databricks allen Mitarbeitenden ab dem ersten Tag Zugriff, und an Tag 3 hatten wir genügend Daten gesammelt, um zu bestätigen, dass diese Modelle an der Effizienzgrenze lagen, was zu ihrer Integration in unsere breitere Infrastruktur führte.

Der Lebenszyklus von Modell-Releases

 Grob gesagt durchlaufen neue Modell-Releases bei Databricks eine Pipeline, die wie folgt aussieht:

1. Neue Modelle sofort allen Mitarbeitenden auf „experimenteller“ Basis zur Verfügung stellen.
2. Die Nutzung neuer Modelle basierend auf einem Budget pro Nutzer einschränken.
3. Nach dem Sammeln ausreichender Daten entscheiden, ob das Modell in die Produktion übernommen (oder sogar als Standard festgelegt) werden soll.

Schritt 1: Neue Modelle sofort verfügbar machen

Um das Modellmanagement über geschlossene und offene Modellanbieter hinweg zu vereinfachen, nutzen wir für die gesamte interne Verwendung unser eigenes Databricks Unity Gateway. Dies ist unser zentraler Hub für AI-Governance, Kostenmanagement und Observability, daher ist es nur logisch, dass wir hier ansetzen.

Über das Gateway ermöglichen wir allen Mitarbeitenden den Zugriff auf das neu veröffentlichte Modell. Eine serverseitige Konfiguration reicht jedoch nicht aus. Unsere Mitarbeitenden nutzen Claude Code, Codex und das Omnigent-Meta-Harness auf ihren Laptops, und wir müssen die neue Modellkonfiguration an sie verteilen.

Hier kommt das Unity Gateway CLI (UG CLI) ins Spiel. Das UG CLI läuft bereits auf den Laptops aller Mitarbeitenden und wird über unser Mobile Device Management bereitgestellt. Wann immer jemand Claude Code, Codex oder Omnigent startet, wird das UG CLI ausgeführt, um nach neuen Modellen, Tools und Skills zu suchen, und aktualisiert die Konfiguration des lokalen Harness. UG ermöglicht es uns außerdem, standardmäßige und experimentelle Modelle zentral festzulegen, Modelle für das Smart Routing vorzubereiten und Traces zu sammeln, um jeden Modell-Rollout zu evaluieren.

Wir haben das Unity Gateway so konfiguriert, dass es experimentelle Konfigurationen für Opus 5.5 und Sol 6 bereitstellt. Diese Modelle werden nun mit diesem Tag angezeigt, sodass Mitarbeitende sie auswählen können, aber wissen, dass es sich um ein neues Modell handelt, das möglicherweise nicht das beste seiner Klasse ist oder nicht dauerhaft verfügbar bleibt:

Claude Code / Modellausgabe kennzeichnet Ous 5.5 eindeutig als experimentell

Schritt 2: Nutzung über ein Budget pro Nutzer einschränken

Wir haben bereits darüber geschrieben, wie wir Budgets pro Nutzer für AI-Ausgaben konfigurieren. Seitdem haben wir unsere Gesamtbudget-Architektur um vier Hauptbudgets erweitert, die jeweils auf Nutzerbasis definiert sind:

1. Monatliches Maximum: Jeder Nutzer hat eine monatliche Gesamtobergrenze für Ausgaben über alle Modelle hinweg.
2. Tägliches Limit für unkontrollierte Ausgaben: Jeder Nutzer hat ein tägliches Maximum, das direkt in Slack erhöht werden kann, um versehentliche Ausgaben durch eine außer Kontrolle geratene Session zu vermeiden.
3. [Neu!] Budget für Spitzenqualität: Wir weisen einen bestimmten Teil des monatlichen Budgets den hochwertigsten Modellen an der Qualitätsgrenze zu, wie z. B. GPT Astra und Claude Fable. (Fable ist intern derzeit aufgrund der Datenaufbewahrungsrichtlinien von Anthropic nicht im Einsatz, aber wir arbeiten eng an der Implementierung ihrer neuen Richtlinie.) Dies spiegelt die Absicht wider, dass diese Modelle nicht für den täglichen Gebrauch genutzt, sondern für spezialisierte Aufgaben ausgewählt werden sollten, für die sie besonders geeignet sind, um die 2- bis 3-fachen Kosten im Vergleich zur nächsten Qualitätsstufe zu rechtfertigen.
4. [Neu!] Experimentelles Budget: Ein weiterer Teil des monatlichen Budgets ist für die Nutzung neuer, ungetesteter Modelle vorgesehen. Hierbei versuchen wir, eine schnelle Einführung mit dem Risiko abzuwägen, ein Modell breit bereitzustellen, das sich nicht an der Effizienzgrenze befindet.

Am ersten Tag des Modell-Launches haben wir Opus 5.5 und Sol 6 für alle Mitarbeitenden über das Unity Gateway verfügbar gemacht und sie für das experimentelle Budget getaggt. In den folgenden Tagen haben wir Daten gesammelt, um über die nächsten Schritte zu entscheiden: das experimentelle Tag zu entfernen oder das Modell ganz aus dem Modellkatalog für unsere Entwickler zu löschen.

Übersicht über die Budgeteinrichtung mit den vier Budgets

Schritt 3: Das Modell übernehmen oder verwerfen

Um festzustellen, ob sich das Modell an der Effizienzgrenze befindet, stützen wir uns auf drei Signale:

1. Benchmark-Daten: Wir verfügen über eine Reihe privater Benchmarks, mit denen wir verschiedene Aufgaben testen. Dazu gehören Offline-Benchmarks wie Dokumentenverständnis, die Workspace-Suche und unser eigenes Genie-Produkt sowie Online-Benchmarks, bei denen wir zwei Modelle nebeneinander ausführen und die Ergebnisse für die Erstellung von Pull Requests vergleichen. Wir erweitern und optimieren diese Benchmarks kontinuierlich. Im Idealfall reichen unsere Benchmarks aus, um Kosten und Qualität jedes neuen Modell-Releases schnell zu bestimmen.
    
2. Von Nutzern gemeldete Qualität: Die Freigabe des experimentellen Modells liefert eine Fülle von Erfahrungswerten darüber, wie die Nutzer das neue Modell wahrnehmen. Wir stellen fest, dass eine Gruppe von Power-Usern begierig darauf ist, neue Modelle auszuprobieren und ihre Erfahrungen über Slack und Umfragen auszutauschen.
    
3. Kostenverfolgung über OpenTelemetry-Traces: Das Unity Gateway protokolliert alle Traces an einem zentralen Ort, zusammen mit den Kosteninformationen. Wir können auf Session-Basis vergleichen, wie Pilotnutzer im Vergleich zu den neuesten Modellen Geld für die vorherige Modellgeneration ausgegeben haben. Dies sagt uns zwar nicht unbedingt etwas über die Qualität, gibt uns aber ein gutes Maß für die Kosten.

Für Opus 5.5 und Sol 6 zeichnen alle drei Metriken ein ziemlich einheitliches Bild.

Benchmarks wie unser OfficeQA Pro V2 zeigen, dass Opus 5.5 eindeutig an der Kosten-Qualitäts-Grenze liegt – ein riesiger Fortschritt auf beiden Achsen im Vergleich zu Opus 5. GPT-6 Sol schneidet sowohl bei den Kosten als auch bei der Qualität irgendwo zwischen GPT-5.6 Sol und GPT-5.6 Terra ab.

Nutzerberichte stimmen weitgehend darin überein, dass Opus 5.5 bei Engineering- und Debugging-Aufgaben (die überwiegende Mehrheit unserer Early Adopter sind Engineers) eine deutliche Qualitätssteigerung gegenüber Opus 5 und Opus 4.8 darstellt und sein Schreibstil weitaus bevorzugt wird. GPT-6 Sol hingegen ist im Vergleich zu GPT-5.6 Sol gelegentlich ein Qualitätsrückschritt.

Kosten-Tracking ermöglichte es uns, die Nutzung der Early Adopter mit der Nutzung derselben Gruppe eine Woche zuvor zu vergleichen. Die Beibehaltung derselben Kohorte erwies sich als entscheidend, da Early Adopter eher Power-User von AI als Durchschnittsnutzer sind.

Wir wollten die Kosten auf eine Basis von $/Session normalisieren, da Nutzer, die ein neues Modell ausprobieren, beim Experimentieren manchmal ihre Nutzung in Bezug auf die Anzahl der Sessions erhöhen. Wir stellten fest, dass ein einfacher Vergleich auf Basis von $/Session immer noch irreführend war, da sich auch die Verteilung der Sessions veränderte: Early Adopter versuchten mit den neuen Modellen schwierigere Probleme zu lösen als in einer durchschnittlichen Session.

Daher haben wir die Sessions danach stratifiziert, ob es sich um Single- oder Multi-Turn-Sessions handelte und ob Dateiänderungen vorgenommen wurden, und die Verteilung entsprechend neu gewichtet. Die folgende Tabelle zeigt die Ergebnisse für Opus 5.5 vs. Opus 4.8 und GPT-6 Sol vs. GPT-5.6 Sol.

Die GPT-Zahlen sind nicht allzu überraschend, da der Preis um 50 % gesenkt wurde. Wir haben uns jedoch gefreut, dass Opus 5.5 angesichts unserer bisherigen Erfahrungen mit Opus 5 auch für unsere realen Workloads eine erhebliche Preissenkung darstellt.

Unsere Entscheidung

Wir konnten unseren Mitarbeitenden bereits am ersten Tag des Modell-Launches experimentellen Zugriff auf Opus 5 sowie GPT-6 Sol und Luna geben. Innerhalb von drei Tagen hatten wir genügend Daten gesammelt, um zu bestätigen, dass diese Modelle an der Effizienzgrenze liegen, und beschlossen, sie aus dem experimentellen Budget in den Standardbetrieb als allgemein verfügbare Modelle zu übernehmen.

In der nächsten Woche werden wir bei Opus 5.5 noch einen Schritt weiter gehen und es zum Standard für Claude Code machen, da es im Vergleich zu seinen Vorgängern eindeutig eine höhere Qualität bei geringeren Kosten bietet.

Unsere Erfahrung mit GPT-6 Sol deutet darauf hin, dass es GPT-5.6 Sol nicht als Standard für Codex ersetzen wird. Wir werden GPT-6 Sol jedoch aufgrund seines Kostenvorteils gegenüber 5.6 Sol in das Toolkit unseres Smart Routers aufnehmen. 

Insgesamt fanden wir dieses Playbook effektiv, um Modellqualität und -kosten schnell zu bewerten, sodass wir die neuesten Modelle, die sich bewähren, rasch einführen können. Diese Flexibilität ist heute wichtiger denn je, da fast täglich neue Modelle auf den Markt kommen.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag