Hermes 4.3 36B (Thinking)

Mit einem Gesamtscore von 68.02% zeigt Hermes 4.3 36B (vLLM, Seed-OSS, Dense, NVFP4) ein eigentümliches Profil: als Generalist in der Server-Klasse mit 36 Milliarden Dense-Parametern will es zugleich denken, orchestrieren und Tools nutzen, bleibt im Benchmark aber ein Modell mit spürbarem Eigensinn. Der konkrete Testlauf erfolgte im Thinking-Modus, und das merkt man: Antworten sind oft strukturiert und bedacht, aber nicht automatisch präziser. Der Speed Profile Badge lautet Batch Tool Expert; das steht für eher gemächliche, werkzeugorientierte Nutzung statt interaktivem Schlagabtausch. Sovereign Risk: MEDIUM — die offenen Gewichte stammen aus einem US-geprägten Rechts- und Provenienzkontext; bei lokalem Betrieb fließen keine Prompts an einen Cloud-Provider, die Herkunft bleibt trotzdem ein relevanter Compliance-Faktor.

Kopfnoten: Stabilität und Zuverlässigkeit

Architektur und Charakter

Die vorab vergebene Metadaten-Einstufung trifft den Kern erstaunlich gut, nur nicht ganz so schmeichelhaft, wie es die Tag-Kette vermuten lässt. Hermes 4.3 36B (vLLM, Seed-OSS, Dense, NVFP4) ist ein Generalist mit Server-Ambitionen, Dense-Architektur und langem Kontextfenster von 512K Tokens. Dense heißt hier nicht bloß technisch „klassischer Transformer“, sondern praktisch auch: Die vollen 36 Milliarden Parameter arbeiten bei jedem Token mit. Man bezahlt also für Kapazität nicht nur beim Laden, sondern auch beim Laufverhalten.

Wichtig ist die doppelte Natur der Kategorisierung. Architektonisch ist das Modell sowohl als Thinking als auch als Thinking-Optional markiert. Für diesen Bericht zählt der harte Laufmodus: getestet wurde explizit mit aktiviertem Thinking. Das ist keine Nebensache, sondern der Bewertungsrahmen. Längere, argumentativ ausgearbeitete Antworten sind hier kein Laster, sondern Absicht. Gerade für ein Modell mit Agentic-Orchestrator-Anspruch darf man also erwarten, dass es Aufgaben sauber zerlegt, Prioritäten erkennt und nicht an der ersten Formalie stolpert. Genau daran misst sich Hermes. Und genau daran reibt es sich im Benchmark auch.

Geschwindigkeit und Effizienz

Hermes ist ein lokales Modell und wurde nativ auf ASUS GX10 / NVIDIA DGX Spark (GB10 Grace Blackwell Superchip, ~115 GB Unified Memory — kein praktisches Speicherlimit für getestete Modellgrößen) evaluiert. Der Batch Tool Expert-Badge passt zur Beobachtung: Das Modell ist nicht für flüssige Dialoge gemacht, sondern eher für Aufgaben, bei denen man eine längere Bearbeitungszeit akzeptiert, solange am Ende ein brauchbarer Arbeitsstand herausfällt. Das kann im Dokumentations- oder Recherchekontext legitim sein. Für Agenten, die schnell iterieren oder in Ketten auf Antworten warten, ist es eine spürbare Bremse.

Immerhin verhält sich Hermes token-ökonomisch. Kein Modul übersteigt den erwarteten Verbosity-Rahmen. Das ist ein echter Pluspunkt, weil langsame Modelle, die auch noch schwafeln, die Geduld gleich doppelt bestrafen. Hermes tut das nicht. Es produziert in CLI, Code Quality, Dokumentation, UX und Content durchweg weniger oder ungefähr so viele Tokens wie der Flottenmedian. Die Langsamkeit kommt hier also nicht aus textlicher Maßlosigkeit, sondern aus dem Charakter des Modells selbst. Das ist ehrlicher, aber nicht angenehmer.

Reasoning und Logik

Im Logical-Reasoning-Modul landet Hermes bei 63.34 Punkten. Das ist nicht katastrophal, aber für ein Modell, das im Thinking-Modus läuft und sich architektonisch Reasoning auf die Fahnen schreibt, eben auch kein Auftritt mit Nachdruck. Die qualitativen Protokolle zeigen ein wiederkehrendes Muster: Die Lösungsidee ist oft da, die didaktische oder formale Ausführung bleibt flacher als sie sein sollte.

