AnythingLLM: Dokumentenchat fürs Team lokal einrichten

Für ein fünfköpfiges Team ist AnythingLLM vor allem als selbst gehostete Docker-Instanz mit getrennten Benutzerkonten und einem lokalen Modell sinnvoll. So kann der Dokumentenchat auf dem eigenen Server bleiben. Wird dagegen ein Cloud-Modell ausgewählt, erhält dessen Anbieter die Textpassagen, die zur Beantwortung einer Frage verwendet werden. Allein die lokale Ablage der Dateien macht den Chat noch nicht unternehmensintern.

AnythingLLM passt gut, wenn zunächst Fragen zu Unternehmensdokumenten beantwortet werden sollen und der Assistent später einige nützliche Werkzeuge erhalten soll. Desktop eignet sich für Einzelpersonen, Docker für einen gemeinsam genutzten Server und die verwaltete Cloud, wenn Mintplex Labs den Betrieb der Infrastruktur übernehmen soll.

Am 5. November 2026 anhand der aktuellen Projektwebsite, Dokumentation und des GitHub-Repositorys geprüft. Die folgende Einrichtung beschreibt einen dokumentierten Bereitstellungsweg mit empfohlenen Zugriffsbeschränkungen. Sie ist kein Bericht über einen durchgeführten Leistungs- oder Sicherheitstest.

Was ist AnythingLLM, und welche Variante passt?

AnythingLLM verbindet eine Chatoberfläche, Dokumentensuche, Arbeitsbereiche und Agenten mit einem frei gewählten Modell. Docker, eine Software zum Ausführen von Anwendungen in Containern, stellt die gemeinsame Servervariante bereit. Ein großes Sprachmodell, kurz LLM, erzeugt die Antwort. AnythingLLM liefert dazu die Dokumente, den Gesprächsverlauf und die verfügbaren Werkzeuge, mit denen sich die geschäftliche Frage beantworten lässt.

Das lässt sich mit einer Unternehmensbibliothek vergleichen: Arbeitsbereiche sind Lesesäle, Dokumente die Regale, der Suchindex findet passende Textstellen und das Modell formuliert daraus eine Antwort. Der Bibliothekar kann im eigenen Gebäude sitzen oder für einen externen Dienst arbeiten. Diese letzte Entscheidung bestimmt, wer den Text zu sehen bekommt.

Der Funktionsvergleich von Desktop und Docker ordnet die Benutzerverwaltung und die Zugriffssteuerung für Arbeitsbereiche Docker zu. Desktop auf allen Team-Laptops zu installieren, ergibt noch keinen zentral verwalteten Teamdienst.

Die verwaltete Cloud nutzt eine isolierte, von Mintplex betriebene AWS-Instanz. Die Trennung von anderen Kunden ist hilfreich, erfüllt aber nicht die Anforderung, Dateien im eigenen Haus zu behalten. Zu den dokumentierten Einschränkungen zählen außerdem das Fehlen eines integrierten LLM, von MCP-Werkzeugverbindungen und von selbst programmierten Agenten. MCP ist ein Standard, über den Agenten externe Werkzeuge anbinden können. Statt eines integrierten Modells wird ein unterstützter Modelldienst verbunden. Vorgefertigte Agenten und eigener ausführbarer Code sind unterschiedliche Funktionen.

Für die Geschäftsführung lautet die entscheidende Frage, wer den Server betreut. Für die IT-Leitung geht es darum, welche Daten und Zugangsdaten ihn verlassen dürfen. Wenn die Vorgabe „Unsere Dokumente bleiben auf unseren Geräten“ lautet, sind Docker und lokale Verarbeitung der Ausgangspunkt.

Modelle: Die Rechenbasis getrennt von der Anwendung wählen

AnythingLLM lässt sich mit lokalen Modellanbietern und Cloud-Anbietern verbinden. Die Installation legt daher noch keine Modellfamilie fest. Die Anbieterkonfiguration unterscheidet zwischen dem systemweiten Standard, abweichenden Einstellungen einzelner Arbeitsbereiche und dem für Agenten verwendeten Modell.

