llm-adapter:
- Paralleler Download: llama.cpp zieht ueber EINE Verbindung (oft 1-50 MB/s,
auch bei 1 Gbit). Die Box holt fehlende Dateien jetzt vorher selbst in
64-MB-Stuecken ueber LLM_DOWNLOAD_CONNECTIONS (Standard 8) Verbindungen,
prueft die sha256 und legt sie im HF-Cache-Layout ab, das llama.cpp selbst
benutzt (blobs/<sha256>, snapshots/<commit>/<datei>, refs/main). Die Karte
bleibt waehrenddessen beim alten Modell. Scheitert es, laedt llama.cpp wie
bisher selbst. Fortschritt zaehlt bei sparse-Dateien nur geschriebene Bytes.
- Abbrechen: llm_remove_model mit cancel=true (kein neuer Typ → RVS-Allow-List
unveraendert). Waehrend des Downloads: Stopp + halbe Datei weg, Karte
unveraendert. Waehrend llama.cpp laedt: wie ein Fehlschlag → Karte zurueck.
Laeuft nichts mehr, schliesst die Antwort den haengenden Eintrag.
- Loeschen: llm_remove_model mit deleteFiles=true entfernt das Repo aus dem
Cache — nicht, solange es auf einer Karte liegt oder geladen wird.
- worker_hello meldet "disk": freier Platz + heruntergeladene Modelle je Repo.
Diagnostic: Abbrechen-Knopf je laufendem Download; im Katalog "auf ki-box ·
18,6 GB" mit Loeschen-Knopf und eine Zeile mit dem freien Platz je Box.
Getestet gegen HuggingFace (ggml-org/tiny-llamas, 4 Verbindungen, 2-MB-
Stuecke: Layout + Pruefsumme + Abbruch) und Loeschen inkl. Sperren.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
llm-adapter: Vor jeder Aenderung an Registry/Belegung rechnet die Box aus,
was vom Modell noch fehlt (fertige Blobs zaehlen nicht), und vergleicht es
mit dem freien Platz minus Puffer (LLM_DISK_RESERVE_GB, Standard 2). Reicht
es nicht, werden halbe Downloads, an denen seit 30 min niemand schreibt,
geloescht und neu gerechnet; reicht es dann immer noch nicht, bricht das
Laden mit klarer Meldung im Download-Fenster ab ("braucht ca. X GB, frei
sind Y GB"). Frueher brach llama.cpp mitten im Download ab, und der Grund
kam ueber llama-swap nicht an.
Diagnostic: Die MoE-Frage war ein confirm(), bei dem "Abbrechen" "ganz auf
die Karte laden" hiess. Jetzt ein Dialog mit drei Knoepfen: Aufteilen
(empfohlen) / Ganz auf die Karte / Abbrechen (laedt nichts). Esc und Klick
daneben brechen ab.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Statt Suchfeld neben einem normalen Dropdown (Tippen → Liste oeffnen →
passt nicht → zurueck ins Feld) oeffnet ein Klick jetzt eine Liste mit dem
Suchfeld oben. Tippen filtert sofort, Auswahl per Klick oder Pfeiltasten +
Enter, Esc / Klick daneben / Scrollen schliesst. Das versteckte <select>
haelt weiter Wert und onchange (onLlmCardSelect unveraendert).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Modell-Katalog: Suchfeld (erscheint, sobald die Liste geladen ist),
Teilsuche ueber Name, Beschreibung, Repo und Quantisierung; mehrere
Woerter muessen alle vorkommen.
- LLM-Karten: Suchfeld ueber jedem Modell-Dropdown blendet nicht passende
Modelle aus; "— leer —" und das geladene Modell bleiben sichtbar.
- Fix: Ein offenes Karten-Dropdown klappte nach ein paar Sekunden zu, weil
jedes worker_update die Liste neu zeichnete. Solange ein Dropdown oder
Suchfeld darin den Fokus hat, wird das Neuzeichnen aufgeschoben und beim
Verlassen nachgeholt (gilt auch fuer die Ziel-Karte im Katalog).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
29.10., 06:40: Claudes Anmeldung war kurz abgelaufen; die CLI lieferte
"Failed to authenticate: OAuth session expired …" mit is_error=true als
Text. Das Brain hat das als ARIAs Antwort gespeichert (nur der
Sicherheitsfilter wurde bisher abgefangen) — dieselbe Klasse Fehler, die
schon einmal einen Chat vergiftet hat.
Jetzt: is_error ohne Sicherheitsfilter wird wie eine Ausnahme behandelt —
klar markierter [Fehler: …]-Eintrag statt einer scheinbaren Antwort.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude Code liefert in result.result nur den LETZTEN Textblock eines Turns.
Am 28.10. hat ARIA in einem 2-Stunden-Turn ihren Bericht geschrieben, danach
noch auf Laeufe gewartet und mit einer kurzen Notiz geendet — beim Brain kam
nur die Notiz an ("…steht im Bericht oben"), der Bericht war weg.
- Nicht-Streaming: alle Textbloecke des Turns sammeln; laengere fruehere
(>= 300 Zeichen, z.B. Berichte) kommen vor die letzte Antwort. Kurze
Zwischensaetze bleiben weg, <voice> nur aus der letzten Antwort.
- Belegprotokoll speichert jetzt auch Texte (geschwaerzt, max. 20k je
Block), damit so etwas wiederherstellbar ist.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
28.10., 17:51:42: alle Clients verloren gleichzeitig die RVS-Verbindung
(RVS/Proxy kurz weg) — waehrend Gemma 31 s an einer Anfrage von Marina
rechnete. Nach 2 s war alles wieder verbunden, aber die fertige Antwort ging
ueber die tote Verbindung raus und wurde verworfen ("Send fehlgeschlagen
(llm_response)"); Marina wartete bis zu ihrer Frist (660 s) ins Leere.
llm-adapter: llm_response wird ueber die aktuelle Verbindung geschickt, ist
gerade keine offen, aufgehoben (5 min) und nach dem Wiederverbinden
nachgeschickt.
RVS: gezielte Antwort, deren Fragender nur neu verbunden ist (alte
Verbindung weg), geht bis 2 MB an den Raum statt verworfen zu werden — der
Fragende erkennt sie an der requestId. Dateien bleiben gezielt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bei MoE-Modellen (z.B. Qwen3-Coder-30B-A3B: 18,6 GB, davon 16,35 GB
Experten) rechnet pro Wort nur ein kleiner Teil. llama.cpp kann die
Experten in den RAM legen (--cpu-moe / --n-cpu-moe N), der Rest bleibt auf
der Karte.
Adapter:
- Registry-Feld cpuMoe: 0 = Karte, -1 = alle Experten in den RAM,
N = die der ersten N Schichten; -2 beim Laden = automatisch aufteilen.
- Automatisch: liest nur den Kopf der GGUF bei HuggingFace (HTTP-Range,
Tensor-Verzeichnis), rechnet Experten je Schicht + KV-Cache gegen den
VRAM der Karte und legt so viele Experten auf die Karte wie passen
(12 GB/32k: 16 von 48 Schichten auf der Karte, 32 im RAM).
- Kontext-Auswahl: GB-Schaetzung fuer die Karte ohne ausgelagerte Experten;
slot meldet moe, cpuMoe, ramMB. KV-Rechnung als _kv_bytes() geteilt.
Diagnostic: MoE-Modell zu gross fuer die Karte → Rueckfrage "Experten
automatisch aufteilen?"; pro Karte Auswahl Experten: Karte / automatisch /
Arbeitsspeicher. Kontextwechsel rechnet die Aufteilung neu.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Was ARIA selbst im Proxy ausfuehrt (Bash/ssh, Read, Edit …), war nur live
sichtbar — ob sie fuer "auf Prod nachgesehen" wirklich nachgesehen hat (und
wo), liess sich hinterher nicht pruefen. Das Befehlslog gab es nur fuer die
Host-Agenten.
Proxy (proxy-patches/routes.js): start/tool_use/tool_result/end zusaetzlich
dauerhaft nach /shared/logs/aria-tools/<tag>.jsonl (30 Tage), Passwoerter,
Tokens, API-Keys, private Schluessel und Zugangsdaten in URLs geschwaerzt.
Diagnostic: 🔍 an jeder ARIA-Bubble → alle Werkzeug-Aufrufe zwischen Stefans
Frage und dieser Antwort (Befehl + Ausgabe). Hat sie nichts ausgefuehrt,
sagt das Fenster es deutlich (Stand kommt dann aus Verlauf/Gedaechtnis).
GET /api/aria-proof?ts=&project=.
Deploy: proxy --force-recreate (Patch wirkt nur beim Start), diagnostic --build.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Anlass: Im Projekt Software Bude hat ARIA Test- (aria-wohnung) und
Prod-Schmiede (172.0.2.46) verwechselt, richtige Berichte fuer erfunden
erklaert und auf der Testumgebung ein Projekt angelegt. Ihr Wissen dazu lag
ungepinnt und veraltet ("ALTE Testinstanz") im kalten Gedaechtnis.
- Systemprompt: neuer Abschnitt "DEIN GEDAECHTNIS — so pflegst du es":
von sich aus speichern, was nicht live nachsehbar ist; was NICHT rein
gehoert (laufende Staende, eigene ungepruefte Berichte); Schubladen
(tool = Infrastruktur, angepinnt); vor dem Speichern suchen, aktualisieren
statt doppeln, Falsches loeschen; Erinnern != Wissen; jeder Stand-Bericht
nennt Quelle (wo/womit/wann).
- Verzeichnis: Titel + Merkzeile + Datum statt nur Titel; Cold-Treffer mit Datum.
- memory_save: identity/rule/preference/tool/skill werden angepinnt wie
beschrieben (vorher nur mit explizitem pinned=true — Infrastruktur landete
kalt). memory_update kann die Schublade aendern. Neu: memory_delete.
- Destillat: Fakten nur aus dem, was Stefan sagt/entscheidet/bestaetigt;
keine live nachsehbaren Staende (Ticket-Nummern, Status, Commit-IDs).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
32k als Zeichen-Spanne (Text vs. Code, ~2,3 Zeichen je Token bei HTML/JS)
statt pauschal 20–25 Seiten. Neu: in sehr langen Verlaeufen uebersehen
Modelle eher etwas (Mitte) und jede Anfrage wird langsamer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lokal bekam ARIA starr die letzten 8 Nachrichten — alles davor war fuer das
lokale Modell weg. Neu (local_compact.py):
- Fenster nach Tokens: so viele der letzten Nachrichten, wie in ~75 % des
Kontextfensters der Karte passen (Systemprompt + Antwort abgezogen), max.
LOCAL_MAX_TURNS (12). Kontextfenster vom Cluster (Bridge /internal/llm-models).
- Was herausfaellt, fasst das lokale Modell im Hintergrund zum laufenden
Notizzettel zusammen (pro Projekt, /data/local_summaries.json); er geht als
"Bisheriger Verlauf" in den lokalen Systemprompt. Destillat ins Gedaechtnis
laeuft unveraendert weiter. Reset des Gespraechs loescht auch den Zettel.
- Bridge/local_llm: optionale laengere Frist fuer Hintergrund-Aufrufe
(Compacting 180 s statt der 30 s fuer schnelle Antworten).
Diagnostic: Info-Box zum Kontext erklaert Kuerzen / Compacting / Gedaechtnis
und was ARIA davon nutzt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bisher kam context_exceeded als 502 an — OpenAI-Clients (litellm/OpenHands)
hielten das fuer einen Serverfehler statt zu kuerzen/verdichten. Jetzt 400
mit code context_length_exceeded und dem OpenAI-ueblichen Text inkl. Zahlen.
Doku: Abschnitt "Den Verlauf verwaltet das Programm" (Kuerzen, Verdichten,
Gedaechtnis) fuer Drittprogramme.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Modell-Katalog → "🏆 Bestenlisten": Fenster mit laufend gepflegten
Ranglisten nach Kategorie (Allgemein, Programmieren, Bilder erzeugen,
Lokal/Community — Arena, Artificial Analysis, LiveBench, Aider, SWE-bench,
Vellum, r/LocalLLaMA, HF), darunter "Gerade im Trend auf HuggingFace" pro
Kategorie (Allgemein / Programmieren / Bilder verstehen): nur Repos mit
ladbarem GGUF, echte Groesse + Quantisierung, "passt / zu gross" gegen die
groesste LLM-Karte, standardmaessig nur bekannte Anbieter (Trend != gut).
"In Katalog" uebernimmt das Repo; geladen wird wie gewohnt im Katalog.
Server: GET /api/llm-discover (HF trendingScore, 30 min Cache),
POST /api/llm-catalog/add.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Hinter jeder Token-Auswahl bei den LLM-Karten ein kleines i: oeffnet eine
Erklaerung — Arbeitsgedaechtnis pro Anfrage statt Sitzungsgedaechtnis, was
beim Ueberlauf passiert, Bild Schreibtisch/Aktenordner/Archiv, Speicherbedarf.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neben "Auslastung" bei jeder Box ein "📊 Karten"-Button: dasselbe Fenster,
nur fuer diese Box (Titel zeigt den Namen).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
LLM-Karten → "📊 Auslastung": Fenster mit jeder Box und jeder Karte, live
jede Sekunde — Rechenlast, Speicher (belegt/gesamt), Temperatur, Strom,
Verlauf der letzten 2 min und was auf der Karte laeuft (LLM-Modell mit
Kontext, Whisper, F5-TTS, Voxtral).
node_stats (alle GPU-Dienste, identische Kopie) meldet im Live-Stream jetzt
zusaetzlich die Werte PRO Karte (mit uuid). Pro Box streamt bevorzugt der
LLM-Adapter (sieht alle Karten mit echter Nummer); Boxen ohne ihn: jeder
GPU-Dienst seine Karte, Nummer aus worker.gpus. Streams werden erneuert,
solange das Fenster offen ist, und beim Schliessen beendet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Der Adapter liest den Kopf der GGUF-Datei (nur Metadaten): trainiertes
Maximum (context_length) und KV-Cache pro Token — bei Sliding-Window-Modellen
(Gemma) waechst nur der globale Teil mit dem Kontext. Daraus pro Stufe eine
Schaetzung Modell + mmproj + KV (f16) + 1,4 GB Aufschlag (gemessen: Gemma 4
12B @32k geschaetzt 8,8 GB, belegt 8,77 GB).
Diagnostic: Liste kommt von der Box (statt fest 4k..128k), bis zum Maximum
des Modells (auch krumme wie 40960), mit "ca. X GB" und "passt nicht",
wenn es die Karte sprengt. Alte Box ohne Angaben: feste Liste wie bisher.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Statt der nackten Binary haengt release_agent.sh jetzt
aria-host-agent-linux-x64-v<version>.zip an: Binary, install-service.sh,
aria-host-agent.service, .env.example und LIESMICH.txt (Start direkt oder
als systemd-Dienst). Ausfuehrbar-Rechte bleiben beim Entpacken erhalten.
install-service.sh startet den Dienst neu statt nur "enable --now" — so
laedt ein Update die neue Binary auch, wenn der Dienst schon laeuft.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
nssm.cc lieferte 503 → Windows-Build im Release fehlgeschlagen, und das
Skript hat die Ursache verschluckt (>/dev/null). Jetzt: 3 Versuche je Quelle,
Ersatz aus dem Internet Archive, feste SHA-256-Pruefsumme (beide Quellen
liefern dieselbe Datei). release_agent.sh schreibt das Build-Log nach
dist/build-win.log und zeigt bei Fehlern die letzten Zeilen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Hintere Stellen laufen 0..9 und uebertragen nach vorne (0.2.6.9 → 0.2.7.0,
0.2.9.9 → 0.3.0.0), die vorderste zaehlt einfach weiter (9.9.9.9 → 10.0.0.0).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
./release.sh und host-agent/release_agent.sh ohne Argument nehmen die hoechste
Version aus Datei (package.json bzw. build.gradle) und letztem Git-Tag und
zaehlen die letzte Stelle hoch (0.2.6.1 → 0.2.6.2). Mit Argument wie bisher.
Vor dem Bauen: Anzeige alt → neu und Rueckfrage; existiert der Tag schon oder
ist die Version ungueltig, bricht das Skript vorher ab.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Keine neue Version: Meldung mit installierter Version, neuester Version auf
dem Server und ob Update-Server und Download-Weg erreichbar sind (HEAD auf
/update/latest.apk). Keine Verbindung: Meldung mit Server-Adresse, Zustand
und letztem Verbindungsfehler. Keine Antwort in 10 s: Hinweis auf alten RVS.
Neue Version: wie bisher der Update-Dialog (nur einmal, nicht doppelt ueber
den ChatScreen-Listener).
RVS antwortet auf update_check jetzt auch ohne neue Version (update_none
mit latest/current).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Agent fragt beim Verbinden und alle ~6 h per agent_update_check nach; der
RVS antwortet mit agent_update_available, wenn in rvs/updates/agent/ eine
neuere APK liegt (eigener Ordner — die Cockpit-App bekommt sie so nicht
angeboten). Download im Hintergrund per HTTP (/update/agent/latest.apk,
Raum-Token im Header, 3 Versuche, Groessen-Check), dann Benachrichtigung
"Tippen zum Installieren" + Knopf in der App. Installieren per FileProvider
und Android-Installer (REQUEST_INSTALL_PACKAGES; ein Tippen bleibt Pflicht).
host_hello meldet jetzt die Version. release_agent.sh kopiert die APK auf den
RVS, wenn RVS_UPDATE_HOST gesetzt ist.
RVS: APK-Auslieferung als serveApk() fuer beide Apps zusammengefasst.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bisher kam die APK als EINE WebSocket-Nachricht (~65 MB Base64) mit starrem
60-s-Timeout — ueber den externen Proxy (Heim-Upload → Hetzner → Handy) zu
knapp, Abbruch ohne Fortschritt.
RVS: GET/HEAD /update/latest.apk — nur mit gueltigem Raum-Token im Header
X-RVS-Token (sonst 403), Content-Length, Range/206 zum Fortsetzen. Version
im Dateinamen wird ohne angehaengten Punkt erkannt.
App: Download per HTTP (react-native-fs) mit Fortschritt in % und MB,
Abbrechen-Knopf, Abbruch nur bei 30 s ohne Daten statt fester Gesamtzeit,
3 Versuche, Groessen-Check gegen Content-Length. Alter RVS (404): Fallback
auf den WebSocket-Weg mit 5 min Timeout.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
RVS: die ARIA-App wird auch ohne client_hello erkannt, sobald sie eine
Nachricht schickt, die nur sie sendet (app_log mit platform android/ios,
location_update, stt_lease_request, update_download, vnc_open).
Bridge: "Voice-Config geladen" und "Voice-Config gespeichert" schrieben
den huggingfaceToken noch im Klartext ins Log — jetzt ***.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Das NVIDIA-Container-Toolkit ersetzt NVIDIA_VISIBLE_DEVICES im Prozess durch
"void" — whisper/f5tts/voxtral meldeten das als GPU. Die Compose gibt die
Karte jetzt zusaetzlich als ARIA_GPU mit (nur Anzeige).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Einstellungen, zwischen Runtime-Konfiguration und App-Onboarding: alle
Verbindungen im Raum des konfigurierten Tokens — Art, Name, Details,
Adresse, verbunden seit, zuletzt aktiv.
RVS merkt sich pro Verbindung, wer sie ist: aus Nachrichten, die ohnehin
fliessen (sat_hello, host_hello, worker_hello, update_check der App,
llm_cluster_*), oder aus dem neuen client_hello (Bridge, Diagnostic, App
mit Geraetename). Adresse aus X-Forwarded-For hinter einem Reverse-Proxy.
room_clients_query liefert NUR den eigenen Raum; room_clients von Clients
wird nicht weitergereicht. Typen in der Allow-List ergaenzt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mit RVS_HTTP_TLS=true spricht der RVS auf RVS_HTTP_PORT HTTPS/WSS statt
Klartext — damit ist auch die Strecke externer Proxy → RVS verschluesselt.
Das oeffentliche Zertifikat hat der Proxy; hier reicht ein selbstsigniertes,
das beim ersten Start in data/rvs-tls/ erzeugt wird (eigenes darf dort
liegen). Image bekommt dafuer openssl. Nur ohne den Caddy im Stack.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neu in rvs/.env: COMPOSE_PROFILES=caddy (wie bisher, Caddy macht TLS) oder
leer (ohne Caddy). Der RVS bietet dafuer immer einen unverschluesselten Port
an (RVS_HTTP_BIND:RVS_HTTP_PORT, Default 127.0.0.1:3000), auf den ein
vorhandener nginx/Traefik zeigt — statt nginx → Caddy → RVS mit doppeltem TLS.
Caddys HTTPS-Port ist jetzt CADDY_HTTPS_PORT (Default 444 wie bisher).
README: beide Modi, nginx-Vorlage mit WebSocket-Headern und IPv6, Hinweis
dass Caddy fuer die Zertifikats-Erneuerung Port 80 von aussen braucht.
Bestehende Installationen mit Caddy muessen COMPOSE_PROFILES=caddy eintragen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neben dem Zahnrad zeigt ein Schloss, wie sicher die Verbindung zu ARIA ist:
Schloss = verschluesselt und in Ordnung, Schloss mit ! = Zertifikat-Problem
(abgelaufen oder abgelehnt), durchgestrichen = unverschluesselt (TLS-Fallback
oder so eingestellt). Antippen erklaert es in einfachen Worten; einmal pro
App-Start kommt ein Hinweis, wenn das Zertifikat abgelaufen ist.
Einstellungen → Verbindung: "Abgelaufenes Zertifikat akzeptieren". Toleriert
GENAU das Ablaufdatum: die Kette wird zum Zeitpunkt kurz vor dem Ablauf gegen
die System-CAs geprueft, der Hostname weiter von OkHttp. Selbstsignierte oder
fremde Zertifikate kommen auch mit Schalter nicht durch (gegen das echte,
abgelaufene RVS-Zertifikat und badssl.com getestet). Gilt fuer WebSocket und
fetch (z.B. App-Update vom RVS).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Bridge schrieb beim Config-Broadcast den kompletten Payload ins Log,
inklusive huggingfaceToken. Jetzt werden Werte von Schluesseln wie token,
secret, passw, apikey, credential als *** ausgegeben (Zaehler wie maxTokens
bleiben sichtbar). Dasselbe fuer das Debug-Log der RVS-Nachrichten in der
Diagnostic.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Anlass: die Software-Schmiede bekam "request (8274 tokens) exceeds the
available context size (8192 tokens)". Sie holt ctx vom Cluster zwar ab,
kuerzt aber nach einem eigenen, von Hand eingetragenen Wert (32768).
ARIA-Seite:
- Neue Fehlerart context_exceeded (statt model_error) mit promptTokens und ctx
— Programme koennen automatisch kuerzen und nochmal senden, statt Text
auszuwerten. llm-adapter liest es aus llama.cpps exceed_context_size_error,
der Cluster-Router reicht es durch und wiederholt es nicht anderswo.
- Diagnostic → LLM-Karten: Kontextfenster pro Karte (4k … 128k). Laedt das
Modell mit neuem -c; Programme sehen den neuen Wert ueber ctx. Passt es
nicht in den Grafikspeicher, setzt die Box zurueck — jetzt inkl. Registry
(vorher blieb bei einem Fehlschlag der zu grosse ctx in aria_models.json
stehen und waere beim naechsten Start wieder gescheitert).
- Doku: context_exceeded, ctx kann sich aendern, "danach kuerzen, nicht nur
anzeigen".
Getestet gegen llama-swap: Kontext 512 → 1024 (gleiche Karte), Fehlschlag
bei 65536 → Registry + Config wieder 1024, zu langer Verlauf →
context_exceeded mit promptTokens=6030, ctx=1024.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Zwischendurch kam bei Programmen (Software-Schmiede) "model_error: Server
error '500 …'" — nach "nochmal versuchen" lief es weiter. Ursache, auf der
Box nachgestellt: steht im Verlauf ein frueherer Werkzeugaufruf, dessen
arguments kein gueltiges JSON sind (typisch bei Code: Dateiinhalt mit
Anfuehrungszeichen/Umbruechen), lehnt llama.cpp (Stand der Box, Aug. 2026)
die GANZE Anfrage mit 500 ab — und jede weitere mit demselben Verlauf.
Neuere llama.cpp-Versionen nehmen es an.
llm-adapter:
- _sanitize_messages: solche arguments werden als {"_raw": "…"} verpackt,
dict-arguments zu JSON, fehlende zu "{}". Nur Kopien; gueltige bleiben
unangetastet. Auf der Box: kaputt → 500, eingepackt → 200.
- _llama_error_text: bei HTTP-Fehlern kommt der GRUND von llama.cpp mit
(z.B. "request (9017 tokens) exceeds the available context size (8192)")
statt nur "Server error '500'". Volle Antwort ins Box-Log — falls es noch
einen anderen Ausloeser gibt, steht er dort.
Hinweis: ob das der einzige Ausloeser ist, ist offen — die urspruengliche
Fehlerantwort war 4,6 KB gross, diese Ablehnung nur 265 Byte. Mit dem
durchgereichten Grund ist der naechste Fall sofort zu sehen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Zwei Ursachen, beide auf der KI-Box nachgewiesen:
1. llama.cpp fand auch mit Treiber 615 keine Karte ("unsupported display
driver / cuda driver combination"). Das llama-swap-Image traegt in seiner
ld.so.conf die eigene CUDA-Kompatibilitaets-libcuda (575) VOR dem vom
Container-Toolkit eingehaengten Host-Treiber (615) ein. Die Kompatibilitaets-
bibliothek hilft nur Rechenzentrumskarten; bei GeForce scheitert llama.cpp
damit — mit aelterem Treiber ("forward compatibility …") wie mit neuerem —
und rechnet still auf der CPU. Jetzt LD_LIBRARY_PATH mit dem Host-Treiber
zuerst. Auf der Box getestet: llama.cpp sieht CUDA0 + CUDA1. Whisper und
F5-TTS (andere Images) sehen ihre Karte mit 615 ohnehin.
2. Nach dem Reboot erreichte kein Container den RVS ("Temporary failure in name
resolution"). Debian traegt die Netzwerkkarte als allow-hotplug ein; darauf
wartet network-online.target nicht. Docker startete die Container 2 s nach
"online", bevor DHCP den DNS-Server lieferte ("DNS resolver has no external
nameservers"), und die Container behalten diesen leeren Stand. Passiert bei
jedem Reboot. bootstrap.sh legt jetzt ein systemd-Drop-in an: Docker wartet
vor dem Start bis zu 90 s auf einen Nameserver in /etc/resolv.conf, dann
startet es trotzdem. Netzkonfiguration bleibt unangetastet. Escaping und
beide Pfade (DNS da / nicht da) in einer echten systemd-Unit getestet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nach "--upgrade-driver" + Reboot lud der freie nouveau-Treiber statt nvidia,
nvidia-smi fehlte, und Docker startete keinen GPU-Container mehr ("failed to
initialize NVML: Driver Not Loaded"). Zwei Stolperfallen, die in der
apt-Simulation vorher nicht sichtbar waren:
1. NVIDIAs Paket "nvidia-smi" ist nur noch Doku. Das Programm — und
Bibliotheken, die das Container-Toolkit braucht — steckt bei NVIDIA in
"nvidia-driver-cuda". Jetzt in der Paketliste.
2. /etc/modprobe.d/nvidia.conf (sperrt nouveau) war ein Verweis ueber das
Alternativen-System. Die entfernten Altpakete nehmen ihn mit, dpkg legt die
neue Datei nur als nvidia.conf.dpkg-new ab. Jetzt: tote Verweise weg,
.dpkg-new aktivieren (oder eigene Sperre schreiben), initramfs fuer alle
Kernel neu bauen.
nv_postfix laeuft nach der Installation UND, wenn der Treiber schon neu ist —
ein erneuter --upgrade-driver-Lauf repariert also eine Box, die schon in
diesem Zustand steckt. Idempotent; meldet nur Erfolg, wenn das Schreiben
geklappt hat. Getestet gegen den nachgestellten Zustand der Box (erst
Reparatur + Reboot-Hinweis, zweiter Lauf: nichts zu tun).
Dazu: die DKMS-Pruefung las den Kernelnamen als Regex — "6.12.101+deb13"
passte darum nie, die Warnung "nicht gebaut" war falsch. Jetzt -F, und fuer
jeden installierten Kernel (apt hatte nebenbei 6.12.113 mitgebracht, der dann
startete).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1. "Die LLM-Box meldet noch keine Karten": die Box schickte die Karten-
Belegung, aber workerList() im Diagnostic-Server gibt nur eine feste
Feldliste an den Browser — slots stand nicht drauf. Meine UI-Tests haben
die Flotte direkt im Browser gesetzt und sind an genau dieser Stelle
vorbeigelaufen. Jetzt Ende-zu-Ende getestet: echter Diagnostic-Server +
RVS + Box-Meldung → Browser (per DevTools-Protokoll gelesen).
2. Lokales Modell sprang auf "Qwen3 8B" zurueck: die Auswahl wurde gespeichert,
aber die Seite behielt intern das alte Modell und stellte das Dropdown beim
naechsten Lebenszeichen der Box (10 s) darauf zurueck. Dazu wie gewuenscht
umgebaut: nur Modelle, die im Cluster geladen sind, jedes einmal, ohne
Karte. Ist das gewaehlte gerade nirgends geladen: "(offline)" — geht
automatisch weiter, sobald eine Box es hat. Nichts da: "kein Modell
verfuegbar". Waehrend die Auswahl offen ist, wird nicht umgebaut.
3. "Bereit", aber Karte leer: der llm-adapter meldet pro Karte den belegten
VRAM. Laeuft ein Modell "ready" und die Karte bleibt unter 400 MB, rechnet
llama.cpp auf der CPU (Treiber zu alt fuer das CUDA im Image) — das sagt
llama.cpp nicht nach aussen. Diagnostic zeigt es jetzt in Flotte,
LLM-Karten und Modell-Auswahl ("laeuft auf der CPU").
4. bootstrap.sh: der normale Lauf meldete "✓ Treiber aktiv", auch wenn er fuer
das LLM zu alt ist. Jetzt Warnung mit Version und dem Befehl
(--upgrade-driver), wenn das LLM-Profil aktiv ist.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Das lokale LLM rechnete auf der KI-Box die ganze Zeit auf der CPU: Treiber
550 (Debian, auch trixie-backports — mehr gibt es dort nicht) kann CUDA 12.4,
die llama.cpp-/llama-swap-Images brauchen 12.8/12.9. llama.cpp meldet dann
"failed to initialize CUDA … forward compatibility …", findet keine Karte
und laeuft still auf der CPU weiter — "ready" meldet es trotzdem. Whisper und
F5-TTS (CUDA 12.2) waren nicht betroffen.
--upgrade-driver installierte bisher "nvidia-driver" aus den Backports und
meldete Erfolg — es kam aber derselbe 550er. Jetzt: NVIDIAs Paketquelle fuer
Debian 13 (Treiber 615), Upgrade an Ort und Stelle.
Vorher auf der Box simuliert (apt -s in einem Temp-Verzeichnis, nichts
veraendert): ALLE installierten NVIDIA-Pakete mit hochzuziehen scheitert an
Konflikten — NVIDIA hat Debians Teilpakete (nvidia-driver-bin,
nvidia-alternative, …) zusammengefasst. Nur nvidia-driver, nvidia-kernel-dkms,
nvidia-smi, libcuda1 (+ persistenced/modprobe, wenn installiert) anfordern →
apt loest es sauber: 30 aktualisiert, 8 neu, 10 Altpakete entfernt,
Container-Toolkit unberuehrt.
Sicherungen: spielt erst durch (apt -s); bricht OHNE Aenderung ab und nimmt
die Paketquelle wieder raus, wenn apt keinen Weg findet oder das
Container-Toolkit anfassen wuerde. Zeigt den Plan und fragt nach (--yes zum
Ueberspringen). Prueft danach Version und DKMS-Build. Ablauf in einem
frischen Debian-13-Container getestet (Installation abgefangen).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Programme sollen nicht Box und Karte aussuchen muessen. Die ARIA-Bridge kennt
alle Boxen samt Karten-Belegung und verteilt (bridge/llm_cluster.py):
- Auswahl: unter allen online Boxen mit dem Modell die mit den wenigsten
laufenden Anfragen, bei Gleichstand reihum. Eine Karte / alles frei →
alles dorthin ("verteilen, wenn noetig").
- Ausfall: geht eine Box waehrend der Anfrage offline (kein Ping mehr), wird
sie EINMAL an eine andere Box mit demselben Modell gegeben. Modell-Fehler
(z.B. Kontext zu lang) werden nicht wiederholt — waeren ueberall gleich.
- Fehler kommen als Fehler (ok=false + errorCode), nie als Antwort-Text: ein
Programm wuerde ihn sonst als Aussage der KI in seinen Verlauf schreiben —
so ist bei ARIA schon mal ein ganzer Chat kaputtgegangen.
RVS: llm_cluster_models_request → llm_cluster_models (jedes Modell EINMAL,
ctx = kleinstes Kontextfenster unter seinen Karten), llm_cluster_request →
llm_cluster_response. In der RVS-Allow-List freigegeben.
ARIA nutzt denselben Router (mit ihrer 30-s-Frist fuer den lokalen
Schnellweg) — vorher Round-Robin ohne Ausfall-Ersatz, und errorCode ging
verloren.
xtts/openai_rvs_wrapper: fuer Programme, die nur "OpenAI-kompatibel" koennen
(OpenHands & Co.). Kleiner Container NEBEN dem Programm, fuer das der Cluster
dann http://127.0.0.1:8099/v1 ist; braucht nur eine ausgehende Verbindung zum
RVS. /v1/models (jedes Modell einmal, context_length), /v1/chat/completions
(auch stream und tools), Fehler als HTTP mit OpenAI-Fehlerobjekt. Hilfsseite
auf / zeigt Status, Base URL und Modelle. Fuer Programme in Docker: Netz
aria-llm, Name openai-rvs-wrapper. .env.example mit RVS_HOST/PORT/TOKEN.
(Ein OpenAI-Endpunkt direkt auf der VM war kurz drin und ist wieder raus —
der Wrapper braucht keinen offenen Port auf der VM.)
docs/LLM-SCHNITTSTELLE.md neu gegliedert: A) Cluster ueber RVS (empfohlen),
B) Wrapper, C) direkt an eine Box (Sonderfall), plus "Umstellen" fuer
bestehende Clients (Software-Schmiede).
Tests: mit echtem RVS und zwei echten llm-adaptern als zwei Boxen —
Modell einmal gelistet, 6 parallele Anfragen 3/3 verteilt, Box friert
mitten in der Anfrage ein → nach 15 s von der anderen beantwortet
(attempts=2), danach direkt die gesunde, nicht geladenes Modell →
model_unavailable ohne content. Wrapper als Docker-Container gegen das
offizielle OpenAI-SDK: models.list, create mit/ohne stream, NotFoundError,
AuthenticationError. Das Doku-Beispiel lief unveraendert (nur Adresse).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
duffyduckandClaude Opus 5.5