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>
xtts — AI-Box (Compute-Node) Setup & Bootstrap
Der xtts-Stack sind ARIAs GPU-Dienste (STT: Voxtral/Whisper · TTS: F5-TTS ·
lokales LLM). Er läuft auf einer oder mehreren AI-Boxen — jede per .env
konfiguriert (COMPOSE_PROFILES, GPU-Zuordnung). Details zu Profilen/GPU-Wahl
stehen im Haupt-README (Abschnitt „Compute-Nodes").
bootstrap.sh macht aus einem frisch installierten Debian Trixie (headless,
nur SSH) einen startklaren GPU-Host für diesen Stack.
Was das Script tut
- Basis-Pakete (curl, gnupg, git …)
contrib non-free non-free-firmwareaktivieren (Trixie-deb822-Format berücksichtigt)- NVIDIA-Treiber installieren (
nvidia-driver+ firmware) - Docker Engine + Compose-Plugin
- NVIDIA Container Toolkit + Docker-Runtime auf NVIDIA konfigurieren
xtts/.envaus.env.exampleanlegen (RVS_TOKEN optional gleich setzen)- GPU-im-Container-Test (
docker run --gpus all … nvidia-smi) - optional (
--up): denxtts-Stack hochziehen
Alles idempotent — mehrfach ausführbar.
Ablauf
git clone <repo> ARIA-AGENT
cd ARIA-AGENT/xtts
sudo ./bootstrap.sh
# → Wenn der Treiber frisch installiert wurde: einmal neu starten, dann nochmal:
sudo reboot
# … nach dem Boot:
cd ARIA-AGENT/xtts
sudo ./bootstrap.sh --up --token <DEIN_RVS_TOKEN>
Der Treiber-Reboot ist normal (Kernel-Modul wird erst beim Boot geladen). Beim zweiten Lauf überspringt das Script alles Erledigte und macht nur noch den GPU-Test + Stack-Start.
Optionen
| Option | Wirkung |
|---|---|
--up |
am Ende docker compose up -d --build (Default-Profil) |
--token <TOK> |
RVS_TOKEN in xtts/.env eintragen (auch via RVS_TOKEN=… env) |
--rvs-host <H> |
RVS_HOST setzen |
Wichtig
- Stimm-Daten (nicht in git): falls von der alten Box noch vorhanden,
xtts/voice-id/(Speaker-Fingerprint) +xtts/voices/(F5-Referenz) herkopieren. Sonst egal — in der App neu anlegen: Stimme neu enrollen (ohne Fingerprint läuft die Speaker-ID fail-open, alles geht durch) + F5-Voice-Referenz neu hochladen. - Voxtral bleibt aus auf der 3060 (braucht ≥16 GB VRAM). Das Default-Profil
fährt Whisper (mit dem M0.1-Fix) + F5-TTS + lokales LLM. Voxtral erst mit der
24-GB-Karte:
docker compose stop whisper-bridge && docker compose --profile voxtral up -d --build. - Erster Start lädt Modelle (mehrere GB via HuggingFace nach
xtts/hf-cachextts/models) — genug Platz (1 TB NVMe ✓) und etwas Geduld.
- Box im selben Netz wie der RVS (z.B. Rechenzentrum, direkt auf die interne
IP statt NAT-Hairpin): in
xtts/.envRVS_HOST=<interne-ip>+RVS_SNI=<zert-name>(Name, für den das Caddy-Zert gilt). Ohne das scheitert TLS antlsv1 alert internal error. Zuhause / normal:RVS_SNIleer lassen.
Verifizieren
nvidia-smi # Host sieht die GPU
docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi # Container auch
docker logs -f aria-whisper-bridge # "RVS verbunden" + service_status ready
Lokales LLM von außen nutzen (OpenAI-Endpunkt)
llama-swap spricht OpenAI-kompatibel (/v1/chat/completions, /v1/models).
Damit können Fremd-Tools direkt auf das lokale Modell: OpenHands, Continue,
Open WebUI, Aider …
Base-URL: http://<box>:<LLM_OPENAI_PORT>/v1
Modell: qwen3-8b (oder ein anderer Key aus llama-swap/config.yaml)
API-Key: LLM_OPENAI_KEY (falls gesetzt)
In der .env:
| Variable | Bedeutung |
|---|---|
LLM_OPENAI_BIND |
127.0.0.1 = nur diese Maschine (Default, sicher) · 0.0.0.0 = ganzes LAN |
LLM_OPENAI_PORT |
Host-Port (Default 8081) |
LLM_OPENAI_KEY |
API-Key; leer = ohne Authentifizierung |
⚠️
LLM_OPENAI_BIND=0.0.0.0ohneLLM_OPENAI_KEYheißt: jeder im Netz kann das Modell benutzen. Entweder Key setzen oder auf localhost gebunden lassen.
Wo wird was konfiguriert?
- Port und Erreichbarkeit immer in der
.env. Beides ist ein Docker-Port-Mapping und steht beim Container-Start fest — es lässt sich nicht aus der Ferne ändern. - API-Key: entweder in der
.envoder — wenn dort leer — in der ARIA-Diagnostic unter Compute-Flotte bei der jeweiligen Box. Dort abgelegt landet er auf der Box unter/models/openai_key.json(Rechte 0600). - Die
.envhat immer Vorrang. StehtLLM_OPENAI_KEYdort, ist das Feld in der Diagnostic schreibgeschützt (🔒-Hinweis). - Ein geänderter Key greift, sobald ein Modell das nächste Mal geladen wird
(llama-server bekommt ihn per
--api-key). Laufendes Modell also einmal entladen lassen (TTL) oder ein anderes Modell anfragen.
Prüfen:
curl -s http://localhost:8081/v1/models # ohne Key
curl -s -H "Authorization: Bearer $LLM_OPENAI_KEY" \
http://localhost:8081/v1/models # mit Key
OpenHands (optionales Profil)
OpenHands ist rein optional und liegt in einem eigenen Profil. Wer es nicht in
COMPOSE_PROFILES aufführt, bei dem wird der Container gar nicht erst angelegt —
das Image wird nicht einmal geladen. Für den normalen ARIA-Betrieb also einfach weglassen:
COMPOSE_PROFILES=voxtral,f5tts,llm docker compose up -d # ohne OpenHands
COMPOSE_PROFILES=llm,openhands docker compose up -d # mit OpenHands
Dann http://<box>:<OPENHANDS_PORT> (Default 3000) öffnen. Das lokale Modell ist
schon vorbelegt (OPENHANDS_LLM_BASE_URL, OPENHANDS_LLM_MODEL) und in der
Oberfläche änderbar.
| Variable | Bedeutung |
|---|---|
OPENHANDS_BIND |
127.0.0.1 (Default) oder 0.0.0.0 fürs LAN |
OPENHANDS_PORT |
Host-Port (Default 3000) |
OPENHANDS_LLM_BASE_URL |
Default http://llama-swap:8080/v1 (Container-intern — nicht der Host-Port) |
OPENHANDS_LLM_MODEL |
Default openai/qwen3-8b |
⚠️ OpenHands startet eigene Arbeits-Container und bekommt dafür den Docker-Socket. Das ist faktisch Root-Zugriff auf diese Maschine — wer die Oberfläche erreicht, kann im Zweifel alles auf der Box.
Deshalb bleibt
OPENHANDS_BINDauf127.0.0.1. Von einem anderen Rechner greifst Du per SSH-Tunnel zu, statt den Port ins LAN zu öffnen:ssh -L 3000:127.0.0.1:3000 user@box # dann lokal http://localhost:3000Das kostet nichts und ist die wirksamste Absicherung, solange der Socket durchgereicht wird. Wer echte Isolation braucht: OpenHands in eine eigene VM, oder einen rootless Docker-Daemon als Beiwagen statt des Host-Sockets.
Ohne das Profil ändert sich nichts: Wer nur ARIAs Box fahren will, startet OpenHands gar nicht.