Besonders aufschlussreich ist die Logikaufgabe mit den zwei Wächtern. Dort liegt die eigentliche Schlussfolgerung korrekt: Hermes versteht das Prinzip der doppelten Verdrehung und kommt zur richtigen Tür. Das Problem ist nicht das Denken, sondern die Verpackung. Der Judge bemängelt eine zu oberflächliche Erklärung des Mechanismus, fehlende Alternativformulierungen und geringere pädagogische Tiefe als im Referenzstandard. Für Alltagsgebrauch ist das noch akzeptabel. Für ein Thinking-Modell im Server-Tier ist es ein kleiner Verrat am eigenen Anspruch.

Hinzu kommt ein konkreter Sprachfehler im Reasoning-Bereich. In einer metakognitiven Aufgabe ignorierte das Modell die explizite Sprachanweisung und antwortete auf Englisch. Das ist kein Schönheitsfehler, sondern Instruction-Following-Schwäche. In Umgebungen mit fester Zielsprache fällt so etwas nicht als intellektuelles Missverständnis auf, sondern als unmittelbarer Produktionsfehler.

Insgesamt ist das Reasoning also brauchbar, aber nicht souverän. Hermes denkt sichtbar mit. Nur führt Denken hier nicht automatisch zu einem Qualitätsvorsprung. Manchmal wirkt es eher wie ein ausführlicher Arbeitsweg zu einem bloß ordentlichen Ergebnis.

Code Quality und Security

Mit 67.8 Punkten im Code-Quality-Modul liefert Hermes keine Blamage, aber auch keinen Sicherheitsbericht, den man ungeprüft unterschreiben möchte. Das Modell erkennt viele klassische Schwachstellen korrekt, formatiert sauber und bleibt in der Tabelle diszipliniert. SQL-Injection, Klartextpasswörter, XSS, Session Fixation, Path Traversal: Das Repertoire sitzt. Man merkt, dass hier ein solides Fundament vorhanden ist.

Aber die Schwächen sind genau dort unangenehm, wo ein Sicherheitskontext kein Schulterzucken erlaubt. In einem Audit übersah Hermes 4 von 19 relevanten Schwachstellen. Das entspricht einer Lücke von 21%. Darunter waren keine dekorativen Randnotizen, sondern unter anderem Hardcoded Secrets, Root-Zugangsdaten ohne Passwort, ein Reset-Token ohne Ablaufzeit und ein Problem im Header-Kontext. Noch problematischer ist die Fehlklassifikation einzelner Funde. Ein IDOR-Fall, also unberechtigter Zugriff auf Objekte über manipulierte Identifikatoren, wurde als fehlende Eingabesanitisierung verbucht. Das ist fachlich nicht dasselbe. Wer Bedrohungsmodelle verwechselt, verwechselt am Ende auch Prioritäten.

Die Fix-Vorschläge sind zudem nicht immer trennscharf. Beim Token-Injection-Fall verweist das Modell auf Prepared Statements oder mysqli_real_escape_string, obwohl die eigentliche Schwachstelle im Mail-Kontext lag. Das ist kein kleiner Patzer, sondern eine falsche Diagnose. Ein Sicherheitsmodell, das die richtige Alarmglocke hört, aber auf die falsche Leitung zeigt, ist nützlich für die Vorprüfung und riskant für die Freigabe.

Für die Einordnung ist wichtig: Hermes trägt auch den Charakter eines uncensored finetuned Modells. Solche Modelle sind nicht primär für DevSecOps-Treue gebaut, sondern für freiere inhaltliche Generierung bei intakter Basisarchitektur. Das erklärt manches, entschuldigt aber nicht alles. In der Praxis taugt Hermes im Security-Kontext eher als Assistent für den ersten Sweep als als letzte Instanz.

Dokumentation, UX und Content-Transformation

Die freundlichste Lesart auf Hermes im Schreibbereich lautet: funktional, oft strukturiert, gelegentlich mit rauer Kante. Die weniger freundliche lautet: Es erledigt die Pflicht und vergisst dabei regelmäßig, dass Form ebenfalls Teil der Aufgabe ist.

Im Content-Transformation-Bereich zeigt sich beides zugleich. Positiv ist die grundsätzliche Fähigkeit, Material umzubauen, zu strukturieren und auf Zielmedien zuzuschneiden. Das Protokoll zum Videoskript zeigt ein verwendbares Ergebnis mit Analyse, Zeitmarken, Produktionshinweisen und Easter Egg. Das ist keine Kleinigkeit. Viele Modelle scheitern schon daran, die Teile der Aufgabe überhaupt zusammenzuhalten. Hermes tut das.

Nur ist der Teufel hier nicht im Detail, sondern direkt in der Produktionsrealität. Das Skript behauptet eine Laufzeit von 4:15 Minuten, die sichtbare Textmenge spricht aber eher für rund 5:40 Minuten. Die Zeitmarken addieren sich nicht sauber zur tatsächlichen Sprechdauer. Für Redaktionen und Creator-Workflows ist das ein Blocker. Ein Skript mit falscher Timing-Logik ist wie ein Fahrplan mit poetischer Freiheit: schön gemeint, praktisch unerquicklich.

