4.2 KiB
Verdict pilote mimo-v2.5 sur hermes-nyora — GARDER mimo (2026-07-08)
Contexte
Pilote lancé le 2026-07-05 : mimo-v2.5 (provider opencode-go) en modèle par défaut de hermes-nyora, en comparaison avec DeepSeek V4 Flash (l'ancien défaut de la plateforme). Dispositif de comparaison : cron veille-ia-nexum-compare-deepseek rejouant le MÊME brief de veille Dr. Nexum (mêmes items de /opt/data/veille_raw.json) avec V4 Flash, 15 min après le run mimo, 3x/jour.
Précision de routage : mimo-v2.5 passe en DIRECT par https://opencode.ai/zen/go/v1 (provider built-in opencode-go, clé OPENCODE_GO_API_KEY), et NON par Bifrost. Vérifié dans logs.db de Bifrost : zéro trafic mimo. Les deux modèles sont couverts par le même forfait OpenCode Go → coût marginal nul des deux côtés.
Données (logs agent.log 2026-07-01 → 08, fenêtre pilote 05→08/07)
| Métrique (05–08/07) | mimo-v2.5 | deepseek-v4-flash |
|---|---|---|
| Appels API | 591 | 194 |
| Latence médiane / moyenne | 9,7 s / 14,1 s | 10,5 s / 26,1 s |
| p90 / p99 | 27 s / 73 s | 53 s / 206 s |
| Streams gelés (kill 180 s) | 0 | 19 sur la semaine (8 le 05/07, 6 le 08/07) |
| Échecs d'appel | 1 (APIConnectionError) | 19 (18 ReadError/broken pipe) |
| Jobs cron perdus (3/3 retries) | 0 | 2 |
| Débit médian | 22,3 tok/s | 28,3 tok/s |
Comparaison qualitative sur les 3 runs appariés du cron de comparaison :
- 07/07 20h : les deux briefs complets et bons. V4 Flash même légèrement meilleur en vérification factuelle (a identifié la « Caveman Method », flaggé les claims non vérifiés). Qualité ≈ parité.
- 08/07 07h : V4 Flash CRASH —
RuntimeError: Broken pipeaprès 3 tentatives, aucun brief livré. mimo : brief complet de 24 Ko. - 08/07 12h : V4 Flash a rendu un méta-résumé de 867 caractères au lieu du brief Telegram demandé (hors format). mimo : brief complet conforme.
Verdict : GARDER mimo-v2.5, V4 Flash en fallback uniquement
Le problème de V4 Flash n'est pas la qualité d'analyse (équivalente quand il aboutit) mais la fiabilité du streaming : streams qui gèlent 180 s puis meurent en broken pipe, y compris pendant la semaine du pilote, avec 2 jobs cron réellement perdus. mimo-v2.5 : latence de queue 3x meilleure (p99 73 s vs 206 s), zéro stream gelé, un seul incident (réponses vides le 05/07 21h47, rattrapé par le fallback). Pas de routage par type de tâche : rien dans les données ne le justifie, et ça complexifierait la config pour rien.
Config finale appliquée (2026-07-08)
data/config.yaml:model.default: mimo-v2.5+max_tokens: 8192(modèle reasoning, jamais < 2048) ;delegation.model: mimo-v2.5(était deepseek-v4-flash) ; fallback 1 = opencode-go/deepseek-v4-flash ; fallback 2 = openrouter/deepseek/deepseek-v4-flash.data/profiles/veilleur/config.yaml:default: mimo-v2.5,max_tokens: 8192(était deepseek-v4-flash).data/cron/jobs.json: cronveille-ia-nexum-compare-deepseekdésactivé (test terminé). Le cron principalveille-ia-nexum-4ee61494garde son overridemodel: mimo-v2.5.- Backups :
config.yaml.bak-20260708T-verdict,profiles/veilleur/config.yaml.bak-20260708T-verdict,cron/jobs.json.bak_20260708_verdict_mimo. - Appliqué par
docker restart hermes-agent-nyora(healthy, profils default + veilleur re-registrés).
Ce qui NE marche PAS / pièges
- Ouvrir
logs.dbde Bifrost depuis le Mac via SMB échoue (unable to open database file, WAL) → interroger viassh nas 'sqlite3 -readonly /volume1/docker/bifrost/data/logs.db ...'. - Les erreurs Bifrost deepseek-v4-flash de la semaine sont surtout des 401
virtual_key_not_found(76, client sans VK — autre chantier) + 16 erreurs 500 upstream ; sans lien avec le pilote Hermes. - mimo-v2.5 peut rendre des réponses vides en rafale (1 épisode observé) : le gateway retry 3x puis bascule sur le fallback tout seul — surveiller
Empty responsedansagent.logsi ça devient fréquent.
Surveillance post-verdict
Vérifier dans une semaine : grep -c 'Stream stale' data/logs/agent.log et le taux d'Empty response mimo. Si les réponses vides mimo dépassent ~1/jour, envisager le retour V4 Flash ou un nouveau pilote.