Die integrierte Laufzeit verwendet Lemonade, eine Schicht zur Modellbereitstellung, mit llama.cpp, einer Software zum Ausführen kompatibler lokaler Modelle. Unterstützt werden GGUF-Modelldateien, ein Paketformat für herunterladbare Modelle. Die Dokumentation enthält Beispiele mit Llama und Phi; die Docker-Anleitung zeigt außerdem Qwen. Entscheidend ist ein Modell, das zur vorhandenen Hardware passt. Innerhalb einer Modellfamilie sind die Hardwareanforderungen keineswegs immer gleich.

Als externe lokale Dienste lassen sich unter anderem LM Studio, eine Desktopanwendung mit Modellserver, und LocalAI anbinden. Zu den Cloud-Verbindungen gehören Chatmodelle von OpenAI, Claude-Modelle von Anthropic und Google Gemini sowie allgemeine OpenAI-kompatible Endpunkte. Weitere Anbieter führt die Integrationsliste im Repository auf.

Das sind Anschlussmöglichkeiten, keine Zusage, dass jedes Modell mit Dokumenten, Bildern und Werkzeugaufrufen gleich gut umgeht. Ein Modell kann gut lesbare Antworten schreiben und trotzdem das falsche Werkzeug auswählen oder eine längere Anweisung nicht zuverlässig befolgen.

AnythingLLM und Ollama gemeinsam nutzen

Ollama ist eine eigenständige Modelllaufzeit, die AnythingLLM lokal erzeugte Antworten liefern kann. Die Anwendung ergänzt diese Laufzeit um Dokumentenarbeitsbereiche und Zugriffssteuerung. Läuft bereits ein funktionierender lokaler Modelldienst, ist es vernünftig, zunächst dabei zu bleiben.

Bei einer Neuinstallation steht auch die optionale integrierte Modelllaufzeit der Docker-Variante zur Verfügung, die weiter unten eingerichtet wird. Die Entscheidung für die Teamvariante erfordert also keinen zusätzlichen Modellserver.

Für einen vertraulichen Arbeitsbereich für Betriebsabläufe sollte ein lokales Chatmodell ausgewählt und auch das Agentenmodell geprüft werden. Ein anderer Arbeitsbereich kann einen Cloud-Anbieter verwenden, sofern seine Datenrichtlinie das erlaubt. Das Embedding-Modell wird allerdings separat und systemweit festgelegt. Das ist die entscheidende Einschränkung dieser Flexibilität.

AnythingLLM und RAG: Wie Arbeitsbereiche Dokumente nutzen

Die Dokumentensuche von AnythingLLM stellt dem Modell passende Textstellen bereit. Sie bringt ihm nicht dauerhaft den Inhalt jeder Datei bei. Retrieval-Augmented Generation, kurz RAG, bedeutet, in den Quellen zu suchen und ausgewählte Passagen in die Anfrage an das Modell einzufügen.

Ein Embedding ist eine numerische Darstellung, mit der sich inhaltlich verwandte Texte finden lassen. Die Anwendung zerlegt ein Dokument in Abschnitte, erzeugt Embeddings und speichert einen durchsuchbaren Index. Bei einer Frage wählt die Suche passende Abschnitte für die Antwort aus. Das Kontextfenster des Modells begrenzt die Textmenge, die es gleichzeitig berücksichtigen kann: Anweisungen, Gesprächsverlauf und diese Passagen eingeschlossen.

Dokumente lassen sich auf zwei praktische Arten bereitstellen:

• Ein Dokument an einen Chat anhängen, wenn es um genau diese Datei geht. AnythingLLM fügt standardmäßig den vollständigen Text ein, soweit das Kontextfenster reicht. Anhänge sind auf den jeweiligen Arbeitsbereich und Gesprächsstrang begrenzt.
• Ein Dokument in einen Arbeitsbereich einbetten, wenn es als wiederverwendbares Wissen dienen soll. Es steht dann in den Gesprächssträngen dieses Arbeitsbereichs und für alle Personen mit Zugriff auf ihn zur Verfügung.

