Edge-Native Voice Assistants: Integrating Local LLMs with Home Assistant Hardware

The paradigm of smart home automation is currently undergoing a fundamental architectural shift. For the past decade, the industry standard has relied heavily on cloud-tethered voice assistants, which routinely route sensitive domestic audio to external corporate servers for speech-to-text (STT) processing, natural language understanding (NLU), and text-to-speech (TTS) generation. This reliance introduces inherent latency, creates absolute dependencies on external network connectivity, and raises significant privacy concerns. This architecture is increasingly being replaced by edge-native, fully localized pipelines. This transition has been catalyzed by the convergence of highly capable local hardware ecosystems, specifically devices like the Home Assistant Green and the Home Assistant Voice Preview Edition, alongside the rapid proliferation of highly compressed, open-weights Large Language Models (LLMs) managed by inference frameworks such as Ollama.

Establishing a fluid, conversational artificial intelligence interface entirely on a local network host requires a highly orchestrated technology stack. The latency budget for a voice assistant is unforgiving; responses must ideally begin within a sub-second window to feel natural to the human user. Achieving this requires precise hardware selection at both the sensory edge and the inference core, optimized audio pipelines utilizing decentralized protocols, and rigorous model selection focusing on advanced architectures like the Qwen and Gemma model families.

The Hardware Foundation: Orchestration and Sensory Edge

Creating a fully private, LLM-backed voice assistant necessitates a bifurcated hardware approach: a central orchestration hub for state management, low-power edge hardware for audio capture and wake-word detection, and high-performance computational hardware for AI inference.

Central Orchestration: Home Assistant Green

At the core of the local smart home network sits the automation hub. The Home Assistant Green serves as an accessible, plug-and-play entry point for this orchestration. As a dedicated hardware hub, the Home Assistant Green runs the Home Assistant Operating System natively, managing the state of all connected Internet of Things (IoT) devices, maintaining the automation logic, and routing the complex internal network traffic required for voice pipelines1.

While the Home Assistant Green is highly efficient at state management and executing standard automations, its internal hardware is optimized for low power consumption rather than heavy computational workloads. Consequently, attempting to run advanced machine learning models directly on the Green's processor introduces severe bottlenecks. Weaker Home Assistant hardware can lead to prohibitively slow speech processing and inference times3. For users operating solely on a Home Assistant Green without a supplementary inference server, the system typically mandates offloading speech processing to the Home Assistant Cloud to maintain acceptable response times5. However, for a fully localized, zero-cloud architecture, the Home Assistant Green acts primarily as the traffic director, utilizing the Wyoming protocol to route audio payloads to dedicated, high-performance edge nodes on the local area network.

Audio Edge Hardware: Home Assistant Voice Preview Edition

The physical interaction point for the user is the Home Assistant Voice Preview Edition (VPE). Priced at approximately $59, the VPE is a purpose-built, privacy-focused voice satellite designed by Nabu Casa, the commercial entity behind Home Assistant7. Unlike commercial smart speakers that utilize proprietary, locked-down firmware aimed at ecosystem lock-in, the VPE operates entirely on open-source ESPHome firmware, ensuring complete transparency and hackability7.

The internal architecture of the Voice Preview Edition is characterized by a deliberate "split-brain" design engineered for specialized audio processing at the absolute edge of the network7. This architecture separates the networking logic from the digital signal processing to ensure maximum efficiency.

The wake-word detection (e.g., recognizing the phrase "Okay Nabu") is processed locally on the ESP32-S3 using the microWakeWord engine7. This ensures that the device continuously evaluates ambient audio without ever transmitting a data stream over the network until an intentional wake-word trigger is positively identified. Once triggered, the XMOS XU316 DSP scrubs the audio signal, isolating the human voice from background interference and acoustic echo, which significantly improves downstream speech-to-text transcription accuracy before the payload is dispatched to the central hub11.

Inference Server Hardware and the Economics of Local AI

