Files
mission-control-v2/docs/RADAR.md
T
HitonabiandClaude Opus 5.5 f4bbdad311 doku: Betriebsdoku neu (ARCHITEKTUR, BETRIEB, UPDATES, RADAR, WIEDERAUFBAU)
- ARCHITEKTUR.md (neu): Prozesse und Units, Rollen box/homelab und Partner-Instanz aus
  Phase 2a (kern/einstellungen.py, kern/zeit.py, kern/partner.py, /api/partner), Modell-Rollen,
  Bild-Weiche, wer welche Datei schreibt (inkl. mc2-quittiert.json), Meldeweg mit
  Telegram-Zweitweg, alle 62 /api-Routen, Herkunftspruefung, kurzer Ausblick Homelab-Teil.
- BETRIEB.md (neu, loest RUNBOOK.md und BACKUP.md ab): Handgriffe, Meldungen und Betreffzeilen,
  Waechter-Regeln (Partner nach 5 Takten, Spracherkennung nur wenn wach, Ausblenden-Knopf),
  Dienste schlafen/wecken, zweistufiger Deploy mit Prueftor, Sicherung und Zurueckspielen,
  Notfall, Pfade auf der Box.
- UPDATES.md (neu): Sonntags-Kette per Timer, Postchecks, Festhalten und Freigeben, Handbetrieb,
  Update-Verlauf, Fallen.
- RADAR.md (neu): Modell-Radar (Leitplanken, Nachtablauf, Pruefstand, Uebernehmen/Verwerfen,
  Merkliste) und Stack-Radar.
- WIEDERAUFBAU.md (neu, loest DISASTER_RECOVERY.md ab): entschlackte Schrittfolge, Anhang A
  (llama-swap-Unit und Drop-ins) behalten.

Stand der Aussagen: Code in main 75611be.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 17:37:09 +02:00

6.7 KiB
Raw Blame History

Radar — Modell-Radar, Stack-Radar, Prüfstand

Stand 24.09.2026, Code in main = 75611be. Für Techniker und Agenten.

