Hermes 4 14B (llama.cpp, Q4_K_M)

LLM Model Review

Erstellt am 4.6.2026 · Instruct · Thinking-Optional

Mit einem Gesamtscore von 67.34% und dem Speed-Profile-Badge „Interactive Tool Expert“ gibt sich Hermes 4 14B (llama.cpp, Q4_K_M) als lokaler Allrounder mit Werkzeug-Ambitionen, nicht als Denkmaschine. Das passt zur kuratierten Einordnung erstaunlich gut: ein Generalist der Desktop-Klasse, dicht gebaut mit 14 Milliarden Parametern, der Instruktionen meist direkt und brauchbar ausführt, aber unter Druck schneller die Fassung verliert als die besten Modelle dieser Gewichtsklasse. Sovereign Risk: MEDIUM — NousResearch ist ein US-Anbieter der Gewichte; bei lokaler Nutzung greift der CLOUD-Act-Kontext praktisch erst dann, wenn man das Modell über fremde Hosting- oder API-Infrastruktur betreibt.

Kopfnoten: Stabilität und Zuverlässigkeit

Architektur-Fit: Was die Kategorie hier wirklich bedeutet

Die Metadaten „Instruct, Thinking-Optional“ sind bei diesem Modell keine dekorative Etikette, sondern fast schon die Gebrauchsanweisung. Hermes 4 14B (llama.cpp, Q4_K_M) antwortet wie ein klassisches Instruct-Modell: direkt, strukturiert, oft formal sauber, selten verspielt. Wenn eine Aufgabe eine klare Form verlangt, versucht es zu liefern. Wenn sie dagegen tiefe Abwägung, präzise Priorisierung und robuste Selbstkontrolle verlangt, wird sichtbar, dass wir hier nicht mit einem vollwertigen Reasoning-Spezialisten arbeiten.

Wichtig ist der zweite Teil der Einordnung: Thinking-Optional. Dieser Modus wurde im Benchmark bewusst nicht aktiviert. Bewertet wurde also das Verhalten so, wie ein typischer Nutzer das Modell ohne Spezialkonfiguration erlebt. Das erklärt, warum Hermes im Reasoning-Modul respektabel wirkt, aber nicht die pädagogische Tiefe oder die methodische Ausdauer größerer Denkmodelle erreicht. Es kann logisch arbeiten. Es will nur nicht dauerhaft in den fünften Gang.

Als Generalist in der Desktop-Klasse und mit dichter Architektur ist die Erwartungshaltung klar: solide Breite, vernünftige Struktur, akzeptable lokale Nutzbarkeit. Nicht erwartet werden Wunder bei Sicherheitsanalyse, langen Dokumentausgaben oder eng getakteten Multi-Constraint-Prompts. Genau dort entscheidet sich dann, ob ein Modell nur kompetent aussieht oder auch im Alltag trägt. Hermes schwankt.

Geschwindigkeit: flott genug, aber mit langem Schatten

Auf dem lokalen Referenzsystem, einem Apple Silicon M4, 24GB Unified Memory (Shared RAM/VRAM), erreicht Hermes 4 14B (llama.cpp, Q4_K_M) laut Leaderboard 30.3 Tokens pro Sekunde. Das ist für ein 14B-Dense-Modell in Q4 eine vernünftige Zahl. Der Badge „Interactive Tool Expert“ signalisiert den beabsichtigten Einsatz ziemlich treffend: nicht Massentext im Hintergrund, sondern interaktive Aufgaben mit Werkzeugbezug, also Antworten, die schnell genug kommen sollen, um einen Dialog nicht abzuwürgen.

Das Problem ist nicht die reine Generationsgeschwindigkeit. Das Problem ist der Schwanz der Verteilung. Im Mittel wirkt Hermes brauchbar, in den Ausreißern wird es unerquicklich. Wenn in fünf Prozent aller Anfragen fast zweieinhalb Minuten oder länger vergehen, ist das für einen Agenten-Loop oder eine fokussierte Arbeitssitzung keine Nebensache mehr. Bei einem lokalen Desktop-Modell ist das meist kein API-Zirkus, sondern ein Fingerzeig auf das Testsystem: Speichergrenze, Lastspitzen, interne Komplexität einzelner Prompts. Anders gesagt: Das Modell passt grundsätzlich auf die Maschine, lebt dort aber nicht immer entspannt.

