The Pod Was Ready. The Files Were Already Failing

Lazy container-image pulling promises to mount an AI model immediately and fetch its contents only when read. In measurements spanning artifacts from 2 to 140 gigabytes, eStargz and AWS SOCI made cold time-to-first-prediction nearly independent of image size: 16.9 to 17.6 seconds, versus 24.5 to 573 seconds for eager pulls. But the cost moved rather than disappeared. Reading a full 14-gigabyte model through the lazy mount took 105.3 seconds, slower than the 72.4-second eager pull it replaced.

The sharper result was operational. Sustained legitimate reads exhausted the snapshotter's finite node cache, and already-running pods began losing access to model files. At the first failure stage, one instrumented pod passed every Kubernetes-visible and application-level check for 196 seconds while the snapshotter logged real errors. Under heavier pressure, 67 to 94 percent of model files failed; restarting the daemon left stale file handles inside a pod still marked Running. The measurements expose a monitoring and capacity-planning hazard, not a claim that every lazy-pulling deployment will fail.