Wenn uns ein Kunde fragt, ob ein offenes Modell seine Aufgabe übernehmen kann, wollen wir mit einer Messung antworten. Nicht mit einem Eindruck aus einer Demo und nicht mit der Tabelle des Herstellers. Dafür haben wir einen Prüfstand gebaut, bks-lab/lab-bench auf GitHub. Seit heute, dem 10. Oktober 2026, liegen seine Ergebnisse auch auf Hugging Face.

Die Frage hinter dem Prüfstand

Unser Schwerpunkt ist souveräne KI: Die Daten bleiben auf Hardware, die das Unternehmen kontrolliert. Dieses Versprechen hängt an einer einfachen Frage. Welche Aufgaben schafft ein offenes Modell auf so einer Hardware?

Wir haben die Frage bewusst eng gestellt. Ein Rechner, eine Grafikkarte, eine RTX 4090 mit 24 GB Speicher. Das ist ein Arbeitsplatzrechner, wie ihn ein mittelständisches Unternehmen ohne Rechenzentrum aufstellen kann. Was auf dieser Karte läuft, können wir einem Kunden zusagen. Was nur mit in den Arbeitsspeicher ausgelagertem Modell oder gar nicht durchläuft, sagen wir ebenso deutlich.

Wie wir messen

Die Regeln für die Fähigkeitstests, um die es hier vor allem geht, stehen in plan/ROADMAP.md und in je einem Testplan pro Aufgabe. Die wichtigsten:

  • Der Testplan steht vor der Messung fest. Daten, Modelle, Maß, Vergleichswert und Schwellen schreiben wir als Datei ins Repository, bevor das erste Modell läuft. So lässt sich der Test nicht nachträglich an die Ergebnisse anpassen.
  • Öffentliche Datensätze mit geprüfter Lizenz. Auch die Lizenz jedes Modells prüfen wir vorher. Modelle mit Einschränkungen wie „nur für nicht kommerzielle Nutzung“ haben wir aussortiert, und jede Zeile der Ergebnistabelle nennt die Lizenzklasse.
  • Automatische Maße. Niemand bewertet die Antworten nach Gefühl. Gezählt wird gegen feste Sollwerte aus den Datensätzen.
  • Ein Intervall zu jeder Zahl. Jeder Wert trägt ein 95-%-Bootstrap-Intervall. Das ist der Bereich, in dem der Wert bei einer anderen Stichprobe aus denselben Daten wahrscheinlich läge. Überlappen sich die Intervalle zweier Modelle und trennt sie auch der gepaarte Test nicht, nennen wir sie nicht verschieden.

Eine Regel ist mir besonders wichtig. Ich nenne sie die Referenzwert-Regel: Kein Modell wird bewertet, bevor der Prüfstand einen veröffentlichten Wert nachgerechnet hat. Bei der deutschen Suche musste bge-m3 erst den Wert aus der öffentlichen MTEB-Tabelle treffen. Wir kamen auf 0,5767, veröffentlicht sind 0,5759. Erst danach liefen die anderen Modelle. Stimmt der Referenzwert nicht, ist der Aufbau falsch und jede weitere Zahl wertlos. Für die Rechnungen gibt es keinen veröffentlichten Wert. Dort prüft der Prüfstand vorher, ob jeder Sollwert überhaupt im gerenderten Dokument steht. Das traf für 391 von 391 Werten zu.

Was herauskam

Gemessen sind die drei Aufgaben, die in unserem Plan für Kunden ganz oben stehen: Suche in eigenen Dokumenten, Spracherkennung für Besprechungsprotokolle und Rechnungsfelder. Alle drei haben ihre Vorprüfung nach der Referenzwert-Regel bestanden.

Aufgabe Bestes Modell Wert Vergleich
Deutsche Suche (nDCG@10, MIRACL de) Qwen3-Embedding-8B mit bge-reranker-v2-m3 0,640 BM25 0,199
Deutsche Spracherkennung (Wortfehlerrate, FLEURS de) canary-1b-v2 und whisper-large-v3 4,52 % und 4,70 % nicht getrennt
Rechnungsfelder aus Seitenbildern (34 Rechnungen) gemma4-26b und gemma4-12b 98,0 % und 97,8 % Regex über den PDF-Text 27,0 %

