LLM Benchmarks Sommer 2025

Endlich haben wir einen Begriff für den Ansatz des Custom Chain-of-Thought (oder SO CoT), den wir in zahlreichen Projekten intensiv einsetzen.

Dieser Ansatz wurde ursprünglich aus erfolgreichen Anwendungsfällen in unserem KI-Portfolio abgeleitet und durch Forschungs- und Entwicklungsarbeit in der Community weiter verfeinert (einschließlich erfolgreicher Beiträge zu den Enterprise RAG Challenges).

Tatsächlich nutzen alle Evaluierungen unseres Reasoning LLM Benchmark v2 (seit Januar 2025) spezialisierte SGR-Schemata, um das Reasoning zu steuern.

Mehr über SGR erfahren Sie hier – oder sehen Sie sich die öffentlich verfügbare Demo an. Diese Demo zeigt, wie sich mit SGR ein Business Assistant aufbauen lässt, der in der Lage ist:

• Planung und Reasoning durchzuführen, während ein kostengünstiges Modell ohne Reasoning-Fähigkeiten verwendet wird
• Tools aufzurufen, um Kund:innen in einem fiktiven Unternehmen zu verwalten, das AGI-Kurse verkauft (in der Demo simulieren wir Tools zum Erstellen von Rechnungen, Versenden von E-Mails und Abrufen von Kundendaten)
• zusätzliche Regeln und eigene Erinnerungen zu generieren

All das geschieht in 160 Zeilen Python-Code – ganz ohne AI Frameworks oder Tool Calling. Lediglich mit dem OpenAI SDK und Pydantic.

Das Thema der Entwicklung und Orchestrierung von Agenten für Business-Aufgaben interessiert uns besonders – und wir sind bestrebt, den Stand der Technik in diesem Bereich weiter voranzutreiben. Später in diesem Bericht werden wir dazu noch eine weitere spannende Ankündigung machen. Zunächst jedoch sehen wir uns an, welche Modelle sich mit Schema-Guided Reasoning am besten für Business-Aufgaben eignen.

Beginnen wir mit den offensichtlichen großen Erfolgen. OpenAI hat kürzlich eine Reihe neuer Modelle veröffentlicht:

• verfügbar über API: gpt-5, gpt-5-mini und gpt-5-nano (Ankündigung)
• zum Download: gpt-oss-20b und gpt-oss-120b (Ankündigung / Download)

gpt-5 von OpenAI ist derzeit das TOP-1-Modell auf unserem Leaderboard!

gpt-5 ist das derzeit intelligenteste Modell – gleichzeitig jedoch sehr groß, langsam und teuer. Für alltägliche Business-Automatisierungsaufgaben im großen Maßstab ist es daher überdimensioniert. Dafür gibt es kleinere Modelle wie gpt-5-mini – und genau hier wird es spannend.

gpt-5-mini belegt aktuell den 5. Platz im Leaderboard, wenn es unter Schema-Guided Reasoning läuft. Es ist ein preislich attraktives und zugleich leistungsfähiges Modell – sehr ausgewogen.

Neben den API-Modellen hat OpenAI auch zwei Open-Weights-Modelle veröffentlicht, die frei heruntergeladen und auf eigener Hardware betrieben werden können. Zum Beispiel:

• Download über HuggingFace
• Ausführung auf eigener Hardware mit ollama
• Oder Experimente über OpenRouter

Das besonders Interessante: Das Modell gpt-oss-120b ähnelt in unseren Benchmarks dem gpt-5-mini auffallend stark. Es wirkt fast so, als wären die beiden Modelle nahezu identisch.

So oder so – es ist das erste Mal seit Langem, dass ein Modell aus den Top 5 öffentlich und frei zur Nutzung verfügbar ist.

Ebenso belegte das Modell gpt-5-nano den 16. Platz auf unserem Leaderboard. Das Modell gpt-oss-20b erzielte sehr ähnliche Ergebnisse und erreichte den 18. Platz.

ℹ️ Auch wenn die Modelle den Namen gpt-oss tragen, handelt es sich dabei nicht um echte Open Source-Modelle, sondern vielmehr um Open Weights-Modelle. Das bedeutet: Die Modelle können frei heruntergeladen und genutzt werden – jedoch werden die ursprünglichen Trainingsdaten und Pipelines nicht offengelegt.

