Hermes 3: lokale KI-Agenten mit Function-Calling

Was Hermes 3 ist

Hermes 3 ist eine Modellfamilie von Nous Research, einem auf offene Modelle spezialisierten Forschungslabor. Technisch ist Hermes 3 ein Finetune von Metas Llama 3.1, verfuegbar in den Groessen 8B, 70B und 405B Parameter. Die Gewichte sind offen zugaenglich (Lizenz folgt der zugrunde liegenden Llama-3-Lizenz), du kannst das Modell also komplett auf eigener Hardware betreiben, ohne dass eine Anfrage eine Cloud-API erreicht.

Der Unterschied zu einem generischen Llama-3.1-Finetune liegt im Trainingsschwerpunkt: Nous Research hat Hermes 3 gezielt auf Function-Calling/Tool-Use, strukturierte JSON-Ausgaben und mehrstufiges Reasoning trainiert, dazu auf praezises Befolgen von System-Prompts und lange Multi-Turn-Konversationen. Nous Research selbst positioniert Hermes 3 als generalistisches Modell mit “advanced agentic capabilities”, das bei allgemeinen Faehigkeiten mit den offiziellen Llama-3.1-Instruct-Modellen mithalten oder sie in Teilbereichen uebertreffen soll (Stand: 2026-07).

Das Tool-Format: tools, tool_call, tool_response

Hermes nutzt ein eigenes, aus der Hermes-2-Reihe uebernommenes Format fuer Tool-Definitionen und -Aufrufe, aufbauend auf dem ChatML-Nachrichtenformat. Die Grundidee:

1. Im System-Prompt stehen die verfuegbaren Werkzeuge als JSON-Schemas, eingerahmt von einem tools-Block (spitze Klammern werden hier aus MDX-Gruenden als Wort geschrieben).
2. Entscheidet das Modell, dass ein Werkzeug gebraucht wird, antwortet es nicht mit Fliesstext, sondern mit einem strukturierten Aufruf, eingerahmt von einem tool_call-Block, der Name und Argumente als JSON enthaelt.
3. Dein eigener Code parst diesen Block, fuehrt die eigentliche Aktion aus und schickt das Ergebnis als neue Nachricht mit der Rolle tool zurueck, eingerahmt von einem tool_response-Block.
4. Das Modell verarbeitet die Antwort und formuliert daraus eine natuerlichsprachliche Antwort oder ruft ein weiteres Werkzeug auf.

Ein typischer Tool-Aufruf sieht so aus:

{"name": "get_stock_fundamentals", "arguments": {"symbol": "TSLA"}}

Wichtig dabei: Das Modell entscheidet selbstaendig, ob ein Tool ueberhaupt gebraucht wird. Bei einer reinen Wissensfrage antwortet Hermes 3 direkt in Fliesstext, ohne einen Tool-Aufruf zu erzwingen. Ab Hermes 2 Pro sind die Tags als jeweils einzelne Tokens im Vokabular hinterlegt, was das Parsen waehrend des Streamings vereinfacht und beschleunigt.

Referenz-Code fuer dieses Format inklusive Beispiel-Tools (Aktienkurse, Firmenkennzahlen) stellt Nous Research im Repository Hermes-Function-Calling bereit (MIT-Lizenz, rund 1.4k Sterne, Stand: 2026-07).

Use Case: datensouveraene Agenten im KMU

Der naheliegendste Einsatzzweck fuer Hermes 3 ist ein Agent, der mit internen, sensiblen Werkzeugen arbeitet, ohne dass Anfragen ein Cloud-Rechenzentrum verlassen. Ein paar konkrete Beispiele aus dem KMU-Alltag:

• Ein Support-Agent, der auf interne Ticket-, Kunden- und Inventarsysteme zugreift und dabei Personendaten nie an einen externen Anbieter schickt.
• Ein IT-Automatisierungs-Agent, der Systemzustaende abfragt (Serverauslastung, freier Speicherplatz, Backup-Status) und bei Bedarf definierte Wartungsskripte anstoesst.
• Ein Dokumentations-Agent, der in einer lokalen Wissensdatenbank sucht (siehe RAG mit Firmenwissen) und Antworten ausschliesslich aus verifizierten internen Quellen zusammenstellt.

