The project’s most instructive feature is its command routing. Rather than asking a conversational model to interpret every request, Lewis uses explicit rules first, a small language model second, and a larger conversational model only when necessary. That design helps explain how routine actions can feel immediate even when loading the conversational model takes more than 10 seconds.
How the local voice pipeline works
Lewis describes five model-based components surrounding a rule-based command handler. Each has a distinct job:
| Component | Role in Lewis’s system |
|---|---|
| openWakeWord | Detects the activation phrase and triggers the rest of the assistant. |
| NVIDIA Parakeet | Converts speech into text. |
Llama 3.2 3B, identified as llama3.2:3b | Maps requests that do not match explicit rules onto predefined commands. |
| Qwen 3 | Handles conversation when the request is not recognized as a command. |
| Kokoro | Converts the resulting response into spoken audio. |
The rule-based path is important. A request such as “Play AC/DC” can match a predefined command directly after transcription. It does not need another AI model to decide what the user meant.
A less explicit request—“I’m in the mood to listen to some AC/DC”—goes to Llama 3.2 3B, which attempts to map it onto the same supported command. Only requests outside those command paths reach Qwen.
The practical implication is that conversational capability and household-control latency need not be tied together. A larger model can handle open-ended questions without sitting in the execution path for every light switch or music command. The smaller model’s described role is interpretation against an existing command list, rather than inventing arbitrary actions.
Lewis originally developed these components for a Discord bot. Reusing them for a home assistant meant changing the input and action endpoints: microphone audio and Home Assistant automations replaced Discord input and bot commands. That is useful software reuse, although deploying the components through Discord would have different privacy boundaries from a wholly local microphone setup.
What “faster than Alexa” establishes
According to How-To Geek, Lewis observed wake-word detection in a small fraction of a second and Parakeet transcription faster than the duration of speech on a GeForce RTX 5060 Ti. He reports that simple commands usually execute as soon as he finishes speaking, while requests requiring the Llama interpreter produce output in less than a second after speech ends.
Those observations do not establish a universal response-time advantage. Lewis does not identify the Alexa comparison device, provide repeated measurements, or isolate network delay from cloud processing time. Nor does “producing output” necessarily measure the same endpoint as the beginning of a spoken answer.
The conversational path behaves differently. Lewis reports that initially loading his Qwen 3.x model takes more than 10 seconds. Once it is resident in GPU memory, he describes its response speed as conversationally acceptable, without supplying a numerical measurement.
A separate MakeUseOf build report describes roughly two seconds from the end of speech to the beginning of a spoken response with its language model already loaded into VRAM. That is another builder’s account of a different setup, not an independent replication of Lewis’s results. No independent replication of Lewis’s timing claims was found in the available reporting.
NVIDIA’s NeMo documentation confirms that Parakeet can perform local transcription, including a quick-start example using nvidia/parakeet-tdt-0.6b-v2. Lewis does not specify his Parakeet checkpoint, however, so that documented example should not be mistaken for his exact configuration. NVIDIA also documents streaming recognition separately; processing an audio recording faster than its duration does not, by itself, establish continuous streaming behavior.
For anyone assessing the design, command execution, first spoken response and cold-start loading are separate measurements. A system can be excellent at the first and noticeably slower at the others.
Home Assistant supports the architecture, not automatic compatibility
Lewis suggests orchestrating the components through Home Assistant’s Assist pipeline using the Wyoming protocol, or through custom scripting. Home Assistant’s own documentation confirms that Wyoming connects Assist to external speech-to-text, text-to-speech and wake-word services.
Those services can run on another computer on the local network. This allows an existing Home Assistant host to remain in place while more demanding speech processing runs on a separate machine. Home Assistant explicitly documents that arrangement for resource-intensive services such as Whisper.
For an already-running, Wyoming-compatible service, the documented connection procedure is:
- Open Home Assistant and go to Settings > Devices & services.
- Select Add Integration, then choose Wyoming Protocol.
- Enter the service’s hostname or IP address and its listening port when prompted.
- Complete the integration setup. A discoverable service may instead appear automatically under Discovered.
This connects a compatible service; it does not install the models or assemble Lewis’s routing logic. Home Assistant’s Wyoming documentation names services including Whisper, Piper and openWakeWord, but does not establish that Lewis’s exact Parakeet–Llama–Qwen–Kokoro combination is a turnkey configuration.
Room devices add another layer. Lewis proposes Raspberry Pi- or ESP32-based microphone and speaker satellites connected to a central GPU server, but says he has not yet tackled a complicated satellite deployment. His report therefore supports the central assistant design more strongly than a finished whole-home installation.
GPU memory is only part of the hardware decision
According to Lewis’s How-To Geek account, 8GB of GPU memory is enough to run Parakeet, Kokoro and Llama 3.2 3B simultaneously. That statement does not include Qwen in the three-model memory budget.
The distinction matters when selecting hardware. The report does not identify the Qwen model size, model precision or full memory configuration, so it cannot establish that the complete conversational stack fits comfortably into any 8GB card. Lewis says 12GB and 16GB cards offer more room, but provides no reproducible capacity comparison.
For Windows users, individual component support also should not be confused with a verified Windows-native installation. The openWakeWord project documents Windows support through ONNX Runtime; on Linux, its installation supports both ONNX Runtime and TensorFlow Lite Runtime. Its optional Speex noise-suppression feature is documented for x86 and Arm64 Linux, rather than Windows.
Lewis does not provide a complete operating-system and runtime recipe for the full stack. A spare Windows PC with a suitable GPU is therefore potential hardware for the project, not proof that every component will install and work together without additional integration.
Local processing gives control over privacy
The privacy benefit is substantial but narrower than the phrase “completely private” suggests. Local speech recognition and local language-model inference remove the need to send those requests to a remote AI provider. They also put retention decisions in the owner’s hands.
Lewis’s own workflow illustrates that distinction. He reports initially retaining misfires and misunderstood requests to train a LoRA customization for his speech patterns and use cases. He says he subsequently disabled retention once the system worked reliably.
Thus, local processing and zero retention are separate properties. Audio can remain inside a house and still be stored. Likewise, running models locally does not establish the behavior of every connected automation or service.
Lewis reports that nothing now leaves his server and nothing is retained, but his account does not include a network audit or an independent examination of logging. The supported conclusion is that this architecture enables local control over speech processing and retention—not that installing these models automatically guarantees either outcome.
Wake-word tuning deserves attention too. The openWakeWord project recommends testing activation thresholds in the intended environment, rather than assuming its default threshold of 0.5 fits every room. Its optional voice-activity detection can reduce false activations from non-speech noise, while voice-specific verifier models can reduce unwanted activation at the cost of making the assistant less responsive to unfamiliar speakers.
These are meaningful household trade-offs: making the assistant more selective can also make it less convenient for guests or other family members.
A development project rather than an appliance replacement
Lewis reports spending more than two weeks making the assistant reliable, with substantial help from Claude, before dealing with a complex satellite arrangement. That development effort belongs alongside the GPU requirement when judging the cost.
The strongest reason to pursue this design is control: over command handling, model selection, response generation and data retention. Its most reusable engineering lesson is to keep common commands on a short, predictable path and reserve conversational inference for requests that need it.
For an enthusiast already running Home Assistant and willing to maintain custom software, Lewis’s build offers a credible architecture. For someone choosing hardware specifically to reproduce it, the missing Qwen configuration and incomplete deployment recipe remain practical blockers to buying confidently. The project demonstrates a promising local assistant; it does not yet supply an appliance-like replacement that another household can reproduce from a parts list alone.