While the Voice Preview Edition captures the pristine audio and the Home Assistant Green routes the data, the heavy computational lifting requires a dedicated local inference server. For the basic speech-to-text (STT) transcription and localized intent matching, a mid-range system (such as an Intel N100 mini-PC with 16GB of RAM) is generally sufficient5. However, replacing the basic intent matcher with a Large Language Model as the primary conversation agent drastically alters the hardware requirements.

To run a quantized 8-Billion (8B) to 14-Billion (14B) parameter LLM concurrently with STT and TTS models, the inference server must be equipped with a modern Discrete Graphics Processing Unit (GPU)14. The minimum recommended configuration for a fluid experience is a GPU possessing at least 12GB to 16GB of Video RAM (VRAM)14. Apple Silicon hardware, such as the Mac Mini M2, M3, or M4, is also highly capable of running this entire stack natively. The unified memory architecture of Apple Silicon provides immense memory bandwidth, allowing the GPU cores to access large model weights directly without the bottleneck of PCIe transfer speeds16.

The financial structure of this architecture is defined almost entirely by capital expenditure (CapEx) rather than operating expenditure (OpEx). Users face an upfront hardware cost encompassing the $59 Voice Preview Edition and the substantial cost of the inference server or discrete GPU. However, once deployed, the ongoing subscription fees, per-token API costs, and wake-word licensing fees associated with cloud AI providers are reduced to exactly $0 per month18.

For comparison, utilizing premium cloud application programming interfaces (APIs) introduces variable, usage-based costs. While exact pricing fluctuates, leading cloud services generally charge per million characters for TTS and per minute of audio for STT.

While renting fractional GPU instances (like an RTX 3060 at ~$0.03/hr on services like Clore.ai) to host models like Kokoro is an option for developers, the ultimate goal for smart home users is to bring the compute entirely inside the residential local area network20.

The Wyoming Protocol and the Audio Pipeline

To coordinate the various disparately hosted components of the voice stack, Home Assistant relies extensively on the Wyoming protocol. Wyoming is a lightweight, low-latency communication protocol specifically engineered to transport JSON Lines (JSONL) and raw Pulse-Code Modulation (PCM) audio streams over network sockets22. This protocol is highly modular, enabling developers to spin up independent Docker containers for STT, NLU, and TTS, all of which communicate seamlessly with the Home Assistant Green hub.

Speech-to-Text (STT): The Whisper Integration

When the Voice Preview Edition detects a wake word, it begins streaming the subsequent audio over the Wyoming protocol to the designated STT engine. The standard local deployment utilizes OpenAI's Whisper architecture, which has revolutionized robust speech processing by training on massive datasets to minimize Word Error Rates (WER)24. In a home environment, this is typically implemented via whisper.cpp or the faster-whisper library for optimized CPU and GPU inference26.

The execution speed of the STT engine is a critical bottleneck in the perceived latency of the entire voice assistant. Utilizing wyoming-faster-whisper loaded with a heavily quantized tiny or base model enables near real-time transcription, often completing in a fraction of a second18. While larger Whisper models (such as medium or large-v3) offer superior accuracy and lower WER, particularly for complex phrasing or diverse accents, they introduce processing delays that can disrupt conversational flow unless accelerated by a powerful, dedicated GPU28.

Text-to-Speech (TTS): Piper vs. Kokoro

For the voice response phase of the pipeline, Home Assistant historically defaulted to Piper, a highly efficient local TTS engine optimized for low-resource environments like the Raspberry Pi26. While Piper handles basic, rigid phrasing well and operates with exceedingly low latency, it frequently struggles with natural vocal cadence. Furthermore, field reports indicate that Piper consistently stumbles when synthesizing complex strings such as currency amounts, phone numbers, and intricate addresses, often sounding overly robotic or phonetic26.

A rapidly emerging standard for localized, high-fidelity TTS is the Kokoro-82M model. Despite possessing a remarkably small architecture of only 82 million parameters and requiring under 2GB of VRAM (while also running efficiently on CPU-only instances), Kokoro delivers state-of-the-art, natural-sounding speech synthesis20. Licensed under Apache 2.0, Kokoro supports multiple languages and offers diverse voice styles and emotional conditioning without the subscription costs associated with cloud providers20.

