Hermes 4 14B (Q6_K, Abliterated)

Mit einem Gesamtscore von 68.25% liefert Hermes 4 14B (Q6_K, Abliterated) ein erstaunlich brauchbares Generalist-Paket für die Desktop-Klasse: ein dichtes 14B-Modell, das Instruktionen meist direkt befolgt, in der Breite ordentlich arbeitet, aber bei Tiefe, Präzision und Verlässlichkeit immer wieder an seine Grenzen stößt. Der Speed-Profile-Badge „Batch Tool Expert“ passt: Das Modell ist kein hektischer Dialogpartner, sondern eher ein geduldiger Schreiber für stapelbare Aufgaben. Als Instruct-Modell antwortet es meist geradlinig statt ausufernd, und als Thinking-Optional-Kandidat sollte man im Hinterkopf behalten, dass der Benchmark den erweiterten Denkmodus gerade nicht aktiviert hat. Das erklärt manches an der knappen Reasoning-Tiefe, entschuldigt aber nicht jede Oberflächlichkeit. Sovereign Risk: MEDIUM — die Gewichte stammen von einem US-Anbieter; der CLOUD Act spielt bei lokaler Nutzung der Open-Weights-Variante nicht direkt hinein, wäre bei API- oder Fremdhosting aber relevant.

Kopfnoten: Stabilität und Zuverlässigkeit

Diese Kopfnoten sind die unangenehme Wahrheit, die man nicht unter den Teppich reden sollte. Hermes 4 14B (Q6_K, Abliterated) kann in Einzeltests vernünftig aussehen und dann im Gesamtlauf doch die Nerven verlieren. Für interaktive Nutzung mag man gelegentliche Hänger noch mit einem Retry erschlagen. Für Agenten-Frameworks oder unbeaufsichtigte Batch-Prozesse ist so etwas Gift.

Architektur-Charakter: offen, direkt, aber nicht immer feinmotorisch

Die vorab vergebene Einordnung trifft den Charakter des Modells ziemlich sauber. Als Instruct-Modell priorisiert Hermes 4 14B (Q6_K, Abliterated) sichtbare Befolgung von Anweisungen: Tabellen kommen meist als Tabellen, Ausgaben bleiben meist in der geforderten Sprache, und Antworten driften selten in wolkige Selbstgespräche ab. Das ist ein echter Vorteil im Alltag. Viele Nutzer wollen kein künstliches Nachdenken sehen, sondern ein Ergebnis.

Der Zusatz Thinking-Optional ist hier wichtiger, als er auf den ersten Blick wirkt. Dieser Benchmark misst das Standardverhalten ohne explizit freigeschalteten erweiterten Denkmodus. Entsprechend sieht man ein Modell, das logisch oft auf dem richtigen Pfad ist, aber seine Ableitung nicht immer mit der Sorgfalt ausführt, die man von einem spezialisierten Reasoning-Modell erwarten würde. Hermes denkt nicht schlecht. Es denkt nur selten weiter, wenn der erste brauchbare Entwurf schon steht.

Der dritte Marker, Uncensored-Finetuned, erklärt ebenfalls einiges. Anders als bei ablatierten Gewichtsoperationen bleibt die Basisarchitektur intakt; das Modell bricht also nicht mechanisch auseinander. Dafür sieht man die typische Schwäche dieser Klasse: keine völlige Katastrophe, aber eine gewisse Nuancenarmut in komplexen Aufgaben. Die Antworten sind offen, oft bereitwillig und formal kooperativ. Gerade bei schwierigen Analyse- und Security-Aufgaben fehlt dann jedoch die letzte Schicht an Skepsis, Genauigkeit und Selbstkorrektur. Es ist ein Modell, das lieber antwortet, als zu zögern. Das ist sympathisch. Und manchmal genau das Problem.

Geschwindigkeit: brauchbarer Durchsatz, miserabler Ausreißer-Tail

Auf dem lokalen Referenzsystem Apple Silicon M4, 24GB Unified Memory (Shared RAM/VRAM) erreicht Hermes 4 14B (Q6_K, Abliterated) 25.62 Tokens pro Sekunde. Für ein 14B-Dense-Modell in Q6_K ist das an sich ein vernünftiger Wert. Er passt auch zum Badge „Batch Tool Expert“: kein Echtzeit-Sprinter, aber schnell genug, um längere Antworten ohne quälenden Basistakt zu erzeugen.