Suche. nDCG@10 misst, wie gut die ersten zehn Treffer sortiert sind, 1 wäre perfekt. Qwen3-Embedding-8B erreicht allein 0,613 und ist von jedem anderen Suchmodell getrennt. Ein Reranker, der die ersten 100 Treffer neu sortiert, hebt das auf 0,640. Der Preis ist Zeit. Das große Modell schafft 44 Textabschnitte pro Sekunde beim Aufbau des Suchindex, bge-m3 und e5-large rund 1.200, bei einem nDCG@10 von 0,56 bis 0,58. Für einen großen Bestand, der sich täglich ändert, ist ein kleineres Modell wie bge-m3 die praktische Wahl. BM25, die klassische Wortsuche, liegt mit 0,199 weit hinten. Das liegt am Datensatz, der gezielt Abschnitte mit denselben Wörtern als falsche Treffer enthält. Über die Wortsuche in Firmendokumenten sagt die Zahl nichts.

Spracherkennung. Die Wortfehlerrate ist der Anteil falsch erkannter Wörter. canary-1b-v2 liegt bei 4,52 %, whisper-large-v3 bei 4,70 %. Der Test trennt die beiden nicht. In der Übersicht steht dann das Modell mit weniger Grafikspeicher, hier whisper-large-v3 mit 8,9 GB. Ein Befund außerhalb des Plans ist für Besprechungen wichtiger als die Hauptzahl. Bei den 21 Aufnahmen über 30 Sekunden steigt die Fehlerrate von whisper-large-v3 auf 17,6 %, canary-1b-v2 bleibt bei 3,2 %. Die Gruppe ist klein, aber Besprechungen sind lang.

Rechnungsfelder. Wir haben 34 Testrechnungen der KoSIT, der Koordinierungsstelle für IT-Standards, als Seitenbilder gerendert. Je Rechnung fragen wir zwölf Felder ab: Rechnungsnummer, Rechnungs- und Fälligkeitsdatum, Verkäufer und Käufer, Umsatzsteuer-ID des Verkäufers, IBAN, vier Beträge und Währung. Die Sollwerte stammen aus dem XML der Rechnungen, niemand musste sie abtippen. gemma4-12b liest 399 von 408 Feldern richtig, gemma4-26b 400. Das kleinere Modell braucht 9,8 GB und 2,1 Sekunden pro Rechnung. Ein regulärer Ausdruck über den Text der PDF-Datei schafft 27,0 %.

Eine Zahl hat uns überrascht. Ein Textmodell, Qwen3.8-27B, bekam statt des Bildes die saubere Textebene der PDF und kam nur auf rund 66 %. Der Grund steht in den Rohzeilen. Bei allen 34 Rechnungen hat es für alle vier Betragsfelder null geantwortet, von den übrigen 272 Feldern hatte es 268 richtig. Die Anweisung verlangt Beträge als Zahl, das Schema erlaubt nur Text oder null, und das Modell hat sich für null entschieden. Ohne die Rohzeilen hätten wir aus 66 % den falschen Schluss gezogen. Deshalb veröffentlichen wir sie.

Nachgemessen: vier weitere Fähigkeiten

Aktualisiert am 12. Oktober 2026. Zwischen dem 10. und 12. Oktober 2026 liefen vier weitere Tests auf derselben Karte: Werkzeugaufrufe, Leseverstehen, langer Kontext und Durchsatz. Alle Werte stammen aus den Befunden im Prüfstand, Stand Commit 08331c4. Die Zeilen stehen auch im Datensatz lab-bench-results auf Hugging Face, Teil capabilities.