Dazu kommt ein harter Constraint-Verstoß im Content-Modul. In einer Aufgabe überschritt das Modell die explizite Wortvorgabe von 250 Wörtern mit 419 Wörtern, also 168% des Limits. Das System verhängte dafür automatisch einen Abzug von 16.80 Punkten beziehungsweise 20% auf den erreichbaren Score. Die inhaltliche Qualität der Antwort ist damit irrelevant. Die Strafe greift unabhängig davon. Genau das macht solche Verstöße so unerquicklich: Nicht der Judge war pingelig, sondern das Regelwerk konsequent.

Noch schwerer wiegt die Sprachdisziplin. In einer weiteren Content-Aufgabe ignorierte Hermes die explizite Sprachanweisung und antwortete auf Englisch. Das ist kein isolierter Ausrutscher, sondern Teil eines breiteren Musters über mehrere Module hinweg. Bei simultanen Vorgaben aus Sprache, Länge und Format verliert das Modell erkennbar zuerst die Sprachvorgabe.

Im Bereich Documentation Quality steht der Score bei 66.94 Punkten und damit über dem Gesamteindruck des Modells, aber nicht über dessen strukturellen Macken. Auch hier kam es in einer Aufgabe zu einem Sprachfehler: Statt des geforderten Deutschen lieferte Hermes Englisch. In produktiven Dokumentationspipelines ist das ein direkter Durchfaller, weil Übersetzungs- oder Lektoratsaufwand nicht nachgelagert „irgendwie“ aufgefangen werden sollte. Dokumentation lebt von Verlässlichkeit, nicht von guten Absichten.

UX Writing fällt mit 62.05 Punkten eher blass aus. Das passt zum Gesamtcharakter. Hermes kann umschreiben, glätten und toxische oder exkludierende Begriffe neutralisieren. Im qualitativ protokollierten Beispiel ersetzt es problematische Formulierungen ordentlich und hält sich an die Instruktion, nur den umgeschriebenen deutschen Text auszugeben. Was fehlt, ist oft Wärme, idiomatische Eleganz und das letzte Gespür für Ton. Der Judge beschreibt das treffend: funktional, aber weniger einladend und weniger natürlich als die Referenz. Man bekommt das Ergebnis. Nur klingt es stellenweise so, als hätte ein korrektes Modell den Charme an der Garderobe abgegeben.

Das Sprachversagen ist kein isolierter Ausreißer. Über mehrere Aufgaben im Content-, Documentation- und Reasoning-Bereich zeigt das Modell ein konsistentes Muster: Bei simultanen Vorgaben aus Sprache, Länge und Format verliert es die Sprachvorgabe als erste Bedingung. Konkret betraf das eine Videoskript-Aufgabe im Content-Transformation-Modul, eine Dokumentationsaufgabe und eine metakognitive Logikaufgabe. Für deutschsprachige Produktivumgebungen ist das ein strukturelles Risiko, kein Detail.

CLI, Tool-Use und Halluzinationen

Das eigentlich Spannende an Hermes ist sein Tool-Anspruch. Die Metadaten versprechen Tool-Use, Long-Context und Agentic-Orchestrator. Das Benchmark-Ergebnis zeigt jedoch einen deutlichen Bruch zwischen Anspruch und Einsatzsicherheit. Der ToolUse-Score liegt bei 67.46, die Tool Execution selbst bei 90.0. Das bedeutet vereinfacht: Das Modell kann Werkzeuge formal einbinden und den Ablauf grundsätzlich bedienen. Aber wenn es um die inhaltliche Treue zum Tool-Ergebnis geht, wird es heikel.

Halluzinationen

Hier liegt die Achillesferse des Modells. In drei Tool-Use-Aufgaben generierte Hermes Inhalte, die nicht aus dem abgerufenen Tool-Ergebnis stammten, sondern erfunden waren. Das führte jeweils zu einer Halluzinationsbegrenzung im Score. Für content-kritische Aufgaben wie Recherche, Faktenberichte oder agentische Zusammenfassungen ist das kein kleiner Schönheitsfehler, sondern ein disqualifizierendes Signal. Ein Tool-Modell darf nicht so tun, als habe es nachgesehen, wenn es in Wahrheit improvisiert hat.

