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>
2.1 KiB
2.1 KiB
OpenAI-RVS-Wrapper
Macht den ARIA-LLM-Cluster für Programme, die nur „OpenAI-kompatibel" können (OpenHands, Continue, Open WebUI …), zu einem ganz normalen OpenAI-Endpunkt auf diesem Rechner:
Programm ──HTTP──▶ Wrapper (127.0.0.1:8099) ──RVS──▶ ARIA-Bridge ──▶ KI-Box / Karte
Der Wrapper braucht nur eine ausgehende Verbindung zum RVS. Das Programm kann also stehen, wo es will — keine Portfreigabe, kein VPN.
Einrichten
cp .env.example .env # RVS_HOST, RVS_PORT, RVS_TOKEN eintragen
docker compose up -d --build
Dann im Browser http://127.0.0.1:8099/ öffnen. Die Hilfsseite zeigt, ob die Verbindung steht, welche Modelle es gibt und was man einträgt.
Im Programm eintragen
| Feld | Wert |
|---|---|
| Base URL | http://127.0.0.1:8099/v1 |
| API-Key | beliebig — oder WRAPPER_API_KEY, falls gesetzt |
| Modell | ein Name von der Hilfsseite, z.B. qwen3-8b |
| Kontextfenster | der Wert von der Hilfsseite (nicht mehr eintragen, die Box gibt nur so viel her) |
Läuft das Programm selbst in Docker, ist 127.0.0.1 dort der eigene
Container. Dann das Netz aria-llm anhängen und http://openai-rvs-wrapper:8099/v1
nehmen:
services:
openhands:
# …
networks: [default, aria-llm]
networks:
aria-llm:
external: true
Was der Cluster dahinter macht
- Jedes Modell steht in der Liste einmal, egal auf wie vielen Karten es liegt.
- Liegt es auf mehreren Karten, verteilt der Cluster bei Last. Fällt eine Box mitten in der Anfrage aus, übernimmt eine andere mit demselben Modell.
- Welche Modelle es gibt, legt nur die ARIA-Diagnostic fest (Einstellungen → LLM-Karten). Ein Programm kann nichts laden oder entladen.
- Fehler (Modell nicht geladen, Cluster nicht erreichbar) kommen als HTTP-Fehler mit OpenAI-Fehlerobjekt, nie als normale Antwort.
stream: truegeht; die Antwort kommt derzeit in einem Rutsch statt Wort für Wort.
Endpunkte: GET /v1/models, POST /v1/chat/completions, GET /health, GET / (Hilfsseite).
Die Schnittstelle dahinter: docs/LLM-SCHNITTSTELLE.md.