Der gemeinsame Nenner: Branchen mit strengen Datenschutz- oder Geheimhaltungsanforderungen, oder schlicht der Wunsch, keine laufenden Tokenkosten fuer ein hohes Anfragevolumen zu zahlen. Der Preis dafuer ist, dass du selbst fuer Hardware, Betrieb und Absicherung verantwortlich bist - mehr dazu weiter unten bei den Grenzen.

Setup: Hermes 3 lokal starten

Variante 1: Ollama (schnellster Einstieg)

Ollama fuehrt Hermes 3 als vorquantisiertes GGUF-Modell aus seiner Modellbibliothek aus. Ein einziger Befehl laedt und startet das 8B-Modell:

ollama run hermes3

Andere Groessen holst du per Tag-Suffix:

ollama run hermes3:70b
ollama run hermes3:405b

Sobald Ollama laeuft, steht automatisch eine lokale, OpenAI-kompatible API unter http://localhost:11434/v1 bereit. Damit funktioniert Tool-Use grundsaetzlich auch ueber Ollamas eigenes tools-Parameter im Chat-Endpunkt, sofern dein Client-Code Funktionsdefinitionen im OpenAI-Format mitschickt - Ollama uebersetzt sie intern in das modellspezifische Format. Mehr zu Ollama und llama.cpp allgemein findest du unter lokale Modelle betreiben.

Variante 2: vLLM (fuer produktionsnahen Betrieb)

vLLM ist eine auf Durchsatz optimierte Inferenz-Engine, die sich fuer den Betrieb mehrerer gleichzeitiger Anfragen eignet, etwa wenn mehrere Nutzer oder mehrere Agenten-Instanzen parallel auf dasselbe Modell zugreifen. vLLM bringt einen dedizierten Parser fuer das Hermes-Tool-Format mit:

vllm serve NousResearch/Hermes-3-Llama-3.1-8B \
  --enable-auto-tool-choice \
  --tool-call-parser hermes

--enable-auto-tool-choice schaltet ueberhaupt erst frei, dass das Modell selbststaendig entscheidet, ob und welches Tool es aufruft. --tool-call-parser hermes sagt vLLM, dass es die tool_call-Bloecke im Hermes-spezifischen Format erwarten und in das OpenAI-kompatible tool_calls-Antwortformat uebersetzen soll. Laut vLLM-Dokumentation funktioniert der hermes-Parser mit allen Hermes-Modellen ab Hermes 2 Pro. Optional laesst sich zusaetzlich ein passendes Chat-Template mitgeben, falls das Standardtemplate im Tokenizer nicht ausreicht:

vllm serve NousResearch/Hermes-3-Llama-3.1-8B \
  --enable-auto-tool-choice \
  --tool-call-parser hermes \
  --chat-template ./tool_chat_template_hermes.jinja

Danach spricht du vLLM ueber dieselbe OpenAI-kompatible /v1/chat/completions-Schnittstelle an wie einen Cloud-Anbieter, inklusive des tools-Parameters fuer Funktionsdefinitionen - ein grosser Vorteil, wenn du bestehenden Agenten-Code (etwa mit einem OpenAI-SDK) nur auf eine neue Basis-URL umbiegen willst.

Eigene Tools definieren

Unabhaengig vom Server definierst du eigene Werkzeuge als JSON-Schema, genau wie bei Cloud-Function-Calling (siehe KI-Agents und Tool-Use). Ein Beispiel fuer ein Werkzeug, das Ticket-Status abfragt:

{
  "type": "function",
  "function": {
    "name": "ticket_status_abfragen",
    "description": "Fragt den aktuellen Status eines Support-Tickets anhand der Ticket-ID ab.",
    "parameters": {
      "type": "object",
      "properties": {
        "ticket_id": {
          "type": "string",
          "description": "Die eindeutige ID des Tickets, z. B. 'TCK-2451'."
        }
      },
      "required": ["ticket_id"]
    }
  }
}