Integrating Kokoro into the Home Assistant Wyoming pipeline involves running a community-maintained Docker container, such as the ghcr.io/remsky/kokoro-fastapi-gpu image33. This specific container exposes an OpenAI-compatible API endpoint directly on the local network19. Home Assistant can interface with this endpoint via the "OpenAI TTS" custom integration or through a dedicated Wyoming proxy container that bridges the API to the native pipeline36.

One critical challenge in the TTS pipeline is continuous streaming support. If the Wyoming proxy or the TTS engine waits for the entire LLM text response to be generated before synthesizing the audio file, the user experiences a massive latency spike, resulting in unnatural conversational pauses38. Advanced implementations configure the LLM to output text in chunks or sentences, feeding them sequentially into the TTS engine to begin audio playback before the LLM has even finished its inference process17.

LLMs at the Edge: Ollama, Qwen, and Gemma

The core intelligence of the local voice assistant is provided by an LLM running on an inference engine, with Ollama being the predominant industry standard for local deployment26. Home Assistant provides a native Ollama integration that connects the Assist pipeline directly to the local model API, which typically operates on port 114341.

However, the selection of the open-weights model is a critical variable. Not all highly rated LLMs are suited for smart home control. A voice assistant must translate ambiguous natural language requests (e.g., "Make it cozy in the living room") into strict JSON structures that correspond directly to Home Assistant entity states and API service calls29. This capability is known formally as tool calling or function calling.

Console Interaction and Verification

Administrators typically interact with Ollama via the command line interface (CLI) to download, test, and verify models prior to integrating them with the Home Assistant user interface. The process is streamlined into simple pull and run commands. For example, testing the Gemma 2B model natively in the terminal demonstrates its baseline capabilities before it is subjected to the complex system prompts of Home Assistant:

Bash

# Downloading and initiating a chat session with the Google Gemma 2B model
$ ollama run gemma:2b
>>> Turn off the kitchen lights.
I do not have direct access to your physical devices or smart home systems. Therefore, I cannot turn off your kitchen lights.

40

The response above illustrates a fundamental limitation: without an integration passing a specific tool schema to the model, the LLM is isolated from the physical world. To enable the model to actually control the home, it must be accessed via API with a defined system prompt and an array of available tools. Ollama's REST API accepts JSON payloads that include the conversation history and the required function schema42. A standard curl request to the Ollama endpoint demonstrates how Home Assistant systematically communicates with the model in the background:

JSON

curl http://localhost:11434/api/chat -d '{
 "model": "qwen2.5:7b",
 "messages": [{"role": "user", "content": "Turn on the living room lamp."}],
 "tools": [
   {
     "type": "function",
     "function": {
       "name": "execute_service",
       "description": "Call a Home Assistant service to change device state.",
       "parameters": {
         "type": "object",
         "properties": {
           "domain": {"type": "string"},
           "service": {"type": "string"},
           "entity_id": {"type": "string"}
         },
         "required": ["domain", "service", "entity_id"]
       }
     }
   }
 ]
}'

43

Qwen2.5 vs. Gemma 2 in Agentic Tasks

When evaluating models in the highly efficient 2B to 14B parameter range, stark performance profiles emerge between the Qwen and Gemma architectures regarding their utility as home agents. While both are highly capable text generators, their architectural biases dictate their effectiveness in a pipeline reliant on strict JSON output.

The Qwen2.5 Family: Developed by Alibaba Cloud, the Qwen2.5 series (specifically the 7B, 14B, and 32B Coder and Instruct variants) currently dominates local benchmarks for logical reasoning and strict formatting45. Because Qwen2.5 models are natively trained on vast datasets of code and JSON structures, they are highly reliable at adhering to the rigid schema required by Home Assistant's tool-calling APIs45. When tasked with modifying multiple smart home entities simultaneously, Qwen2.5 accurately generates the required service payloads without hallucinatory syntax errors45.

