Kann KI ohne Cloud laufen? Was heute wirklich auf dem Gerät funktioniert

Warum diese Frage inzwischen fast immer kommt

In jedem zweiten Gespräch über KI fällt irgendwann derselbe Satz: „Unsere Daten dürfen das Haus nicht verlassen." Danach folgt meistens eine Runde über Serverstandorte, Auftragsverarbeitungsverträge und die Frage, ob der Anbieter mit den Daten trainiert.

Es gibt eine Antwort, die diese ganze Diskussion überspringt. Die Daten verlassen das Gerät gar nicht erst.

Das klingt nach Marketing, ist aber technisch inzwischen realistisch. Ich habe es gebaut: SpeakFlow AI, eine iOS-App für Sprache-zu-Text, Text-zu-Sprache und KI-Textaktionen, seit Kurzem im App Store. Sie funktioniert wahlweise vollständig ohne Cloud. Kein Server von mir, der irgendwas sieht. Wer lieber die großen Modelle nutzen will, bringt seinen eigenen API-Schlüssel mit.

Was dabei herausgekommen ist, taugt als ehrliche Bestandsaufnahme: Was lokale KI heute kann, wo sie aufhört und welche Fallen niemand erwähnt.

Was heißt „auf dem Gerät" überhaupt?

Der Begriff wird ziemlich großzügig benutzt. Manche Anbieter meinen damit, dass ein kleiner Vorverarbeitungsschritt lokal läuft und der Rest trotzdem in die Cloud geht.

Ich meine damit: Das Modell liegt als Datei auf dem Telefon, die Berechnung passiert auf dem Chip im Telefon, und im Flugmodus funktioniert alles genauso. Kein Netzwerkverkehr, keine API, kein Anbieter dazwischen.

Für die drei Aufgaben in der App sieht das so aus:

Spracherkennung: sieben Modelle zur Auswahl, von 78 MB bis 1,08 GB.
Sprachausgabe: ein deutsches Sprachpaket von etwa 342 MB, einmalig geladen.
Textverarbeitung: fünf lokale Sprachmodelle zwischen 505 MB und 2,9 GB, dazu Apple Intelligence, das schon im System steckt und keinen zusätzlichen Speicher braucht.

Das sind reale Downloads auf ein reales Telefon. Wer die Größen sieht, versteht sofort den ersten Haken: Das ist kein Feature, das man nebenbei mitliefert.

Was funktioniert davon wirklich gut?

Spracherkennung ist der Bereich, in dem lokale Modelle am weitesten sind. Die größeren Whisper-Varianten liefern auf dem Gerät Ergebnisse, die für Diktat, Sprachnotizen und Gesprächsmitschriften taugen. Wer eine ruhige Umgebung und ein halbwegs aktuelles iPhone hat, merkt im Alltag kaum einen Unterschied zur Cloud-Variante.

Sprachausgabe funktioniert ebenfalls, klingt aber hörbar nüchterner als die guten Cloud-Stimmen. Für Vorlesen und Korrekturhören reicht es. Für ein Produktvideo würde ich es nicht nehmen.

Bei der Textverarbeitung wird es interessant. Ein Modell mit ein bis zwei Milliarden Parametern kann zusammenfassen, umformulieren und Rechtschreibung korrigieren. Es kann nicht das, was du von GPT-Klasse gewohnt bist. Es verliert bei langen Texten den Faden, es erfindet gelegentlich, und es ignoriert Anweisungen, die eine Zwischenüberlegung erfordern. Warum genau das passiert und wie man es umgeht, habe ich im zweiten Teil auseinandergenommen, weil es über diese eine App hinaus nützlich ist.

Wo On-Device an harte Grenzen stößt

Drei Grenzen sind so hart, dass man sie in der Planung kennen muss.

Arbeitsspeicher. Ein Modell, das mehr RAM braucht als vorhanden ist, führt nicht zu einer Fehlermeldung. iOS schießt die App mitten in der Berechnung ab. Für den Nutzer sieht das aus wie ein Absturz, und genau so bewertet er es auch. Deshalb prüft die App vor dem Download, ob das Gerät ein Modell überhaupt ausführen kann, und graut es sonst samt Begründung aus. Vorher, nicht nachher.

