There Was No Pre-Trained Model for My Sump Pump

A model zoo is a public shelf of finished neural networks. You browse it, you find something that does roughly what you want, you download the weights, and you are ninety percent of the way to a working system without training anything yourself. There are thousands of them, free, and for a lot of problems the shelf genuinely works.

There is nothing on that shelf for a sump pump in a basement in upstate New York.

Nobody has published a model that detects a worn bearing in a residential circulator from a fifteen-dollar smart plug. Nobody is going to. The market for that model is me. So when I built the thing that watches my pump, I could not start where a competent engineer would prefer to start, which is with something that already works.

I have been quietly a little embarrassed about that. This week I read a piece arguing that starting from the shelf is the mistake.

The Argument Against the Shelf

A company called ModelCat published a piece titled Why Model Zoos Fall Short in Production AI, which the Edge AI and Vision Alliance reprinted this week. It is vendor content and they have a product behind the argument. It is also, in the parts that matter, correct.

The claim is that model zoos are excellent for research and quietly terrible for deployment, for four reasons.

The reusability is partly an illusion. A zoo model was validated under conditions that are not your conditions. As they put it:

Even well-performing models often require significant modification to function within a specific environment.

The workflow is not the advertised one. The promise is select, fine-tune, deploy, in that order, once. What actually happens:

What was intended to be a streamlined workflow becomes a cycle of iteration.

The benchmarks measure the wrong thing. Zoo models compete on accuracy against standard datasets. They do not compete on fitting in two megabytes of RAM, or answering in under a second, or staying reliable when the input is a badly lit basement instead of a curated test set.

And the starting point itself is backwards. When you begin with a model, every constraint you have becomes something you react to. The model needs a GPU, so now you need a GPU. The model expects clean labeled data, so now you are labeling data. The model runs in the cloud, so now the customer's network is a dependency and their basement has a monthly bill attached.

What Starting From Constraints Actually Looked Like

I did not choose this method. I arrived at it by having no alternative, which is a less flattering story but a more useful one, because it means I can tell you exactly what it cost.

The constraints came first because they were the only things that existed:

• One pump, in one basement, with one failure mode I actually cared about.
• One sensor, a smart plug that reports power draw, because I was not going to drill into a working pump or void anything.
• No cloud, because a monitoring system that stops working when the internet does is not a monitoring system, it is a subscription.
• Hardware already in the house, because the entire premise is that this has to be affordable for a building that cannot justify a facilities contract.
• No labeled data, because my pump had not failed yet, and the whole point was to catch the first time.

Look at that list and notice how much it decides before any modeling happens. One power signal at a modest sample rate rules out most of the interesting architectures immediately. No labeled failures rules out supervised classification entirely. No cloud rules out anything that will not run on a small board in a basement.

By the time I got to the question of what should the detector actually be, the constraints had already answered most of it. What survived was small: learn what a normal cycle looks like on this specific pump, then watch for the shape of that cycle changing. Run duration, current draw, the interval between runs, how those drift together over weeks.

That is not an impressive model. I could not put it on a shelf for anyone else to download, because it is not transferable — it is fitted to one machine in one basement, which is precisely why it works there.

The Failure Mode This Avoids

I want to be specific about what the alternative looks like, because I have watched it happen to other people's projects and the shape is always the same.

Someone at a small company decides to do predictive maintenance. They find a well-regarded anomaly detection model, or a vibration classifier with a nice paper behind it. It looks great. Then:

Every one of those is a reasonable requirement in isolation. Together they turn a monitoring project into an infrastructure project, and the infrastructure project is where it dies — not dramatically, just quietly, eight months in, when the person driving it moves on and nobody can explain what it was for.

The ModelCat piece cites a Gartner prediction that organizations will abandon sixty percent of AI projects unsupported by AI-ready data through 2026. I would not lean on that number; it is an analyst forecast quoted inside a marketing post, which is two steps removed from anything measured. But it points at something I think is real, and the mechanism is not mysterious. Projects do not usually fail because the model was bad. They fail because the model brought a list of requirements with it and the list was longer than the budget.

The Same Argument, From the Silicon People

Here is the part that convinced me this is a genuine shift and not one vendor's positioning.

On the same day, the same publication ran a talk summary from Imagination Technologies, the chip design company, about a technique they call self-compression. James Imber, their Director of Research, presented it at the Embedded Vision Summit in May.

Some background on why this matters. To run a neural network on a small cheap device, you usually have to shrink it, and the standard way to shrink it is quantization: take a network whose numbers are stored at full precision and store them with fewer bits instead. Eight bits instead of thirty-two. Sometimes four. The model gets dramatically smaller and faster, and it gets a little bit worse.

How much worse is not a hypothetical. Last week a company called Quadric published exactly this comparison for a small speech recognition model: the full-precision version made errors on 7.54% of words, and the eight-bit version made errors on 8.92%. That gap, about one and a third percentage points, is the price of compression.

And notice when that compression happens. The network is trained at full precision, learns all its weights assuming it will have all those bits available, finishes, and only then gets told it is going to run on eight. It spent its entire training being wrong about the machine it would live on.

Self-compression's premise is that this sequence is the problem. Instead of picking a precision and squeezing the finished model into it, the network learns its own bit depths during training — allocating more precision to the layers that need it and less to the layers that do not, while it is still able to adapt.

But look at what the idea is. It is letting the deployment budget reach backward into training, so the model is shaped by the device it will run on instead of being adapted to it afterward.

That is the same sentence as the model zoo argument. One is about software workflow and one is about numerical precision, they were written by companies with nothing to do with each other, and they landed on the same day saying: the deployment should shape the model, not the other way around.

What This Is Worth to Someone Who Owns a Building

You do not care about bit depths. Here is the part that translates.

When you get a proposal for anything with AI in it, there is a question worth asking that most people do not, and it is not a technical question. It is: what does this system need from me in order to work?

Not what it does. What it needs. A network connection? An electrician? Someone to label data? A year of history before it says anything useful? A cloud account that bills monthly forever? Physical access to modify equipment that currently works?

Add those up before you look at the capability claims, because that sum is the actual project, and it is where these things fail. A modest system with a short list beats an impressive system with a long one, every time, in a building without a facilities department.

My own list, for what it is worth, is one outlet and about twenty minutes. That is not because I am a better engineer than the people selling the impressive systems. It is because I started from a basement instead of from a shelf, and the basement kept saying no to things.

The Thing I Would Tell Myself Two Years Ago

The embarrassment was misplaced. Not having a pre-trained model available was not a handicap I worked around. It was the constraint that kept the project small enough to finish.

Every shortcut I could not take was also a dependency I did not acquire. No cloud model meant no network dependency. No labeled dataset meant no waiting for failures. No GPU meant a system cheap enough that a twelve-unit building can actually pay for it, which is the only version of this business that exists.

The shelf is genuinely useful when your problem looks like everyone else's problem. Small buildings do not have that kind of problem. Every one of them is a specific machine, in a specific room, with a specific way of dying, and the thing that watches it has to be built for that room or it is decoration.

It turns out there is a name for building it that way. I just did it in the wrong order to have known.