llmware: RAG-Pipelines mit kleinen Modellen auf dem Laptop

Welches Problem llmware adressiert und für wen

Die README beschreibt llmware als Framework für wissensbasierte Anwendungen, die lokal, privat und ohne Cloud-Abhängigkeit laufen sollen. Der Adressat ist damit nicht das Forschungsteam, das ein Basismodell vortrainiert, sondern das Entwicklungsteam, das einen vorhandenen Dokumentenbestand durchsuchbar und mit einem generativen Modell beantwortbar machen will. Der Ausgangspunkt ist ein Ordner mit gemischten Dateien, nicht ein sauber vorbereiteter Datensatz. Die README nennt als Zielumgebungen AI-PC, Laptop, Edge und Self-Hosting unter Windows, Mac und Linux. Das ist eine andere Zielgruppe als bei Frameworks, die auf einen GPU-Cluster oder einen gehosteten Vektordienst zugeschnitten sind. Der zweite Teil der Zielgruppe sind Teams, die aus Kostengründen oder wegen Datenhaltung nicht jede Anfrage an einen Cloud-Anbieter schicken wollen. llmware unterstützt zwar laut README auch OpenAI, Anthropic und Google, der Schwerpunkt der Beispiele liegt aber auf Modellen, die auf dem Gerät laufen. Wer eine reine Cloud-Orchestrierung sucht, findet hier mehr Bauteile als nötig.

ModelCatalog als Abstraktion über Inferenz-Backends

Der Modellkatalog ist die erste der beiden Hauptkomponenten. Die README nennt über 300 Modelle in quantisierten Formaten, darunter die eigenen SLIM-, Bling-, Dragon- und Industry-Bert-Familien. Der entscheidende Mechanismus ist die Vereinheitlichung: Egal ob GGUF, OpenVINO, ONNXRuntime, ONNXRuntime-QNN für Qualcomm, WindowsLocalFoundry oder Pytorch im Hintergrund arbeitet, der Zugriff erfolgt über ModelCatalog().load_model mit einem Modellnamen als Zeichenkette. Das Beispiel der README lädt "llmware/bling-phi-3-gguf" und ruft anschließend inference oder stream auf. Für die Portierung auf eine andere Hardware bedeutet das: Der Anwendungscode bleibt gleich, nur der Name des Modells und damit das Format wechseln. Diese Abstraktion hat einen Preis. Die Dokumentation im README zeigt nur die Aufrufform, nicht die Fehlerbilder. Wer ein Modell lädt, das für sein Zielformat nicht vorliegt, erfährt das erst zur Laufzeit. Die Liste der unterstützten Backends ist lang, aber ob ein bestimmtes Modell in einem bestimmten Format verfügbar ist, muss der Nutzer selbst im Katalog prüfen. Die README liefert dafür list_all_models als Einstiegspunkt.

Ingestion: Library, add_files und die Rolle der Dateiendung

Die zweite Komponente ist die RAG-Pipeline. Ihr zentrales Objekt ist die Library, die die README als Wissensbasis-Container beschreibt, mit einem Textbestand in einer Datenbank und einem Dateiverzeichnis unter llmware_data/accounts/{library_name}. Der Ablauf ist in drei Aufrufe gefasst: Library().create_new_library("my_library"), dann lib.add_files("/folder/path/to/my/files"), dann lib.install_new_embedding mit einem Modellnamen und einem vector_db-Wert. add_files ist laut README die universelle Ingestion-Funktion. Der Mechanismus dahinter ist eine Weiterleitung nach Dateiendung: Die README listet pdf, pptx, docx, xlsx, txt, csv, md, json/jsonl, wav, png, jpg und html. Jede Endung bekommt einen eigenen Parser, danach folgen Textzerlegung in Chunks und Indexierung. Bemerkenswert ist, dass Bilder und Audio in derselben Funktion landen wie Textdokumente. Das ist praktisch für gemischte Ablagen, verschiebt aber die Frage der Qualität in den jeweiligen Parser. Die README sagt nichts über die Genauigkeit einzelner Parser, über den Umgang mit gescannten PDFs ohne Textebene oder über Tabellenextraktion. Wer solche Dokumente hat, sollte vor dem Aufbau einer großen Bibliothek einen Testlauf mit einer kleinen Stichprobe machen.

Embeddings, Vektordatenbanken und Mehrfachinstallation

Ein Detail, das die README ausdrücklich zeigt, ist die Mehrfachbelegung einer Bibliothek mit Embeddings. Nach dem ersten Aufruf von install_new_embedding mit "mini-lm-sbert" und "milvus" folgt ein zweiter mit "industry-bert-sec" und "chromadb". Die Bibliothek trägt also mehrere Vektorindizes parallel, und die Abfrageschicht wählt über die Parameter embedding_model_name und vector_db aus, welcher verwendet wird. Das Beispiel im Query-Abschnitt konstruiert dafür ein zweites Query-Objekt mit den passenden Namen. Dieser Aufbau erlaubt einen Vergleich zweier Einbettungen auf demselben Textbestand, ohne die Bibliothek neu aufzubauen. Er kostet aber Speicher und Indexierungszeit, weil jeder Chunk mehrfach eingebettet wird. Der batch_size-Parameter, im Beispiel 500 für Milvus und 100 für ChromaDB, steuert die Verarbeitung in Blöcken. Die README nennt keine Obergrenzen für Bibliotheksgröße oder Chunk-Anzahl. Wer eine Abschätzung braucht, muss sie aus der eigenen Datenmenge und dem Speicherbedarf des jeweiligen Vektorindex selbst ableiten.

Abfragevarianten und der Umgang mit mehreren Indizes

