Die Werkzeuge für eigene Sprachmodelle sauber sortiert: Wer macht was, was trägt eine Abteilung – und was bleibt Testumgebung?
Kostenlose KI-Erstberatung anfragen →
Zufriedene Kunden der Suchhelden GmbH
Hinweis zur Aktualität: Dieses Werkzeug-Ökosystem verändert sich schnell. Projekte wechseln den Schwerpunkt, neue Oberflächen tauchen auf, andere verschwinden. Wir halten diese Seite deshalb regelmäßig nach und weisen das Aktualisierungsdatum sichtbar aus. Wenn Dir eine Einschätzung überholt vorkommt, sag uns Bescheid.
Wer anfängt, Sprachmodelle selbst zu betreiben, stolpert schnell über dieselben Namen. Ollama, vLLM, llama.cpp, LM Studio, Open WebUI. In Foren werden sie im selben Atemzug genannt. In Angeboten stehen sie nebeneinander. Und in Meetings sagt jemand „wir nehmen Ollama", bevor überhaupt geklärt ist, wofür.
Das ist der häufigste Fehler in diesem Bereich. Diese LLM-Werkzeuge lösen unterschiedliche Probleme. Manche führen ein Modell aus. Andere sind nur die Oberfläche davor. Wieder andere sind zum Ausprobieren am eigenen Arbeitsplatz gedacht. Sie sind keine Alternativen zueinander, sondern Bausteine, die zusammen ein System ergeben.
„Du kannst um die Welt fliegen um international Business zu machen – wir bringen Dein Business zum Fliegen. Wir bewegen uns durch datenbasierte Customer Journeys, setzen auf transparente Zusammenarbeit und positionieren Dein Business an die Spitze. Ein Business braucht keine Superkräfte, aber es braucht Helden – Suchhelden. Denn nicht alle Helden tragen Capes.“
Ollama Server, vLLM & Open WebUI: Welches Werkzeug wofür?
Diese Seite sortiert den Werkzeugkasten. Wir erklären, welche Rolle jedes Werkzeug spielt, wo seine natürliche Grenze liegt und welche Kombination zu welcher Ausgangslage passt. Was Du hier nicht findest: Installationsbefehle, Konfigurationsdateien oder Systemanforderungen. Dafür gibt es die Projektdokumentationen – und die sind schneller aktuell, als eine Ratgeberseite je sein kann.
Uns geht es um die Entscheidung davor. Die teuren Fehler passieren nämlich nicht bei der Installation. Sie passieren, wenn ein Werkzeug für eine Aufgabe eingesetzt wird, für die es nie gedacht war.
Welche Werkzeuge laufen, legen wir in Schritt 2 fest und richten sie in Schritt 4 auf Eurem Server ein.
So setzen wir das mit Euch um: Ziele verstehen → Stack und Modelle wählen → Ihr mietet den Server nach unserer Vorgabe → wir richten ihn ein und betreuen ihn → wir führen die KI bei Euch ein → wir trainieren sie, bis Eure Ziele erreicht sind. Den Ablauf im Detail ansehen
Jetzt anfragen →Lass uns gemeinsam herausfinden, wo Künstliche Intelligenz in Deinem Unternehmen den größten Nutzen stiftet – ehrlich, unverbindlich und auf Augenhöhe. Wenn sich ein Projekt für Dich nicht rechnet, sagen wir Dir das genauso klar.
Es beginnt fast immer gleich. Jemand aus der IT installiert ein Modell auf dem eigenen Rechner. Es funktioniert erstaunlich gut. Kolleg:innen sehen es, finden es nützlich und wollen auch Zugriff. Ein paar Wochen später hängen fünfzehn Leute an einem Aufbau, der für eine Person gedacht war.
Dann kommen die Fragen, die vorher niemand stellen musste. Wer darf eigentlich was sehen? Wo werden die Verläufe gespeichert? Und wer ist erreichbar, wenn es morgens klemmt?
Die Antwort ist selten ein größerer Rechner. Es ist ein anderer Aufbau. Ein Werkzeug für einzelne Arbeitsplätze bringt keine Benutzerverwaltung mit, weil es sie nie brauchte. Das nachzurüsten ist aufwendiger, als es gleich richtig zu bauen.
„Wir setzen auf Ollama." Dieser Satz fällt oft, bevor jemand sagen kann, wie viele Menschen das System nutzen sollen. Er ist dann keine Entscheidung, sondern eine Abkürzung. Bekannt ist nicht dasselbe wie passend.
Das Problem daran: Die Werkzeuge unterscheiden sich vor allem darin, wie sie mit gleichzeitigen Anfragen umgehen. Ein Werkzeug für den Einzelplatz bearbeitet eine Anfrage nach der anderen. Ein Werkzeug für den Serverbetrieb nimmt viele Anfragen parallel an.
Wer zuerst das Werkzeug festlegt, muss die Anforderungen danach passend schrumpfen. Die Reihenfolge entscheidet deshalb mehr als die Werkzeugwahl selbst.
Der dritte Fall ist der unangenehmste. Das System läuft, wird genutzt und ist nirgends erfasst. Es steht in keinem Inventar. Es taucht in keinem Update-Plan auf. Die Person, die es aufgesetzt hat, ist inzwischen in einem anderen Projekt.
Solche Installationen altern still. Sicherheitsaktualisierungen bleiben aus, Modelle veralten. Und wenn jemand aus der Revision fragt, wer wann was abgefragt hat, gibt es keine Antwort.
Das ist kein Werkzeugproblem, sondern ein Zuständigkeitsproblem. Die Werkzeugwahl beeinflusst aber, wie leicht sich Zuständigkeit organisieren lässt. Ein System mit zentraler Benutzerverwaltung lässt sich übergeben. Ein Aufbau auf einem Einzelrechner nicht.
Die Tabelle sieht nach einer Rangliste aus, ist aber keine. Es gibt hier kein bestes Werkzeug, weil die Zeilen unterschiedliche Fragen beantworten. Ollama, vLLM und llama.cpp führen Modelle aus. Open WebUI und LibreChat tun das nicht – sie geben Menschen eine Oberfläche dafür. Gateway und Werkzeug-Anbindung sind noch einmal etwas anderes: Sie regeln, wer worauf zugreifen darf.
Die eigentliche Entscheidung liegt deshalb nicht in einer Spalte, sondern in der Kombination. In fast jedem Unternehmensaufbau braucht es zwei Bausteine: etwas, das das Modell ausführt, und etwas, durch das Menschen es erreichen. Welcher Baustein unten steht, hängt an der erwarteten Last. Welcher oben steht, hängt daran, wie Ihr Benutzer und Rechte verwaltet. Ab einer gewissen Größe kommt die Gateway-Schicht dazwischen.
Zuerst steht die Frage, was das System eigentlich tun soll. Nur chatten? Dokumente auswerten? Im Hintergrund Daten verarbeiten? Diese drei Fälle führen zu unterschiedlichen Aufbauten. Ein reiner Chat-Zugang ist deutlich einfacher als ein System, das automatisiert Dokumente durchschiebt.
Wichtig ist auch die Art der Nutzung. Gelegentliche Fragen belasten ein System anders als ein Prozess, der ununterbrochen arbeitet. Wir fragen deshalb nicht nach Wunschtechnik, sondern nach dem Arbeitsalltag.
Der zweite Schritt entscheidet am meisten. Arbeitet eine Person damit, ein Team oder das halbe Unternehmen? Und vor allem: Wie viele davon gleichzeitig? Das ist die Zahl, die zählt – nicht die Zahl der Konten.
Aus dem Nutzerkreis folgt fast automatisch die Laufzeitumgebung. Für einzelne Rechner und Testaufbauten reicht ein schlankes Werkzeug. Sobald viele Menschen parallel Anfragen stellen, braucht es eine Umgebung, die genau dafür gebaut ist. Diesen Übergang planen wir bewusst, statt ihn im laufenden Betrieb zu erleben.
Jetzt geht es um den Ort. Läuft das System auf einem Arbeitsplatzrechner, auf einem Server im Haus oder auf gemieteter Kapazität in einem deutschen Rechenzentrum? Davon hängt ab, wie das Netz aussieht, wie die Anmeldung funktioniert und wie Updates eingespielt werden.
Hier fällt auch die Entscheidung über die Oberfläche. Eine Chat-Umgebung für Teams gehört an Euer bestehendes Benutzerverzeichnis angebunden. Dann müssen keine zweiten Passwörter gepflegt werden, und ausgeschiedene Kolleg:innen verlieren den Zugang automatisch. Wer das überspringt, baut eine Nebenwelt neben der eigenen IT. Für Teams richten wir das auf einem Server ein, den Ihr nach unserer Vorgabe mietet – und betreuen ihn über die gesamte Laufzeit.
Der letzte Schritt wird am häufigsten vergessen. Wer betreut das System? Wer spielt Updates ein? Wer schaut auf die Auslastung? Und wen rufen die Nutzer:innen an, wenn etwas nicht geht? Ohne Antwort auf diese vier Fragen ist kein Aufbau fertig.
Dazu gehört die unspektakuläre Seite: Protokollierung einschalten, Backups aufsetzen, einen Update-Weg festlegen. Das ist der Teil, den niemand vorzeigt. Er entscheidet trotzdem, ob das System in einem Jahr noch läuft.
Ein Ollama Server ist ein Rechner, auf dem die Software Ollama läuft und ein Sprachmodell über eine Schnittstelle bereitstellt. Ollama ist also kein Modell und keine Oberfläche. Es ist eine Laufzeitumgebung: Sie lädt das Modell, führt es aus und nimmt Anfragen entgegen. Andere Programme können diese Schnittstelle ansprechen.
vLLM erfüllt dieselbe Grundaufgabe, ist aber für andere Größenordnungen gebaut. Der Schwerpunkt liegt darauf, viele Anfragen gleichzeitig zu bedienen, ohne dass die Nutzer:innen warten. Deshalb ist vLLM die übliche Wahl, wenn ein Inferenz-Server eine ganze Abteilung oder ein Unternehmen versorgen soll. Der Begriff Inferenz meint dabei schlicht das Anwenden eines fertig trainierten Modells.
Der Unterschied ist also keine Frage von besser oder schlechter. Er liegt im Einsatzzweck. Beide führen dieselben frei verfügbaren Modelle aus.
Die meisten Missverständnisse lösen sich auf, sobald man drei Schichten trennt. Ganz unten liegt das Modell. Das ist eine Datei mit trainierten Gewichten, für sich allein nicht benutzbar. Welche Modelle es gibt und wie sie sich unterscheiden, haben wir in unserem Ratgeber zu den Modellen im Vergleich beschrieben.
Darüber liegt die Laufzeitumgebung. Sie lädt das Modell in den Speicher, führt es aus und stellt eine Schnittstelle bereit. Ollama, vLLM und llama.cpp gehören in diese Schicht. Sie sind austauschbar, solange die Schnittstelle gleich bleibt.
Ganz oben liegt die Oberfläche. Sie ist das, was Deine Kolleg:innen tatsächlich sehen: ein Chatfenster, eine Anmeldung, eine Auswahl an Modellen, gespeicherte Verläufe. Open WebUI und LibreChat gehören hierher. Sie führen selbst kein Modell aus, sondern sprechen die Schnittstelle darunter an.
Im Unternehmensbetrieb kommt eine vierte Schicht dazu. Zwischen Laufzeitumgebung und Oberfläche sitzt dann ein zentraler Vermittlungsdienst, das Gateway. Die Reihenfolge lautet damit: Modell, Laufzeitumgebung, Gateway, Oberfläche. Warum sich dieser Zwischenschritt lohnt, beschreiben wir weiter unten im Werkzeug-Kapitel.
Wer diese Schichten sauber auseinanderhält, kann jede einzeln tauschen. Ein anderes Modell, ohne dass die Oberfläche sich ändert. Eine andere Laufzeitumgebung, ohne dass Nutzer:innen etwas merken. Genau das ist die praktische Bedeutung von Kein Vendor-Lock-in auf technischer Ebene.
Der Markt wartet nicht – belegte Zahlen
stufen generative KI als geschäftskritisch ein.
KPMG 2025der Mittelständler haben noch keine konkrete KI-Strategie.
KI-Index Mittelstand, H-KAjährliches Produktivitätspotenzial generativer KI weltweit.
McKinsey Global InstituteIm Folgenden beschreiben wir die Rolle jedes Werkzeugs, nicht seine Bedienung. Messwerte findest Du bewusst keine – sie veralten schnell.
Ollama ist der bequemste Einstieg in den Eigenbetrieb. Modelle lassen sich mit wenig Aufwand laden und ansprechen, die Schnittstelle ist an gängige Standards angelehnt. Genau deshalb ist Ollama in Testumgebungen und auf Entwicklungsrechnern so verbreitet.
Für kleine, klar abgegrenzte Installationen ist das ausreichend. Sobald aber Rechte, Protokollierung und viele gleichzeitige Nutzer:innen dazukommen, endet der natürliche Einsatzbereich. Ollama ist dann nicht kaputt – es war nur nie dafür gedacht.
Daneben gibt es inzwischen Ollama Cloud, also Modellleistung über fremde Infrastruktur. Das ist bequem, aber kein Eigenbetrieb mehr. Wer aus Datenschutzgründen selbst betreibt, sollte diesen Unterschied kennen.
Open WebUI ist die Chat-Oberfläche für Teams. Sie bringt mit, was die Laufzeitumgebungen bewusst weglassen: Benutzerkonten, Rollen und Gruppen, Verläufe, eine Modellauswahl und geteilte Vorlagen für wiederkehrende Aufgaben.
Das macht sie zum Schlüsselstück im Unternehmensaufbau. Erst hier entsteht aus einer technischen Schnittstelle ein Werkzeug, das Kolleg:innen ohne Einweisung benutzen. Auch die Anbindung des Firmenwissens läuft üblicherweise über diese Schicht. Wer die Oberfläche als Nebensache behandelt, wundert sich später über die geringe Nutzung.
LM Studio ist eine Oberfläche zum Ausprobieren am eigenen Arbeitsplatz. Modelle lassen sich laden und direkt im Gespräch testen, ohne dass jemand einen Server aufsetzen muss. Für die erste Orientierung ist das hervorragend.
Als Grundlage für den Unternehmensbetrieb ist es nicht gedacht. Es läuft auf einem einzelnen Rechner und kennt keine zentrale Verwaltung. Genau darin liegt aber sein Wert: Wer wissen will, was Modelle heute leisten, kommt hier am schnellsten ans Ziel.
Bis hierher kann das System vor allem eines: reden. Interessant wird es, wenn das Modell auf interne Systeme zugreifen darf. Dafür gibt es eine standardisierte Werkzeug-Anbindung, bekannt unter dem Kürzel MCP.
Die Idee dahinter ist einfach. CRM, Ticketsystem, Dateiablage oder Datenbank werden als Werkzeuge beschrieben und bereitgestellt. Das Modell nutzt sie, wenn die Aufgabe es verlangt. Es ruft dann selbst einen Vorgang ab, prüft einen Status oder legt einen Eintrag an – statt nur zu erklären, wie das ginge.
Das ist der Schritt vom Chatfenster zum Assistenten, der in Prozessen arbeitet. Er will sorgfältig eingerichtet sein. Jedes angebundene Werkzeug bekommt eigene Grenzen, und schreibende Zugriffe behandeln wir zurückhaltender als lesende. Auch hier ist die Technik der kleinere Teil. Der größere ist die Festlegung, wer was auslösen darf.
vLLM ist das Arbeitstier für den Unternehmensbetrieb. Es ist darauf ausgelegt, viele Anfragen parallel anzunehmen und die vorhandene Rechenleistung gut auszunutzen. Arbeitet eine ganze Abteilung damit, verhält sich ein solcher Aufbau spürbar ruhiger als eine Einzelplatz-Lösung.
Dafür braucht es mehr Einrichtungsaufwand. vLLM erwartet, dass jemand bewusst entscheidet, welches Modell wie bereitgestellt wird. Auch die passende Server-Ausstattung will vorher geklärt sein. Im Gegenzug verhält sich das System unter Last vorhersehbar.
llama.cpp ist die Grundlage dafür, dass Modelle auch auf bescheidener Hardware laufen, ohne spezialisierte Grafikbeschleunigung. Viele bequemere Werkzeuge bauen im Kern darauf auf.
Für den Alltag im Unternehmen ist llama.cpp selten die direkte Wahl. Es ist eher Fundament als Bedienoberfläche. Interessant wird es dort, wo wenig Hardware zur Verfügung steht – oder beim Betrieb ohne Internetverbindung.
Bei ernsthaftem Betrieb kommt ein Baustein dazu, der in Werkzeuglisten meist fehlt. Zwischen Oberfläche und Modell sitzt ein zentraler Vermittlungsdienst, oft Gateway genannt. Er nimmt alle Anfragen entgegen und leitet sie an die passende Laufzeitumgebung weiter. Die Nutzer:innen bekommen davon nichts mit.
Entscheidend ist, wie dieser Dienst nach außen auftritt. Er stellt eine Schnittstelle bereit, die kompatibel zu der der großen Anbieter ist. Das hat drei Folgen.
Erstens lassen sich bestehende Tools, Skripte und Automatisierungen ohne Umbau anbinden. Was heute gegen einen externen Dienst arbeitet, zeigt danach auf Euer eigenes System. Meist genügen eine andere Adresse und ein anderer Zugangsschlüssel.
Zweitens laufen Rechte, Budgets, Protokollierung und Nutzungsübersichten an einer Stelle zusammen. Wer darf welches Modell ansprechen? Wie stark wird das System genutzt? Welche Abteilung erzeugt welche Last? Das beantwortet das Gateway, nicht jede Anwendung für sich.
Drittens lassen sich mehrere Modelle parallel bereitstellen und tauschen. Ein schnelles für den Alltag, ein stärkeres für schwierige Fälle, dazu vielleicht ein Spezialmodell. Ein Modellwechsel wird damit zur Einstellung statt zum Projekt.
Über dieselbe anbieterkompatible Schnittstelle lassen sich auch Automatisierungsplattformen anbinden. Werkzeuge wie n8n verketten einzelne Schritte zu einem Ablauf und können selbst im eigenen Haus betrieben werden. Ein eingehendes Dokument wird geprüft, eingeordnet, zusammengefasst und weitergereicht. So wächst aus dem Chat eine KI-Prozessautomatisierung.
Warum KI-Helden
Keine lange Vertragsbindung. Volle Flexibilität, volle Kostenkontrolle.
Statt sechsstelliger Projektkosten: flexibles Monatsmodell.
Modellunabhängig und immer am neuesten Stand — keine Bindung an ein LLM.
Persönlicher Ansprechpartner, Jour-Fixe-Calls und dediziertes Umsetzungsteam.
Die folgenden Situationen decken fast alles ab, was uns in Projekten begegnet. Such Dir die, die Eurer Lage am nächsten kommt.
Ziel ist Orientierung, nicht Betrieb. Hier reicht ein Werkzeug für den Arbeitsplatz: LM Studio zum Testen verschiedener Modelle, alternativ Ollama, wenn später eine Schnittstelle gebraucht wird. Wichtig ist nur, dass keine vertraulichen Inhalte in nicht freigegebene Umgebungen wandern.
Sobald mehrere Menschen dasselbe System nutzen, braucht es eine Oberfläche mit Konten und Rollen. Typisch ist Open WebUI vor einer Laufzeitumgebung. Ob darunter Ollama oder vLLM läuft, hängt daran, wie viele Anfragen gleichzeitig auflaufen. Für eine überschaubare Abteilung mit gelegentlicher Nutzung genügt oft noch der schlanke Weg.
Jetzt ist vLLM die naheliegende Grundlage, mit Open WebUI oder einer vergleichbaren Oberfläche davor. Anmeldung über das bestehende Benutzerverzeichnis, Rollen und Gruppen sauber abgebildet, Protokollierung eingeschaltet. Hier gehören auch Datenschutz und Betriebsrat früh an den Tisch – mehr dazu auf unserer Seite zum Datenschutz bei eigener KI.
In Produktion, kritischer Infrastruktur und Verwaltung gibt es Netze ohne Außenverbindung. Der Aufbau funktioniert dort genauso, nur müssen Modelle und Aktualisierungen kontrolliert hereingereicht werden. Das ist der klassische Fall für den Betrieb im eigenen Haus. Gehostete Varianten wie Ollama Cloud scheiden hier grundsätzlich aus. Unser Standard bleibt auch hier der gemietete Server auf Euren Namen. Hardware im eigenen Haus setzen wir nur in Absprache um – mit einer Partnerfirma, die sie bei Euch aufbaut und betreut.
Entwicklungsteams sind meist die ersten Nutzer:innen. Sie wollen Modelle direkt über die Schnittstelle ansprechen, nicht über ein Chatfenster. Hier bewährt sich eine gemeinsame Laufzeitumgebung im Netz statt vieler Einzelinstallationen auf Notebooks. Nebenbei entsteht das Wissen, das später den Unternehmensbetrieb trägt.
Wenn ein System ununterbrochen Dokumente verarbeitet, gelten andere Regeln. Dann zählt Verlässlichkeit mehr als Bequemlichkeit: vLLM als Grundlage, Überwachung der Auslastung, ein festgelegter Update-Weg und ein definierter Zustand, auf den zurückgesetzt werden kann. Die Oberfläche ist hier Nebensache, die Anbindung an die KI-Prozessautomatisierung dagegen entscheidend.
Keines dieser Werkzeuge löst das eigentliche Problem: die Organisation drumherum. Sie führen Modelle aus und zeigen Chatfenster an. Sie schulen niemanden und klären keine Zuständigkeiten. Wer glaubt, mit der Installation sei die Arbeit getan, unterschätzt den Rest deutlich.
Dazu kommt die Geschwindigkeit des Feldes. Empfehlungen von vor einem Jahr können heute falsch sein. Das ist ein echtes Risiko im Eigenbetrieb. Wer solche Systeme betreibt, braucht jemanden, der die Entwicklung verfolgt – oder betreutes Hosting auf eigener Infrastruktur, bei dem wir das übernehmen.
Und es gibt Fälle, in denen sich der Eigenbetrieb nicht lohnt. Wenn nur wenige Menschen gelegentlich unkritische Texte schreiben lassen, ist ein fertiger Dienst der ehrlichere Weg. Auch das sagen wir Dir lieber vorher.
Eine letzte Einschränkung betrifft den Datenschutz. Eigene Werkzeuge sind eine gute Ausgangslage, weil Inhalte Deine Umgebung nicht verlassen. Die rechtliche Bewertung ersetzen sie nicht. Eine vollständige Rechtsberatung können wir nicht leisten – für die datenschutzrechtliche Bewertung zieh bitte spezialisierte Datenschutzberater:innen oder Deine:n Datenschutzbeauftragte:n hinzu.
Lass uns gemeinsam klären, welche Kombination zu Eurer Ausgangslage passt – und welche Schritte es bis zum Betrieb wirklich braucht. Kostenlos und unverbindlich.
KI-Helden ist die KI-Abteilung der Suchhelden GmbH aus Osnabrück. Seit über einem Jahrzehnt arbeiten wir mit Unternehmen an digitalen Projekten. Vom Start-up bis zum internationalen Konzern, branchenunabhängig. Über 4.000 realisierte Projekte, ein Team aus über 140 Held:innen.
Für Werkzeugfragen heißt das vor allem eines: Wir haben diese Aufbauten im Betrieb gesehen, nicht nur im Test. Uns interessiert deshalb weniger, was heute in Foren empfohlen wird. Uns interessiert, was Dein Team in einem Jahr noch bedient und Deine IT noch betreut.
Ein Ollama Server ist ein Rechner, auf dem die Software Ollama läuft und ein Sprachmodell über eine Schnittstelle bereitstellt. Ollama lädt das Modell, führt es aus und nimmt Anfragen entgegen. Andere Programme oder eine Chat-Oberfläche sprechen diese Schnittstelle an. Ollama ist also weder das Modell noch die Oberfläche, sondern die Schicht dazwischen. Für kleine Installationen ist das ein bequemer Einstieg.
Der Einsatzzweck. Beide führen dieselben frei verfügbaren Modelle aus, sind aber für unterschiedliche Größenordnungen gebaut. Ollama ist auf einfachen Einstieg optimiert und passt zu einzelnen Rechnern, Testumgebungen und kleinen Installationen. vLLM ist darauf ausgelegt, viele Anfragen gleichzeitig zu bedienen, und ist deshalb die übliche Wahl im Unternehmensbetrieb. Besser oder schlechter gibt es hier nicht, nur passend oder unpassend.
Für kleine, klar abgegrenzte Installationen ja, für den breiten Unternehmensbetrieb in der Regel nicht. Ollama bringt keine Benutzerverwaltung mit und ist nicht auf viele gleichzeitige Anfragen ausgelegt. In vielen Projekten ist es trotzdem die richtige Zwischenstufe. Steht der Anwendungsfall fest, wird die Laufzeitumgebung getauscht und eine Oberfläche mit Rechten davorgesetzt. Nutzer:innen merken von diesem Wechsel meist nichts.
Diese Seite gibt bewusst keine Installationsanleitung. Die offiziellen Projektseiten sind dafür die bessere Quelle, weil sie immer aktuell sind. Aus unserer Erfahrung ist die Installation ohnehin der kleinste Teil der Arbeit. Die eigentlichen Fragen kommen danach. Wer darf zugreifen? Wo werden Verläufe gespeichert? Wer spielt Updates ein? Und wer ist erreichbar, wenn es klemmt? Genau dort setzen wir an.
Open WebUI ist eine Chat-Oberfläche, die vor eine Laufzeitumgebung geschaltet wird. Sie bringt Benutzerkonten, Rollen und Gruppen, gespeicherte Verläufe und eine Modellauswahl mit. Sie führt selbst kein Modell aus, sondern spricht die Schnittstelle darunter an. Damit macht sie aus einer technischen Installation ein Werkzeug für alle. Angebunden an Euer Benutzerverzeichnis gelten dort dieselben Regeln wie im Rest Eurer IT.
Meistens braucht es eine Kombination aus beiden Schichten, aber nicht zwingend diese. Eine Laufzeitumgebung führt das Modell aus, eine Oberfläche macht es für Menschen benutzbar. Ob unten Ollama oder vLLM liegt, entscheidet der Nutzerkreis. Welche Oberfläche oben sitzt, entscheidet Eure Benutzerverwaltung. Die Schichten lassen sich unabhängig voneinander tauschen, solange die Schnittstelle dazwischen sauber bleibt. Ab einer gewissen Größe kommt zwischen beiden noch ein Gateway dazu.
Weil dort zusammenläuft, was sich sonst über viele Anwendungen verteilt. Ein Gateway nimmt alle Anfragen entgegen und leitet sie an die passende Laufzeitumgebung weiter. An dieser einen Stelle regelt Ihr Rechte, Budgets, Protokollierung und Nutzungsübersichten. Mehrere Modelle lassen sich parallel bereitstellen und tauschen. Für einen kleinen Testaufbau ist das verzichtbar. Sobald mehrere Anwendungen oder Abteilungen dazukommen, fehlt sonst die Stelle zum Steuern.
In der Regel ja. Ein Gateway stellt eine Schnittstelle bereit, die kompatibel zu der der großen Anbieter ist. Anwendungen, die heute gegen einen externen Dienst arbeiten, zeigen danach auf Euer eigenes System. Meist genügen eine andere Adresse und ein anderer Zugangsschlüssel. Getestet gehört trotzdem jede Anbindung, denn ein anderes Modell antwortet anders. Prompts und feste Ausgabeformate prüfen wir nach dem Umzug erneut.
Über eine standardisierte Werkzeug-Anbindung, bekannt unter dem Kürzel MCP. Dabei werden einzelne Systeme als Werkzeuge beschrieben und dem Modell bereitgestellt. Es kann dann einen Vorgang abrufen oder einen Eintrag anlegen, statt nur darüber zu reden. Wichtig ist ein klares Rechtekonzept: Jedes Werkzeug bekommt eigene Grenzen, und schreibende Zugriffe behandeln wir zurückhaltender als lesende. Wir starten mit dem Anwendungsfall, der den größten Nutzen bringt.
Ollama Cloud bedeutet, Modellleistung über fremde Infrastruktur zu beziehen statt selbst zu betreiben. Das ist bequem und sofort nutzbar. Es ist aber kein Eigenbetrieb mehr, denn Inhalte verlassen Deine Umgebung. Wer aus Datenschutzgründen selbst betreibt, hebt damit den eigenen Vorteil wieder auf. Für unkritische Aufgaben kann das trotzdem sinnvoll sein. Entscheidend ist, dass die Unterscheidung im Haus bekannt ist.
LM Studio ist eine Oberfläche zum Ausprobieren am eigenen Arbeitsplatz. Modelle lassen sich laden und direkt im Gespräch testen, ohne dass jemand einen Server aufsetzt. Für die erste Orientierung ist das ideal. Als Grundlage für den Unternehmensbetrieb ist es nicht vorgesehen, weil es auf einem einzelnen Rechner läuft. Viele unserer Projekte beginnen trotzdem genau hier, weil jemand Lust zum Ausprobieren hatte.
llama.cpp macht Sprachmodelle auf bescheidener Hardware lauffähig, auch ohne spezialisierte Grafikbeschleunigung. Es ist eher Fundament als Bedienoberfläche. Viele bequemere Werkzeuge bauen im Kern darauf auf. Direkt eingesetzt wird es vor allem dort, wo wenig Rechenleistung zur Verfügung steht oder ein Modell auf einem Gerät ohne Netzanbindung arbeiten soll. Für den normalen Bürobetrieb ist es selten die erste Wahl.
Ein Inferenz-Server ist ein System, das ein fertig trainiertes Modell anwendet und Anfragen dazu beantwortet. Inferenz meint genau das: nicht trainieren, sondern nutzen. Ollama, vLLM und llama.cpp übernehmen diese Aufgabe in unterschiedlichen Größenordnungen. Der Begriff sagt nichts über die Hardware aus, sondern über die Rolle im Aufbau. In Angeboten meint er meist schlicht den Rechner, auf dem das Modell läuft.
Wenn mehrere Menschen gleichzeitig arbeiten, wenn Rechte differenziert werden müssen oder wenn nachvollziehbar sein soll, wer wann was abgefragt hat. Spätestens dann braucht es eine Umgebung mit Benutzerverwaltung und eine Laufzeitumgebung für parallele Anfragen. Die Zahl der Konten ist dabei nicht entscheidend, sondern die Zahl der gleichzeitigen Anfragen. In der Praxis merkt man den Übergang daran, dass Antworten zäh werden.
In der Regel ja, wenn der Aufbau von Anfang an in Schichten gedacht wurde. Modell, Laufzeitumgebung und Oberfläche lassen sich getrennt tauschen, solange die Schnittstellen dazwischen sauber bleiben. Genau deshalb planen wir die Architektur vor der Werkzeugwahl. Ein Wechsel ist dann ein überschaubarer Eingriff und kein Neubau. Aufwendig wird es nur, wenn Oberfläche und Laufzeitumgebung nie sauber getrennt waren.
Das entscheiden wir nach Aufgabe, Nutzerkreis und Betriebsform. Für den Unternehmensbetrieb ist eine auf parallele Anfragen ausgelegte Laufzeitumgebung mit einer Oberfläche davor der Normalfall. Für Testaufbauten und einzelne Arbeitsplätze nehmen wir bewusst den schlanken Weg. Wir arbeiten modellagnostisch und ohne Vendor-Lock-in, gebunden wird hier niemand. Wenn ein Werkzeug aus Eurem Haus die Anforderungen erfüllt, bauen wir darauf auf.
Eigener Betrieb ist eine gute Ausgangslage, weil Inhalte Deine Umgebung nicht verlassen und Du den Standort bestimmst. Dazu gehören aber ein Rechtekonzept, Protokollierung und geklärte Zuständigkeiten. Die Werkzeuge allein leisten das nicht, sie müssen entsprechend eingerichtet werden. Eine vollständige Rechtsberatung können wir nicht leisten – für die datenschutzrechtliche Bewertung zieh bitte spezialisierte Datenschutzberater:innen oder Deine:n Datenschutzbeauftragte:n hinzu.
Schnell. Projekte verschieben ihren Schwerpunkt, Funktionen kommen dazu, manche Werkzeuge verlieren an Bedeutung. Deshalb aktualisieren wir diese Seite regelmäßig und weisen das Datum sichtbar aus. Für den Betrieb heißt das vor allem eines: Es braucht jemanden, der die Entwicklung verfolgt und Updates bewertet. Wer das nicht leisten will, sollte die Betreuung abgeben, statt einmal aufzubauen und danach zu hoffen.
Ja, und wir bauen bewusst so, dass das möglich bleibt. Dazu gehören eine dokumentierte Architektur, nachvollziehbare Entscheidungen und eine Einarbeitung Deines Teams. Wir halten nichts von Aufbauten, die nur ihr Erbauer versteht. Ob Du die Betreuung bei uns lässt oder intern übernimmst, ist eine Frage Eurer Kapazität. Ein Wechsel ist in beide Richtungen jederzeit möglich.
