[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"doc-detail-83978-en":3,"doc-seo-83978-105":29,"detail-sidebar-cat-0-en-105":83},{"code":4,"msg":5,"data":6},0,"success",{"doc_id":7,"user_id":8,"nickname":9,"user_avatar":10,"doc_module":4,"category_id":11,"category_name":12,"doc_title":13,"doc_description":14,"doc_content":15,"file_id":16,"file_url":17,"file_type":18,"file_size":19,"view_count":20,"is_deleted":4,"is_public":20,"is_downloadable":20,"audit_status":20,"page_count":21,"language":22,"language_code":23,"site_id":24,"html_lang":23,"table_of_contents":25,"faqs":26,"seo_title":13,"seo_description":14,"update_tm":27,"read_time":28},83978,7971461740886,"Theodore","https://ap-avatar.wpscdn.com/davatar_3d24733baf745e90a7e4bdd5f77d97b2",8,"Research & Report","Bounded Memory Parallel Image Pulling for Large Container Images","AI/ML training and inference increasingly use container images that must be downloaded before workloads start, placing cold image pull on the critical path during scaling and host updates. For large GPU images (31–48 GiB), startup time is dominated by runtime reassembly and unpacking, while in-memory ordered chunk buffering grows with image size. This backlog can exhaust host RAM shared with CUDA and model weights, triggering OOM-killed daemons. Disk-Backed Parallel Pull (DBPP) writes chunks directly to disk offsets, bounding memory and improving peak usage without throughput loss.","Bounded-Memory Parallel Image Pulling for Large  \nContainer Images  \nSri Saran Balaji Vellore Rajakumar, Henry Wang, Ankur Singh, James Thompson  \nAmazon Web Services  \nSeattle, USA  \narXiv :2607 .05596v 1 [ cs .DC] 6 Jul 2026  \nAbstract—AI/ML workloads increasingly run as containers, where a container image must be downloaded to the host before the workload can start. This cold image pull lands on the critical path whenever a training or inference job scales up ora host is updated, and for GPU workloads it has become the dominant component of startup time as AI/ML images reach 31–48 GiB compressed. We present Disk-Backed Parallel Pull (DBPP), an alternative to the in-memory ordered reassembly used by containerd 2.2, the upstream container runtime. containerd splits layers into chunks fetched concurrently over [HTTP range](HTTP range)[ ](HTTP range)requests, but chunks that arrive out of order accumulate in the runtime heap until a sequential consumer drains them in order. This backlog grows with image size, and on GPU nodes where host memory is shared with frameworks and model weights, it leads to out of memory (OOM) termination of the runtime itself.  \nDBPP writes each chunk directly to its target byte offset on disk, eliminating the ordering dependency and bounding memory regardless of image size. Because each layer lands on disk as a complete, seekable file, DBPP runs SHA-256 digest verification and decompression simultaneously, two passes containerd must run one after the other. In controlled experiments across five production-scale images (up to 48.5 GiB), DBPP reduces peak daemon memory by 8.7–25.3× while maintaining comparable pull throughput. On a memory-constrained node, containerd 2.2 is OOM-killed pulling a 31.4 GiB image while DBPP completes the same pull. The underlying idea reaches past container images: any pipeline that buffers data in memory only to enforce ordering can move that buffer to disk once the backing store is fast enough, trading a scarce, contended resource for an abundant one.  \nIndex Terms—container images, parallel downloading, Kubernetes, containerd, machine learning infrastructure, memory efficiency, cloud computing  \nI. INTRODUCTION  \nLarge-scale AI and ML training and inference workloads increasingly ship as container images. Frameworks such as PyTorch and Megatron bundle GPU runtimes, numerical libraries, and model-serving code into images that reach 31– 48 GiB compressed (Table I) . These images are deployed on GPU-accelerated cloud instances with 100–3200 Gbps of network bandwidth, enough to transfer them in seconds. But in practice, the pull takes far longer, because the container runtime must also reassemble and unpack each layer before the image is ready to run. The bottleneck is not the network but how the runtime assembles the image.  \nWhen a container image is pulled, the runtime fetches each layer from a remote registry over [HTTP](HTTP), verifies the layer against its cryptographic digest, decompresses it, and unpacks the result into a local filesystem. For large images this process  \ndominates pod startup, accounting for more than 75% of total startup time [1] . The pull path is the critical path.  \nThe containerd container runtime [2] addressed part of this by introducing intra-layer parallelism: splitting each layer into fixed-size chunks and fetching them concurrently via HTTP range requests. However, its reassembly buffers chunks in an ordered, in-memory pipe: chunks that arrive early are held in the daemon heap until a sequential consumer reaches their position. Because parallel download outruns that consumer, the backlog grows with image size. On memory-constrained GPU nodes (where system memory is shared with CUDA contextsand model weights), this exhausts the host: pulling a 31.4 GiBimage on a node with 7.6 GiB random-access memory (RAM) terminates the container runtime daemon via the kernel OOM killer.  \nWe present Disk-Backed Parallel Pull (DBPP), which we have implemen","cbCaigUGruZPAQLH","https://ap.wps.com/l/cbCaigUGruZPAQLH","pdf",253865,1,7,"English","en",105,"# Introduction\n# Background\n## How a Container Image Pull Works","[{\"question\":\"How does DBPP reduce memory usage during parallel image pulls?\",\"answer\":\"DBPP writes each downloaded chunk directly to its target byte offset on disk, removing the in-memory ordering dependency. It also enables digest verification and decompression to run together per layer on disk, keeping daemon memory bounded regardless of image size.\"}]",1784191816,18,{"code":4,"msg":30,"data":31},"ok",{"site_id":24,"language":23,"slug":32,"title":13,"keywords":33,"description":14,"schema_data":34,"social_meta":78,"head_meta":80,"extra_data":82,"updated_unix":27},"bounded-memory-parallel-image-pulling-for-large-container-images","",{"@graph":35,"@context":77},[36,53,68],{"@type":37,"itemListElement":38},"BreadcrumbList",[39,43,47,50],{"item":40,"name":41,"@type":42,"position":20},"https://docshare.wps.com","Home","ListItem",{"item":44,"name":45,"@type":42,"position":46},"https://docshare.wps.com/document/","Document",2,{"item":48,"name":12,"@type":42,"position":49},"https://docshare.wps.com/document/research-report/",3,{"item":51,"name":13,"@type":42,"position":52},"https://docshare.wps.com/document/bounded-memory-parallel-image-pulling-for-large-container-images/83978/",4,{"url":51,"name":13,"@type":54,"author":55,"headline":13,"publisher":57,"fileFormat":60,"inLanguage":23,"description":14,"dateModified":61,"datePublished":62,"encodingFormat":60,"isAccessibleForFree":63,"interactionStatistic":64},"DigitalDocument",{"name":9,"@type":56},"Person",{"url":40,"name":58,"@type":59},"DocShare","Organization","application/pdf","2026-07-17","2026-07-16",true,{"@type":65,"interactionType":66,"userInteractionCount":20},"InteractionCounter",{"@type":67},"ViewAction",{"@type":69,"mainEntity":70},"FAQPage",[71],{"name":72,"@type":73,"acceptedAnswer":74},"How does DBPP reduce memory usage during parallel image pulls?","Question",{"text":75,"@type":76},"DBPP writes each downloaded chunk directly to its target byte offset on disk, removing the in-memory ordering dependency. It also enables digest verification and decompression to run together per layer on disk, keeping daemon memory bounded regardless of image size.","Answer","https://schema.org",{"og:url":51,"og:type":79,"og:title":13,"og:site_name":58,"og:description":14},"article",{"robots":81,"canonical":51},"index,follow",{"doc_id":7,"site_id":24},{"code":4,"msg":5,"data":84},[85,89,93,97,102,107,111,114,119,122,126],{"id":20,"doc_module":4,"doc_module_name":45,"category_name":86,"show_sort_weight":87,"slug":88},"Story & Novel",90,"story-novel",{"id":46,"doc_module":4,"doc_module_name":45,"category_name":90,"show_sort_weight":91,"slug":92},"Literature",80,"literature",{"id":52,"doc_module":4,"doc_module_name":45,"category_name":94,"show_sort_weight":95,"slug":96},"Exam",70,"exam",{"id":98,"doc_module":4,"doc_module_name":45,"category_name":99,"show_sort_weight":100,"slug":101},5,"Comic",60,"comic",{"id":103,"doc_module":4,"doc_module_name":45,"category_name":104,"show_sort_weight":105,"slug":106},6,"Technology",50,"technology",{"id":21,"doc_module":4,"doc_module_name":45,"category_name":108,"show_sort_weight":109,"slug":110},"Healthcare",40,"healthcare",{"id":11,"doc_module":4,"doc_module_name":45,"category_name":12,"show_sort_weight":112,"slug":113},30,"research-report",{"id":115,"doc_module":4,"doc_module_name":45,"category_name":116,"show_sort_weight":117,"slug":118},9,"Religion & Spirituality",20,"religion-spirituality",{"id":117,"doc_module":4,"doc_module_name":45,"category_name":120,"show_sort_weight":117,"slug":121},"World Cup","world-cup",{"id":123,"doc_module":4,"doc_module_name":45,"category_name":124,"show_sort_weight":123,"slug":125},10,"Lifestyle","lifestyle",{"id":127,"doc_module":4,"doc_module_name":45,"category_name":128,"show_sort_weight":98,"slug":129},19,"General","general"]