Selbst gehostete KI auf Unternehmensniveau
In diesem Artikel teilen wir, wie Saphes IT Systems selbst gehostete KI auf Unternehmensniveau von Anfang an angegangen ist. Wir haben diesen Weg aus zwei Gründen eingeschlagen: Wir mussten strenge Compliance-Anforderungen erfüllen, und wir wollten die volle Kontrolle behalten, statt von einem einzigen Anbieter abhängig zu sein.
Unsere Arbeit ist eng mit geistigem Eigentum und sensiblen Kundendaten verbunden. Proprietäres Wissen und Assets ohne klare Garantien und Kontrolle an einen externen KI-Anbieter zu senden, wirft eine einfache Frage auf: Was, wenn wir unser IP am Ende umsonst hergeben?
Nach mehr als zwei Jahren praktischer Experimente unter Produktionsbedingungen haben wir tiefe Expertise im Entwurf und Betrieb eines wettbewerbsfähigen selbst gehosteten KI-Stacks aufgebaut. Heute übersetzt sich diese Erfahrung in eine Plattform, die nicht nur konform und kontrollierbar ist, sondern auch schneller und deutlich kosteneffizienter als viele Alternativen.
In den folgenden Abschnitten betrachten wir die wichtigsten Bausteine eines selbst gehosteten KI-Setups für Unternehmen:
- Hardware und Dimensionierung (Planung auf Basis von Kapazität und SLOs)
- Modellstrategie (was für welche Aufgaben laufen soll und wie der Lebenszyklus verwaltet wird)
- Software-Stack (Inferenz, Orchestrierung, RAG, Observability)
Hardware und Dimensionierung
Die Dimensionierung beginnt mit einigen praktischen Zielen: erwartete Nutzerzahl, Spitzennebenläufigkeit, akzeptable Latenz (Time-to-First-Token und Tokens/Sek.) und Workload-Mix (Chat, RAG, Batch-Jobs, Embeddings). Von dort aus kannst du wählen:
- Compute: CPU vs. GPU, GPU-Klasse (Consumer oder Datacenter) und VRAM-Bedarf, bestimmt durch Modellgröße + Kontextlänge + Batch-Größe. Siehe PassMark GPU-Benchmarks für Vergleiche zwischen Consumer- und Pro-Karten.
- Speicher und Storage: genug RAM für unterstützende Dienste plus schneller lokaler Speicher für Modellgewichte und Caches; plane Wachstum ein, wenn Modelle und Kontextfenster größer werden.
- Netzwerk: Netzwerk mit niedriger Latenz zwischen Inferenz und unterstützenden Diensten (Vektordatenbank, Storage, Observability) und genug Egress-Kapazität, wenn mehrere Apps das Modell aufrufen.
Für Teams, die bereits Server betreiben, sieht das wie Kapazitätsplanung für jede andere interne Plattform aus: SLOs definieren, messen, dann skalieren.
Beobachtungen
Diese Beobachtungen entsprechen möglicherweise nicht genau deinen Anforderungen. Wir empfehlen dringend, deine zukünftige Nutzung mit einem Experten zu analysieren, statt zu raten. Die folgenden Beispiele sind Beobachtungen aus der Praxis, aber sie sind nicht präzise genug, um allein das richtige Setup zu wählen.
| Unternehmensgröße | Nutzungsarten | Hardware-Optionen | Anfangskosten |
|---|---|---|---|
| Kleines Team (2-20 Nutzer), geringe Nutzung | Interner Chat, Ad-hoc-Q&A, geringe Nebenläufigkeit | CPU-first (Apple M3 Ultra) oder 1× Pro GPU 48GB VRAM (z. B. RTX PRO 5000) mit 64GB RAM und schnellem NVMe | ~2k-5k€ |
| Kleines Entwicklerteam (2-10 Nutzer), hohe Nutzung | Interner Chat, Ad-hoc-Q&A, hohe Nebenläufigkeit, RAG, Codegenerierung, Code-Vervollständigung | 2× Pro GPU 96GB VRAM (RTX PRO 5000) oder 4× Premium- und kosteneffiziente Consumer-GPU (RTX 3090) mit 128GB RAM und schnellem NVMe | ~5k-15k€ |
| Mittleres Unternehmen (50-200 Nutzer), gemischte Nutzung | Interner Assistent + Abteilungs-RAG (HR, Vertrieb, Support), moderate Nebenläufigkeit, einige Batch-Jobs | 2× Datacenter-GPU 80GB (A100 / H100) oder 2× 96GB Pro RTX 6000 GPUs, 256-512GB RAM, 2-4× NVMe (RAID); ziehe einen separaten Node für Vektordatenbank/ETL in Betracht | ~20k€-50k€ |
Häufig gestellte Fragen
Wie viel kostet der Strom für den Betrieb des Systems?
Das ist vernachlässigbar im Vergleich zu den Anfangskosten oder den Kosten pro Token bei KI-Anbietern. Nehmen wir an, du nutzt 20% der Zeit 100% deiner Kapazität mit 4 Consumer-GPUs (eine intensive Nutzung). Dann liegt deine Rechnung bei etwa 100€/Monat. Bei derselben intensiven Nutzung bei KI-Anbietern lägest du bei etwa 3k-6k€ pro Monat.
Wie wählt man das richtige Mainboard und was ist mit PCIe?
Das hängt von deinen Anforderungen ab. Einige professionelle Mainboards wie das MZ32-AR0 werden empfohlen, besonders wenn du mehrere Modelle nutzen und sie schnell laden/entladen möchtest (PCIe-Version und Lanes pro Slot, hier PCIe 4 16x). Wenn du dich auf ein oder zwei Modelle verlässt, kannst du sie geladen halten und ein Consumer-Mainboard wie ein B550 Eagle verwenden, das sehr kosteneffizient ist. Tatsächlich ist die Lane-Geschwindigkeit, selbst bei PCIe 3 x1, ausreichend, und es gibt keinen Unterschied bei der Inferenzgeschwindigkeit; nur das Laden der Modelle dauert viel länger.
Wie versorgt man 4 GPUs mit Strom? Kann ich mehrere Netzteile verwenden?
Ja. Wir empfehlen, mehrere Netzteile zu verwenden, wenn du keines findest, das deine Anforderungen erfüllt. Ein Netzteil kann aktiviert werden, ohne dass es mit der Workstation verbunden werden muss.
Welche CPU sollte ich mit High-End-GPUs kombinieren?
Priorisiere PCIe-Lanes und Speicherbandbreite: Workstation-/Server-CPUs (Threadripper/EPYC/Xeon) passen oft besser als Consumer-CPUs, wenn du 2-4+ GPUs betreibst. Vermeide CPU-Engpässe beim Token-Streaming und bei RAG-Pipelines.
Welches Storage-Setup eignet sich am besten für Modellgewichte und RAG?
Verwende schnelles NVMe für Modellgewichte und Hot-Caches. Separate Volumes (oder separate Nodes) für die Vektordatenbank und Logs. RAID1/10 hilft bei der Verfügbarkeit; plane auch Backups für Indizes und Dokumente ein.
Ist Consumer-GPU-Hardware zuverlässig genug für die Produktion?
In den meisten Fällen ja. Wenn du jedoch Kunden bedienst und kein höheres Betriebsrisiko akzeptierst (kein ECC-VRAM, weniger vorhersehbare Temperaturen), bevorzuge Datacenter-GPUs, validierte Gehäuse und Enterprise-Support.
Wie gehen wir mit Kühlung, Lärm und Leistungsgrenzen um?
Plane zuerst den Luftstrom (von vorne nach hinten, Lüfter mit hohem statischem Druck), dimensioniere Netzteile mit Reserve und setze GPU-Leistungsgrenzen, um Leistung/Watt zu stabilisieren. In Büros solltest du eine entfernte Rack-Platzierung oder leisere Workstation-Builds in Betracht ziehen (vermeide Blowersysteme).
Brauchen wir Hochgeschwindigkeitsnetzwerk (10/25GbE)?
Eigentlich nicht. KI-Verkehr ist überwiegend Text, und Text ist leicht, daher ist das selten der Engpass.
Kann ich AMD- oder Intel-GPUs verwenden?
Die kurze Antwort ist ja, aber praktisch lohnt es sich oft nicht. Das Problem ist die Ökosystem-Unterstützung (ROCm und Intel oneAPI) im Vergleich zu CUDA. Selbst wenn du etwas bei den Anfangskosten sparst, wirst du wahrscheinlich mehr kämpfen, und manchmal kannst du ein bestimmtes Modell oder eine Funktion einfach nicht nutzen.
Modellauswahl
Unternehmens-Setups profitieren von einer bewussten Modellpolitik statt "ein Modell für alles". In der Praxis empfehlen wir, ein kleines "Modellportfolio" zu definieren:
- Primäres Assistentenmodell (die beste Qualität, die du innerhalb deiner Latenz-/SLO-Grenzen betreiben kannst)
- Kosteneffizientes Modell für Aufgaben mit hohem Volumen (Klassifizierung, Extraktion, Routing, Entwürfe)
- Embeddings-Modell für RAG (und optional ein Reranker, wenn die Retrieval-Qualität wichtig ist)
Auswahlkriterien, die wir verwenden:
- Passung zu den Aufgaben: Chat vs. Übersetzungen vs. strukturierte Extraktion vs. Coding; gib nicht zu viel für ein großes Modell bei einfacher Klassifizierung aus.
- Serving-Effizienz: Die KV-Cache-Größe wächst mit dem Kontextfenster; der Kontext ist oft der eigentliche VRAM-Engpass.
- Lizenzen und Governance: Validiere die Lizenzkompatibilität (interne Nutzung, kundengerichtete Nutzung, Weitergabe) und dokumentiere genehmigte Modelle. Prüfe die Modelllizenzen von Hugging Face vor dem Deployment.
Unsere Basisempfehlungen
Die folgende Tabelle ist als Ausgangspunkt gedacht (der genaue VRAM hängt vom Backend, der Batch-Größe, dem Kontext und davon ab, ob du mehrere Modelle geladen hältst).
| Modell | Quantisierung | Kontextfenster | VRAM-Größe | Nutzung |
|---|---|---|---|---|
| Qwen3.6 35b (a3b) | Q5_K_M | 256k | 50GB | Coding, agentische Aufgaben, allgemeine Aufgaben |
| Qwen3.6 27b | Q5_K_M | 256k | 50GB | Wie der 35b, genauer in Benchmarks, aber langsamer |
| GLM 4.7 flash | Q5_K_M | 198k | 50GB | Coding, agentische Aufgaben, allgemeine Aufgaben |
| TranslateGemma | Q5_K_M | 128k | 35GB | Übersetzungen |
| Qwen2.5 Coder 14b (base) | Q5_K_M | 8k (bis zu 32k) | 25GB | Code-Vervollständigung |
| Nomic Embed 0.3b | FP16 | 2k | 1GB | Leichtes, zuverlässiges und portables Embeddings-Modell |
| Qwen3 Embedding 4b | Q8_0 | 40k | 20GB | Sehr genaues Embeddings-Modell, aber schwer, nützlich wenn du ein großes Kontextfenster brauchst |
| Flux 2 Klein 9b | FP8 | / | 10GB | Gut für fotorealistische Ergebnisse |
| GLM Image | FP8/FP16 | / | 20GB | Gut für gängige Bilder, auch mit Text |
Häufig gestellte Fragen
Welchen Durchsatz kann man erwarten?
Jedes unserer Beispiele ist sehr praxisnah. Eine 4× RTX 3090, die Qwen 3.6 35B mit einem Kontextfenster von 256k auf llama.cpp ausführt, liefert zum Beispiel 120 Tokens/Sek. für einen einzelnen Nutzer und 70 Tokens/Sek. für 3 gleichzeitige Anfragen, was besser ist als beispielsweise die Claude 4.6 API, ohne jegliche Nutzungsbeschränkung.
Wie wählen wir das richtige Kontextfenster?
Beginne beim Produktbedarf, nicht beim Modell-Datenblatt. Für die meisten Unternehmensassistenten reichen 8k-16k, wenn deine RAG-Pipeline gut ist (weniger abrufen, besser abrufen). Erhöhe den Kontext nur, wenn du echte Workflows mit langen Dokumenten hast (Verträge, große technische Spezifikationen, Code-Reviews über mehrere Dateien). Denke daran: Ein längerer Kontext erhöht den VRAM-Verbrauch (KV-Cache) und senkt oft den Durchsatz.
Wie wählen wir die richtige Quantisierung (FP16 vs. 8-Bit vs. 4-Bit)?
Verwende niemals FP16, außer bei sehr kleinen Modellen oder Bildgenerierung; es lohnt sich nicht. 8-Bit ist sehr gut für genauigkeitsempfindliche Aufgaben mit besserer Speichereinsparung. 4-Bit ist meist das beste Kosten-/Leistungsverhältnis für Chat und RAG in der Produktion, aber validiere an deinem eigenen Evaluierungsset (manche Aufgaben wie strikte Extraktion oder mehrsprachige Nuancen können sich verschlechtern). Bei Saphes empfehlen wir die Q5-Quantisierung; die Balance ist perfekt für unsere Nutzung, und wir haben bei dieser Quantisierung nie eine verschlechterte Ausgabe festgestellt.
Was beeinflusst den VRAM am stärksten?
Drei Hauptfaktoren: (1) Modellgewichte, (2) Kontextfenster (KV-Cache) und (3) Batching/Nebenläufigkeit. Viele Teams unterschätzen den KV-Cache: Eine Verdopplung des Kontexts kann den VRAM-Bedarf deutlich erhöhen, besonders bei höherer Nebenläufigkeit.
Sollten wir ein großes Modell oder mehrere kleinere ausführen?
Bevorzuge mehrere Modelle, wenn du eine klare Aufgabentrennung hast: einen starken Assistenten für "schwierige" Anfragen und ein günstigeres Modell für Routing, Zusammenfassung, Extraktion oder Entwürfe. Das senkt die Kosten und verbessert die Latenz unter Last.
Brauchen wir einen Reranker für RAG?
Wenn deine Dokumente verrauscht oder lang sind und die Retrieval-Qualität wichtig ist (Support-Wissensdatenbanken, juristische/technische Inhalte), verbessert ein Reranker die Genauigkeit oft stärker als eine Vergrößerung des Kontexts. Wenn dein Korpus klein und sauber ist, kannst du darauf verzichten.
Warum nicht ein großes Modell wie Kimi k2.5?
Sobald du eine bestimmte Größenordnung erreichst, haben zusätzliche Parameter immer weniger Einfluss auf die Qualität. Ein Modell wie Qwen 3.6 ist heute mehr als ausreichend für komplexe agentische Aufgaben; du musst dich nicht auf "Frontier"-Open-Source-Modelle wie Deepseek V4 verlassen. Die Leistungslücke ist den Aufwand nicht wert: Ein kleineres, gut konfiguriertes Modell ist mehr als ausreichend und viel schneller.
Sollte ich mehrere Modelle oder ein großes Flaggschiff-Modell verwenden?
Wir empfehlen, ein Flaggschiff-Modell zu haben, das für die meisten Aufgaben immer auf deinen GPUs geladen ist. Halte etwas VRAM für nützliche kleinere Modelle frei, etwa einen Übersetzungsspezialisten und Code-Vervollständigung; diese belegen nicht viel VRAM und sind sehr schnell in dem, was sie tun. Das hilft auch, gleichzeitige Anfragen von deinem Flaggschiff-Modell abzulasten.
Software-Stack / Tooling
Ein typischer selbst gehosteter Stack ist modular und kann klein beginnen:
Inferenz
Für die Inferenz gibt es derzeit drei echte Herausforderer. Jeder bietet eine OpenAI-kompatible API, und jeder hat Stärken und Kompromisse:
| Lösung | Vorteile | Nachteile |
|---|---|---|
| Ollama | Schnell einzurichten, benutzerfreundlich: ein paar Befehle und dein Modell läuft. | Langsamer als die anderen Lösungen; lädt/entlädt Modelle häufig, wenn eine Anfrage nicht zu dem passt, was bereits geladen ist. |
| Llama server (llama.cpp) | Sehr schnell und solide bei Nebenläufigkeit; hoher Grad an Anpassung; breite Modellauswahl und Formatunterstützung. | Lädt jeweils ein Modell; länger einzurichten als Ollama. |
| vLLM | Ausgezeichnet für Nebenläufigkeit; die richtige Wahl für ein Flaggschiff-Modell in großem Maßstab; ermöglicht ein hohes Maß an Anpassung. | Langsamer als llama.cpp bei einzelnen Anfragen; länger einzurichten als Ollama; weniger unterstützte Formate als llama.cpp. |
UI / Gateway
Es gibt eine herausragende Option: Open WebUI. Open WebUI fungiert als Gateway und bietet granulare Zugriffskontrolle. Es bringt außerdem viele Funktionen mit, darunter das Proxying von Ollama (falls du es nutzt) sowie anderer verbundener OpenAI-kompatibler APIs.
Open WebUI kann mit ComfyUI für die Bildgenerierung gekoppelt werden; beide interagieren gut miteinander und schaffen ein GPT-ähnliches Erlebnis bei der Bildgenerierung.
RAG
Ein RAG-System (Retrieval-Augmented Generation) ist für viele Anwendungsfälle entscheidend, und je mehr Dokumente dein Unternehmen hat, desto wichtiger wird es. RAG ermöglicht es dir, Ausschnitte deiner Dokumente zu speichern und, statt für jede Frage 300 Seiten in das Kontextfenster zu injizieren, nur die relevanten Teile zusammen mit Metadaten (Dokumentname, Seitenreferenz usw.) abzurufen. Erfahre mehr über die RAG-Architektur und Best Practices.
Für Entwicklungszwecke ist RAG oft weniger nützlich (zum Beispiel ist es nicht realistisch, für jeden Branch eine ganze Codebasis neu zu embedden). Im Gegensatz dazu kann das Embedden strukturierter Dokumentation für ein Framework oder eine Sprache sehr hilfreich sein.
Bevor du ein RAG-System einrichtest (was einfach zu starten ist), ist der wichtigste Teil die Definition, was in deiner Datenbank stehen soll und welche Metadaten du brauchst. Die Architektur ist wichtig: Sie bestimmt, ob dein RAG-System in der Praxis nutzbar sein wird.
Du kannst ChromaDB oder Qdrant auf deinem Server betreiben. Beide sind gut; wir empfehlen Qdrant, weil es schnell und gut gestaltet ist (diese Empfehlung ist subjektiv).
Code-Editoren
Für eine local-first, KI-gestützte Entwicklung empfehlen wir das folgende Setup:
Zed: unsere Standardempfehlung. Es integriert KI nativ, unterstützt ACP und andere moderne Tooling und ist extrem schnell und reaktionsschnell. Siehe die KI-Dokumentation von Zed für Einrichtungsdetails.
VS Code oder JetBrains:
- Continue für Code-Vervollständigung und schnelle Chat-artige Antworten.
- Cline für stärker agentische Workflows (mehrstufige Aufgaben, repo-weite Änderungen, Tooling-Orchestrierung).
MCPs
Es gibt reichlich MCPs auf dem Markt. Die richtigen sind einfach die, die du brauchst. Am wichtigsten ist das Deployment: MCPs können auf verschiedene Arten laufen und unterschiedliche Verbindungstypen unterstützen. Wir empfehlen streamable HTTP-Verbindungen für MCPs, die sich mit deinem Server verbinden müssen, und sie direkt auf dem Server auszuführen.
Ein solides Set an MCPs, oder die Entwicklung derer, die du brauchst, kann ein Game Changer sein. MCPs sind vor allem durch die Vorstellungskraft begrenzt: Du kannst ein MCP entwickeln, um mit deiner E-Commerce-Plattform, deinem CMS zu sprechen, Inhalte zu erstellen und abzurufen, Produkte anzulegen und vieles mehr. Erfahre mehr über die Spezifikation des Model Context Protocol und erkunde das MCP Registry für von der Community entwickelte Integrationen.
Abschließende Gedanken
Heute ist die Integration selbst gehosteter KI in ein Unternehmen kein Moonshot mehr: Sie ist konkret und machbar. Modelle sind heute intelligent und schnell genug, um komplexe Aufgaben zu bewältigen, ein gut konfiguriertes RAG-System kann die meisten automatisierten RAG-Lösungen auf dem Markt übertreffen, UI-Tools sind benutzerfreundlich geworden, und der ROI wird oft schnell erreicht, typischerweise innerhalb von 6 bis 24 Monaten, je nach Komplexität deiner Systeme.
Dennoch gibt es wichtige Überlegungen. Das anfängliche Setup kann kompliziert sein: Treiberprobleme, das Verbinden von Tools, die Konfiguration des RAG-Systems und die Auswahl der richtigen Modelle. Für uns sind die größten Kosten nicht die Hardware, sondern das zeitaufwändige Setup, während die laufende Wartung meist viel einfacher ist.
