Sprachsteuerung offline mit ONNX/TFLite-Modellen
Ein Satz kleiner Modelle mit festen Schlüsselwörtern – Standard-ONNX für Smartphones, Browser und Desktops, INT8-TFLite für Mikrocontroller – lauscht auf ein Wake Word und eine Handvoll Sprachbefehle, komplett offline. Dieser Artikel zeigt, wann diese Art von Modell das richtige Werkzeug ist, wie dieselben Dateien auf jeder Plattform laufen, und führt anhand eines funktionierenden ESP32-S3-Beispiels durch den ganzen Weg.
Wann braucht man so ein Modell?
Ein Keyword-Spotting-Modell (KWS) ist das richtige Werkzeug, wenn der Wortschatz fest und klein ist – ein Wake Word plus höchstens einige Dutzend Befehle – und das Produkt immer lauschen muss, ohne Audio irgendwohin zu senden. Wenn Nutzer alles sagen können, braucht es ein volles ASR-Modell; aber ASR verlangt eine Größenordnung mehr Rechenleistung und Energie – auf einem ESP32-Mikrocontroller oder einem Akkugerät meist unerreichbar, und Dauerlauschen ist damit schlicht unpraktikabel.
| Feste Schlüsselwörter (ONNX/TFLite) | On-Device ASR | Cloud-Sprachassistent | |
|---|---|---|---|
| Wortschatz | Fest: 1 Wake Word + 2–10 Befehle | Offen | Offen |
| Größe | ~100-KB-Klasse | Hunderte MB | Lokal nichts, Audio verlässt das Gerät |
| Hardware | MCU (ESP32-S3) bis Browser | Linux-SBC / Smartphone | Alles mit Mikrofon + Netzwerk |
| Netzwerk | Nicht nötig | Nicht nötig | Erforderlich |
| Rechenleistung & Energie | Millisekundenklasse auf einem MCU – niedrig genug für Dauerlauschen, auch für Akkugeräte | Eine Größenordnung mehr CPU/RAM/Energie – Dauerlauschen unpraktikabel | Lokal leicht, aber das Funkmodul schläft nie |
| Antwort | Sofort, auf dem Gerät | Schwerer, geräteabhängig | Netzwerk-Latenz |
| Laufende Kosten | Keine – die Modelldatei gehört Ihnen | Rechenleistung/Energie | Nutzungsabhängig oder Abo |
| Datenschutz | Audio verlässt das Gerät nie | Bleibt lokal | Audio wird hochgeladen |
Konkrete Situationen, in denen Teams zu einem Modell mit festen Schlüsselwörtern greifen:
- Smart Home: „Licht an“, „Heizung an“ – ein Wake Word plus eine Handvoll Gerätebefehle
- Gemeinschaftsgeräte & Zeiterfassung: „Stempeluhr“, „Schichtbeginn“ – Stempeln per Sprache, wo Tippen unpraktisch ist
- Roboter & Kameras: „Foto“, „Start“, „Stopp“ – Steuerung, wenn die Hände beschäftigt sind
- Präsentationen & Kioske: „Nächste Seite“, „Zurück“ – ohne Fernbedienung, ohne den Bildschirm zu berühren
- Spielzeug & Gadgets: ein eigenes Wake Word, das zum Produktnamen wird
- PTT-Funkgeräte: Sprechtaste per Stimme, ohne nach dem Knopf zu greifen
Alle haben feste Wortschätze und nehmen den KWS-Kompromiss gern mit: auf offene Konversation verzichten und dafür winzig, sofort, privat und kostenlos im Betrieb sein. Ein KWS-Modell für so einen festen Wortschatz nötig? Auf voicute.com trainierbar – auf Deutsch, Englisch, Französisch, Japanisch oder Chinesisch; die folgenden Schritte führen den ganzen Weg.
Ein Modellformat, alle Plattformen
Die Open-Source-Open-Source-Inferenz-Engine und Demo-Modelle ansehen →-Pipeline liefert aus demselben Training zwei Formate: ONNX für alles mit ONNX Runtime, INT8-TFLite für TFLite-Micro-Geräte wie den ESP32-S3. Die Inferenz-Pipeline besteht aus drei Dateien:
Audio (16 kHz) → melspectrogram.onnx → embedding_model.onnx → your_word.onnx → Wahrscheinlichkeit
melspectrogram.onnxundembedding_model.onnxsind über alle Wake Words geteilt – im Repo enthalten.your_word.onnxist der Klassifikator pro Wort. Wake Word wechseln = eine kleine Datei tauschen (plus ein Eintrag inmodel_info.json).- Multi-Class-Modelle packen 2–10 Schlüsselwörter in eine Klassifikator-Datei mit N+1-Softmax-Ausgängen.
Open-Source-Runtimes im selben Repository laden diese Dateien auf Android (android/), Web (web/, ONNX im Browser), Python unter Windows/Linux/macOS (linux/) und ESP32-S3/P4 (esp32/, TFLite). Ein Wyoming-Sidecar verbindet dieselben Modelle mit Home Assistant. Kein AccessKey, keine Cloud-Inferenz, keine Geräte-Laufzeitgebühren – die heruntergeladene Modelldatei gehört Ihnen.
Praxisbeispiel: Wake Word + Sprachbefehle auf dem ESP32-S3
Um die ganze Kette einmal Ende-zu-Ende zu zeigen, läuft derselbe Modellstapel auf dem kleinsten Ende dieser Plattformliste. Das Demo kombiniert genau die beiden Modelltypen dieser Pipeline: ein Single-Keyword-Wake-Modell für „Hallo Lumo“ und ein Multi-Keyword-Modell für die vier Folgebefehle. Das Board ist ein ESP32-S3 HMI DevKit (Dual-Core 240 MHz, 8 MB PSRAM, ES7210-Mikrofon-Codec) mit ESP-IDF 6.0.1. Sagen Sie „Hallo Lumo“ – ein eigenes deutsches Wake Word – und die LED bestätigt den Wake. Innerhalb des 6-Sekunden-Fensters heißt „Licht rot / blau / grün / weiß“ das Licht die Farbe wechseln, danach kehrt das Gerät in den Wachmodus zurück.
Invoke() ≈ 76 ms ≈ 121 ms pro Frame gegen einen 160-ms-Hop – Echtzeit. 20+ Wakes in stillen und lauten Räumen, alle vier Befehle erkannt, keine Verwechslung. Die Fehlauslösungen des Wake-Modells sanken durch Hard-Negative-Mining von ~319/h auf ~2,6/h, gemessen auf 24 h zurückgehaltener Audioaufnahmen. Die Latenz variiert je nach Modell – immer mit dem eigenen messen.Warum selbst trainieren? Espressifs eingebautes MultiNet unterstützt Befehle nur auf Chinesisch und Englisch. Beide Modelle hier trainiert die eigene Pipeline auf Mel-Features – derselbe Ablauf funktioniert in jeder Sprache, Deutsch ist nur das, was dieses Demo spricht.
- Demo-Modelle (deutsches Wake Word + Befehle): onnx-wakeword/models/de
- ESP32-Firmware und Beispiele: onnx-wakeword/esp32
Eigene Schlüsselwortmodelle gewünscht – ein einzelnes Wake Word oder ein Multi-Keyword-Befehlssatz, in fünf Sprachen? Genau das trainiert voicute.com; der Rest dieses Artikels führt Schritt für Schritt hindurch.
Wie es funktioniert: zwei kleine Modelle, zeitgetrennt
Ein Gerät führt zwei kompakte INT8-TFLite-Modelle auf demselben Kern aus, so geplant, dass sie sich nie in die Quere kommen:
- Wake-Modell, immer aktiv. Die ESP-SR-AFE übernimmt das Audio-Frontend (AEC, NS, VAD); das Wake-Modell konsumiert das neueste Mel-Fenster. Bei einem Treffer wechselt das Gerät den Modus.
- Befehlsmodell, nur nach einem Wake. In den nächsten 6 Sekunden ordnet ein zweiter Multi-Keyword-Klassifikator die Sprache einem der konfigurierten Befehle zu (hier: vier Farben). Nach dem Fenster – oder nach einem Befehl – fällt das Gerät zurück in den Nur-Wake-Modus.
Diese Sperre hält falsche Befehle niedrig: Das Befehlsmodell lauscht nie allein. Die Fehlauslösungslast trägt das Wake Word – und genau das kann die Pipeline optimieren (Schritt 4).
Schritt 1 · Das Demo-Modell selbst ausführen (kostenlos)
Beide Demo-Modelle liegen auf GitHub, ohne Registrierung. Der schnellste Check braucht keine Hardware – die Python-Runtime lädt dieselben Modelldateien auf dem Desktop:
git clone https://github.com/voicute/onnx-wakeword.git
cd onnx-wakeword
pip install onnxruntime numpy sounddevice
python linux/infer.py --model-dir ./models/de/
Der vollständige Embedded-Pfad ist das getestete ESP-IDF-Beispiel:
cd onnx-wakeword/esp32/examples/esp32s3_hmi_devkit
idf.py set-target esp32s3
python patch_led_strip.py
idf.py build
idf.py -p COM6 flash monitor
Die Web-Runtime führt dieselben Demo-Modelle komplett im Browser aus – praktisch, um den Klang eines Schlüsselworts vor jeder Hardware zu prüfen.
Schritt 2 · Eigenes Wake Word trainieren (kostenlos)
Auf voicute.com die Phrase eingeben und eine Sprache wählen – Deutsch, Englisch, Französisch, Japanisch oder Chinesisch. Das Training erzeugt ein Modell der ersten Runde (R0): einen Standard-ONNX-Klassifikator für Desktop/Mobile/Browser plus passendes INT8-TFLite für den ESP32-S3. Dieser Schritt kostet nichts.
Schritt 3 · Mit der eigenen Stimme testen (kostenlos)
In der Konsole das Basic-Modell gegen das eigene Mikrofon, die tatsächliche Entfernung und den realen Hintergrundgeräuschen testen. Dieser Schritt entscheidet alles Weitere – also vorher testen, nicht nach dem Bezahlen: die Phrase so sagen, wie man sie wirklich sagt, aus der Entfernung, in der man sie wirklich nutzt. Fällt der Recall schwach aus, ein paar Echt-Audio-Aufnahmen der Phrase ergänzen und neu trainieren – Aufnahmen sind eine optionale Trainingseingabe, weiterhin kostenlos.
Schritt 4 · Was brauchen Sie?
Nach dem Test sind Sie in einer von vier Situationen:
- Die Phrase wird manchmal verpasst → 5 Echt-Audio-Aufnahmen ergänzen und neu trainieren (kostenlos). Die meisten Recall-Probleme sind Abdeckungsprobleme und lösen sich hier.
- Es weckt zuverlässig, löst aber bei Fernsehen oder Geplapper aus → die Fehlauslösungs-Optimierung durchführen (kostenpflichtig pro Runde) – wie sie funktioniert, steht im nächsten Abschnitt.
- Sprachsteuerung statt nur Wake Word → ein Multi-Keyword-Modell mit 2–10 festen Befehlen in einer Datei trainieren – oder ganz auf das Wake Word verzichten und ein Befehlswort als Auslöser nehmen. Das Demo oben ist exakt diese Architektur.
- Es funktioniert einfach → Modell herunterladen (kostenpflichtig, einmalig) und auf einer der obigen Runtimes einsetzen.
Fehlauslösungen im Griff: R0 vs. R1 und Hard-Negative-Mining
Jedes Modell beginnt als R0 – die erste Runde, trainiert auf vorbereiteten Sprachdaten plus einem festen Satz an Störungen (Rauschen, Hall, Lautstärke). Die echte Welt hat weit mehr: Fernsehen, Musik, Hintergrundgeplapper, Werbung. Und die Störungen sind wortspezifisch: Derselbe Werbeclip kann „Hallo Lumo“ auslösen und das Modell eines anderen Wortes völlig unberührt lassen. Ein frisches R0 mit hohen Fehlauslösungen ist also bei jedem Schlüsselwortmodell normal – kein Zeichen schlechten Trainings.
R1 behebt das, in zwei Schritten, die den beiden Konsole-Buttons entsprechen:
- Negativ-Scan. Das R0-Modell hört ~100 Stunden negativer Audioaufnahmen der jeweiligen Sprache und markiert die Clips, auf die es reagiert – per Definition die Hard Negatives dieses Modells (bis zu 10.000 behalten). Wenige Minuten.
- Vollretraining. Diese Clips kommen als Negativbeispiele in den ursprünglichen Trainingssatz, und das Modell wird komplett neu trainiert. Typischerweise 40–80 Minuten.
Weil die Negativbeispiele gegen R0s echte Schwächen ausgewählt werden, senkt eine Runde die Fehlauslösungen im Schnitt von Hunderten pro Stunde auf einstellig (rund 95 %). Beim Wake Word dieses Demos: gemessen 319/h → 2,6/h über 24 Stunden zurückgehaltener Audioaufnahmen. Sowohl Single-Keyword- als auch Multi-Keyword-Modelle unterstützen diesen Ablauf – das Vier-Farben-Befehlsmodell im Demo kann dieselbe Scan-und-Retrain-Schleife durchlaufen. Eine R2-Pipeline steht für völlig neue Störquellen bereit, doch für die meisten Schlüsselwörter reicht eine R1-Runde für den Alltag. Die Optimierung kostet pro Runde; aktuelle Preise auf voicute.com.
Schritt 5 · Auf der eigenen Hardware validieren
Das Konsolentesting beweist das Modell; das Gerät beweist das Produkt. Drei Prüfungen vor dem Ausliefern:
- Echtzeit-Budget. Mel +
Invoke()messen und unter dem Audio-Hop halten (in diesem Demo 160 ms). Passt es nicht: Modell verkleinern oder nur das neueste Fenster verarbeiten. - Fehlauslösungen pro Stunde. Eine Stunde der realen Umgebung aufnehmen – Fernsehen, Gespräche, Musik –, diese Aufnahmen niemals ins Training geben, durch die Firmware laufen lassen und Auslösungen zählen. Diese eine Zahl ist mehr wert als jeder kurze Demo-Clip.
- Verpasste Wakes bei derselben Schwelle. Fehlauslösungs- und Recall-Zahlen bedeuten nur zusammen etwas; beide dokumentieren.
FAQ
- Wann ist ein Modell mit festen Schlüsselwörtern die falsche Wahl?
- Wenn der Wortschatz nicht festgelegt ist. Diktat, freie Fragen, alles Offene braucht volles ASR – ein KWS-Modell erkennt konstruktionsbedingt nur die trainierten Wörter.
- Funktioniert das komplett offline?
- Ja. Wake Word und Befehle laufen beide lokal. Keine Cloud-Inferenz, kein Laufzeit-Accountschlüssel.
- Welche Plattformen und Sprachen?
- Android, Web, Python (Windows/Linux/macOS), ESP32-S3/P4, plus Wyoming für Home Assistant; Modelle für Deutsch, Englisch, Französisch, Japanisch und Chinesisch.
- Was ist kostenlos, was kostet etwas?
- Training und Konsolentest sind kostenlos. Modelldateien herunterladen und die Fehlauslösungs-Optimierung sind kostenpflichtig – aktuelle Preise auf voicute.com.
- Kann fremde Sprache einen Befehl auslösen?
- Nur innerhalb des 6-Sekunden-Fensters nach dem Wake, und die Wake-Sperre blockiert das meiste. Sprache im Fenster kann derzeit noch falsch klassifiziert werden; das Hard-Negative-Mining für Schlüsselwörter ist in der Pipeline dafür vorgesehen.