Aufgabe Bestes Modell Wert Vergleich
Werkzeugaufrufe (BFCL v3, 1.000 Aufgaben) qwen3-14b und qwen3.8-27b 91,9 % und 90,6 % nicht getrennt
Leseverstehen (F1, GermanQuAD, 1.000 Fragen) gelectra-large 0,872 bestes Sprachmodell 0,849
Langer Kontext (Treffer bei 32k Tokens, 180 Aufgaben) qwen3-14b, qwen3.8-27b, gpt-oss-20b je 100 % alle sieben Modelle mindestens 90 %
Durchsatz (Entscheidungen pro Stunde, 16 Nutzer) granite4-3b 260.731 qwen3-8b 190.414

Werkzeugaufrufe. Ein Modell bekommt Funktionen beschrieben und soll die richtige mit den richtigen Argumenten aufrufen, über die eingebaute Werkzeugschnittstelle von Ollama. qwen3-14b trifft 91,9 % der 1.000 Aufgaben, qwen3.8-27b 90,6 %. Der Test trennt die beiden nicht (p 0,22), qwen3-14b braucht aber 10,3 statt 18,1 bis 22,3 GB. Das kleine granite4-3b kommt mit 3,1 GB auf 86,9 %. Zwei Befunde sind für den Einsatz wichtiger als die Rangfolge. Stehen die Funktionen als JSON im Systemprompt, treffen fünf von sieben Modellen öfter als über die Werkzeugschnittstelle (bei qwen3.8-27b fehlt die Messung im Prompt-Modus), qwen3-14b etwa mit 94,6 %. Und gpt-oss-20b scheitert an der Anbindung in Ollama: Es gibt höchstens einen Aufruf je Aufgabe zurück und landet bei 50,8 %. Erzwingt Ollama beim Erzeugen ein JSON-Schema, halten alle acht Modelle es in 89,5 % bis 93,4 % der Fälle ein. Ohne Zwang sind es nur 73,3 % bis 90,5 %. Eine Prüfung der Ausgabe bleibt also nötig. Vorab haben wir den Aufbau gegen die BFCL-Rangliste geprüft: 93,5 % bei einfachen Aufrufen gegen 95,25 % für Qwen3-14B, erlaubt waren fünf Punkte Abstand. Die Rangliste misst mit Denkmodus und voller Genauigkeit, wir ohne Denkmodus und in Q4_K_M. Einzelheiten im Befund C4.

Leseverstehen. Das Modell bekommt einen deutschen Wikipedia-Abschnitt und eine Frage und soll die Antwort aus dem Text nennen. Gewonnen hat kein Sprachmodell, sondern gelectra-large, ein kleines Lesemodell mit 335 Millionen Parametern: F1 0,872 gegen 0,849 bei gemma4-12b, dem besten Sprachmodell (p 0,024). Es braucht 1,7 GB und 28 Millisekunden je Frage, gemma4-12b 9,2 GB und 302 Millisekunden. Der Vergleich ist allerdings ungleich. Das Lesemodell wurde auf dem Trainingsteil desselben Datensatzes trainiert, die Sprachmodelle sahen kein Beispiel. Größe half nicht: gemma4-26b kommt auf 0,778, und qwen3.8-27b schrieb bei 104 Fragen „keine Antwort“, obwohl die Antwort im Text stand. Einzelheiten im Befund C6.

Langer Kontext. Wir verstecken eine Angabe in einem langen deutschen Text und fragen danach, bei 4k, 16k und 32k Tokens (rund 4.000, 16.000 und 32.000). Alle sieben Modelle liegen bei jeder Länge bei mindestens 90 %. qwen3-14b, qwen3.8-27b und gpt-oss-20b beantworten bei 32k Tokens alle 180 Aufgaben richtig. gpt-oss-20b liest so einen Text in 2,7 Sekunden ein, qwen3-14b braucht 8,1. Die Fehler bei Gemma und Mistral zeigen keine Schwäche beim Finden. Ollama hat 97 von 3.780 Eingaben ohne Fehlermeldung auf gut die Hälfte gekürzt, weil der Text in den Tokens des Modells länger war als das eingestellte Kontextfenster. Auf allen ungekürzten Eingaben antworten beide richtig. Für den Betrieb heißt das: Das Kontextfenster muss größer sein als die längste Eingabe, gemessen in den Tokens des Modells. Längere Texte als 32k Tokens haben wir nicht getestet. Einzelheiten im Befund C7.

