Sizing a local AI camera stack: model, RTSP, Docker, latency, cost
A five-part sizing model for local vision inference: camera source, model coverage, Docker serving, latency, and continuous power cost.

The camera source limits the stack
You are deciding whether a local vision model can watch a camera feed continuously without a cloud dependency. The trade-off is model coverage against continuous power: more species and lower latency raise watts, and the arithmetic is watts times hours times utility rate. A small box and a modest rate make the stack worth it; a large rack does not.
The stack has five parts:
- camera source
- model coverage
- serving runtime
- latency budget
- continuous power cost
Pick the camera source first. BirdNet-Go used three existing security cameras and their microphones for bird detection in one DIY build. Its camera ingestion path used RTSP stream URLs from IP cameras. The source is ready when the stream is reachable, the frame rate is stable, and audio exists only if the model needs it.
Start with cameras you already own. Reusing existing hardware keeps the initial outlay low and makes the power calculation easier to defend. Cameras that cannot expose a stable stream need fixing before you add model complexity. Check the stream before you add an accelerator.
Model coverage sets the base cost
Choose the model coverage you actually need. BirdNet-Go's model gallery added Google Perch v2, which can detect 14,795 species, compared with 6,000 species for BirdNET 2.4. Wider species coverage is not automatically a better fit for a local camera. It raises inference load and can move the same hardware into a higher power state.
Compare the model against the site, not against a benchmark list. Species-rich models can be the wrong choice if the local habitat uses a small subset of it. Run the candidate model on a short sample of local clips before you commit to local inference. Accuracy that is useless at the frame rate you can afford turns the larger model into a cost. Use test clips from the same time of day and the same lighting conditions. Finish with a written species list that matches the site.
The serving runtime is the smallest component
Wrap the model serving runtime in a container. BirdNet-Go ran as a Docker container in a homelab. A working container has an image, a restart policy, and a log you can tail.
Treat the container as the unit of operations. It should start, stop, and restart without manual edits. Store model weights, configuration, and logs in separate paths so you can swap models without breaking the camera pipeline. A clean runtime helps you compare model choices under the same serving conditions. Record the container's power draw under load so the cost model uses measured watts, not vendor claims.
Latency and power share the same budget
Set the latency budget from the event you care about. A camera-trap study found computer vision could miss up to 10% of pairwise ecological interactions. In its community-level analysis, only 3 of 344 unique pairwise interactions were missed. Do not target the lowest possible latency on a weak CPU; you will use power and still miss events.
Measure the whole path, not just the model. Ingestion, preprocessing, inference, and output all consume time and power. Rare events can tolerate a slower loop on edge hardware; frequent events need a tighter loop. Log the interval between event and detection so the budget is visible in the same place as the power draw. Make the log timestamped so you can compare detection delay against the event time. The budget is valid only with a frame interval that catches the event, a confidence threshold you can defend, and a log of missed detections.
Price the continuous power cost before you celebrate. Separate the recurring cost from the upfront cost. Hardware and installation are upfront; electricity is the recurring line that grows over time. Use the measured watts from the container, the operating hours, and the utility rate.
BirdNet-Go ran on local hardware without cloud services, API calls, or a monthly fee. Low utility rates do not justify a stack when the model forces a high-power device. High rates make a smaller model with lower coverage the better product decision. Write the recurring line down before you chase a false positive.