Hermes kennt dein Modell nicht? Kontextfenster und Fähigkeiten per model_overrides festlegen

Das kennst du: Du hängst einen lokalen vLLM-Server an Hermes, und nach ein paar Runden meldet der Agent „context full“ – obwohl dein Modell 8K oder 128K Tokens problemlos verarbeitet. Oder du wechselst auf ein frisch veröffentlichtes Modell, das offensichtlich Vision kann, und Hermes besteht darauf: „Dieses Modell unterstützt keine Bilder.“ Meist liegt das Problem nicht am Modell – sondern daran, dass Hermes’ Bild vom Modell aus einem Modellkatalog stammt, und dein Modell dort nicht auftaucht oder der Eintrag veraltet ist. Die gute Nachricht: Seit v0.20.1 kannst du all das direkt in config.yaml über model_overrides korrigieren und Hermes genau sagen, was dein Modell kann.

Warum das passiert: blinde Flecken im Modellkatalog

Hermes entscheidet, was ein Modell kann – wie lang sein Kontextfenster ist, ob es Tools, Vision oder Reasoning unterstützt – hauptsächlich anhand von models.dev, einem öffentlichen Modellkatalog, plus einiger eingebauter Fallback-Regeln. Das deckt gängige Cloud-Modelle gut ab, hat aber immer Lücken:

  • Lokale Modelle: dein vLLM-, Ollama- oder llama.cpp-Server nutzt selbst erfundene Modell-IDs; sie stehen nicht im Katalog;
  • Brandneue Modelle: gerade von einem Anbieter veröffentlicht, noch nicht katalogisiert;
  • Veraltete Einträge: das Kontextfenster ist zu klein eingetragen, die Fähigkeiten stimmen nicht, oder der Anbieter hat ein Update ausgeliefert, das der Katalog noch nicht nachvollzogen hat.

In solchen Fällen greift Hermes auf „sichere Standardwerte“ zurück: unbekannte Modelle bekommen eine 200K-Kontextschätzung, Tool-Calling ist aktiv, Vision und Reasoning dagegen aus. Ist die Annahme falsch, bekommst du genau das seltsame Verhalten aus der Einleitung – vorhandene Fähigkeiten gelten als fehlend, und Kontextfenster, das du bezahlt hast, bleibt ungenutzt.

Die Lösung: model_overrides in config.yaml