Durchsatz. Wie viel schafft die Karte, wenn mehrere Nutzer gleichzeitig fragen? Mit 16 parallelen Anfragen trifft granite4-3b 260.731 kurze Entscheidungen pro Stunde, qwen3-8b 190.414. Für einen einzelnen Nutzer ist gemma4-26b mit 178,3 Tokens pro Sekunde eines der schnellsten, weil es als Mixture of Experts je Token nur rund 4 Milliarden Parameter rechnet. Bei 16 Nutzern kippt das Bild. Jede Anfrage braucht einen Zwischenspeicher für den bisherigen Text, und bei manchen Modellen passen 16 davon nicht mehr neben die Gewichte. gemma4-12b fällt dann von 397,0 Tokens pro Sekunde bei 8 Nutzern auf 146,2 bei 16, weil Ollama Teile auf den Prozessor legt. qwen3.8-27b lief nur mit einem Platz und bedient 16 Nutzer nacheinander. Gegen vLLM, einen Server für viele gleichzeitige Anfragen, verliert Ollama bei 16 Nutzern: qwen3-14b schafft unter vLLM 789,5 statt 564,0 Tokens pro Sekunde, gemma4-12b 708,8 statt 146,2. Mit einem Nutzer ist Ollama schneller, 85,6 gegen 79,6 bei qwen3-14b. Beide liefen mit ihrer eigenen 4-Bit-Fassung der Gewichte (bei gemma4-12b unter vLLM eine Umwandlung aus der Community), verglichen sind also Server und Fassung zusammen. Beim Strom liegt granite4-3b mit 165 Joule je 1.000 erzeugte Tokens vorn, gemessen an der Grafikkarte bei 16 Nutzern. Dieser Test misst nur Tempo und Strom, keine Qualität. Einzelheiten im Befund C8.

Nachgemessen: Übersetzung und drei Aufgabentests

Aktualisiert am 12. Oktober 2026. Am selben Tag kamen die Übersetzung (C5) und drei Tests an den Entscheidungsmodellen dazu: Stabilität bei gemischten Optionen (T2), Robustheit gegen Tippfehler (T9) und Durchsatz mit Bündeln (T10). Alle Werte stammen aus den Befunden im Prüfstand, Stand Commit cfd07a2.

Übersetzung. Gemessen wird chrF++ auf 1.012 Sätzen aus FLORES+, in beide Richtungen, auf einer Skala von 0 bis 100. Von Deutsch nach Englisch erreicht gemma4-26b 68,1 und gemma4-12b 67,9, von Englisch nach Deutsch 65,5 und 65,1. Der gepaarte Test trennt die beiden nicht (p 0,060 und 0,053). Unsere Wahl ist deshalb das kleinere gemma4-12b mit 8,7 statt 18,5 GB Grafikspeicher. eurollm-9b folgt mit 67,3 und 64,8. Das eigens für Übersetzung gebaute opus-mt liegt mit 64,9 und 61,1 drei bis vier Punkte zurück, braucht aber nur 1,9 GB und schafft im Bündel von 32 rund 84 Sätze pro Sekunde (Mittel beider Richtungen), gemma4-12b einzeln 4,2. Ob drei bis vier Punkte bei einem großen Stapel zählen, hängt von der Aufgabe ab. Die Grenzen: ein Satz pro Aufruf, nur Deutsch und Englisch, Nachrichten- und Lexikontext. FLORES+ kann im Training einzelner Modelle gewesen sein. Einzelheiten im Befund C5.

Stabilität. Dieselben 5.948 Fragen zu 2.974 deutschen Befehlen laufen zweimal, einmal mit den Optionen in fester Reihenfolge und einmal gemischt. Bei qwen3.8-27b ändert sich die Antwort in 5,7 % der Fragen, bei winnow-12b in 7,8 %, bei gemma4-12b in 9,1 %. Die Änderungen sitzen vor allem in der Frage mit 18 Optionen (10,4 %, 13,9 % und 14,4 %), in der zweiten Frage sind es 1,0 %, 1,7 % und 3,9 %. Bei winnow-12b und qwen3.8-27b liegt die gemischte Fassung außerdem rund einen Punkt höher, die Reihenfolge der Optionen beeinflusst also auch die Trefferquote. GLiNER Decide ändert keine einzige Antwort (0 von 5.948). Warum, haben wir nicht geprüft. Einzelheiten im Befund T2.

