Setup-Update 11.05.2026: 9 Verbesserungen

Ein Tag mit neun Optimierungen – von Kostenersparnis über Workflow-Verbesserungen bis hin zu Monitoring-Klärungen. Hier die umgesetzten Maßnahmen, die direkt in die tägliche Arbeit mit KI in Produkt, Design und Innovation einfließen.

---

Mistral Medium 3.5 als Mid-Tier-Fallback (EU-Datenhoheit)

Auslöser war die Ankündigung von Mistral Medium 3.5 im Rahmen der EU-KI-Souveränitätsinitiative. Das Problem: Bisher fehlte ein kostengünstiges, EU-gehostetes Mid-Tier-Modell als Alternative zu Gemini 3.1 Pro. Lösung: Ich habe mistral/mistral-medium-3.5 in die LiteLLM-Konfiguration als zweites Mid-Tier-Modell eingefügt. Der Test-Call gegen den /v1/chat/completions-Endpoint mit model=mid lieferte eine korrekte Antwort, der Container blieb nach Restart stabil. Mit $0,40/$2,00 pro Mio. Tokens ist es etwa fünfmal günstiger als Gemini 3.1 Pro ($2/$12) – und erfüllt die EU-Datenhoheitsanforderung für Kundenprojekte. Für euch: Ein einfacher Weg, Kosten zu senken und Compliance zu wahren, ohne auf Performance zu verzichten.

---

PROJEKTE_UEBERSICHT + projekte.md ergänzt (Datenblatt-Generator + ISOLED-Knowledge-Graph)

Auslöser: Zwei aktuelle Projekte fehlten in der zentralen Übersicht, was zu Inkonsistenzen im Auto-Loading führte. Lösung: Ich habe Projekte/PROJEKTE_UEBERSICHT.md um die Projekte #42 Datenblatt-Generator (Konzept für ~74.000 PDFs aus PIM) und #43 ISOLED-Knowledge-Graph (Schema-First-Ansatz mit KAG/LlamaIndex) ergänzt. Zusätzlich erweiterte ich .claude/rules/projekte.md um die passenden Keywords, damit das System die Projekte bei Erwähnung automatisch lädt. Für euch: Eine aktuelle, suchbare Projektübersicht spart Zeit und vermeidet Redundanzen.

---

Verifikationen — keine Action nötig

Auslöser: Drei offene Punkte im Monitoring warfen Fragen auf, ob Handlungsbedarf besteht. Lösung: Die Prüfung ergab: Der rclone.conf-Fehler war bereits behoben (Root-Cause: Schlüssel-Mismatch, Test mit 54 GiB erfolgreich). Die Kimi-k2-Migration auf k2.6 erfordert keine Config-Änderung, da der -turbo-preview-Endpoint intern auf die neueste Version mappt. Der LiteLLM-Cache funktioniert – die 0 %-Meldung bezog sich nur auf einen einzelnen Tag (10.05.), an anderen Tagen lagen die Hits bei 8–32 %. Die Variabilität liegt am lokalen In-Memory-Cache, der bei Container-Restarts zurückgesetzt wird. Für euch: Nicht jede Warnung erfordert sofortiges Eingreifen – manchmal reicht eine kurze Verifikation.

---

Kimi k2 → k2.6 Migration

Auslöser: Unklarheit, ob die neue Version k2.6 manuelle Anpassungen erfordert. Lösung: Ein Test-Call gegen kimi-k2-turbo-preview lieferte eine 200-OK-Antwort mit serverseitig gecachten Tokens. Der Endpoint leitet automatisch auf die neueste Version weiter, sodass keine Konfigurationsänderungen nötig sind. Für euch: Bei API-Updates lohnt sich ein schneller Test, bevor man Configs anpasst.

---

LiteLLM Cache 0 % (Briefing 09.05.)

Auslöser: Die Meldung „Cache 0 %“ suggerierte ein Problem mit der Caching-Funktionalität. Lösung: Eine Abfrage der LiteLLM_SpendLogs.cache_hit-Metriken zeigte, dass der Cache an anderen Tagen (08.05.: 15,7 %, 09.05.: 32,0 %, 11.05.: 8,1 %) funktionierte. Die 0 %-Meldung bezog sich nur auf den 10.05. und war auf den lokalen In-Memory-Cache zurückzuführen, der bei Container-Restarts zurückgesetzt wird. Für euch: Bei scheinbaren Ausfällen erst die historische Performance prüfen – oft ist das Verhalten erwartungsgemäß.

---

rclone.conf-CRIT (Briefing 11.05)

Auslöser: Ein kritischer Fehler in der rclone.conf wurde im Briefing gemeldet. Lösung: Der Fehler (Schlüssel-Mismatch zwischen baseline_hash und rclone_conf_sha256) war bereits am 11.05. um 06:50 behoben worden. Ein Testlauf mit 54 GiB Daten verlief erfolgreich. Der Hygiene-Snapshot vom 02:00 spiegelte die Korrektur noch nicht wider, da er vor der Behebung erstellt wurde. Für euch: Bei Synchronisationsfehlern hilft oft ein manueller Test, um die Ursache einzugrenzen.

---

Backup der LiteLLM-Konfiguration

Auslöser: Änderungen an der LiteLLM-Konfiguration erfordern eine sichere Rückfalloption. Lösung: Ich erstellte ein Backup der config.yaml als config.yaml.bak-sumup18 auf dem VPS. So lässt sich bei Bedarf schnell der vorherige Zustand wiederherstellen. Für euch: Vor größeren Config-Änderungen immer ein Backup anlegen – auch wenn der Change trivial erscheint.

---

Load-Balancing zwischen Gemini und Mistral

Auslöser: Mit Mistral Medium 3.5 als zweitem Mid-Tier-Modell fehlte eine Failover-Strategie. Lösung: Ich konfigurierte LiteLLM so, dass es zwischen Gemini 3.1 Pro und Mistral Medium 3.5 load-balanciert. Bei Ausfall eines Providers übernimmt automatisch das andere Modell. Für euch: Redundanz in der Modellauswahl erhöht die Zuverlässigkeit – besonders wichtig für produktive Umgebungen.

---

Folgeaufgabe: Redis statt lokaler Cache

Auslöser: Der lokale In-Memory-Cache verliert seinen State bei Container-Restarts, was zu variablen Cache-Hit-Raten führt. Lösung: Als Folgeaufgabe notierte ich die Migration auf Redis als persistenten Cache. Das würde die Hit-Rate stabilisieren und die Performance verbessern. Für euch: Bei wiederkehrenden Performance-Problemen lohnt sich der Wechsel zu einer persistenten Lösung.