Die Anleitung zum Umgang mit Dokumenten beschreibt diese Änderung des Geltungsbereichs ausdrücklich. Wird der Entwurf eines Inhabers in einen gemeinsamen Arbeitsbereich verschoben, ist das eine Freigabeentscheidung – auch wenn sich das ursprüngliche Gespräch privat angefühlt hat.

Ein Beispiel: Eine freigegebene Retourenrichtlinie wird im Support-Arbeitsbereich hinterlegt. „Was muss ein Supportmitarbeiter prüfen, bevor er eine Retoure genehmigt?“ ist eine sinnvolle Frage für die Dokumentensuche. „Liste alle Ausnahmen in sämtlichen Dateien auf“ verlangt dagegen eine Vollständigkeit, die einige relevante Auszüge nicht belegen können. Bevor eine Antwort als vollständig gilt, sollte die zugrunde liegende Richtlinie geprüft werden.

Für den ersten Dokumentenpilotversuch empfiehlt sich der Query-Modus. Er soll Antworten aus hochgeladenem Material liefern und melden, wenn passende Informationen fehlen. Der Chat-Modus verwendet zusätzlich das Allgemeinwissen des Modells; der Agent-Modus kann Werkzeuge aufrufen. Das sind die dokumentierten Chatmodi. Da neue Arbeitsbereiche im Agent-Modus starten können, sollte diese Einstellung bewusst gewählt werden.

Ist AnythingLLM für vertrauliche Unternehmensdokumente sicher?

AnythingLLM gibt Kontrolle über die Komponenten. Ob Daten vertraulich bleiben, hängt jedoch von der Konfiguration jeder textverarbeitenden Komponente ab. Entscheidend ist, wo die Verarbeitung stattfindet, nicht das Etikett „lokal“ auf der Anwendung.

Dateien und gespeicherter Text. Desktop legt seine Anwendungsdaten in einem lokalen Speicherverzeichnis ab. Die Speicherdokumentation nennt aufbereitete Dokumente, zwischengespeicherte Embeddings, die Datenbank und direkte Uploads. Bei Docker muss das Speicherverzeichnis der Anwendung dauerhaft auf dem Server gesichert werden. In der verwalteten Cloud liegen die entsprechenden Anwendungsdaten auf der gehosteten Instanz.

Embeddings und Index. Die standardmäßige LanceDB-Konfiguration speichert den Vektorindex auf der AnythingLLM-Instanz. Für lokale Textverarbeitung sollte der integrierte Embedder beibehalten werden. Bei einem Cloud-Embedding-Anbieter muss der zu verarbeitende Text an diesen Anbieter gehen, selbst wenn die erzeugten Vektoren lokal gespeichert werden. Eine externe Vektordatenbank schafft einen weiteren Speicherort für Indexdaten. Embeddings und indexierte Texte sind Unternehmensdaten, keine Anonymisierung.

Die Anfrage für die Antwort. Ein Cloud-Chatmodell erhält die Prompt-Inhalte, die es für seine Antwort verwendet: die Frage, den mitgelieferten Gesprächskontext und abgerufene Dokumentenpassagen. Ein angehängtes oder angeheftetes Dokument kann seinen vollständigen Text beisteuern. Die ursprüngliche PDF-Datei kann also auf dem eigenen Server bleiben, während vertrauliche Sätze ihn verlassen. Für diese Kopie gelten die Bedingungen und Aufbewahrungseinstellungen des empfangenden Anbieters. AnythingLLM kann eine externe Inferenzanfrage nicht im eigenen Haus halten.

Agenten und externe Dienste. Websuchen, externe APIs und MCP-Werkzeuge können Informationen nach außen senden. Ein lokales Modell macht diese Dienste nicht zu lokalen Diensten. Für einen strikt internen Dokumentenassistenten sollten externe Skills deaktiviert und die verfügbaren Werkzeuge geprüft werden, bevor vertrauliche Dateien hinzukommen.

Das folgenreichste Konfigurationsdetail steht in der Embedding-Dokumentation: Der Embedder gilt systemweit, während Chatmodelle je Arbeitsbereich unterschiedlich sein können. Ein Arbeitsbereich mit lokalem Chatmodell kann seine Dokumente deshalb trotzdem an einen Cloud-Embedder senden. Benötigen vertrauliche und extern verarbeitete Aufgaben unterschiedliche Embedding-Richtlinien, sind getrennte Instanzen angebracht. Eine abweichende Chatmodelleinstellung im Arbeitsbereich schafft diese Grenze nicht.