Gerade weil Hermes architektonisch auch als Agentic-Orchestrator eingeordnet ist, fällt dieser Befund schwerer ins Gewicht. Ein orchestrierendes Modell muss nicht jeden String perfekt exekutieren. Es darf bei Shell-Feinheiten oder exakten One-Linern gelegentlich von spezialisierten Sub-Agenten profitieren. Was es sich nicht leisten darf, ist das freie Ausschmücken von Tool-Outputs. Denn genau dort endet Orchestrierung und beginnt Fiktion.

Der Vergleich mit dem Standard-Modus desselben Modells ist nüchtern interessant. Der Thinking-Lauf verbessert den Gesamtscore leicht von 67.14% auf 68.02% und hebt vor allem Dokumentation sowie ToolUse etwas an. Gleichzeitig sinken Content Transformation, Cultural Intelligence und UX Writing leicht. Thinking macht Hermes also nicht grundsätzlich besser. Es macht das Modell eher etwas analytischer und etwas weniger glatt. Das kann je nach Aufgabe Gewinn oder Reibungsverlust sein.

Kulturelle Intelligenz

Mit 67.3 Punkten im Cultural-Intelligence-Modul bleibt Hermes hinter seinem besseren Beispiel zurück. Das ist schade, weil gerade die qualitative Probe zeigt, dass das Modell problematische Begriffe, toxische Metaphern und gendercodierte Formulierungen im Deutschen solide entschärfen kann. Es arbeitet die groben Störungen weg, ohne unnötig zu moralisieren. Das ist praktisch und oft genau richtig.

Was fehlt, ist Feinmotorik. Der Judge bemängelt holprige Formulierungen wie „geselligem Abenteuern“ und einen insgesamt neutraleren, weniger einladenden Ton als im Referenztext. Hermes entfernt Giftstoffe, aber es kocht daraus noch kein gutes Menü. Für interne Umschreibungen reicht das oft. Für öffentliche Kommunikation mit Anspruch auf idiomatische Präzision eher nicht.

Datenschutz und Datenhoheit

Ein eigener Cloud-Datenschutzblock ist hier nicht nötig, weil Hermes 4.3 36B (vLLM, Seed-OSS, Dense, NVFP4) als Open-Weights-Modell lokal betrieben wird. Relevant bleibt dennoch die Provenienz: Das Weights-Provenienz-Risiko ist mit MEDIUM bewertet, weil die öffentlich verfügbaren Apache-2.0-Gewichte aus einem US-geprägten Kontext stammen und Nous Research als US-Unternehmen dem CLOUD Act unterliegt. Für den lokalen Einsatz entschärft das den operativen Datenabfluss deutlich, löst aber nicht jede Governance-Frage rund um Herkunft und Compliance-Dokumentation.

Fazit

Hermes 4.3 36B (vLLM, Seed-OSS, Dense, NVFP4) ist kein schlechtes Modell. Es ist aber eines, das man verstehen muss, bevor man ihm vertraut. Als lokaler Generalist der Server-Klasse mit 36 Milliarden Dense-Parametern bringt es echten Werkzeugkasten mit: lange Kontexte, Thinking-Modus, offene Gewichte, Apache-2.0-Lizenz, brauchbare Analysefähigkeiten. Im besten Fall wirkt es wie ein bedächtiger technischer Redakteur mit Sicherheitsgrundwissen und einem Hang zur Übererklärung. Im schlechteren Fall wie genau derselbe Redakteur, der bei drei entscheidenden Stellen die Vorgabe überliest und zwei Fakten hinzudichtet.

Die Stärken sind real: token-ökonomisches Verhalten, sauber strukturierte Antworten, ordentliche Security-Basis, brauchbare Reasoning-Qualität und formal solide Tool-Anbindung. Die Schwächen sind ebenfalls real und für den Einsatz wichtiger als mancher Mittelwert: sieben Timeouts in 49 Tests, kritische Tail-Latenz, wiederholte Sprachfehler, ein harter Wortlimit-Verstoß mit automatischem 20%-Abzug und vor allem drei halluzinierende Tool-Use-Fälle. Für agentische Recherche oder faktenkritische Workflows ist das zu viel. Für lokale Wissensarbeit, Entwürfe, erste Analysen und unkritische Dokumentationshilfe kann Hermes dagegen sinnvoll sein, sofern ein Mensch die letzte Kontrolle behält.

Kurz gesagt: Dieses Modell hat Verstand, aber keine eiserne Disziplin. Wer einen freien, lokal betreibbaren Assistenten mit Charakter sucht, findet hier Substanz. Wer Verlässlichkeit ohne Nachkontrolle braucht, sollte weitersuchen.

Diese Auswertung wurde automatisch auf Grundlage der Benchmark-Daten generiert. Eingesetztes Modell: GPT 4.5 von OpenAI. Die Rohdaten und die vollständige Methodik sind im GitHub-Projekt dokumentiert.