LLM-Vergleich auf Polnisch: 4 Open-Source-Modelle im Test

👁 114 Aufrufe

Die jüngsten Veröffentlichungen offener Modellgewichte bieten im Oktober 2026 die perfekte Grundlage für einen praktischen LLM-Vergleich: vier Systeme, identische kurze Prompts und eine Zielsprache abseits der üblichen englischsprachigen Benchmark-Diskussionen. Meinen Test auf Polnisch habe ich am 19. Oktober 2026 via API durchgeführt. Dabei erzielten DeepSeek V4.1 Flash 1017 und Nemotron 3.5 Super VL jeweils 12/12 Punkte, Muse Spark Open erreichte 11/12 und Step 5 Preview kam auf 9/12.

Methodik: LLM-Vergleich mit überprüfbaren Aufgaben

Ich habe insgesamt 48 Anfragen via API übermittelt, ohne Wiederholungsläufe für einzelne Aufgaben. Sämtliche Modelle erhielten exakt dieselben Prompts und Generierungsparameter. Ein Testskript prüfte die Rückmeldungen automatisiert anhand vordefinierter Kriterien. Die gespeicherten Protokolle erfassen Request-Laufzeit, Completion-Tokens, Kosten, Antworttexte und die finale Bewertung. Wie die Modelle architektonisch aufgebaut sind, wie viele Parameter sie besitzen und unter welcher Lizenz sie stehen, fasst meine Übersicht zu Open-Source-KI-Modellen mit offenen Gewichten zusammen.

Die Aufgabenstellungen waren bewusst kompakt gehalten. Einige verlangten ein eindeutiges mathematisches Ergebnis, während Aufgaben zur Grammatik oder Formatierung mehrere valide Lösungen zuließen. Nicht jeder Prompt war daher eine reine Frage mit genau einer richtigen Antwort. Das Ziel war vielmehr zu prüfen, ob ein Modell unter gleichen Rahmenbedingungen ein akzeptables Resultat liefert.

• Berechne 37 mal 48 minus 125.
• Nenne den polnischen Genitiv Plural von „przyjaciel“ (Freund).
• Zähle das Vorkommen des Buchstabens „ż“ in einem polnischen Beispielsatz.
• Extrahiere Steuernummer, Bruttobetrag und Datum einer Rechnung in ein JSON-Objekt.
• Berechne die Prüfziffer einer polnischen PESEL-Identifikationsnummer anhand vorgegebener Ziffern und Gewichtungen.
• Ermittle die jüngste Person aus einem kurzen Logikrätsel über Altersangaben.
• Nenne den Wochentag des 11. November 1918.
• Schreibe genau drei klein geschriebene polnische Wörter zum Thema Herbst.
• Nenne die Gesamtzahl der polnischen Woiwodschaften (Verwaltungsbezirke).
• Rechne 2,5 Stunden in Sekunden um.
• Korrigiere einen polnischen Satz mit Rechtschreib- und Zeichensetzungsfehlern.
• Setze die Zahlenreihe 2, 6, 12, 20, 30 logisch fort.

Das API-Routing kann aufeinanderfolgende Anfragen auf unterschiedliche Hardware-Backends leiten. Eine gesetzte Temperature von 0 eliminiert diese infrastrukturellen Laufzeitunterschiede nicht und ersetzt keine statistischen Wiederholungsreihen. Die ermittelten Zeiten dokumentieren die tatsächlichen Abfragen dieses Tages und keinen synthetischen Hardware-Benchmark unter Laborbedingungen.

Ergebnisse und Kosten für diesen KI-Modelle-Vergleich

Die Kosten in der Tabelle basieren auf den aufgerundeten Werten der erfassten Nutzungsprotokolle. Für den kompletten Durchlauf fielen Gesamtkosten von $0.11081294 an, also rund $0,11. Diese Beträge beschreiben ausschließlich meinen konkreten Test via API zu diesem Zeitpunkt. Sie stellen keine verbindlichen Preisgarantien für abweichende Arbeitslasten dar.