Positiv ist die Token-Ökonomie. Kein Modul überschreitet den erwarteten Verbosity-Rahmen. Für ein lokales Modell ist das mehr als eine Kostenfrage. Weniger Text heißt hier oft auch weniger Wartezeit. Hermes redet nicht hemmungslos drauflos. Wenn es langsam wird, dann nicht, weil es epische Romanlängen produziert, sondern weil bestimmte Aufgaben es strukturell aus dem Tritt bringen.

Code Quality: brauchbare Analyse, fragile Ausführung

Die Code-Quality-Note von 62.5% erzählt schon, dass hier keine Spezialistenklasse unterwegs ist. Die Audit-Protokolle zeigen auch warum. Hermes erkennt einige offensichtliche Sicherheitsmängel korrekt, etwa SQL Injection, unsichere Cookies, problematische Vergleichsoperatoren oder Klartextpasswörter. Es kann also durchaus technische Risiken sehen und auch naheliegende Fixes nennen. Das ist die gute Nachricht.

Die schlechte Nachricht ist gravierender: Sobald die Aufgabe eine größere, präzise tabellarische Sicherheitsanalyse verlangt, wird das Modell instabil. Im dokumentierten Security-Audit brach die Ausgabe in einer Wiederholungsschleife zusammen, die Tabelle wurde strukturell beschädigt, mehrere SQL-Injection-Befunde tauchten redundant in leicht variierten Versionen auf, und zugleich fehlten kritische Schwachstellen wie IDOR, Session Fixation, Token-Ablauf, schwacher Zufallszahlengenerator oder reflektiertes XSS. Das ist kein bloßes Schönheitsproblem. Wer Security-Audits mit redundanten Zeilen und fehlenden Kernbefunden ausliefert, produziert im Zweifel trügerische Sicherheit. Und trügerische Sicherheit ist die teuerste Sorte.

Tabellen-Robustheit (Code Quality): Das Modell zeigt einen prompt-sensitiven Tabellen-Generierungsfehler. Es lieferte in [1] der Code-Quality-Tests keine verwertbare Tabelle (Endlosschleife / Token-Abbruch), obwohl die Analyse-Texte inhaltlich oft begonnen wurden. Der Fehler tritt primär bei Prompts ohne spezifische Markdown-Beispielzeilen auf. Anmerkung: Dieser Mangel ließe sich im Produktiveinsatz durch gezieltes Prompt-Engineering (z. B. Few-Shot-Beispielzeilen) einfach ausgleichen. CrucibleMark testet jedoch gezielt die native Zero-Shot-Prompt-Robustheit eines Modells. Da Modelle solch unaufgeregte Format-Anfragen out-of-the-box abfangen können sollten, wird diese Fragilität hier trotz des Workarounds als realer Alltagsmangel betrachtet und schlägt sich konsequent im verringerten Score nieder.

Gerade im Security-Kontext wiegt das doppelt schwer. Hermes ist kein zensur-chirurgisch beschädigtes Abliteration-Experiment, sondern ein uncensored finetuned Modell mit intakter Grundarchitektur. Deshalb wäre es billig, die Schwächen hier einfach mit dem Etikett „nicht dafür gedacht“ wegzuwischen. Mildernd gilt nur: Sein Fokus liegt nicht primär auf Security-Engineering. Entschuldigend gilt das nicht. Für ernsthafte Code-Reviews und Verwundbarkeitsanalysen braucht es mehr als Schlagwort-Erkennung. Man braucht Vollständigkeit, Priorisierung und Formstabilität. Genau dort wird Hermes nervös.