gpt-oss-Modelle basieren auf einer Mixture-of-Experts (MoE)-Architektur, bei der jeweils nur ein kleiner Teil des Modells für die Generierung jedes neuen Tokens genutzt wird. Dadurch sind diese Modelle besonders schnell.

Das Modell gpt-oss-120B kann auf einer einzelnen H100 GPU betrieben werden (Voraussetzung: moderne GPU mit 80 GB VRAM), während gpt-oss-20B bereits mit einer modernen GPU mit 16 GB VRAM läuft, etwa einer RTX 5090.

Normalerweise bedeutet die Anforderung einer „modernen GPU“, dass solche Modelle nicht nativ auf älteren GPUs wie der 4090 oder A100 unterstützt werden. Doch hier gibt es eine interessante Ausnahme:

Dank der MoE-Architektur lassen sich diese Modelle auch lokal mit überraschend wenig VRAM betreiben – wenn auch langsamer.

Beispielsweise kann 120B mit etwa 10–30 Tokens pro Sekunde sogar auf älteren Karten mit nur 5–8 GB VRAM recht ordentlich laufen. In diesem Fall wird der Attention-Teil des Modells auf der GPU gehalten, während alle Experts im regulären Arbeitsspeicher liegen (dafür sind 64 GB RAM erforderlich). Mehr über die Konfiguration von llama.cpp zum Betrieb dieser Modelle finden Sie auf Reddit (Discussion).

ℹ️ TL;DR: Es gibt einen neuen --cpu-moe-Schalter, der das MoE-Offloading auf die CPU unterstützt (in Ollama derzeit noch nicht verfügbar).

Es gibt ein grundlegendes Problem mit dem GPT-5 Release. Es verwendet ein völlig neues Response-Format zur Definition von Konversationen, genannt OpenAI Harmony. Dieses Format ist derzeit jedoch noch nicht gut mit Structured Outputs kompatibel. Das bedeutet, dass die OpenAI API gelegentlich ihr Versprechen nicht einhält, immer JSON zurückzugeben, das dem vorgegebenen Schema entspricht.

Wir haben Fehler mit dem OpenAI SDK festgestellt, wenn gpt-5, gpt-5-mini und gpt-5-nano Antworten lieferten, die nicht mit dem bereitgestellten Schema kompatibel waren. Hier ist ein Gist, das das Problem zuverlässig mit allen GPT-5-Modellen reproduziert: SGR triggers Harmony parsing bug with GPT-5 models. Wir haben den Fehler direkt an OpenAI gemeldet und ihn außerdem mit der OpenAI Community geteilt, inklusive Repro, sodass die Details vollständig nachvollziehbar sind.

Interessanterweise verschwindet das Problem sofort, wenn man von den GPT-5-Modellen wieder zu gpt-4o wechselt – und zusätzlich werden die Antworten deutlich schneller. Dafür gibt es zwei mögliche Gründe:

• gpt-4o verwendet nicht das komplexere Harmony Response Format
• gpt-4o ist kein Reasoning-Modell. GPT-5-Modelle „denken“ im Hintergrund, bevor sie antworten, während gpt-4o einfach direkt eine Antwort gibt.

Die Probleme mit den neuen GPT-5-Modellen betreffen nicht nur die API, sondern auch die gpt-oss-120B- und gpt-oss-20B-Modelle. Kein öffentlicher LLM-Anbieter, der APIs mit Structured Outputs bereitstellt, unterstützt bislang die Nutzung dieser Modelle in funktionierender Form. Sogar Ollama hat Schwierigkeiten mit diesem neuen Format (siehe Ticket).

ℹ️ Wie haben wir die GPT-5 Modelle in unserem Benchmark zuverlässig zum Laufen gebracht? Ganz einfach: Gar nicht.
Wir haben ein funktionierendes Constrained Decoding lediglich simuliert, indem wir alle Antworten mit ungültigem Schema verworfen haben – solange, bis schließlich eine gültige Antwort erzeugt wurde.

Wir sind uns ziemlich sicher, dass die Integrationsprobleme bald behoben sein werden. Dann hätten wir ein großartiges lokales Modell, das intelligent und schnell ist – und sich innerhalb von SGR zum Reasoning anleiten lässt, was seine Fähigkeiten noch weiter verstärkt.

Die Grok-Modelle erzielten in unseren Benchmarks bisher traditionell eher niedrige Werte. Mit Grok-4 kam jedoch der plötzliche Sprung an die Spitze des Leaderboards – mit Ergebnissen, die denen von GPT-5 entsprechen (bei mittlerem Reasoning-Aufwand).

