Das eigene Siri lokal und On-Device ganz ohne Cloud aufbauen

• So baust du dir einen persönlichen Sprachassistenten, der On-Device läuft, selbst – ohne Abhängigkeit von LLM-APIs und der Cloud
• Dieser Assistent versteht natürliche Sprache, führt persönliche Funktionsaufrufe aus und arbeitet ausschließlich lokal, wodurch vollständiger Schutz der Privatsphäre möglich wird
• Dafür wird das Modell LLaMA 3.1 per LoRA feinabgestimmt, mit Whisper Sprache in Text umgewandelt und anschließend als Befehl interpretiert, der direkt auf dem Gerät ausgeführt wird
• Das Projekt besteht aus Datensatzerstellung → Fine-Tuning → Anbindung der Sprachschnittstelle → Tests und Deployment und wird als fünfteiliger kostenloser Minikurs angeboten
• Es wird vor dem Irrtum gewarnt, „On-Device-Ausführung = einfach“ zu setzen, und betont, dass auch lokal MLOps-Denken und strenge Qualitätskontrolle unverzichtbar sind

---

Warum sollte man gerade jetzt einen lokalen Sprachassistenten bauen?

• Gespräche mit ChatGPT sind nützlich – aber muss man selbst einfache Befehle in die Cloud schicken?
• Wenn das Modell direkt auf dem eigenen Gerät installiert ist, sind Geschwindigkeit, Privatsphäre und Kontrolle zugleich gesichert
• Besonders nützlich ist das in sensiblen Umgebungen wie Medizin, Recht und internen Tools

Überblick über die Gesamtarchitektur

Projektkomponenten

1. Spracherkennung (Whisper) → Umwandlung in Text
2. LLM (LLaMA 3.1) → Interpretation des Befehls
3. Funktionsausführer → Ausführung realer Funktionen wie lock_screen()

Teil 1: Architektur und MLOps-Denkweise

Warum MLOps auch lokal nötig ist

• Es gibt Probleme wie Model Drift, Prompt-Änderungen, Datensatzzuverlässigkeit und mangelndes Debugging-Logging
• Die Vorstellung „lokal allein reicht aus“ ist riskant; ein systematischer Ansatz ist nötig

Online-Entwicklung vs. Offline-Ausführung

• Entwicklung (Fine-Tuning, Datengenerierung) erfolgt in der Cloud, die Ausführung läuft lokal
• Diese Prozesse klar zu trennen und strukturiert zu verwalten, ist der Kern von MLOps

Datensatzerstellung (Dataset Generation Flow)

• Nicht nur einfache Prompt-Sammlung, sondern Entwurf strukturierter Funktionsaufrufmuster und konversationeller Anfrageformen
• Erstellung hochwertiger Datensätze, die verschiedene Formulierungen, Absichten und Fehlerfälle abdecken

Kernpunkte

• lock_screen() → umfasst verschiedene natürlichsprachliche Formulierungen wie „Sperr den Bildschirm“
• Eine automatische Validierungs-Engine prüft, ob die Ausgabe der beabsichtigten Form entspricht

Fine-Tuning (Instruction Tuning für Function Calling)

• Feinabstimmung eines kleinen Modells (per SFT) für präzises Befehls-Mapping
• Einsatz praxisnaher Tools wie Unsloth, W&B und GGUF-Export

Ziel

• LLaMA 3.1 8B in ein lokal lauffähiges 4bit-Modell umwandeln
• Leichtgewichtige Optimierung mit Raspberry Pi als möglichem Ziel

Modellanbindung und reale Ausführung

• Whisper wandelt Spracheingaben in Text um
• Das feinabgestimmte LLM interpretiert den Befehl
• Anbindung an einen lokalen API-Funktionsausführer (lock_screen(), get_battery_status() usw.)

Ergebnis

• Sprachassistent in Echtzeit ist möglich
• Kein Netzwerk nötig, kein Abfluss personenbezogener Daten, vollständige Kontrolle durch den Nutzer

