#!/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}" # 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 & 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 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. 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