Audio-Länge bei multimodalen Modellen. Die neuen Modelle, die Audio direkt verstehen, klingen nach der eleganten Lösung: ein Modell für alles. In der Praxis gilt ein Limit von 30 Sekunden Audio pro Eingabe. Für eine Diktier-App, in der Aufnahmen minutenlang laufen, hieße das: mitten im Satz zerschneiden. Außerdem können diese Modelle Audio zwar lesen, aber nicht erzeugen. Für Sprachausgabe fallen sie komplett aus.

Speicherplatz und Geduld. Zwischen der Entscheidung „ich will das lokal" und dem ersten funktionierenden Satz liegen mehrere hundert Megabyte Download. Das ist eine echte Hürde, und man sollte sie dem Nutzer nicht als Kleinigkeit verkaufen.

Warum Lizenzen hier wichtiger sind als Benchmarks

Das ist der Punkt, den ich in Gesprächen am häufigsten erklären muss, und er entscheidet über echtes Geld.

Für deutsche Sprachausgabe auf dem Gerät gibt es mehrere gängige Wege. Der bekannteste hängt an einer Komponente namens espeak-ng, die unter GPL-3.0 steht, und an Stimmen-Lizenzen, die uneinheitlich und teilweise ungeklärt sind. Für eine kommerzielle App, deren Quellcode geschlossen bleiben soll, ist beides ein reales Risiko. Nicht „theoretisch problematisch", sondern die Art von Risiko, die dir später ein Anwalt erklärt.

Ich habe deshalb einen anderen Weg genommen, bei dem die Kette sauber ist: Bibliothek unter MIT, Modelle unter Apache-2.0, und die Komponente, die Text in Lautschrift übersetzt, ist ein neuronales Modell statt der GPL-Komponente. Nachgesehen im Paket selbst, nicht in der Dokumentation geglaubt. Dokumentation ist ein Versprechen, das Paket ist die Wahrheit.

Der Preis dafür war konkret: Diese Bibliothek erzwingt iOS 17.0 als Mindestversion. Das Deployment Target musste hoch, was ältere Geräte ausschließt. Nicht verhandelbar, weil es als vorkompiliertes Paket kommt.

Für dich als Unternehmen ist die Lehre übertragbar. Wenn dir jemand eine KI-Lösung mit lokalen Modellen anbietet, ist die interessante Frage nicht, wie gut das Modell in irgendeinem Benchmark abschneidet. Die interessante Frage ist, unter welcher Lizenz Modell und Bibliothek stehen und ob das mit deinem Geschäftsmodell zusammenpasst.

Was Apple im Review verlangt hat

Die erste Einreichung im App Store wurde abgelehnt. Das war ärgerlich und lehrreich zugleich, weil der interessanteste Ablehnungsgrund direkt am Thema hängt.

Es ging um die Regel, dass personenbezogene Daten erst nach ausdrücklicher Zustimmung an einen KI-Dienst eines Dritten gehen dürfen. Apple sagt dazu ausdrücklich, dass ein Hinweis in der Datenschutzerklärung nicht genügt. Die Offenlegung muss in der App passieren: was gesendet wird, an wen, und davor eine bewusste Zustimmung.

Meine erste Umsetzung war eine Abfrage vor der gesamten App. Korrekt, solange jeder Anbieter ein Cloud-Dienst ist. Falsch in dem Moment, in dem lokale Modelle dazukamen, die überhaupt nichts senden. Niemand sollte einer Datenübermittlung zustimmen müssen, um ein Modell zu nutzen, das offline auf seinem eigenen Telefon rechnet.

Die zweite Umsetzung fragt an den sieben Stellen, an denen tatsächlich etwas das Gerät verlässt. Ob ein Anbieter sendet, leitet die App aus einer einzigen Tatsache ab: Er braucht einen API-Schlüssel. In dieser App braucht ein Anbieter genau deshalb einen Schlüssel, weil er auf fremden Servern läuft. Lokale Anbieter sind damit konstruktionsbedingt ausgenommen. Es gibt keine Liste, die jemand vergessen könnte zu aktualisieren.

Das ist für mich der eigentliche Kern von Datenschutz in Software: nicht eine Regel, an die man sich erinnern muss, sondern eine Konstruktion, in der der Fehler gar nicht erst möglich ist.

Wie funktioniert das technisch?

Jetzt wird es etwas technischer. Wer nur die Einordnung wollte, kann direkt zum Fazit springen.