Risikomanagement in der Offline-Phase

• Tests auf verschiedenen Geräten und Betriebssystemen sind nötig
• Aufbau eines Logging-Systems ist Pflicht (als Opt-in mit manueller Übermittlung)
• Noch vor dem offiziellen Release Probleme früh erkennen – durch Stresstests und Nutzerfeedback

Ausblick

• In der nächsten Lektion geht es um praktische Datensatzerstellung für Function Calling
• Ein spezialisierter Datensatz, der die Zuordnung von natürlichsprachigen Befehlen zu API-Aufrufen lernt, wird strukturiert aufgebaut
• Kein Scraping, nur promptbasierte Simulationen und automatisch validierte Daten

Fazit

• Lokale KI-Systeme mögen simpel wirken, doch Stabilität und Qualität erfordern ein noch höheres Maß an Steuerung
• Da man sich nicht auf Cloud-Logs oder Hotfixes stützen kann, sind höhere Zuverlässigkeit und mehr Verantwortungsbewusstsein nötig
• Deshalb sollte MLOps-Denken und strukturiertes Design von Anfang an angewendet werden

> „Die Zeit für einen echten KI-Assistenten mit Fokus auf Privatsphäre und Local-First ist gekommen“
> Im nächsten Teil beginnt die praktische Erstellung eines Datensatzes für echtes Command-to-Function-Mapping.

[asheswook]

3.1 ist für nicht englischsprachige Nutzer schwer zu verwenden, und mit 3.3 oder 4 wäre wohl auch Koreanisch möglich, aber wenn man es On-Device laufen lassen will, dürfte es für Nicht-Englisch zumindest erst ab 32b sinnvoll sein, wenn man das berücksichtigt, scheint es derzeit noch schwierig zu sein ...

[GN⁺]

Hacker-News-Kommentare

• Die Idee gefällt mir so gut, dass ich es selbst bauen möchte, aber meine Erfahrungen mit den kleinen Whisper-Modellen lokal waren eher enttäuschend. Ich frage mich, ob jemand für einen solchen Anwendungsfall Ergebnisse erzielt hat, die gut genug sind. Vielleicht war auch einfach mein Mikrofon nicht gut.
  • Du solltest den Zustand deines Mikrofons auf jeden Fall noch einmal prüfen. In unserer Firma nutzen wir Whisper, um komplette Meetings in Echtzeit zu transkribieren und zu übersetzen, und es liefert eine wirklich hervorragende Leistung.
  • Mich würde interessieren, welches Modell ihr verwendet. Ich nutze normalerweise das Large-Modell auf der GPU. Es ist schnell und funktioniert wirklich gut. Man sollte aber beachten, dass es immer nur eine Sprache gleichzeitig erkennen kann. Wenn man nichts angibt, läuft es mit automatischer Erkennung. Die kleineren Modelle sind entsprechend leistungsschwächer und unterstützen oft im Wesentlichen nur Englisch. Für mich liefert Large die beste Leistung, aber um auf tatsächlich brauchbare Geschwindigkeit zu kommen, braucht man unbedingt GPU-Hardware. Das gilt auch zusammen mit faster-whisper oder insanely-fast-whisper.
• Es wäre wirklich toll, wenn es das einfach als installierbares Produkt oder als App gäbe. Ich würde es gern bequem über eine UI einrichten und trainieren. Trotzdem bin ich für diesen Guide sehr dankbar, weil ich damit wohl genau das bauen kann, was ich möchte.
• Wirklich großartiges Material, ich wollte einfach Danke sagen. Ich habe noch nicht alles nachvollzogen, frage mich aber, ob dieses Modell auf dem iPhone in der Praxis gut läuft. Unser 9-jähriges Kind hat mit ollama das Qwen-0.6B-Modell gut zum Laufen gebracht, aber die anderen Modelle waren zu langsam und boten keine wirklich brauchbare User Experience.
  • Ach so, es ging um ein 9 Jahre altes Telefon. Ich dachte schon, ein Grundschulkind deployt hier direkt Modelle, und war ziemlich baff. In dem Alter habe ich noch das Einmaleins gelernt.
  • Laut den MLC-Unterlagen lassen sich auf iOS auch Modelle bis zur Größenordnung 8B ausführen. Realistischer wirken aber eher 1–3B. Hier ist das Referenzmaterial: https://llm.mlc.ai/docs/deploy/ios.html#bring-your-own-model
