Vision auxiliaire mal routee sur modeles text-only (auto -> echec silencieux)

Instance auteur : Claude (diagnostic multi-instance, hermes-perso + hermes-tt) Date : 2026-07-27 Tags : [infra, vision, bifrost, config, transverse] Statut : valide

Probleme

vision_analyze echouait systematiquement sur hermes-perso (contexte : extraction guide d'orientation universitaire, screenshots de verification) avec une erreur 400 - Upstream request failed (parfois 404 selon le provider), empechant toute verification visuelle avant livraison -- alors que cette verification est une regle etablie (post-incident IAKifech Ep2 : jamais de validation sur metriques seules).

Contexte et contraintes

Config auxiliary.vision.provider: auto dans config.yaml de chaque instance Hermes. auto resout vers le modele principal configure pour l'instance (model.default). Sur hermes-perso et hermes-tt, ce modele principal est deepseek-v4-flash -- un modele text-only (confirme OpenRouter : Text-only, no vision/image input). Toute image envoyee a ce provider echoue par construction, pas par bug transitoire.

hermes-nyora et hermes-nabil tournent sur mimo-v2.5, natif omnimodal -- auto fonctionne correctement pour ces deux-la, ce qui a masque le probleme puisqu'il ne touchait que 2 instances sur 4.

Ce qui NE fonctionne PAS

Tentative	Erreur obtenue	Raison de l'echec
Laisser `auto` par defaut	`400 Upstream request failed` / `404` sur toute image	`auto` pointe vers le modele principal, ici text-only
Ne rien configurer et esperer un fallback automatique	Meme erreur, aucun fallback vision dans la structure `auxiliary.vision` (pas de liste, contrairement a `fallback_providers` du modele principal)	La structure de config n'a qu'un seul provider/model pour vision, pas de chaine de fallback

Solution validee

Router explicitement auxiliary.vision vers un modele multimodal via Bifrost, avec les memes identifiants que le modele principal (meme base_url/api_key, provider custom) :

auxiliary:
  vision:
    provider: custom
    model: google/gemini-2.5-flash
    base_url: http://bifrost-proxy/v1
    api_key: bfk-0cd1fba7d440ca2eefd30b28a7349b7d28422dcbc49e982d
    timeout: 120
    download_timeout: 30

Applique sur hermes-perso et hermes-tt (fichiers config.yaml, backup .bak-20260727 conserve a cote). Containers redemarres (docker restart) pour charger la nouvelle config -- config.yaml n'est lu qu'au demarrage, jamais a chaud (meme piege que jobs.json, cf. regle cron dans PROTOCOL-INFRA.md).

hermes-nyora et hermes-nabil laisses en auto : leur modele principal gere nativement la vision, pas de changement necessaire pour l'instant.

Verification

Prochaine tache impliquant une image sur hermes-perso ou hermes-tt : confirmer dans les logs (/opt/data/logs/errors.log ou agent.log) que l'appel vision affiche provider=custom et model=google/gemini-2.5-flash dans routing_info, plus aucune trace de deepseek-v4-flash sur un appel vision.

Pieges specifiques

config.yaml n'est pas recharge a chaud -- toujours redemarrer le container apres modification, quel que soit le champ touche.
Verifier ce meme champ sur toute future instance Hermes creee avec un modele principal text-only -- le defaut auto est un piege qui ne se revele qu'a l'usage (premier envoi d'image).
Le Gemini utilise ici (google/gemini-2.5-flash) est deja configure comme provider dans bifrost-proxy/models.json -- pas de nouvelle cle a creer.

References

Incident declencheur : diagnostic hermes-perso, tache orientation universitaire Yesmine (27/07/2026)
common/bifrost-vk-incidents.md, common/hermes-vers-bifrost-bifrost-proxy.md

3.7 KiB Raw Blame History