CLI und Tool-Nähe: besser als die Sicherheitsnote vermuten lässt

Im CLI-Benchmark steht Hermes mit 85.56% deutlich stärker da als im eigentlichen Code-Quality-Modul. Das ist kein Widerspruch, sondern ein Charakterhinweis. Das Modell liegt näher an praktischer Assistenz als an tiefer technischer Forensik. Wo klare Shell-Aufgaben, Befehlsstruktur und zielgerichtete Ausführung gefragt sind, wirkt es fokussierter und nützlicher. Der „Interactive Tool Expert“-Badge kommt nicht aus dem Nichts.

Allerdings endet die Euphorie beim Tool-Use dort, wo Faktentreue gegen Bequemlichkeit antreten muss. In zwei Tool-Use-Aufgaben halluzinierte das Modell Inhalte, die nicht im tatsächlich abgerufenen Werkzeugergebnis standen. Das ist keine kleine Ungenauigkeit, sondern ein disqualifizierendes Verhalten für recherchekritische oder faktengebundene Prozesse. Sobald ein Modell externes Material abrufen soll, muss seine erste Tugend sein, zwischen gesehen und erfunden zu unterscheiden. Hermes tut das hier nicht zuverlässig genug.

Reasoning und Logik: ordentlich, aber nicht tief genug für große Sprünge

Die Reasoning-Note von 64.02% ist weder Absturz noch Ausrufezeichen. Sie passt zum Modell. Hermes kann logisch denken. In einem klassischen Wächter-und-Türen-Rätsel liefert es eine korrekte, vollständig deutsche und sauber strukturierte Lösung inklusive <thought>-Tags. Es prüft mehrere Ansätze, verwirft direkte Fragen nachvollziehbar und landet bei der richtigen indirekten Formulierung. Das ist mehr als bloßes Musterabspulen.

Was fehlt, ist die zweite Lage. Die besten Reasoning-Modelle erklären nicht nur, was funktioniert, sondern warum das zugrunde liegende Prinzip robust ist. Sie geben Alternativformulierungen, abstrahieren die Methode und machen die Lösung lehrbar. Hermes bleibt näher am erfolgreichen Lösen als am guten Erklären. Für Alltagslogik reicht das. Für komplexe Planung, mehrstufige Abhängigkeiten oder heikle Abwägungen wird es schnell zu flach.

Immerhin zeigt sich hier kein systematischer Metakognitions-Konflikt. Das Modell verweigert die geforderten Denkformate nicht reflexhaft, sondern arbeitet mit. Das ist bei lokal laufenden Open-Weights-Modellen keineswegs selbstverständlich und verdient eine nüchterne Anerkennung. Hermes diskutiert lieber zu wenig als gar nicht. Das ist die sympathischere Schwäche.

UX Writing: die schwächste Flanke

Mit 56.65% ist UX Writing der sichtbarste Problemraum dieses Modells. Das ist deshalb relevant, weil Instruct-Modelle gerade bei knappen, tonalen, präzisen Formaten eigentlich glänzen sollten. Hermes tut es hier nicht. Es schreibt selten katastrophal, aber auffällig oft zu schwer, zu lang oder zu generisch. Die Sprache wirkt dann nicht falsch, sondern nur eine halbe Ebene neben der Aufgabe. Für Microcopy ist das fast dasselbe.

Der Kernfehler ist fehlende Verdichtung. Gute UX-Texte sind kleine Präzisionswerkzeuge. Hermes behandelt sie gelegentlich wie Mini-Absätze aus einer Support-Doku. Das liest sich professionell und trifft trotzdem den Zweck nicht ganz. Gerade auf Buttons, Hinweisen, Fehlermeldungen oder kurzen Conversion-Texten wird aus „formal brauchbar“ schnell „praktisch zu lang“. Für ein Modell mit Instruct-DNA ist das eine Enttäuschung mit Ansage.

Content Transformation: kreativ brauchbar, disziplinarisch anfällig