model_overrides ist ein neuer Top-Level-Konfigurationsabschnitt, der mit v0.20.1 erschienen ist (PR #85560). Seine Aufgabe ist simpel: Für ein bestimmtes Modell unter einem bestimmten Provider legst du die Metadaten von Hand fest, und sie überschreiben den Katalog. So geht’s:

model_overrides:
  custom:my-local-vllm:        # provider name, then the model ID
    my-llava-model:
      context_window: 8192     # this model's real context is 8K
      supports_vision: true    # it does accept images
    my-llama-model:
      context_window: 32768
      supports_tools: false    # tool calls are flaky here — turn them off
  upstage:                     # you can also fix cloud models
    solar-pro4:
      context_window: 524288   # not in the catalog; actually 512K

Starte Hermes nach dem Speichern neu (bearbeiten mit hermes config edit, dann die Session neu starten), und die Overrides greifen. Trage nur die Felder ein, die der Katalog falsch oder gar nicht kennt – alles, was du weglässt, behält den Katalogwert, sodass du andere Einstellungen nicht versehentlich kaputt machst.

Die drei Felder, die du am häufigsten brauchst

Alle brauchst du selten. Im Alltag ist es meist eines von diesen:

  • context_window: die Kontextlänge des Modells in Tokens. Zu niedrig angesetzt, werden Gespräche vorzeitig abgeschnitten; zu hoch angesetzt, arbeitet das Modell mit überdimensioniertem Kontext – such die echte Zahl nach, wo du kannst.
  • supports_vision: ob das Modell Bildeingaben akzeptiert. Das ist die häufigste Falle bei lokalen Vision-Modellen (LLaVA-Stil): Ohne die Angabe bietet Hermes dir nie an, Bilder zu senden.
  • supports_tools: ob das Modell Tool-Calling kann. Ist ein Modell bei der Tool-Nutzung unzuverlässig, schaltest du es hier besser explizit aus, statt zuzusehen, wie es immer wieder scheitert.

Die vollständige Feldliste

model_overrides unterstützt alle diese Felder mit derselben Bedeutung wie die Modell-Metadaten:

Feld Bedeutung
context_window Kontextlänge in Tokens
max_output_tokens Maximale Ausgabe-Tokens pro Antwort
supports_tools Tool-Calling-Unterstützung (Standard: true bei unbekannten Modellen)
supports_vision Bild-Eingabe-Unterstützung (Standard: false)
supports_reasoning Reasoning-Modus-Unterstützung (Standard: false)
model_family Modellfamilien-Kennung für das Fallback-Matching

_default: ein Sicherheitsnetz für nicht katalogisierte Modelle

Jedes Modell von Hand zu pflegen ist mühsam. Du kannst ein _default pro Provider – oder global – als Fallback für Modelle setzen, die der Katalog nicht kennt:

model_overrides:
  custom:my-vllm:
    _default:                  # applies only to uncataloged models
      context_window: 32768
  _default:                    # global fallback, gap-filling only
    context_window: 128000

_default ist von Design her lückenfüllend: Er gilt nur für Modelle, die der Katalog nicht kennt und verdrängt nie Katalogdaten bekannter Modelle. Ein globaler Standardwert kann also nicht versehentlich jedes Modell eines Providers beschneiden – bekannte Modelle behalten ihre Katalogwerte.

Zwei Szenarien aus der Praxis

Szenario eins: ein lokales Vision-Modell. Du stellst ein Modell mit eigener ID über vLLM bereit, und es akzeptiert Bilder. Ohne Konfiguration geht Hermes davon aus, dass es keinerlei Vision hat:

model_overrides:
  custom:my-vllm:
    my-llava-model:
      context_window: 8192
      supports_vision: true

Szenario zwei: ein brandneues Cloud-Modell. Upstages solar-pro4 stand zum Launch nicht im Katalog, also behandelte ihn die Fallback-Regel als 256K-Kontext, obwohl er wirklich 512K hat. Deklariere ihn, und du kannst das volle Fenster nutzen:

model_overrides:
  upstage:
    solar-pro4:
      context_window: 524288

Wissenswertes

  • Providernamen akzeptieren beide Schreibweisen: die Hermes-Provider-ID (z. B. custom:my-vllm) oder die models.dev-ID (z. B. github-copilot) – beide werden erkannt.
  • Modell-IDs werden case-insensitiv abgeglichen, analog zur Katalogsuche.
  • Falsche Werte warnen, crashen nie: ein fehlerhafter Wert (etwa context_window: "512k") wird nur mit einer Warnung geloggt, die gültigen Geschwisterwerte greifen trotzdem.
  • Vorrang: explizite Einträge gewinnen gegen die Standardwerte von models.dev, OpenRouter und den eingebauten Regeln; ein pro Modell gesetztes context_length unter custom_providers steht über allem und wird nie überschrieben.
  • Das passt perfekt zu custom_providers (eigene API-Endpunkte) – lokale Server, Proxy-Gateways und Inhouse-Modelle laufen alle auf derselben Kombination.

Fazit

Falsche Modell-Metadaten sind eine der heimtückischsten Fallen für Nutzer lokaler und neuer Modelle: Die Fähigkeit ist da, Hermes weiß nur nichts davon. Genau dafür gibt es model_overrides – keine Codeänderungen, kein Warten auf eine Katalogaktualisierung; ein paar Zeilen in config.yaml deklarieren, und Hermes kennt dein Modell endlich. Falls du dich mit der Einrichtung eigener Modelle noch nicht beschäftigt hast: Die Installationsanleitung zeigt, wie du Provider konfigurierst, und per pip installierte Modell-Provider sind ein ergänzender Weg, Hermes neue Modelle vorzustellen.