Auch Löschen und Zugriffsentzug sind zu unterscheiden. Wird ein Dokument aus einem Arbeitsbereich entfernt, bleiben die aufbereitete Datei und der Cache in der Dokumentenbibliothek erhalten. Laut Anleitung zu Datenschutz und Löschung muss es aus My Documents gelöscht werden, um die aufbereitete Quelle und zwischengespeicherte Embeddings arbeitsbereichsübergreifend zu entfernen. Für Kopien in Sicherungen oder externen Diensten braucht es eigene Aufbewahrungsregeln.

Telemetrie ist eine weitere Einstellung, unabhängig vom Modellverkehr. Die Nutzungstelemetrie lässt sich unter Privacy oder mit DISABLE_TELEMETRY=true deaktivieren. Konfigurierte Cloud-Anbieter, Werkzeugverbindungen und Modelldownloads werden dadurch nicht abgeschaltet.

AnythingLLM Docker für ein fünfköpfiges Team einrichten

Der Ausgangspunkt ist ein Linux-Server mit dauerhaftem Anwendungsspeicher, einem lokalen Modell und getrennten Konten. Das folgende Beispiel setzt eine Neuinstallation, bereits installiertes Docker und eine IT-Leitung voraus, die authentifizierten Zugriff über ein bestehendes privates Netzwerk und einen auf dem Server laufenden HTTPS-Reverse-Proxy bereitstellen kann.

Die Docker-Systemanforderungen nennen als Grundbedarf 2GB RAM, eine CPU mit 2 Kernen und 5GB Speicherplatz für die Anwendung. Das ist keine Dimensionierungszusage für lokale Inferenz oder fünf gleichzeitige Nutzer. Für Modell, Dokumente und parallele Anfragen werden zusätzlicher Arbeitsspeicher und Speicherplatz benötigt. Auf einem Intel- oder AMD-System mit der standardmäßigen LanceDB muss AVX2 innerhalb des Servers oder der virtuellen Maschine verfügbar sein; ARM64 verwendet einen separaten Build.

1. 1

   Dauerhaften Speicher anlegen und die Anwendung starten

   Der folgende Befehl wird vom Betreiber auf dem Server ausgeführt. Er passt den offiziellen Installationsbefehl an: Der Webport wird für einen HTTPS-Proxy an Loopback gebunden, ein automatischer Neustart ergänzt, Telemetrie deaktiviert und lokale Inferenz aktiviert.

   export ANYTHINGLLM_STORAGE="$HOME/anythingllm"
   mkdir -p "$ANYTHINGLLM_STORAGE"
   touch "$ANYTHINGLLM_STORAGE/.env"
   sudo chown -R 1000:1000 "$ANYTHINGLLM_STORAGE"
   
   docker pull mintplexlabs/anythingllm:latest
   docker run -d \
     --name anythingllm \
     --restart unless-stopped \
     -p 127.0.0.1:3001:3001 \
     --cap-add SYS_ADMIN \
     -v "$ANYTHINGLLM_STORAGE:/app/server/storage" \
     -v "$ANYTHINGLLM_STORAGE/.env:/app/server/.env" \
     -e STORAGE_DIR=/app/server/storage \
     -e DISABLE_TELEMETRY=true \
     -e ENABLE_BUILT_IN_LLM=true \
     mintplexlabs/anythingllm:latest

   Die Einbindung erhält die Daten beim Austausch des Containers. Die Eigentümereinstellung folgt dem dokumentierten Benutzer des Images, 1000:1000. Ein Speicherfehler sollte nicht dadurch behoben werden, dass alle Schreibzugriff auf das Verzeichnis erhalten. SYS_ADMIN stammt aus dem veröffentlichten Befehl und gewährt dem Container weitreichende Befugnisse. Dieser Dienst gehört deshalb auf kontrollierte Infrastruktur. Weitere Einzelheiten stehen in der offiziellen Docker-Installationsanleitung.