Die Query-Schicht bietet laut README Textsuche, semantische Suche, Hybridformen, Metadatenfilter und benutzerdefinierte Filter. Die Beispiele zeigen text_query mit exact_mode, semantic_query mit result_count sowie text_query_with_document_filter, das eine Textsuche auf bestimmte Dateien einschränkt, hier über den Schlüssel file_name in einem Wörterbuch. Das ist der Punkt, an dem llmware über eine reine Vektorsuche hinausgeht: Die Einschränkung auf eine Teilmenge der Bibliothek passiert vor der Suche, nicht nachträglich durch Filtern der Ergebnisse. Für Anwendungsfälle mit klaren Dokumentgrenzen, etwa Quartalsberichte eines Bereichs, ist das der naheliegende Weg. Die README zeigt jedoch keine Aussage darüber, wie sich Text- und Semantiktreffer kombinieren lassen oder wie die Rangfolge bei gemischten Ergebnissen entsteht. Wer Hybridsuche braucht, muss die Gewichtung selbst bauen. Das ist eine Lücke in der Beschreibung, nicht zwingend im Code, aber für die Planung relevant.

Prompt mit Quellen und die Grenze des Beispiels

Der Prompt-Abschnitt führt die beiden Teile zusammen. Prompt().load_model lädt ein Modell, danach wird ein Dokument hinzugefügt. Die README beschreibt den Ablauf so, dass die Datei geparst, in Chunks zerlegt, über die Abfrage gefiltert und als modellfertiger Kontext verpackt wird. Das ist der Kern der RAG-Pipeline in einem Aufruf. Die README bricht an dieser Stelle ab, mitten im Codeblock, und der weitere Teil ist nicht überliefert. Damit fehlt genau die Information, die für die Bewertung wichtig wäre: Welche Parameter steuern die Anzahl der eingebundenen Chunks, wie wird die Kontextlänge gegen das Modelllimit begrenzt, und wie werden Quellenangaben in der Antwort zurückgegeben. Wer llmware für eine Anwendung mit Nachweispflicht prüft, muss diese Fragen anhand der Beispiele im Repository klären, nicht anhand der README. Das ist keine Kritik am Mechanismus, sondern eine Einschränkung des vorliegenden Materials.

Betrieb, Lizenz und Pflegeaufwand

llmware steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung und Änderung, verlangt aber die Beibehaltung von Urheberrechts- und Lizenzhinweisen und enthält eine ausdrückliche Patentgewährung sowie einen Haftungsausschluss. Ob das für einen konkreten Vertriebsweg ausreicht, ist eine Rechtsfrage und nicht Teil dieser Einordnung. Wichtiger für den Betrieb ist die Kopplung an Modellgewichte: Die eigenen Bling-, Dragon- und Industry-Bert-Modelle liegen auf Hugging Face und können eigene Lizenzbedingungen tragen, die von Apache-2.0 abweichen. Wer ein Modell aus dem Katalog produktiv einsetzt, muss dessen Lizenz separat prüfen. Die Versionshistorie zeigt drei Releases zwischen Februar und April 2026, die aktuelle Version ist v0.4.6 vom 14. April 2026. Die Null vor der Eins deutet auf eine Vorabversion hin. Die README nennt Python 3.10 bis 3.14 als unterstützt. Ein Upgrade auf eine neue Minor-Version kann bei einer Bibliothek, die mehrere Inferenz-Backends und Vektordatenbanken bündelt, Abhängigkeitskonflikte mit sich bringen; die Release Notes sind die Stelle, an der solche Änderungen stehen.

Wann llmware das falsche Werkzeug ist

Der Ansatz setzt auf kleine, spezialisierte Modelle. Das ist eine bewusste Entscheidung für geringen Rechenbedarf, nicht für maximale Antwortqualität. Wer offene Fragen über einen heterogenen Bestand beantworten lassen will und dafür ein großes Modell braucht, wird mit den lokalen Bling-Varianten nicht glücklich. Auch für Teams, die bereits eine ausgereifte Cloud-RAG-Kette mit gehostetem Vektorindex betreiben, ist der Wechsel ein Rückschritt an Bequemlichkeit: llmware verlangt, dass Embedding-Modell, Vektorindex und Inferenz-Backend selbst betrieben und aktualisiert werden. Ein dritter Fall: Wenn der Dokumentenbestand fast ausschließlich aus gescannten PDFs ohne Textebene besteht, entscheidet die OCR-Qualität über das gesamte Ergebnis, und die README macht dazu keine Angaben. Als Alternative bietet sich ein Vektordienst mit eigener Ingestion-Pipeline an, etwa ein gehosteter Index, bei dem das Parsen und Einbetten vom Anbieter übernommen wird. Der Unterschied liegt genau dort: llmware gibt die Kontrolle über Datenhaltung und Modellwahl, nimmt aber das Betriebsrisiko nicht ab. Wer die Kontrolle nicht braucht, zahlt mit llmware für etwas, das er nicht nutzt.

Redaktionelles Fazit

llmware passt zu Teams, die Dokumentenbestände auf eigener Hardware durchsuchbar machen wollen und dafür kleine, quantisierte Modelle akzeptieren. Wer maximale Antwortqualität aus großen Cloud-Modellen braucht oder eine ausgereifte Parser-Dokumentation für jede Dateiendung erwartet, sollte zuerst die Beispiele im Repository gegen die eigenen PDFs, Tabellen und Audioformate laufen lassen. Vor dem Produktiveinsatz ist konkret zu prüfen, ob lib.install_new_embedding mit dem gewählten vector_db-Wert die eigenen Datenmengen in der angegebenen batch_size verarbeitet und ob die installierte Python-Version im Bereich 3.10 bis 3.14 liegt.

Offizielle Quellen

1. License: Apache-2.0
2. llmware-ai/llmware on GitHub
3. Project website
4. README
5. Releases