• Warum muss das ein von einem LLM geschriebener Text sein? Das frage ich mich.
  • Dieser zusammenfassende Stil, also dieses starke Formatting und (!) dass jeder Absatz als Bullet-List kommt, ist extrem verwirrend. Gerade bei langen Texten wirkt der Bildschirm dadurch unruhig und flach, was die Lesbarkeit verschlechtert.
• Vor Kurzem ist mir aufgefallen — vielleicht habe ich die Ankündigung verpasst —, dass Siri zumindest für einige Befehle lokal arbeitet. Man kann zum Beispiel die Apple Watch in den Flugmodus versetzen und dann nach einem Timer oder einer Erinnerung fragen.
  • Siri hatte zumindest seit iOS 15 eingeschränkte Offline-Funktionen, aber die meisten Nutzer haben das kaum bemerkt, weil der Großteil der Siri-Befehle eine Netzwerkverbindung benötigt.
• Ich frage mich, warum Apple die Daten nicht analysiert und für die vielleicht 1000 häufigsten Anwendungsfälle hartkodierte Handler bereitgestellt hat.
  • Eigentlich tun sie genau das schon, nur viel zu langsam. Sie fügen Helligkeits- und Energie-Funktionen hinzu, erklären aber nicht vernünftig, was offline nutzbar ist. Man muss erst in den Flugmodus wechseln und selbst alles ausprobieren, um das herauszufinden. Die User Experience ist wirklich schlecht.
• Tolles Projekt und gute Zusammenfassung.
• Ich frage mich, ob Apple es erlaubt, Siri durch einen anderen Assistenten zu ersetzen. Auf Android waren Assistenten außer Google lange beim Hintergrund-Listening sowie bei Hardkeys, Gesten und Shortcuts eingeschränkt. Ich weiß nicht, ob Google Assistant diese Sonderbehandlung immer noch genießt, aber selbst wenn, würde mich das nicht besonders überraschen.
  • Ein Teil des Problems liegt am separaten Coprozessor (AOP), der das Wakeword „hey siri“ verarbeitet. Das Modell ist außerdem in die Firmware einkompiliert. Technisch ist es nicht unmöglich, aber es reicht nicht, die Google-App einfach im Hintergrund laufen zu lassen, weil Gesten ausgelöst werden, während der AP schläft. Über den seitlichen Action Button und Ähnliches könnte man zwar eine Assistenten-App starten, aber das wäre keine zufriedenstellende Erfahrung (zum Beispiel weil die App möglicherweise nicht geöffnet ist). Mehr Details hier: https://machinelearning.apple.com/research/hey-siri
  • Mit dem neu hinzugefügten Action Button ist es ziemlich einfach, über einen benutzerdefinierten Shortcut eine alternative Assistenten-App zu starten.
  • So funktioniert auch Perplexity.
• Ich nutze seit anderthalb Jahren auf dem iPhone konsequent chatGPT und mag Siri wegen ihrer Schwerfälligkeit immer weniger. Ich frage mich, wann OpenAI mit Hilfe von Microsoft ein GPT-Phone herausbringen wird, das mit dem iPhone konkurriert. Ich habe das langweilige iPhone satt. Ich brauche ein GPT-Phone, bei dem direkt vom Sperrbildschirm aus GPT alles übernimmt. Ich kann es kaum erwarten, dass so etwas erscheint, und hoffe, dass es bereits heimlich entwickelt wird.