From 864237ff2c03e0e887607253a1dfef41778f0581 Mon Sep 17 00:00:00 2001 From: duffyduck Date: Sun, 18 Oct 2026 15:33:54 +0200 Subject: [PATCH] =?UTF-8?q?feat(llm):=20Download-Fortschritt=20beim=20Mode?= =?UTF-8?q?ll-Laden=20=E2=80=94=20und=20"Laden"=20kommt=20endlich=20an?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Eigentlicher Fehler zuerst: llm_provision_model/_result und llm_remove_model standen nie in der RVS-Allow-List. Der RVS verwirft unbekannte Typen mit einem stillen return — jeder Klick auf "Laden" im Modell-Katalog ist seit Stage D (19.09.) an dieser Liste gestorben, die Box hat nie davon erfahren. Laden liessen sich nur die Modelle aus der Basis-Config der Box. Gefunden, weil grep rvs/server.js fuer eine Binaerdatei hielt und still uebersprang: in Zeile 164 stand seit a7998bcd ein ECHTES Nullbyte im Template-String statt eines Escapes. Node stoert das nicht, aber git zeigte fuer jede Aenderung am RVS nur noch "Binary files differ". Jetzt \u0000 — zur Laufzeit derselbe String. Fortschritt: llama.cpp zieht das GGUF per -hf selbst und meldet nichts. Der llm-adapter fragt vorab bei Hugging Face, welche Dateien (Groesse, sha256) kommen, und misst genau diese im HF-Cache-Layout, das llama.cpp verwendet: /models/models--org--repo/blobs/.downloadInProgress (waechst) /models/models--org--repo/blobs/ (fertig) Layout gegen den echten llama.cpp-Server ausprobiert, nicht angenommen. Geht auch bei gesplitteten Modellen und zwei Downloads gleichzeitig; Fallback fuer aeltere Layouts ueber alle *.downloadInProgress. Phasen: queued → start → download (%, MB/s, Restzeit) → load ("laedt in die Karte") → ready ("in Karte N geladen", Name + VRAM aus nvidia-smi) bzw. error. Mitgefixt: der Warmup wartete LLM_TIMEOUT_SEC (Default 60 s). Ein Modell mit mehreren GB meldete deshalb "Fehler", waehrend llama-swap weiterlud. Jetzt LLM_WARMUP_TIMEOUT_S (1900 s, ueber llama-swaps healthCheckTimeout). Diagnostic: Knopf "⬇ Downloads" neben "Von HuggingFace aktualisieren" mit Zaehler fuer laufende; "Laden" oeffnet das Fenster direkt. Der Server merkt sich den Stand pro (Box, Modell), ein spaeter geoeffneter Tab sieht laufende Downloads. Antwortet die Box nicht, steht nach 30 s eine Warnung da statt nichts. Compose (KI-Box): llm-adapter bekommt LLM_GPU (Karte fuer die Meldung) und HF_TOKEN (Dateiliste gesperrter Repos). Test: Fortschritt gegen einen echten llama.cpp-Download (Qwen2.5-0.5B Q8, 676 MB): Prozent steigend 0 → 91.6, dann load; zweiter Lauf aus dem Cache direkt load mit cached=true. Co-Authored-By: Claude Opus 5.5 --- README.md | 1 + diagnostic/index.html | 130 +++++++++++++++++++++++++++++ diagnostic/server.js | 44 +++++++++- rvs/server.js | 7 +- xtts/docker-compose.yml | 5 ++ xtts/llm-adapter/adapter.py | 162 ++++++++++++++++++++++++++++++++++-- 6 files changed, 342 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index c1c9327..760cce0 100644 --- a/README.md +++ b/README.md @@ -544,6 +544,7 @@ Erreichbar unter `http://:3001`. Teilt das Netzwerk mit der Bridge. - `GET /api/chat-backup?lines=N` — letzte N Zeilen aus `chat_backup.jsonl` (Default 200, max 5000) als geparstes JSON. Hilfreich um nachzuvollziehen was ARIA tatsaechlich gemacht hat. - `GET /api/agent-stream?lines=N` — gleiche Mechanik fuer den persistierten Live-Stream (Tool-Calls + Inputs + Outputs). - **OAuth-Callback-Pipeline**: Caddy davor terminiert TLS via Let's Encrypt, RVS hat einen HTTP-Listener auf demselben Port wie der WebSocket. Provider (Spotify/Dropbox/Discord/...) redirecten den User an `https://{RVS_HOST}/oauth/callback/{service}` → RVS broadcastet als `oauth_callback`-WS-Message → aria-bridge forwarded an Brain → Brain matched `state`, tauscht `code` gegen Token, persistiert in `/shared/config/oauth_tokens.json`. Token-Refresh laeuft automatisch. ARIA hat fuenf Brain-Tools: **`oauth_register_provider`** (legt URLs eines neuen Providers wie Dropbox/Discord/Notion/... on-demand in `oauth_apps.json` an — Credentials bleiben Stefans Job), `oauth_authorize`, `oauth_get_token`, **`oauth_call`**, `oauth_revoke` +- **Lokale Modelle laden mit Fortschritt** (Modell-Katalog → „Laden", Knopf **⬇ Downloads**): echte Prozentanzeige mit Tempo und Restzeit, danach „laedt in die Karte" und am Ende „✓ in Karte N (Name) geladen" samt belegtem VRAM. llama.cpp zieht das GGUF per `-hf` selbst und meldet nichts; der llm-adapter fragt deshalb vorab bei Hugging Face, welche Dateien mit welcher Groesse und sha256 kommen, und misst genau diese im HF-Cache-Layout (`/models/models--org--repo/blobs/.downloadInProgress`, nach Abschluss ohne Endung) — klappt auch bei gesplitteten Modellen und parallelen Downloads; liegt es schon im Cache, geht es direkt ans Laden. Der Warmup wartet jetzt bis zu `LLM_WARMUP_TIMEOUT_S` (1900 s) statt 60 s — vorher meldete ein mehrere GB grosses Modell „Fehler", waehrend llama-swap weiterlud. Ein Auftrag, auf den die Box nicht antwortet, erscheint nach 30 s als Warnung statt still zu verschwinden. Pro LLM-Box laeuft **ein** Modell auf ihrer LLM-Karte (`LLM_GPU`), ein anderes zu laden wechselt dorthin. *Wichtig:* `llm_provision_*` fehlte bis hierhin in der RVS-Allow-List — „Laden" hat seit Stage D nie eine Box erreicht - **Sprachmodell**: die Auswahlliste kommt aus **Anthropics eigenem Modell-Katalog** (`downloads.claude.ai/model-catalog/v1/catalog.json`, Surface `cc`) — dieselbe Quelle, aus der sich Claude Code bedient. Oeffentlich, ohne API-Key. Oben die **Tier-Aliase** (opus/sonnet/haiku/fable), die automatisch der neuesten Version folgen; darunter die **exakten Versionen**, aeltere als solche markiert. „↻ Aktualisieren" holt frisch, sonst 6h-Cache mit Datei-Fallback fuer offline. **🔬 Testen** schickt eine echte Mini-Anfrage durch den ganzen Weg und zeigt, welches Modell tatsaechlich geantwortet hat (aus `modelUsage.canonicalModel` der CLI — das Modell selbst zu fragen waere unzuverlaessig). Vier Ergebnisse: Tier aufgeloest (gruen), exakte Version (gruen), **nicht erkannt** (gelb — der Proxy haette still `opus` eingesetzt), ungueltig (rot, mit CLI-Begruendung) - **ARIA E-Mail** (Einstellungen → Integrationen): ARIA liest und sendet Mails ueber IMAP/SMTP (je SSL/TLS, STARTTLS oder unverschluesselt, Zertifikatspruefung abschaltbar fuer eigene Server) — Text, HTML, **Anhaenge** und **eingebettete Bilder** (``), Antworten mit `In-Reply-To`, Ordner anlegen (auch Unterordner) und Mails verschieben. Tools: `email_status`, `email_send`, `email_list`, `email_read`, `email_folders`, `email_folder_create`, `email_move`. Code in [`aria-brain/aria_mail.py`](aria-brain/aria_mail.py). **Whitelist** ist eine harte Grenze im Sendepfad, kein Prompt-Hinweis: alles, was nicht drinsteht, ist gesperrt, leer = ARIA sendet nirgendwohin; geprueft wird jeder Empfaenger (An/Cc/Bcc), ein fremder blockiert die ganze Mail. Eine Schreibweise, damit kein Eintrag mehrdeutig ist: `stefan@hacker-net.de` (genau die), `*@hacker-net.de` (die Domain, NICHT `evilhacker-net.de`, keine Subdomains), `*@*.hacker-net.de` (Subdomains), `*@*` (alles); Kurzformen wie `*hacker-net.de` werden beim Speichern mit Korrekturvorschlag abgelehnt. **Zugangsdaten sieht ARIA nie**: Konfiguration und Passwort liegen im Brain unter `/data` (in ARIAs Container nicht eingehaengt — `/shared` dagegen schon, darum NICHT dort), keine Schnittstelle gibt das Passwort zurueck (nur „gesetzt"), der Brain-Export laesst `email_secret.json` und `email_admin.key` aus. Konfiguration lesen/aendern nur mit Admin-Schluessel (`X-Aria-Admin`, liegt in `/data`), den die Diagnostic anhaengt — Anfragen aus ARIAs Container weist sie ab, sonst koennte eine eingehende Mail ARIA dazu bringen, per curl die Whitelist zu oeffnen. *Grenze:* ARIAs Container hat einen SSH-Schluessel auf die VM; legt sie es gezielt darauf an, kommt sie als root an jede Datei — das hier verhindert, dass Zugangsdaten von selbst irgendwo auftauchen, keinen bewussten Einbruch. Eingehende Mails sind fuer ARIA als **Daten, nicht Anweisungen** markiert. Kopie jeder gesendeten Mail landet in „Gesendet" (fehlt der Ordner, wird er angelegt). **📬 Postfach oeffnen** zeigt ARIAs ganzes Postfach in eigenem Fenster, Unterordner eingerueckt — nur fuer dich zum Reinschauen, markiert nichts als gelesen (sonst wuesste ARIA nicht mehr, was neu ist); Mail-HTML laeuft in einem Rahmen ohne Skripte und ohne Nachladen von aussen (kein Tracking-Pixel), eingebettete Bilder werden mitgeliefert - **Modell pro Chat**: jeder Chat (Hauptchat und jedes Projekt) kann sein eigenes Modell haben, ohne die Einstellung fuer alle umzustellen. Reihenfolge: **Einstellung** (`brainModel`) < **pro Chat** (`/shared/config/context_models.json`, gesetzt per 🧠-Auswahl neben „+ Projekt") < **Ausweich** (Sicherheitsfilter, s.u.). Angezeigt wird immer, was der **naechste Turn wirklich nutzt**: in den Kontext-Karten, in der Auswahl (orange „↪ läuft auf …" plus **„↩ zurück zu …"**, wenn gerade ausgewichen wird) und an jeder ARIA-Bubble — dort das Modell, das tatsaechlich geantwortet hat (aus `modelUsage` der CLI, also die aufgeloeste Version statt des Alias). Als Grundeinstellung zaehlt das Modell, mit dem das Brain **laeuft**, nicht der Dateiwert — ein ausstehender Neustart nach Aenderung von `brainModel` faellt so auf. In der **App** dasselbe hinter der Quell-Anzeige (Einstellungen, Default aus): Modell-Chip in der Kopfzeile, Tippen oeffnet die Auswahl fuer diesen Chat, die Bubbles zeigen das Modell statt nur „Claude" diff --git a/diagnostic/index.html b/diagnostic/index.html index 1c1769b..bbdbde7 100644 --- a/diagnostic/index.html +++ b/diagnostic/index.html @@ -103,6 +103,7 @@ .modal-overlay { display:none; position:fixed; top:0; left:0; right:0; bottom:0; background:rgba(0,0,0,0.85); z-index:1000; justify-content:center; align-items:center; } .modal-overlay.open { display:flex; } + @keyframes llmdlpulse { 0%,100% { opacity:.15; } 50% { opacity:.45; } } .modal-box { background:#0D0D1A; border:1px solid #FFD60A44; border-radius:10px; width:90vw; max-width:860px; max-height:90vh; display:flex; flex-direction:column; overflow:hidden; } .modal-header { display:flex; justify-content:space-between; align-items:center; padding:10px 14px; @@ -843,6 +844,7 @@

Modell-Katalog

+

@@ -1859,6 +1861,25 @@

+ + +