Offline-First-KI: Ein LLM, das ohne Netz funktioniert

Der Strom ist seit neun Stunden weg, das Mobilfunknetz ist überlastet, und die Gefriertruhe in deiner Garage ist voll mit Fleisch, das du am Samstag gekauft hast. Ist es noch essbar? Normalerweise würdest du einen Chatbot fragen. Im Moment ist aber das Internet das Erste, was ausgefallen ist. Dieses Szenario ist das Designbriefing für eine wachsende Klasse von Offline-First-KI-Tools: ein Assistent und eine Referenzbibliothek, die komplett auf deinem Laptop laufen. Das Modell, der Korpus, der Suchindex – alles läuft lokal, sodass die Frage „Wie reinige ich dieses Wasser?“ auch dann funktioniert, wenn das Ethernetkabel abgezogen ist. Als Architekturübung finde ich das spannender als Notfallausrüstung. Wenn man das Netz wegnimmt, muss man Entscheidungen treffen, die cloudbasierte KI einfach ignorieren kann, und diese Entscheidungen sind weit über Notfallkits hinaus nützlich. Wenn du dich schon mit dem lokalen Betrieb großer Sprachmodelle auf eigener Hardware beschäftigt hast, sind die Einschränkungen eines Offline-Assistenten die scharfe Spitze dieses Problems.

Was Offline-First-KI tatsächlich mitliefern muss

Ein Cloud-Assistent ist schlank: Dein Client schickt Text, ein Rechenzentrum schickt Tokens zurück. Ein Offline-Assistent muss den gesamten Stack auf Consumer-Hardware nachbauen, das heißt, drei große Komponenten ausliefern und dafür sorgen, dass sie harmonieren. Erstens die Inferenz-Engine. In der Praxis heißt das llama.cpp oder eine seiner Abwandlungen, weil es auf Apple Silicon, gewöhnlichen x86-CPUs und Consumer-GPUs mit einem einzigen Abhängigkeitsbaum läuft. Die Mac-App bündelt sie; der Windows-Build holt sie während der Einrichtung nach. In beiden Fällen kannst du nicht voraussetzen, dass sie auf dem Rechner des Nutzers existiert – du installierst sie selbst, unauffällig, beim ersten Start. Zweitens das Modell. Hier wird es spannend, und ich komme darauf zurück, denn die Wahl des richtigen Modells ist das zentrale Designproblem. Drittens die Bibliothek. Ein Offline-Assistent in diesem Bereich enthält etwa 930.000 Wikipedia-Artikel (die meistgelesene Teilmenge), medizinische Referenzen wie MedlinePlus und WikiMed, Notfallleitfäden von FEMA und CDC, Überlebenshandbücher des Militärs, wikiHow, iFixit-Reparaturanleitungen und Stack-Exchange-Q&A-Dumps zu Themen wie Hausreparatur und Amateurfunk. Alles als Klartext, alle Lizenzen bleiben erhalten und werden pro Artikel angezeigt. Der vollständige Download umfasst etwa 9 GB und wächst installiert auf 19 GB an; eine schlanke Version ohne Wikipedia und iFixit kommt auf 1,3 GB. Das ist ebenso eine kuratorische Entscheidung wie eine technische – jemand hat festgelegt, welche Quellen den Schnitt überstehen. Das Ganze muss in ein Setup mit drei Schritten passen, das fünf Minuten Klickarbeit und bis zu zweieinhalb Stunden Download dauert. Diese letzte Zahl ist wichtiger, als sie aussieht: Das Download-Fenster ist deine einzige Chance, überhaupt etwas zu holen. Es ist dieselbe Disziplin, die man bei Software anwendet, die man nicht neu starten oder erreichen kann, nur dass die unerreichbare Umgebung eine sturmdunkle Küche ist.

Das Modell-Stufenproblem: Eine App, viele Gehirne

