barby cb71f56fbf Worker G: litellm :4000 YAML-Bug gefixt (114 Modelle live), Hermes-Router zeigt auf toten Host (302)

2026-07-23 15:08:09 +02:00

5.9 KiB

Raw Blame History

name

description

metadata

hub-brain-modelle-check-2026-07-23

Worker G Ergebnis (302): Hub-Modelle/Hermes-Verfuegbarkeit geprueft, litellm-YAML-Bug gefunden+gefixt, Hermes-Router zeigt auf toten Host

node_type	date	author
memory	2026-07-23	worker-g-vm302

Worker G: Hub-Modelle/Hermes-Verfuegbarkeits-Check (302)

Geprueft von VM302 aus (Tailscale-Route zu hub.comet-bicolor.ts.net 100.87.20.94 direkt erreichbar) + ergaenzend per SSH direkt auf den Hub.

Ausgangslage laut Auftrag

Hub-Brain: http://100.87.20.94:3097 → existiert nicht, bestaetigt (Connection refused, kein Prozess/kein Listener). Deckt sich mit vorhandener Memory hub-endpoints-aktuell.md (verifiziert 2026-07-10: ":3097 und :3088 existieren NICHT"). Ein aelterer, widerspruechlicher Eintrag reference_hub_service_map_live.md ("3097 = brain/tts, active") ist veraltet/falsch — sollte korrigiert/geloescht werden.
Router: http://100.87.20.94:3080 → antwortet, ist aber nur ein nginx-Proxy auf jump.panel1.de:3080 (100.91.98.15, eigener uvicorn router:app, 3 Modelle: auto, mammouth::auto, minimax::MiniMax-M2). Kein vollstaendiger 17-Provider- Router.

Gefundener Kern-Bug (BEHOBEN)

Der eigentliche Modell-Gateway des Hubs ist LiteLLM auf :4000 (100.87.20.94:4000, tailnet-only, master_key: sk-litellm-koerner, systemd litellm.service). Er war crashgelooped (activating auto-restart):

yaml.parser.ParserError: while parsing a block mapping
  in "/opt/litellm/config.yaml", line 1, column 1
expected <block end>, but found '-'
  in "/opt/litellm/config.yaml", line 556, column 1

Ursache: ein router_settings: Block (2 Zeilen) war mitten in die model_list:-YAML-Liste eingefuegt worden (Zeile 554/555), was das Parsen der restlichen 17 Listeneintraege danach (bis Zeile 571) invalid machte.

Fix (reversibel, Backup vorhanden):

Backup: /opt/litellm/config.yaml.bak-fix-20260723-145857
router_settings:-Block ans Dateiende verschoben (korrekte Position als eigener Top-Level-Key nach model_list:)
YAML validiert (python3 -c "import yaml; yaml.safe_load(...)" → OK, 4 Top-Level-Keys: general_settings, litellm_settings, model_list, router_settings)
systemctl restart litellm.service → aktiv, stabil, kein Crash-Loop mehr
GET /v1/models (mit Bearer sk-litellm-koerner) → 114 Modelle, siehe unten

Modell-Liste (114, Stand 2026-07-23 15:00, von :4000 via LiteLLM)