The Gemma 2 Family: Google's Gemma 2 models (e.g., 2B and 9B) are widely praised within the open-source community for their creative writing style, nuanced translation capabilities, and highly engaging conversational fluidity45. However, in the strict context of smart home tool calling, system builders and researchers frequently describe Gemma 2 as an "inconsistent glass cannon"46. While it produces highly human-like text responses, it frequently fails to output valid JSON payloads, leading to broken automation chains and failed device executions45.

For a production-grade Home Assistant deployment focused on device control, Qwen2.5 (14B or 7B) is the demonstrably superior choice. Conversely, Gemma 2 may be preferred strictly if the primary use case is purely conversational querying, creative text generation, or stylistic roleplay where physical execution is secondary45.

Advanced Integration: The Extended OpenAI Conversation Component

Because the native Home Assistant Ollama integration can sometimes lack advanced routing capabilities for complex multi-agent setups or custom functional execution, many system architects deploy the extended_openai_conversation custom component49.

This component treats the local Ollama instance (or a local routing proxy like LiteLLM) as an OpenAI-compatible endpoint. Doing so unlocks advanced capabilities, allowing the injection of highly complex tool schemas directly into the model's context51. With this component, developers can grant the local LLM the ability to execute bash commands, perform file operations, scrape web data, or dynamically query SQLite databases regarding the history of a sensor state51.

This level of integration requires careful entity management. A significant challenge in LLM-based smart homes is context window bloat. Home Assistant must inject the state of available devices into the LLM's prompt before the model can make an informed decision. Exposing a massive ecosystem of IoT devices rapidly consumes the model's context window. For example, exposing 50+ entities can consume thousands of tokens, massively slowing down inference and causing smaller models to hallucinate or "forget" devices mid-conversation due to attention degradation26. To optimize performance, administrators must strictly limit entity exposure to only the critical devices intended for voice control, grouping entities into higher-level abstractions (e.g., exposing a single "Living Room Lights" group rather than listing 10 individual smart bulbs)1.

To further achieve sub-second voice responses, relying exclusively on an LLM for every command is architecturally inefficient. Advanced implementations utilize a "local-first" handling strategy26. In this configuration, Home Assistant evaluates the transcribed text from Whisper against its native, regex-based intent matching engine first. If a command is rigid and explicit (e.g., "Turn off the kitchen lights"), the standard intent engine executes the command instantly without ever querying the LLM26. The LLM is reserved as a fallback, absorbing only complex, compound, or conversational queries (e.g., "Did I leave the garage light on, and is the back door locked?")26.

Scaling Inference: Managing Multiple Ollama Instances

As deployments scale and multiple household users interact with the system simultaneously, administrators may attempt to run multiple concurrent queries against an Ollama server. However, Ollama's VRAM management architecture introduces significant complexities when scaling.

When the OLLAMA_NUM_PARALLEL environment variable is increased to handle multiple simultaneous requests, Ollama does not load multiple independent copies of the model weights into the GPU. Instead, it exponentially scales the Key-Value (KV) cache to maintain the context of multiple parallel sessions53. The KV cache stores the attention vectors for every token in the active context window. If a model declares a massive theoretical context window in its GGUF metadata (e.g., 128K tokens), Ollama may attempt to pre-allocate VRAM for the entire cache upon loading the model, anticipating maximum usage54.

This behavior can result in a catastrophic memory footprint, with the KV cache consuming upward of 60GB to 90GB of VRAM, even if the user's actual prompt is only a few hundred tokens long54. When VRAM is exhausted, Ollama is forced to "spill" processing over to much slower system RAM, causing inference speeds to plummet from an optimal 40+ tokens per second to unusable, single-digit speeds15.

To mitigate KV cache explosion and VRAM fragmentation when utilizing multiple GPUs, deploying a load-balanced architecture is recommended over relying on high parallel settings within a single instance53. Rather than forcing a single Ollama instance to manage massive parallel contexts across multiple GPUs, architects deploy multiple distinct Ollama server containers. Each container is bound to a specific, dedicated GPU using the CUDA_VISIBLE_DEVICES environment flag53. A reverse proxy, such as Nginx, sits in front of the containers, acting as a load balancer to distribute incoming API requests evenly across the independent Ollama instances57. This segregates the KV cache allocations, prevents VRAM spillage, and ensures optimal, isolated hardware utilization across the cluster.

