KI-Tools in der Praxis: Voice PE Realtime — Sprachsteuerung, die endlich funktioniert

Alle reden von smarter Sprachsteuerung. Alle versprechen, dass man bald natürlich mit seinem Zuhause spricht. Und alle, die es tatsächlich versucht haben, wissen: Zwischen Versprechen und Wohnzimmer liegt eine ziemlich große Lücke. Der Home Assistant Voice PE — das 60-Euro-Sprachgerät von Nabu Casa — war von Anfang an als offene Hardware-Plattform gedacht, nicht als fertiges Alexa-Pendant. Die mitgelieferte Assist-Pipeline funktioniert grundsätzlich, aber das Nutzererlebnis ist holprig: Speech-to-Text, dann Text an ein LLM, dann Text-to-Speech zurück. Mehrere Sekunden Stille zwischen Frage und Antwort. Kein Gesprächsfluss. Kein Unterbrechen. Kein Kontext.

Das Open-Source-Projekt Voice PE Realtime — entwickelt von Tristan Brotherton und mittlerweile 458 Commits stark — geht einen anderen Weg. Es ersetzt die gesamte Pipeline durch eine direkte Speech-to-Speech-Verbindung zur OpenAI Realtime API. Das Ergebnis ist kein smarterer Sprachbefehl-Empfänger, sondern etwas, das sich wie ein Gespräch anfühlt. Das klingt nach der Lösung. Aber wer denkt, hier geht es nur um bessere Technik, übersieht die eigentliche Frage: Zu welchem Preis — und mit welchen Kompromissen?

Inhaltsverzeichnis

Was Voice PE Realtime eigentlich ist
Speech-to-Speech: Der entscheidende Unterschied
Die Architektur: Was läuft wo
Wake-Word-Training: Maschinelles Lernen im Wohnzimmer
Speaker-Identifikation: Wer spricht da?
Kosten: Was das im Betrieb wirklich bedeutet
Einschränkungen und offene Fragen
Vergleich: Lokal, OpenAI-basiert, Alexa und Google
FAQ
Fazit

Kurzantwort

Voice PE Realtime verbindet Home Assistant Voice PE mit OpenAI Realtime API für echte Sprachkonversation — inklusive Kosten, Setup und aller Einschränkungen. Kurz gesagt: ki tools praxis ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

Was Voice PE Realtime eigentlich ist

Voice PE Realtime ist kein fertiges Produkt und kein einzelnes Repository. Es sind zwei Komponenten, die zusammenarbeiten: eine ESPHome-Firmware für den Voice PE und ein Home-Assistant-Add-on, das die Verbindung zur OpenAI Realtime API herstellt.

Die Firmware verwandelt den Voice PE in einen schlanken Audio-Client. Sie streamt das Mikrofonsignal mit 16 kHz über einen lokalen WebSocket an das Backend-Add-on, das seinerseits eine OpenAI-Realtime-Session verwaltet. Wake-Word-Erkennung läuft on-device, alles andere — Spracherkennung, Verstehen, Antwortgenerierung, Smart-Home-Steuerung — passiert in der Cloud.

Die entscheidende Designentscheidung: Es gibt keine Assist-Pipeline mehr auf dem Audiopfad. Kein Wyoming-Protokoll, kein Whisper-STT, kein Piper-TTS. Das ist radikal anders als der Standard-Home-Assistant-Ansatz und auch als die meisten lokal gehosteten Alternativen.

Das Projekt basiert lose auf früheren Arbeiten von xandervanerven und maxmaxme, die ebenfalls den Voice PE mit der OpenAI Realtime API verbanden, sowie auf fjfrickes ha-openai-realtime. Brothertons Version ist in Funktionsumfang und Produktionshärtung deutlich darüber hinausgegangen: Enrollment-Modus, False-Wake-Harvesting, Voice-Print-Identifikation, Timer, Multi-Device-Architektur.

Realistisch betrachtet: Das ist Bastel-Enthusiasmus auf hohem Niveau, kein Consumer-Produkt. Wer das installieren will, braucht einen Home-Assistant-OS-Server, einen OpenAI-Account mit aktivierter Abrechnung, und die Bereitschaft, ESPHome-Firmware selbst zu flashen. Die Doku sagt 30-45 Minuten. Wer ESPHome noch nie angefasst hat, sollte einen Nachmittag einplanen.