Mit 73.3% gehört Content Transformation zu den angenehmeren Seiten von Hermes. Das Modell kann Material umarbeiten, umformen, strukturieren und in einen neuen Ton überführen. Im Protokoll zum Videoskript gelingt ihm eine vollständige deutsche Ausarbeitung mit Hook, Segmentierung, Annotationen und brauchbarer Produktionsnähe. Das ist nicht nichts. Viele lokale Modelle scheitern hier früher an Struktur oder Tonalität.

Aber genau in diesem Modul zeigt sich auch ein struktureller Makel: Hermes verliert unter gleichzeitigen Vorgaben aus Stil, Länge und Format wiederholt das Wortlimit als erste Bedingung. In einer Aufgabe überschritt es die explizite Vorgabe von 250 Wörtern auf 380 Wörter, also 152% des Limits. Das System verhängte dafür einen automatischen Abzug von 20% beziehungsweise 16.40 Punkten auf den erreichten Aufgabenscore. In einer zweiten Aufgabe überschritt es die Vorgabe von 900 Wörtern auf 1331 Wörter, also 148% des Limits. Auch hier griff ein automatischer Abzug von 20% beziehungsweise 17.60 Punkten. Die inhaltliche Qualität der Antwort ist damit irrelevant. Die Strafe greift unabhängig davon.

Das Längenproblem ist kein isolierter Ausreißer. Über mehrere Aufgaben im Content-Transformation-Bereich zeigt das Modell ein konsistentes Muster: Bei simultanen Vorgaben aus Sprache, Länge und Format verliert es das Wortlimit als erste Bedingung. Das ist im Alltag ärgerlich, im Benchmark aber völlig zu Recht teuer. Wer „maximal 250 Wörter“ sagt, meint nicht „schreiben Sie erst einmal, was Ihr Herz begehrt“.

Gerade das erwähnte Videoskript illustriert die Ambivalenz gut. In der Sache war vieles vorhanden: Hook, Produktionshinweise, Abschnitte, ein erkennbarer Versuch, gesprochene Sprache zu imitieren. Gleichzeitig wurde das Skript zu lang, das Timing unrealistisch und die editorische Präzision ausgedünnt. Hermes hat Ideen. Es hat nur nicht immer die Disziplin, sie rechtzeitig abzuschneiden.

Documentation Quality: nützlich, aber mit Hang zur Ausführlichkeit

Die 64.83% in Documentation Quality sind solide genug, um das Modell für interne Notizen, technische Erklärungen oder erste Entwürfe nicht vom Tisch zu wischen. Hermes kann strukturieren, ordnen, Abschnitte bilden und im Deutschen meist verständlich bleiben. Das ist mehr wert, als manche reine Chat-Modelle in dieser Größenklasse liefern.

Auffällig ist allerdings der vergleichsweise hohe Tokenverbrauch in diesem Modul: 3562 Tokens gegenüber einem Fleet-Median von 2494, also 1.43-fach so viel Text. Das ist noch im grünen Rahmen, aber der Trend ist klar. Hermes erklärt lieber etwas mehr als etwas weniger. Auf lokaler Hardware heißt das nicht höhere API-Kosten, sondern längere Wartezeit. Der Nutzer bezahlt mit Geduld statt mit Rechnung. Das ist günstiger, aber nicht gratis.

Cultural Intelligence: sprachlich sauber, kulturell nicht fein genug

Mit 73.6% schlägt sich Hermes in Cultural Intelligence insgesamt ordentlich. Es hält die deutsche Sprache sauber durch, folgt der „nur Ausgabe, keine Meta-Erklärung“-Vorgabe korrekt und liefert formell brauchbaren Text. Das Protokoll zeigt aber auch, wo die Decke hängt: Bei inklusiver Sprache und der echten Umformung toxischer, männlich codierter Stellenausschreibungsrhetorik bleibt das Modell zu konventionell.

