Files
mission-control-v2/deploy/warmup.sh
T
Hitonabi f88ed4e5df LLM-Landschaft: Vision raus aus dem Warm-Set (on-demand, ttl 900) + Template=Live-Abgleich
User-Entscheid 07.07.: 'Gehirn + Embedding reichen komplett aus' — die Augen
(VL-30B, ~19 GB) werden nur gebraucht, wenn Lucy auf dem Desktop an ist oder
die IDE-Lane sie ruft. Warm-Set = nur noch Qwen3.6 + embed; damit passt der
60-GB-Chef-Gutachter (gpt-oss) wieder neben das Hirn.

- llama-swap.config.yaml: VL-30B aus brains raus, ttl 0 -> 900 (15 min
  Nachlauf); Kommentare entstaubt. AUSSERDEM Template<->Live-Drift beendet:
  Template hatte coder-lite wiederbelebt (live seit 05.07. entfernt) und
  KV q4_k (lief NIE live) — beides auf Live-Wahrheit (q8_0, kein coder-lite)
  zurueckgesetzt; Qualitaet vor ein paar GB, RAM-Engpass ist mit der Diaet weg.
- warmup.sh: Default 'fast vision' -> 'fast' (Root-Kopie unter
  /usr/local/bin braucht spaeter einmal sudo cp — bis dahin waermt ein
  llama-swap-Restart vision einmalig, ttl 900 raeumt es wieder ab)
- warmer.py: Docstring auf neues Warm-Set angepasst
- Lucy-Seite (eigenes Repo): App waermt die Augen beim Start + alle 10 min,
  solange sie laeuft — Augen-Lebenszyklus == Lucy-Lebenszyklus

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-07 21:53:06 +02:00

59 lines
2.7 KiB
Bash

#!/usr/bin/env bash
# Lädt das warme "brains"-Set nach einem llama-swap-(Re)Start vor, damit die ERSTE
# Anfrage nicht kalt ist (llama-swap lädt sonst lazy bei Bedarf).
# Eingehängt als ExecStartPost=-/usr/local/bin/llama-swap-warmup.sh in llama-swap.
#
# `fast` = das Agent-Hirn (Qwen3.6-35B-A3B), `embed` = das Embedding-Modell
# (Qwen3-Embedding-0.6B, für Mem0/Gedächtnis). Die Augen (vision/VL-30B) sind seit 07.07.
# ON-DEMAND (User-Entscheid) und gehören NICHT mehr ins Warm-Set — die Lucy-App wärmt sie
# beim Start selbst an. Modelle werden NICHT automatisch zusammen geladen — jedes einzeln
# anstoßen, sonst bleibt es kalt.
# Embedding läuft im --embedding-Modus → anderer Endpunkt (/v1/embeddings, nicht chat).
# Selbst-detachend: blockiert den Service-Start nicht.
# NACH ÄNDERUNG: sudo cp deploy/warmup.sh /usr/local/bin/llama-swap-warmup.sh (root-Kopie!)
set -u
URL="${MC_LLAMA_SWAP_URL:-http://127.0.0.1:8080}"
BRAINS="${MC_WARMUP_MODELS:-fast}"
EMBEDS="${MC_WARMUP_EMBED:-embed}"
if [ "${1:-}" != "--inner" ]; then
setsid "$0" --inner >/dev/null 2>&1 &
exit 0
fi
# --- ab hier im entkoppelten Hintergrundprozess ---
for _ in $(seq 1 60); do # auf llama-swap warten (max ~120s)
curl -sf "$URL/v1/models" >/dev/null 2>&1 && break
sleep 2
done
for m in $BRAINS; do # Chat-Hirne über /v1/chat/completions
curl -s -m 180 -X POST "$URL/v1/chat/completions" \
-H 'Content-Type: application/json' \
-d "{\"model\":\"$m\",\"max_tokens\":1,\"messages\":[{\"role\":\"user\",\"content\":\"ping\"}]}" \
>/dev/null 2>&1 || true
done
for m in $EMBEDS; do # Embedding-Modelle über /v1/embeddings
curl -s -m 120 -X POST "$URL/v1/embeddings" \
-H 'Content-Type: application/json' \
-d "{\"model\":\"$m\",\"input\":\"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.
AGENT_KEY="$(grep -E '^API_SERVER_KEY=' "$HOME/.hermes/.env" 2>/dev/null | cut -d= -f2- | tr -d '"' | tr -d "'")"
if [ -n "$AGENT_KEY" ]; then
for _ in $(seq 1 45); do # auf hermes-gateway warten (Boot-Reihenfolge)
curl -sf -m 2 "http://127.0.0.1:8642/health" >/dev/null 2>&1 && break
sleep 2
done
curl -s -m 120 -X POST "http://127.0.0.1:8642/v1/chat/completions" \
-H "Authorization: Bearer $AGENT_KEY" -H 'Content-Type: application/json' \
-H 'X-Hermes-Session-Id: warmup-prefill' \
-d '{"model":"hermes","stream":false,"messages":[{"role":"user","content":"Sag nur OK."}]}' \
>/dev/null 2>&1 || true
fi