Self-hosted KI für KMU: Ollama, OpenWebUI, vLLM und Llama.cpp im Vergleich (2026)

Wann lohnt sich On-Premise-KI wirklich, welcher Stack passt zu welchem Anwendungsfall, und was kostet das im Vergleich zur OpenAI-API?

Wer 2026 als Mittelständler überlegt, eigene Sprachmodelle zu betreiben, wird mit zwei gegensätzlichen Erzählungen konfrontiert: einerseits die Marketingversprechen der großen Cloud-Anbieter, andererseits eine wachsende Open-Source-Welt, in der ein RTX-4090-Server angeblich „alles kann”. Beide Vereinfachungen sind falsch. Dieser Artikel erklärt, welche Unternehmen tatsächlich on-prem fahren sollten, welche Tools welche Aufgabe lösen, und ab welchem Volumen sich die Investition rechnet — auf Basis aktueller Hardware-Preise, Strompreise und API-Tarife im April 2026.

Wir sind eine Beratung mit Sitz in DACH, die genau solche Architekturen für KMU plant und umsetzt. Der Artikel ist daher eine Entscheidungshilfe — kein Werbetext für ein bestimmtes Setup.

1. Wer braucht überhaupt eine selbstgehostete KI?

Die ehrliche Antwort lautet: die meisten KMU nicht. Wer als Zehn-Personen-Agentur ChatGPT für gelegentliche Texte und Recherchen nutzt, hat mit einer ChatGPT-Business- oder Claude-Team-Lizenz inklusive Auftragsverarbeitungsvertrag den besseren Deal — schneller, günstiger und mit höherer Modellqualität. Self-Hosting kostet Geld, IT-Kapazität und Aufmerksamkeit, die anderswo besser investiert sind.

On-Premise lohnt sich realistisch ab folgender Konstellation:

• Mehr als 50 Mitarbeitende mit regelmäßiger KI-Nutzung, oder kleinere Teams mit hochfrequentem Einsatz (z. B. RAG-Bot mit mehreren tausend Anfragen pro Tag).
• Verarbeitung wirklich schutzbedürftiger Daten: Patientenakten, Mandantenkommunikation, Steuerdaten, interne Bewerbungsunterlagen, F&E-Material, Quellcode mit Geschäftsgeheimnissen.
• Regulatorische Anforderungen: BaFin-Aufsicht, KRITIS, Berufsgeheimnis nach § 203 StGB, DORA-pflichtige Finanzdienstleister, Pharma/MedTech mit MDR-Bezug.
• Vorhersehbares hohes Volumen, bei dem die OpenAI-Token-Rechnung den Hardware-Amortisationspfad sichtbar unterschreitet (ab ca. 500 k Tokens/Tag aufwärts — siehe Abschnitt 4).
• Vorhandene IT-Kompetenz im Haus oder ein Partner, der die Plattform betreut.

Wer es lassen sollte: Unternehmen unter 20 Mitarbeitenden ohne IT-Abteilung, gelegentliche Textnutzung, keine besonderen Datenkategorien. Hier ist der TCO einer eigenen Inferenz-Server-Lösung höher als jede sinnvolle API-Rechnung — und Sie binden Personal an Wartung statt an Wertschöpfung.

Die regulatorischen Treiber, die das Bild 2026 verändert haben

Drei Entwicklungen machen die Diskussion in DACH ernster, als sie es 2024 noch war:

EU AI Act in Wirkung. Seit dem 2. Februar 2025 gelten Art. 5 (Verbot bestimmter KI-Praktiken) und vor allem Art. 4 KI-VO (KI-Kompetenzpflicht) für Anbieter und Betreiber — also auch für jedes KMU, dessen Mitarbeitende ChatGPT nutzen. Seit dem 2. August 2025 greifen die GPAI-Pflichten. Am 2. August 2026 wird die Verordnung in vollem Umfang anwendbar, einschließlich der Hochrisiko-Pflichten nach Anhang III. Zentrale deutsche Aufsichtsbehörde ist die Bundesnetzagentur mit ihrem KI-Service-Desk. Bußgelder reichen bis zu 35 Mio. € oder 7 % des Konzernumsatzes.

