Lokale KI-Infrastruktur im Unternehmen: Der Praxis-Leitfaden für On-Premises-LLMs und autonome Agenten

Wer Künstliche Intelligenz im Unternehmen einsetzt, landet fast automatisch bei den großen Cloud-Anbietern. Für schnelle Experimente ist das bequem. Sobald KI jedoch tief in Geschäftsprozesse integriert wird, treten zwei strukturelle Fragen in den Vordergrund: Wie bleiben die Kosten bei wachsender Nutzung beherrschbar? Und wie lassen sich sensible Firmendaten kontrolliert verarbeiten?

In seinem Buch „Souveräne KI – Strategie und Aufbau der eigenen Open-Source-Infrastruktur“ beschreibt Ingmar Stapel einen alternativen Ansatz: den Aufbau einer unternehmenseigenen KI-Werkstatt auf Basis von Open-Source-Modellen. Das Buch verbindet strategische Überlegungen mit konkreten Hardware- und Software-Setups.

Dieser Beitrag ordnet den Ansatz ein und fasst die wichtigsten praktischen Entscheidungen zusammen. Die konkreten Token- und TCO-Beispiele stammen aus Stapels Modellrechnungen. Sie sind keine allgemeingültigen Marktpreise und sollten für jedes Unternehmen mit den eigenen Annahmen neu gerechnet werden.

Hinweis: Dieser Beitrag beschreibt technische und wirtschaftliche Aspekte. Er ist keine Rechtsberatung. Datenschutzrechtliche Fragen sollten für den konkreten Anwendungsfall fachkundig geprüft werden.

Für wen ist dieses Buch?

„Souveräne KI" richtet sich laut Verlagsangaben vor allem an zwei Rollen im Unternehmen:

• Strategische Entscheider (Geschäftsführung, CTOs, Abteilungsleitungen). Für sie zählen Investitionssicherheit, Datenschutz und Compliance-Anforderungen wie der EU AI Act. Sie suchen eine belastbare TCO- und Architekturgrundlage für ihre Entscheidung.
• Technisch umsetzende Rollen (IT-Verantwortliche, DevOps-Engineers, Systemadministratoren). Sie sind mit Linux, Docker und der Kommandozeile vertraut. Sie wollen eine lokale KI-Infrastruktur selbst aufbauen und betreiben.

Wer weder strategische Verantwortung noch operative Umsetzung übernimmt, findet in diesem Beitrag bereits die wesentlichen Argumente und Zusammenhänge zusammengefasst.

Warum Cloud-Kosten zur Innovationsbremse werden können

Kommerzielle Modell-APIs werden typischerweise nach Verbrauch abgerechnet. Je erfolgreicher eine Automatisierung läuft und je mehr Mitarbeiter sie nutzen, desto höher kann die Rechnung ausfallen. Der Zusammenhang ist nicht immer linear zur Zahl der sichtbaren Benutzeranfragen, denn agentische Systeme erzeugen im Hintergrund zusätzliche Modellaufrufe.

Ein KI-Agent arbeitet häufig in einer Schleife: Er plant, recherchiert, ruft Werkzeuge auf, bewertet Zwischenergebnisse und wiederholt diese Schritte, bis die Aufgabe abgeschlossen ist. Je nach Implementierung werden dabei Teile der Konversationshistorie, Werkzeugergebnisse und RAG-Kontext immer wieder verarbeitet.

Stapel beschreibt im Buch eine 90-minütige Arbeitssitzung, die rund vier Millionen Tokens verbraucht. Das Beispiel zeigt, wie stark lange Kontexte und viele Agentenschritte den Verbrauch erhöhen können. Es ist aber kein fixer Richtwert: Modell, Kontextmanagement, Caching, Anzahl der Schritte und Ausgabeumfang verändern das Ergebnis erheblich.

In Teams kann daraus eine unerwünschte Token-Angst entstehen. Wenn jeder Versuch sichtbar das Budget belastet oder an ein Rate-Limit stößt, werden komplexe Workflows seltener ausprobiert. Genau diese Experimente sind aber nötig, um tragfähige Automatisierungen zu finden.