Speech-to-Speech: Der entscheidende Unterschied

Die klassische Sprachpipeline — und das gilt für Alexa, Google Assistant und die Standard-HA-Assist-Pipeline gleichermaßen — arbeitet in drei getrennten Schritten: Sprache wird zu Text (STT), Text wird vom Sprachmodell verarbeitet (LLM), Antworttext wird zu Sprache (TTS). Jeder Schritt braucht Zeit. Die Wartezeit zwischen Frage und Antwort liegt typischerweise bei zwei bis fünf Sekunden, je nach Hardware und Modell. Das ist für Kommandos erträglich, für Konversation nicht.

Die OpenAI Realtime API — konkret das Modell gpt-realtime-2.1, das am 6. Juli 2026 veröffentlicht wurde — verarbeitet Audio direkt. Das Modell hört Sprache, versteht sie, denkt nach und generiert gesprochene Antworten, ohne dass irgendwo Text als Zwischenformat anfällt. Die Latenz liegt im Bereich von wenigen hundert Millisekunden. Das ist der Unterschied zwischen „Befehl ausführen" und „Gespräch führen".

Was das Modell zusätzlich kann: Werkzeuge aufrufen, während es spricht. Wenn man fragt „Wie war das Wetter heute und schalt bitte das Licht ein", kann der Agent parallel die Wetter-API und die HA-MCP-Schnittstelle ansteuern, anstatt sequenziell zu arbeiten. Er kann während der Tool-Ausführung Füllphrasen wie „Einen Moment, ich schaue nach" einstreuen, um die Konversation am Leben zu halten. Und er kann mitten im Satz unterbrochen werden — „Stop" beendet die Antwort sofort.

Das alles ist eine erhebliche Verbesserung gegenüber dem Stand von Anfang 2026. Aber es ist auch ein teurer Cloud-Dienst. Der Speech-to-Speech-Komfort erkauft sich mit einer vollständigen Abhängigkeit von OpenAI-Servern. Ohne Internetverbindung ist das Gerät stumm. Wer „Hey Alexa, Licht an" durch eine lokale Lösung ersetzen wollte, bekommt hier das Gegenteil.

ki tools praxis – Illustration 2

Die Architektur: Was läuft wo

Ein genauer Blick auf die Datenströme lohnt sich, weil hier viele Missverständnisse auftauchen. Das System hat drei Komponenten in zwei Sphären:

Auf dem Voice PE (lokal, ESP32-S3): Der va_client streamt das Mikrofonsignal roh über einen WebSocket an das Backend. Gleichzeitig läuft microWakeWord on-device — ein schlankes neuronales Netz, das auf das Aktivierungswort trainiert ist. Wird es erkannt, öffnet sich der Mikrofon-Stream. Der XMOS-DSP-Chip auf dem Voice PE filtert Hintergrundgeräusche, bevor das Signal überhaupt zur ESP32 gelangt.

Auf dem Home-Assistant-Server (lokal): Das Backend-Add-on nimmt den WebSocket-Stream auf Port 8080 entgegen und leitet ihn an die OpenAI Realtime API weiter. Das Add-on verwaltet die Session, puffert Antworten, steuert die Lautstärke (+6 dB Kompensation, weil OpenAIs Audio leiser gemastert ist als die Geräte-Sounds) und stellt die Verbindung zu Home Assistant über die offizielle MCP-Server-Integration her.

In der Cloud (OpenAI): gpt-realtime-2.1 verarbeitet das Audiostreaming, führt Tool-Calls über die MCP-Schnittstelle aus und streamt die Sprachantwort zurück. Web-Suche läuft über einen separaten API-Call.

Die Daten fließen also: Mikrofon → lokaler WebSocket → HA-Add-on → Internet → OpenAI → Internet → HA-Add-on → lokaler WebSocket → Lautsprecher. Audio-Samples zur Wake-Wort-Verbesserung werden ausschließlich lokal gespeichert — in /share/voice-enrollment und /share/voice-probes. Sprachaufnahmen aus Enrollment-Sessions verlassen laut Doku nie das lokale Netzwerk.

