Telling users the truth about ingest time

In short: a tool that runs local models on a laptop is slow at bulk work, and a large photo import can run for hours, often overnight. I put that sentence near the top of the setup guide, before the install command, because a user who knows it in advance leaves the import running, and a user who finds out halfway decides the software is broken.

The number nobody wants to write down

Every photo in an import is looked at by a vision model running on the laptop's GPU. On a laptop with the default local model, that vision call is most of the cost of the import. Text documents are cheap. Photos are not.

The tempting move is to hide that. Show a progress bar, keep the copy upbeat, let people discover the duration on their own. I think that is the wrong call for a tool people point at a decade of their own life. So the setup guide says plainly how long a bulk import can take, before anything about installing.

Those are rough ranges on a laptop with the default local model, not benchmarks. I give ranges on purpose. Machines differ, libraries differ, and a precise figure would be wrong for almost everyone who read it.

A user who expects to wait overnight is patient. A user who expected twenty minutes is filing a bug.

What makes the honest number bearable

A long import is only acceptable if three other things are true, and the guide says each of them right after the table.

• It resumes. Ingest picks up safely after a stop or a restart, so leaving it running and closing the tab is fine. Without that sentence, an overnight estimate is a threat. With it, it is a background job.
• It knows about bursts. Burst shots and near-identical photos skip their own vision call and inherit the understanding of the shot they duplicate. A camera burst costs roughly one call instead of one per frame.
• You can trade money for time. Pointing the photo-understanding step at a hosted model instead of the local one trades money for wall-clock time, and removes the hardware floor entirely.

The two settings that move it

The other thing a user can do is make the GPU busier. The app can send the local model runner more than one request at a time, but the runner only serves them in parallel if it is told to.

# Host side: how many requests the model runner serves at once.
runner:
  parallel_requests: 2

# App side: how many requests ingest sends at once. Keep them equal.
ingest:
  workers: 2

Saying when not to use it

The hardest honest sentence in the guide is not about time. It is about machines that should not try. On a CPU-only machine, a single photo caption takes minutes instead of seconds, which makes local vision too slow to be practical.

I could have written "slower on older hardware" and let people find out. Instead the guide says: if your machine is CPU-only, do not use the local vision model. Add a hosted key, or accept a text-only understanding of photos from the filename, metadata and any text available. A slow import is a trade. An import that never realistically finishes is a broken promise.

The same section is plain about memory. The containers, the tracing stack and the local model each want their share, and together they set a floor that rules out the smallest laptops. None of that is pleasant to read. All of it is cheaper to read before installing than to discover after.

Write your own "how long will this take"

If your product does anything slow on the user's own machine, write that section now. Three rows of realistic sizes with honest ranges. One sentence on whether it is safe to close the tab. The one or two settings that actually move the number. And one sentence about who should not try at all. Put it above the install command, not in a troubleshooting page nobody opens until it is too late.