How to run Qwen on a Mac for smart home control

Status note, Q3 2026: this is a local Qwen-on-Mac setup for Home Assistant control through Ollama. It is not the Apple/Siri/Qwen China setup path that has been muddying searches for “qwen ai mac setup.” If your goal is to make a Home Assistant light, switch, thermostat, or scene respond to a local model running on an Apple Silicon Mac, you are in the right recipe.

The operational verdict is yes, with strings attached. Qwen can be run locally on a Mac through Ollama and used by Home Assistant as a conversation agent, but Home Assistant’s device-control path is officially experimental, only models with tool support can control Home Assistant, and Home Assistant recommends exposing fewer than 25 entities to reduce mistakes from smaller local models. That entity count is guidance, not a magic safety line. The work is in choosing the right Qwen tag, binding Ollama correctly on the LAN, and keeping the exposed Home Assistant surface boringly small. [1]

The setup path, before touching the terminal

The clean chain is simple enough to draw: Ollama serves Qwen on the Mac; Home Assistant connects to that Ollama server through its official integration; the integration is selected as a conversation agent; only selected Home Assistant entities are exposed for control. Home Assistant’s Ollama integration added a local conversation-agent route in Home Assistant 2024.4, and Home Assistant’s analytics show it in use by about 2.2% of active installs, but the control step remains the part to treat carefully. [1]

Pick the Qwen model for tool calls, not for bragging rights

For this recipe, start with qwen3:8b or qwen3.5:9b-mlx, then re-check the Ollama library page before you put the setup into daily use. Ollama lists Qwen3 with tool support across a wide size range, and Qwen3.5 as the newer generation with tool support, large context windows, and tags spanning from small local models to very large ones. [2][3]

That “tool support” line is not decorative. A normal chat model can answer “turn on the kitchen light” with a polite sentence. A tool-calling model can return a structured request that Home Assistant can route to an exposed entity. For smart-home control, a slightly older or smaller model that reliably calls tools is more useful than a newer model that only talks fluently.

The reason to start at 8B or 9B is not that these are universal sweet spots. They are practical starting points: small enough to be plausible on consumer Apple Silicon, large enough to give the tool-calling layer a fair shot, and currently represented in Ollama’s Qwen library. If your Mac has a tight memory envelope, treat the model size decision the same way you would for any local LLM: RAM comes first, then latency, then ambition. For a broader memory-envelope discussion, see NestGrid’s local LLM hardware requirements guide.

ollama pull qwen3:8b
# or, if the tag is still present and appropriate for your Mac:
ollama pull qwen3.5:9b-mlx

Do not skip the tag check. The Qwen/Ollama landscape is moving quickly enough that an article dated Q3 2026 should not pretend the tag list is frozen. If a newer Qwen tag appears, the first question is still the dull one: does that exact tag support tools in Ollama?

Apple Silicon performance context, with the vendor label left on

Apple Silicon is not a novelty target for local LLMs anymore. Ollama’s March 30, 2026 MLX preview post reported a vendor-published benchmark for Qwen3.5-35B-A3B at 1851 tokens per second prefill and 134 tokens per second decode on Apple’s M5-series GPU Neural Accelerators, with more than 32GB of unified memory required for that specific benchmark. That is useful context for why a Mac Mini, Studio, or MacBook can be a serious local-LLM host; it is not a promise that your smaller Qwen tag, your memory pressure, or your Home Assistant prompts will feel the same. [4]

Run Ollama on the Mac

Install Ollama on the Apple Silicon Mac, pull the Qwen model you chose, and verify that the model responds locally before adding Home Assistant to the chain. The first test is intentionally plain: if the Mac cannot run the model from Ollama, Home Assistant is not the problem yet.

ollama run qwen3:8b
# Test prompt inside Ollama:
# What are you, and do you support tool use?

A local text response only proves that Ollama is serving the model. It does not prove Home Assistant control. Keep that distinction clean while debugging. Chat success, tool support, and device control are three different checkpoints.

If Home Assistant is not on the Mac, bind Ollama to the LAN

This is the step that causes a lot of otherwise-good setups to look broken. If Home Assistant runs on a separate box, container host, NAS, VM, Home Assistant Green, or Home Assistant Yellow, it cannot connect to an Ollama server that is listening only on the Mac’s localhost. Home Assistant’s Ollama documentation and community setup notes both point to the same requirement: expose Ollama on 0.0.0.0 when another machine on the LAN needs to reach it. [1][5]

• If Home Assistant runs on the same Mac: point the integration at the local Ollama host.
• If Home Assistant runs elsewhere: configure Ollama on the Mac to listen on 0.0.0.0, restart Ollama, and point Home Assistant at the Mac’s LAN address.
• If it still fails: check the Mac firewall, the Home Assistant host’s network route, and whether Ollama was actually restarted after the binding change.

