runpod: size the container disk for the weights before renting
The failure this prevents was observable, not hypothetical: a pod boots, pulls the image, starts downloading, fills its 40 GB disk and dies at load_timeout_s having paid for every minute. The size of a HuggingFace repo is one metadata call, so it is asked before the pod exists, and the disk is grown to fit — weights plus ~25 GB for the unpacked image and the download cache. It counts what a load will actually FETCH, not the whole repo. SDXL's repo is 77 GB, of which a diffusers load pulls 28: the rest is the same weights again as Flax .msgpack, legacy .bin and ONNX exports. Sizing to the repo would have rented 100 GB for a 28 GB model. An explicit container_disk_gb that is already large enough is respected. And with a network volume attached the weights land there, not on the container disk, so the disk stays at its configured size — which is the point of the volume. Co-Authored-By:Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY
Showing
Please
register
or
sign in
to comment