The Impracticality of Voice-Driven "Vibe Coding"

Within the broader AI development community, "vibe coding" refers to a rapid prototyping paradigm where developers write, edit, and iterate on complex software entirely through natural language interactions with an AI agent, without manually typing syntax. While highly specialized smaller coding models—most notably Qwen2.5-Coder—are exceptionally proficient at autocomplete and local code generation within an Integrated Development Environment (IDE)59, attempting to execute vibe coding through a voice interface (such as the Home Assistant Voice Preview Edition) is fundamentally flawed and rarely practiced by open-model self-hosters.

The impedance mismatch arises directly from the physical limitations and error rates of linear audio pipelines:

1. STT Transcription Failures: Programming requires absolute, character-level precision regarding syntax, camelCase variable naming conventions, and specialized punctuation. STT models like Whisper are trained predominantly on conversational, natural speech and struggle immensely to accurately transcribe complex logical structures or specialized algorithmic jargon dictated via a microphone61. A single mistranscribed bracket or variable name renders the resulting code non-functional.
2. Lack of Visual Screen Grounding: Effective vibe coding requires a tight, continuous feedback loop where the developer visually reviews the exact code structure generated by the LLM in an IDE before accepting it. A headless smart speaker system offers no visual output terminal for review.
3. TTS Incomprehensibility: If the LLM generates a 50-line Python script or a complex YAML automation, having a TTS engine (even a high-quality one like Kokoro) literally read the raw syntax, semantic indentation, and punctuation brackets aloud is utterly incomprehensible and entirely unusable for the human developer.
4. Prompt Injection and Severe Security Risks: Exposing a highly agentic LLM with potential access to the host's file system or broader local network to open, unauthenticated voice commands introduces severe, unacceptable security risks. Without robust validation protocols, a mistranscribed command, ambient noise, or a malicious audio prompt injection (e.g., a commercial or news clip playing from a nearby television) could inadvertently trigger the LLM to execute destructive bash scripts or modify critical system files62.

Consequently, while local LLMs are perfectly suited for vibe coding within the secure, text-based confines of a terminal or IDE integration, combining this specific practice with ambient smart home voice satellites remains largely unfeasible and highly discouraged.

Benchmarking Capabilities: HomeBench and VoiceAgentBench

As local voice assistants mature from hobbyist projects to robust deployment architectures, academic and industry frameworks have emerged to quantify their reliability mathematically. Integrating LLMs into smart homes introduces the persistent risk of the model confidently executing the wrong action (hallucination) or failing to understand the cascading logical constraints of physical devices.

HomeBench is a specialized smart home dataset specifically designed to evaluate how LLMs handle both valid and invalid instructions across complex, multi-device environments63. The benchmark reveals that even frontier, cloud-based models struggle significantly in realistic home automation contexts. For example, when presented with invalid multi-device instructions (commands that violate physical device constraints or logic, such as adjusting the fan speed of an air conditioner that is powered off), models frequently fail to recognize the error or refuse the command, resulting in a near 0.0% success rate in zero-shot scenarios for many architectures63.

Furthermore, advanced simulators like SimuHome evaluate the complex temporal reasoning of LLMs (e.g., "Keep the kitchen lights on until the dishwasher finishes"). Testing reveals that workflow scheduling and temporal dependencies remain a persistent, unresolved challenge across the industry, exposing the hard limits of current Chain-of-Thought (CoT) reasoning when applied to time-delayed physical actions64.

VoiceAgentBench specifically targets end-to-end voice agents, measuring tool selection accuracy and structural consistency when audio is transcribed and processed sequentially66. Benchmarks in this domain indicate that traditional cascaded pipelines (STT  LLM  TTS) suffer from severe error propagation; a minor transcription error by Whisper regarding a specific device name can completely derail the LLM's subsequent tool-calling logic68.

Future Forecasts: The Shift to Audio-Native LLMs