Hier kommt die Entscheidung, vor der Cloud-Software nie steht: Du weißt nicht, welche Hardware dein Nutzer hat, du kannst seinen RAM nicht abfragen und ihn nicht auf einen größeren Cluster umleiten, und die Antwort verändert sowohl die Download-Größe als auch die Qualität jeder einzelnen Antwort, und zwar dauerhaft. Die Lösung in dieser Werkzeugkategorie ist ein hardwaregesteuertes Stufensystem. Beim ersten Start prüft die App den Systemspeicher und wählt ein Modell, das passt: - 128 GB oder mehr: ein großes Flaggschiff-Modell (eine Version nutzt NVIDIA Nemotron 3.5 Super, ca. 80 GB auf der Festplatte), das beim blinden Test des Projekts zu Blackout- und Erste-Hilfe-Fragen 21 von 22 Punkten erreicht. - 32–96 GB: ein Modell mittlerer Größe mit rund 27 Mrd. Parametern (ca. 18 GB), ebenfalls 21 von 22. - 32 GB unter Windows: ein geschwindigkeitsoptimiertes Modell mit ca. 25 GB, 19 von 22. - 16–31 GB: ein Modell der 8B-Klasse (ca. 6 GB), 14 von 22. Lies die letzte Zeile noch einmal. Der Rechner, den die meisten Leute tatsächlich besitzen – ein Laptop mit 16 GB –, bekommt ein Gehirn, das den Kernpunkt offizieller Empfehlungen etwa in einem Drittel der Fälle verfehlt, und zwar bei Fragen, bei denen der Kernpunkt Dinge sind wie „Iss das Hähnchen nicht, das sechs Stunden bei Raumtemperatur lag.“ Das ist die unbequeme Rechnung der Offline-First-KI. Quantisierung und kleine Modelle sind inzwischen wirklich gut – ein gut abgestimmtes 8B-Modell ist ein brauchbarer Schreibassistent und eine passable Suchoberfläche. Aber die Qualitätskurve passt sich nicht deinen Einsatzbedingungen an. Wenn eine Cloud-App ein intelligenteres Modell will, setzt sie ein Konfigurations-Flag um. Wenn eine Offline-App eines will, braucht der Nutzer einen größeren Laptop, den er vor drei Jahren hätte kaufen müssen. Du lieferst die Kurve aus, und die Kurve liefert dich aus. Die ehrliche Gegenmaßnahme ist die, die diese Tools übernehmen: Behandle das kleine Modell als Schnittstelle zum Korpus, nicht als Autorität darüber. Jede Antwort listet genau auf, welche Artikel gelesen wurden, mit markierter Textstelle, weil die Entwickler wissen, dass die 8B-Stufe manchmal falschliegt.

Retrieval als Vertrauensschicht, nicht als Feature

Jedes RAG-System (Retrieval-Augmented Generation) zeigt inzwischen seine Quellen; in der Cloud ist das ein Kontrollkästchen, eine Art Transparenz-Theater. Offline trägt das Retrieval die Last. Es ist das Einzige, was zwischen einer plausibel klingenden Halluzination und einem Nutzer steht, der in einem echten Notfall danach handelt. Das Design, das sich daraus ergibt, sieht so aus: Das Modell durchsucht die Klartext-Bibliothek, liest die besten Passagen und schreibt eine Antwort, die zitiert, was es gelesen hat. Bittet der Nutzer darum, etwas nachzuschlagen, sucht es auch dann, wenn es bereits aus dem Gedächtnis geantwortet hatte – und die Oberfläche zeigt an, aus welchem Modus jede Antwort stammt: Gedächtnis, geöffnete Artikel oder Suchtreffer, die nie geöffnet wurden. Diese letzte Unterscheidung ist subtil und wichtig. „Ich habe passende Ausschnitte gefunden“ und „Ich habe den Artikel gelesen“ sind unterschiedliche Behauptungen mit unterschiedlicher Verlässlichkeit, und die Oberfläche behandelt sie auch so. Es gibt außerdem ein Fehlerszenario, das ich besonders mag: Wenn das Modell losgesucht, aber nie eine finale Antwort geschrieben hat – was kleine Modelle tatsächlich tun –, füttert die App es jetzt mit den besten gefundenen Artikeln und lässt es noch einmal versuchen, statt dem Nutzer nichts zu zeigen. Offline kannst du nicht auf ein größeres Modell oder eine Retry-Queue zurückgreifen. Du baust den Retry direkt in die Agenten-Schleife ein. Das ist ein kompaktes Beispiel für das, was man meint, wenn man sagt, LLM-Agenten verhalten sich wie verteilte Systeme: Teilausfälle überall, und die Orchestrierungsschicht muss dafür sorgen, dass der Ausfall überlebbar ist. Eine weitere Architekturentscheidung lohnt sich, sie zu übernehmen: das Denkbudget. Die App legt fest, wie viele Tokens das Modell vor der Antwort denken darf – aus, 1.000, 4.000, 16.000 oder unbegrenzt. Wird das Limit erreicht, bricht das Denken ab und das Modell antwortet mit dem, was es bis dahin hat. Im Akkubetrieb ist ein Modell, das sich im Kreis dreht, nicht nur falsch, sondern ein Stromfresser. Eine harte Obergrenze macht aus einem unbegrenzten Rechenproblem ein begrenztes – genau der Instinkt, den du brauchst, wenn die Steckdose nur theoretisch existiert.

