Vous connaissez la situation : vous branchez un serveur vLLM local dans Hermes et, après quelques échanges, il annonce « contexte plein » — alors que votre modèle gère 8K ou 128K jetons sans problème. Ou bien vous passez à un modèle tout juste sorti qui gère manifestement la vision, et Hermes insiste : « ce modèle ne prend pas en charge les images. » Le problème ne vient généralement pas du modèle — c’est que l’image qu’Hermes se fait du modèle provient d’un catalogue de modèles, et que votre modèle n’y figure pas, ou que sa fiche est obsolète. Bonne nouvelle : depuis la v0.20.1, vous pouvez corriger tout cela directement dans config.yaml avec model_overrides, et dire à Hermes exactement ce qu’est votre modèle.

Pourquoi cela arrive : les angles morts du catalogue de modèles

Hermes décide de ce qu’un modèle sait faire — la longueur de sa fenêtre de contexte, sa prise en charge des outils, de la vision ou du raisonnement — principalement à partir de models.dev, un catalogue public de modèles, complété par quelques règles de repli intégrées. Cela couvre bien les modèles cloud courants, mais il y a toujours des angles morts :

• Modèles locaux : votre serveur vLLM, Ollama ou llama.cpp utilise des identifiants de modèles que vous avez inventés ; ils ne figurent pas au catalogue ;
• Modèles tout juste sortis : publiés par un fournisseur, pas encore répertoriés ;
• Fiches obsolètes : la fenêtre de contexte est indiquée trop petite, les capacités sont erronées, ou le fournisseur a livré une mise à jour que le catalogue n’a pas encore intégrée.

Dans ces cas, Hermes retombe sur des « valeurs sûres par défaut » : les modèles inconnus reçoivent une estimation de contexte de 200K, la prise en charge des outils est activée, mais la vision et le raisonnement sont désactivés. Quand l’hypothèse est fausse, vous obtenez exactement le comportement étrange décrit en introduction — des capacités bien réelles sont traitées comme absentes, et du contexte que vous avez payé part en pure perte.

La solution : model_overrides dans config.yaml

model_overrides est une nouvelle section de configuration de premier niveau, livrée avec la v0.20.1 (PR #85560). Son rôle est simple : pour un modèle précis, chez un fournisseur précis, vous déclarez les métadonnées à la main et elles remplacent celles du catalogue. Exemple :

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

Redémarrez Hermes après avoir enregistré (modifiez avec hermes config edit, puis relancez la session) et les surcharges prennent effet. N’écrivez que les champs que le catalogue renseigne mal ou pas du tout — tout ce que vous laissez de côté conserve la valeur du catalogue, vous ne pouvez donc pas casser d’autres réglages par accident.

Les trois champs que vous utiliserez le plus

Vous aurez rarement besoin de tous. Au quotidien, c’est généralement l’un de ceux-ci :

• context_window : la longueur de contexte du modèle, en jetons. Trop bas, les conversations sont coupées trop tôt ; trop haut, le modèle s’égare sur un contexte surdimensionné — cherchez la valeur réelle dès que possible.
• supports_vision : indique si le modèle accepte les images en entrée. C’est le piège le plus courant avec les modèles de vision locaux (type LLaVA) : sans cette déclaration, Hermes ne vous propose jamais d’envoyer des images.
• supports_tools : indique si le modèle sait utiliser les outils. Si un modèle est peu fiable avec les outils, mieux vaut le désactiver explicitement ici que de le regarder échouer en boucle.

La liste complète des champs

model_overrides prend en charge tous ces champs, avec la même signification que les métadonnées de modèle :

Champ	Signification
context_window	Longueur de contexte en jetons
max_output_tokens	Nombre maximal de jetons de sortie par réponse
supports_tools	Prise en charge des outils (vrai par défaut pour les modèles inconnus)
supports_vision	Prise en charge des images en entrée (faux par défaut)
supports_reasoning	Prise en charge du mode raisonnement (faux par défaut)
model_family	Identifiant de famille de modèles utilisé par la logique de repli

_default : un filet de sécurité pour les modèles absents du catalogue

Écrire chaque modèle à la main est fastidieux. Vous pouvez définir un _default par fournisseur — ou globalement — comme repli pour les modèles que le catalogue ne connaît pas :

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

_default ne comble que les manques, par conception : il ne s’applique qu’aux modèles que le catalogue ne connaît pas et ne remplace jamais les données du catalogue pour les modèles connus. Un défaut global ne peut donc pas plafonner par accident tous les modèles d’un fournisseur — les modèles connus conservent leurs valeurs de catalogue.

Deux scénarios concrets

Premier scénario : un modèle de vision local. Vous servez un modèle à identifiant personnalisé via vLLM et il accepte bien les images. Sans configuration, Hermes part du principe qu’il n’a aucune capacité de vision :

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

Deuxième scénario : un modèle cloud tout juste sorti. Le solar-pro4 d’Upstage ne figurait pas au catalogue à sa sortie, la règle de repli lui attribuait donc 256K de contexte alors qu’il en a réellement 512K. Déclarez-le et vous pouvez utiliser toute la fenêtre :

model_overrides:
  upstage:
    solar-pro4:
      context_window: 524288

À savoir

• Les noms de fournisseurs acceptent les deux orthographes : l’identifiant Hermes du fournisseur (ex. custom:my-vllm) ou l’identifiant models.dev (ex. github-copilot) — les deux sont reconnus.
• Les identifiants de modèles sont comparés sans tenir compte de la casse, comme pour la recherche dans le catalogue.
• Une valeur invalide émet un avertissement, jamais une erreur fatale : une valeur mal formée (par exemple context_window: "512k") journalise un avertissement, et les valeurs voisines valides sont tout de même appliquées.
• Priorité : les entrées explicites priment sur les valeurs par défaut de models.dev / OpenRouter / intégrées ; une context_length par modèle définie sous custom_providers passe devant tout, elle n’est donc jamais écrasée.
• Cela s’associe parfaitement avec custom_providers (points de terminaison API personnalisés) — serveurs locaux, passerelles proxy et modèles maison tournent tous sur la même combinaison.

Pour conclure

Des métadonnées de modèle erronées sont l’un des pièges les plus sournois pour les utilisateurs de modèles locaux et de modèles récents : la capacité existe, Hermes ne le sait simplement pas. model_overrides existe précisément pour cela — aucun changement de code, aucune attente d’une actualisation du catalogue ; déclarez quelques lignes dans config.yaml et Hermes connaîtra enfin votre modèle. Si vous n’avez pas encore exploré la configuration de modèles personnalisés, le guide d’installation explique comment configurer les fournisseurs, et les fournisseurs de modèles installés via pip montrent une approche complémentaire pour présenter de nouveaux modèles à Hermes.