Robustheit. 1.000 deutsche Befehle laufen in vier Fassungen: sauber, mit Tippfehlern, ohne Umlaute (ae, oe, ue, ss) und umgangssprachlich. Tippfehler kosten jedes der vier Werkzeuge 3,0 bis 4,2 Punkte Treffer, fehlende Umlaute und Umgangssprache höchstens 1,8. GLiNER Decide ändert bei Tippfehlern am meisten Antworten (18,2 % gegen 7,1 bis 9,2 % bei den Sprachmodellen), verliert netto aber ähnlich viel. Die Störungen sind nach festen Regeln erzeugt und bilden keine echten Erkennungsfehler der Spracherkennung nach, die Zahlen sind eher eine Untergrenze. Einzelheiten im Befund T9.

Bündelung. GLiNER Decide beantwortet 399,5 Entscheidungen pro Sekunde, wenn Anfragen in Bündeln von 8 laufen, einzeln sind es 69,8. Das ist das 5,7-Fache, und die Antworten bleiben in allen Bündelgrößen dieselben. Größere Bündel sind langsamer: 380,6 bei 32 und 354,4 bei 128. Zur Einordnung: Der Klassifikator trifft auf diesen Befehlen 56 % gegen 79 bis 82 % der Sprachmodelle in T2. Die Sprachmodelle haben wir hier nicht neu gemessen, ihr Durchsatz steht oben unter „Durchsatz“. Einzelheiten im Befund T10.

Nachgemessen: personenbezogene Daten

Aktualisiert am 12. Oktober 2026. Die Erkennung personenbezogener Daten in deutschem Text (C9) ist gemessen, mit einer Einschränkung vorneweg: Das Soll dieses Datensatzes hat ein Sprachmodell erzeugt, und die Nachprüfung der 40 Stichprobentexte hat ebenfalls ein Sprachmodell gemacht, kein Mensch. Das war Claude Haiku 5.5, jede Beanstandung hat Claude Opus 5.5 gegengeprüft. Unser Testentwurf verlangt eine Prüfung durch einen Menschen. Die steht noch aus, und wir halten die Abweichung im Entwurf fest.

Die Prüfung fand 43 falsche Stellen unter 149, etwa „Damen“, „Herren“ oder „Jetzt“ als Person. Die Präzision des Solls liegt bei 0,685 und damit unter der vorab festgelegten Schwelle von 0,90. Der Test gilt deshalb als „Soll verrauscht“, alle Zahlen beschreiben nur, eine Rangfolge behaupten wir nicht. Auf dem geprüften Soll der 40 Texte erreichen gemma4-12b 0,839 und qwen3.8-27b 0,828 (nicht getrennt), gliner-pii-domains 0,738, gliner2.5-multi 0,649, gliner-multi-pii 0,444, Presidio 0,300 und die Regex-Grundlinie 0,150. Auf allen 476 Texten mit dem ursprünglichen Soll liegt qwen3.8-27b mit 0,644 vor gemma4-12b mit 0,627. Beide Wertungen zeigen dieselben Gruppen: die zwei Sprachmodelle vorn, dann die GLiNER-Modelle, Presidio und Regex am Ende. Presidio meldet viel (Präzision 0,238), der Regex trifft feste Formate wie E-Mail-Adressen sauber, aber nur 8 % aller Stellen. Der Datensatz ist erfunden und stammt aus dem Finanzbereich, die Zahlen sagen nichts über echte Dokumente. Einzelheiten im Befund C9.

Was ein Vergleich verdeckt

Die Entscheidungsmodelle haben wir schon ausführlich in Jev gegen lokale Modelle beschrieben. Ein Ergebnis aus derselben Reihe zeigt, warum wir zu jeder Zahl ihre Herkunft nennen. Beim Einordnen kurzer Befehle in 18 Themen (MASSIVE, deutsch) kommt Jev von TypeSafe auf 72,8 %, das lokale Winnow-12B auf 71,8 %. Der Test trennt die beiden nicht.