Wer mehrere Voice-PE-Geräte betreiben will, braucht pro Gerät eine eigene Add-on-Instanz mit eigenem Port. Das Backend ist explizit auf 1:1-Verbindungen ausgelegt. Bei drei Geräten laufen drei Add-on-Instanzen auf Ports 8080, 8082, 8084. Das skaliert, aber der Verwaltungsaufwand wächst linear.

Wake-Word-Training: Maschinelles Lernen im Wohnzimmer

Ein oft übersehener Aspekt: Voice PE Realtime trainiert das Wake-Word-Modell auf die eigenen Stimmen. Das ist kein Gimmick, sondern der wahrscheinlich am meisten unterschätzte Teil des Projekts.

Standard-Wake-Words wie „Okay Nabu" oder „Hey Jarvis" funktionieren passabel, aber sie sind auf generische Stimmen trainiert. Wer Kinder im Haushalt hat, einen Dialekt spricht oder einfach eine ungewöhnliche Stimmfrequenz hat, kennt das Problem: Mal reagiert das Gerät nicht, mal löst es falsch aus. Die Lösung des Projekts ist ein mehrstufiger Trainingszyklus, der sich selbst verbessert:

Erstens: Enrollment. Man sagt „Teach me my voice", das Gerät geht in einen Aufnahmemodus (cyan atmender LED-Ring), und ein Audio-Coach führt durch 25 Wake-Word-Wiederholungen plus 90 Sekunden natürliches Sprechen. Die Aufnahmen bleiben lokal.

Zweitens: Live-Labeling. Jede Wake-Word-Auslösung speichert den Audio-Anfang. War es ein Fehlalarm, kann man das auf drei Arten markieren: „That was a false alarm" sagen, den Center-Button doppelt drücken, oder einfach nichts sagen — erkannte Fehlauslösungen ohne anschließende Spracheingabe werden automatisch als falsch-positiv markiert.

Drittens: Retraining. Ein wöchentlicher Job trainiert microWakeWord neu — mit etwa 50.000 synthetischen Stimmen als Basis, den eigenen Aufnahmen mit dreifachem Gewicht und den markierten Fehlalarmen als harten Negativbeispielen. Das Training läuft in etwa zwei Stunden auf Apple Silicon oder NVIDIA-Hardware. Das Ergebnis wird qualitätsgeprüft gegen das aktuelle Modell, bevor es zum manuellen Flash bereitgestellt wird.

Die Zahlen aus dem Projekt-Haushalt: Der Detection-Cutoff stieg in drei Durchläufen von 0,43 auf 0,71 bei etwa 97% Recall. Jeder Durchlauf trainierte auf den Fehlern des vorherigen.

Das ist maschinelles Lernen in Reinform, und es funktioniert nur, weil das Projekt systematisch Fehler sammelt und in Training umwandelt. Gleichzeitig: Wer nur ein Gerät betreiben will und keine Lust auf Modell-Training hat, kann auch das mitgelieferte Standardmodell verwenden oder jedes beliebige microWakeWord-Modell einspielen. Der Aufwand ist optional, nicht Voraussetzung.

Speaker-Identifikation: Wer spricht da?

Dass ein Assistent erkennt, wer spricht, ist einer dieser Anwendungsfälle, die in Demos beeindrucken und in der Praxis selten zuverlässig funktionieren. Voice PE Realtime hat einen bemerkenswert pragmatischen Ansatz gewählt, der die Grenzen der aktuellen Technik respektiert.

Die Differenzierung läuft auf zwei Ebenen: Auf der einfachen Stufe gibt man zwei konfigurierbare Sprecher-Namen an (speaker_male_name, speaker_female_name). Das Modell verwendet dann für den männlichen Sprecher „Sir", für den weiblichen „Ma’am" und spricht beide mit ihren konfigurierten Namen an. Bestimmte Werkzeuge lassen sich auf einen Sprecher beschränken — die Beschränkung greift unterhalb des Modells, kann also nicht durch geschicktes Formulieren umgangen werden.