2. 2

   Ein lokales Modell wählen und Dokumente lokal verarbeiten

   Bei der Ersteinrichtung Built-in auswählen, ein zum Server passendes Modell herunterladen und den integrierten Embedder sowie die lokale Vektordatenbank beibehalten. Unter Settings > AI Providers > LLM das ausgewählte Modell bestätigen, bevor Unternehmensdateien hochgeladen werden.

   Die Anleitung für das integrierte Docker-Modell verlangt ENABLE_BUILT_IN_LLM=true beim Containerstart. Die Einstellung nur in die eingebundene .env zu schreiben, aktiviert die Laufzeit nicht. Der obige Befehl verwendet CPU-Inferenz. Für NVIDIA-Beschleunigung sind die Container-Toolkit-Voraussetzungen der Anleitung zu erfüllen und --gpus all zu ergänzen. AMD- und Intel-GPUs benötigen eigene Geräte- und Gruppeneinstellungen.

   Laufzeit, Modell und benötigte Laufzeitkomponenten sollten heruntergeladen werden, solange Internetzugang besteht. Vor der Einladung des gesamten Teams ist die CPU-Leistung mit der vorgesehenen Pilotaufgabe zu bewerten. Die integrierte Laufzeit hält jeweils ein Modell geladen. Der gemeinsame Pilotversuch sollte daher mit einem Modell beginnen.

3. 3

   Einzelne Benutzerkonten vor dem Teamzugang aktivieren

   Auf dem Server http://127.0.0.1:3001 öffnen oder den Loopback-Dienst über den administrativen Tunnel erreichen. Unter Security & Access den Mehrbenutzermodus aktivieren und das erste Administratorkonto erstellen. Danach erfolgt eine Abmeldung; anschließend mit den neuen Zugangsdaten anmelden.

   Für dieses Beispiel mit fünf Personen über die Benutzerverwaltung vier Kollegen anlegen oder einladen und jeweils die Rolle Default vergeben. Zusammen mit dem eigenen Admin-Konto ergibt das fünf Nutzer. Laut Rollendokumentation können Default-Nutzer nur in Arbeitsbereichen chatten, denen sie ausdrücklich hinzugefügt wurden. Ein Manager kann alle Arbeitsbereiche einsehen. Für Kollegen, die nur Dokumente einer Abteilung sehen sollen, reicht diese Rolle daher zu weit. Admin hat vollständigen Systemzugriff. Der dokumentierte Wechsel in den Mehrbenutzermodus lässt sich nicht rückgängig machen.

4. 4

   Arbeitsbereiche anlegen und die Browser des Teams verbinden

   Den Arbeitsbereich Gemeinsame Betriebsabläufe für freigegebene Verfahren erstellen und alle fünf Konten hinzufügen. Für geschütztes Material einen Arbeitsbereich Inhaber anlegen und nur berechtigte Personen zuweisen. Jedes Dokument gehört in den passenden Arbeitsbereich. Vertrauliches Material sollte nicht im gemeinsamen Arbeitsbereich eingebettet und anschließend per Prompt versteckt werden.

   Der bestehende HTTPS-Reverse-Proxy leitet den für das Team gewählten Hostnamen an http://127.0.0.1:3001 auf diesem Server weiter. Der Netzwerkzugriff wird auf die Belegschaft beschränkt. Das Beispiel stellt bewusst keinen Webport direkt öffentlich bereit. Alle Kollegen öffnen die HTTPS-Adresse und melden sich mit ihrem eigenen Konto an.

5. 5

   Vor der Ausweitung einen Abnahmetest durchführen

   Mit einer kleinen Auswahl freigegebener Dokumente und zehn typischen Fragen beginnen, darunter zwei, die sich aus den Dokumenten nicht beantworten lassen. Die Quellpassagen und die zulässigen Arbeitsbereiche eines gewöhnlichen Nutzers prüfen. Auch einen Nutzer testen, dem der Zugriff verweigert werden muss. Danach senden alle fünf Personen gleichzeitig typische Anfragen; dabei Wartezeiten und Speichernutzung beobachten.

   Den dauerhaften Speicher und die eingebundene Konfiguration gemeinsam sichern, entweder bei gestopptem Container oder mit einem konsistenten Sicherungsverfahren. Die Sicherung muss geschützt werden, da sie Dokumente und geheime Konfigurationsdaten enthält. Vor regulären Updates die bereitgestellte Image-Version oder deren Digest dokumentieren und prüfen, ob sich die Pilotinstallation wiederherstellen lässt.