Beim Token-Verbrauch zeigten sich massive Differenzen: DeepSeek benötigte 1.283 Completion-Tokens, Nemotron 3.868, Muse 12.241 und Step 19.672. Diese Zahlen enthalten den internen Reasoning-Prozess und nicht nur die letztlich sichtbare Textausgabe. Ein Modell kann folglich deutlich mehr Rechenbudget verbrauchen, ohne dabei mehr sichtbaren Nutzwert auszugeben.

Zudem verdecken Medianwerte extreme Ausreißer nach oben: Die langsamste Anfrage dauerte bei DeepSeek 2,4 Sekunden, bei Nemotron 11,7 Sekunden, bei Muse 126,3 Sekunden und bei Step beachtliche 230,1 Sekunden. In produktiven interaktiven Szenarien fällt ein einzelner stark verzögerter Request mit Abbruch schwer ins Gewicht, selbst wenn der Durchschnitt stabil bleibt.

Sämtliche Fehlerursachen waren leere Antworten

Muse Spark Open scheiterte an der Umrechnung von 2,5 Stunden in Sekunden (korrekt: 9.000 Sekunden). Step 5 Preview scheiterte an der Drei-Wörter-Vorgabe zum Herbst, an der Frage zu den Woiwodschaften Polens sowie an der Rechtschreibkorrektur. Jeder dieser fehlgeschlagenen Datensätze wies eine komplett leere Antwortzeile und exakt 6.000 verbrauchte Completion-Tokens auf. Das Budget erschöpfte sich offenbar vollständig während der internen Denkphase, bevor ein finales Textzeichen generiert werden konnte.

Diese Differenzierung ist entscheidend: Es handelte sich bei den Fehlern nicht um falsche Rechenergebnisse oder grammatikalisch fehlerhafte Formulierungen, sondern um das Ausbleiben jeglicher Antwort. Da das API-Protokoll weder den Denkprozess noch ein spezifisches Finish-Reason-Feld speicherte, lässt sich die genaue interne Schleife nicht rekonstruieren.

Ein höheres Token-Limit oder modifizierte Reasoning-Parameter hätten diese Abbrüche möglicherweise verhindert. Dies wurde im Rahmen dieses Durchlaufs jedoch nicht getestet. Es wäre voreilig, solche Anpassungen blind als Lösung anzusehen oder vorauszusetzen, dass das Modell bei unbegrenztem Token-Limit fehlerfrei geantwortet hätte.

Warum ich die Bewertung der Rechtschreibaufgabe korrigiert habe

Der ursprüngliche Korrektursatz lautete: „Wziąść parasol bo napewno bedzie padać.“ Das ursprüngliche Testmuster verlangte zwingend den korrigierten Infinitiv „wziąć“ neben den korrekten Schreibweisen „na pewno“ und „będzie“. Muse, DeepSeek und Nemotron formulierten stattdessen: „Weź parasol, bo na pewno będzie padać.“

„Weź parasol“ ist die grammatikalisch einwandfreie polnische Imperativform für „Nimm einen Regenschirm“. Angesichts des Aufforderungscharakters des fehlerhaften Ausgangssatzes ist dies eine völlig legitime Korrektur. Ich habe die Bewertungsregel entsprechend angepasst und allen drei Modellen jeweils einen Punkt gutgeschrieben. Bei Step 5 blieb das Feld komplett leer, weshalb sich die Punktzahl hier nicht veränderte.

Dieser Schritt verdeutlicht ein typisches Problem bei automatisierten Sprachtests: Starre Prüfmuster bestrafen oft valide sprachliche Varianten, wenn sie nur eine einzige Zeichenkette erwarten. Für die Transparenz ist es unerlässlich, solche Anpassungen offenzulegen, statt Punktestände kommentarlos umzuschreiben.

