In this article
A restarted process does not imply cold storage; record cache history and each preparation layer explicitly.
Cold is a condition that needs a definition
Restarting a model worker does not necessarily make every part of its loading path cold. The operating system may retain file pages, the artifact may already be local, and another layer may preserve compiled work. A second start can therefore be faster without any change in SSD capability or GPU performance.
The Linux virtual-memory guide explains page-cache reclamation and the consequences of deliberately dropping caches. Treat cache state as an experimental condition to document, not as a reason to clear a shared server’s caches whenever a benchmark looks inconsistent.
Separate the layers of preparation
Record whether the artifact is already present, whether the operating system recently read its files, whether the engine process is new and whether the model is already resident on the device. Keep compilation or kernel-cache preparation as another explicit condition where applicable. These states can change independently.
A useful test table names the intended scenario instead of using a single cold flag. For instance, local artifact with a new process is different from a fresh artifact download, and neither necessarily describes an uncached storage read. Explain which conditions were observed and which were only assumed.
Observe the actual loading sequence
Capture worker start, artifact access, file reading, device preparation and readiness using defined timing boundaries. Include concurrent activity and host memory pressure because they can change cache residency. A successful process restart is not proof that all file data was fetched from the device during the next run.
The fio reference shows why buffered and non-buffered I/O represent different test paths. A separate storage baseline can help interpret the loader, but changing fio’s cache mode does not change how the model engine reads its files. Keep the benchmark and application observations connected without pretending they are identical workloads.
Compare scenarios without disturbing neighbors
Use an isolated, approved environment for experiments that require a tightly controlled initial state. On an occupied node, retain observed cache history and report its limits rather than forcing a system-wide cache eviction. The preparation method itself belongs in the result because it can alter CPU work, filesystem metadata and the traffic seen by other services.
An illustrative series could contain a first local load and several later restarts using unchanged files. If later starts become faster, examine storage-phase timing and engine preparation separately. The series supports a warm-path comparison; it does not automatically quantify the operating-system cache’s contribution or establish a universal cold-start time.
Preserve both deployment scenarios
A production restart with warm host caches and a newly provisioned node can both matter operationally. Report their distributions separately, with repeat counts and preparation conditions. Do not publish only the fastest restart as the time needed to introduce new capacity.
The final artifact should state artifact locality, process state, observed cache history, device residency, timing boundaries and unresolved uncertainty. It gives an operator a reproducible scenario rather than a vague cold-loading number and helps distinguish storage work from the rest of model readiness.
When the operating system or engine changes the preparation conditions, retain a separate series so comparisons do not silently combine different ways of preparing the node.