Eigene Hardware verschiebt das Kostenmodell von laufenden API-Gebühren zu einer Investition. Nach der Anschaffung fällt keine Gebühr pro verarbeitetem Token an. Kostenlos ist der Betrieb dennoch nicht: Strom, Kühlung, Administration, Wartung und Ersatzbeschaffung bleiben Teil der Rechnung.

Das Hardware-Fundament: VRAM vor Spitzenleistung

Bei der Planung eines lokalen Inferenzservers schauen viele zuerst auf CPU-Leistung oder theoretische FLOPS. Für große Sprachmodelle ist jedoch häufig der verfügbare Grafikspeicher der erste harte Engpass.

Die Modellgewichte sollten für eine schnelle GPU-Inferenz in den VRAM passen. Hinzu kommen Speicherbedarf für den KV-Cache, Laufzeitdaten und parallele Anfragen. Passt das Modell nicht vollständig auf die GPU, kann ein Teil auf Arbeitsspeicher oder CPU ausgelagert werden – meist auf Kosten von Geschwindigkeit und Durchsatz.

Quantisierung reduziert den Speicherbedarf deutlich. Bei 4 Bit benötigen die reinen Gewichte eines 70B-Modells grob 35 bis 45 GB. Das ist eine Größenordnung, keine Garantie: Architektur, Quantisierungsformat, Kontextfenster und Inferenz-Engine bestimmen den tatsächlichen Bedarf. Auch der Qualitätsverlust ist modell- und aufgabenabhängig und sollte mit den eigenen Anwendungsfällen getestet werden.

Stapel zeigt als leistungsstarkes Beispiel eine Workstation mit zwei NVIDIA RTX PRO 6000. NVIDIA nennt 96 GB GDDR7-ECC-Speicher pro Karte, also 192 GB in einem Dual-GPU-System. Damit dieser Speicher gemeinsam für ein Modell nutzbar wird, muss die verwendete Engine das Modell über mehrere GPUs verteilen. Gleichzeitig müssen Stromversorgung, Kühlung, Gehäuse und Mainboard für zwei Karten mit hoher Leistungsaufnahme ausgelegt sein.

Die richtige Hardware folgt deshalb aus dem Lastprofil:

• Welche Modelle sollen tatsächlich laufen?
• Wie groß sind Kontextfenster und KV-Cache?
• Wie viele Anfragen müssen parallel verarbeitet werden?
• Welche Antwortzeit ist akzeptabel?
• Wie sieht der Ausfall- und Wartungsplan aus?

Ein einzelner Benchmark beantwortet diese Fragen nicht. Ein Pilot mit repräsentativen Prompts, Dokumenten und gleichzeitigen Benutzern ist aussagekräftiger.

Der modulare Software-Stack

Eine wartbare On-Premises-Architektur trennt Betriebssystem, GPU-Laufzeit, Inferenz und Benutzeroberfläche in klar definierte Schichten. Als Basis bietet sich eine Linux-LTS-Distribution wie Ubuntu an, weil Treiber, Container-Werkzeuge und viele KI-Projekte dort gut unterstützt werden.

Darauf folgen NVIDIA-Treiber und die passende CUDA-Laufzeit. Für Container stellt das NVIDIA Container Toolkit die GPU-Ressourcen bereit. Die eigentlichen Dienste laufen in Docker-Containern.

Diese Kapselung reduziert Abhängigkeitskonflikte und macht Deployments reproduzierbarer. Sie löst den Betrieb aber nicht automatisch: Treiber, Container-Images, Modelle und Weboberflächen brauchen feste Versionen, Update-Prozesse, Backups und Sicherheitsprüfungen.

Inferenz-Engines und Chat-Oberflächen

Das Buch stellt mehrere Werkzeuge für unterschiedliche Phasen und Lastprofile vor:

