diff --git a/_INDEX.md b/_INDEX.md index d393452..83148be 100644 --- a/_INDEX.md +++ b/_INDEX.md @@ -44,8 +44,8 @@ | Runbook | Date | Tags | |---------|------|------| -| [Accès Bifrost (passerelle LLM, vision/OCR)](common/bifrost-access.md) | 2026-06-14 | bifrost, llm, x-bf-vk | -| [Bifrost — incidents VK & fallback (consolidé 23/06 + 06/07)](common/bifrost-vk-incidents.md) | 2026-07-09 | bifrost, vk, opencode, cout | +| [Accès Bifrost (passerelle LLM, vision/OCR)](common/bifrost-access.md) | 2026-07-11 | bifrost, llm, x-bf-vk, bifrost-proxy, hermes-desktop | +| [Bifrost — incidents VK & fallback (consolidé 23/06 + 06/07 + 11/07)](common/bifrost-vk-incidents.md) | 2026-07-11 | bifrost, vk, opencode, cout | | [Migration provider → OpenCode Go (consolidé, état des modèles à jour)](common/opencode-go-migration.md) | 2026-07-09 | opencode, hermes, family-help | | [n8n Code nodes LLM vers Bifrost obligatoire](common/runbook-n8n-llm-bifrost.md) | 2026-06-15 | n8n, bifrost, code-node | | [Génération/édition d'images IA (nano-banana)](common/openrouter-image-gen.md) | 2026-06-14 | openrouter, image | @@ -126,3 +126,4 @@ - `common/vps-transition-swap-hdd.md` — transition VPS Contabo (doublure noyau métier) pour swap HDD + reset volume. Tailscale = fenêtre. (10/07/2026) - `scripts/backup-usb.sh` — backup USB incrémental root (docker+volumes+mémoire), tâche DSM. (10/07/2026) + diff --git a/common/bifrost-access.md b/common/bifrost-access.md index a30d3b8..ef52adc 100755 --- a/common/bifrost-access.md +++ b/common/bifrost-access.md @@ -40,16 +40,22 @@ Que ce soit a la creation ou en update via /api/governance/virtual-keys, le cham ### Endpoint /anthropic/v1/messages : ne marche pas avec les providers custom Teste et confirme : /anthropic/v1/messages fonctionne pour les providers CANONIQUES de Bifrost (ex. groq -> 200 OK, reponse bien traduite au format Anthropic). Pour un provider CUSTOM (base_provider_type: openai, ex. opencode), la meme requete renvoie 404 "HTML response received from provider". Ne pas utiliser le plan "provider Anthropic natif cote client + base_url vers /anthropic" pour router vers DeepSeek/OpenCode via Bifrost. Utiliser /v1/chat/completions (mode OpenAI-compatible standard) a la place. -### Recette Hermes Desktop -> Bifrost -> DeepSeek V4 Flash (OpenCode) -~/.hermes/config.yaml : - model: - provider: custom - base_url: http://192.168.100.33:3085/v1 - default: opencode/deepseek-v4-flash - api_mode: chat_completions - context_length: 128000 +### Recette Hermes Desktop -> Bifrost -> DeepSeek V4 Flash (OpenCode) — MAJ 2026-07-11 (valide, testee de bout en bout) -~/.hermes/.env : - CUSTOM_API_KEY=sk-bf- +**Utiliser bifrost-proxy (port 3086), pas Bifrost direct (3085).** Le proxy traduit `Authorization: Bearer ` (ou `x-api-key`) en `x-bf-vk` cote Bifrost. Fonctionne avec le format de vk classique `bfk-*` — pas besoin du format `sk-bf-*` ni d'un client capable d'envoyer un header custom. + +Config generique (tout client OpenAI-compatible, type Hermes Desktop) : +``` +Base URL : http://192.168.100.33:3086/v1 +Auth : Authorization: Bearer (champ "API Key" standard) +``` + +**Piege vecu (11/07)** : ecrire l'IP avec un `:` au lieu d'un `.` (ex. `192:168.100.33`) casse le parsing cote client → symptome "connected but no models" trompeur, ne pas chercher plus loin avant d'avoir verifie l'IP au caractere pres. + +**`/v1/models` sur le port 3086 ne requete PAS Bifrost en direct** : il sert un catalogue STATIQUE (`/mnt/docker/bifrost-proxy/models.json` sur le NAS), relu a chaque requete (pas de restart necessaire pour l'editer). Si un modele manque dans le picker du client alors qu'il est bien autorise sur la vk cote Bifrost (verifiable via `curl http://172.17.0.1:3085/v1/models -H "x-bf-vk: "`), l'ajouter directement dans ce fichier. Cf. incident 11/07 dans bifrost-vk-incidents.md — `deepseek-v4-flash` avait disparu de ce catalogue lors de la reduction de stack fin juin/debut juillet. + +VK Yesmine (Hermes Desktop) : `Yesmine-Key`, `bfk-04e2a58c7ce42bd676c4e0768b4b40ae5dc01a9999979527`, providers openrouter/google/nvidia_nim/opencode (deepseek-v4-flash). Reutilisable telle quelle pour tout futur client desktop — **MacBook M5 Pro inclus** — tant que le format reste `bfk-*`. + +#### Ancienne piste (2026-07-02, port 3085 direct + vk `sk-bf-*`) — DEPRECIEE +Documentee a l'epoque en misant sur un support natif de `Authorization: Bearer` par les vk au format `sk-bf-*`. Non reconfirmee depuis, et la vk Yesmine reellement utilisee est restee au format `bfk-*`. Le contournement via bifrost-proxy (3086) est desormais la methode de reference : plus simple (aucune regeneration de vk necessaire), et validee de bout en bout le 11/07/2026 (connexion + appel chat reel sur deepseek-v4-flash confirmes). -Vk dediee a Yesmine (Hermes Desktop T470) : Yesmine-Key, budget 3 dollars/mois, providers openrouter/google/nvidia_nim/opencode, allowed_models opencode limite a deepseek-v4-flash. Detail complet : NyoraNotes, note "Bifrost debloque pour Yesmine - Hermes Desktop T470". diff --git a/common/bifrost-vk-incidents.md b/common/bifrost-vk-incidents.md index 1aa5943..86abf10 100644 --- a/common/bifrost-vk-incidents.md +++ b/common/bifrost-vk-incidents.md @@ -37,3 +37,18 @@ curl -X POST http://bifrost:8080/v1/chat/completions -H 'x-bf-vk: ' \ -d '{"model":"deepseek-v4-flash","max_tokens":30,"messages":[{"role":"user","content":"dis OK"}]}' # 200 + routing_info.provider=opencode attendu ``` + + +## Incident 11/07/2026 — VK stale-cache (3e occurrence) + modele manquant dans bifrost-proxy + +**Contexte** : config Hermes Desktop sur le poste de Yesmine, via bifrost-proxy (port 3086). + +1. **401 virtual_key_not_found recurrent sur la vk Yesmine**, alors que la vk est active et correctement provisionnee en base (providers openrouter/google/nvidia_nim/opencode, allow_all_keys=1 sur les 4). Confirme dans logs.db : rafales d'echecs 401 entrecoupees d'appels reussis sur la meme vk, meme minute — meme signature que l'incident du 06/07 (cache VK memoire desynchronise de la DB). **Fix identique : restart du conteneur bifrost.** Troisieme occurrence en 5 jours -> ce n'est plus un incident isole, cf. section "A surveiller" plus bas. +2. **`opencode/deepseek-v4-flash` absent du picker du client** alors qu'autorise sur la vk cote Bifrost. Cause : le catalogue statique `/mnt/docker/bifrost-proxy/models.json` (servi par nginx sur `/v1/models`, independant de Bifrost) avait perdu cette entree lors de la reduction de stack fin juin/debut juillet (l'ancien fichier plus complet contenait `deepseek/deepseek-v4-flash`, la refonte l'a droppee au passage a la nomenclature `opencode/*`). Fix : entree reajoutee dans models.json (`opencode/deepseek-v4-flash`, ctx 128000), backup de l'ancien fichier garde (`models.json.bak-20260711-manual`). Aucun restart necessaire, le fichier est relu a chaque requete `/v1/models`. +3. Un vrai `HTTP 500 provider API error` a egalement ete observe en parallele, mais sans rapport avec les deux points ci-dessus : erreur `INTERNAL` renvoyee directement par Google AI Studio sur `gemma-4-26b-a4b-it` (panne ponctuelle fournisseur, confirmee sur `google-key1` et `google-key2`). Aucune action cote infra. + +**Recette client complete (Hermes Desktop, MacBook inclus)** : voir `common/bifrost-access.md`, section "Recette Hermes Desktop" (MAJ 11/07) — port 3086, `Authorization: Bearer `, catalogue statique a completer manuellement si un modele manque. + +## A surveiller (mis a jour 11/07) + +Le cache VK stale n'est plus un incident isole : 3 occurrences en 5 jours (23/06 racine differente, 06/07, 11/07) avec le meme symptome et le meme fix (restart bifrost). A investiguer en profondeur si ca continue : pourquoi le cache memoire ne s'invalide pas sur ecriture DB (write recent sur config.db sans invalidation cache observe le 11/07). En attendant, reflexe standard confirme : **tout 401 virtual_key_not_found inexplique -> restart bifrost avant toute autre investigation**, ne pas re-tester en boucle sur le meme cache fige.