The current prevailing architecture of linking discrete, specialized models (Whisper for STT + Ollama for NLU + Kokoro for TTS) via the Wyoming protocol is widely considered a transitional phase in the evolution of AI. The future trajectory of edge-native voice assistants lies definitively in Audio-Native LLMs (SpeechLMs)29.

Emerging models like Qwen2.5-Omni or specialized academic architectures like DESAMO are designed to ingest raw audio waveforms directly into the LLM's embedding space, bypassing the intermediate text transcription step entirely29. This unified, end-to-end approach provides several profound technological advantages:

• Paralinguistic Comprehension: By analyzing the raw waveform, the LLM can interpret emotion, vocal tone, hesitation, and sarcasm, providing critical context that is entirely lost when audio is flattened into plain text transcriptions69.
• Ambient Sound Recognition: An audio-native model can identify and classify non-speech environmental events. For example, a smart home system equipped with an Audio LLM could detect the acoustic signature of breaking glass or an elderly person falling, classifying it as an emergency intent and executing a routine without requiring a spoken command29.
• Drastically Reduced Latency: Collapsing three separate models into a single end-to-end inference pass drastically reduces total system memory overhead and computation time. This architectural shift promises to bring response latency closer to natural human conversational norms (typically under 300 milliseconds), finally bridging the gap between artificial and human interaction speeds66.

As these multimodal architectures are further compressed, quantized, and optimized for consumer-grade GPUs, the orchestration overhead of intermediate routing tools like Wyoming will decrease. This will eventually allow edge devices like the ESP32-S3 to stream ambient audio directly into a single, unified localized intelligence, transforming the smart home from a reactive command center into a contextually aware, proactive environment.

Works cited

