bolbol
/
nas-runbooks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
nas-runbooks/common/bifrost-vk-stale-cache-et-f...

5.5 KiB
Raw Blame History

Bifrost : VK stale-cache + migration fallback OpenRouter -> OpenCode Go

Instance auteur : Claude (via mcp-nas) Date : 2026-07-06 Tags : infra, bifrost, hermes, opencode, openrouter, cout Statut : valide

Probleme observe

  1. Pipeline nyora-veille (n8n workflow "VEILLE | Ingest Opportunites", node "Enrichir via Bifrost") en echec repete (401 virtual_key_not_found) le 06/07 a 07:34 et 13:29-13:30 UTC, alors que le x-bf-vk hardcode dans le node correspond exactement a la valeur Nabil-Key en base (bfk-e5832bfebd22e9d8252a426d0734ed5f2d923204c8033d6d). Aucun cout facture (echec avant tout routage provider).
  2. hermes-nyora (mimo-v2.5, pilote 01-08/07) a bascule 2x le 05/07 (~21:38 et 21:48 UTC) sur son fallback natif fallback_providers: openrouter (bypass Bifrost, cle OPENROUTER_API_KEY en .env) suite a des reponses vides du pilote sur OpenCode. Cout reel facture sur OpenRouter, hors quota epuise.
  3. Bifrost logs.db (depuis 06/06) : 1370 appels reussis, 17,43$, VK non identifiee, modele deepseek/deepseek-v4-flash sur OpenRouter -> trace de sessions Claude Cowork/Claude Code routees via Bifrost et interceptees par une regle de routing.

Cause racine

  • Point 1 : cache Bifrost desynchronise (VK valide en base mais rejetee en memoire) -> un simple restart du container bifrost recharge correctement le VK store. Meme famille de piege que celui deja connu pour les cles provider (config.json au boot) : Bifrost ne recharge pas systematiquement son etat interne sans redemarrage explicite.
  • Point 2 : fallback_providers des 3 instances Hermes pointait vers openrouter (paye a l'usage) au lieu de opencode-go (deja couvert par le forfait Go). Design d'origine (voir migration-provider-opencode-go.md, 14/06) : a l'epoque volontaire comme filet de secours large, mais genere une facturation reelle des qu'un modele opencode echoue (meme hors quota).
  • Point 3 : regle de routing Bifrost Haiku -> Gemini 2.5 Flash (id f5f03c54-049a-4f53-8590-7392730f42e0) avait un NOM ne correspondant pas a sa cible reelle en base (deepseek/deepseek-v4-flash payant sur openrouter au lieu de gemini-2.5-flash gratuit sur Google AI Studio). Les 4 autres regles Opus/Sonnet/Catch-all pointent, elles, vers des modeles :free OpenRouter et sont correctes.

Solution appliquee (06/07/2026)

  1. routing_targets (config.db Bifrost) : rule f5f03c54... -> provider=google, model=gemini-2.5-flash (etait openrouter/deepseek-v4-flash). Backup pris avant edit (config.db.bak-). Restart container bifrost pour charger.
  2. Les 3 data/config.yaml Hermes (hermes-tt, hermes-nyora, hermes-perso) : fallback_providers: openrouter/deepseek-v4-flash -> opencode-go/deepseek-v4-flash, key_env: OPENCODE_GO_API_KEY (nom reel de la var injectee par le compose top-level, pas OPENCODE_API_KEY comme indique dans l'ancien runbook de migration). Backup des 3 fichiers pris avant edit. Restart des 3 containers hermes-agent-* (perso a eu besoin d'un start manuel apres le restart, le call restart API ayant timeout cote client -> verifier l'etat plutot que de re-tenter en boucle).
  3. Aucun changement necessaire sur le node n8n "Enrichir via Bifrost" : le restart bifrost a suffi a corriger le probleme de VK stale.

Verification

curl -s --unix-socket /var/run/docker.sock http://localhost/containers/<c>/json | jq .State
# bifrost, hermes-agent-tt/nyora/perso : running + healthy apres restart

curl -X POST http://bifrost:8080/v1/chat/completions -H 'x-bf-vk: <Nabil-Key>' \
  -d '{"model":"deepseek-v4-flash","max_tokens":30,"messages":[{"role":"user","content":"dis OK"}]}'
# HTTP 200, routing_info.provider=opencode -> confirme

A surveiller

  • Si un 401 virtual_key_not_found reapparait sans changement de config -> suspecter a nouveau le cache VK, restart bifrost avant toute autre investigation.
  • Fiabilite mimo-v2.5 (reponses vides) non resolue en soi ; le fallback pointant desormais vers opencode-go, tout echec futur du pilote restera gratuit (dans le forfait) au lieu d'etre facture.
  • Auditer les 4 autres regles Opus/Sonnet/Catch-all : noms vs cibles reelles a revalider periodiquement (meme type de desync que la regle Haiku).

References

  • migration-provider-opencode-go.md (14/06/2026)
  • llm-audit-register.md (24/06/2026), item "N8n Ingest Opportunites"

Addendum 06/07/2026 — pilote mimo-v2.5 sur hermes-nyora

Migration mimo-v2.5 confirmee active depuis le 05/07 20h01 (decision : tester un modele de raisonnement sur Nyora uniquement, controler la conso, decider ensuite de generaliser ou non aux 3 instances). Bilan a J+1 : 389 appels, ~11,65M tokens entrants (tres majoritairement cache), ~182K tokens sortants, 5 incidents "reponse vide/pensee sans contenu", 2 fallbacks (meme session courte 21h47-21h48 du 05/07). Taux d'echec 0,5%, isole a un cas de contexte court (in=631) ou le raisonnement interne du modele epuisait le budget max_tokens avant d'emettre le contenu visible (meme piege documente pour family-help dans migration-provider-opencode-go.md).

Fix applique : model.max_tokens 4096 -> 8192 dans data/config.yaml hermes-nyora (backup pris), restart hermes-agent-nyora (start manuel necessaire, l'appel restart API a timeout cote client comme pour hermes-agent-perso plus tot). Container reparti healthy, mimo-v2.5 toujours model par defaut.

Point de decision (generaliser mimo-v2.5 aux 3 instances ou rester DeepSeek V4 Flash) a reprendre en fin de semaine de pilote, sur la base de la conso reelle et du taux d'incidents mesures ici.