Hermes 4 14B (llama.cpp, Q6_K, Abliterated)

LLM Model Review

Aktualisiert am 12.6.2026 · Instruct · Thinking-Optional · Uncensored-Finetuned

Mit einem Gesamtscore von 68,25 Prozent präsentiert sich Hermes 4 14B (llama.cpp, Q6_K, Abliterated) als eigensinniger Desktop-Generalist mit klarer Handschrift: schnell genug für ernsthafte Arbeit, offen im Ton, oft brauchbar, aber nicht frei von groben Fehltritten. Der Speed Profile Badge „Batch Tool Expert“ passt erstaunlich gut. Dieses Modell ist kein nervöser Chat-Sprinter, sondern eher ein lokaler Arbeiter für längere Durchläufe, der bei Strukturaufgaben ordentlich liefert und bei Präzision gelegentlich die Nerven verliert. Sovereign Risk: MEDIUM — die Gewichte stammen von einem US-Anbieter; bei lokaler Nutzung greift der CLOUD-Act-Kontext praktisch nicht direkt, wohl aber bei Hosting über Dritte.

Kopfnoten: Stabilität und Zuverlässigkeit

Architektur und Charakter: Was diese Kategorie erwarten lässt

Die Vorab-Einordnung als Instruct, Thinking-Optional, Uncensored-Finetuned ist hier nicht bloß Etikett, sondern erklärt einen guten Teil des Verhaltens. Als Generalist soll das Modell breit funktionieren, nicht nur in einer Nische glänzen. Als Desktop-Modell mit 14 Milliarden Parametern und dichter Architektur trägt es seine gesamte Kapazität bei jedem Token mit sich herum. Es gibt also keinen Experten-Trick wie bei Mixture-of-Experts-Modellen. Was Hermes kann, muss aus diesen 14 Milliarden Parametern vollständig kommen.

Die Instruct-Seite sieht man sofort. Hermes antwortet meist direkt, strukturiert und ohne künstliches Herumtheoretisieren. Das ist angenehm, solange die Aufgabe eine saubere Umsetzung verlangt. Es wird problematisch, wenn die Aufgabe ausdrücklich mehr Tiefe, Gegenprüfung oder Variantenvergleich fordert. Dann wirkt das Modell nicht dumm, sondern voreilig. Thinking-Optional ist ebenfalls relevant: Solche Modelle unterstützen grundsätzlich einen erweiterten Denkmodus, der im Benchmark aber bewusst nicht aktiviert wurde. Gemessen wurde also das Standardverhalten ab Werk. Und das Standardverhalten ist hier klar: Hermes löst lieber schnell und konkret, als lange und elegant zu denken.

Der dritte Tag, Uncensored-Finetuned, setzt den Ton. Anders als bei radikal „abliterierten“ Modellen scheint die Basisarchitektur zwar nicht mechanisch beschädigt, aber die Prioritäten liegen sichtbar nicht auf maximaler Disziplin in komplexen Prüfaufgaben. Solche Modelle sind oft offen, hilfreich und stilistisch freier, verfehlen aber Nuancen bei Code, DevOps und sicherheitskritischer Präzision. Genau das sieht man hier. Nicht als Totalversagen, aber als wiederkehrendes Muster.

Geschwindigkeit und lokaler Betrieb

Hermes 4 14B (llama.cpp, Q6_K, Abliterated) wurde lokal auf einem Apple Silicon M4 mit 24GB Unified Memory (Shared RAM/VRAM) getestet. Diese Information ist nicht dekorativ. Für ein dichtes 14B-Modell in Q6_K ist die Speichergrenze real, und die Timeouts sprechen eine deutliche Sprache.