Die zweite Ebene ist Voice-Printing: Über TitaNet-Embeddings werden Stimmprofile erstellt („enrolled centroids" aus den Enrollment-Aufnahmen). Die Mindestdauer für eine Identifikation liegt bei drei Sekunden. Sprecher, die nicht zugeordnet werden können, gelten als „unknown" und bekommen neutrale Behandlung. Als Fallback dient eine Pitch-Analyse.

Was das nicht ist: Eine forensische Sprechererkennung. Das System trifft eine pragmatische Haushalts-Unterscheidung, keinen biometrischen Identitätsnachweis. Für die Frage „Hat das Kind oder der Partner gesprochen?" reicht das. Für alles andere nicht — und das ist auch gut so.

Ein verbreitetes Missverständnis: Sprachprofile werden nicht in die Cloud geladen. Die TitaNet-Embeddings werden lokal berechnet und in /share/voice-prints gespeichert.

Kosten: Was das im Betrieb wirklich bedeutet

Hier trennt sich das Projekt von fast allen lokal gehosteten Alternativen. Voice PE Realtime läuft vollständig über die kostenpflichtige OpenAI-API. Wer keine Kreditkarte bei OpenAI hinterlegt hat, kann das System nicht nutzen. Die Preisstruktur der Realtime API (Stand Juli 2026) ist transparent, aber nicht trivial zu durchschauen:

Audio-Eingabe: $32 pro 1 Million Token
Gecachte Audio-Eingabe: $0,40 pro 1 Million Token
Audio-Ausgabe: $64 pro 1 Million Token
Text-Eingabe (Tools, Anweisungen): $4 pro 1 Million Token
Text-Ausgabe im Session-Kontext: $24 pro 1 Million Token

Diese Token-Preise sind für Audiodaten notorisch schwer in Alltagskosten umzurechnen. Eine grobe Orientierung: Die OpenAI-Dokumentation gibt 1 Token pro 100 ms Audio beim Nutzer und 1 Token pro 50 ms beim Assistenten an, also etwa 600–1.200 Audio-Token pro Minute. In der Praxis (basierend auf Messungen von 4.000 Produktions-Sessions) liegen die Kosten für das Mini-Modell bei etwa $4–9 pro Stunde, für das volle gpt-realtime-2.1 bei schätzungsweise $8–15 pro Stunde — je nach Modellwahl, Reasoning-Einstellung und Cache-Nutzung. Das ist deutlich teurer, als die ersten Community-Schätzungen vermuten ließen.

Das klingt nach viel. Aber Sprachassistenten neigen zu langen Sessions. Wer das Mikrofon in der Küche während des Kochens offen lässt oder eine ausgedehnte Diskussion mit dem Assistenten führt, kann in zehn Minuten durchaus $1,50–3,00 erreichen. Auf den Monat hochgerechnet, landen Vielnutzer schnell bei $60–100 — deutlich mehr, als ein Alexa-Gerät in der Anschaffung kostet.

Das Projekt hat Gegenmaßnahmen eingebaut: Proaktive Session-Erneuerung vor OpenAIs 60-Minuten-Cap, Turn-Liveness-Watchdogs, die endlose Schweigeschleifen unterbinden, und konfigurierbare Follow-up-Fenster. Trotzdem: Die Kostenkontrolle liegt beim Nutzer. OpenAI hat keine Budget-Deckelung auf API-Ebene, die verhindert, dass eine fehlerhafte Konfiguration über Nacht dreistellige Beträge verursacht.

Seit dem 7. Mai 2026 ist gpt-realtime-2 in der API verfügbar, seit dem 6. Juli 2026 auch gpt-realtime-2.1 mit Reasoning-Unterstützung und einem günstigeren Mini-Modell. Das Mini-Modell kostet in etwa so viel wie das vorherige gpt-realtime-mini, hat aber zusätzliche Reasoning-Features. Für einfache Smart-Home-Kommandos reicht das vermutlich aus — aber getestet ist das im Projektkontext noch nicht breit.

Wer die Kosten drücken will, sollte aggressiv cachen: System-Prompts, Policy-Texte, Gerätelisten und Workflow-Anweisungen ändern sich selten. Der Sprung von $32 auf $0,40 durch Caching ist der wirksamste Kostenhebel.

Einschränkungen und offene Fragen

Das Projekt ist technisch beeindruckend, aber fünf Punkte sollte jeder kennen, bevor er anfängt:

Erstens: Kein Offline-Betrieb. Anders als die lokale HA-Assist-Pipeline mit Whisper und Piper funktioniert Voice PE Realtime nur mit Internetverbindung. Bei einem Internetausfall ist das Gerät ein Briefbeschwerer mit LED-Ring. Das ist der Preis für die Sprachqualität.

Zweitens: OpenAI-Abhängigkeit. Das Add-on ist fest mit der OpenAI Realtime API verdrahtet. Der openai_model-Parameter erlaubt jede Modell-ID, aber die API selbst ist proprietär. Es gibt derzeit keinen lokalen Ersatz, der auch nur annähernd vergleichbare Latenz und Qualität bietet. Lokale Modelle wie Llama oder Whisper+Piper arbeiten mit der klassischen STT→LLM→TTS-Kette und erreichen nicht die Konversationsqualität.

Drittens: Kein Datenschutz für Sprachinhalte. Während Enrollment-Aufnahmen und Wake-Word-Training lokal bleiben, gehen alle tatsächlichen Sprachbefehle an OpenAI. OpenAI speichert API-Daten standardmäßig für 30 Tage, es sei denn, man verwendet einen Enterprise-Vertrag mit Zero Data Retention (ZDR). Das ist eine grundsätzlich andere Datenschutz-Architektur als bei lokalen Lösungen.

Viertens: Komplexität. Das System hat mehr bewegliche Teile als eine Standard-HA-Assist-Pipeline. ESPHome-Firmware flashen, WebSocket-Konfiguration, Wake-Word-Modell-Training, Voice-Print-Enrollment, MCP-Server-Einrichtung — das sind viele Schritte, die alle funktionieren müssen. Die Doku ist gut, aber kein Ersatz für Debugging-Erfahrung.

Fünftens: Keine offizielle Unterstützung. Das Projekt ist ein Community-Fork, kein Nabu-Casa-Produkt. Es kann jederzeit von API-Änderungen, Modell-Deprecations oder schlicht mangelnder Maintainer-Zeit getroffen werden. Die 458 Commits und die aktuellen Updates (letzter Commit vor wenigen Stunden) sprechen für aktive Pflege, aber es gibt keine Garantie.

Vergleich: Lokal, OpenAI-basiert, Alexa und Google

Um das Projekt einzuordnen, hilft ein direkter Vergleich der verfügbaren Ansätze für die Sprachsteuerung mit Home Assistant.

Die klassische lokale Lösung (Whisper STT + Piper TTS + Wyoming) bietet vollständige Unabhängigkeit von Cloud-Diensten. Die Erkennungsqualität von Whisper ist gut, Piper klingt passabel natürlich, und die Reaktionszeit liegt je nach Hardware zwischen einer und fünf Sekunden. Ein ESP32-S3-BOX kostet etwa 45 Euro als einmalige Anschaffung. Keine laufenden Kosten. Der Nachteil: Die Latenz der Pipeline und das fehlende Kontextverständnis machen flüssige Gespräche unmöglich. Das System versteht Befehle, keine Konversation.

Voice PE Realtime bietet Konversationsqualität auf Alexa-Niveau oder darüber, mit besserem Kontextverständnis und flexibleren Automationen durch die HA-MCP-Anbindung. Die Latenz ist mit wenigen hundert Millisekunden konkurrenzfähig. Der Preis: Laufende API-Kosten und vollständige Cloud-Abhängigkeit.

Alexa und Google Assistant bieten die beste Spracherkennungsqualität, riesige Skill-Ökosysteme und sind ohne technische Vorkenntnisse nutzbar. Die Geräte kosten 30-60 Euro, es gibt keine nutzungsabhängigen Kosten. Aber: Jeder Sprachbefehl geht an US-Server, wird dort verarbeitet und gespeichert — oft 18 Monate oder länger. Die Integration mit Home Assistant ist möglich, aber immer eine Brückenlösung.

Wer Privacy über alles stellt, bleibt bei der lokalen Whisper-Piper-Lösung. Wer das beste Nutzererlebnis will und keine Privacy-Bedenken hat, bekommt mit Voice PE Realtime aktuell die überzeugendste Home-Assistant-Sprachsteuerung. Wer Alexa schon im Haus hat und zufrieden ist, hat wenig Grund zu wechseln — es sei denn, die HA-Integration ist ihm wichtiger als das Skill-Ökosystem.

Entscheidungshilfe: Wann ist das sinnvoll?

Eher sinnvoll, wenn du ki tools praxis nicht nur als Nachricht lesen willst, sondern eine praktische Einordnung brauchst: Was ändert sich, wen betrifft es und welche nächsten Schritte sind realistisch?

Eher abwarten, wenn die Quellenlage noch dünn ist, wichtige technische Details fehlen oder der Nutzen nur aus Hersteller- oder Projektversprechen besteht. Dann ist Beobachten besser als vorschnelles Umstellen.

Worauf du achten solltest: konkrete Verfügbarkeit, nachvollziehbare Kosten, offene Einschränkungen, Sicherheits- oder Datenschutzfolgen und belastbare Quellen statt bloßer Ankündigungen.

FAQ

Muss ich programmieren können, um Voice PE Realtime einzurichten?

Nein, aber Kommandozeilen-Erfahrung hilft. Man muss ESPHome-Firmware flashen, YAML-Konfigurationen anpassen, ein Add-on in Home Assistant installieren und einen OpenAI-API-Key besorgen. Wer Home Assistant selbst aufgesetzt hat, wird klarkommen. Wer HA nur als fertiges Image nutzt, sollte sich die Doku vorher genau ansehen.

Kann ich das System auch ohne OpenAI betreiben?

Zum Zeitpunkt der Veröffentlichung: nein. Das Add-on ist auf die OpenAI Realtime API ausgelegt. Zwar erlaubt der openai_model_custom-Parameter jede Modell-ID, aber es gibt derzeit kein lokales Modell, das echtes Speech-to-Speech mit vergleichbarer Latenz und Qualität liefert. Das kann sich ändern, ist aber aktuell nicht absehbar.

Funktioniert das auf Deutsch?

Die Wake-Word-Erkennung und das Enrollment funktionieren sprachunabhängig. Die OpenAI-Stimmen unterstützen mehrere Sprachen, Deutsch wird von gpt-realtime-2.1 verstanden und gesprochen. Die Qualität der deutschen Aussprache ist gut, aber nicht perfekt — vor allem bei zusammengesetzten Wörtern und Gerätenamen kann es holprig klingen. Die instructions (System-Prompt) kann man auf Deutsch verfassen, dann antwortet der Assistent auch auf Deutsch.

Wie viele Voice-PE-Geräte kann ich betreiben?

Theoretisch beliebig viele. Praktisch: Pro Gerät eine eigene Add-on-Instanz mit eigenem Port. Bei drei Geräten sind das drei Instanzen. Jede Instanz braucht ihre eigene OpenAI-Session. Die Kosten multiplizieren sich entsprechend — wer drei Geräte parallel betreibt, zahlt auch dreifache API-Kosten. Die Geräte arbeiten unabhängig voneinander, es gibt keine geräteübergreifende Session-Übergabe.

Lohnt sich das Wake-Word-Training wirklich?

Das kommt darauf an. Wer allein lebt und eine durchschnittliche Stimme hat, wird mit dem Standardmodell vermutlich zufrieden sein. Wer Kinder hat, die das Gerät nutzen sollen, in einem lauten Haushalt lebt oder einen starken Dialekt spricht, profitiert erheblich. Der Sprung von 0,43 auf 0,71 Detection-Cutoff ist kein theoretischer Wert, sondern macht sich im Alltag bemerkbar — weniger verpasste Aktivierungen, weniger Fehlauslösungen mitten in der Nacht.

Was passiert mit meinen Sprachdaten?

Die Enrollment-Aufnahmen und False-Wake-Audio-Samples bleiben auf dem HA-Server im /share-Verzeichnis. Die eigentlichen Sprachbefehle gehen an OpenAI und unterliegen den OpenAI-Datenschutzbedingungen: 30 Tage Speicherung standardmäßig, es sei denn, man hat einen Enterprise-Vertrag mit Zero Data Retention. Wer das nicht will, sollte beim lokalen Ansatz bleiben.

Kann ich andere KI-Modelle nutzen?

Der openai_model-Parameter akzeptiert jede gültige OpenAI-Modell-ID. gpt-realtime-2.1-mini ist günstiger, aber weniger leistungsfähig bei komplexen Anfragen. Theoretisch könnte man auch über openai_model_custom experimentelle oder zukünftige Modelle ansprechen, solange sie die Realtime-API-Schnittstelle implementieren. Andere Anbieter wie Anthropic oder Google haben derzeit keine vergleichbare Speech-to-Speech-API im Angebot.

Brauche ich zwingend einen Mini-PC oder reicht ein Raspberry Pi?

Das Add-on selbst ist leichtgewichtig — es managed nur die WebSocket-Verbindung und die OpenAI-Session. Ein Raspberry Pi 4 oder 5 reicht dafür völlig aus. Die eigentliche Rechenarbeit findet in der Cloud statt. Anders sieht es aus, wenn man Wake-Word-Modelle selbst trainieren will: Das Training läuft auf Apple Silicon oder NVIDIA-Hardware und braucht etwa zwei Stunden pro Durchlauf. Auf einem Raspberry Pi wäre das nicht praktikabel.

Was kostet der Betrieb realistisch im Monat?

Schwer zu sagen, weil es stark vom Nutzungsverhalten abhängt. Wer das Gerät nur für gelegentliche Sprachbefehle nutzt („Licht an", „Temperatur einstellen") und das Mini-Modell verwendet, kommt mit 5-10 Dollar im Monat aus. Wer täglich ausgedehnte Konversationen führt und das volle gpt-realtime-2.1 nutzt, kann 60-100 Dollar erreichen. Ein Familienhaushalt mit drei Geräten könnte 150 Dollar und mehr verbrauchen. Die gute Nachricht: Die Kosten sind transparent und in der OpenAI-Abrechnung nachvollziehbar. Die schlechte: Es gibt keine eingebaute Budgetgrenze.

Fazit

Voice PE Realtime ist das, was man bekommt, wenn ein fähiger Entwickler ein persönliches Problem löst und die Lösung als Open Source freigibt: technisch exzellent, an den richtigen Stellen pragmatisch, aber ohne den Produkt-Schliff, den ein kommerzielles Team draufpacken würde.

Die Speech-to-Speech-Qualität ist derzeit konkurrenzlos im Home-Assistant-Ökosystem. Das Wake-Word-Training ist kein Marketing-Feature, sondern funktionierendes maschinelles Lernen im eigenen Wohnzimmer. Die Sprachidentifikation ist zurückhaltend genug implementiert, um nicht in dystopische Gefilde abzurutschen. Und die Doku ist für ein Community-Projekt außergewöhnlich gut.

Die Kehrseite: Cloud-Abhängigkeit, laufende Kosten, Datenschutz-Kompromisse und eine Setup-Komplexität, die technisch weniger versierte Nutzer abschrecken wird. Wer auf der Suche nach einer lokal betriebenen, privacy-freundlichen Alternative zu Alexa ist, wird hier nicht glücklich. Wer aber bereit ist, Nutzungskomfort mit Geld und einem gewissen Kontrollverlust zu bezahlen, bekommt aktuell die beste verfügbare Sprachsteuerung für Home Assistant.

Das Projekt wird daran gemessen werden, ob es die Abhängigkeit von OpenAI langfristig lockern kann — entweder durch Unterstützung alternativer Realtime-APIs, sobald diese verfügbar sind, oder durch ein lokales Fallback-Modell für den Fall, dass das Internet ausfällt. Bis dahin ist es eine hervorragende Lösung für einen spezifischen Nutzertyp: Home-Assistant-erfahren, zahlungsbereit, und kompromissfähig in Sachen Datenschutz.

Passende Produktrecherchen

Für den technischen Aufbau und die passende Hardware finden sich bei Amazon verschiedene Komponenten. Beachte: Die folgenden Links führen zu thematisch relevanten Suchergebnissen — eine Kaufentscheidung solltest du auf Basis eigener Recherche treffen.

Hinweis gemäß § 5 TMG und Amazon PartnerNet-Richtlinien: kalika.de nimmt am Amazon Partnerprogramm teil. Die mit Sternchen () oder als „Affiliate-Link" gekennzeichneten Links sind Werbelinks. Wenn du über diese Links einkaufst, erhalten wir eine kleine Provision — ohne Mehrkosten für dich. Als Amazon-Partner verdienen wir an qualifizierten Verkäufen.*

Quellen

ki tools praxis – Illustration 3