Das Problem ist nicht der Durchsatz pro Sekunde. Das Problem ist die Streuung. Ein Modell kann mit 25.62 t/s auf dem Papier ordentlich aussehen und sich in der Praxis trotzdem zäh anfühlen, wenn der Tail der Antwortzeiten entgleist. Genau das passiert hier. Dazu kommt der Speicherrahmen des Testsystems: 24 GB Unified Memory sind für 14B in dieser Quantisierung grundsätzlich machbar, aber eben kein luxuriöser Puffer. Wenn ein lokales Modell dieser Klasse schon fünf Timeouts produziert, dann ist das kein theoretischer Befund, sondern ein Warnschild. Wer lokal produktiv arbeiten will, braucht nicht nur Geschwindigkeit, sondern Berechenbarkeit. Hermes liefert Ersteres einigermaßen. Letzteres nicht zuverlässig genug.

Positiv ist immerhin die Token-Ökonomie. Über alle Module hinweg bleibt das Modell im erwartbaren Rahmen. Kein Bereich läuft textlich aus dem Ruder. Für ein lokales Modell ist das wichtig, weil jedes unnötige Wort hier nicht nur Stilfrage ist, sondern direkt in zusätzliche Wartezeit übersetzt wird. Hermes verhält sich token-ökonomisch. Die Langsamkeit entsteht also nicht aus Geschwätzigkeit, sondern aus Instabilität und Ausreißern.

Code Quality: formal ordentlich, inhaltlich zu oft mit der groben Kelle

Der schwächste Kernbereich ist die Code Quality mit 62.9%. Das ist kein Totalausfall, aber auch kein Befund, den man beschönigen sollte. Hermes 4 14B (Q6_K, Abliterated) kann Sicherheitsprobleme in Code erkennen, Tabellen sauber strukturieren und offensichtliche Schwachstellen benennen. Doch sobald die Aufgabe Präzision statt bloßer Mustererkennung verlangt, fängt das Modell an zu rutschen.

Ein Judge-Protokoll ist dabei besonders aufschlussreich. In einer umfangreichen Sicherheitsanalyse identifizierte das Modell zwar 14 Schwachstellen in einer Markdown-Tabelle und blieb formal vollständig deutsch. Inhaltlich lag es aber deutlich neben der Ideallinie. Kritische Lücken wie Session Fixation, CSRF, hartkodierte Secrets oder fehlende Token-Abläufe blieben unerkannt. Schlimmer noch: Es produzierte mindestens eine gravierende False Positive. Eine Profil-Update-Stelle wurde als SQL Injection markiert, obwohl dort bereits Prepared Statements verwendet wurden. Das ist kein Schönheitsfehler, sondern eine fachliche Fehllesung des Codes. Wenn ein Security-Bericht echte Risiken übersieht und dafür Phantomschmerzen diagnostiziert, wird aus Analyse schnell Beschäftigungstherapie.

Die eigentliche Schwäche ist dabei nicht mangelnde Form, sondern mangelnde Hierarchie. Hermes erkennt oft, dass „hier etwas faul ist“, aber nicht immer, was genau faul ist, wie schwer es wiegt und wie es sich in eine Angriffskette einordnet. Es schreibt saubere Tabellen, aber keine besonders belastbaren Audits. Das passt zur Modellkategorie: Ein uncensored-finetuned Generalist ist nicht auf forensische Schärfe im Secure-Coding getrimmt. Das ist als Einordnung wichtig. Es ist aber kein Freifahrtschein. Wer dieses Modell für Sicherheitsreviews nutzt, sollte jedes Urteil wie einen Erstentwurf behandeln, nicht wie ein Gutachten.

CLI und Tool-Nähe: erstaunlich stark, aber nicht blind vertrauenswürdig

Im CLI-Benchmark erreicht das Modell 85.56%. Das ist eines seiner klar besseren Felder und zeigt, dass Hermes 4 14B (Q6_K, Abliterated) konkrete, operative Instruktionen oft sehr gut umsetzt. Für Shell-nahe Aufgaben ist das eine erfreuliche Nachricht, zumal solche Tests strukturierte Präzision verlangen und wenig Raum für literarische Ausweichbewegungen lassen.