DSGVO und Schrems II bleiben relevant. Das EU-US Data Privacy Framework wurde am 3. September 2025 vom EuG (Latombe-Urteil) bestätigt — US-Anbieter mit DPF-Zertifizierung sind also weiterhin grundsätzlich nutzbar. Die Konstellation bleibt aber politisch fragil: NOYB hat eine „Schrems III”-Klage angekündigt, und der CLOUD Act steht in struktureller Spannung zu Art. 48 DSGVO. Wer mehrjährige Architektur-Entscheidungen trifft, sollte das Restrisiko bepreisen.

Berufsgeheimnis schlägt DSGVO. Der Hessische Datenschutzbeauftragte (HBDI) hat im November 2025 in seinem 137-seitigen M365-Bericht klargestellt, was Anwaltschaft und Ärzteschaft längst wissen: DSGVO-Konformität ersetzt nicht § 203 StGB. Für Berufsgeheimnisträger braucht es zusätzlich eine § 203-Zusatzvereinbarung — und selbst dann bleibt die bloße Möglichkeit eines Zugriffs durch Provider-Personal eine Offenbarung im Sinne des Strafrechts. Die BRAK-Handlungshinweise vom Dezember 2024 und § 62a StBerG für Steuerberater gehen in dieselbe Richtung. Für viele dieser Berufsgruppen ist On-Premise nicht Komfort, sondern de facto der einzig saubere Weg.

2. Die vier Tools im Überblick

Bevor wir vergleichen, eine wichtige Klarstellung: Die vier Werkzeuge sitzen auf unterschiedlichen Schichten des Stacks. Sie sind keine Konkurrenten im engeren Sinn — sie ergänzen sich.

• Llama.cpp ist die unterste Schicht: eine C++-Inferenzbibliothek, die Modelle auf CPU oder GPU ausführt.
• Ollama ist eine Laufzeitumgebung mit Modellregister, die Llama.cpp (und MLX auf Apple Silicon) verpackt und über eine HTTP-API bereitstellt.
• vLLM ist ein produktionstauglicher Inferenz-Server für hohen Durchsatz und parallele Anfragen — eine eigene Engine, nicht auf Llama.cpp aufgesetzt.
• OpenWebUI ist ein Frontend, das sich an Ollama, vLLM oder andere OpenAI-kompatible Backends anbindet.

Eine typische Architektur kombiniert also zwei oder drei dieser Tools.

Vergleichstabelle

Tool	Schicht	Lizenz	Beste Eignung	Hardware-Minimum	Empfohlen	Setup-Zeit
Llama.cpp (ggml-org/llama.cpp)	Inferenz-Bibliothek	MIT	Edge-Geräte, Apple Silicon, CPU-only, eingebettete Lösungen	16 GB RAM, x86-64 mit AVX2	RTX-Karte oder Apple M-Series mit ≥ 32 GB unified memory	1–2 h
Ollama (v0.21.x)	Runtime + Registry	MIT	Schnelle MVPs, Entwicklerteams, Single-User-Workstations	8 GB RAM, CPU-only möglich	RTX 4090 / 5090 oder RTX 6000 Ada	30 min
OpenWebUI (v0.8.x)	Web-Frontend	BSD-3 (modifiziert; ab 2025 mit Branding-Klausel)	ChatGPT-ähnliches UI für Mitarbeitende, einfaches RAG, Multi-User	Docker, 4 GB RAM	Server mit Backend (Ollama oder vLLM)	1–2 h
vLLM (v0.20.x)	Hochdurchsatz-Inferenzserver	Apache 2.0	Produktionsbetrieb, viele parallele Nutzer, RAG-Plattform, Agentenflotten	NVIDIA-GPU mit ≥ 24 GB VRAM	H100/H200, RTX 6000 Ada/Blackwell, ggf. mehrere GPUs	0,5–2 Tage

Was Sie zu jedem Werkzeug wissen sollten:

Llama.cpp ist das Fundament. Das Projekt der ggml-org (umbenannt vom alten ggerganov/llama.cpp) liefert das GGUF-Format, in dem heute fast alle quantisierten Open-Source-Modelle verteilt werden. Es unterstützt CUDA, ROCm, Vulkan, Metal, SYCL und Apple Accelerate. Wer auf Apple Silicon (M3/M4 Ultra mit 192–512 GB unified memory) hostet oder ein 70-B-Modell auf einer einzelnen Workstation laufen lassen will, landet faktisch bei Llama.cpp — meistens indirekt über Ollama, LM Studio oder Jan.