Das Hauptproblem bei Grok-4 ist, dass es ziemlich teuer und langsam werden kann. Ein Beispiel aus unserem Benchmark: Bei einer Anfrage dauerte es ganze 50 Sekunden, bis überhaupt die erste Antwort zurückkam.

Gemini 2.5 Pro ist derzeit eines der besten General-Purpose-Modelle für den Einsatz in Business-Automatisierungsaufgaben. Es verfügt über einen großen Context (mit dem es tatsächlich umgehen kann), unterstützt mehrere Modalitäten und ist zudem vergleichsweise günstig.

Das einzige Problem: Google LLMs bieten nach wie vor kein vollwertiges Structured Output (wie es etwa bei Mistral, OpenAI, Fireworks, Cerberas, Grok oder lokalen Deployments verfügbar ist). Stattdessen steht nur ein eingeschränkter Funktionsumfang zur Verfügung, mit dem zu arbeiten oft mühsam ist.

Anthropic-Modelle waren in den letzten Monaten bestenfalls mittelmäßig. Am höchsten schaffte es ein recht teures claude-3.7-sonnet im Thinking Mode – auf Platz 12. Allerdings unterstützt Anthropic ebenfalls kein Structured Output über Constrained Decoding, was die Integration mit ihren LLMs ziemlich unzuverlässig macht.

Die neuen Qwen-3-Modelle gewannen direkt nach ihrem Release Ende April an Popularität und werden bis heute für ihre Qualität gelobt. Tatsächlich belegt qwen-3-32B den 11. Platz auf unserem Leaderboard – direkt vor Claude-3.7-sonnet:thinking.

Tatsächlich hat ein Community-Mitglied ausprobiert, wie klein ein LLM sein kann, das sich noch für den Einsatz von AI Agents in Business-Szenarien eignet – und es gelang, die SGR Demo auf Qwen-3-4B zu portieren, ausgeführt über ein lokales llama.cpp Deployment.

ℹ️ In diesem Beispiel wird eine quantisierte Version von Qwen3-4B-Instruct-2507 verwendet: Qwen3-4B-Instruct-2507-Q8_0.

Dazu sind zwei Anmerkungen wichtig:

• Erstens entscheiden sich Teams derzeit für Qwen-3-Modelle, wenn sie das kleinstmögliche, aber noch leistungsfähige Modell benötigen.
• Zweitens gilt natürlich: In realen Business-Szenarien bietet der Einsatz eines größeren Modells mehr Sicherheitsspielraum (z. B. gpt-oss-20B oder qwen-3-32B). Dennoch ist es bemerkenswert, dass ein derart kleines Modell in durchaus komplexen Szenarien sinnvoll eingesetzt werden kann.

Hier ist der Source Code, der zeigt, wie man eine klassische SGR Demo so aktualisiert, dass sie mit Qwen-3-4B funktioniert. Er umfasst drei wesentliche Änderungen:

• Entfernt das OpenAI SDK und baut rohe Requests an die von llama.cpp bereitgestellte API
• Erweitert den Prompt, indem die Business Rules detaillierter ausformuliert werden
• Fügt zu Beginn der SGR Cascade in NextStep ein weiteres Reasoning-Feld hinzu

Diese Änderungen reichen aus, damit sogar Qwen-3-4B in einer Aufgabe sinnvoll arbeitet, die ein multi-step reasoning und agentic behaviour erfordert.

Die DeepSeek-Modelle waren bei ihrem Erscheinen ein echter Erfolg. Doch seitdem sind mehrere leistungsstärkere Modelle veröffentlicht worden, die sie in unseren Benchmarks nach unten verdrängt haben.

Zum jetzigen Zeitpunkt ist die ursprüngliche deepseek-r1-Version auf den 17. Platz gefallen und erreicht im SGR-Mode denselben Score wie das gpt-oss-20B-Modell. deepseek-r1-0528 brachte lediglich eine inkrementelle Verbesserung und liegt aktuell auf Platz 14.

Allerdings ist das Interesse daran begrenzt: Kaum jemand möchte ein 671B-Modell betreiben, wenn ein wesentlich besseres 120B-Modell verfügbar ist. Qwen3-32B ist zudem kleiner – und trotzdem leistungsstärker.

Auch das kürzlich veröffentlichte DeepSeek Chat v3.1 konnte in unserem SGR-Benchmark keine nennenswert besseren Ergebnisse erzielen.