Wird stattdessen ein bestehender externer lokaler Modellserver verwendet, muss die Netzwerkverbindung aus dem Container geprüft werden. localhost bezeichnet innerhalb des Containers diesen Container, nicht den Modelldienst des Hosts. Die Anleitung zur Hostverbindung erklärt den Unterschied. Eine erreichbare Adresse verwenden und den Modelldienst auf vertrauenswürdige Aufrufer beschränken.

Agenten und MCP: Was den Arbeitsbereich verlassen kann

Ein Agent ergänzt den Dokumentenchat um Aktionen. Er kann Werkzeuge verwenden, um Informationen abzurufen oder Aufgaben auszuführen. Seine Berechtigungen verdienen deshalb ebenso viel Aufmerksamkeit wie die Dokumente, die er liest.

Unter Settings > Agent Skills nur die für den Ablauf benötigten Skills auswählen. Manche sind standardmäßig aktiviert. Die Anleitung zur Agenteneinrichtung erlaubt außerdem, pro Arbeitsbereich ein Agentenmodell zu wählen. Für den ersten Pilotversuch ist das Abrufen einer freigegebenen Richtlinie der bessere Einstieg als der Zugriff auf sämtliche Unternehmenssysteme.

Das Model Context Protocol, kurz MCP, ist ein verbreiteter Weg, über den Anwendungen Modelle mit Werkzeugen verbinden. Die MCP-Konfiguration von AnythingLLM unterstützt lokale, befehlsbasierte Server und externe Verbindungen. Ein Werkzeug kann etwa ein Verzeichnis lesen, eine Datenbank abfragen oder einen weiteren Dienst aufrufen. Wie weit eine solche Aktion reicht, bestimmen die bereitgestellten Zugangsdaten.

Selbst gehostetes Docker unterstützt laut Docker-MCP-Anleitung MCP Tools, aber keine Resources, Prompts oder Sampling. Die Konfiguration liegt unter plugins/anythingllm_mcp_servers.json im dauerhaften Speicherverzeichnis. Nach Änderungen Agent Skills öffnen und Refresh verwenden.

Ein lokal gestarteter MCP-Server läuft innerhalb des Containers. Er sieht Containerpfade und ausdrücklich eingebundene Dateien, keine beliebigen Ordner auf dem Host. Manuell installierte Werkzeugabhängigkeiten können beim Austausch des Containers verschwinden. Bevor der Betrieb von ihnen abhängt, sollte sich ihre Installation reproduzieren lassen.

Eine Zugriffsbeschränkung des Arbeitsbereichs begrenzt nicht automatisch die Datenbankzugangsdaten eines Werkzeugs. Das Werkzeug braucht ein eng begrenztes Konto, dessen Zugriff separat geprüft wird. In einem zunächst nur lesenden Pilotbetrieb lassen sich die Folgen leichter untersuchen, bevor Aktionen zum Ändern von Datensätzen oder Versenden von Nachrichten erlaubt werden.

AnythingLLM-Alternativen: Wann eine andere Lösung passt

AnythingLLM ist eine gute Wahl, wenn gemeinsame Dokumentenarbeitsbereiche im Mittelpunkt stehen. Sein Vorteil liegt im Zusammenspiel dieser Bausteine. Dokumentenchat und MCP sind keine exklusiven Funktionen.

Open WebUI für eine vielseitigere gemeinsame Chatoberfläche

Open WebUI ist der passendere erste Kandidat, wenn vor allem eine allgemeine, selbst gehostete Oberfläche für verschiedene Modelldienste mit konfigurierbaren Erweiterungen gesucht wird. Die Dokumentation behandelt Anbieteranbindungen und Erweiterbarkeit. Die aktuelle Grundlagenanleitung erklärt Dokumentenanhänge und wiederverwendbare Wissensdatenbanken.

