CrucibleMark ist meine Reise zur Bewertung der Leistungsfähigkeit von Open-Weight-Modellen im lokalen und Cloud-Hosting. Dieser Weg ist gepflastert mit immer neuen Ideen und Aspekten der Bewertung der Modelle und daraus resultierend die Einordnung dieser neuen Bewertungskriterien in den Gesamtscore. Mit dem Tooluse-Benchmark begann ich zu erfassen, welches Modell wie gut im agentischen Umfeld Werkzeuge nutzen konnte. Leider hat sich diese Bewertung bisher nicht auf den Score ausgewirkt. Bisher.
Die Ausgangslage
Das Tool-Use-Modul lief seit seiner Einführung als eigenständiger Benchmark: Es prüft, ob ein Modell externe Werkzeuge wie Websuche oder HTTP-Fetch tatsächlich aufruft und auswerten kann, oder Ergebnisse nur halluziniert. Aus meiner Sicht ein kritischer Test für Agenten-Pipelines. Das Modul lieferte von Anfang an belastbare Scores, floss aber nicht in den Total Score ein. Das war Anfangs so gewollt, da ich davon ausging, dass nur wenige LLMs Werkzeuge nutzen können. Da ein umfangreicher Test aller Benchmarkmodelle aber zu einem anderen Ergebnis führte, wurde es zur Bewertung der LLMs im produktiven Einsatz immer wichtiger, dass auch dieser Score in die Gesamtwertung einfließt.
Auch ein anderer Punkt wurde mit zunehmender Komplexität des Benchmarks immer wichtiger: Modelle, die im Alltag als starke Allrounder überzeugen, landen im Leaderboard mitunter hinter reinen Coding-Spezialisten. Dies ließ sich nicht durch einen Bugfix beheben. Die Ursache lag im Wesen der Berechnung des Total Score selbst.
Der neue Weg zum Score
Ab Version 5 zieht das Tool-Use-Modul offiziell in die Gesamtformel ein. Gleichzeitig zählt jetzt auch mit, was ein Modell nicht liefert: Fehlende oder fehlerhafte Ergebnisse fließen als moderater Abzug in den Total Score ein, statt einfach herausgerechnet zu werden.
Der Rechenkern
Die eigentliche Formel ist bewusst einfach gehalten: ein gewichteter Durchschnitt über alle Module:
$$ \text{Score} = \frac{\sum (\text{Modul-Score} \times \text{Modul-Gewicht})}{\sum \text{Modul-Gewicht}} $$
Kompliziert wird es nicht durch die Formel selbst, sondern durch das, was vorher entschieden werden muss. Welche Zahl wird für welches Modul überhaupt in Zähler und Nenner der Formel eingesetzt?
Die Klassifikation davor
Bevor der Score berechnet wird, prüft eine Klassifikation pro Modell und Modul, in welchen von vier Zuständen ein Ergebnis fällt:
| Zustand | Bedeutung | Auswirkung auf Formel |
|---|---|---|
present |
Test lief erfolgreich | Score zählt normal in Zähler und Nenner |
missing / unknown |
Test war vorgesehen, lieferte aber kein Ergebnis | Score = 0 im Zähler, Gewicht bleibt im Nenner (Malus) |
incapable |
Modell unterstützt das Testfeld technisch nicht | Komplett raus, weder Zähler noch Nenner |
rolling_out / not_deployed |
Modul ist neu, noch nicht für alle Modelle scharf | Für alle Modelle raus (Übergangsschutz) |
Diese Kette von Wenn-Dann-Bedingungen ist im Kern nichts anderes als ein Filter, der vor der Berechnung entscheidet, welche Werte überhaupt zur Anwendung kommt.
Warum vier Zustände statt einer einfachen Ja/Nein-Abfrage
Eine simple Ja/Nein-Logik würde zwei grundverschiedene Situationen verwechseln:
- „Das Modell kann technisch keine Tools benutzen" ist fair und sollte nicht bestraft werden.
- „Das Modell hat den Benchmark nicht abgeschlossen, obwohl es das könnte" ist unfair und sollte sich im Score niederschlagen. Genau diese Unterscheidung zwischen
incapableundmissingist der eigentliche Mehrwert der vier Zustände. Der Rechenkern bleibt dabei immer dieselbe einfache gewichtete Durchschnittsbildung.
Ein Beispiel aus der Praxis
Am Modell „Command A+" zeigt sich der Unterschied konkret. Mit denselben Rohdaten (Zähler 464.23) ergeben sich je nach Logik zwei völlig unterschiedliche Scores:
$$ \text{Malus-Formel (aktuell, korrekt):} \quad \frac{464.23}{7.5} = 61{,}90 $$
$$ \text{Exempt-Formel (alt, fehlerhaft):} \quad \frac{464.23}{6.5} = 71{,}42 $$
Die Malus-Formel ist die neue, korrekte Logik: Das fehlende Modul bleibt mit seinem Gewicht von 1 im Nenner und wirkt als Malus. Die ursprüngliche Exempt-Formel zeigt die alte Logik, die vor dem Fix galt und behandelt das fehlende Modul, als hätte es nie existiert. Der durchschnittliche Score von „Command A+" war künstlich hoch. Genau dieser rund zehn Punkte große Unterschied war der Auslöser für die Überarbeitung der Berechnung.
Warum starke Spezialisten in der Rangliste nicht immer auf den vorderen Plätzen stehen
Wer ein Modell täglich für komplexe, vielschichtige Aufgaben nutzt, wird sich manchmal fragen, warum es im Leaderboard hinter einem reinen Coding-Spezialisten liegt. Die naheliegende Vermutung wäre, dass Code-Qualität im Total Score stärker gewichtet wird als andere Bereiche, das ist aber so nicht der Fall. Jedes vollwertige Modul, ob Code Quality, UX-Writing, Cultural Intelligence, Reasoning oder jetzt auch Tool Use, geht mit demselben Gewicht in die Formel ein: kein Modul zieht den Score stärker in eine Richtung als ein anderes.
Warum liegen für das Coding bekannte LLMs dann trotzdem oft vorne? Weil der Total Score eben kein Spezialisten-Ranking ist, sondern die Konsistenz über alle Bereiche hinweg misst. Ein Modell, das in sechs von sieben Modulen solide bis stark abschneidet, gewinnt im Durchschnitt gegen ein Modell, das in einem Bereich brilliert, in anderen aber deutlich abfällt, selbst wenn genau dieser eine Bereich im Alltag am meisten zählt. Die tägliche Nutzung ist fast immer linear und fokussiert: Man arbeitet überwiegend in einem oder zwei Feldern, nicht gleichzeitig in allen sieben, die der Total Score gleichmäßig abbildet.
Genau deshalb ist der Total Score bewusst als Einstiegspunkt gedacht, nicht als Endurteil. Er liefert die erste Einschätzung zur Gesamtstärke eines Modells. Wer wissen will, wie es konkret in Coding, Dokumentation oder einem anderen Einsatzfeld abschneidet, findet die passenden Teil-Scores weiterhin einzeln auswertbar im erweiterten Leaderboard. Der Total Score öffnet die Tür zur Rangliste, die Teil-Scores führen tiefer in den jeweiligen Anwendungsfall.
Ein verwandter Punkt betrifft agentische Modelle, die im Alltag oft als besonders leistungsfähig gelten und im Leaderboard trotzdem nicht immer auf den vorderen Plätzen landen. Die eigentliche Stärke von orchestrierenden LLMs liegt in der Fähigkeit, viele Teilprozesse gleichzeitig zu überwachen, gegeneinander abzuwägen und andere Modelle oder Werkzeuge zu steuern. CrucibleMark testet diese Orchestrierungsfähigkeit aktuell nicht! Jedes Modell tritt ausschließlich als ausführendes LLM an, das eine einzelne, linear formulierte Aufgabe direkt beantwortet. Ein Modell, das im Alltag als Dirigent eines ganzen Agenten-Systems brilliert, wird hier also nur als einzelner Musiker bewertet, nicht als Orchesterleiter. Dieser Aspekt sollte bei der Interpretation von Platzierungen von stark agentisch ausgelegten Modellen berücksichtigt werden.
Was sich für die Rangliste ändert
Für die meisten Modelle ändert sich praktisch nichts. Modelle, die sauber getestet wurden und dabei alle Module abgearbeitet haben, bleiben in ihrer Positionierung in der Rangliste weitestgehend stabil.
- Spitze und Mittelfeld: Werte bleiben weitgehend unverändert (variieren im Zehntelbereich)
- Hintere Plätze: hier zeigen sich die spürbarsten Verschiebungen, weil dort bislang Datenlücken existierten, die eigentlich gegen die betroffenen Modelle gesprochen hätten
- Ausgeschlossen bleiben: Modelle mit nachweislich fehlender Fähigkeit für ein Testfeld
Das ist kein Zufall, sondern der Preis für eine ehrlichere Vergleichsbasis zwischen lokalen, offenen und kommerziellen Modellen, alle gemessen an denselben Fragen. Der beste Score ist am Ende nicht einfach der höchste Wert, sondern ein Ergebnis, das sich ein Modell durch vollständige Testabdeckung auch tatsächlich verdient hat.