Choose Raspberry Pi memory for the whole home stack

The board goes in, Home Assistant comes up clean, MQTT joins it, and someone bolts a small model on top for camera detection because the cores are sitting idle. It runs fine for weeks. Then a nightly backup job fires, memory pressure spikes for the first time, and the whole stack stalls into swap while someone's standing in a dark hallway waiting on the porch light to notice them. Nobody planned for that moment. The box was sized to boot a model cleanly once. Everything after that was optimism.

Here's the constraint that governs this, and it has nothing to do with tokens per second: whatever memory the board carries has to cover the operating system and the services running every day before a model claims a single megabyte of headroom. Picture a Pi 5 carrying Home Assistant, MQTT, and a small inference service at once, drawing from one pool, unlike a homelab LLM server that gets an entire rack and its own breaker. The board's name on the box matters less than everything built around it: storage, power supply, cooling, the OS, radio or accelerator support, and the downstream service that uses the model's output. A model running once from a shell prompt is several decisions away from a household feature. And if you're choosing between a board like this and something with real VRAM, that's a different calculation, not this one.

write the job in four lines before you shop

Skip the spec sheet: write down the event, the input, the output, the deadline. "Add AI to the camera" tells you nothing. "A parcel sitting in the porch zone for twenty seconds triggers one local notification with a thumbnail" is something you can test, and it tells you which parts never needed a model.

Once you have that, measure the board's existing baseline, add model weights and runtime overhead on top, and leave headroom for the update still to come. Test against the room you have: the microphone, the camera angle, the network. Edge deployments amplify ordinary variation: evening light, a television in the background, a warm cabinet, a flaky cable, or a busy Home Assistant database can move your numbers more than a model upgrade will. Keep a running record as you go:

• board, OS, power supply, cooling
• model artifact and runtime version
• the real input set and the action it should trigger
• cold latency, warm latency, sustained rate
• memory, temperature, wall power
• what happens on a false trigger, a missed one, and recovery

Accuracy alone won't tell you if this survives a household. Check for duplicate notifications, a clean comeback after reboot, reconnection once the network drops, and what happens when the inference service isn't there. Somebody needs a manual way to turn the light on without knowing which container died.

the model doesn't get a vote on the lock

Generative output is fine for interpreting a request or ranking options. It has no business being the only thing standing between a person and a lock, a heater, an alarm, a valve, or a battery. Permissions, timeouts, confirmations, and interlocks belong in deterministic code, full stop. Camera text, calendar entries, webpages, MQTT payloads, and voice transcripts all count as untrusted data, not instructions.

Privacy needs the same full-path treatment. Running inference locally stops one upload, but the recordings, event logs, thumbnails, backups, and remote dashboards can still leave copies you forgot about. Decide up front what gets kept, for how long, and who can pull it during debugging. The frame the camera never captures is the private one; the one discarded right after a bounded decision is next best.

Then run it like an appliance, not a demo you're proud of: a service manager or a small pinned container, configuration kept separate from the model files, a health check that proves the function, not just that a process owns a port, and backups of controller state plus a known-good image for nodes installed somewhere inconvenient. Run it long enough for the enclosure to reach thermal equilibrium, and measure power at the wall with the normal peripherals attached, because a board that throttles, swaps, corrupts storage, or monopolizes your home-automation host isn't ready, no matter how good its best-case inference looked. Size for the busiest ordinary hour, not an empty dashboard. When the model goes away, the automation underneath it should get dumber, not stop.

The part I still don't have a clean answer for is the update itself: holding a second copy of a model or a container image in memory during a swap, on a board that was already tight before the new version showed up. I over-provision for it and call the extra headroom a tax I haven't found a way around.