Ein klassisch trainierter Klassifikator erreicht auf derselben Frage 86,9 %. Das klingt nach einem klaren Sieger. Er hat aber vorher 11.514 beschriftete Beispiele genau dieser Themen gesehen, die anderen Modelle kein einziges. Mit zehn Beispielen pro Thema fällt er auf 70,8 %. Die Zahl misst also, was beschriftete Daten bringen, und ist mit den anderen nicht vergleichbar. Die Einzelheiten stehen in den route1-Befunden und auf der Laborseite Entscheidungsmodelle.

Warum wir das öffentlich machen

Eine Empfehlung, die sich nicht prüfen lässt, ist eine Behauptung. Deshalb liegt auf GitHub alles, was man zum Nachrechnen braucht: der Code, die Testpläne mit Datum, die Fälle und die Rohzeilen jedes Laufs. Wo ein Datensatz zu groß ist oder seine Lizenz das Weitergeben verbietet, liegt dort das Skript, das ihn holt und per Prüfsumme kontrolliert.

Bei jedem Push rechnet ein zweites Skript, das den Messcode nicht benutzt, die Hauptzahlen der Spracherkennung und der Rechnungsfelder aus den Rohzeilen nach, mit eigener Normalisierung. Weicht etwas ab, wird die Prüfung rot. Wer uns nicht glaubt, kann nachrechnen.

Warum Hugging Face

Auf Hugging Face suchen Entwickler und Datenteams nach Modellen und Datensätzen. Dort liegen auch die Modelle, die wir gemessen haben. Ein Ergebnis, das neben dem Modell steht, wird eher gefunden als eines in einem Repository, das niemand kennt. Seit heute liegt dort:

  • der Datensatz lab-bench-results mit allen Ergebnistabellen, unter CC BY 4.0,
  • der Space lab-bench, eine Seite, die diese Tabellen zeigt,
  • der Datensatz xrechnung-invoice-fields mit den 34 KoSIT-Testrechnungen als 118 Seitenbilder, den Sollwerten und den aufgezeichneten Ausgaben von sieben Modellvarianten, unter Apache-2.0,
  • der Space xrechnung-invoice-fields-viewer: Rechnung wählen, Seiten ansehen, Feld für Feld vergleichen, was jedes Modell gelesen hat,
  • die Sammlung Measured on one RTX 4090 mit den 19 gemessenen Modellen, jedes mit unserem Wert als Notiz.

Den größten Nutzen für andere sehe ich im Rechnungsdatensatz. Wer ein eigenes Modell auf Rechnungen prüfen will, nimmt dieselben Seitenbilder und vergleicht seine Ausgabe Rechnung für Rechnung mit unseren. Die Sollwerte sind exakt, weil sie aus dem XML kommen.

Was bewusst nicht auf Hugging Face liegt

Hugging Face ist ein US-Unternehmen. Für öffentliche Testdaten und Ergebnisse ist das in Ordnung, für alles andere nicht. Daraus folgen drei Entscheidungen.

Keine Live-Demo mit Upload. Der Rechnungsbetrachter führt kein Modell aus und nimmt keine Datei entgegen. Er zeigt nur gespeicherte Ausgaben unserer Läufe. So landet dort keine echte Rechnung auf einem Server in fremder Hand, auch nicht aus Versehen.

Keine Einzelantworten von Jev. Die Antworten von Jev auf jede einzelne Frage liegen nur auf GitHub. TypeSafe hat am 10. Oktober 2026 erlaubt, sie zu veröffentlichen, damit andere die Messungen nachprüfen können. Die Bedingungen: kein Modell damit trainieren oder destillieren und kein Produkt bauen, das mit TypeSafe konkurriert. Der Wortlaut steht in der Erlaubnis und im Nutzungshinweis. Ein Datensatz auf Hugging Face ist eine Trainingsquelle, deshalb bleiben die Zeilen dort draußen. Die Gesamtwerte von Jev sind Messergebnisse und stehen in der Ergebnistabelle.