Die gemessene Generierungsgeschwindigkeit von 25,62 Tokens pro Sekunde ist für diese Klasse ordentlich. Sie erklärt auch den Badge „Batch Tool Expert“: kein Modell für hektisches Hin-und-her, aber gut geeignet für Aufgaben, die man losschickt und dann arbeiten lässt. Das Problem ist nicht die Rohgeschwindigkeit pro Token. Das Problem ist die Streuung. Wenn ein Modell im Mittel vernünftig schreibt, aber in fünf Prozent der Fälle über fünf Minuten Tail-Latenz produziert, dann ist jeder Agenten-Workflow plötzlich ein Geduldsspiel mit Sollbruchstelle.

Positiv ist immerhin die Token-Ökonomie. Hermes verhält sich token-ökonomisch. Kein Modul übersteigt den erwarteten Verbosity-Rahmen. Selbst dort, wo es etwas ausführlicher wird, bleibt es innerhalb des grünen Bereichs. Für ein lokales Modell ist das wichtig, weil mehr Text hier nicht Cloud-Kosten, sondern vor allem mehr Wartezeit bedeutet.

Code Quality: sauber formatiert, inhaltlich zu oft daneben

Der Code-Quality-Wert von 62,9 Prozent ist einer dieser Fälle, in denen die Oberfläche seriöser wirkt als der Unterbau. Hermes liefert Tabellen, spricht korrekt Deutsch, benennt echte Schwachstellen und hält die Form. Das ist mehr, als viele freiheitsliebende Finetunes schaffen. Aber die inhaltlichen Lücken wiegen schwer.

Im konkreten Security-Audit erkannte das Modell 14 Schwachstellen, während der Referenzstandard 19 identifizierte. Noch problematischer ist die Art der Fehler. Hermes übersah sicherheitsrelevante Punkte wie Session Fixation, CSRF-Schutz, hartkodierte Secrets, DB-Credentials und Token-Ablauf im Passwort-Reset. Das sind keine exotischen Randnotizen, sondern Stoff, den man in einer ernsthaften Review nicht liegen lassen sollte.

Schlimmer ist die Fehlklassifikation. Das Modell markierte eine vermeintliche SQL-Injection im Profil-Update, obwohl dort bereits vorbereitete Statements verwendet wurden. Der eigentliche Fehler war eine IDOR-Schwachstelle, also ein unsicherer Direktzugriff auf fremde Objekte. Das ist kein kleiner Versprecher, sondern ein Lesefehler am offenen Code. Dazu kommt eine „potenzielle Command Injection“, für die im vorliegenden Snippet gar keine passenden Systemaufrufe existierten. Wer in einem Security-Audit Geister sieht, senkt nicht nur den Score, sondern das Vertrauen.

Das Urteil fällt deshalb hart aus: Hermes kann Security-Probleme benennen, aber nicht mit der Verlässlichkeit, die man für Code-Review oder Secure Development braucht. Milde ist hier nur insofern angebracht, als ein uncensored-finetuned Generalist nicht primär für DevSecOps gezüchtet wurde. Trotzdem gilt: Wenn ein Modell bei echten Schwachstellen danebengreift und gleichzeitig falschen Alarm schlägt, ist es als alleiniger Prüfer nicht tragfähig.

CLI und Tool-Nähe: überraschend brauchbar, aber nicht frei von Erfindung

Der CLI-Benchmark mit 85,56 Prozent gehört zu den erfreulicheren Seiten dieses Modells. Hermes folgt Befehlslogik meist gut, bleibt knapp und produziert keinen unnötigen Roman. Für typische Shell-nahe Aufgaben ist das ein echter Pluspunkt. Es passt zum Instruct-Profil: direkte Aufforderung rein, brauchbare Struktur raus.

Diese Stärke wird allerdings durch Halluzinationen im Tool-Kontext beschädigt. In zwei Tool-Aufgaben erfand das Modell Inhalte, die nicht aus dem tatsächlich abgerufenen Tool-Ergebnis stammten. Der Score wurde deshalb durch eine Halluzinationsgrenze gedeckelt. Für content-kritische Aufgaben wie Recherche, Verifikation oder faktengebundene Berichte ist das ein disqualifizierendes Signal. Ein Tool-using-Modell, das nach dem Blick ins Werkzeugfach trotzdem eigene Fakten dazudichtet, verhält sich wie ein Monteur, der Schrauben zählt, aber Zahlenwürfel liest.