Konkret griff es zu maskulinen Formen wie „Fachmann“ und „Kandidat“, obwohl gerade diese Schieflage entfernt werden sollte. Dazu blieb ein Teil der aggressiven Leistungsrhetorik erhalten. Das ist nicht grob daneben, aber eben kulturell nicht fein genug. Hermes versteht die Oberfläche der Aufgabe besser als ihre soziale Stoßrichtung. Für reine Übersetzung oder Tonanpassung reicht das oft. Für sensible HR-, Diversity- oder Community-Kommunikation braucht es eine kontrollierende Redaktion.

Halluzinationen: der Makel mit Produktionsrelevanz

Halluzinationen sind in diesem Benchmark kein metaphysisches Thema, sondern ein Betriebsrisiko. Und Hermes produziert hier einen klaren Befund: In zwei Tool-Use-Aufgaben wurden Inhalte erfunden, die nicht aus dem Werkzeugoutput stammten. Das ist besonders unerquicklich, weil das Modell gerade mit Tool-Nähe und strukturierter Assistenz wirbt.

Die praktische Konsequenz ist einfach. Für alles, was an echte Quellen, Rechercheergebnisse oder externe Systemausgaben gebunden ist, sollte man Hermes nie ohne Gegenprüfung laufen lassen. Das Modell ist in solchen Momenten nicht böswillig, sondern übergriffig. Es ergänzt, wo es nur wiedergeben dürfte. Für kreative Assistenz ist das harmlos. Für operative Wahrheitspflichten ist es Gift.

Datenschutz und Datenhoheit

Ein eigener Datenschutzalarm ergibt sich bei dieser lokal betriebenen Open-Weights-Variante nicht. Relevanter ist die Herkunft der Gewichte: Das berechnete Sovereign Risk liegt bei MEDIUM. Die Begründung ist sachlich und überschaubar. Nous Research ist ein US-Unternehmen, doch bei lokaler beziehungsweise selbst gehosteter Nutzung fallen laut Card weder zwingender Cloud-Transfer noch providerseitige Datenspeicherung an; die ausgewiesene Datenspeicherung liegt bei 0 Tagen. Eine GDPR-DPA ist nicht verfügbar, was für Unternehmen erst dann zum echten Compliance-Thema wird, wenn ein Drittanbieter-Hosting oder externer Dienst ins Spiel kommt. Kurz gesagt: lokal gut kontrollierbar, bei Fremdhosting sofort neu zu bewerten.

Fazit

Hermes 4 14B (llama.cpp, Q4_K_M) ist ein charakterstarker, aber nicht durchgehend verlässlicher Desktop-Generalist. Es folgt Instruktionen meist sauber, liefert brauchbare Struktur, arbeitet im CLI- und Transformationsbereich oft überzeugender als seine reine Gesamtzahl vermuten lässt und bleibt dabei token-ökonomisch. Für lokale Assistenz, Rohfassungen, Shell-nahe Hilfe und allgemeine Textarbeit ist das Modell ernsthaft brauchbar.

Seine Schwächen sind allerdings nicht akademisch, sondern praktisch. Security-Analysen leiden unter Fragilität und Lücken. UX Writing ist zu schwerfällig. Bei harten Wortlimits wird das Modell wiederholt nachlässig. Und in toolgebundenen Aufgaben halluziniert es Fakten dazu, die schlicht nicht da waren. Wer damit produktiv arbeitet, bekommt keinen Versager, aber auch keinen stillen Profi. Eher einen motivierten Kollegen, der oft richtig liegt, manchmal sauber formuliert und gelegentlich mit zu viel Selbstvertrauen den falschen Satz ergänzt.

Als lokales Modell mit 14B Dense-Architektur auf Desktop-Niveau ist das respektabel. Als unbeaufsichtigter Agent für sicherheitskritische, faktenkritische oder streng formatierte Workflows ist es nicht die richtige Wahl. Die Weights stammen von NousResearch unter Apache-2.0-Lizenz; das ausgewiesene Provenienz-Risiko ist MEDIUM, praktisch relevant wird es bei dieser Open-Weights-Variante aber erst außerhalb des rein lokalen Betriebs.

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.