2.7 KiB
Router V2 – Migration und Kompatibilität
Ergebnis
V2 behält die OpenAI-kompatible Basis-URL und die virtuellen Modelle
qwen-fast, qwen-medium und qwen-long. Bestehende Chat-, Tool-, Audio-,
Vision- und Bildpfade bleiben erhalten. Die Änderungen betreffen absichtlich
die Stellen, an denen der alte Router unsicher oder nicht deterministisch war.
Bewusste Änderungen
| Alt | V2 |
|---|---|
| alle LAN-Clients ohne Authentifizierung | API-Key für alle fachlichen Endpunkte |
GET /fast schaltet ein Modell |
nur noch POST /fast (analog medium/long) |
/health hängt am Modellzustand |
/health = Prozess, /ready = Textmodell |
| Profil durch Textvergleich erkannt | Kontext + Alias aus Profilregister geprüft |
| Profilwechsel und Request konnten sich überholen | atomare Modell-Lease |
| Drain-Timeout beendete trotzdem das Modell | Wechsel wird sicher abgebrochen |
| Workerzustand nur im RAM | atomare Zustandsdatei und Startup-Recovery |
| beliebige Bild-URL | Data-URL, Größenlimit; Remote standardmäßig aus |
| unbegrenzte Parallelität und Bildablage | Request- und Retention-Limits |
| Auth-Header potenziell am Upstream | Router-Credentials werden entfernt |
Client-Migration
- Router-Key aus
/etc/mike-ai/router-api-keyohne Anzeige in einen lokalen Secret-Store des Clients übernehmen. - Basis-URL unverändert auf
http://HOST:8081/v1lassen. - Den Key als OpenAI-API-Key/Bearer-Token konfigurieren.
GET /v1/modelstesten und anschließend einen kurzen Chat überqwen-fastsenden.- Automationen, die Profile per GET schalten, auf POST umstellen.
- Überwachung auf
/health(Liveness) und/ready(Readiness) aufteilen.
Sicheres Rollout
V2 wird nicht blind über einen laufenden Router kopiert:
- Repository-Commit und aktuelle produktive Konfiguration sichern.
- Profilregister gegen alle drei systemd-Overrides prüfen.
- API-Key erzeugen und Clients vorbereiten.
- Router installieren und zuerst lokal mit Key prüfen.
- Fast, Medium und Long jeweils einmal schalten und Alias/Kontext prüfen.
- Streaming und einen Tool Call testen.
- Erst danach normale Clients auf V2 freigeben.
Ein Rollback stellt Routerdateien und Unit aus dem Installationsbackup wieder her. Der neu erzeugte API-Key und die Zustandsdatei enthalten keine Modelldateien oder Chatdaten.
Verbleibender Architekturpunkt
Der Routerprozess läuft derzeit als root, weil er den systemweiten llama.cpp- Dienst und temporäre GPU-Worker steuert. Die Unit ist stark gehärtet, dennoch ist das nicht das langfristige Ideal. V3 soll HTTP/API und privilegierte Orchestrierung trennen: unprivilegierter Proxy plus kleiner Root-Helper mit festen, nicht frei parametrisierbaren Aktionen.