Provider-Praefixe: mammouth/* (Chat: claude/claude-haiku/claude-sonnet/opus/gpt-4/ gpt-4o/gpt-5/gpt-5.4-nano/grok/grok-fast/gemini/gemini-2.5-pro/gemini-flash/kimi/ glm/llama/mistral/qwen/perplexity/sonar/deep-research/deepthink/expert/reasoning/ thinking + Medien: flux/nano-banana/sd/recraft/svg/image/gpt-image/veo/kling/sora/ grok-imagine/tts*/speech/elevenlabs/playht/azure-tts/google-tts/openai-tts), deepseek/* (chat, reasoner, v4-flash), jump/deepseek-chat, gpu1/* (qwen3-8b, codestral, gemma3-27b, dolphin3 via Ollama 100.108.128.107), devmac/* (devstral, gemma3, qwen3-32b), ionos/* (13 Modelle inkl. llama-3.1-405b, qwen3-coder, flux-schnell, ocr, embeddings/reranker), free/* (deepseek-r1/v3, gemini-flash, llama4-maverick, mistral-small, qwen3-235b), image/* (comfyui, lustify, pony, sd15, juggernaut, realvis, biglust, cyberpony), qolaba/*, monster/*, openrouter/gemini-pro, code/* (antigravity, gemini, gemini-2.5-flash), hermes2/agi, gpushadow/*.

Vollstaendige Liste im Beleg-Log (Session-Output), auf Anfrage nachreichbar.

"302"-Hinweis/Tag

In keiner Hub-/Hermes-Config (litellm config.yaml, hermes-orchestrator.py, hermes-v2/*, hermes-index.json) existiert ein Tag/Label "302" fuer Modelle. Die einzigen "302"-Treffer sind unrelated Skill-IDs (ln-302-task-replanner, "302ai Api Integration Skill"). Interpretiert als: Kennzeichnung, dass diese Pruefung von VM302 aus erfolgte (Netzwerksicht) — kein technischer Modell-Tag. [BÄR]: falls ein echtes "302"-Tag/Label in Hermes fuer Modell-Sichtbarkeit gemeint war, bitte przisieren — wurde nirgends im Code/Config gefunden.

Ungeloester Befund — [BÄR] noetig

hermes-orchestrator.py, /opt/hermes-v2/orchestrator.py, stategraph.py, supervisor.py haben hartkodiert ROUTER = 'http://100.92.201.88:3080' (Host tools.comet-bicolor.ts.net). Dieser Host ist laut Tailscale seit 2026-06-12 offline (connectedToControl: false, kein lastSeen seither) — 5+ Wochen tot. D.h. Hermes' eigentliche LLM-Call-Funktion router_chat() zeigt seit Wochen auf einen toten Host und kann darueber vermutlich seit Wochen keine Modelle laden/nutzen (nicht als "trivial/reversibel" eingestuft, da mehrere Produktions-Dateien + Auth-Header (master_key vs. dummy) + Modellnamen-Mapping betroffen sind — braucht Bär-Entscheidung, welcher Router (neu: :4000 LiteLLM mit 114 Modellen, oder :3080 nginx-Proxy mit 3 Modellen) Hermes kuenftig verwenden soll).

Separat: t_brain_ask() in hermes-orchestrator.py ruft weiterhin http://localhost:3097/v1/brain — bestaetigt totes Ziel (Eskalationsstufe 4 "Brain-Ask" laut Vier-Stufen-Eskalation in CLAUDE.md ist damit vermutlich nicht funktionsfaehig).

Status brain-smoke-test.service

Laeuft alle 6h, schlaegt seit mind. 3 Tagen durchgehend 5/5 fehl (erwartungs- gemaess, da Ziel :3097/v1/brain nicht existiert). Sollte deaktiviert oder auf einen echten Endpoint umgebogen werden — [BÄR].

Zusammenfassung

Item	Status
Hub-Brain :3097	existiert nicht (bestaetigt, wie Memory 2026-07-10)
Router :3080 (Tailscale, ueber nginx→jump)	laeuft, nur 3 Modelle
LiteLLM Gateway :4000 (echter Hub-Modell-Gateway)	war down (YAML-Bug) → gefixt, jetzt 114 Modelle live
"302"-Tag in Config	nicht gefunden, ungeklaert → [BÄR]
Hermes ROUTER-Konstante	zeigt auf toten Host (100.92.201.88, seit 5+ Wochen offline) → [BÄR]
brain-smoke-test.service	daueraft rot, erwartungsgemaess (totes Ziel) → [BÄR]

5.9 KiB Raw Blame History