Es gibt zwei Radare mit getrennten Aufgaben:

  • Modell-Radar (Box-Wart, mc2-radar.timer um 00:30): sucht und testet neue Modelle für Hirn und Coder selbst. Getauscht wird nur per Knopf „Übernehmen".
  • Stack-Radar (Hermes-Cron „KI und Stack Radar", Sa 08:00): Wochenbericht über den Zustand der Box und über Neuigkeiten draußen (Releases, Entwurfsmodelle). Er testet und ändert nichts.

Modell-Radar

Code: backend/services/radar.py, Nachtlauf backend/radar_lauf.py, Messungen deploy/bench/pruefstand.py, Merkliste deploy/radar-watchlist.json. Zustand: /srv/models/mc2-radar.json, Baseline /srv/models/mc2-radar-baseline.json, Downloads /srv/models/radar/<id>/. Protokoll: journalctl --user -u mc2-radar.

Leitplanken (User-Entscheid 23.09.)

  • Zwei Rollen: Hirn (Alias hermes) und Coder (Alias coder), jede mit Bild-Zwilling (vision bzw. coder-bild).
  • Tests nur nachts 00:3002:30, höchstens ein neuer Kandidat pro Woche. Um 03:00 braucht der NerdQuiz-Nachtlauf das Hirn.
  • Nur was neben das Warm-Set passt: 27 GB Warm-Set plus Kandidat mit KV-Cache ≤ 115 GB, gerechnet mit dem Kontext aus dem Betrieb (131 072; passt das nicht, stufenweise kleiner, nie unter 32 768). Ab 90 % des Budgets heißt es „passt knapp".
  • Pflicht: GGUF plus Bild-Projektor (mmproj), mindestens 20B Parameter; als Hirn höchstens 12B aktive Parameter (dichte Modelle nie als Hirn). Die installierte Engine muss die Architektur kennen, und die Platte darf nach dem Download nicht über 80 % liegen.
  • Durchgefallene werden gelöscht, Bestandene bleiben liegen. Getauscht wird erst mit „Übernehmen".

Ablauf einer Nacht

  1. Um 00:30 startet mc2-radar.service (Persistent=true, holt einen verpassten Lauf nach).
  2. Suche, höchstens einmal am Tag: zuerst die Merkliste in ihrer Reihenfolge, dann die Hugging-Face-Entdeckung (höchstens 3 Funde je Rolle). Jeder Fund wird bewertet: Dateien, Größe, Engine-Unterstützung, Speicher. Der Knopf „Jetzt suchen" macht dasselbe sofort (läuft synchron und kann Minuten dauern).
  3. Offene Urteile nachholen: Kandidaten mit Status „getestet", bei denen die Vergleichsmessung fehlte.
  4. Test, wenn ein Kandidat dran ist:
    1. Download nach /srv/models/radar/<id>/.
    2. Baseline des heutigen Modells der Rolle über llama-swap (gecacht, höchstens monatlich neu gemessen).
    3. In llama-swap bleibt nur das Warm-Set; ein Aufpasser entlädt Modelle, die nachts nachgeladen werden (etwa den Coder).
    4. Draft-Varianten kurz messen: ohne Draft, eingebauter MTP-Kopf, Draft des heutigen Modells (nur bei gleicher Architektur und genug Speicher). Ein Draft aus der Merkliste wird allein genommen.
    5. Mit der schnellsten Variante den Prüfstand fahren; der Kandidat läuft als eigener llama-server auf :5899.
    6. Bild-Probe über einen Zwilling ohne Draft, dann das Urteil.
  5. Frist: Die Messungen prüfen das Fensterende 02:30 selbst. 5 Minuten danach zieht die Notbremse (Kandidaten-Server und Download stoppen, der Prozess endet hart). RuntimeMaxSec=2h10min beendet die Unit spätestens um 02:40 samt llama-server.
  6. Bestanden: Meldung „[Modell-Radar] … hat den Nachttest bestanden"; nachts landet sie in der Morgenmeldung.

Status eines Kandidaten: neu → wartet → getestet → bestanden oder durchgefallen → uebernommen oder verworfen. Höchstens 3 Versuche je Kandidat; ein Abbruch, für den der Kandidat nichts kann, zählt nicht als Versuch.

Prüfstand (deploy/bench/pruefstand.py)

  • Der Kandidat läuft als eigener llama-server auf 127.0.0.1:5899; der Live-Stack bleibt unberührt.
  • Hirn: Tempo kurz und bei 13k Kontext (Prefill, Decode, Draft-Akzeptanz), Werkzeug-Aufrufe zwischen ~100 Werkzeugen mit ~12k Kontext, Deutsch- und JSON-Probe.
  • Coder: Tempo, Werkzeug-Aufrufe eines Coding-Agenten, 10 kleine Programmieraufgaben mit Unit-Tests in einem Temp-Ordner mit Zeitlimit.
  • Bild: ein im Code gezeichnetes Bild (Formen, Farben, Text), einmal direkt, einmal mitten in einer Werkzeug-Aufgabe.
  • Urteil: bestanden = keine Verschlechterung bei den Pflichtwerten UND mindestens ein echter Vorteil.
  • Handbetrieb: deploy/bench/pruefstand-hirn.py misst Kandidaten mit festen Pfaden gegen die Live-Modelle, optional mit einem Werkzeug-Test durch den echten Hermes (Provider pruefstand in der Hermes-Config).

Übernehmen und Verwerfen (Seite „Modelle")

Übernehmen geht nur bei Status „bestanden" und nicht während eines Nachtlaufs:

  1. Der Ordner wandert von /srv/models/radar/ nach /srv/models/<Repo-Name>.
  2. Eintrag in llama-swap mit dem getesteten Draft und den Betriebs-Flags der Rolle, ohne Projektor. Dazu der Bild-Zwilling <Eintrag>-Bild in der Gruppe bild (ttl 900). Der alte Zwilling fliegt aus der Config, seine Dateien bleiben.
  3. Hirn: Alias hermes, Gruppe brains, ttl 0, model.default in der Hermes-Config; Hermes startet dafür kurz neu. Der Alias fast wandert mit, MC_WARMSET im Steward-Drop-in wird umgestellt und der Steward neu gestartet. Coder: Rolle coder; heavy wandert mit, die ttl des alten Coders wird übernommen.
  4. Das alte Modell bleibt auf der Platte (Aufräumen-Panel).

Verwerfen: Die heruntergeladenen Dateien werden gelöscht, und das Radar testet dieses Modell nie wieder.

Ein Tausch schreibt die llama-swap-Config heute noch mehrmals (offener Punkt in wissen/OFFENE-FAEDEN.md).

Merkliste

deploy/radar-watchlist.json, Felder je Eintrag: name, rolle (hirn oder coder), repo, quant (Standard Q4_K_M), eng (passt nur knapp), notiz, ueberspringen (Grund, dann kein Test), optional draft und flags. Merkliste und Hugging-Face-Entdeckung zusammen ergeben die Warteschlange; Merkliste zuerst.

Stack-Radar (Hermes-Cron „KI und Stack Radar", Sa 08:00)

  • deploy/jobs/stack-radar.sh sammelt Fakten und meldet selbst über notify.sh mit Betreff „[Stack-Radar]".
  • deploy/jobs/stack-ist.sh prüft Ergebnisse statt Lebenszeichen: Lösen die Rollen-Aliase auf? Lief der letzte Timer gut? Ist die Sicherung jünger als zwei Tage?
  • deploy/jobs/stack-upstream.py schaut nach draußen: Releases, gemergte PRs, neue Entwurfsmodelle und Modelle der Familien, die die Box fährt; verglichen mit dem letzten Lauf (~/.hermes/state/stack-upstream.json). Liste: deploy/trend-radar-watchlist.json.
  • Das Hirn (fast) schreibt aus den Fakten einen kurzen Bericht; es darf nichts dazuerfinden. Antwortet es nicht, gehen die roten Rohbefunde trotzdem raus.
  • Grundsatz: „Fakten sammelt ein Skript, Prosa schreibt das Modell." Mehr in deploy/jobs/README.md.