Warm-Waechter lief 11 Tage im Leerlauf: Reranker war nie erreichbar

Beim Nachsehen wegen einer haengenden Gitea-Karte im Steward-Log gefunden:
600 vergebliche warmup.sh-Laeufe in 24 h, alle 90 Sekunden. Aelteste Meldung
dieser Art: 15.07.2026 — also elf Tage, nicht erst seit dem Umbau.

Ursache: Der Reranker steckt in der ko-residenten Gruppe `brains` und gilt dem
Waechter damit als warm-pflichtig. Er antwortet aber NUR auf /v1/rerank — und
genau diesen Endpunkt kannte warmup.sh nicht. Das Modell konnte also nie warm
werden, der Waechter sah es ewig als "fehlend" und rief alle 90 s ein Skript auf,
das daran nichts aendern konnte. Mit Devstral in derselben Gruppe habe ich die
Falle vorgestern verdoppelt.

Zwei Korrekturen:
1. warmup.sh waermt jetzt auch Reranker (MC_WARMUP_RERANK, Default "reranker").
2. warmer.py bekommt MC_WARMSET als Override der Gruppen-Ableitung. Ko-Residenz
   ("duerfen gleichzeitig liegen") und Warm-Pflicht ("muessen immer liegen") sind
   zwei verschiedene Aussagen; die Gruppe kann nur die erste ausdruecken. Seit
   Coder (TTL 90 min) und Kritiker (TTL 30 min) in `brains` liegen, haette der
   Waechter sonst gegen ihre TTLs gearbeitet und nachts 62 GB wieder hochgeladen.

Steward bekommt MC_WARMSET = embed + reranker + hermes (Drop-in auf der Box).
Falle dabei, live erlebt: systemd trennt `Environment=` an Leerzeichen — ohne
Anfuehrungszeichen kam nur das erste Modell an und das Warm-Ziel war still zu
klein. Der erste Fix sah deshalb erfolgreich aus (Schleife weg), war aber nur
eine kaputte Messung. Jetzt gequotet und im Prozess-Environ geprueft.

Belegt: alle drei Ziel-Modelle warm, 0 vergebliche Ausloesungen des neuen
Prozesses, Coder geladen aber korrekt kein Warm-Ziel.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

backend/services/warmer.py

@@ -73,7 +73,18 @@ def _run_warmup() -> bool:
 
 
 def _warmset_members() -> set[str]:
-    """Soll-Warm-Set = Mitglieder aller ko-residenten Gruppen (swap:false bzw. persist/persistent)."""
+    """Soll-Warm-Set. `MC_WARMSET` (leerzeichengetrennt) schlägt die Gruppen-Ableitung.
+
+    Warum ein Override (26.07.2026): Seit die ko-residente Gruppe auch Modelle MIT TTL
+    enthält (Coder 90 min, Kritiker 30 min), ist „alle Gruppen-Mitglieder" das falsche Ziel.
+    Der Wächter würde gegen die TTLs arbeiten und nachts 62 GB wieder hochladen, die
+    absichtlich freigegeben wurden. Ko-Residenz („dürfen gleichzeitig liegen") und
+    Warm-Pflicht („müssen immer liegen") sind zwei verschiedene Aussagen — die Gruppe kann
+    nur die erste ausdrücken.
+    """
+    explizit = os.environ.get("MC_WARMSET", "").split()
+    if explizit:
+        return set(explizit)
     try:
         from services import llamaswap
         groups = llamaswap.list_groups() or {}

deploy/warmup.sh

@@ -15,6 +15,11 @@ set -u
 URL="${MC_LLAMA_SWAP_URL:-http://127.0.0.1:8080}"
 BRAINS="${MC_WARMUP_MODELS:-fast}"
 EMBEDS="${MC_WARMUP_EMBED:-embed}"
+# Reranker laufen im --reranking-Modus und antworten NUR auf /v1/rerank — weder Chat noch
+# Embeddings wecken sie. Solange das hier fehlte, galt der Reranker dem Waechter dauerhaft
+# als "fehlend": er rief warmup.sh alle 90 s auf, ohne dass sich je etwas aendern konnte
+# (600 vergebliche Laeufe in 24 h, aelteste Meldung 15.07.2026).
+RERANKS="${MC_WARMUP_RERANK:-reranker}"
 
 if [ "${1:-}" != "--inner" ]; then
   setsid "$0" --inner >/dev/null 2>&1 &
@@ -41,6 +46,13 @@ for m in $EMBEDS; do                           # Embedding-Modelle über /v1/emb
     >/dev/null 2>&1 || true
 done
 
+for m in $RERANKS; do                          # Reranker über /v1/rerank (eigener Endpunkt!)
+  curl -s -m 120 -X POST "$URL/v1/rerank" \
+    -H 'Content-Type: application/json' \
+    -d "{\"model\":\"$m\",\"query\":\"ping\",\"documents\":[\"ping\"]}" \
+    >/dev/null 2>&1 || true
+done
+
 # Agenten-Prompt vorkauen: Hermes' Systemprompt (~70 KB, 33 Tool-Schemas) kostet nach
 # jedem Modell-(Neu-)Laden sonst 30-40 s Prefill BEIM ERSTEN USER-CALL (gemessen 03.07.:
 # kalt 37 s, mit gefülltem Prompt-Cache ~6 s). Ein Wegwerf-Turn füllt den -cram-Cache.