Dieses Schema schickst du zusammen mit der Konversation an die API. Antwortet das Modell mit einem entsprechenden Tool-Aufruf, fuehrt dein eigener Code die eigentliche Abfrage aus (Datenbank, internes API, Dateisystem) und schickt das Ergebnis als Tool-Antwort zurueck. Fuer mehrstufige Aufgaben wiederholt sich dieser Zyklus, bis das Modell entscheidet, dass es genug Information fuer eine finale Antwort hat.

Hardware-Bedarf je Modellgroesse

Der Speicherbedarf folgt denselben Grundregeln wie bei anderen lokalen LLMs (siehe lokale Modelle betreiben fuer Details zu Quantisierung):

Fuer die meisten KMU-Szenarien ist das 8B-Modell der realistische Startpunkt: Es laeuft auf gaengiger Consumer- oder kleiner Workstation-Hardware und liefert fuer klar abgegrenzte Tool-Use-Aufgaben brauchbare Ergebnisse. Das 70B-Modell lohnt sich, wenn komplexeres Reasoning oder laengere Werkzeug-Ketten gefragt sind und die Hardware dafuer vorhanden ist. 405B ist praktisch nur mit Server-Infrastruktur sinnvoll und fuer die allermeisten kleinen Betriebe nicht der richtige Weg.

Grenzen gegenueber grossen Cloud-Modellen

Ein lokal betriebenes Hermes-3-Modell ersetzt kein aktuelles Spitzenmodell eines grossen Cloud-Anbieters, sondern deckt eine andere Nische ab:

• Rohleistung bei komplexem Reasoning: Bei sehr verschachtelten, mehrstufigen Aufgaben mit vielen Werkzeug-Ketten bleiben die groessten proprietaeren Cloud-Modelle (Stand: 2026-07) in der Regel voraus.
• Zuverlaessigkeit bei exotischen Schemas: Ungewoehnlich komplexe oder tief verschachtelte JSON-Schemas werden von kleineren, lokal laufenden Varianten (8B) tendenziell weniger zuverlaessig eingehalten als von grossen Cloud-Modellen.
• Aktualitaet: Ein lokal gehostetes Modell hat keinen eingebauten Internetzugriff und kein automatisches Wissens-Update. Aktuelles Wissen muss ueber eigene Tools (Suche, interne Datenbank) nachgereicht werden.
• Betriebsaufwand: Updates, Absicherung und Skalierung liegen komplett bei dir, statt bei einem Anbieter.
• Dafuer: volle Datenhoheit, keine laufenden Tokenkosten pro Anfrage, und keine Abhaengigkeit von externen API-Verfuegbarkeiten (siehe auch lokale LLMs und Datenhoheit).

Fuer klar abgegrenzte, wiederkehrende Agenten-Aufgaben mit bekanntem Werkzeug-Umfang - etwa interne Ticket- oder Monitoring-Automatisierung - ist ein lokal betriebenes Hermes-3-Modell heute eine ernstzunehmende, produktionstaugliche Option. Fuer offene, komplexe Aufgaben mit unvorhersehbaren Anforderungen bleibt ein aktuelles Cloud-Modell meist die robustere Wahl.

Weiterlernen

• Hermes 3 - Nous Research - Offizielle Produktseite mit Uebersicht und Ressourcen
• Hermes-3-Llama-3.1-8B auf Hugging Face - Modellkarte mit Prompt-Format und Beispielcode
• Hermes-Function-Calling auf GitHub - Referenzimplementierung fuer das Tool-Format
• Hermes 3 Technical Report (arXiv) - Technisches Paper zu Training und Evaluation
• vLLM Tool-Calling-Dokumentation - Offizielle Doku zu --tool-call-parser und Tool-Use-Setup
• Ollama Modellbibliothek: hermes3 - Verfuegbare Groessen und Tags fuer Ollama