Do not debug AI on an underpowered SBC supply

So no, it isn't the quantized model misbehaving. It's the USB hub sagging the moment inference starts pulling sustained current, and half the thread argues tokens per second, not whether anyone put a multimeter on that rail. Inference isn't a spike workload, it holds CPU, storage, and USB near their ceiling for the whole run, and that finds every marginal cable and bargain adapter in the chain. Voltage stability isn't a footnote, it's the precondition. A board that browns out mid-inference gives you no benchmark, and the symptoms, random resets, corrupted storage, a model that "sometimes just stops", look like software bugs until somebody checks the supply.

Write the job in four lines before you shop for hardware

"Add AI to the camera" tells you nothing testable. "When a parcel sits in the porch zone for a fixed number of seconds, fire one local notification with a thumbnail" gives you the event, input, output, and deadline, and shows what doesn't need a model at all. Most of that porch example is a zone check and a debounce timer; the model earns its place at one narrow decision, not the whole pipeline. Skip it and you'll buy accelerator hardware to solve what a cron job already handled. The appliance matters as much as the board: storage, supply, cooling, OS, radio support, whatever consumes the output.

Measure the wall before you measure the model

Once the job is written down, the first experiment isn't accuracy, it's current. Budget the board plus every peripheral, NVMe, accelerator, radio dongle, fan, use the supply the vendor recommends, not whatever barrel adapter was in the drawer, and check the logs for undervoltage events. Test with the room you actually have, not a demo clip: your microphone, your camera angle, your sensor, your language, your network. Evening light changes what the camera sees, a television nearby changes what the microphone hears, a warm cabinet changes thermals, a busy Home Assistant database changes latency more than any model revision will. Accuracy is the wrong bar for anything unattended, though: check for duplicate notifications, reboot survival, reconnection after the network returns, and a visible state with a manual override for when the model goes quiet.

The model doesn't get to hold the deadbolt

The failure I keep seeing blamed on a model or a kernel is usually a reset caused by cable loss dressed up as a mystery. Separately: generative output is fine at interpreting a request, summarizing a history, ranking a few options. It has no business being the only layer between an event and a lock, a heater, an alarm, a valve, or a battery. Ranges, permissions, timeouts, confirmations, interlocks belong in deterministic code that doesn't care what the model said. Camera text, calendar entries, web pages, MQTT payloads, voice transcripts: treat it as untrusted input, or a summarization bug becomes a safety bug.

Local inference is not the same as no copies

"Runs locally" answers one privacy question, whether anything left the building, and skips the rest. Recordings, event logs, thumbnails, backups, and a remote dashboard can all retain what the camera saw, long after the model made its call. Decide up front what gets collected, how long it lives, who can pull it, and what happens while you're debugging. The most private frame is the one the camera never records. Second best is the one thrown away the moment the decision gets made.

Run it until the enclosure stops changing temperature

Treat the thing as an appliance, not a demo you SSH into when curious. Run it under a service manager or a pinned container, keep configuration separate from the model files, and give it a health check that proves the function, not that a process holds a port open. Let it run long enough for the enclosure to reach a stable temperature and measure power at the wall with every peripheral attached: a board that throttles, swaps, or corrupts storage under sustained load isn't finished, whatever one good inference run looked like. Hardware for local LLMs is worth reading first: the board is one part of an appliance that has to survive a cupboard for a year, and the same resilient AI architecture instinct applies to a windowsill node: when the model goes away, automation should get dumber, not stop.

Fix the power supply before you touch the software. That's the one rule I'd keep.