Das ist der entscheidende Vorbehalt für alle Agenten- oder Automationsideen. Hermes kann Tool-Ausgaben verarbeiten. Man darf ihm nur nicht blind glauben, wenn Genauigkeit wichtiger ist als Form.

Reasoning und Logik: korrekt, knapp, etwas zu zufrieden mit sich selbst

Im Reasoning-Bereich landet Hermes bei 64,55 Prozent. Das ist weder Absturz noch Triumph, sondern ein sauberes Beispiel für ein Modell, das das Rätsel löst, aber nicht wirklich ausleuchtet. Im protokollierten Wächter-und-Türen-Puzzle war die Kernlogik richtig. Die doppelte Umkehr wurde korrekt erkannt, die finale Strategie stimmte. Inhaltlich also kein Patzer.

Der Punktverlust kam aus der Tiefe. Die Aufgabe verlangte sichtbares Herleiten und das Erkunden unterschiedlicher Ansätze. Hermes lieferte dagegen im Kern eine funktionierende Kurzform. Das ist effizient, aber nicht vollständig. Es fehlten systematische Gegenprüfung, alternative Formulierungen, robustere Erklärung und der letzte didaktische Schliff. Das Modell denkt hier nicht falsch. Es denkt nur ungern länger, wenn es die Antwort schon sieht.

Für die Kategorie ist das folgerichtig. Ein Instruct-Modell im Standardmodus priorisiert Antwort über Exegese. Wer ein Modell sucht, das Probleme breit entfaltet, Gegenbeispiele abklopft und seine Schlüsse fast schon ausstellt, wird hier nicht glücklich. Wer dagegen eine korrekte Erstlösung mit brauchbarer Erklärung will, bekommt in vielen Fällen genau das.

UX Writing: funktional, kontrolliert, aber zu wenig psychologische Raffinesse

Mit 61,55 Prozent zeigt Hermes im UX-Writing seine sympathische und gleichzeitig frustrierende Seite. Die Antworten sind geordnet, sprachlich sauber und formal diszipliniert. Im vorliegenden Mikrocopy-Fall hielt das Modell die Wortlimits ein, blieb auf Deutsch und produzierte die geforderte Tabellenstruktur. Das Fundament stimmt.

Was fehlt, ist die eigentliche Magie guter UX-Texte. Der Richter beschreibt die Vorschläge treffend als „korrekt, aber konservativ“. Hermes ersetzt Jargon, aber ohne das psychologische Feintuning, das aus bloßer Textbereinigung echte Nutzerführung macht. Besonders aufschlussreich ist der Fehler in Schritt 3 einer mehrstufigen Flow-Optimierung: Wo die Aufgabe noch eine Auswahlhandlung verlangte, lieferte das Modell schon eine Abschlussbotschaft. Es verwechselte also Aktion mit Belohnung. Das ist keine Katastrophe, aber genau die Art von strukturellem Missverständnis, die in realen Interfaces zu unnötiger Reibung führt.

Hermes schreibt brauchbare Oberfläche, aber selten die Sorte Mikrocopy, die Nutzer wirklich elegant durch Unsicherheit führt. Es klingt vernünftig. Es denkt zu selten in Verhaltensmustern.

Content Transformation: stark in Produktion, schwächer in Diagnose

Der Wert von 74,43 Prozent im Bereich Content Transformation gehört zu den besten Disziplinen des Modells. Zu Recht. In der protokollierten Videoskript-Aufgabe lieferte Hermes eine vollständige, gut getaktete deutsche Produktion mit Zeitmarken, Screen-Anmerkungen und brauchbarer Sprechsprache. Gerade das Timing wurde vom Judge ausdrücklich gelobt. Für einen Desktop-Generalisten ist das mehr als respektabel.