Trotzdem sollte man den Schraubenschlüssel nicht mit einem Multimeter verwechseln. Gute CLI-Leistung bedeutet hier vor allem: Das Modell kann Kommandos und Ablaufstrukturen brauchbar formulieren. Es bedeutet nicht automatisch, dass es in angrenzenden Tool- oder Recherche-Szenarien gleich zuverlässig bleibt. Genau dort tauchen nämlich Halluzinationsprobleme auf, und die sind bei arbeitsnahen Systemen besonders heikel.

Reasoning und Logik: korrekt, aber zu schnell zufrieden

Im Bereich Logical Reasoning landet Hermes bei 64.55%. Das ist die Art Ergebnis, die man in einem Satz zusammenfassen kann: meist richtig, selten brillant. Ein gutes Beispiel liefert das klassische Zwei-Wächter-Rätsel. Dort fand das Modell die korrekte Strategie, erklärte die doppelte Inversion sauber und blieb vollständig deutsch. Der inhaltliche Kern saß. Gleichzeitig blieb die Antwort deutlich flacher als die Referenz: keine systematische Fallunterscheidung, keine alternative Formulierung, keine robustere Verallgemeinerung. Das Modell löst das Rätsel. Es baut aber kein Geländer für den Leser.

Genau hier zeigt sich der Unterschied zwischen „thinking-optional im Standardmodus“ und einem echten Deep-Reasoning-Charakter. Hermes kommt oft ans Ziel, aber nicht mit jener methodischen Beharrlichkeit, die bei komplexeren Problemen den Unterschied zwischen Zufallstreffer und belastbarem Denken ausmacht. Der Judge vermerkte zudem, dass eine Aufgabe ausdrücklich die Exploration unterschiedlicher Lösungswege verlangte. Hermes bot im Wesentlichen nur einen. Das ist kein Denkfehler. Es ist ein Compliance- und Tiefenproblem.

Für Alltagslogik reicht das oft. Für Aufgaben, bei denen man die Ableitung prüfen oder weiterverwenden muss, ist es zu dünn. Hermes argumentiert wie jemand, der die richtige Antwort kennt, aber nicht immer Lust hat, die ganze Tafel vollzuschreiben.

UX Writing: funktional, diszipliniert, aber ohne psychologischen Feinschliff

Im Modul UX Writing & Microcopy erzielt das Modell 61.55%. Das ist einerseits solide genug, um nicht peinlich zu werden, andererseits weit entfernt von dem, was gute Produkttexte heute leisten müssen. Ein Judge-Protokoll bringt es auf den Punkt: korrekt, konservativ, uninspiriert.

In einer Aufgabe zur Überarbeitung jargonlastiger Interface-Texte hielt sich Hermes sauber an die mobilen Wortlimits, lieferte die geforderte Tabellenstruktur und formulierte klar genug. Was fehlte, war die psychologische Feinmechanik. Statt Nutzersorgen aktiv zu entschärfen, Vertrauen aufzubauen oder Handlungsschritte elegant zu rahmen, betrieb das Modell vor allem Jargon-Austausch. Das Ergebnis funktionierte. Es wirkte nur nicht, als hätte jemand über Menschen nachgedacht.

Besonders bezeichnend war ein Strukturfehler in einem mehrstufigen Onboarding-Szenario. Der dritte Schritt hätte eine Auswahlhandlung abbilden müssen. Hermes verwandelte ihn stattdessen in eine Abschlussfeier. Das ist typisch für ein Modell, das Anweisungen grundsätzlich befolgt, aber semantische Rollen in Prozessschritten nicht immer präzise auseinanderhält. Es schreibt „fertig“, wo eigentlich noch „entscheide jetzt“ stehen müsste. UX-Texte verzeihen so etwas nicht. Dort ist falsche Dramaturgie kein Stilproblem, sondern ein Conversion-Problem.

Content Transformation: erstaunlich brauchbar, solange niemand Kino erwartet

Mit 74.43% ist Content Transformation & Adaption ein klarer Lichtblick. Hermes 4 14B (Q6_K, Abliterated) kann längere Umformungsaufgaben tragen, Strukturen sauber aufbauen und in deutscher Sprache durchhalten. In einem ausgearbeiteten Video-Skript zu Zwei-Faktor-Authentifizierung zeigte das Modell sogar echte Stärken: realistische Zeitmarken, glaubwürdiger gesprochener Ton, brauchbare Produktionshinweise und insgesamt ein output, den ein Redakteur nicht wegwerfen müsste.