Do not expose Ollama to the public internet for this recipe. The target shape is a local Home Assistant host talking to a local Mac over a trusted LAN. If you need remote access, solve that separately with the same caution you would apply to any service that can influence your home.

Add Ollama to Home Assistant and make it the conversation agent

Once Qwen responds through Ollama and the Home Assistant machine can reach the Mac, add the official Ollama integration in Home Assistant. In the integration setup, use the Mac’s Ollama address and select the Qwen model tag you pulled. Then configure the integration as the conversation agent for Assist. This is the official route; do not build the first version of this recipe around an unofficial bridge unless you already know why you need one. [1]

1. In Home Assistant, add the Ollama integration.
2. Enter the Ollama host that Home Assistant can actually reach.
3. Select the exact Qwen model tag running in Ollama.
4. Set the Ollama-backed assistant as the conversation agent for Assist.
5. Enable Home Assistant control only after you have trimmed the exposed entities.

Home Assistant’s documentation is explicit about the important boundary: controlling Home Assistant from the Ollama conversation agent is experimental, and only models that support tools can do it. If the model does not call tools, it may still answer questions, but it is not a working smart-home controller. [1]

Expose fewer devices than you think you need

Entity exposure is not cleanup after the fun part. It is part of the setup. Home Assistant recommends exposing fewer than 25 entities when using smaller local models because reducing the choice set reduces mistakes. Again, fewer than 25 is not a hard rule or a guarantee; it is the official direction of travel. [1]

A good first exposure set is not “everything in the house.” It is the devices you can name unambiguously and would not panic about if the assistant selected them incorrectly during testing.

Names matter here. “Kitchen pendant,” “kitchen counter,” and “kitchen table lamp” give the model a better surface than five entities called variations of “light.” If your Home Assistant instance has years of old integrations, helper entities, disabled rooms, and duplicate device names, fix exposure before blaming Qwen.

A restrained first test

Start with commands that reveal whether tool calling is actually happening:

• “Turn on the desk lamp.”
• “Is the living room lamp on?”
• “Set the hallway light to off.”
• “What devices can you control in this room?”

Keep the first test session text-only inside Home Assistant Assist. Voice adds microphones, wake words, speech-to-text, text-to-speech, room noise, and timing. Those are real projects, but they are not useful variables while you are still proving that Qwen can call the right Home Assistant tool.

Where community reports fit

Community reports are encouraging, especially around Qwen3 and Qwen3.5 behavior with Home Assistant tool calling. The closest current community recipe to reproduce against is the Home Assistant forum blueprint on using Ollama on Apple Silicon, and its value is practical: it shows another user’s wiring, assumptions, and failure points. It is still user testimony, not a replacement for Home Assistant’s experimental label or for your own entity-exposure discipline. [6]

If you are comparing model families rather than following this Qwen recipe, NestGrid’s Qwen smart-home assistant overview is the better place for ecosystem context. If you want a different cloud or agent route into Home Assistant, compare it against the Anthropic AI agents setup rather than trying to turn this Ollama recipe into every possible LLM architecture.

Known limits worth accepting before daily use

The first limit is the experimental Home Assistant control path. Treat working commands as a successful constrained setup, not as a universal compatibility claim. Test entity classes one at a time, especially if the exposed surface includes climate controls, scripts, or scenes that touch multiple devices.

The second limit is model output style. Qwen3-family models can expose thinking-style behavior depending on the model and runtime settings, and those thought tags or reasoning traces can pollute replies in an assistant UI. If control works but replies look messy, that is a prompt/runtime cleanup problem, not necessarily a device-control failure. It deserves its own troubleshooting pass rather than more exposed entities.

The third limit is voice polish. Whisper.cpp for speech-to-text and Piper for local speech replies can extend this into a fuller local voice assistant, but do that after the text conversation agent can control a small device set reliably. Voice is an interface layer on top of the control chain, not proof that the chain works.

Working judgment for Q3 2026

Local Qwen-on-Mac smart-home control is viable today when it is kept narrow: Apple Silicon Mac running Ollama, Qwen tag with tool support, official Home Assistant Ollama integration, conversation agent configured, LAN binding fixed when Home Assistant lives elsewhere, and a deliberately small exposed-entity set. That is enough to make this a usable recipe. It is not enough to call local private AI home control “solved” for every house, every Mac, or every Qwen tag.

References

1. Ollama — Home Assistant
2. qwen3 — Ollama
3. qwen3.5 — Ollama
4. MLX — Ollama Blog, March 30, 2026
5. Linking local Ollama with Home Assistant — thibmaek.com
6. Blueprint on AI: using Ollama on Apple Silicon — Home Assistant Community