1. Ollama - Home Assistant, https://www.home-assistant.io/integrations/ollama/
2. Home Assistant Voice Preview Edition - ameriDroid, https://ameridroid.com/products/home-assistant-voice-preview-edition
3. Home Assistant Voice Preview Edition | Apollo Automation, https://apolloautomation.com/products/home-assistant-voice
4. Home Assistant Voice Preview Edition - The Pi Hut, https://thepihut.com/products/home-assistant-voice-preview-edition
5. Home Assistant Voice - Preview Edition - Pimoroni, https://shop.pimoroni.com/products/home-assistant-voice
6. Home Assistant Voice Preview Edition - Everything Smart Technology, https://shop.everythingsmart.io/products/home-assistant-voice-preview-edition
7. Home Assistant Voice Preview Edition review: is the $59 box ready, https://botmonster.com/smart-home/home-assistant-voice-preview-edition-review/
8. Home Assistant Voice Preview Edition - mostlychris, https://www.mostlychris.com/home-assistant-voice-preview-edition-2/
9. Home Assistant Voice Preview Edition, https://www.home-assistant.io/voice-pe/
10. Home Assistant Voice Preview Edition: Private Voice Control for, https://esp32.co.uk/home-assistant-voice-preview-edition-private-voice-control-for-smart-homes/
11. "ReSpeaker Lite" - new Seeed Studio Voice Assistant Development, https://community.home-assistant.io/t/respeaker-lite-new-seeed-studio-voice-assistant-development-kit-hardware-combine-esp32-with-xmos-xu316-dsp-chip-for-advanced-audio-processing-as-a-esphome-based-home-assistant-assist-satellite-voice-devkit/756944
12. Re-Using an Echo Dot 3rd gen with Voice Assistant, https://community.home-assistant.io/t/re-using-an-echo-dot-3rd-gen-with-voice-assistant/1020256
13. How to Collect and Search Ollama Logs with OpenTelemetry - Bronto, https://bronto.io/blog/logging-events-from-ollama
14. Voice Assistant Connected to Local Ollama, https://community.home-assistant.io/t/voice-assistant-connected-to-local-ollama/935725
15. Ollama VRAM Requirements: Complete 2026 Guide to GPU, https://localllm.in/blog/ollama-vram-requirements-for-local-llms
16. Building the AI-powered local smart home - Home Assistant, https://www.home-assistant.io/blog/2025/09/11/ai-in-home-assistant/
17. Local LLM/Whisper/Piper for HA Voice Assist... How to improve the, https://www.reddit.com/r/homeassistant/comments/1migi2p/local_llmwhisperpiper_for_ha_voice_assist_how_to/
18. Local Voice Assistant - Whisper + Ollama + Kokoro TTS Guide (2026), https://everylocalai.com/stack/local-voice-assistant
19. Deploy Open-Source TTS on GPU Cloud: Kokoro, Fish Speech, and, https://www.spheron.network/blog/deploy-open-source-tts-gpu-cloud-2026/
20. Kokoro TTS | Guides - Clore.ai, https://docs.clore.ai/guides/audio-and-voice/kokoro-tts
21. hexgrad/Kokoro-82M - Hugging Face, https://huggingface.co/hexgrad/Kokoro-82M
22. Wyoming Protocol - Home Assistant, https://www.home-assistant.io/integrations/wyoming/
23. Local Voice Assistant Step 2: Speech to Text and back - Earth.li, https://www.earth.li/~noodles/blog/2025/05/voice-assistant-whisper.html
24. arXiv:2212.04356v1 [eess.AS] 6 Dec 2022, https://arxiv.org/pdf/2212.04356
25. Introducing Whisper - OpenAI, https://openai.com/index/whisper/
26. Home Assistant AI voice with a local LLM: what works in 2026, https://botmonster.com/smart-home/build-private-local-ai-voice-assistant-2026/
27. Wyoming protocol server for whisper.cpp - GitHub, https://github.com/rhasspy/wyoming-whisper-cpp
28. Remote voice assist Pipeline - Whisper - Home Assistant Community, https://community.home-assistant.io/t/remote-voice-assist-pipeline-whisper/841968
29. DESAMO: A Device for Elder-Friendly Smart Homes Powered ... - arXiv, https://arxiv.org/pdf/2508.18918
30. My Journey to a reliable and enjoyable locally hosted voice assistant, https://community.home-assistant.io/t/my-journey-to-a-reliable-and-enjoyable-locally-hosted-voice-assistant/944860
31. Kokoro TTS Review 2026 | AI Infrastructure & MLOps Tool, https://aiagentslist.com/agents/kokoro-tts
32. Run Free Text-to-Speech Locally on Open WebUI: Kokoro TTS, https://www.youtube.com/watch?v=UzpGgC2SmzI
33. GitHub - remsky/Kokoro-FastAPI: Dockerized OpenAI-compatible, https://github.com/remsky/Kokoro-FastAPI
34. How to use Kokoro TTS instead of Piper for Assist : r/homeassistant, https://www.reddit.com/r/homeassistant/comments/1j895sr/how_to_use_kokoro_tts_instead_of_piper_for_assist/
35. Setup Kubernetes · remsky/Kokoro-FastAPI Wiki - GitHub, https://github.com/remsky/Kokoro-FastAPI/wiki/Setup-Kubernetes
36. Configuration Issues: OpenAI TTS Speech Service and Kokoro, https://community.home-assistant.io/t/configuration-issues-openai-tts-speech-service-and-kokoro/993509
37. Best way to implement Kokoro TTS? : r/homeassistant - Reddit, https://www.reddit.com/r/homeassistant/comments/1r0f110/best_way_to_implement_kokoro_tts/
38. TTS streaming support - Voice Assistant - Home Assistant Community, https://community.home-assistant.io/t/tts-streaming-support/909884
39. Run LLM Locally on Raspberry Pi: No API, Free & Offline, https://www.electronicsforu.com/electronics-projects/run-llm-locally-on-raspberry-pi-free
40. How to Run Google Gemma Locally / Online Now! - Anakin.ai, http://anakin.ai/blog/how-to-run-google-gemma-locally/
41. Run Free LLM like Ollama/Deepseek in your Local system - Medium, https://prabhjeetlearning.medium.com/1-agentic-ai-run-free-llm-like-ollama-deepseek-in-your-local-system-25386b581b20
42. Generate a chat message - Ollama documentation, https://docs.ollama.com/api/chat
43. Structured Outputs - Ollama documentation, https://docs.ollama.com/capabilities/structured-outputs
44. Ollama API: curl, Streaming, and the OpenAI-Compatible API | Easton, https://eastondev.com/blog/en/posts/ai/ollama-api-calls/
45. Best Small LLMs for Real-World Use: Your Recommendations?, https://www.reddit.com/r/LocalLLaMA/comments/1hj50f5/best_small_llms_for_realworld_use_your/
46. Gemma3 – The current strongest model that fits on a single GPU, https://news.ycombinator.com/item?id=43340785
47. Interpretation of Progressively Elliptical Commands in Smart Homes, https://arxiv.org/pdf/2606.18636
48. Next Gemma versions wishlist : r/LocalLLaMA - Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1jhwr2p/next_gemma_versions_wishlist/
49. GitHub - jekalmin/extended_openai_conversation: Home Assistant, https://github.com/jekalmin/extended_openai_conversation
50. r/homeassistant on Reddit: Built a Jarvis using Assist, the Extended, https://www.reddit.com/r/homeassistant/comments/17vd5sn/built_a_jarvis_using_assist_the_extended_openai/
51. CLAUDE.md - jekalmin/extended_openai_conversation - GitHub, https://github.com/jekalmin/extended_openai_conversation/blob/develop/CLAUDE.md
52. Built a voice interface for HA using local LLM (Ollama) - Reddit, https://www.reddit.com/r/homeassistant/comments/1pv5b0k/built_a_voice_interface_for_ha_using_local_llm/
53. Ollama Does Not Utilize Multiple Instances of the Same Model for, https://github.com/ollama/ollama/issues/9054
54. How Ollama Silently Ate 65GB of My VRAM (And How I Fixed It), https://dev.to/ljkunal/how-ollama-silently-ate-65gb-of-my-vram-and-how-i-fixed-it-22pf
55. Ollama memory usage higher than it should be with increased, https://www.reddit.com/r/LocalLLaMA/comments/1k627e8/ollama_memory_usage_higher_than_it_should_be_with/
56. non global CUDA_VISIBLE_DEVICES #9607 - ollama/ollama - GitHub, https://github.com/ollama/ollama/issues/9607
57. Multi-GPU LLM Inference on Linux: Setup, Load Balancing, and, https://linuxprofessional.ie/article.php?slug=multi-gpu-llm-inference-linux-setup
58. Making an Ollama Mesh with Nginx - DEV Community, https://dev.to/lancer1977/ollama-mesh-3l5j
59. Setup AI Code Completions In VS Code Using Ollama, https://krupeshanadkat.com/setup-ai-code-completions-in-vs-code-using-ollama/
60. The Complete Guide to Ollama: Run Large Language Models Locally, https://dev.to/ajitkumar/the-complete-guide-to-ollama-run-large-language-models-locally-2mge
61. Audio-Native Speech Recognition with a Frozen Discrete-Diffusion, https://arxiv.org/abs/2607.13013
62. OpenClaw/ClawdBot on Home Assistant - Custom Integrations, https://community.home-assistant.io/t/openclaw-clawdbot-on-home-assistant/981467?page=2
63. HomeBench: Evaluating LLMs in Smart Homes with Valid ... - arXiv, https://arxiv.org/pdf/2505.19628
64. and Environment-Aware Benchmark for Smart Home LLM Agents, https://arxiv.org/html/2509.24282v1
65. SIMUHOME:ATEMPORAL- AND ENVIRONMENT-AWARE, https://openreview.net/pdf?id=LCS1WsGvha
66. VoiceBench: Benchmarking LLM-Based Voice Assistants, https://www.semanticscholar.org/paper/VoiceBench%3A-Benchmarking-LLM-Based-Voice-Assistants-Chen-Yue/fea901c4c075dc268fb3f3124dec01443ae2cc2a
67. VoiceAgentBench: Are Voice Assistants Ready For Agentic Tasks?, https://openreview.net/forum?id=mi9q49AR3d
68. DESAMO: A Device for Elder-Friendly Smart Homes Powered ... - arXiv, https://arxiv.org/html/2508.18918v1
69. Universal Speech Token Learning via Low-Bitrate Neural Codec, https://arxiv.org/html/2503.12115v1