In einem internen Benchmark auf der eigenen Multi-Millionen-Zeilen-Codebasis schneidet das chinesische Open-Source-Modell GLM 5.2 so gut ab wie Anthropics Opus 4.8, kostet aber weniger. Databricks will es deshalb als tägliches Arbeitsmodell für seine Entwickler einsetzen.
In einem internen Benchmark auf der eigenen Codebasis mit mehreren Millionen Zeilen landete GLM 5.2 im obersten Leistungscluster, statistisch gleichauf mit Anthropics Opus 4.8. Pro Aufgabe kostete es allerdings nur 1,28 US-Dollar gegenüber 1,94 US-Dollar bei Opus.
"Die Belege zeigen, dass es an der Zeit ist, diese Modelle als tägliche Arbeitspferde fürs Coding einzusetzen", schreiben die Autoren des Blogbeitrags, darunter Databricks-Mitgründer Matei Zaharia. Qualitative Rückmeldungen interner Entwickler, die das Modell im Alltag pilotieren, bestätigten die Benchmark-Ergebnisse. Das Unternehmen arbeite bereits daran, GLM mit bestmöglicher Performance zu betreiben.
Drei Leistungsklassen, aber kein einzelner Anbieter dominiert
GLM 5.2 ist dabei nicht die einzige Erkenntnis des Benchmarks. Insgesamt gruppierten sich die getesteten Modelle und Konfigurationen laut Databricks in drei Cluster: Die Spitzengruppe mit 82 bis 90 Prozent Pass-Rate umfasst Opus 4.8, GLM 5.2 und GPT 5.5 in bestimmten Konfigurationen. Eine Mittelgruppe mit 71 bis 82 Prozent beinhaltet unter anderem Sonnet 4.6, Sonnet 5 und GPT 5.4. Am unteren Ende mit 51 bis 60 Prozent stehen GPT 5.4-mini und Haiku 4.5.
Die getesteten Modelle gruppieren sich in drei Leistungscluster: Opus 4.8, GLM 5.2 und GPT 5.5 erreichen in der Spitzengruppe 82 bis 90 Prozent Pass-Rate – die Kosten pro Aufgabe variieren je nach Konfiguration und Umgebung jedoch erheblich. | Bild: DatabricksEine Analyse über Unity AI Gateway ergab zudem, dass rund 61 Prozent der Coding-Aufgaben der Databricks-Ingenieure mittlerer Komplexität entsprechen, etwa 19 Prozent niedriger und nur 12 Prozent hoher Komplexität. Bisher waren die teuersten Modelle der Standard. Auf Basis der Benchmark-Ergebnisse will das Unternehmen nun mehr Arbeit auf günstigere Modellklassen verlagern, abhängig von der Komplexität.
Die Pareto-Grenze, also das beste Verhältnis von Qualität zu Kosten, wird von Modellen dreier Anbieter gebildet: OpenAI, Anthropic und Open Source. Nur ein Mix aus verschiedenen Anbietern biete Frontier-Performance, so Databricks.
Die Pareto-Grenze – das beste Verhältnis von Qualität zu Kosten – wird von Modellen dreier Anbieter gebildet: OpenAI, Anthropic und das Open-Source-Modell GLM 5.2. Viele teurere Konfigurationen liegen deutlich unterhalb dieser Effizienzlinie. | Bild: DatabricksDatabricks weist zudem darauf hin, dass Token-Preis und tatsächliche Aufgabenkosten nicht dasselbe sind. Die Tokeneffizienz, vergleichbar mit dem Spritverbrauch beim Auto, spielt eine ebenso große Rolle und kann sich je nach Software-Umgebung deutlich unterscheiden.
In einem Test sendete der Pi-Harness gegenüber Claude Code etwa dreimal weniger Kontext an das Modell. Bei Opus 4.8 mit "high effort" war Pi so 2,08-mal günstiger bei vergleichbarer Qualität (85 gegenüber 87 Prozent). Bei GPT 5.5 zeigte sich ein ähnliches Muster: Codex verbrauchte 1.235.000 Tokens gegenüber 665.000 bei Pi.
Der Pi-Harness von Databricks sendet deutlich weniger Kontext an die Modelle als die nativen Coding-Umgebungen – und ist dadurch bei vergleichbarer Pass-Rate bis zu 2,08-mal günstiger pro Aufgabe, etwa bei Opus 4.8 mit "high effort". | Bild: DatabricksBenchmark auf echten Aufgaben statt öffentlichen Datensätzen
Um diese Ergebnisse zu erzielen, baute das Databricks-Team einen eigenen Benchmark, statt auf öffentliche Alternativen wie SWE-Bench zu setzen. Deren Aufgabenprofile seien für die eigene Codebasis nicht repräsentativ, so die Begründung: Lösungen sickerten mit der Zeit in Trainingsdaten ein, und die Aufgaben passten nicht zu einem Stack mit über zehn Programmiersprachen, darunter Python, Go, TypeScript, Scala und Rust. So rät etwa OpenAI neuerdings vom relativ neuen SWE-Bench-Pro-Benchmark für Coding-Aufgaben ab, da die Aufgaben teils im Training vorhanden sind oder Designfehler haben.
Die eigenen Benchmark-Aufgaben wurden stattdessen aus echten Pull-Requests konstruiert. Sie mussten aktuell, von Menschen geschrieben, mit hochwertigen Tests versehen und repräsentativ für den gesamten Stack sein. Jede einzelne wurde manuell evaluiert, Tests wurden teilweise umgeschrieben, um alternative Implementierungen zuzulassen. Bewertet wurde ausschließlich anhand bestandener Tests, nicht durch einen LLM-Richter. Laut Databricks belohnt ein solcher eher gut klingende Antworten als tatsächliche Korrektheit.
Auch beim eigenen Benchmark stieß das Team auf ein Schummelproblem: Modelle suchten in der Git-Historie nach der korrekten Lösung, anstatt sie selbst zu erarbeiten. Databricks löste das, indem die Git-Historie für die Dauer jedes Laufs vollständig abgeschnitten wurde.
KI-News ohne Hype – von Menschen kuratiert
Mit dem THE‑DECODER‑Abo liest du werbefrei und wirst Teil unserer Community: Diskutiere im Kommentarsystem, erhalte unseren wöchentlichen KI‑Newsletter, 6× im Jahr den "KI Radar"‑Frontier‑Newsletter mit den neuesten Entwicklungen aus der Spitze der KI‑Forschung, bis zu 25 % Rabatt auf KI Pro‑Events und Zugriff auf das komplette Archiv der letzten zehn Jahre.



