AIDiveForge field notes · Evidence recorded October 15–16, 2026
Our lms load command took 44.6 seconds while the engine reported 8.1 seconds loading the model. The two timers measured different boundaries.
Which startup are you timing?
A person waiting for a command to return, an engine opening a model and an application waiting for its first answer do not necessarily see the same duration. Our LM Studio test recorded llmster 0.0.25-1, the headless runtime, in an isolated container. We used the same small GGUF model as the other local-runtime tests and no GPU.
The lms load command took 44.6 seconds on a cold start. The engine's log reported 8.1 seconds loading the model. About 34 seconds, with an observed range of 33 to 36 seconds in the notes, passed between the load request and the engine starting. The log did not explain what it waited on. We cannot attribute that delay to a specific service or cause.
Keep these observations separate
| Boundary | Recorded observation | Safe interpretation |
|---|---|---|
| lms load command | 44.6 s | How long that command took in this cold test |
| Engine's internal model-load timer | 8.1 s | The engine's reported loading interval |
| Request to engine-start interval | About 34 s in the notes | An unexplained part of this startup |
| First generated answer | Not interchangeable with either timer | Requires its own measured boundary |
How a comparison can become misleading
It would be tempting to put the command duration beside another runtime's internal load timer and call the smaller number a speed win. That would compare different tasks. Our Ollama/LM Studio pair explicitly marks the mixed-boundary startup row as not comparable. The same discipline should apply to a chart, social post or procurement note.
The recorded runtime pair also included generation measurements under controlled settings. Those are a different experiment from command startup. If your application keeps a model loaded for hours, request throughput after warmup may matter most. If a worker restarts frequently, the complete restart-to-ready interval may be the useful quantity.
A practical startup log
If a command waits unexpectedly, preserve the interval before changing several settings at once. A hypothesis about the pause is useful only if the next test can distinguish it from another explanation. Our offline run blocked three LM Studio hosts and still served the prepared model; it did not reveal the cause of this startup pause.
- Record a timestamp before starting the service or issuing the load request.
- Keep the service log and the client command's exit status.
- Record when the engine begins loading and when it reports ready.
- Submit a fixed request and record the first successful response separately.
- Repeat cold and warm cases, clearly defining whether the model file and operating-system cache were already available.
What we would test next
We would repeat the same boundary measurements on dedicated hardware, capture the relevant logs and compare a prepared offline start with an online start. Until that experiment is run, describing the observed interval is more accurate than naming a cause.
For choosing a runtime, start with the event your users experience: a model becoming ready, a first answer or a completed batch. A precisely labeled timer is more useful than an apparently decisive comparison of unlike measurements.
Test conditions and sources
8-vCPU AMD EPYC 9354P cloud VM, each test limited to 3 cores and 10 GB RAM, no GPU, no internet (isolated Docker network). Local-model runs blocked external access. Hosted-model reruns explicitly allowed the Anthropic API. The machine was shared; generation ratios apply to their paired sessions and do not predict GPU or other-machine performance.
These are dated observations, not a claim about the latest release or every machine. Recommendations and example procedures are our interpretation of the recorded results.
- Our LM Studio / llmster test and startup notes
- Our Ollama test for separately labeled startup measurements
- LM Studio documentation