1. LM Studio eignet sich gut für visuelles Experimentieren auf einer Workstation. Modelle lassen sich vergleichen und über einen lokalen Server für erste Integrationen bereitstellen. Die LM-Studio-Dokumentation beschreibt Desktop-App und lokale APIs.
2. Ollama macht den Einstieg in lokale Modelle einfach und stellt eine HTTP-API für eigene Anwendungen bereit. Der offizielle Quickstart zeigt interaktiven Betrieb und API-Aufrufe.
3. vLLM zielt auf performantes Serving und parallele Last. Die vLLM-Dokumentation nennt unter anderem Continuous Batching, Prefix Caching und High-Throughput-Serving.

Die Auswahl ist keine Glaubensfrage. LM Studio kann für Exploration sinnvoll sein, Ollama für kleine interne Dienste und vLLM für höhere Parallelität. Vor einer Produktionsentscheidung sollten alle Kandidaten mit demselben Modell, denselben Prompts und dem erwarteten Lastprofil gemessen werden.

Für Mitarbeiter kann Open WebUI als zentrales Chat-Cockpit vor der Inferenz-Engine stehen. Es verbindet sich unter anderem mit Ollama und OpenAI-kompatiblen Endpunkten. Seine RAG-Funktion zerlegt Dokumente, erzeugt Embeddings und fügt gefundene Abschnitte als Kontext in eine Anfrage ein.

Dabei gehören Mandantentrennung, Rollen, Speicherorte und Löschregeln bewusst konfiguriert und getestet. Eine lokale Installation allein beantwortet diese organisatorischen und rechtlichen Fragen nicht.

Firmenwissen mit RAG nutzbar machen

Der wirtschaftliche Hebel entsteht, wenn ein Modell nicht nur allgemeines Wissen verarbeitet, sondern gezielt auf interne Informationen zugreifen kann. Retrieval-Augmented Generation (RAG) besteht vereinfacht aus vier Schritten:

1. Dokumente werden eingelesen und in kleinere Abschnitte zerlegt.
2. Ein Embedding-Modell wandelt die Abschnitte in Vektoren um.
3. Eine Vektorsuche findet zu einer Frage die relevantesten Passagen.
4. Das Sprachmodell erhält Frage und Fundstellen gemeinsam als Kontext.

Das Modell wird dadurch nicht automatisch „wahrheitsgetreu“. Retrieval-Qualität, veraltete Dokumente, fehlende Berechtigungsfilter und Halluzinationen bleiben Risiken. Für produktive Systeme sind Quellenangaben, Evaluationen, Zugriffsregeln und ein nachvollziehbarer Aktualisierungsprozess unverzichtbar.

Wenn Inferenz, Embeddings, Dokumentenspeicher und Vektordatenbank im eigenen Netz laufen, müssen Dokumente für diesen Ablauf nicht an einen externen Modellanbieter gesendet werden. Ob die konkrete Gesamtlösung geltende Datenschutzanforderungen erfüllt, sollten die zuständigen Fachleute im Unternehmen bewerten.

Prozessautomatisierung mit n8n, Flowise und Agenten

Der nächste Schritt ist die Verbindung mit der bestehenden IT-Landschaft. Low-Code-Werkzeuge wie n8n oder Flowise können Modelle, Datenbanken, E-Mail-Systeme und interne APIs in Workflows zusammenführen. Agenten wie der im Buch behandelte Hermes Agent ergänzen Planung, Werkzeugaufrufe und mehrstufige Ausführung.

Damit wächst auch das Risiko. Ein Chatbot formuliert eine Antwort; ein Agent kann eine E-Mail versenden, einen Datensatz ändern oder einen Prozess auslösen. Produktive Agenten brauchen deshalb mindestens:

• eng begrenzte Werkzeugrechte,
• Freigaben vor irreversiblen Aktionen,
• Obergrenzen für Schritte, Laufzeit und Ressourcen,
• strukturierte Protokolle für Modell- und Werkzeugaufrufe,
• Tests mit typischen Fehler- und Angriffsszenarien,
• einen klaren Weg zur Übergabe an einen Menschen.

Autonomie sollte nicht das Ziel an sich sein. Sinnvoll ist die kleinste Autonomiestufe, die den Prozess zuverlässig verbessert.

Wirtschaftlichkeit: Die TCO entscheidet