Eine funktionierende Open WebUI-Installation sollte beibehalten werden, wenn sie die Anforderungen an Dokumente und Zugriffe bereits erfüllt. Ein Wechsel der Oberfläche allein behebt weder schlechte Quelldokumente noch ein ungeeignetes Modell. AnythingLLM bietet sich an, wenn die Einführung um wenige, klar zugewiesene Dokumentenarbeitsbereiche organisiert werden soll.

LibreChat für Werkzeugverbindungen mit persönlichen Zugangsdaten

LibreChat verdient einen genaueren Blick, wenn jede Person Werkzeuge mit ihren eigenen Zugangsdaten verbinden muss. Die MCP-Dokumentation beschreibt nutzerbezogene Verbindungen, Zugangsdaten und OAuth-Anmeldung sowie Werkzeuge, die Chats oder Agenten zugeordnet werden.

Für ein Unternehmen mit individuell autorisierten Systemzugängen ist das ein konkreter Grund zur Prüfung. Dafür müssen diese Verbindungen verwaltet und Modelle gewählt werden, die ihre Werkzeuge zuverlässig aufrufen. Für eine kleine gemeinsame Richtlinienbibliothek mit wenigen Werkzeugen bleibt AnythingLLM mit seinen Arbeitsbereichen der direktere Einstieg.

AnythingLLM im Vergleich zu LM Studio

LM Studio passt zu Einzelpersonen, die vor allem lokale Modelle herunterladen, ausführen und vergleichen möchten. Die aktuelle Anwendungsdokumentation behandelt außerdem MCP, API-Bereitstellung und den Betrieb ohne grafische Oberfläche. Die Offline-Anleitung umfasst auch lokalen Dokumentenchat. Damit kann LM Studio sowohl eigenständig nützlich sein als auch als Modelldienst hinter einer anderen Anwendung dienen.

AnythingLLM Docker ist die passende Wahl, wenn eine gemeinsame Dokumentenanwendung mit zugewiesenen Arbeitsbereichszugriffen benötigt wird. LM Studio passt, wenn der Modellbetrieb die entscheidende Anforderung ist. Es geht um die benötigte Anwendungsschicht, nicht um eine vermeintliche Trennung in „kann Dokumente lesen“ und „kann keine Dokumente lesen“.

Bei der Wahl des Modelldienstes hilft der Vergleich von Ollama und LM Studio. Passt keines der beiden zu Hardware oder Bereitstellungsbedarf, stellt der Leitfaden zu Ollama-Alternativen weitere Laufzeiten vor.

Wo „private KI“ zu viel verspricht

„Läuft lokal“ beschreibt eine Konfiguration, aber noch nicht vollständig den Weg der Daten. Eine lokale Oberfläche kann ein Cloud-Modell aufrufen, ein lokales Modell ein externes Werkzeug und ein lokaler Index von einem Cloud-Embedder erzeugt werden.

Auch „Mit allen Dokumenten chatten“ verspricht mehr, als eine gewöhnliche Dokumentensuche tatsächlich erfasst. Sie wählt Passagen aus und kann genau die Ausnahme übersehen, die eine Antwort verändert. Hinzugefügte Dokumente trainieren das Modell nicht dauerhaft. Auch eine zitierte Passage muss die daraus gezogene Schlussfolgerung tatsächlich stützen.

Schließlich sind Mindestanforderungen für die Installation keine Leistungsgarantie für ein Team. Modell, Kontextlänge, Embedding-Aufwand und zeitlich überlappende Anfragen bestimmen die Nutzungserfahrung. Der Einstieg lohnt sich, wenn jemand den Server verantwortet und eine konkrete Dokumentenaufgabe feststeht. Fehlt noch eine klare Regel, wer auf die Dateien zugreifen darf oder wie eine akzeptable Antwort aussieht, ist Abwarten sinnvoll. Ein bestehendes System sollte bleiben, wenn es diese Anforderungen bereits erfüllt.

Häufige Fragen

Ist AnythingLLM seriös?

Ja. Es handelt sich um ein Open-Source-Projekt von Mintplex Labs mit öffentlich zugänglichem Code und Installationsdokumentation. Damit ist die Herkunft nachvollziehbar. Die Sicherheit des konkret gewählten Modells, der Plugins oder der Serverkonfiguration ist dadurch nicht zertifiziert.