Die Skeptiker haben einen Punkt (zur falschen Hälfte)

Die schärfste Kritik an diesem Genre: Warum nicht das LLM weglassen und ein durchsuchbares Archiv ausliefern? Kiwix macht genau das seit Jahren – Wikipedia und medizinische Referenzen, komprimiert, indiziert, offline durchsuchbar, ohne Halluzinationsrisiko, läuft auf einer alten Kiste. Und für einen kuratierten Textbestand ist eine Suchmaschine wohl das verlässlichere Werkzeug. Ein Tester fragte den Offline-Assistenten, wie man einen Bogenbohrer baut, und bekam die Teile richtig, aber die Bewegung falsch: Das Modell beschrieb, wie man die Spindel zwischen den Handflächen rollt, ignorierte den Bogen völlig und erwähnte „das Anfachen der Funken“, was ein Reibungsfeuer gar nicht erzeugt. Eine Suchmaschine kann diesen Fehler nicht machen, weil sie nichts generiert. Aber ich glaube, diese Kritik verfehlt, wofür das LLM in solchen Systemen eigentlich da ist, und die stärkste Verteidigung des Designs besteht darin, seine Rolle neu zu beschreiben: Das Modell ist eine Suchintelligenz, kein Orakel. Die Stichwortsuche scheitert, wenn du das Vokabular nicht kennst – wenn du Symptome hast statt einer Diagnose, ein kaputtes Ding statt eines Teilnamens. Semantisches Retrieval hilft bei „ähnlich in der Bedeutung“, aber nicht bei „verbunden durch Mechanismus oder Ursache“. Genau diese Lücke schließt ein generatives Modell: Es kann aus „Pflanzen werden an den Blatträndern gelb“ fünf Spuren ableiten, auf die eine Stichwortsuche nie gekommen wäre. Die Aufgabe des Modells ist, dich zu den richtigen Seiten zu bringen. Die Aufgabe der Seiten ist, richtig zu sein. Die andere Kritik – „Wenn du in der Apokalypse ein LLM brauchst, lerne einfach die Fähigkeiten“ – ist als Lebensratschlag fair und als Software-Kritik nutzlos. Das Erste-Hilfe-Wissen von niemandem umfasst Verbrennungen bei Kindern, Chemie der Wasseraufbereitung und Generatorreparatur. Bücher decken all das ab; die Frage betrifft nur die Oberfläche. Dort, wo die Skeptiker wirklich treffen, ist die Stufe mit 14 von 22 Punkten. Wenn die Oberfläche ein Drittel der Zeit falsch liegt und jede Antwort einen Hinweis „Prüfe die Quellen“ trägt, ist irgendwann das ehrliche Produkt das Archiv mit einem Suchfeld. Das LLM verdient seinen Platz nur, solange es nachweislich Laien schneller zur richtigen Passage bringt als Strg+F. Das ist eine empirische Frage über deine Nutzer, kein Bauchgefühl.

Ein minimaler Offline-First-KI-Stack

Wenn du deine eigene Version davon bauen willst – und du solltest es tun, es ist ein wirklich lehrreiches Wochenendprojekt –, ist das Grundgerüst kleiner, als du erwartest. Die spannenden Teile sind die Entscheidungen, nicht der Code. Ein lokaler Assistent mit Retrieval-Vorrang in Python sieht grob so aus:

import subprocess
from pathlib import Path
CORPUS_DIR = Path("./library")          # plain-text articles, one file each
MODEL = "./models/granite-8b-q4.gguf"   # quantized to fit 16 GB RAM
def search_corpus(query: str, k: int = 5) -> list[dict]:
"""Dumb but honest: rank articles by keyword overlap.
Swap in BM25 or embeddings later; the interface is the point."""
terms = set(query.lower().split())
hits = []
for f in CORPUS_DIR.rglob("*.txt"):
text = f.read_text(errors="ignore")
score = sum(text.lower().count(t) for t in terms)
if score:
hits.append({"path": f.name, "score": score, "text": text[:3000]})
return sorted(hits, key=lambda h: -h["score"])[:k]
def answer(question: str) -> str:
sources = search_corpus(question)
context = "\n\n".join(
f"[SOURCE {i}: {s['path']}]\n{s['text']}"
for i, s in enumerate(sources, 1)
)
prompt = (
"Answer ONLY from the sources below. Cite them as [SOURCE n]. "
"If they don't cover it, say so.\n\n"
f"{context}\n\nQuestion: {question}\nAnswer:"
)
out = subprocess.run(
["llama-cli", "-m", MODEL, "-p", prompt,
"-n", "512", "--ctx-size", "8192"],
capture_output=True, text=True,
)
citations = "\n".join(f"[{i}] {s['path']}" for i, s in enumerate(sources, 1))
return out.stdout + "\n\n--- Sources ---\n" + citations
print(answer("how long is food safe in a fridge without power"))

Was das Ganze von einem Spielzeug zu einem Produkt macht, steckt in den Einschränkungen, die in diese vierzig Zeilen eingebaut sind: Der Prompt verbietet Antworten außerhalb der Quellen, Zitate werden maschinell angehängt (dem Modell wird nie zugetraut, sie zu formatieren – ein realer Fehler bestand darin, dass Modelle eine Zeile „Quellen:“ erfanden, die ihre eigenen Suchbefehle auflistete), und die Länge der Generierung ist begrenzt. Was hier fehlt, aber für den Produktivbetrieb nötig wäre: ein Embedding-Index für die semantische Suche, ein Budget für Denk-Tokens, eine Speicherprüfung zur Auswahl der Modelldatei und Lizenz-Metadaten pro Datei, damit die Oberfläche sie anzeigen kann. Beachte, was nicht drin ist: keine Netzwerkaufrufe, keine API-Schlüssel, keine Telemetrie. Sobald Modelldatei und Korpus auf der Platte liegen, ist dieses Programm physisch nicht in der Lage, eine Frage nach außen zu tragen. Datenschutz ist dann keine Richtlinie mehr, sondern eine Folge des Abhängigkeitsgraphen.

Die Einschränkungen, die mit dir nach Hause kommen

Wer offline-first baut, dem bleiben einige nicht offensichtliche Einschränkungen dauerhaft in der Architektur erhalten. **Speicher und Installationsfenster sind einmalig.** Die vollständige Bibliothek braucht während der Installation etwa 27 GB freien Speicher, bevor sie sich auf 19 GB einpendelt, und alles muss beim ersten Download ankommen. Es gibt kein Nachladen einer fehlenden medizinischen Referenz während eines Hurrikans. Das treibt dich zu rigoroser Kuratierung – 930.000 Artikel klingen nach viel, bis man sich erinnert, dass Wikipedia Millionen hat. Jemand hat nach Lesezahlen sortiert und den Schwanz abgeschnitten. **Strom ist eine erstklassige Ressource.** Auf einem MacBook Pro gemessen zieht eine Antwort etwa 100 W für 5 bis 40 Sekunden pro Frage – ein voller Akku reicht für ungefähr 100 bis 300 Antworten. Plötzlich ist lange Gedankenkette nicht nur langsam, sondern eine Treibstoff-Entscheidung. Denkbudgets und kleine Modellstufen hören auf, Optimierungen zu sein, und werden zum Produkt. **Dein Update-Kanal ist deine Rettungsleine.** Die App muss Modelle, Bibliothek und Binärdatei mit einem Klick aktualisieren, ohne den lokalen Zustand zu zerstören, denn bis der Nutzer wieder Bandbreite hat, können Monate vergehen. Und Disziplin beim Hintergrund-Ressourcenverbrauch wird auf neue Weise wichtig: Ein Fix in einer Version sorgte dafür, dass Cmd+Q die Inferenz-Engine tatsächlich beendet, die ein mehrere Gigabyte großes Modell im Speicher gehalten hatte, nachdem das Fenster geschlossen war. Im Akkubetrieb ist das kein Speicherleck, sondern ein Wärme- und Stundenleck. **Nutzerdateien gehören zur Vertrauensgrenze.** Wenn Nutzer eigene PDFs hineinziehen können – ein Generatorhandbuch, ein familiärer Notfallplan –, muss deine Retrieval-Pipeline mit potenziell bösartig oder schlicht chaotisch aufbereiteten Eingaben umgehen: eingescannte PDFs, seltsame Kodierungen, riesige Dateien. Offline kannst du davon nichts an einen Cloud-Parser auslagern.