Ollama macht die Inbetriebnahme trivial. Ein Befehl, und Sie haben einen lokalen OpenAI-kompatiblen API-Endpoint:

# Linux-Installation
curl -fsSL https://ollama.com/install.sh | sh

# Modell laden und starten
ollama pull qwen3:14b
ollama run qwen3:14b

Stärken: Ein-Befehl-Setup, riesige Modellbibliothek, automatische Hardware-Erkennung, deepe Toolchain-Integration (Continue, Open WebUI, n8n). Schwächen: Standardkontextlänge nur 2 048 Tokens (muss manuell hochgesetzt werden, sonst zerschießt das jedes RAG), Single-Tenant-Architektur, kein Auth, kein Rate-Limiting — also für interne Demos und kleine Teams geeignet, aber kein Produktions-Backend für hundert gleichzeitige Nutzer.

OpenWebUI ist die UI, die Mitarbeitende zu sehen bekommen sollten. Version 0.8.x bringt 9 unterstützte Vektordatenbanken (Qdrant, pgvector, Milvus, Chroma u. a.), 15+ Web-Such-Provider, vollwertige RBAC, LDAP/Active Directory, SCIM 2.0 für Okta/Entra/Google Workspace, OpenTelemetry-Observability und Audit-Logs. Damit ist es eines der wenigen Open-Source-Frontends, das sich realistisch in eine Unternehmensumgebung einpassen lässt. Achtung bei der Lizenz: OpenWebUI ist seit 2025 nicht mehr klassisches MIT, sondern ein modifiziertes BSD-3 mit Branding-Klausel — vor Rebranding-Plänen lesen.

# docker-compose.yml — Ollama + OpenWebUI Minimalsetup
services:
  ollama:
    image: ollama/ollama
    volumes:
      - ollama:/root/.ollama
    ports:
      - "11434:11434"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

  openwebui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - openwebui:/app/backend/data
    depends_on:
      - ollama

volumes:
  ollama:
  openwebui:

vLLM ist die Engine, sobald es ernst wird. Die PagedAttention-Architektur (UC Berkeley, SOSP 2023) reduziert die KV-Cache-Verschwendung von 60–80 % bei naiven Implementierungen auf unter 4 % — was bei gleichbleibender VRAM-Größe deutlich höhere Batch-Größen und damit Durchsatz erlaubt. Auf einer H100 80 GB liefert vLLM für Llama 3.1 8B BF16 etwa 12 500 Tokens/s aggregiert; auf 4× RTX 6000 Ada erreichen Tensor-Parallel-Setups mit Qwen 2.5 72B um 450 Tokens/s aggregiert — ein typischer Sweet Spot für KMU-RAG-Workloads.

3. Welcher Stack für welchen Anwendungsfall?

Drei realistische Szenarien, die wir in unserer Beratungspraxis täglich sehen:

Szenario A: 10 Mitarbeitende, ChatGPT-Ersatz für Texte und E-Mails

Empfehlung: Ollama + OpenWebUI auf einem einzelnen Workstation-Server mit einer Consumer-GPU.

Modelle: Qwen 3 14B oder Llama 3.3 instruct in Q4_K_M-Quantisierung passt komfortabel in 24 GB VRAM. Für deutsche Texte ist Qwen 3 (Apache 2.0) auf den OpenGPT-X-Benchmarks regelmäßig vorne; Mistral Small 3.1 ist eine starke Alternative, wenn französisch-deutsche Mehrsprachigkeit zählt.

Hardware: Workstation mit RTX 4090 (24 GB) oder RTX 5090 (32 GB). Eine RTX 4090 erreicht auf Llama 3 8B etwa 150 Tokens/s — schneller, als Ihre Mitarbeitenden lesen. Für zehn Personen mit Wechselzugriff genügt das problemlos.

Investition: Komplettsystem ca. 4 000–5 000 € netto, plus 2 500–3 500 € Setup (Härtung, OpenWebUI-Integration, Active-Directory-Anbindung, Schulung).