Keine Fälle aus fremden Datensätzen. Die Befehle aus MASSIVE und die Aufgaben aus fast-decisions stammen von Amazon und Fastino und liegen dort schon auf Hugging Face, als AmazonScience/massive und fastino/fast-decisions. Eine zweite Kopie bei uns brächte nichts außer einer zweiten Stelle, die veralten kann.

Wie die Zahlen aktuell bleiben

Damit die Kopie auf Hugging Face nicht veraltet, baut ein Ablauf im Repository die Datensätze und Spaces neu, sobald sich Ergebnisse, Rechnungsdaten oder der Exportcode ändern, und lädt sie hoch. In jeder Datensatzkarte steht der Commit des Prüfstands, aus dem sie gebaut ist. Wer eine Zahl auf Hugging Face findet, kommt so mit einem Klick zum Stand im Repository, der sie erzeugt hat.

Die Grenzen

Ein Prüfstand, der seine Grenzen verschweigt, wäre nicht mehr wert als eine Herstellertabelle. Diese gelten für alle Zahlen oben:

  • Ein Lauf je Modell. Wiederholte Läufe fehlen noch, und die Geschwindigkeit haben wir einmal gemessen statt dreimal. Nur der Durchsatztest C8 wiederholt jede Messung dreimal.
  • 34 Rechnungen geben weite Intervalle. Für gemma4-12b reicht das Intervall von 96,3 % bis 99,0 %.
  • Testrechnungen sind keine echten Scans. Alle haben dasselbe saubere Layout, ohne Stempel, Logos oder Schräglage. Echte Scans schneiden vermutlich schlechter ab, gemessen haben wir das noch nicht.
  • Das beste Modell ist erst nachträglich gewählt. Wer viele Varianten misst, findet eher eine, die gut aussieht. Die p-Werte sind dafür nicht korrigiert.
  • Vorlesen ist keine Besprechung. FLEURS enthält vorgelesene Sätze in guter Aufnahmequalität, kein Durcheinanderreden.

Was daraus folgt

Für uns ist der Prüfstand die Grundlage jeder Modellempfehlung. Laut Plan messen wir als Nächstes lange Dokumente, und die Prüfung des Solls für personenbezogene Daten durch einen Menschen. Jeder Test bekommt zuerst seinen Plan im Repository, dann seine Messung.

Aktualisiert am 12. Oktober 2026: Werkzeugaufrufe und strukturierte Ausgabe (C4), Leseverstehen (C6), langer Kontext (C7) sowie Durchsatz und Energie (C8) sind inzwischen gemessen, die Ergebnisse stehen oben unter „Nachgemessen“. Dazu kommen Übersetzung (C5) sowie die Aufgabentests Stabilität (T2), Robustheit (T9) und Durchsatz mit Bündeln (T10), ebenfalls oben unter „Nachgemessen“. Dazu kommt die Erkennung personenbezogener Daten (C9), mit Soll von einem Sprachmodell nachgeprüft, nicht von einem Menschen, siehe oben unter „Nachgemessen: personenbezogene Daten“.

Du hast eine Aufgabe und willst wissen, ob ein offenes Modell sie auf eigener Hardware schafft? Schreib uns. Am liebsten mit einem öffentlichen Datensatz, den wir in den Prüfstand aufnehmen können. Dann kann jeder die Antwort nachrechnen, auch du.

Alles zum Nachprüfen

Auf Hugging Face:

Auf GitHub:

Auf bks-lab.com:

Alle Werte stammen aus den Befunden im Prüfstand, Stand Commit 1cb5dab vom 10. Oktober 2026. Gemessen am 9. und 10. Oktober 2026 auf einer RTX 4090 mit 24 GB, die Entscheidungsmodelle am 9. Oktober 2026. Die Werte unter „Nachgemessen“ stammen aus Commit 08331c4 vom 12. Oktober 2026, gemessen vom 10. bis 12. Oktober 2026 auf derselben Karte mit Ollama 0.35.0 und vLLM 0.31.0.