Die häufigste Sorge, die wir im Erstgespräch hören: «Und wer macht die Updates? Was passiert, wenn ein neues Modell kommt? Und wenn etwas kaputtgeht?» Das sind die richtigen Fragen – und die Antwort ist: lokale KI ist nicht wartungsfrei, aber sie ist auch nicht wartungsintensiv.
Im Folgenden erklären wir, was genau aktualisiert wird, wie oft, wer es macht, und was ein realistisches Wartungsmodell für Ihr Unternehmen aussieht. Am Ende wissen Sie, wofür Sie bei LokaleKI zahlen – und was Sie selbst (oder Ihre IT) in der Hand haben.
Was aktualisiert wird – die vier Ebenen
Eine lokale KI besteht aus vier Schichten, die jeweils eigene Updates haben:
| Schicht | Was sich ändert | Typische Frequenz | Wer es macht |
|---|---|---|---|
| Modell (7B/14B/70B) | Neue Modell-Generation (Llama, Qwen, Mistral) | alle 2–6 Monate (nur, wenn es eine spürbare Verbesserung bringt) | LokaleKI (empfohlen) oder eigene IT |
| Ollama / Runtime | Sicherheitspatches, neue Features, Performance | monatlich | LokaleKI (im Wartungsvertrag) |
| Open WebUI / Frontend | Sicherheitspatches, neue Funktionen, Bugfixes | monatlich | LokaleKI (im Wartungsvertrag) |
| RAG / Vektor-Index | Neue Dokumente, Korpus-Änderungen, Re-Index | nach Bedarf | LokaleKI oder eigene IT (Upload) |
Der wichtigste Punkt: Die häufigsten Updates sind Sicherheitspatches für Ollama, Open WebUI und das Betriebssystem. Die kommen monatlich und sind in der Regel 30–60 Minuten Arbeit pro Lauf. Modelle werden nicht «automatisch» aktualisiert – das passiert bewusst, wenn eine neue Version nachweislich besser ist und Sie es wollen.
Wie oft – das realistische Zeitbild
Hier die typische Wartungsrhythmik, wie wir sie bei unseren Kunden einrichten:
- Monatlich (automatisiert): Sicherheitspatches für Ollama, Open WebUI, GPU-Treiber, OS. Läuft im Wartungsfenster (z.B. Samstag, 2–4 Uhr), ohne dass Ihre Mitarbeiter es mitbekommen. Dauer: 30–90 Minuten.
- Quartalsweise (manuell): Modell-Review. Wir prüfen, ob die nächste Modell-Generation (z.B. Llama-4, Qwen-3) für Ihre Anwendung eine spürbare Verbesserung bringt. Wenn ja: staged Rollout – zuerst auf der Testinstanz, dann auf der Produktivinstanz, mit Fallback zum alten Modell.
- Nach Bedarf (reaktiv): RAG-Re-Index, wenn sich Ihr Korpus deutlich verändert (neue Abteilung, neuer Prozess, gewachsener Vertragsbestand). Dauer: 1–4 Stunden je nach Korpusgröße.
- Laufend (Monitoring): Wir überwachen Uptime, VRAM-Auslastung, Antwort-Latenz, Fehler-Logs. Wenn etwas kippt, bekommen Sie eine Benachrichtigung – Sie müssen nicht selbst nachschauen.
Das ist nicht «wartungsfrei», aber auch nicht «wartungsintensiv»: Im Tagesgeschäft merken Ihre Mitarbeiter nichts. Die Wartung läuft im Hintergrund, im Wartungsfenster, mit Benachrichtigung, wenn etwas auffällt.
Modelle: wie ein Update läuft (ohne dass Sie Angst haben müssen)
Die häufigste Angst: «Was passiert, wenn das neue Modell schlechter ist als das alte?» Die Antwort: Nichts. Wir machen Modell-Upgrades immer staged:
- 1. Testphase (1–2 Wochen): Das neue Modell wird auf einer parallelen Instanz eingespielt. Ihre Mitarbeiter arbeiten mit dem alten Modell weiter.
- 2. Vergleich: Wir laufen beide Modelle mit Ihren realen Anwendungsfällen, messen Qualität, Latenz, VRAM-Bedarf. Sie bekommen einen Vergleichsreport.
- 3. Entscheidung: Sie entscheiden, ob Sie wechseln. Wenn das neue Modell besser ist: Cutover über ein Wochenende. Das alte Modell bleibt als Fallback auf der Festplatte – keine Neuinstallation.
- 4. Fallback: Wenn das neue Modell Probleme macht, schalten wir in Minuten auf das alte Modell zurück. Kein Datenverlust, keine Uminstallation.
Das Modell ist Ihre Datei auf Ihrer Festplatte. Sie können jederzeit zwischen mehreren Modellen wechseln, ohne dass etwas umgebaut werden muss. Genau das ist der Vorteil eines lokalen Setups gegenüber einer Cloud-API, bei der der Anbieter den Modellwechsel vornimmt und Sie keinen Fallback haben.
Monitoring: was wir überwachen, und warum das wichtig ist
Eine lokale KI ist ein Server – und Server müssen überwacht werden. Unser Monitoring deckt:
- Uptime: Läuft Ollama? Ist Open WebUI erreichbar? Ist die GPU nicht in einen Fehlerzustand gegangen?
- VRAM-Auslastung: Wie voll ist der Speicher? Wenn er über 80 % belegt ist, sind die Kontextfenster knapp – wir bekommen es, bevor Ihre Mitarbeiter es spüren.
- Antwort-Latenz: Wie schnell sind die Antworten im Durchschnitt? Wenn die Latenz steigt (mehr gleichzeitige User), bekommen Sie eine Warnung.
- Fehler-Logs: Wenn Ollama oder Open WebUI einen Fehler meldet, bekommen wir es in Echtzeit – nicht erst, wenn ein Mitarbeiter es meldet.
- Temperatur: Bei der DGX Spark und der 5090 überwachen wir die GPU-Temperatur. Wenn sie über 80 °C geht, ist die Kühlung im Blick.
Das Dashboard sehen Sie und wir. Sie bekommen eine wöchentliche Zusammenfassung (Uptime, Anfragen, Top-Fragen) und eine Benachrichtigung bei Auffälligkeiten. Sie müssen nie selbst auf einen Server schauen, um zu wissen, ob alles läuft.
Was Sie selbst (oder Ihre IT) machen – und was nicht
Ihre Rolle (oder die Ihrer IT) im Wartungsmodell:
- Zugangsverwaltung: Wenn ein Mitarbeiter eintritt oder austritt, wird sein Open-WebUI-Account aktiviert/deaktiviert. Das kann Ihre IT selbst machen (2 Minuten) – oder wir übernehmen es im Wartungsvertrag.
- Neue Dokumente: Sie (oder Ihre Abteilung) laden neue Dokumente in den RAG-Korpus hoch. Wir übernehmen das Re-Index im Wartungsvertrag.
- Netzwerk & Firewall: Änderungen am Netzwerk (z.B. neue Abteilung, VLAN-Änderung) – das ist Ihr IT-Team, wir koordinieren.
Was Sie NICHT machen: Modell-Upgrades, Ollama-Patches, RAG-Re-Index, GPU-Treiber-Updates, Monitoring, Fehlerdiagnose. Das ist unser Job. Der Wartungsvertrag deckt genau das ab – zu festen, vorhersehbaren Konditionen (ca. 100–200 €/Monat), ohne dass Sie jedes Mal «mal schnell schauen» müssen.