Right move, wrong reason
The house has two computers that matter here. One is a small always-on server that runs the cameras and the automations. The other is a workstation across the room. The vision models lived on the small server, and it was struggling.
My question was whether we should move the models to the workstation, since it has more memory. Moving them was the right call. Memory was not the reason. For this kind of model the limit is the graphics card: memory decides whether a large model fits, and the graphics card decides whether it is fast.
So the real question was which machine had the better graphics card, and one command answered it. The workstation had a current card with 16 GB. The server had an older laptop card with 6 GB. That single fact removed the riskiest item from the plan, a delicate reconfiguration of the old machine, because there was no longer any reason to attempt it.
Chosen by bake-off, not by reputation
There was a newer vision model that might replace the two older models we were running, one for images and one for text. Rather than argue from reviews, we ran it on real snapshots from our own cameras. I looked at the images first, so that there was a known right answer before the model gave its own.
- A vehicle: described correctly, including that the plate was not visible.
- A person: clothing and direction described correctly, plus a red object in the right hand, a detail the old model had missed.
- The daily written summary, the second model's job: done cleanly in about four seconds.
Each image took under three seconds once the model was loaded. One model could do both jobs, so the decision made itself.
Time from camera event to written description
Reversible first, irreversible last
The order of the work mattered more than any single step.
- Make the model available on the workstation, reachable only by the one machine that needs it.
- Point the house at the new location. This is a settings change and can be reversed in a minute.
- Verify by outcome, not by the absence of errors: a test message, a test image, and then a real camera event, start to finish, in about six seconds.
- Only then delete the old models from the server, the one step that takes real time to undo.
Deleting them freed roughly 10 GB on a machine that had been short of space, which closed a second problem we had been carrying.
The tradeoff, written down
Nothing here was free. Vision now depends on the workstation being switched on. We accepted that for two reasons that are recorded with the change: the workstation runs all day in any case, and the system fails gently. If the workstation is off, the cameras, the recordings and the automations carry on, and the vision step reports that it is unavailable instead of inventing an answer.
What I took from it
- Check the mechanism, not only the conclusion. A right answer held for the wrong reason will mislead the next decision.
- Choose between tools on your own data, against answers you established first.
- Prove the new path before deleting the old one.
- Write down the tradeoff you accepted, so that nobody rediscovers it as a surprise.
"Great things are not done by impulse, but by a series of small things brought together."