Andere Prüfungen waren von Beginn an fehlertolerant aufgebaut. Der JSON-Prüfer akzeptierte Datenobjekte auch dann, wenn sie von Markdown-Codeblöcken umschlossen waren. Die PESEL-Prüfung akzeptierte die Endziffer auch innerhalb eines Begleittextes. Die Resultate bewerten somit die inhaltliche Richtigkeit und nicht die pedantische Einhaltung strikter Ausgabeformate.

Praxiserkenntnisse für Open-Source-LLM abseits von Englisch

Das greifbare Testergebnis lautet: DeepSeek V4.1 Flash 1017 und Nemotron 3.5 Super VL meisterten diesen Aufgabenkatalog ohne leere Antworten, während Muse Spark Open einen Zähler durch ein Token-Limit verlor. Die methodische Erkenntnis wiegt schwerer: Reasoning-Budgets und flexible Sprachprüfungen gehören zwingend in jedes Evaluierungskonzept. Herstellerangaben ersetzen keine eigene Validierung für den jeweiligen Einsatzzweck.

Wenn Sie ein Open-Source-LLM in anderen Sprachen evaluieren, sollten Sie Prüfaufgaben stets an den realen grammatikalischen Strukturen, Namen, Datumsformaten und typischen Redewendungen ausrichten. Eine bloße Übersetzung englischer Benchmarks zerstört oft die eigentliche Testabsicht: Das Zählen bestimmter Sonderzeichen oder morphologische Ableitungen lassen sich nicht eins zu eins übertragen.

• Erfassen Sie getrennt, ob eine Antwort überhaupt ankam, ob sie sachlich korrekt war und ob das Format passte.
• Prüfen Sie abgelehnte Antworten manuell auf sprachlich plausible Alternativen.
• Dokumentieren Sie Token-Limits und Reasoning-Parameter transparent neben den Ergebnissen.
• Wiederholen Sie geschäftskritische Prompts, um Schwankungen abzufedern.
• Trennen Sie reine Text-Prompts strikt von multimodalen Tests mit Bildern, Scans oder Audio.

Dieser Durchlauf enthielt keine Aufgaben auf Deutsch, Englisch, Französisch, Spanisch oder Niederländisch. Die Ergebnisse lassen sich nicht pauschal auf andere Sprachen übertragen. Komplexe Textgenerierung, Code-Generierung, Tool-Nutzung und Long-Context-Abfragen waren nicht Gegenstand dieser Messung. Für kleinere Modelle, die auf lokaler Konsumenten-Hardware laufen, verweise ich auf meinen früheren Test lokaler KI-Modelle auf einer RTX 4090; weitere Messungen finden Sie im Wissnox Labor.

FAQ

Hat ein Modell eine inhaltlich falsche Antwort geliefert?

Nach Anpassung der Rechtschreibprüfung bestand jede nicht-leere Antwort die Kriterien. Da manche Prüfungen Formatabweichungen tolerierten, bedeutet dies jedoch keine absolut fehlerfreie Befolgung aller Formatanweisungen.

Wurden die Modelle auf lokaler Hardware getestet?

Nein. Alle Abfragen liefen via API. Die Werte spiegeln keine lokale Ausführung auf einer bestimmten Workstation oder optimierten Inferenz-Servern wider.

Beweist ein Ergebnis von 12/12 die Praxistauglichkeit?

Nein. Es belegt lediglich das erfolgreiche Bestehen von 12 kurzen Aufgaben in jeweils einem einzigen Durchlauf. Für den Produktiveinsatz sind statistische Wiederholungen und anwendungsspezifische Prompts unerlässlich.

// weiterlesenKI-Stimmen im Vergleich: 8 Modelle im BlindtestBenchmarksBeste Video-KI 2026: 10 Modelle im Test und VergleichBenchmarksGPT-6 Astra Test: 11 KI-Modelle im Vergleich - Code & InstruktionenBenchmarks