Der Baukasten
Die Technologien hinter einer eigenen KI
Vier Bausteine, jeweils mehrere ernsthafte Kandidaten. Diese Seite sagt, wofür sich welcher eignet – und wo der Unterschied im Betrieb tatsächlich auffällt.
Vier Bausteine, jeweils mehrere ernsthafte Kandidaten. Diese Seite sagt, wofür sich welcher eignet – und wo der Unterschied im Betrieb tatsächlich auffällt.
Ein Produkt namens „eigene KI“, das man installiert, gibt es nicht. Was man aufbaut, ist eine Kette: Ein Inferenz-Server führt das Sprachmodell aus. Eine Vektordatenbank hält Ihre Dokumente durchsuchbar. Ein RAG-Framework verbindet beides. Eine Oberfläche macht das Ganze für Mitarbeitende bedienbar.
Für jede dieser Schichten gibt es mehrere ausgereifte Open-Source-Projekte. Die Auswahl ist selten eine Frage von besser oder schlechter, sondern eine Frage der Betriebsgröße: Ein Werkzeug, das für fünf Nutzer ideal ist, wird bei hundert gleichzeitigen Anfragen zum Engpass.
Wie die Schichten zusammenspielen, steht auf der Seite KI-Architektur. Hier geht es um die Auswahl innerhalb einer Schicht.
Der Inferenz-Server lädt das Modell und beantwortet Anfragen. Die Wahl entscheidet darüber, wie viele Menschen gleichzeitig arbeiten können, ohne zu warten.
| Werkzeug | Stärke | Passt, wenn |
|---|---|---|
| Ollama | In Minuten eingerichtet, verwaltet Modelle selbst, läuft auch ohne dedizierte Grafikkarte | überschaubare Nutzerzahl, Pilotbetrieb, Abteilungslösung |
| vLLM | Bündelt gleichzeitige Anfragen und nutzt den Speicher für den Gesprächsverlauf effizienter | viele parallele Nutzer, produktiver Dauerbetrieb |
| llama.cpp | Läuft praktisch überall, verteilt ein Modell bei Bedarf auf Grafikkarte und Hauptspeicher | knappe oder ungewöhnliche Hardware, Sonderfälle |
| TGI | Aus dem Hugging-Face-Umfeld, ähnlich ausgerichtet wie vLLM | bestehende Hugging-Face-Infrastruktur |
Unter Last zeigt sich der Unterschied. Bei einer einzelnen Anfrage liegen Ollama und vLLM nah beieinander. Stellen zehn Menschen gleichzeitig eine Frage, arbeitet Ollama sie weitgehend nacheinander ab, während vLLM sie zusammenfasst und gemeinsam durch die Grafikkarte schickt. In Messungen anderer liegt der Durchsatz dann um ein Mehrfaches auseinander. Für einen Pilotbetrieb mit fünf Personen spielt das keine Rolle. Für einen Support-Assistenten, der im Tagesgeschäft mitläuft, entscheidet es über die Wartezeit.
Unser üblicher Weg: Der Pilot startet auf Ollama, weil er damit in einem Tag steht. Der Wechsel auf vLLM kommt, wenn die Nutzung es verlangt – beide sprechen dieselbe Schnittstelle, die Anwendungen darüber merken davon nichts.
Hier liegen Ihre Dokumente in der Form, in der die KI sie durchsuchen kann. Die Auswahl hängt weniger an der Suchqualität als daran, was Sie ohnehin betreiben.
Unsere Standardwahl für neue Systeme. Filtert zuverlässig nach Metadaten – also etwa nach Abteilung, Aktualität oder Berechtigung – und bleibt dabei schnell. Genau das braucht man, sobald nicht jeder alles sehen darf.
Eine Erweiterung für PostgreSQL. Wenn Sie ohnehin eine PostgreSQL-Datenbank betreiben, sparen Sie sich ein zusätzliches System samt Backup, Monitoring und Updates. Bei sehr großen Datenmengen stößt sie eher an Grenzen.
Bringt viel mitgeliefertes Zubehör mit, etwa eigene Module zum Erzeugen der Vektoren. Das nimmt Arbeit ab und bindet zugleich stärker an die Denkweise des Projekts.
Ehrliche Einordnung: Bei einigen zehntausend Dokumenten liefern alle drei brauchbare Ergebnisse. Der Unterschied im Projekt entsteht fast nie an der Suchqualität, sondern am Betriebsaufwand – ein System weniger im Haus ist ein Argument, das nach zwei Jahren noch zählt.
Das Framework verbindet Dokumente, Suche und Modell. LlamaIndex ist auf genau diese Aufgabe zugeschnitten und bleibt entsprechend übersichtlich. LangChain kann deutlich mehr – Werkzeugaufrufe, mehrstufige Abläufe, Agenten – und ist dafür schwerer zu durchschauen. Haystack liegt dazwischen und legt Wert auf klar beschriebene Pipelines.
Für eine reine Wissenssuche über Firmendokumente ist LangChain meist mehr Werkzeug als nötig. Sobald die KI aber Aktionen auslösen soll – ein Ticket anlegen, einen Bestand abfragen – kehrt sich das um.
Wie die Pipeline im Einzelnen arbeitet, steht unter Eigene Daten in die KI bringen.
Die Wahl des Frameworks entscheidet weniger über die Antwortqualität als das Embedding-Modell – jener Baustein, der Text in Zahlen übersetzt. Wer deutschsprachige Dokumente durchsuchen will, braucht ein mehrsprachiges Modell.
Ein auf Englisch trainiertes Embedding findet in deutschen Texten spürbar schlechter. Das ist einer der häufigsten Gründe, warum ein RAG-System „irgendwie nicht die richtigen Stellen findet“ – und er hat nichts mit dem Sprachmodell zu tun, dem man es zuerst anlastet.
Was Mitarbeitende sehen, ist eine Chat-Oberfläche. Open WebUI ist hier der verbreitetste Weg: Anmeldung über das vorhandene Firmenkonto, Rechte pro Gruppe, Gesprächsverläufe, Dokumenten-Upload. Wer ChatGPT kennt, findet sich ohne Schulung zurecht.
Dass die Oberfläche vertraut aussieht, ist kein Nebenaspekt. Eine KI, die anders bedient wird als das, was die Leute privat nutzen, wird im Alltag umgangen.
Offene Sprachmodelle wie Llama, Mistral, Qwen oder Gemma sind austauschbare Teile, keine Grundsatzentscheidung. Ein neues Modell einzusetzen dauert bei sauberem Aufbau Minuten.
Genau prüfen muss man die Lizenz: Nicht jedes frei herunterladbare Modell darf ohne Weiteres kommerziell eingesetzt werden. Manche Lizenzen knüpfen Bedingungen an die Unternehmensgröße oder verlangen eine Namensnennung. Wir klären das vor der Auswahl, nicht danach.
Die Frage kommt in jedem Gespräch. Sie lässt sich überschlagen, und das reicht für die Planung: Der Speicherbedarf ergibt sich aus der Zahl der Parameter mal dem Speicher je Parameter – und der hängt an der Quantisierung.
Ein Modell wird ursprünglich mit hoher Genauigkeit gespeichert, üblicherweise zwei Byte je Parameter. Quantisierung senkt diese Genauigkeit: Bei 8 Bit ist es etwa ein Byte, bei 4 Bit rund ein halbes. Der Speicherbedarf sinkt entsprechend, die Antwortqualität nimmt messbar, aber für die meisten Büroaufgaben verkraftbar ab.
In der Praxis ist die 4-Bit-Variante eines größeren Modells fast immer die bessere Wahl als die volle Variante eines kleineren. Mehr Wissen im Modell wiegt schwerer als die letzten Prozente Präzision.
Neben dem Modell selbst belegt der Kontext Speicher – alles, was das Modell gerade „im Kopf behält“. Dieser Anteil wächst mit der Länge des Gesprächs und mit der Zahl gleichzeitiger Nutzer.
Deshalb genügt es nicht, den Modellbedarf auszurechnen und eine Karte in dieser Größe zu kaufen. Wir planen einen Puffer ein; ohne ihn treten Speicherfehler genau dann auf, wenn das System zum ersten Mal wirklich genutzt wird.
Konkrete Größenordnungen aus dem eigenen Betrieb – mit gemessenen Zeiten statt Faustformeln – stehen unter Lokale KI: Hardware, Kosten und Grenzen. Fertig konfigurierte Maschinen samt Preisen finden Sie unter KI-Server kaufen oder mieten.
Kein Baukasten ohne Empfehlung. Für einen ersten produktiven Firmen-Chatbot setzen wir in der Regel auf Ollama, Qdrant, LlamaIndex und Open WebUI – vier Komponenten, die sich einzeln austauschen lassen, sobald es Gründe dafür gibt.
Der häufigste erste Wechsel ist der Inferenz-Server, wenn die Nutzerzahl steigt. Der zweithäufigste ist das Embedding-Modell, wenn sich zeigt, dass die Suche in Ihren Fachbegriffen nicht sauber trifft.
Ollama, solange wenige Personen gleichzeitig arbeiten; vLLM, sobald es viele werden. Der Unterschied liegt nicht in der Antwortqualität, sondern im Durchsatz: Ollama arbeitet Anfragen weitgehend nacheinander ab, vLLM bündelt sie und schickt sie gemeinsam durch die Grafikkarte. Bei rund zehn gleichzeitigen Nutzern liefert vLLM in Messungen ein Mehrfaches an Durchsatz. Beide sprechen dieselbe Schnittstelle, ein späterer Wechsel ist deshalb unkritisch.
Für neue Systeme meist Qdrant, weil es zuverlässig nach Berechtigungen und Metadaten filtert. Wenn Sie ohnehin PostgreSQL betreiben, ist pgvector die sparsamere Wahl — bis in den Bereich einiger Millionen Textabschnitte arbeitet es ohne Auffälligkeiten, und Sie sparen sich ein zusätzliches System im Betrieb. Die Suchqualität unterscheidet sich in dieser Größenordnung kaum; der Betriebsaufwand schon.
Eine größere, als die meisten erwarten. Ein nur auf Englisch trainiertes Embedding erkennt deutsche Komposita und Beugungen schlecht und findet deshalb die falschen Stellen. Für deutschsprachige Unterlagen setzen wir ausschließlich mehrsprachige Modelle ein. Wenn ein RAG-System „irgendwie nicht das Richtige findet", liegt es häufiger hieran als am Sprachmodell, dem man es zuerst anlastet.
Meistens ja, aber nicht ausnahmslos — und das ist vor der Auswahl zu klären, nicht danach. Einige Modelle stehen unter freien Lizenzen ohne Einschränkung, andere knüpfen die kommerzielle Nutzung an Bedingungen, etwa an die Größe des Nutzerkreises, oder erlauben in der frei verfügbaren Fassung nur Forschung. Wir prüfen die Lizenz jedes Modells, bevor es in einem Kundensystem landet.
Wir empfehlen keine Technologie, ohne Ihre Nutzerzahl und Ihre Datenlage zu kennen.
Direkter Kontakt – ohne Umwege. Wir melden uns innerhalb eines Werktages.