Die App ist in React Native gebaut, rund 23.700 Zeilen TypeScript auf 183 Dateien, mit 331 Tests. Jeder Anbieter, ob lokal oder Cloud, ist ein eigenständiges Modul hinter einem gemeinsamen Vertrag. Insgesamt sind es 17 davon. Die App ruft nur transcribe, synthesize oder complete auf und weiß nicht, ob dahinter ein Modell auf dem Chip oder eine API im Netz steckt. Genau diese Trennung macht es überhaupt erst möglich, lokale und Cloud-Anbieter gleichberechtigt nebeneinander zu betreiben.

Interessanter als die Tests, die Verhalten prüfen, sind fünf Tests, die Architektureigenschaften prüfen. Der Hintergrund: Ein Fehlermuster trat in dieser Codebasis fünfmal auf. Eine Zugriffsprüfung fragte „ist ein API-Schlüssel da?", ohne zu fragen „braucht dieser Anbieter überhaupt einen?". Für lokale Anbieter hieß das: blockiert. Zwei der fünf Fundstellen scheiterten stumm, ohne Fehlermeldung, im Hintergrund.

Solche Fehler fängt keine Typprüfung. Deshalb gibt es Tests, die den Quellcode nach Mustern durchsuchen und rot werden, sobald jemand die Regel verletzt:

Regel	Was sie verhindert
Keine Schlüssel-Prüfung ohne Abfrage, ob der Anbieter einen braucht	lokale Anbieter werden blockiert
Keine Sendestelle ohne Zustimmungs-Abfrage	stiller Upload
Kein Fehlercode ohne Übersetzung	technischer Code landet auf dem Bildschirm
Kein Anbieter-Import außerhalb seines Ordners	die zentrale Registry wird umgangen
Jeder Textbaustein in allen drei Sprachen vorhanden	roher Schlüssel statt Text

Jeder dieser Tests wurde gegengeprüft, indem der Fehler absichtlich wieder eingebaut wurde. Ein Schutz, von dem niemand weiß, ob er überhaupt auslösen kann, ist Dekoration.

Der Übersetzungstest fand beim ersten Lauf 11 fehlende Textbausteine in Deutsch und Englisch und 24 in Spanisch. Die verwendete Bibliothek zeigt einen fehlenden Baustein still als seinen technischen Schlüssel an. Kein Absturz, keine Warnung. Der Nutzer liest einfach settings.chooseSTTProvider auf dem Bildschirm und hält die App für kaputt.

Was ich bewusst offen lasse

Ehrlichkeit ist hier wichtiger als jede Erfolgsmeldung, sonst triffst du auf falscher Grundlage eine Entscheidung.

Zur deutschen Sprachqualität der lokalen Sprachmodelle gibt es keine veröffentlichten Messdaten. Für keines dieser Modelle. Ich sage das so, statt eine Zahl zu schätzen, die dann zitiert wird. Die Mindestwerte für Arbeitsspeicher im Katalog sind konservativ geschätzt, nicht auf echter Hardware durchgemessen. Live-Erkennung während des Sprechens ist für die lokalen Modelle noch nicht angebunden. Und die Testabdeckung der Kernlogik liegt bei 37,8 Prozent, mit den kritischen Pfaden abgedeckt und den dünnen Stellen bei den API-Wrappern.

Fazit

Lokale KI ist keine Zukunftsmusik mehr, aber auch kein Selbstläufer. Spracherkennung funktioniert heute richtig gut auf dem Gerät. Sprachausgabe funktioniert brauchbar. Textverarbeitung funktioniert für einfache Aufgaben und bricht bei allem, was mehrere Denkschritte braucht.

Die eigentlichen Hürden liegen nicht beim Modell. Sie liegen bei Arbeitsspeicher, Lizenzketten und der Frage, wie du Zustimmung so baust, dass sie nur dort greift, wo wirklich etwas gesendet wird.

Für Unternehmen heißt das: Wenn Daten aus rechtlichen Gründen im Haus bleiben müssen, ist lokale Verarbeitung eine ernsthafte Option, gerade bei Sprache und Dokumenten. Wenn dagegen Antwortqualität bei komplexen Aufgaben zählt, führt an guten Modellen kein Weg vorbei. Dann geht es darum, sie sauber und DSGVO-konform einzubinden, mit Servern in Deutschland und europäischen Anbietern dort, wo personenbezogene Daten fließen.

Die richtige Antwort ist fast immer eine Mischung. Und die Entscheidung, was wo läuft, trifft man pro Aufgabe, nicht einmal pauschal für die ganze Firma.