Die Schwäche liegt wieder in der Voranalyse. Das Modell benennt, was fehlt, aber oft eher als Checkliste denn als Diagnose. Es sagt, dass der Hook fehlt, nicht warum das im Zuschauerverhalten schmerzt. Es baut ein Easter Egg ein, aber nur als dekorativen Textblitz statt als Interaktionsmechanik. Es liefert Produktionsmaterial, aber nicht die letzte Schicht redaktioneller Strategie.

Hinzu kommt ein dokumentierter Einzelfall in diesem Modul: In einer Aufgabe mischte das Modell in ein ansonsten deutsches Skript ein englisches „But wait“ ein. Das ist kein flächendeckender Sprachzerfall, aber im Produktiveinsatz mit fester Markensprache ein direkter Nachbearbeitungspunkt.

Kurz gesagt: Hermes adaptiert Inhalte gut, inszeniert sie ordentlich und bleibt handwerklich nützlich. Es ist eher Produktionsassistent als Creative Director.

Documentation Quality: solide Schreibhilfe mit einem peinlichen Sprachbruch

Die 65,94 Prozent in Documentation Quality klingen zunächst nach kontrollierter Mittelklasse. Das passt auch zum generellen Eindruck: Hermes kann dokumentarisch schreiben, strukturieren und erklären. Aber in diesem Modul steht ein glasklarer Regelverstoß im Protokoll, und der muss schwerer wiegen als jede allgemeine Freundlichkeit.

In einer Dokumentationsaufgabe ignorierte das Modell die explizite Sprachanweisung und antwortete auf Englisch, obwohl Deutsch verlangt war. Das System registrierte einen Language Mismatch mit Sprachmarker-Zählung DE=25, EN=60. Das ist kein stilistischer Grenzfall, sondern eine saubere Instruction-Following-Schwäche. In Umgebungen mit fixer Zielsprache, etwa interner Dokumentation, Support-Vorlagen oder regulatorischen Texten, ist so ein Ausrutscher nicht akademisch, sondern operativ störend.

Bemerkenswert ist dabei, dass dies als einzelner dokumentierter Sprachfehler erscheint, nicht als breit nachgewiesenes Serienmuster über mehrere Aufgaben. Trotzdem bleibt der Punkt unangenehm. Gerade weil Hermes sonst oft instruktionsnah arbeitet, wirkt ein solcher Wechsel ins Englische wie ein unnötiger Kontrollverlust.

Cultural Intelligence: ordentlich entgiftet, aber nicht immer feinfühlig genug

Mit 71,0 Prozent schneidet Hermes im kulturellen und tonalen Feingefühl solide ab. In der protokollierten Aufgabe entfernte es toxische Begriffe, glättete grobe Männlichkeitscodes und schrieb durchgehend auf Deutsch. Das ist die Pflicht. Die Kür verpasste es knapp.

Der Judge kritisiert vor allem die Wortwahl. Statt präziser, einladender und wirklich inklusiver Sprache griff Hermes stellenweise zu generischeren oder etwas fordernderen Formulierungen. „Mitarbeiter“ statt „Fachkraft“, „Wir erwarten“ statt eines einladenderen Registers. Dazu kommt, dass die Lösung etwas länger und schwerfälliger ausfiel als nötig. Das Modell weiß also, was sozial entgiftet werden muss. Es hat nur nicht immer das feinste Ohr für Tonalität.

Für viele praktische Umschreibungen ist das völlig ausreichend. Wer allerdings Texte für Recruiting, Diversity-Kommunikation oder sensible Markenstimmen produziert, sollte die letzte Schleifrunde einem Menschen überlassen.

Security und Halluzinationen: der gefährlichste Mix ist Selbstvertrauen plus Lücke

