How we run models
Mother runs every model — chat, image, video, speech — inside workers: isolated runtime processes that load a model and serve it. You normally never manage workers by hand, but knowing how they work explains model load times, why some models need a moment to become available, and how your machine uses its GPU.
Workers and the WorkerPool
- A worker owns exactly one loaded model and its engine runtime.
- The WorkerPool decides where each worker runs. It places work by GPU capability and memory, starts workers on demand, and tracks which models are actively serving.
- When you send a request for a model that is not loaded yet, Mother starts or reuses a worker first — that is the pause you see on a "cold" model.
- Model downloads and preparation are separate from serving; a model can be fully downloaded but not yet loaded.
Model lifecycle
A model on your machine moves through a small lifecycle:
- Published — Mother offers the model in the Models catalog.
- Downloaded — weights are on local storage (an Owner can trigger this).
- Ready — a worker has loaded the model and it can serve requests.
- Retired — a newer revision replaces it; existing requests finish, new ones use the replacement.
LLMs
Chat and completion models follow the lifecycle above directly. When several hardware-specific builds of the same model exist, Mother picks the best published build that is actually ready on your machine — you just pick the model by name.
Image and video generation
Media models use the same workers and lifecycle. They can be heavier on startup: some engines precompile GPU-specific caches on first load, so the first generation after a boot can take noticeably longer than later ones.
Where models come from
- The preloaded catalog ships with the machine; new compatible models published by Mother appear in Models.
- Cloud models run on external providers and never load locally — see Cloud model providers.
- Custom models you deploy yourself — see Deploy → Custom models.