Die Schwäche lag auch hier nicht in groben Fehlern, sondern in fehlender Tiefe. Die Analysephase blieb eher Checkliste als Diagnose. Retention-Mechaniken wurden nur teilweise umgesetzt. Das Easter Egg war formal vorhanden, aber dramaturgisch so aufregend wie ein Beipackzettel. Kurz gesagt: Hermes schreibt sendefähiges Material, aber noch kein Material, das aus einer guten Idee eine performante Publikation macht.

Gerade deshalb ist dieses Modul interessant. Es zeigt, dass das Modell auf breiteren, kreativen Transformationsaufgaben oft besser aussieht als in analytischen Präzisionsdisziplinen. Das passt zur Herkunft und zum Tuning. Wer Inhalte umarbeiten, adaptieren oder lokalisieren will, bekommt hier mehr Gegenwert als bei Security-Audits.

Documentation Quality: brauchbare Substanz, aber ein dokumentierter Sprachpatzer

Die Documentation Quality liegt bei 65.94%. Das ist in etwa das Niveau, auf dem Hermes als Schreibmodell insgesamt operiert: nicht dumm, nicht elegant, brauchbar mit Aufsicht. Es kann strukturierte Doku erzeugen und auch längere Antworten tragen, verbraucht dabei mit durchschnittlich 3055 Tokens gegenüber einem Fleet-Median von 2497 etwas mehr Text als der Schnitt. Das bleibt im grünen Bereich, ist bei lokaler Nutzung aber ein kleiner Zusatzballast für die Latenz.

Problematischer ist ein harter, regelbasierter Verstoß: In einer Dokumentationsaufgabe antwortete das Modell auf Englisch statt auf Deutsch, obwohl explizit Deutsch verlangt war. Die Sprachmarker lagen bei DE=25, EN=60. Das System wertete dies als language_mismatch; die Aufgabe wurde also nicht regulär erfolgreich abgeschlossen, sondern mit stark reduziertem beziehungsweise nullnahem Effekt in die Bewertung gezogen. Der Punkt ist deshalb wichtig, weil hier nicht über Stil gestritten wird. Das Modell ignorierte eine glasklare Sprachvorgabe. In produktiven Umgebungen mit fixer Zielsprache ist das ein echtes Einsatzrisiko.

Dieser Sprachfehler ist als Einzelfall dokumentiert, nicht als flächendeckendes Muster über das ganze Modul. Dennoch bleibt er ein Warnsignal. Instruction-Following heißt nicht nur, ungefähr zu verstehen, was gemeint war. Es heißt, explizite Rahmenbedingungen zuverlässig einzuhalten. Gerade ein Instruct-Modell sollte sich daran messen lassen.

Cultural Intelligence: ordentliches Gespür, aber nicht die feinste Klinge

Mit 71.0% steht das Modell im Bereich Cultural Intelligence respektabel da. In einer Umschreibung problematischer Stellenanzeigenformulierung entfernte Hermes toxische Sprache, glättete Geschlechterbias und blieb sauber in deutscher Sprache. Der Judge lobte Professionalität und Formtreue. Das ist kein kleines Kompliment, denn solche Aufgaben verlangen sprachliche Sensibilität ohne Moralisieren.

Die Abzüge entstanden vor allem durch Nuance. Statt der präziseren, einladenderen und marktnäheren Formulierungen der Referenz wählte Hermes teils allgemeinere oder etwas härtere Begriffe. Aus „Fachkraft“ wurde „Mitarbeiter“, aus einladender Ansprache wurde stellenweise ein fordernderer Ton. Das ist nicht falsch. Es ist nur weniger elegant und im Bewerberkontext etwas weniger inklusiv. Man könnte sagen: Das Modell kennt den gesellschaftlichen Dresscode, aber nicht immer den besten Stoff.

Halluzinationen und Security-Risiko: der gefährlichste Makel sitzt nicht im Stil, sondern in der Faktentreue