Über alle Module hinweg zeigt Hermes zwei Arten von Risiko. Erstens analytische Lücken in sicherheitsnahen Aufgaben. Zweitens faktische Erfindungen im Tool-Kontext. Jede dieser Schwächen für sich wäre handhabbar. Zusammen ergeben sie das eigentliche Problemprofil des Modells.

Im Security-Audit war die Hauptsünde nicht fehlende Form, sondern fehlende Trennschärfe. Echte Schwachstellen wurden übersehen, ungefährliche Stellen teils falsch belastet. In den Tool-Aufgaben wiederum halluzinierte Hermes Inhalte, die nicht aus dem Werkzeugsignal gedeckt waren. Für kreative Aufgaben ist diese Offenheit oft produktiv. Für Recherche, technische Verifikation und sicherheitskritische Einschätzungen ist sie Gift.

Man kann es noch zugespitzter sagen: Hermes irrt nicht wie ein scheues Modell, das lieber vorsichtig bleibt. Es irrt eher wie jemand, der auch dann noch antwortet, wenn Zurückhaltung die bessere Tugend wäre.

Datenschutz und Datenhoheit

Da es sich hier um ein lokal betriebenes Open-Weights-Modell handelt, entsteht beim Bezug der Gewichte selbst kein direkter Cloud-Datenabfluss. Die bekannte Lage ist dennoch nicht völlig neutral: Das berechnete Sovereign Risk liegt bei MEDIUM, weil die Gewichte von Nous Research Inc., San Francisco, USA, stammen. Laut Vendor Card gilt für die geprüfte Quelle lokales oder Drittanbieter-Hosting, Datenspeicherung 0 Tage, aber kein GDPR DPA. Für europäische Unternehmen heißt das praktisch: Die Modellquelle ist für lokalen Einsatz unkritischer als ein US-API-Dienst, doch bei Deployment über externe Hoster lebt die Rechts- und Compliance-Frage sofort wieder auf. Zur geprüften Quelle ist das Weights-Provenienz-Risiko bereits durch die US-Herkunft erklärt; bei rein lokaler Ausführung bleibt es vor allem ein Herkunfts-, kein Transferproblem.

Fazit

Hermes 4 14B (llama.cpp, Q6_K, Abliterated) ist ein interessantes Modell, gerade weil es nicht geschniegelt auftritt. Es erreicht 68,25 Prozent und zeigt dabei echten Nutzwert in CLI-nahen Aufgaben, solider Content-Adaption und insgesamt vernünftiger Token-Ökonomie. Als lokaler Desktop-Generalist ist das beachtlich. Vor allem, weil die 25,62 Tokens pro Sekunde auf dem Testsystem grundsätzlich ein flüssiges Arbeiten erlauben würden, wenn die Stabilität nicht dazwischenfunken würde.

Doch die Schwächen sind nicht kosmetisch. 5 von 43 Timeouts und eine P95-Antwortzeit von 303,23 Sekunden machen das Setup auf dieser Maschine für unbeaufsichtigte Produktivabläufe faktisch nicht einsetzbar. Dazu kommen Security-Fehlklassifikationen, ein dokumentierter Sprachfehler in der Dokumentation und Halluzinationen in Tool-gebundenen Aufgaben. Das Modell ist also nicht unbrauchbar. Es ist nur eines, dem man Aufgaben mit Augenmaß geben muss.

Die beste Empfehlung lautet deshalb: einsetzen für kreative Umschreibungen, Content-Produktion, allgemeine Assistenz und strukturierte Batch-Arbeit mit menschlicher Nachkontrolle. Nicht einsetzen als alleinige Instanz für Security-Reviews, faktenkritische Tool-Auswertung oder sprachlich strikt regulierte Dokumentationspipelines. Die lokale Open-Weights-Herkunft ist ein Pluspunkt für Datenhoheit, die US-Provenienz der Gewichte bleibt als Fußnote relevant. Hermes hat Charakter, keine Frage. Aber Charakter ersetzt keine Zuverlässigkeit.

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.