Der Endpointer hat seine EIGENE Rechenzeit als Stille gezaehlt.
Der Tick-Loop laeuft alle 200ms und ist die einzige Stelle, die akustische
Sprach-Energie misst (last_voice_at). Er hat aber auf die Zwischen-
Transkription gewartet — und die laeuft jedes Mal ueber den KOMPLETTEN Buffer.
Bei 10s Audio harmlos, bei zwei Minuten dauert sie mehrere Sekunden. In dieser
Zeit tickte nichts, danach war `now - last_voice_at` um die ganze Rechenzeit
groesser als endpoint_ms (5s) — Endpoint mitten im Satz, obwohl durchgehend
gesprochen wurde. Deshalb traf es genau die LANGEN Nachrichten, und zwar immer
spaeter werdend je laenger die Aufnahme.
Nachgewiesen: die Nachricht vom 02.10. 21:28 (1231 Zeichen) war die einzige mit
reason=endpoint statt stream_end und endet mitten im Satz ("...weil ich
weiss..."). Alle vollstaendigen Nachrichten im Thread haben reason=stream_end,
also den Stop-Knopf.
Fix:
- Zwischen-Transkription laeuft als eigener Task. Der Tick bleibt frei und
misst weiter alle 200ms — die Rechenzeit kann nicht mehr als Stille gelten.
Laeuft noch eine, wird keine zweite gestartet.
- Zwischen-Transkriptionen sehen nur noch die letzten 30s an. Damit bleibt ihre
Kosten konstant statt mit der Aufnahmelaenge zu wachsen. Der FINALE Text
entsteht unveraendert aus dem gesamten Buffer mit beam_size=5 — es geht kein
Wort verloren. stt_partial bekommt dafuer ein Feld 'windowed'.
- _finalize und drop brechen eine laufende Zwischen-Transkription ab, damit der
finale Text nicht hinter ihr auf den GPU-Lock warten muss.
Co-Authored-By: Claude Opus 5 (1M context) <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.