Szenario B: 50 Mitarbeitende, RAG über interne Dokumente + Kundenservice-Bot

Empfehlung: vLLM als Inferenz-Backend, Qdrant oder pgvector als Vektordatenbank, LlamaIndex oder LangChain als RAG-Orchestrierung, OpenWebUI als Mitarbeiter-Frontend, ein dünner eigener Service für den Kundenbot.

Hardware: Workstation mit 1–2× RTX 6000 Ada (48 GB) oder gleich ein gemieteter Server, etwa der Hetzner GEX130 mit RTX 6000 Ada zu 838 € netto/Monat oder der neue GEX131 mit RTX PRO 6000 Blackwell (96 GB GDDR7) zu 889 € netto/Monat. Standort Falkenstein/Nürnberg, ISO 27001:2022, im EU-Rechtsraum — DSGVO-Datenresidenz bedeutet hier nicht „US-Cloud mit EU-Region”, sondern echtes deutsches Eisen.

Modelle: Qwen 3 32B (instruct + reasoning) für die Hauptaufgaben, ein kleineres Modell wie Llama 3.2 3B für günstige Triagierung, plus ein Embedding-Modell wie nomic-embed-text oder BGE-M3.

Szenario C: 200 Mitarbeitende, mehrere Use-Cases, Agenten, hohe Last

Empfehlung: vLLM im Cluster-Betrieb mit Tensor-Parallelism über mehrere GPUs, Lastverteilung über NGINX/Traefik, separates Frontend, Observability mit OpenTelemetry/Prometheus/Grafana.

Hardware: Realistisch wird hier Colocation in Frankfurt oder ein dedizierter GPU-Server-Pool. Wer maximale Souveränität will, baut 2× RTX 6000 Blackwell (96 GB) ins eigene Rack; wer Flexibilität will, mietet 2–4 GEX131-Server oder geht auf H100/H200 bei einem deutschen Provider. Eigenbetrieb ist ab dieser Größe sinnvoll, weil die Hardware-Auslastung über 24 h hoch bleibt — der ökonomische Vorteil von vLLM kommt bei voller Auslastung zur Geltung.

4. Realistische Kostenanalyse

Dies ist die entscheidende Sektion. Wir rechnen für ein KMU mit 50 Mitarbeitenden, das KI als Alltagswerkzeug nutzt: ca. 10 Anfragen pro Tag pro Person, durchschnittlich 1 000 Eingabe- und 500 Ausgabe-Tokens. Das ergibt 750 000 Tokens/Tag oder grob 22,5 Mio. Tokens/Monat (bei 30 Arbeitstagen/Monat).

Variante 1: OpenAI-API als Referenz

Bei Nutzung von GPT-5.4 (April 2026: 2,50 USD/1 M Eingabe, 15,00 USD/1 M Ausgabe):

• Eingabe: 15,0 Mio. × 2,50 USD = 37,50 USD
• Ausgabe: 7,5 Mio. × 15,00 USD = 112,50 USD
• Monatlich rund 150 USD ≈ 140 € netto, also etwa 1 700 €/Jahr.

Mit GPT-5.4-mini (0,25/2,00 USD) wären es nur ca. 22 €/Monat — aber dafür auch deutlich schwächere Reasoning-Qualität. Mit dem neueren GPT-5.5 (ab 23. April 2026: 5,00/30,00 USD) verdoppelt sich die Rechnung auf rund 280 €/Monat.

Wichtig: Diese Zahlen sind nur die Token-Kosten. Hinzu kommen für Berufsgeheimnisträger oder regulierte Branchen die zusätzlichen Vertragskosten (§ 203-Zusatzvereinbarung, Transfer Impact Assessment), Pseudonymisierungsaufwand und das Restrisiko aus CLOUD Act und einer möglichen DPF-Aufhebung.

Variante 2: Self-Hosted auf eigener Hardware

Hardware-Optionen für 50-Personen-Setup:

Option	Anschaffung	Monatlich (Strom 600 W bei 16 ct/kWh)
Workstation mit 1× RTX 5090 (32 GB)	ca. 5 500 € netto	ca. 70 €
Workstation mit 1× RTX 6000 Ada (48 GB)	ca. 11 000 € netto	ca. 60 €
Workstation mit 2× RTX 6000 Ada	ca. 25 000 € netto	ca. 110 €
Mietserver Hetzner GEX130 (RTX 6000 Ada)	0 € + 79 € Setup	838 € + 0 € (Strom inkl.)
Mietserver Hetzner GEX131 (RTX PRO 6000 Blackwell)	0 €	889 € (Strom inkl.)

Stromrechnung im Eigenbetrieb: Eine Workstation mit 600 W Dauerlast verbraucht 5 256 kWh/Jahr. Beim deutschen SMB-Industriestrompreis von ca. 16,0 ct/kWh netto (BDEW-Strompreisanalyse Januar 2026, Mittelstandssegment) sind das 841 €/Jahr — also rund 70 €/Monat. Größere Dual-GPU-Systeme mit 1 000 W Last landen bei rund 1 400 €/Jahr Stromkosten.

Implementierung und Betrieb: Die Initialinvestition für eine professionelle Inbetriebnahme — Installation, Modellauswahl, OpenWebUI-Härtung, AD/SSO-Anbindung, RAG-Pipeline, Monitoring, Schulung — liegt erfahrungsgemäß bei 2 500–5 000 € einmalig, je nach Komplexität. Laufende Wartung: realistisch 4–8 Stunden/Monat. Das umfasst Modell-Updates, Sicherheits-Patches, Capacity-Monitoring, gelegentliche Benchmarks. Wer keinen eigenen IT-Mitarbeiter mit GPU-Erfahrung hat, kalkuliert hier mit 150–250 €/Monat externem Support.

TCO-Vergleich über 1 und 3 Jahre

Annahme: 50-Personen-KMU, mittlere Workload (22,5 Mio. Tokens/Monat).

Szenario	Jahr 1	Jahr 3 (kumuliert)
OpenAI GPT-5.4 (Cloud-only)	ca. 1 700 €	ca. 5 100 €
OpenAI GPT-5.5 (Cloud-only)	ca. 3 400 €	ca. 10 200 €
Hetzner GEX130 (Miete, Setup 3 500 €)	ca. 13 600 €	ca. 33 600 €
Hetzner GEX131 (Miete, Setup 3 500 €)	ca. 14 200 €	ca. 35 200 €
Eigenbau RTX 5090 (kauf, Setup 3 500 €, Strom + Wartung)	ca. 11 000 €	ca. 17 000 €
Eigenbau Dual RTX 6000 Ada (Setup 5 000 €, Strom + Wartung)	ca. 33 000 €	ca. 41 000 €

Was die Tabelle zeigt — und was nicht. Bei einem mittleren Volumen von 22,5 Mio. Tokens/Monat mit GPT-5.4 ist die OpenAI-API rein nominell deutlich günstiger. Self-Hosting rechnet sich erst, wenn:

1. Das Volumen deutlich steigt. Bei ca. 150 Mio. Tokens/Monat (ein Faktor 7) erreicht GPT-5.4 ungefähr 11 000 €/Jahr und liegt damit über dem Eigenbau-RTX-5090-Pfad. Mit GPT-5.5 verschiebt sich der Break-even auf ca. 75 Mio. Tokens/Monat.
2. Die regulatorischen Kosten realistisch eingepreist werden. Wer §-203-Zusatzvereinbarungen, Pseudonymisierungslayer, TIAs und Restrisiken aus DPF-Unsicherheit ehrlich beziffert, addiert pro Jahr leicht mehrere tausend Euro auf jede Cloud-Variante.
3. Mehrere Anwendungsfälle parallel laufen. Die Hardware bezahlen Sie einmal, die Token-Rechnung skaliert linear mit jedem zusätzlichen Use-Case.

Versteckte Kosten, die viele unterschätzen:

• Modell-Updates und Re-Evaluation alle 3–6 Monate (typischerweise 1–2 Tage Aufwand).
• VRAM-Druck bei wachsendem Kontext: Was mit 8 k Tokens passt, sprengt mit 32 k die Karte.
• Authentifizierung, Rate-Limiting, Audit-Logging, DSFA-Dokumentation.
• Monitoring-Stack (Prometheus, Grafana, Loki) — kostet keine Lizenz, aber Aufmerksamkeit.

