nas-runbooks/common/migration-mimo-v25-cerveau-hermes.md

Migration cerveau Hermes DeepSeek V4 Flash -> Mimo V2.5 (perso, HARNESS/dsh-vps, tt, nyora)

Date : 2026-08-17 Portee : hermes-perso, hermes-HARNESS (dsh-vps, VPS Contabo), hermes-tt, hermes-nyora.

Pourquoi

Changement tarifaire DeepSeek V4 Flash cote OpenCode. Mimo V2.5 deja valide en production sur d'autres usages (extraction documentaire nyora-convert-api, scoring broll_coherence_qc.py, et deja pilote comme cerveau sur hermes-nyora depuis le 15/07 -- voir hermes-nyora/verdict-pilote-mimo-v25.md). Cette migration etend son role au cerveau par defaut des 4 instances Hermes.

Ce qui a ete decouvert en route (motif transverse, meme cause a chaque fois)

Chaque instance a livre une surprise differente de ce que la config versionnee (git) ou la doc annoncait -- meme cause a chaque fois : des valeurs de configuration jamais revalidees contre le comportement reel du provider.

1. Git desynchronise du live (nyora, puis perso, puis tt) -- le fichier data/config.yaml commite ne refletait pas la config reellement chargee par le conteneur (bascules faites en live sans commit). Reconciliation faite instance par instance avant toute nouvelle ecriture.
2. Mecanisme d'auth key_env casse sur le chemin Bifrost provider: custom (tente sur hermes-nyora) -- substituer api_key litteral par key_env a casse l'authentification Bifrost (401 virtual_key_not_found, fallback silencieux vers deepseek-v4-flash). Rollback propre effectue. Root cause probable : construction differente du header (Authorization: Bearer vs x-bf-vk) selon le champ utilise -- non resolu, cf bifrost-access.md (Bifrost exige x-bf-vk, rejette Authorization: Bearer en 401). A reprendre cote code/config Hermes avant nouvelle tentative. Le secret bfk-... reste donc en clair dans le config.yaml live de nyora -- dette assumee, pas corrigee de force.
3. context_length: 128000 / max_tokens: 8192 herites de DeepSeek, jamais recalibres pour mimo-v2.5 -- objet du present runbook (detail ci-dessous).

Pattern de bascule retenu (Pattern A)

Pour perso/tt/nyora : model.default -> provider: opencode-go, api_key/ base_url vides (resolution automatique via OPENCODE_GO_API_KEY), PAS provider: custom/bifrost-proxy (chemin casse, cf point 2 ci-dessus). Seul hermes-HARNESS (dsh-vps) route reellement via Bifrost par construction (provider: bifrost dans settings.yaml, VK vk-dsh-vps) -- c'est le pattern attendu et documente pour cette instance, aucune ambiguite.

Correction context_length / max_tokens (2026-08-17)

Symptome : le couple mimo-v2.5/opencode-go dans la table Bifrost governance_model_pricing est totalement vide (aucune limite renseignee) -- ce n'est donc pas une source fiable pour calibrer le yaml. La valeur 128000/8192 presente sur toutes les instances etait une copie du bloc DeepSeek d'origine, jamais revalidee.

Source de verite retenue : specs constructeur croisees (Xiaomi officiel, OpenRouter, HuggingFace, Requesty) -- convergent sur un contexte tres superieur (262k a 1M tokens selon l'hebergeur) et un plafond de sortie de l'ordre de 131k tokens. Ne pas reprendre les valeurs deepseek-v4-flash (1M / 384k) -- specs d'un autre modele, les copier aurait cree une nouvelle valeur fausse dans l'autre sens (plafond de sortie surdeclare ~3x).

Valeurs appliquees (bloc model:, key_env/api_key non touches) :

context_length: 1048576
max_tokens: 131000        # dsh-vps : contextWindow / maxTokens (meme valeurs)

Resultat par instance (ordre de bascule : perso -> HARNESS -> tt -> nyora) :

Instance	Avant	Apres	Verification
hermes-perso	128000/8192	1048576/131000	model_used=mimo-v2.5 confirme, finish_reason=stop, aucune erreur. Commit bolbol/hermes-perso@0c64f40.
hermes-HARNESS (dsh-vps)	contextWindow 131072/maxTokens 8192	1048576/131000	Logs Bifrost (vk-dsh-vps) : appels post-restart model=mimo-v2.5, status=success, aucune erreur. Pas de repo git pour ce fichier (volume Docker nomme, sauvegarde horodatee .bak-ctxfix-20260817 seule trace). UID/GID VPS = 1001:1001 (PAS la convention NAS 1026:100).
hermes-tt	128000/8192	1048576/131000	Logs internes gateway : API call #1: model=mimo-v2.5 provider=opencode-go ... finish_reason=stop. Piege methodologique : le modele s'est auto-declare a tort deepseek-v4-flash quand on lui demandait son propre nom en JSON -- l'auto-declaration d'un LLM sur son identite n'est PAS une source fiable, toujours verifier par les logs internes/gateway. Commit bolbol/hermes-tt@0015ab5.
hermes-nyora	128000/8192	1048576/131000	Logs Bifrost (Nabil-Key) : model=mimo-v2.5, status=success, stop_reason=stop. Secret en clair (api_key: bfk-...) laisse intact (dette separee, point 2). Commit bolbol/hermes-nyora@4067a85.

Aucun repli necessaire sur aucune instance -- 1048576/131000 accepte partout sans erreur de limite cote opencode-go/Bifrost au premier essai.

Points restes ouverts (proprietaire a designer, pas noyes dans ce runbook)

• Secret Bifrost en clair sur hermes-nyora (api_key: bfk-..., x2 dans le yaml live) + mecanisme d'auth key_env casse sur le chemin Bifrost custom
  • VK dediee BIFROST_VK_HERMES_NYORA provisionnee le 18/07 jamais cablee -- trois symptomes du meme sujet non traite (routage Bifrost/Nabil-Key de nyora jamais finalise proprement). A cadrer en session dediee.
• Few-shot des skills AO/RLA sur hermes-tt (dco-generation-tt, courriers-officiels-tt, gsd-ao-evaluation) -- la regle anti-inference est deja en place et confirmee respectee par mimo-v2.5 en test reel, mais les exemples few-shot restent a peupler avec Nabil (references/exemples- valides/, note deja ecrite dans les skills eux-memes -- explicitement pas a faire par un agent seul).

Voir aussi

hermes-nyora/verdict-pilote-mimo-v25.md, hermes-tt/passation-pj-hermes-tt-deepseek-mimo.md, common/bifrost-access.md, common/bifrost-vk-incidents.md, common/opencode-go-migration.md.