Warum dieses Muster über Notfälle hinaus wichtig ist

Datenschutz wird vom Richtlinienversprechen zur Folge des Abhängigkeitsgraphen. Ein Programm ohne Netzwerkaufrufe kann nie etwas abfließen lassen.

Die Notfall-Rahmung macht die Schlagzeilen, aber die Architektur ist die eigentliche Geschichte. Derselbe Stack – lokale Inferenz, kuratierter Korpus, Retrieval mit Zitaten, harte Rechenbudgets – ist das, was du für eine Klinik mit Patientendaten brauchst, die rechtlich das Gebäude nicht verlassen dürfen, eine Fabrikhalle mit luftgetrennten Maschinen, einen Journalisten in einem Land, in dem ein Abfrageprotokoll ein Risiko ist, oder ein Forschungsschiff mit Satelliteninternet, das nach Megabyte abgerechnet wird. Ein Praktiker in der Diskussion beschrieb genau das: eine manuell kuratierte Bibliothek plus lokale Modelle auf einem Grundstück ohne Mobilfunkempfang, vor jeder Reise aktualisiert, die den Großteil seiner täglichen Cloud-KI-Nutzung schrittweise ersetzt hat – selbst wenn Glasfaser verfügbar ist. Das ist die Entwicklung, auf die ich setzen würde. Die Lücke zwischen einem quantisierten 8B-Modell lokal und einer Frontier-API ist real, aber schmal genug, dass bei retrieval-gestützten Aufgaben – „Finde die richtige Passage und fasse sie treu zusammen“ – die lokale Option oft ausreicht, und Ausreichendes plus null Grenzkosten plus garantierter Datenschutz ist ein überzeugendes Paket. Die Frontier-Modelle werden weiter besser, aber Quantisierung ebenso, und kleine Modelle reiten mit etwas Verzögerung auf derselben Skalierungswelle. Wenn dich das Effizienz-Ende dieser Kurve interessiert, liegt die eigentliche Geschichte der Inferenzeffizienz bei Modellen der Flash-Klasse. Mein Rat, wenn du in diesem Bereich etwas entwirfst: Übernimm das Muster, nicht die Prepper-Ästhetik. Kuratiere radikal – eine Bibliothek mit 200 Dokumenten, denen du vertraust, schlägt 930.000, die du nie gelesen hast. Mach Zitate mechanisch, nie vom Modell generiert. Gib dem Modell ein hartes Budget zum Nachdenken. Und entscheide ausdrücklich, ob dein Modell ein Orakel oder eine Suchoberfläche ist. Die Werkzeuge, die einer genauen Prüfung standhalten, sind die ehrlichen genug, das Zweite zu sein.

Fazit

Offline-First-KI handelt nicht vom Überleben der Apokalypse. Es geht darum herauszufinden, wie deine Architektur aussieht, wenn jeder Fluchtweg – ein größeres Modell, ein Cloud-Fallback, ein ständig verfügbares Netz, unbegrenzter Strom – verschweißt ist. Übrig bleiben ein kuratierter Korpus, ein quantisiertes Modell, das auf Hardware passt, die du nicht kontrollierst, Retrieval, das das Vertrauen trägt, und eine Agenten-Schleife, die so gebaut ist, dass sie kontrolliert versagt. Diese Disziplinen erweisen sich auch online als gut. Der Sturm bringt dir nur bei, sie schneller zu lernen.