5. Die häufigsten Stolperfallen bei der Implementierung

Englische Benchmarks lügen für Deutsch. Modelle, die auf MMLU oder GSM8K glänzen, können bei deutschen Texten schwächeln. Die European LLM Leaderboard des Fraunhofer IAIS / OpenGPT-X-Projekts (auf Hugging Face) ist die seriöseste deutschsprachige Referenz. Aktuell führen Qwen 3, Apertus 70B (ETH Zürich/EPFL, Apache 2.0, September 2025) und EuroLLM-22B (EuroHPC-finanziert) — Teuken-7B von Fraunhofer ist als reines EU-Sprachenmodell weiterhin relevant, aber in der allgemeinen Antwortqualität von Qwen 3 14B+ überholt. Aleph Alpha Pharia-1 ist als Open-Source-Variante wegen der nicht-kommerziellen Lizenz für KMU meist keine Option; die kommerzielle PhariaAI-Suite ist auf Enterprise zugeschnitten.

Stromversorgung und Kühlung werden unterschätzt. Eine RTX 5090 hat 575 W TDP und braucht ein 1 200-W-Netzteil. Zwei RTX 6000 Ada in einer Workstation ziehen unter Last über 1 kW. Bürorackräume mit zwei Steckdosen pro Sicherung sind dafür nicht ausgelegt. Wer das nicht im Vorfeld plant, baut Hardware, die nach dem ersten Sommer thermisch drosselt.

Falsche Modellgröße. Der Reflex „nimm das Größte, was passt” ist meist falsch. Für E-Mail-Entwürfe und Kundenanfragen liefert ein 8-B-Modell oft Antworten, die mit einem 70-B-Modell qualitativ kaum unterscheidbar sind — bei einem Achtel des Energie- und Latenzbudgets. Realistisch testen heißt: zehn typische Anfragen aus dem Echtbetrieb mit drei Modellgrößen vergleichen, dann entscheiden.

Produktionsreife wird unterschätzt. Authentifizierung, Rate-Limiting, Audit-Logs, Backup, Recovery, Modell-Versionierung — das sind Themen, die in Tutorials nie auftauchen, aber im echten Betrieb 60 % der Arbeit ausmachen. OpenWebUI 0.8.x liefert vieles davon mit; vLLM nicht — dort braucht es einen Reverse-Proxy mit OAuth-Auth und ein eigenes Quota-Management. Die DSK-Orientierungshilfe vom 17. Oktober 2025 zu RAG-Systemen und der BSI-Kriterienkatalog für generative KI in der Bundesverwaltung (24. Juni 2025) sind die aktuell besten deutschen Referenzdokumente, um eine Eigenbetriebs-Architektur zu strukturieren.

Evaluation wird vergessen. Für jeden produktiven Use-Case sollten Sie ein internes Eval-Set von 50–200 Beispielen anlegen, das Sie bei jedem Modellwechsel automatisiert durchlaufen. Ohne diesen Schritt entsteht ein Wartungsalbtraum: Niemand weiß, ob der nächste Llama-Release das System verbessert oder verschlechtert.

6. Wann wir empfehlen, bei OpenAI oder Anthropic zu bleiben

Wir verdienen an On-Premise-Projekten — und raten trotzdem regelmäßig davon ab. Bleiben Sie bei der Cloud-API, wenn:

• Ihre Gesamtnutzung unter rund 100 000 Tokens pro Tag liegt. Auf diesem Niveau ist jede Eigenbetriebsrechnung Augenwischerei.
• Sie keine IT-Kapazität haben und keinen Partner, der die Plattform betreut.
• Ihre Use-Cases echte Frontier-Fähigkeiten brauchen — etwa state-of-the-art Reasoning, lange Kontextfenster über 200 k Tokens mit hoher Treue, oder spezialisierte Code-Modi, in denen GPT-5.5 Pro oder Claude Opus 4.7 messbar führen. Open-Source-Modelle sind beeindruckend, aber 2026 weiterhin nicht überall führend.

