Du sitzt im Zug ohne Netz und möchtest in einem Digital Garden wie lukiluki nach verwandten Artikeln suchen oder Fragen an gespeicherte Inhalte stellen. Muss die KI dafür einen Server erreichen – oder kann die Web-App selbst rechnen?
Ja: Web-Apps können Embeddings berechnen, semantisch suchen und mit einem passenden Sprachmodell auch Chatbots offline betreiben. Ebenso sind Textklassifikation, Spracherkennung und bestimmte Bildaufgaben möglich. Die Modelle rechnen dabei auf deinem Gerät. Voraussetzung sind eine offline startbare App sowie lokal verfügbare Modelle, Laufzeitdateien und Inhalte. Ob das sinnvoll funktioniert, hängt von Modellqualität, Browser, Arbeitsspeicher und Rechenleistung ab.
Offline-KI braucht drei Dinge gleichzeitig: eine startbare App, ein lokal ausführbares Modell und lokal verfügbare Daten. Ein installierbares App-Symbol oder ein gespeicherter Chatverlauf reicht dafür nicht.
Wie rechnet eine Web-App ohne KI-Server?
Bei lokaler (Ein bereits trainiertes Modell verarbeitet neue Eingaben auf deinem Gerät; das Modell wird dabei nicht neu trainiert.) führt der Browser ein fertig trainiertes Modell aus. Statt eine Frage an eine Cloud-API zu schicken, übergibt die Oberfläche sie an eine lokale Modellbibliothek. Das benötigt keinen API-Schlüssel für die Modellberechnung. Der erstmalige Bezug der App und Modelldateien braucht normalerweise eine Verbindung; danach lässt sich der vorbereitete Funktionsumfang offline nutzen.
Zwei verbreitete Bausteine sind Transformers.js für Text-, Bild- und Audioaufgaben und WebLLM für lokale Sprachmodelle mit Chat-Schnittstelle. Nicht jedes beliebige Modell lässt sich damit laden: Architektur, Dateiformat und unterstützte Rechenoperationen müssen zur Bibliothek passen.
(Ein ausführbares Binärformat für Browser; KI-Laufzeiten können damit Berechnungen auf der CPU ausführen, kurz WASM.) ermöglicht einen CPU-Rechenpfad. (Eine Browser-Schnittstelle, über die geeignete Programme die Grafikkarte auch für allgemeine Berechnungen nutzen können.) kann die Grafikkarte nutzen. Transformers.js unterstützt beide Wege; WebLLM setzt WebGPU voraus. Ein vorhandenes Browser-API beweist noch nicht, dass ein bestimmtes Modell auf dem Gerät läuft. Dafür muss das Modell tatsächlich geladen und mit einer Eingabe ausgeführt werden.
Die Oberfläche bleibt besser bedienbar, wenn rechenintensive Arbeit in einem separaten Web Worker läuft. Dieser führt die Berechnung außerhalb des Hauptthreads aus. Ein Service Worker erfüllt eine andere Hauptaufgabe: Er kann beim Offline-Start gespeicherte App-Dateien ausliefern. WebLLM dokumentiert Worker und Modell-Caches; MDN erklärt den Offline-Start per Service Worker.
Welche KI-Funktionen sind offline möglich?
Die Tabelle beschreibt technische Möglichkeiten mit passenden Modellen, keine gemessenen Geschwindigkeiten oder Zusagen für jedes Handy. Alle Zeilen setzen vollständig lokal verfügbare Dateien voraus.
| Funktion | Geht offline? | Beispiel in einer Web-App | Entscheidende Grenze |
|---|---|---|---|
| Embeddings | Ja | Artikel oder eigene Notizen in Zahlenvektoren umwandeln | Sprachabdeckung und Eignung des Embedding-Modells prüfen |
| Semantische Suche | Ja | „Lange Ladezeit“ findet einen Artikel über Performance | Auch die Suchanfrage braucht einen kompatiblen Vektor |
| Chatbot | Ja, mit lokalem Sprachmodell | Fragen beantworten oder einen Entwurf formulieren | Modell muss in den Speicher passen; Qualität und Tempo variieren |
| Dokumentenchat | Ja, wenn die gesamte Kette lokal ist | Antworten mit Fundstellen aus gespeicherten Artikeln | Dokumente, Suche und Antwortmodell dürfen keine Cloud benötigen |
| Klassifikation | Ja | Notizen nach Thema sortieren | Modell muss die gewünschten Kategorien sinnvoll abbilden |
| Zusammenfassen und Übersetzen | Mit geeignetem Modell | Einen gespeicherten Text kürzen oder übersetzen | Eingabelänge, Sprache und Qualität sind modellabhängig |
| Sprache zu Text | Mit geeignetem Audiomodell | Eine lokale Aufnahme transkribieren | Audiodauer, Speicher und Rechenzeit begrenzen die Nutzung |
| Text zu Sprache | Mit geeignetem Sprachmodell | Einen Artikel vorlesen lassen | Stimme und benötigte Dateien müssen lokal verfügbar sein |
| Bildanalyse | Mit geeignetem Bildmodell | Bilder klassifizieren oder Objekte erkennen | Unterstützung gilt für konkrete Aufgaben und Modellarchitekturen |
Die Aufgabenübersicht von Transformers.js belegt unter anderem Feature Extraction, Klassifikation, Generierung sowie Audio- und Bildaufgaben. Für Chat dokumentiert WebLLM Modellinitialisierung und gestreamte Antworten.
Wie funktionieren lokale Embeddings und Suche?
Embeddings sind Zahlenvektoren, die ein Modell aus Text erzeugt. Für einen Digital Garden berechnest du zunächst Vektoren für Artikelabschnitte und speicherst sie zusammen mit Text, Titel und Link lokal. Eine neue Suchanfrage durchläuft dasselbe Embedding-Verfahren. Anschließend vergleicht die App ihren Vektor mit den gespeicherten Vektoren und zeigt passende Fundstellen an.
Der entscheidende Unterschied: Vektoren vergleichen ist keine neue Modellberechnung. Ein kleiner Datenbestand lässt sich direkt im Browser durchsuchen; eine Cloud-Vektordatenbank ist dafür nicht zwingend nötig. Bei großen Beständen werden Speicherbedarf und ein geeigneter Suchindex wichtiger.
Für öffentliche Artikel kannst du die Dokumentvektoren bereits beim Website-Build erzeugen. Der Browser muss dann nur noch die Suchanfrage einbetten. Private Notizen lassen sich dagegen vollständig auf dem Gerät verarbeiten. In beiden Fällen müssen Dokument- und Anfragevektoren aus demselben kompatiblen Modellraum stammen: gleiche Modellversion und zusammenpassende Vorverarbeitung, Dimensionen sowie gegebenenfalls vom Modell verlangte Präfixe für Anfrage und Dokument. Gleiche Vektorlänge allein genügt nicht.
Ein mit einem Cloud-Modell erzeugter Artikelindex lässt sich deshalb nicht beliebig mit einem kleinen lokalen Modell weiternutzen. Bei einem Modellwechsel müssen die Dokumentvektoren passend neu erzeugt werden. Für deutsche Artikel prüfst du außerdem deutsche Suchanfragen und Umschreibungen; ein englisch optimiertes Modell ist dafür keine verlässliche Standardwahl. Wie Vektoren und Ähnlichkeit zusammenspielen, erklärt die Kachel Embeddings – ähnliche Inhalte finden.
Was braucht ein Offline-Chatbot zusätzlich?
Ein Chatbot benötigt ein generatives Sprachmodell: Es erzeugt die Antwort Stück für Stück. Ein Embedding-Modell allein kann das nicht. Ein lokal laufender Chat kennt außerdem weder automatisch deine Artikel noch aktuelle Informationen aus dem Internet.
Für einen Chat über Garden-Inhalte passt (Retrieval-Augmented Generation: Eine Suche liefert relevante Textstellen, die ein Sprachmodell als Kontext für seine Antwort erhält.): Die App sucht zuerst passende gespeicherte Abschnitte und gibt diese zusammen mit der Frage an das lokale Sprachmodell. Die Antwort sollte auf die verwendeten Fundstellen verweisen. Gibt es keinen passenden Beleg, soll die Oberfläche das kenntlich machen. Auch mit passenden Textstellen können falsche Antworten entstehen.
Das durchgehende Beispiel wäre: „Wie mache ich meine Seite schneller?“ wird lokal eingebettet, findet gespeicherte Performance-Abschnitte und wird mit diesen an das Antwortmodell übergeben. Suche, Kontext und Antwort bleiben auf dem Gerät. Eine aktuelle Webrecherche oder ein externes Tool benötigt weiterhin eine Verbindung.
Für Chat ist neben den Modelldateien auch zusätzlicher Arbeitsspeicher für Berechnungen und Gesprächskontext nötig. Ein kleinerer Download bedeutet deshalb nicht denselben Speicherverbrauch zur Laufzeit. (Modellgewichte werden mit weniger Bits gespeichert; das kann Dateigröße und Speicherbedarf senken, aber Qualität und Hardware-Kompatibilität verändern.) kann helfen, ersetzt jedoch keinen Gerätetest. Begrenze Gesprächslänge und Fundstellen auf das Kontextfenster des gewählten Modells.
Für einen Digital Garden ist deshalb lokale Suche ein sinnvoller erster Ausbau: Sie liefert direkt überprüfbare Treffer. Ein zusätzliches Chatmodell lohnt sich, wenn formulierte Antworten einen erkennbaren Nutzen bieten und auf den Zielgeräten gut genug funktionieren. Wie eine Suche ihre Treffer für Menschen verständlich macht, zeigt Intuitive Suche.
Wie wird daraus eine wirklich offline nutzbare App?
Bereite die App auf einer sicheren Herkunft vor, im Betrieb üblicherweise HTTPS und bei lokaler Entwicklung localhost. Wähle ein unterstütztes Modell mit passender Lizenz und teste es auf deinen Zielgeräten. Ein Manifest und die Installation als (Progressive Web App: Eine Web-App, die unter anderem installierbar sein kann; ihre Offline-Fähigkeit muss zusätzlich umgesetzt werden.) ersetzen diese Vorbereitung nicht.
- App und Inhalte speichern. Halte die Einstiegsseite, benötigte Skripte, Styles, Schriften und gewünschte Artikel offline vor. Prüfe auch direkte Aufrufe und Navigation zwischen gespeicherten Seiten. Ein bereits offener Tab reicht als Nachweis nicht.
- Das vollständige Modellpaket vorbereiten. Dazu gehören Gewichte, Tokenizer, Konfiguration und benötigte Laufzeitdateien. Transformers.js kann Modelle und WASM-Dateien standardmäßig von externen Hosts beziehen; lokale Pfade und Remote-Laden sind konfigurierbar. Eine Datei unter einer eigenen URL ist erst offline verfügbar, wenn sie tatsächlich gespeichert wurde.
- Lokale Daten versionieren. Speichere Texte und Vektoren beispielsweise in IndexedDB, einer Browser-Datenbank für strukturierte Daten. Nutze den Cache der Modellbibliothek beziehungsweise die Cache API für passende Dateien. Lege Modell- und Indexversion gemeinsam fest, damit ein Update keine inkompatiblen Vektoren mischt.
- Speicher und Bereitschaft prüfen. Zeige Downloadfortschritt, fehlende Dateien und Speicherfehler verständlich an. Melde „offline bereit“ erst nach vollständig geladenem Paket und erfolgreichem Testlauf. Der Status muss nach gelöschten oder unvollständigen Daten wieder zurückgesetzt werden.
- Den Ausfall mitplanen. Wenn das Modell nicht läuft, bleiben gespeicherte Artikel und eine einfache Textsuche nutzbar. Biete eine Cloud-Alternative nur als bewusste Auswahl an, wenn dafür Eingaben das Gerät verlassen.
Browser-Speicher ist begrenzt. Daten können durch Nutzer oder bei Speicherdruck gelöscht werden; privates Browsen hat zusätzliche Einschränkungen. Die Storage API kann Belegung schätzen und dauerhafte Speicherung anfragen, deren Gewährung vom Browser abhängt. Eigene Daten brauchen weiterhin eine Exportmöglichkeit. MDN beschreibt Speicherquoten und Löschregeln.
Lokale Inferenz benötigt keinen Upload deiner Eingabe. Analysewerkzeuge, Fehlerberichte, Synchronisierung oder ein Cloud-Fallback können trotzdem Daten übertragen. Prüfe den gesamten Datenfluss und mache solche Übertragungen sichtbar.
Wie prüfst du das Ergebnis ohne Internet?
Teste den vorbereiteten Funktionsumfang im Produktions-Build. Notiere Browser, Gerät, Modellversion und Quantisierung zu deinen Ergebnissen. Miss Ladezeit und Antwortverhalten auf den tatsächlichen Zielgeräten; aus der Unterstützung von WebGPU allein lässt sich keine verlässliche Geschwindigkeit ableiten.
- Kalt starten: Nach vollständiger Vorbereitung die App schließen, Netzwerkzugriff blockieren und erneut öffnen. Einstieg, gespeicherte Artikel und Navigation müssen funktionieren.
- Neue Eingaben rechnen: Eine bisher unbenutzte Suchanfrage und gegebenenfalls eine neue Chatfrage stellen. Es müssen neue Ergebnisse entstehen; ein gespeicherter Verlauf ist kein Beweis für Offline-Inferenz.
- Fundstellen prüfen: Eine deutsche Umschreibung zu einem gespeicherten Thema und eine Frage außerhalb des Bestands testen. Treffer müssen nachvollziehbar sein; unbelegte Chatantworten dürfen nicht als gesicherte Fakten erscheinen.
- Fehlerfälle prüfen: Fehlende Modelldateien, gelöschte Caches und ein ungeeignetes Gerät testen. Erwartet werden verständliche Hinweise und weiter lesbare Inhalte, keine endlose Ladeanzeige.
- Netz und Bedienung prüfen: Den Netzwerkverkehr auch bei bestehender Verbindung kontrollieren; die lokale Verarbeitung darf keine Eingaben versenden. Suche und Chat müssen auf kleinen Bildschirmen und per Tastatur bedienbar bleiben, auch während das Modell rechnet.
Quellen und nächste Schritte
Die Quellen beschreiben unterstützte Verfahren und Voraussetzungen; sie ersetzen keinen Test deines Modells auf deinen Zielgeräten.
- Transformers.js: Aufgaben und Rechenpfade – welche Text-, Audio- und Bildpipelines verfügbar sind.
- Transformers.js v3.8.1: lokale Modelle und Laufzeitdateien – konkrete Konfiguration einer dokumentierten Version; für andere Versionen deren Dokumentation prüfen.
- WebLLM: Chat und Modellinitialisierung – lokales Antwortmodell laden und verwenden.
- WebLLM: Worker und Caching – Berechnung auslagern und Modellartefakte speichern.
- MDN: Offline-Betrieb von Web-Apps – App-Ressourcen ohne Netz ausliefern.
- MDN: Browser-Speicher und Löschregeln – Quoten, Persistenz und Datenverlust einordnen.
Vertiefe die Funktionsweise von Embeddings, bevor du einen Suchindex aufbaust, und nutze Intuitive Suche für die Gestaltung nachvollziehbarer Suchergebnisse.