KI auf dem eigenen Server 2025/2026: von Ollama-Experimenten zu produktiven Workloads

Vor anderthalb Jahren waren lokale Sprachmodelle bei den meisten unserer Kunden ein Wohnzimmer- oder Laborthema: Interessant, beeindruckend, aber ohne Betriebsrelevanz. In den anderthalb Jahren seither hat sich das gedreht. Die Anfragen haben sich verschoben von „kann man das mal ausprobieren“ zu „wir wollen Anfragen aus dem internen Netzwerk bedienen, ohne dass etwas das Haus verlässt“. Dieser Beitrag fasst zusammen, was den Unterschied zwischen einem Experiment und einem produktiven Workload ausmacht.

Warum der Schritt überhaupt passiert

Zwei Entwicklungen haben zusammengefunden. Erstens ist die Werkzeugkette gereift: Mit Ollama hat ein einzelnes Open-Source-Projekt den Einstieg drastisch vereinfacht, und für Durchsatzanforderungen gibt es Serving-Stacks im vLLM-Stil, die Modelle effizient mehrfach gleichzeitig bedienen können. Zweitens ist der Druck von der Compliance-Seite gekommen. Die NIS2-Umsetzung in Deutschland macht dokumentiertes Risikomanagement zur Pflicht, und in genau diesem Rahmen fällt die Bewertung von Cloud-APIs anders aus als noch 2024: Wer sensible Daten verarbeitet, muss nachvollziehen können, wohin sie fließen. Ein Modell auf dem eigenen Server ist dann nicht das nostalgische, sondern das einfache Argument.

Was ein produktiver Betrieb braucht

Der Sprung vom Experiment zum Betrieb ist kein Sprung in der Modellqualität, sondern in den Randbedingungen:

• Speicher und Hardware: Modelldateien gehen von wenigen Gigabyte bis in den zweistelligen Gigabyte-Bereich, die offizielle Ollama-Dokumentation rechnet mit „tens to hundreds of GB“ für die Modellablage. GPU-Beschleunigung setzt konkrete Treiber- und Hardwarevoraussetzungen; wer ohne dedizierten Grafikprozessor plant, muss mit spürbar langsameren Antwortzeiten rechnen. Die Hardwarefrage gehört vor die Softwarefrage, nicht danach.

• Isolation und Zugriffssteuerung: Ein Inferenzdienst, der im lokalen Netzwerk lauscht, ist ein regulärer Dienst mit regulärer Angriffsfläche. Dazu gehören Firewall-Regeln, ein eigener Betriebsnutzer, Ressourcenlimits und die Frage, wer das Modell aktualisieren darf.

• Update-Disziplin: Modellgewichte und Runtime entwickeln sich schnell. Ein ungepflegtes Modellarchiv ist erstens ein Sicherheitsthema (woher kommt die Datei eigentlich?), zweitens ein Betriebsthema, weil sich Antwortverhalten mit jedem Modellwechsel ändern kann.

• Monitoring: Speicher, Kontextlängen, Antwortzeiten und Auslastung müssen sichtbar sein, sonst eskaliert der erste gleichzeitige Nutzeranstieg zum Rätsel.

• Dokumentation: Was das System darf, was es nicht darf, welche Modelle im Einsatz sind und wer sie freigibt, gehört in eine kurze, gepflegte Betriebsdokumentation. Das klingt nach Bürokratie, ist aber genau der Nachweis, den Prüfer und Kunden bei den Fragen nach der KI-Nutzung heute erwarten.

Was sich in der Praxis bewährt hat

Drei Muster aus unseren Projekten. Erstens: Klein anfangen, aber gleich richtig betreiben. Ein einzelnes Modell, ein Host, systemd-Unit, Monitoring, Backup-Konzept für die Modellablage. Der Aufwand dafür ist überschaubar, und genau diese Basis ist später die Vorlage für alles Weitere. Zweitens: Die Schnittstelle früh festlegen. Wer intern über eine HTTP-API arbeitet, kann die Engine hinter der Schnittstelle austauschen, ohne die Konsumenten zu berühren. Drittens: Erwartungen managen. Lokale Modelle sind in ihren Stärken gut, aber nicht austauschbar mit den sehr großen Cloud-Modellen; die Aufgabe entscheidet über die Auswahl, nicht der Benchmark.

Für die Einordnung, wie man solche Infrastruktur sauber aufsetzt und absichert, verweisen wir auf unseren Papier-Beitrag zu KI-Infrastruktur: hosten und sichern, und für die allgemeine Entwicklung des Themas auf unseren Beitrag dazu, wie KI die Arbeit mit Linux-Servern verändert.

Die Grenze des Experiments und der Preis des Betriebs

Ehrlichkeit gehört zum Anspruch dieses Blogs, und hier gehört sie hin: Selbst gehostete KI ist kein kostenloses Gegenmodell zur Cloud-Rechnung, sondern eine Verschiebung der Kosten in andere Posten. Statt nutzungsabhängiger Gebühren trägt man Investition in Hardware, Strom, Wartungsfenster und den Kopf, der sich um Updates kümmert. Bei niedriger und unregelmäßiger Nutzung ist diese Rechnung selten günstig; bei konstanter, planbarer Auslastung und strengen Anforderungen an den Datenfluss dreht sie sich. Genau deshalb empfehlen wir die Entscheidung immer in zwei Schritten: Erst festlegen, welche Arbeitslast aus Datenschutz- oder Compliance-Gründen überhaupt nicht das Haus verlassen darf, und nur für diese den eigenen Betrieb planen. Alles andere kann vorerst dort bleiben, wo es heute läuft, ohne dass jemand ein Risiko eingeht. Diese Trennung hält auch die interne Diskussion ruhig, denn sie verwandelt eine Grundsatzdebatte in eine Reihe von Einzelentscheidungen, die jede für sich überprüfbar ist.

Wer den Betrieb auslagern möchte, findet auf unserer Service-Übersicht die passenden Leistungen.

Fazit

2025/2026 war der Zeitraum, in dem lokale Sprachmodelle von der Kuriosität zum normalen Betreuungsfall geworden sind. Die Technik ist kein Hindernis mehr; Hindernisse sind Planung, Hardwareauswahl und Betriebsreife. Wer den Schritt in Richtung produktivem Betrieb gehen will, sollte ihn wie jede andere Infrastrukturentscheidung behandeln: mit klaren Anforderungen, dokumentierten Zuständigkeiten und einem Update-Rhythmus, der auch dann funktioniert, wenn der Alltag dazwischenkommt.

Quellen

• Ollama-Dokumentation: Hardware support (GPU-Anforderungen, „tens to hundreds of GB“ Modellablage), https://docs.ollama.com/gpu (abgerufen 2026-11-01)

• Ollama-Dokumentation: Windows/Dateisystembedarf (Modellgrößen), https://docs.ollama.com/windows (abgerufen 2026-11-01)

• Ollama-Dokumentation: Troubleshooting (GPU-Erkennung, Runtime-Bibliotheken), https://docs.ollama.com/troubleshooting (abgerufen 2026-11-01)

• BSI: NIS-2-Pflichten (Risikomanagement als Compliance-Kontext), https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/NIS-2-Pflichten/nis-2-pflichten.html (abgerufen 2026-11-01)