Die TCO-Modellrechnung des Buchs markiert bei 20 Mitarbeitern einen interessanten Punkt: Für drei Jahre werden rund 50.760 Euro für Anschaffung und Betrieb der eigenen Hardware und rund 50.800 Euro für eine vergleichbare Cloud-Lösung inklusive RAG angesetzt. Die Differenz von 40 Euro ist in diesem Szenario praktisch bedeutungslos.

Der Vorteil der eigenen Hardware zeigt sich in der Rechnung beim Skalieren. Wenn dieselbe Workstation zusätzliche Nutzer bedienen kann, verteilt sich der Fixkostenblock auf mehr Personen. Cloud-Kosten wachsen dagegen mit Lizenzen und Verbrauch. Bei 50 Nutzern ergibt Stapels Kalkulation über drei Jahre eine Ersparnis von mehr als 17.280 Euro für die On-Premises-Lösung.

Diese Zahlen sind nur so belastbar wie ihre Annahmen. Eine eigene Entscheidungsvorlage sollte mindestens enthalten:

Zusätzlich sollten Opportunitätskosten, Hardware-Auslastung, Restwert und die Kosten eines hybriden Betriebs einfließen. Häufig ist nicht „Cloud oder lokal“, sondern eine bewusste Kombination beider Ansätze die wirtschaftlichste Lösung.

Warum dieser Blogpost nur die Spitze des Eisbergs ist

Dieser Beitrag ordnet den Ansatz ein und liefert die strategischen Argumente. Die eigentliche Umsetzung bleibt jedoch im Detail: Wer die eigene Infrastruktur tatsächlich aufbauen will, braucht mehr als eine Zusammenfassung.

Für die konkrete Umsetzung bietet das Buch nach Angaben des Verlags deutlich mehr Tiefe. Dieser zusätzliche Umfang wird in diesem Beitrag bewusst nicht reproduziert:

• Vollständige, praxiserprobte Konfigurationen. Etwa für Reverse-Proxy, Docker-Compose-Setups und das Routing zwischen Diensten.
• Schritt-für-Schritt-Kommandozeilenbefehle für die einzelnen Installations- und Konfigurationsschritte.
• Hinweise zu typischen Stolpersteinen. Etwa beim Einrichten von CUDA-Umgebungen, bei Berechtigungen und bei der Speicherauslagerung.

Diese Details sollten vor dem produktiven Einsatz ohnehin mit der eigenen Umgebung, den eigenen Sicherheitsanforderungen und aktuellen Versionsständen abgeglichen werden – ein Buch kann das nicht ersetzen, aber als strukturierter Ausgangspunkt erheblich Zeit sparen.

Fazit: Souveränität ist eine Betriebsentscheidung

Eine eigene KI-Werkstatt lohnt sich nicht allein, weil lokale Modelle technisch möglich sind. Sie wird interessant, wenn hohe oder dauerhafte Nutzung, sensible Daten und der Wunsch nach kontrollierbaren Kosten zusammenkommen.

„Souveräne KI“ liefert dafür einen praxisnahen Bauplan. Besonders wertvoll ist die Verbindung aus Hardwareplanung, reproduzierbarem Software-Stack, RAG und agentischer Automatisierung. Unternehmen sollten die Setups jedoch nicht blind kopieren, sondern mit den eigenen Daten, Sicherheitsanforderungen und Lastprofilen validieren.

Wer diesen Weg geht, tauscht Abhängigkeit von einem API-Anbieter gegen Verantwortung für eine eigene Plattform. Genau darin liegt die eigentliche Souveränität.

Bibliografische Angaben und Bezugsquelle

• Titel: Souveräne KI. Strategie und Aufbau der eigenen Open-Source-Infrastruktur
• Autor: Ingmar Stapel
• Verlag: Rheinwerk Computing, 1. Auflage 2026, 464 Seiten
• ISBN: 978-3-367-11588-4 (Buch), 978-3-367-11589-1 (E-Book), 978-3-367-11592-1 (Bundle)
• Offizielle Produktseite: Rheinwerk Verlag – Souveräne KI