Hermes 4 14B (Q6_K, Abliterated) verdient beim Thema Halluzinationen einen eigenen Abschnitt, weil die Befunde hier nicht kosmetisch sind. In zwei Tool-Use-Aufgaben generierte das Modell Inhalte, die nicht aus dem tatsächlich abgerufenen Tool-Ergebnis stammten, sondern erfunden waren. Das System kappte den P2-Score per Halluzinations-Cap. Für content-kritische Aufgaben wie Recherche oder faktengebundene Berichte ist das kein kleiner Makel, sondern ein disqualifizierendes Verhalten.

Das Problem wird durch den Modellcharakter eher verschärft als gemildert. Ein offenes, bereitwilliges uncensored-finetuned Modell neigt dazu, lieber zu liefern als zu bremsen. Wenn es dann an externer Faktengrundlage hängt, kann aus Hilfsbereitschaft Fiktion werden. Das ist bei Kreativarbeit harmlos. Bei Tool-gestützter Wissensarbeit ist es brandgefährlich.

Security-seitig führt das zu einer zweifachen Warnung. Erstens macht Hermes in Code-Audits fachliche Fehlklassifikationen. Zweitens halluziniert es in toolgebundenen Inhalten. Wer damit Sicherheitsberichte, technische Analysen oder faktenkritische Research-Summaries ohne menschliche Nachkontrolle erzeugt, spielt Schach mit einer Figur zu wenig.

Datenschutz und Datenhoheit

Für dieses lokal genutzte Open-Weights-Modell gibt es keinen verpflichtenden Cloud-Datenschutzblock im engeren Sinn, aber die Herkunft der Gewichte ist relevant. Die Gewichte stammen von Nous Research Inc., San Francisco, USA, Lizenz Apache-2.0, kommerzielle Nutzung ist erlaubt. Das berechnete Sovereign Risk liegt bei MEDIUM: nicht wegen laufender Cloud-Verarbeitung durch den Anbieter, sondern wegen der US-Provenienz der Modellgewichte. Praktisch heißt das für europäische Nutzer: Bei rein lokaler Ausführung entsteht kein automatischer externer Datenabfluss. Sobald man das Modell aber bei einem Drittanbieter hostet oder über eine fremde Inferenzschicht betreibt, verschiebt sich die Datenschutzfrage auf diese Infrastruktur. Eine GDPR DPA seitens Nous Research ist nicht verfügbar, was für die Modellquelle selbst weniger relevant ist als für jeden konkreten Hosting-Partner.

Fazit

Hermes 4 14B (Q6_K, Abliterated) ist ein Modell mit erkennbarem Charakter und klaren Grenzen. Es schreibt willig, strukturiert und oft erstaunlich brauchbar. Für Content-Transformation, allgemeine Schreibarbeit, einfache CLI-nahe Aufgaben und kreative Umformulierungen ist es eine ernstzunehmende lokale Option. Dass es als dichtes 14B-Generalistenmodell in der Desktop-Klasse überhaupt so breit einsetzbar bleibt, verdient Respekt.

Aber man sollte sich von der kooperativen Oberfläche nicht täuschen lassen. In Code Quality, Security-Analyse, Reasoning-Tiefe und faktenkritischer Tool-Nutzung fehlt Hermes die letzte Instanz der Selbstdisziplin. Es verwechselt bisweilen Erkennen mit Verstehen und Antwortbereitschaft mit Zuverlässigkeit. Dazu kommen die fünf Timeouts und eine P95-Antwortzeit von 303.23 Sekunden. Auf dem Testsystem ist dieses Setup damit praktisch nicht robust genug für unbeaufsichtigten Produktiveinsatz.

Die beste Empfehlung lautet deshalb: einsetzen als lokales Schreib- und Transformationsmodell mit offener, wenig restriktiver Antworttendenz. Nicht einsetzen als alleinige Instanz für Security-Reviews, faktenkritische Recherche oder agentische Prozesse, die ohne Aufsicht laufen müssen. Die Weights-Provenienz ist transparent und für lokale Nutzung datenschutzseitig deutlich entspannter als jeder Cloud-Dienst. Die technische Zuverlässigkeit dieses konkreten Setups ist es leider nicht. Hermes ist kein Blender. Aber eben auch kein Modell, dem man die Schlüssel einfach kommentarlos auf den Tisch legt.

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.