Wofür werden LLMs eingesetzt?

LLMs erzeugen und verdichten Texte, beantworten Fragen und helfen beim Verfassen von Inhalten. Hier besteht der geschäftliche Nutzen darin, Fragen anhand relevanter Passagen aus einer freigegebenen Dokumentensammlung zu beantworten. Ein Agent ergänzt Werkzeuge, mit denen Aktionen ausgeführt werden können.

Gibt es kostenlose Open-Source-KI-Modelle?

Ja, es gibt herunterladbare Modelle für den lokalen Betrieb. Bei jedem Modell sollten die Lizenz und die Bedingungen für die kommerzielle Nutzung geprüft werden. Die MIT-Lizenz von AnythingLLM gilt nicht automatisch auch für die Modellgewichte. Für Hardware und Administration fallen weiterhin Kosten an.

Lässt sich mit Ollama ein LLM lokal betreiben?

Ja. Ein geeignetes Modell in Ollama ausführen und AnythingLLM mit dem erreichbaren Dienst verbinden. Bei Docker muss die Containernetzwerkkonfiguration berücksichtigt werden. Die localhost-Adresse des Hosts funktioniert nicht automatisch innerhalb des Containers.

Was unterscheidet Ollama von AnythingLLM?

Ollama stellt die Laufzeit für Modelle bereit. AnythingLLM ist eine Anwendung für Dokumente, Arbeitsbereiche und Agenten, die diese Laufzeit nutzen kann. Beide lassen sich kombinieren. Die aktuelle Docker-Variante von AnythingLLM bietet außerdem eine optionale integrierte Laufzeit.

Wie lassen sich LLMs am günstigsten lokal betreiben?

Zunächst vorhandene Hardware und ein dazu passendes Modell verwenden. Anschließend prüfen, ob es die Aufgabe schnell genug erledigt. Weitere Hardware sollte erst gekauft werden, wenn der Engpass feststeht. Die günstigste Konfiguration lässt sich nicht unabhängig von Arbeitslast und akzeptabler Wartezeit bestimmen.

Welches LLM ist am dümmsten?

Unter dieser Bezeichnung gibt es keine sinnvolle allgemeine Rangliste. Ein Modell kann flüssig schreiben und trotzdem bei der Dokumentensuche oder Werkzeugnutzung scheitern. Maßgeblich sind die eigenen Fragen, einschließlich Fällen, in denen es eingestehen sollte, dass die Quelle keine Antwort enthält.

Welches lokale LLM ist am intelligentesten?

Die passende Wahl hängt von Aufgabe, verfügbarem Arbeitsspeicher und akzeptabler Verzögerung ab. Das Modell muss zur Hardware passen; Quellentreue und Werkzeugverhalten sollten geprüft werden. Dieser auf Dokumentation beruhende Erklärartikel kürt keinen Benchmark-Sieger.

Wie viel RAM brauchen lokal betriebene LLMs?

Die Desktop-Anforderungen von AnythingLLM empfehlen für die grundlegende lokale Nutzung 16GB RAM und eine CPU mit 8 Kernen. Ein Server benötigt zusätzlich Kapazität für das ausgewählte Modell und überlappende Anfragen. Der deutlich geringere Grundbedarf der Anwendung allein ist nicht das gesamte Speicherbudget für lokale Inferenz.

Der nächste konkrete Schritt

Eine verantwortliche IT-Person erhält den Server, einen freigegebenen Dokumentensatz und einen klaren Abnahmetest. Mit lokaler Inferenz, integriertem Embedder, lokalem Speicher und Query-Modus beginnen; unnötige Werkzeuge bleiben deaktiviert. Die übrigen vier Personen erst einladen, wenn ihre Arbeitsbereichsrechte geprüft sind. Wird ein Cloud-Modell notwendig, muss vor der Umstellung ausdrücklich feststehen, welcher Text das Unternehmen verlassen darf.

Praktische Anregungen zum KI-Einsatz im kleinen Unternehmen gibt es im Newsletter.