Zwischen „US-Cloud” und „komplett selbst hosten” gibt es 2026 inzwischen sinnvolle Mittelwege: Mistral La Plateforme (Paris, OpenAI-kompatibel, Mistral Medium 3 für 0,40/2,00 USD/1 M Tokens), Aleph Alpha PhariaAI (Heidelberg/München, dedizierte Instanzen, individuelle Verträge), T-Systems Business GPT mit Teuken-7B im deutschen Rechenzentrum, oder Azure OpenAI EU Data Boundary (operativ seit Februar 2025; Hinweis: Anthropic-Modelle in Microsoft 365 Copilot fallen ausdrücklich nicht unter diese Boundary). Für viele KMU ist das der pragmatische Weg, solange die On-Premise-Schwelle noch nicht erreicht ist.

7. Wie wir bei Mainframe vorgehen

Unser Vorgehen folgt drei Phasen, weil sich KI-Architekturen nicht in einem Wurf entscheiden lassen.

Erstens: Discovery-Workshop (1 500 €). Eintägige Sitzung mit Geschäftsführung, IT und einem fachlichen Stakeholder. Wir kartieren die geplanten Use-Cases, prüfen Datenkategorien gegen DSGVO und Berufsgeheimnis, schätzen Volumina und entscheiden gemeinsam: Cloud, EU-Mittelweg oder On-Premise. In etwa einem Drittel der Workshops lautet die ehrliche Antwort: noch keine On-Premise-Lösung, sondern erst saubere Verträge mit dem Cloud-Anbieter.

Zweitens: MVP mit Ollama + OpenWebUI. Wenn On-Premise sinnvoll ist, starten wir klein. Eine einzelne Workstation oder ein GEX130, Qwen 3 14B als Default-Modell, OpenWebUI mit AD-Anbindung, ein erstes RAG-System auf einem klar abgegrenzten Dokumentenkorpus. Das läuft typischerweise in zwei bis vier Wochen. Wir liefern die Architektur dokumentiert ab, schulen das interne Team und übergeben — oder übernehmen den laufenden Betrieb.

Drittens: Skalierung auf vLLM, wenn das MVP trägt. Ab dem Punkt, an dem Latenzen unter Last messbar werden, oder wenn ein zweiter und dritter Use-Case dazukommt, migrieren wir das Backend auf vLLM, ergänzen Observability und führen ein formales Eval-Set ein. Erst hier wird die Plattform zur „echten” Infrastruktur.

Details zu unserem On-Premise-LLM-Deployment-Service finden Sie unter /leistungen/on-premise-llm-deployment.

8. Fazit

Drei Erkenntnisse, die wir aus Dutzenden KMU-Projekten 2025/2026 mitnehmen.

Self-Hosted-KI ist 2026 reif für den Mittelstand — aber nicht für jeden. Die Tools (Ollama, OpenWebUI, vLLM, Llama.cpp) und Modelle (Qwen 3, Apertus, EuroLLM) sind so gut, dass technologische Hürden kein ernsthafter Grund mehr sind, in der US-Cloud zu bleiben. Wirtschaftliche und organisatorische Hürden bleiben aber real.

Die eigentliche Frage ist regulatorisch, nicht technisch. EU AI Act ab August 2026, § 203 StGB für Berufsgeheimnisträger, BaFin-Orientierungshilfe vom Dezember 2025, DSK-Trilogie zu KI und RAG — wer in einem dieser Felder operiert, muss On-Premise oder eine sauber kontrollierbare EU-Lösung mindestens ernsthaft prüfen.

TCO-Rechnungen lügen, wenn sie nur Tokens vergleichen. Eine ehrliche Kalkulation umfasst Vertragsrisiken, Restrisiken aus Schrems II/CLOUD Act, Pseudonymisierungsaufwand und das organisatorische Lock-in eines US-Anbieters. Auf dieser Basis verschiebt sich der Break-even-Punkt häufig deutlich zugunsten von On-Premise.

Wenn Sie unsicher sind, ob ein selbstgehosteter Stack zu Ihnen passt, ist der AI-Agent Discovery Workshop der schnellste Weg zu einer fundierten Entscheidung — bevor Sie Hardware kaufen oder Verträge unterschreiben. Den Service finden Sie unter /leistungen/ai-agent-discovery-workshop, und für die Implementierung selbst unter /leistungen/on-premise-llm-deployment.