Beim manuellen ctx-Eintrag (Modellkarte »Ctx«) gab es nur ein leeres Eingabefeld.
Jetzt:
- Backend: GET /api/models/{id}/ctx/auto liefert den setup-bewussten Optimal-ctx fuer
ein bestehendes Modell (Rolle/Params/Quant + aktuelles Setup) inkl. Budget-Herleitung.
budget.py: params_of_model() + setup_aware_ctx_for_model() (DRY mit footprint_gb).
- Dialog (CustomDialog/useDialog): optionaler Auto-Button im Prompt, der den Wert eintraegt.
- Cockpit: »Ctx« holt den Optimalwert, zeigt ihn + Budget (GTT/reserviert/frei) in der
Meldung und bietet »Auto (Nk)« zum direkten Uebernehmen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
max_ctx_in_budget schaetzte den KV-Cache LINEAR mit den Params, waehrend Footprint/Fit
sqrt rechnen (kalibriert an Hermes-14B@128K~19GB). Folge: fuer grosse Modelle viel zu
konservativ -> setup_aware_ctx schlug z.B. fuer heavy-122B 8192 vor, obwohl 32768 real
passt. Jetzt exakte Inverse der Footprint-Formel (sqrt*0.84) -> heavy bekommt ~49k statt
8k, keine faelschlichen Reduktionen mehr.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bisher rechnete nur der Hirn-Wechsel setup-bewusst; die allgemeine ctx-Auto-Groesse
nahm den Gesamt-RAM in ISOLATION (ignorierte Hirn/warmes Set/Ko-Residenz) -> ctx
konnte zu gross gewaehlt werden.
Neu: services/budget.py buendelt GTT-Budget, Modell-Footprint und reservierten Speicher
gemaess VERIFIZIERTER Box-Residenz (Hirn immer resident; fast/vision duerfen weichen,
wenn grosses on-demand-Modell laedt). setup_aware_ctx() bemisst den groessten ctx, der
NEBEN dem bestehenden Setup passt - rollen-/gruppen-bewusst aus der echten Config.
- fit.py: max_ctx_in_budget() als budget-basierter Kern; max_ctx_for() delegiert
- models.py: install nutzt setup_aware_ctx; /api/fit liefert assigned_ctx + Budget-Herleitung
- agent.py: nutzt die gemeinsamen Helfer (entfernt Duplikate _gtt_budget_gb/_foot)
- AddModel: Ampel zeigt den setup-bewussten ctx ('ctx -> Nk') inkl. Budget-Tooltip;
Rollen-Wechsel laedt die Vorschau neu (Rolle bestimmt das Budget)
Effekt: heavy-122B bekommt z.B. 16k statt 131072 (passt neben dem Hirn), waehrend
warme Kleinmodelle weiter grossen Kontext erhalten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Manueller HF-Install hatte zwei scharfe Kanten:
- kein Fit/OOM-Schutz: zu grosses Modell stuerzte erst beim Laden ab
- stiller Rollen-Diebstahl: exklusiver Alias wanderte kommentarlos weg
Backend: /api/fit leitet params_b jetzt aus KATALOG (echte Metadaten, MoE-bewusst)
oder Namens-Schaetzung ab (params_b<=0) -> Fit-Vorschau fuer beliebige HF-Repos.
Frontend (AddModel): Hardware-Fit-Ampel (perfect/marginal/OOM) mit ~params/req_gb/tps
nach 'Quants laden'; OOM-Gate (zweiter, roter Klick noetig); Warnung welches Modell
die gewaehlte Rolle aktuell haelt und sie verliert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Inspiriert von Odysseus' Cookbook: backend/models_catalog.json mit echten Metadaten
(total/active params, moe, generation) je Rolle. services/catalog.py: Laden, Name-Match,
MoE-bewusstes Scoring (Wissen + Tempo via tps -> MoE-first auf der bandbreiten-Box), Fit.
- discover.py: Empfehlung jetzt KATALOG-FIRST (kuratiert, korrekt), HF-Dynamik als Ergaenzung/Fallback.
- maintenance.model_upgrades: Metadaten aus Katalog -> praezise Familie/Generation/Groesse + MoE-first
(dense ersetzt MoE nur bei grossem Wissens-Sprung). Behebt Coder-Next=7B-Fehlschaetzung,
Qwen2.5-VL-Generations-Downgrade, falsches dense-scout-Upgrade.
- fit.py: MXFP4/FP8/AWQ in der Quant-Tabelle.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
model_upgrades verletzte das Prinzip: schlug Generations-Downgrades (Qwen2.5-VL ueber
Qwen3-VL), Groessen-Downgrades (Qwen3-Coder-Next ~84B -> 30B; Params aus Name als 7B
fehlgeschaetzt) und Fremd-Familien-Swaps (gpt-oss als Qwen-"Upgrade") vor.
- _params_of: groessen-bewusste Params (max aus Name + Dateigroesse).
- _gen_key: Familie+Subtyp+Generation aus dem Namen (qwen-vl 3.0 vs 2.5 etc.).
- Guard: Upgrade nur bei gleicher erkennbarer Familie UND (neuere Generation ODER
deutlich groesser in gleicher Gen). Sonst keine "Bessere Version"-Anzeige.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- agent.set_agent_brain(model_id): vergibt 'hermes'-Alias, tauscht das Modell in die
residente brains-Gruppe (altes Hirn raus, fast/vision bleiben) und zeigt die Hermes-Config
darauf (+ Gateway-Restart). Behebt: AgentView-Switch hielt das neue Hirn nicht warm.
- POST /api/agent/brain/set.
- Cockpit Agent-Hirn-Karte: Button "Hirn wechseln" + Modal mit allen installierten Modellen
(Groesse/Params/Rolle/Tools), aktuelles markiert; Hinweis zugunsten Hermes (Tool-Calling).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
_gguf_total_size summiert alle ...-NNNNN-of-NNNNN.gguf-Teile. size_bytes des ersten
Teils war bei Split-Modellen wie Qwen3.5-122B (11M Header + 47G + 25G) irrefuehrend.
Fix wirkt in UI-Anzeige UND Budget-Footprint.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
heavy ist Split-GGUF (size_bytes = nur erster Teil) -> aus Namen (122B); coder ohne
Groesse im Namen -> aus Dateigroesse (~84B). max() deckt beide Faelle ab.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
_foot() rechnet Gewichte aus size_bytes (genau) + kalibrierten KV-Anteil; Params werden
aus der Dateigroesse abgeleitet, wenn der Name keine Groesse hergibt (z.B. Qwen3-Coder-Next,
46GB -> ~84B). Damit ist das groesste on-demand-Modell im Budget realistisch.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Brain-Kontexte gesenkt (live config): hermes 128K->64K, fast/vision 128K->32K
-> Always-Warm-Footprint 74GB->51GB, ~23GB frei; heavy/coder passen wieder daneben.
- /api/agent/brain liefert jetzt `budget`: projiziert den Always-On-Footprint mit dem
empfohlenen Brain gegen das GTT-Budget (aus amdgpu.gttsize) und prueft, ob das groesste
on-demand-Modell daneben passt (fit.estimate_memory_gb).
- Cockpit Agent-Hirn-Karte: Budget-Zeile (gruen/rot) + Warnung im Update-Confirm, wenn ein
zu grosses Always-On-Brain das groesste on-demand-Modell verdraengen wuerde. Button wird rot.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- discover.rank_runnable: rankt jetzt fit-level > params_b(desc) > downloads -> fuer die
128GB-Box wird das faehigste passende (MoE-)Modell empfohlen statt kleiner Populaer-Modelle.
Top-4-Anzeige nutzt dasselbe Ranking.
- maintenance.model_upgrades: schlaegt KEIN Downgrade mehr vor (rec.params_b >= installiert*0.95).
Behebt: fast 35B-A3B -> 4B wurde faelschlich als Upgrade angeboten.
- Frontend: Rollen-Farb-Mapping zentralisiert in ModelBadges (ROLE_TONE/roleTone);
Cockpit/RolesCard/ActiveModelsCard nutzen es statt eigener Duplikate.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Engine-Cutover ROCm/HIP -> Vulkan/RADV (gfx1151): +12-22% tg auf MoE (llama-bench
verifiziert, fast 53->65 t/s). ROCm-Build bleibt als Rollback unter /opt/llamacpp.
- Backend: vocab-aware Speculative Decoding. services/gguf_meta.py liest den
Tokenizer-Fingerprint (model/pre/n_vocab) direkt aus dem GGUF-Header (ohne Modell-Load);
register_model + migrate_config haengen nur VOCAB-KOMPATIBLE Drafts an (inkl. --spec-type,
das in dieser llama.cpp-Generation noetig ist). Neue Endpoints /api/models/drafts + /{id}/draft.
- Frontend: idiotensichere Spec-Draft-UI (SpecDraftModal) - nur kompatible Drafts waehlbar,
inkompatible gesperrt mit Begruendung; SPEC/SPEC?-Badge nach echtem Aktiv-Status; Rolle in AddModel.
- maintenance.py: Engine-Update-Quelle -> ggml-org/llama.cpp (Build-Nummer-Vergleich),
ENGINE_PATH=/opt/llamacpp-vulkan.
- Startup-Warmup der brains (deploy/warmup.sh, self-detaching ExecStartPost) + deploy/provision-engine.sh.
- Cleanup: tote LiteLLM gateway/config.yaml + alle Referenzen (config.py/backup.py/backup.sh) entfernt;
README + docs/memory aktualisiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
MC2 prüfte Gateway-Erreichbarkeit via GET /v1/models — der Hermes API-Server
lehnte jeden Request ohne gültigen API-Key ab (Spam alle 3s im Log).
Fix: /health-Endpoint nutzen, der keine Authentifizierung benötigt.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Neuere llama-swap-Versionen liefern /running als Liste von Objekten
({model,state,...}) statt Strings. get_running_models() normalisiert nun auf
Namens-Strings → running.includes(name) im Frontend matcht wieder (ActiveModels-
Card + RolesCard 'warm'-Badges). Logger in llamaswap.py ergänzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- ActiveModelsCard: zeigt geladene Modelle (aus /running via useModels) mit
Rolle, Größe (Unified-RAM) und warm-Status; globaler "Inferenz aktiv"-Puls
via useTokenStats-Delta. Prominent oben im Dashboard. Kein Backend-Change.
- maintenance.logs(): journalctl ohne sudo zuerst (User in Gruppe adm darf das
System-Journal lesen), nur bei fehlenden Rechten sudo-Fallback. Behebt
"Unbekannter Fehler" beim llama-swap-Log im MC2-UI.
tsc + Build grün; Dashboard rendert die Live-Karte (Leerzustand lokal, da Engine
offline), keine Konsolenfehler.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
llama-server lehnt --prompt-cache/--prompt-cache-all ab ("invalid argument")
und startet dann nicht — dadurch ließ sich KEIN Modell mehr wecken (u.a. das
Hermes-WebUI bekam "empty stream"). Die Flags gehören zu llama-cli, nicht zum
Server; Prompt-Caching macht llama-server automatisch pro Slot (KV-Reuse).
- config.py: Flags aus _DEFAULT_CMD_TEMPLATE entfernt (+ Warnhinweis).
- migrate_config.py: statt die Flags hinzuzufügen, entfernt es sie nun aus
bestehenden cmds (Reparatur-Migration).
Box-config.yaml wurde bereits direkt korrigiert (alle 7 Modelle); verifiziert:
Hermes lädt + streamt wieder sauber.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Neuer services/pricing.py: PRICING-Dict + compute_savings() aus dem
system-Router extrahiert; Router ist jetzt dünn (nur role_map + Aufruf).
- /system/token-stats liefert zusätzlich das pricing-Dict → Frontend zeigt
die Tarife daraus an statt sie im Text zu hartkodieren.
- SPEC_DRAFT_MODEL_PATH in config.py (MC_SPEC_DRAFT_MODEL); llamaswap.py und
migrate_config.py referenzieren die Konstante statt des doppelten Literals.
- Ersparnis-Berechnung verhaltensneutral verifiziert (35,09 $ / 32,28 €).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
W2: install akzeptiert HF-URL ODER org/repo (normalize_repo); GET /api/hf/
search + /api/hf/quants; Frontend AddModel-Panel (URL+Quant-Dropdown+freie
Suche) im Discover-Tab. W3: POST /api/models/{id}/role + /ctx; Installiert-
Tab mit Rollen-Select (fast/heavy/coder/...), ctx-Edit, Loeschen → LLM
tauschen per Klick.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
LiteLLM baut auf Python 3.14 nicht (orjson-Pin ohne cp314-Wheel). Stattdessen
eingebauter Gateway in MC2: routers/gateway_proxy.py (/v1/chat/completions,
/completions, /models) + services/router_logic.py (Komplexitaets-Routing
fast<->heavy, Streaming-Passthrough). gateway.py/routing.py/connect.py auf
builtin umgestellt (Endpunkt = MC :PORT/v1). Gleicher OpenAI-Vertrag,
spaeter gegen LiteLLM austauschbar.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
model_id_from_path steigt bei Quant-Ordner (Q4_K_M/, UD-Q4_K_M/) eine
Ebene hoch zum Repo-Ordner. Sonst hiess das Heavy-Modell Q4_K_M.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Real-Box-Befund: GPU ist card1 (nicht hardcoded card0), Connector-Dirs
uebersprungen. Zusaetzlich GTT (echter Unified-Memory-Pool) statt nur
VRAM-Carve-out. Frontend zeigt GTT bevorzugt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hitonabi