CIR: Lightweight Container Image for Cross-Platform Deployment Fengzhi Li, Xiaohui Peng, Qingru Xu, Qisong Shi, Tuo Zhou, Yongxuan Dai, Yifan Wang, Ninghui Sun, Zhiwei Xu Institute of Computing Technology, Chinese Academy of Sciences University of Chinese Academy of Sciences
arXiv:2604.10411v1 [cs.DC] 12 Apr 2026
Abstract
Platform-Specific
In modern cloud and heterogeneous distributed infrastructures, container images are widely used as the deployment unit for machine learning applications. An image bundles the application with its entire platform-specific execution environment and can be directly launched into a container instance. However, this approach forces developers to build and maintain separate images for each target deployment platform. This limitation is particularly evident for widely used interpreted languages such as Python and R in data analytics and machine learning, where application code is inherently cross-platform, yet the runtime dependencies are highly platform-specific. With emerging computing paradigms such as sky computing and edge computing, which demand seamless workload migration and cross-platform deployment, traditional images not only introduce inefficiencies in storage and network usage, but also impose substantial burdens on developers, who must repeatedly craft and manage platform-specific builds. To address these challenges, we propose a lazy-build approach that defers platform-specific construction to the deployment stage, thus keeping the image itself cross-platform. To enable this, we introduce a new image format, CIR (Container Intermediate Representation), together with its pre-builder and lazy-builder. CIR targets interpreted-language applications and only stores the identifiers of the application’s direct dependencies, leaving platform adaptation to the lazy-builder, which at deployment time assembles the actual dependencies into runnable containers. A single CIR can therefore be deployed across heterogeneous platforms while reducing image size by 95% compared to conventional images that bundle all dependencies. In evaluation, CIR shortens build time by 76–86%, reduces network usage by 44–50%, and achieves deployment speeds 40–60% faster than pulling pre-built images, outperforming stateof-the-art systems such as Docker, Buildah, and Apptainer.
1
Cross-Platform
Current Workflow
Images Build Scripts Build
Python Application
x86-64
arm64
NVIDIA
AMD
Container CPU GPU
Pull
Cross-Platform Platform-Specific Platform-Specific
Development Platform
Platform-Specific
Deployment Platforms
Lazy-Build Workflow Dependency Specifiers CIR Pre-Build Cross-Platform
Lazy-Build
Cross-Platform Cross-Platform
Development Platform
Platform-Specific
Deployment Platforms
Figure 1: (Up) Conventional container image is platformspecific, and multiple images have to be built for each CPU and GPU combination. (Down) CIR is cross-platform, and a single CIR can be built into different container instances in different deployment platforms. In contrast, emerging distributed computing paradigms such as sky computing [52], multi-cloud computing [23], and edge computing [50] advocate cross-platform deployment and workload migration to enhance execution performance, data locality, and data security [37, 44]. As shown in upper part of Figure 1, the prevailing practice is to construct a separate image for each target deployment platform, which imposes substantial overhead on developers. For example, the YOLO11 object detection system [28] uses 10 distinct build scripts to generate images for different CPU-GPU combinations. The root cause of this inefficiency lies in the separation of environment construction and deployment platform information. Environment construction is performed entirely on the developer side, whereas platform-specific details such as CPU architecture, GPU architecture, and driver versions are only visible to the container runtime at deployment time. This separation forces developers to anticipate the hardware characteristics of target deployment platforms and prepare dedicated build scripts. The image builder executes these scripts with environment managers such as pip, apt, conda and nix to create the execution environment and generate
Introduction
Over 90% of cloud-native applications are deployed using containers [6], an OS-level virtualization technology that provides isolated user-space environments. Applications are packaged together with their execution environments into container images [35], which are stored in registries such as Docker Hub and retrieved by deployment platforms to instantiate containers. Conventional container images are tightly coupled to specific deployment platforms, because the bundled execution environment contains libraries compiled for particular CPU or GPU architectures [17]. The most commonly used image formats are Docker/OCI (produced by buildah and buildkit) and SIF (produced by Apptainer). 1
Fengzhi Li, Xiaohui Peng, Qingru Xu, Qisong Shi, Tuo Zhou, Yongxuan Dai, Yifan Wang, Ninghui Sun, Zhiwei Xu
container images. At deployment, the container runtime detects hardware and driver information, selects the most compatible image, and launches containers. In short, developers build blind, while runtimes deploy blind, causing inefficiency and redundancy. This blind separation contradicts the design goals of modern parallel and distributed systems, where deployment decisions increasingly depend on runtime-visible hardware heterogeneity, accelerator availability, and data locality. This mismatch is particularly pronounced for applications written in interpreted languages, such as Python and R, which dominate data analytics and machine learning workloads. The application code of these languages is inherently cross-platform, while their execution environments heavily depend on platform-specific native libraries, GPU architectures, and driver versions. As a result, developers are forced to repeatedly construct and maintain platformspecific container images, even though the application logic itself remains unchanged. To bridge the gap between environment construction and deployment platform information, we propose a lazy-build method, which defers the platform-specific portion of environment construction to the deployment platform. As shown in the lower part of Figure 2, the conventional build and pull phases are replaced with pre-build and lazy-build phases. The pre-builder on the development platform packages the cross-platform application code together with only the specifiers of its direct dependencies into a new image format, the Container Intermediate Representation (CIR). At deployment time the lazy-builder performs three actions: (1) inspects the target hardware and driver configuration, (2) resolves the specifiers to concrete, platform-appropriate packages and binaries, and (3) assembles the selected packages with the application code into a runnable container instance. The proposed CIR image format is inherently cross-platform, alleviating the burden on developers by abstracting away the complexity of heterogeneous hardware and software environments. Instead of manually crafting build scripts for each target platform, developers only need to declare the application’s direct dependencies. As shown in the lower part of Figure 1, a single CIR can be lazily built into container instances across multiple platforms. The CIR format is also lightweight, thus suitable for workload migration. Since current image bundles the entire execution environment, the average image size exceeds 1 GB on Docker Hub [9], incurring heavy overhead on network bandwidth [4] and storage systems [12]. In contrast, CIR encodes only the names of application dependencies, reducing image size by up to 95%. The key challenges of this lazy-build method are ensuring correctness, consistency, and performance. If the lazy-builder were to directly reuse existing environment managers such as pip or apt on the deployment platform, the build process would be slower than pulling a pre-built image, and the results could be incorrect or inconsistent due to the instability of upstream software registries. To address these challenges, we introduce a new type of software package called the Uniform Component, and co-design the container runtime, image builder, and environment manager into a unified lazy-builder. The lazy-builder guarantees correctness and consistency by converting software packages into immutable uniform components,
Software Registries
Current Workflow
549MB
Dependencies Application Build 58.5s
790MB Image Push 36.8s
Dependencies
Dependency Specification
Pre-Build 1.2s
Container Pull 23.8s
Uniform Component Registry
Lazy-Build Workflow
Application
1954MB Image
21MB CIR Push 0.5s
Development Platform
495MB 1568MB
CIR
Container Lazy-Build 11.0s
Deployment Platform
Figure 2: When deploying the YOLO11 project, the lazy-build approach shortens end-to-end deployment time from 199.1 s to 12.7 s and reduces network traffic from 1339 MB to 516 MB (measured on a 500 Mbps link).
and by applying a uniform dependency resolution algorithm that deterministically selects the appropriate components and their dependencies. For the same deployment configuration, the lazy-builder always produces identical containers from a CIR, thereby ensuring stability and reproducibility. To support this process, we provide a web service that automatically converts Debian packages and Python packages into uniform components, and stores them in a Uniform Component Registry, which currently contains more than 50,000 packages. In terms of performance, lazy-builder not only outperforms stateof-the-art builders such as Docker, Buildah, and Apptainer by 77%87%, but also achieves deployment speed faster than pulling prebuilt images. This lazy-build method is particularly well-suited to data science and machine learning workloads, which are predominantly developed by interpreted-languages. Our method enables a single image representation to be reused across heterogeneous CPU and GPU platforms, significantly reducing build overhead and accelerating deployment. For compiled languages, our system provides compatibility with existing container workflows; however, true cross-platform reuse is fundamentally constrained by architecturespecific binaries and is therefore outside the primary scope of this work. This paper makes the following contributions: • We propose a lazy-build methodology for containers, that abstracts away heterogeneous platform specifics from developers, and enables architecture-aware optimizations during deployment-time. • We design a lightweight cross-platform image format CIR, and develop a production-grade CIR build system that prebuild applications into CIRs and subsequently lazy-build CIRs into containers. • We evaluate our proposed build system using nine real-world AI/ML applications across four different deployment platforms. 2
③
④
150 Time (s)
②
60 40
build push pull
75
58.5 36.8 23.8
80
71.3 38.7 38.0
100 ①
110.1 60.3 64.2
Motivation
Network Traffic (Mbps)
2
Application migration across heterogeneous platforms is a key capability in emerging computing paradigms. In sky computing [27, 52, 61], inter-cloud brokers migrate applications across heterogeneous platforms spanning multiple cloud providers, aiming to reduce costs, improve execution performance, and ensure regulatory compliance. Similarly, in edge computing [34, 59], applications are migrated from centralized cloud to distributed, heterogeneous nodes to minimize latency and alleviate data traffic. Even within a single cloud provider, platform diversity continues to grow [8], driven by the adoption of novel computing architectures (e.g., TPU [29], NPU [11]), emerging GPU families (e.g., NVIDIA Jetson series [36], AMD RDNA series [2]), and alternative CPU architectures such as RISC-V. This growing platform diversity enables performance gains by migrating applications to platforms best suited to each workload. In current practice, cross-platform migrations rely on multiplearchitecture image support: developers build separate container images for each target platform and annotate them with the multi-arch label, allowing the container runtime to select and pull the appropriate image for the deployment platform. However, this approach introduces two key drawbacks: Heavy developer burden As shown in the upper part of Figure 2, the current workflow places the entire responsibility of image building on developers. To support diverse heterogeneous platforms, developers must gain extensive knowledge of platform-specific features and optimizations, create multiple image building scripts, build various container images, and thoroughly test each of them. Well-maintained projects highlight this overhead: YOLO11 [28], HuggingFace Transformers [58], and TensorFlow [1] respectively maintain 10, 25, and 49 distinct Dockerfiles tailored for various CPU and GPU architectures. Similarly, projects such as PyTorch utilize Dockerfile templates with configurable parameters to generate different images suitable for multiple platforms. Both approaches significantly amplify the complexity and overall development effort, consequently imposing considerable additional maintenance burdens on developers. Continuously rebuilding and updating container images is also essential for developers to address software bugs and vulnerabilities. Many applications employ CI/CD pipelines (such as Docker Build Cloud 1 and Google Cloud Build 2 ) to periodically regenerate and refresh container images. However, this practice necessitates significant extra efforts from developers, as well as incurs considerable computational resources, network bandwidth, and storage overhead. Consequently, a large portion of developers do not regularly update their container images, leaving Docker Hub community images with a median of 567 identified vulnerabilities [63]—over 82% of which are classified as highly vulnerable due to outdated dependencies [57]. Slow builds and deployments To build a Docker image, developers first write a Dockerfile, which specifies a base image as the foundation of the building process and specifies the exact commands to use environment managers like apt, conda and pip for reproducing the execution environment. As shown in Figure 4,
140.2 112.8 118.4
CIR: Lightweight Container Image for Cross-Platform Deployment
20 0
40 80 Time (s)
120
0
50
100 200 500 Bandwidth (Mbps)
Figure 3: Building the image of YOLO11 project with Docker. (Left) Shows the network traffic during the building process when the maximum bandwidth is set to 100 Mbps. (Right) Shows the time usage of build, push and pull actions under different bandwidth limits. an image builder pulls the base image from a registry, launches a temporary container from that image, executes the Dockerfile’s instructions, invokes environment managers to install required software, and finally commits the resulting filesystem as a new image. The performance of this image build process is throttled by the environment managers, which must run sequentially during each layer’s construction and cannot exploit cross-manager parallelism. For example, the left side of Figure 3 plots network utilization while building the YOLO11 image over a 100 Mbps network. Regions 1-4 correspond to the four file layers: the base image, model weights, Debian packages, and Python libraries. In most cases, the network traffic achieves only partial utilization of the 100 Mbps capacity. The layers are built sequentially, with intervals between the different areas used for package installations. Once the image is built, it can be pushed to the registry and later pulled on the deployment platform. Deployment latency is driven both by transfer volume and by the layer-by-layer unpacking process. As shown on the right side of Figure 3, we measured pulling times for the 790 MB YOLO11 image under varying bandwidth caps. Given the image size, our calculations indicate that at low bandwidths, deployment is dominated by transfer time, whereas at high bandwidths, it is limited by the sequential unpacking of the file layers. To address these limitations, we introduce CIR, a new image format that lets developers specify an application’s dependencies once and reuse that single declaration across all target platforms, eliminating the need to create separate Dockerfiles manually. By encoding dependencies as abstract specifiers rather than embedding platform-specific binaries, CIR remains lightweight to distribute. To accelerate on-target assembly, we combine techniques such as container slimming, software component pre-processing, and parallelized dependency resolution and fetch. In our experiments this approach delivers up to 60% faster deployments compared with conventional Docker-based workflows.
3
Lazy-Build
Lazy-build is the design principle of CIR’s building system, separating the build process into two phases. On the development
1 https://build.docker.com/
2 https://cloud.google.com/build/
3
Fengzhi Li, Xiaohui Peng, Qingru Xu, Qisong Shi, Tuo Zhou, Yongxuan Dai, Yifan Wang, Ninghui Sun, Zhiwei Xu
However, no single build method is universally applicable. Some methods produce slimmer images but place heavier demands on the host system, whereas others deliver better PyTorch performance at the cost of complicating the integration of additional functionalities. Ultimately, developers must rely on their own experience to select among these imperative methods for each platform configuration. To solve this diversity problem, we propose to use a declarative method, declaring the needs of the application rather than specifying what to do during image build process. To include the PyTorch in the environment, the CIR should only declare
Builder-Controlled Scope
Image Registry
❷ ❶ Build Script
Software Registries
❹
❸
❷
Environment Managers
❸ Image ❺ Image Builder
❶ Request base image ❷ Launch container from base image ❸ Execute build script in container ❹ Environment managers install software ❺ Export container as image
CIR
Uniform Component Registry Uniform Component Manager
❶ Lazy ❹ Builder
Container
❶ Send dependency specifiers ❷ Resolve specifiers to components ❸ Convert missing components ❹ Assemble components into container
Python : torch == 2.5.1
and let the lazy-builder automatically select the most suitable build method on current platform. The detailed selection algorithm is described in section 3.2. Direct Dependency. Current image builders require developers to handle part of the indirect dependencies. For example, for OpenCVPython functionality, the developers need to install system software dependencies including libgl1-mesa-glx and libglib2.0-0:
Figure 4: (Left) Current image builder manages container content via environment managers. (Right) Lazy-builder directly assembles containers from uniform components. platform, the cross-platform application and its dependency specification are pre-built into a CIR. Then on the deployment platform, the dependency specification guides the lazy-builder to combine the actual required software components with the application into a container. This section focuses on two research questions: (1) How should the CIR specify the dependencies in pre-build phase? (2) How to ensure the correctness and consistency of lazy-build? For the first question, we propose that CIR should specify declarative direct dependencies (subsection 3.1). For the second question, we propose to use immutable uniform components as the container building blocks and design two algorithms to resolve the dependency (subsection 3.2).
3.1
FROM python :3.12 - slim RUN apt install -y libgl1 - mesa - glx libglib2 .0 -0 RUN pip install opencv - python
For lazy-build method, the CIR only declares direct dependencies, delegating the resolution of all indirect dependencies to the lazybuilder. For instance, the developer only specifies opencv-python == 4.9.0, and the lazy-builder automatically resolves and retrieves the appropriate Python interpreter, apt packages, and pip packages. This approach not only improves deployment flexibility by allowing the lazy-builder to adapt dependencies to the deployment platform, but it also minimizes errors caused by developers specifying incorrect indirect dependencies. To automatically resolve cross-manager dependency, it is critical that this approach centralizes the resolving process of indirect dependencies, managing them entirely through the builder. As shown in Figure 4, current image builders fetch base images from image registry and call multiple environment managers to install software and libraries. For lazy-build method, we propose to unify components from all registries, store them in one registry, and handle all their dependency relations in one component manager. Using this approach, we aim to render the deployment process more robust, efficient, and adaptive.
Declarative Direct Dependencies
Conventional image builders require developers to explicitly specify every build step. In contrast, CIR describes the execution environment solely through declarative direct dependencies. This abstraction allows the lazy-builder on the deployment platform to interpret the declared dependencies and automatically select appropriate components, thereby constructing a platform-specific container instance on demand. Declarative Dependency. Current image builder is commandoriented rather than functionality-oriented. Consequently, environments with equivalent functionality may be created using different build scripts. For example, the following four Dockerfiles all build images that provide PyTorch.
3.2
Uniform Component
To ensure correctness and consistency under lazy build, the lazybuilder maintains full control over the container execution environment. As shown in Figure 4, containers are constructed from uniform components, which serve as immutable building blocks managed by a dedicated Uniform Component Manager. These components are directly converted from existing software packages, enabling the lazy-builder to compose them through overlay without additional transformation, resulting in a functional container instance. Based on the declarative direct dependencies in CIR, the uniform component manager requires a selection algorithm to identify a suitable uniform component and a resolution algorithm to handle its indirect dependencies.
FROM debian : SOME_VERSION RUN apt install -y python3 - dev python3 - pip RUN pip install torch -------------------------------- -----------------FROM python : SOME_VERSION RUN pip install torch -------------------------------- -----------------FROM nvidia / cuda :12.4.1 - cudnn - runtime - ubuntu22 .04 RUN apt install -y python3 - dev python3 - pip RUN pip install torch -------------------------------- -----------------FROM pytorch / pytorch :2.5.1 - cuda12 .4 - cudnn9 - runtime 4
CIR: Lightweight Container Image for Cross-Platform Deployment
Algorithm 1: Uniform Component Selection
Algorithm 2: Uniform Dependency Resolution
Input: Dependency Item 𝑑 = ( M, 𝑛, specifier) Output: Uniform Component 𝑐 Initialize specSheet with host information; 𝑉 ← VQ( M, 𝑛); repeat 𝑣 ← VSM (𝑉 , specifier); if 𝑣 is empty then return Error: no component satisfies d; end 𝐸 ← EQ( M, 𝑛, 𝑣); 𝑒 ← ESM (𝐸, specSheet); if 𝑒 is empty then /* current 𝑣 may not provide a suitable environment variant 𝑉 ← 𝑉 \ 𝑣; end until 𝑒 is not empty; 𝑐 ← CQ( M, 𝑛, 𝑣, 𝑒 );
Input: Application Dependencies 𝐷 Output: Component List 𝐿 Initialize C with host information; Initialize Dependency Tree T; /* Each node contains a dependency item 𝑑 and a resolution result component 𝑐 T.root ← (empty, (𝐷, C)); for dep ∈ 𝐷 do T.root.AddChild((dep, empty)); end while 𝑇 has a not resolved node do node ← Breadth-First not resolved node of 𝑇 ; if node.d.SatisfiedBy(𝐿) then continue; end spec ←node.d.M.getSpec(C); repeat cs ← UniformComponentSelection(d, spec); if Selection fails then return Error: no component satisfies d; end d ← ConflictResolution(T, cs); until !d.hasConflict(); node.c = cs; for dep ∈ cs.D do node.AddChild((dep, empty)); end C ← CollectContext(T); 𝐿 ← CollectComponent(T); end
*/
Component Selection. We identify a common process of component selection across environment managers for operating system software (apt, nix), programming language library (pip, npm, conda, mamba) and container image (docker). Based on this observation, we propose a uniform component selection algorithm (Algorithm 1), which selects a specific uniform component according to a given dependency specification. In this algorithm, every component 𝑐 is uniquely identified by (M, 𝑛, 𝑣, 𝑒). For component manager M, given a name 𝑛, there are many versions available. Then given the name 𝑛 and the version 𝑣, there are many variants built for different hardware and software environment 𝑒. Every Component Manager M can be abstracted as two functions: • Version selection VS M : (𝑉 , specifier) → 𝑣 Best • Environment selection ES M : (𝐸, specSheet) → 𝑒 Best 𝑉 is a set of versions, and VS selects the most suitable version 𝑣 Best according to the specifier, which is a string like >=3.0, ~=2.0, and latest. 𝐸 represents a set of environment variants, and the ES function selects the most suitable variant, 𝑒 Best , based on the specSheet, which encapsulates the local hardware and software configurations. To rank the variants, we define a metric called deployability, which measures the suitability of a component for deployment on the current platform. This metric considers factors such as local caching, component size, download time, and execution performance. Each uniform component specifies its hardware and software requirements in its metadata. A deployability evaluator reads the metadata of all candidates, compares their requirements against the specSheet, and calculates a deployability score. The ES function then selects the component with the highest deployability score. A Uniform Component Registry stores all the components for every manager, and provides three services: • Version query VQ : (M, 𝑛) → 𝑉 • Environment query EQ : (M, 𝑛, 𝑣) → 𝐸 • Component query CQ : (M, 𝑛, 𝑣, 𝑒) → 𝑐
*/
A component selection request (for example the need of a Python library torch that satisfies >=2.0) corresponds to a dependency item 𝑑 = (M, 𝑛, specifier). It can be resolved to a specific component 𝑐 by the collaboration of component manager M and uniform component registry using Algorithm 1. Dependency Resolution. The uniform component selection algorithm leaves two issues unsolved: how is a specSheet generated, and how are indirect dependencies dealt with? We use a uniform dependency resolution algorithm to address these issues, which is described in Algorithm 2. This dependency resolution algorithm uses breadth-first order to generate the dependency tree, and use conflict-driven clause learning algorithm [14] for conflict resolution. This algorithm is compatible with the dependency resolution algorithm in apt and pip, but also add a Building Context C for every container building process for hardware-software compatibility and cross-manager compatibility. The building context is initialized by reading the hardware and software information of the host platform. For example, CInit = {cpu : amd64, gpu : nvidia, gpu.driver : 535.183.01}
The metadata of uniform component 𝑐 = (𝐷, C) includes dependency items 𝐷 and building context 𝐶. For example, OpenCVPython component (pip, opencv_python, 4.10.0.84, cp37-abi35
Fengzhi Li, Xiaohui Peng, Qingru Xu, Qisong Shi, Tuo Zhou, Yongxuan Dai, Yifan Wang, Ninghui Sun, Zhiwei Xu
manylinux_2_17_x86_64) is
4.2
𝑐 = (𝐷 = {(pip, numpy, >=1.26.0), (apt, libgl1-mesa-glx, any), (apt, libglib2.0-0, any)}, C = {opencv.version : 4.10.0.84}) Each dependency item includes a component manager M item, which enables the expression of cross-manager dependencies.
3.3
Correctness and Consistency
The correctness of the build pipeline requires (1) accurate conversion of upstream software into uniform components, and (2) correct selection of those components according to the dependency specifiers. Using the image benchmark described in Section 5.2, we verified functional correctness by running the official functional tests for each application. To validate selection correctness, we compared the installed apt packages and pip packages in lazy-built containers against those produced by conventional image builders, confirming identical package versions and resolved artifacts. We validate consistency by rebuilding each CIR across heterogeneous target platforms and comparing the results. After the first successful build, the lazy-builder is able to record the identifiers of all selected uniform components. Since uniform components are immutable, an identical CIR deterministically produces bit-identical containers when rebuilt on the same platform type.
4
CIR Build System
Based on the proposed lazy-build method, we designed the CIR image format and implemented its build system with 13,000 LOC GoLang code, including a pre-builder (subsection 4.1), a lazy-builder (subsection 4.2) and a uniform component service (subsection 4.3).3 Currently, this system supports Python projects and can automatically convert components from OCI images, Debian software packages, Python libraries, and HuggingFace models. Figure 5 illustrates the architecture of our CIR build system.
4.1
4.3
2 3 4 5 6 7 8 9 10 11
Uniform Component Service
Uniform component service provides uniform components for all platforms. Once it receives a request, the service first tries to select from the Uniform Component Registry that stores all the previously converted uniform components. If none of them satisfies the request, the service then requests the Upstream Component Sources for a component and uses Component Converters to convert it into a uniform component. The core of this service comprises the uniform component selection algorithm and component converters. The uniform component registry we implemented provides VQ, EQ, and PQ functions for Algorithm 1’s queries. For upstream component sources, we created a portability layer to transform our functions to their API invocations (DockerHub API, Debian snapshot API and Python Package Index API. Three component converters are used by the service to convert Docker images, Debian software packages, and Python libraries into uniform components, which are stored in a compressed .tar.gz
Pre-Builder
The pre-builder on the development platform uses two methods for dependency analysis. The first method performs syntax analysis to identify dependencies across all code files in the Python application. The second method reads the analyzed results from other dependency analyzers, such as requirements.txt and pyproject.toml. Once the dependencies are collected, the pre-builder filters out the indirect dependencies and generates a metadata file, as shown below. The metadata, along with the application code, is then packed into a CIR. 1
Lazy-Builder
The lazy-builder on the deployment platform reads a CIR, resolves all its dependencies, selects the suitable components, and assembles them into a container. The core of lazy-builder is the uniform component selection algorithm (Algorithm 1) and the uniform dependency resolution algorithm (Algorithm 2). For Algorithm 1, the VQ, EQ, and CQ functions are implemented by the Local Uniform Component Storage, which caches components from uniform component service. The VS and ES rules are described in each component manager’s specification document. For example, PyPA Specifications4 describes the scheme of Python wheel version identifier, version specifier, platform tag, and platform compatibility. We followed these specifications to implement the VS and ES functions for selecting Python libraries and designed the specSheet for the Python component manager. The specSheet includes four parameters: CPU architecture, system type, Python interpreter version, and standard C library version. Similarly, we used Debian Policy Manual 5 for Debian software packages and Docker Image Specification6 for Docker images. After all dependencies are resolved, and components are selected and cached, the Uniform Component Assembler uses OverlayFS [3] to mount all the components into a root file system and generates an OCI runtime specification. containerd is used as the container runtime, with CNI plugins and NVIDIA Container Toolkit installed as network and GPU support. Since Docker also uses containerd as runtime, the CIR system achieves container startup latency and runtime performance identical to Docker. Finally, upon the completion of deployment, the lazy-builder records the exact versions of all selected components and generates a dedicated version locking file for each platform. This file serves as a reproducibility manifest, ensuring consistent behavior across testing and production deployment platforms.
[ NAME ] YOLO11 [ VERSION ] 1.0 [ DEPENDENCY ] - [ Apt ] libgl1 [ any ] - [ Apt ] libglib2 .0 -0 [ any ] - [ Apt ] libusb -1.0 -0 [ any ] - [ PyPI ] torch [ >=1.8.0] - [ PyPI ] torchvision [ >=0.9.0] ... - [ LOCAL ] / ultralytics [ yolo11n . pt ] [ WORKDIR ] / ultralytics
4 https://packaging.python.org/en/latest/specifications/ 5 https://www.debian.org/doc/debian-policy/
3 https://github.com/L-F-Z/TaskC
6 https://github.com/moby/docker-image-spec/
6
CIR: Lightweight Container Image for Cross-Platform Deployment
Development Platform CIR [pip] torch [>2.0.0] [apt] ffmpeg [>4.2.0]
Dependency Analyzer
snapshot. debian.org
Algorithm 2
Algorithm 1
Uniform Match Component Selection
Algorithm 1
No
Container
VQ EQ CQ
ffmpeg
4.2.7
aarch64
Local Uniform Component Storage name
version
environment
file
pip
torch
2.5.1
Python3.12-aarch64
/local1
apt
ffmpeg
4.0.0
aarch64
/local2
Algorithm 1
apt
ffmpeg
Component Converters Deb Cvt. 4.2.7
Image Cvt. aarch64
Wheel Cvt. Uniform Component
Uniform Component Service
apt
mgr
Upstream Component
Uniform Match Uniform Component Component Selection Selection
[apt] ffmpeg [>4.2.0] aarch64
VQ EQ CQ
No
hub.docker .com
pypi.org
VQ EQ CQ
❷ ❸
Uniform Dependency Resolution
[apt] ffmpeg [>4.2.0] aarch64
pytorch.org
❶
Lazy-Builder
Uniform Component Assembler
Upstream Component Sources
Pre-Builder Application
Uniform Component Registry mgr
name
version
environment
file
pip
torch
2.5.1
Python3.12-amd64
/path1 /path2
pip
torch
2.5.1
Python3.12-aarch64
apt
ffmpeg
4.2.7
amd64
/path3
apt
ffmpeg
4.2.7
aarch64
/path4
Deployment Platform Figure 5: Overview of the CIR build system. (Upper Left) On the development platform, the pre-builder packages the application into a CIR. (Lower Left) On the deployment platform, the lazy-builder resolves dependencies described in the CIR and assembles uniform components into a container. If a required component is locally unavailable, the deployment platform sends the request to the uniform component service. (Right) The service first attempts to resolve the request from the uniform component registry. If no suitable component exists, it fetches the component from upstream component sources and converts it into a uniform component. archive format that supports streaming decompression. Each converter pre-compiles the component to simplify the installation process. Subsequently, the converter extracts the dependency information into a separate metadata file, allowing both dependency resolution and component downloading to be performed in parallel. Docker image has a manifest file, which links to a config file and several layer files. Docker images normally do not exhibit dependency issues, so the converter only extracts metadata such as User, WorkingDir, Env, Entrypoint and Cmd from the config file. Multiple layer files are extracted to the same directory according to OCI image specification 7 to simulate the mounting result of OverlayFS [3]. The Debian software package .deb file contains a data.tar file and a control.tar file. data.tar includes all the files that require unpacking. control.tar includes the dependency information, and scripts to be executed before and after the unpacking. The converter analyzes and simulates the execution of the scripts, including creating symbolic links, updating shared library caches, setting file permissions, and managing users. Dependency information is directly extracted to uniform component’s metadata.
Python library binary distribution .whl contains a .dist-info directory and multiple files or directories that need to be placed in the Python site-packages directory. From the METADATA file in .dist-info directory, the converter extracts the dependency information and the Python version requirement to uniform component’s metadata. The converter also creates executable scripts according to information in entrypoint.txt. For Python library source distribution, the converter uses Python 3.6 - 3.12 build tools to generate a .whl binary distribution for each version, and then converts the binary distributions to uniform components.
5
Evaluation
To assess the build performance and cross-platform capability, we compared the CIR build system with three state-of-the-art image builders, including Docker (version 27.3.1, using buildx as the frontend and buildkit as the backend build engine) [35], Buildah (version 1.28.2) [38] and Apptainer (version 1.3.5) [30]. We evaluated these builders on four different deployment platforms (subsection 5.1), using a benchmark suite (subsection 5.2) consisting of nine real-world representative machine learning applications. To demonstrate the cross-platform characteristics of CIR (subsection 5.3), we deployed the same CIR on the four deployment platforms.
7 https://github.com/opencontainers/image-spec/
7
Fengzhi Li, Xiaohui Peng, Qingru Xu, Qisong Shi, Tuo Zhou, Yongxuan Dai, Yifan Wang, Ninghui Sun, Zhiwei Xu
The performance of build systems is commonly affected by three key factors: image size, computing resources, and network bandwidth. For image size, we compared the CIR with other image formats generated from baseline build systems (subsection 5.4). To emulate the network conditions (subsection 5.5) of edge devices, personal computers, and data center servers, we adjusted the bandwidth between deployment platforms and the component server from 10 Mbps to 1000 Mbps. For computing resources (subsection 5.6), we tested from 1 CPU core with 2 GB memory to 16 CPU cores with 32 GB memory. We also evaluated the file-sharing performance (subsection 5.7) of the CIR lazy-builder against stateof-the-art image de-duplication methods. As shown in Figure 2, baseline systems perform build and push on the development platform and pull on the deployment platform. In contrast, CIR performs pre-build and push on the development platform and lazy-build on the deployment platform, which downloads the CIR image and assembles uniform components. We evaluate both systems using three metrics: Build Time (build vs. pre-build + lazy-build), Deployment Time (pull vs. lazy-build), and End-to-end Time (build + push + pull vs. pre-build + push + lazy-build).
Image Size
15000 10000
Experimental Setup
CPU Server
5000 0 CLIP
LoRA
SAM2
SB3
SD
Transf.
SB3
SD
Transf.
TTS
Whisper YOLO11
TTS
Whisper YOLO11
15000 10000
GPU Server
5000
We selected four representative platforms as deployment platforms, covering two CPU architectures (amd64 and aarch64) and two GPU architectures (NVIDIA Ampere and AMD RDNA 3). The hardware and software specifications are: • CPU Server: Intel Xeon Platinum 8163, 64 GB Memory. • GPU Server: Intel Xeon Gold 6442Y, 64 GB Memory. NVIDIA A100 80 GB PCIe. 535.183.01 Driver, CUDA 12.2. • Personal Computer: Intel Core i5-10505, 16 GB Memory. AMD Radeon RX 7900 XTX 24 GB, 24.20.3 Driver. • Edge Device: NVIDIA Jetson Orin NX 16 GB, Arm CortexA78AE CPU. To eliminate the impact of external registry speeds, we used the same registry server to cache all external registries and host a uniform component registry. All deployment platforms are connected to this server via a network switch, which limits the maximum bandwidth to 1 Gbps.
5.2
Cross-Platform CIR
5.4
Image Size (MB)
5.1
5.3
We selected the YOLO11 project as our test case because the project’s repository includes multiple official Dockerfiles targeting different deployment platforms. We uses four distinct Dockerfiles to test on each platform, and the Docker builder used 348.9 s on personal computer, 416.1 s on edge device, 212.6 s on GPU server, and 111.2 s on CPU server. In comparison, the CIR approach used a single CIR for all four deployment platforms. With this setup, the CIR build time was reduced by an average of 78.7%, which was only 118.4 s on a personal computer, 26.4 s on an edge device, 67.5 s on a GPU server, and 14.5 s on a CPU server.
0 CLIP
LoRA
SAM2
Average Size (MB)
Docker
Buildah
Apptainer
CIR-container
CPU Server
4330
4187
3634
1177
CIR 188
GPU Server
6010
5870
5555
3319
188
Figure 6: The image size for CPU and GPU platforms. Next, we built the benchmark suite to assess image size generated by our CIR build system and baseline systems. The average image sizes generated on the GPU server by Docker, Buildah, and Apptainer were 6010 MB, 5870 MB, and 5555 MB, respectively, while the average CIR size was only 188 MB. Therefore, on the development platform, CIR reduces average data transfer by approximately 96%. On the deployment platform, the lazy-builder averagely fetched 188 MB CIR and 1822 MB uniform component to assemble the full container, which was about 65% less than Docker, Buildah, and Apptainer. This reduction in final container size is achieved by reusing GPU-related components on host platforms via libnvidia-container, omitting package managers such as apt and pip (since their tasks are performed by the lazy-builder), and removing package caches. The CIR build system delivers better performance for two primary reasons: (1) CIR containers are smaller because they include only the necessary components, and (2) all components are pre-built and pre-processed, allowing for direct assembly. To demonstrate that the second factor also enhances performance, we used the CIR version locking mechanism to create nine specialized CIRs, referred to as CIR-locked, which specify exactly the same dependencies as the baseline images. The container sizes produced by CIR-locked are nearly identical to those of Buildah, deviating by no more than ±2%. In the subsequent experiment, we used CIR-locked to confirm
Benchmark Suite
Our benchmark8 focuses on machine learning domain, which is extensively deployed across edge devices, personal computers, and data center servers. The benchmark suite encompasses nine realworld projects that cover key research areas in machine learning: • Computer Vision: YOLO11 [28], SAM2 [45] • Natural Language Processing: Transformers [58], LoRA [25] • Multimodal: CLIP [40], Stable Diffusion [46] • Speech Processing: TTS [10], Whisper [41] • Reinforcement Learning: Stable Baselines 3 [42] For each project, we directly used the official Dockerfiles for Docker and Buildah, and authored Apptainer definition files that reproduce the same build steps for Apptainer. 8 https://github.com/L-F-Z/TaskC_Demos
8
CIR: Lightweight Container Image for Cross-Platform Deployment
that even when container sizes are similar, the CIR build system still outperformed other baseline systems because of the pre-built and pre-processed components.
CIR
YOLO11 CPU Version [CPU Server]
Docker
Time (s)
282.2
212.6
234.8
618.9
458.4
400 200 0 CIR
Buildah
220 200
68.2
Docker
CIR
Apptainer 1800
YOLO11 CPU Version [CPU Server]
CIR (locked) YOLO11 CPU Version [CPU Server]
1200
150
Time (s)
Time (s)
CIR (locked)
299.4
600
Impact of Network Bandwidth
640 600
Intel Xeon Gold 6442Y CPU (GPU Server)
67.5
400 100
600
Buildah Docker
Apptainer
Buildah
Apptainer
100 CPU Usage (%)
5.5
Intel Xeon Platinum 8163 CPU (CPU Server)
1500 1000 500 2c4g 4c8g 4c16g 16c32g 8c16g 0 1c2g
80 60 40 20
10
3900
20 50 Bandwidth (Mbps) YOLO11 GPU Version [GPU Server]
Time (s)
3000
0
0
100 200
500 800 Bandwidth (Mbps)
750
1200
YOLO11 GPU Version [GPU Server]
600 400
2000
2c4g
0
4c8g 4c16g 8c16g 16c32g Machine Configuration YOLO11 GPU Version [GPU Server]
800
400
0
120
240 360 Time (s)
480
600
100 80 60 40 20
200 1000 640
1c2g
1000
CPU Usage (%)
90
50
Time (s)
200
0
100 10
20
50
Bandwidth (Mbps)
0
100 200
500
800
1c2g
2c4g 4c8g 4c16g 8c16g 16c32g Machine Configuration
0
0
120
240 Time (s)
360
1000
Figure 8: Build times of YOLO11 project under different number of CPU cores and memory sizes.
Bandwidth (Mbps)
Figure 7: Build times of YOLO11 project under different network bandwidth. cores and 16 GB of memory. We found that the CIR system was not only the fastest but also the most stable and the least affected by CPU performance. Although the GPU server’s CPU is more powerful than the CPU server’s, this difference translates to only about a 1% improvement for the CIR system but over 20% for the baseline systems. The variance in build time for our CIR system was approximately 0.2 s, compared to over 11 s for the baseline systems. The lower-left panel of Figure 8 shows the build times on both servers characterized by varying numbers of CPU cores and memory sizes. Only the Apptainer system’s performance was significantly affected by the number of CPU cores. The lower-right portion of Figure 8 shows the reason by showing CPU usage throughout the build process. Apptainer’s use of SquashFS for image compression requires substantial CPU computation during the latter stages of the build, whereas the other systems kept CPU usage below 50%. We found that our CIR system consistently outperformed Docker and Buildah across scenarios. Figure 9 shows the detailed results for build time, deployment time, and end-to-end time of each project, using a representative hardware configuration (GPU server, 4 CPU cores, 16 GB of memory, and a 500 Mbps network bandwidth). We found that our CIR system achieves a reduction in build time of 77.26% compared to Docker, 81.51% compared to Buildah, and 86.94% compared to Apptainer. In addition, our CIR system reduces the deployment time by 62.94% relative to Docker, 61.25% relative to Buildah, and 42.19% relative to Apptainer. Critically, end-to-end time was reduced by 91.57% compared to Docker, 90.58% compared to Buildah, and 90.90% compared to Apptainer.
To demonstrate the impact of network bandwidth, we built YOLO11 on both CPU and GPU servers while limiting the network bandwidth to 10, 20, 50, 100, 200, 500, 800, and 1000 Mbps. As shown in Figure 7, the CIR build system consistently outperforms all other systems at every tested bandwidth, achieving average build time reductions of 54.1% compared to Docker, 56.0% compared to Buildah, and 64.9% compared to Apptainer. Notably, the build time difference between Docker and the CIR system remained roughly 100 s across all bandwidth settings. This observation indicates that with increasing bandwidth, the relative advantage of CIR over Docker increases. When we used a 1000 Mbps network bandwidth, CIR system was 87.1% faster than Docker. The persistent 100-second gap represents the time spent by the Docker on component compilation and processing, which cannot be reduced by simply increasing network bandwidth. Because the CIR-locked container is similar in size to the Docker container but employs pre-compiled and pre-processed components, the consistent 100-second difference also explains why CIRlocked’s build time matches Docker’s under lower bandwidth conditions yet more closely approaches CIR’s performance as the available bandwidth increases.
5.6
Impact of Computing Resources
To assess the impact of computing resources on build time, we built YOLO11 on both CPU and GPU servers using a 500 Mbps bandwidth network. The upper part of Figure 8 shows the build times on the CPU server and the GPU server, both limited to 4 CPU 9
Fengzhi Li, Xiaohui Peng, Qingru Xu, Qisong Shi, Tuo Zhou, Yongxuan Dai, Yifan Wang, Ninghui Sun, Zhiwei Xu CIR
CIR (locked)
Docker
Buildah
1200 900
800
600
400
300 LoRA
SAM2
SB3
SD
Transf.
TTS
Whisper YOLO11
0
CLIP
11.2 60.9 77.6 88.1 59.4 15.3 18.1 122.9 141.4 63.8 49.4 169.8 269.2 265.1 249.9 7.8 9.5 42.9 37.0 18.1 24.8 200.2 359.3 339.6 344.1 21.6 16.4 29.6 24.8 12.5 15.9 73.3 187.7 147.6 105.4 20.2 73.5 97.6 122.5 88.0 12.7 20.9 31.5 30.8 16.8
400 Time (s)
SAM2
SB3
Deployment Time (Pre-Build vs. Pull)
CPU Server
SD
Transf.
TTS
Whisper YOLO11
GPU Server
300
300
200
200 100
100 0
CLIP
LoRA
SAM2
SB3
SD
Transf.
TTS
Whisper YOLO11
CPU Server
0
1600 1200
1000
800
500
400 CLIP
LoRA
SAM2
SB3
SD
LoRA
SAM2
SB3
Transf.
TTS
Whisper YOLO11
SD
Transf.
TTS
Whisper YOLO11
GPU Server
63.6 44.9 361.9 307.0 317.0 68.1 128.2 823.7 846.6 1000.0 194.7 222.5 874.7 806.0 918.3 33.7 53.7 319.5 268.8 290.0 83.3 166.4 1269.9 1326.4 1454.8 78.4 158.2 814.6 880.5 1038.7 68.6 58.3 694.9 576.1 597.2 72.6 72.7 480.2 406.5 409.6 67.9 76.8 716.3 542.9 683.4
2000 1500
0
CLIP
End-to-End Time
11.5 61.2 462.7 420.6 389.6 17.8 20.6 731.0 723.3 561.0 140.6 261.0 1189.2 1053.5 1241.3 8.6 10.2 263.1 229.8 219.4 31.8 207.2 1674.7 1693.9 2019.2 23.0 17.8 312.5 285.6 156.6 20.6 78.0 989.0 825.4 763.8 20.8 74.0 647.7 531.6 554.6 14.9 23.1 190.1 185.6 198.2
Time (s)
LoRA
63.3 44.0 66.0 68.3 50.0 64.8 124.8 204.4 224.1 162.5 103.6 130.8 221.4 206.8 196.6 33.6 53.7 61.4 56.6 34.4 77.9 161.0 283.2 295.9 254.5 74.3 154.1 224.0 225.2 185.6 67.2 56.9 161.0 108.4 87.7 72.1 72.1 90.2 97.0 64.1 65.7 74.6 153.7 147.0 102.3
CLIP
GPU Server
63.4 44.2 106.2 146.9 195.3 66.8 126.8 278.6 355.0 679.7 165.1 192.4 278.8 330.4 533.9 33.6 53.7 108.1 145.7 201.0 80.5 163.6 512.6 633.2 968.3 77.9 157.7 330.7 387.9 640.4 68.1 57.8 232.9 312.7 387.5 72.5 72.5 139.5 188.6 262.3 67.5 76.4 212.6 234.8 458.4
11.3 61.0 154.7 216.5 261.3 17.3 20.1 271.8 379.9 428.0 111.0 231.4 468.2 485.2 783.9 7.9 9.5 122.1 138.7 178.3 27.4 202.8 744.9 902.3 1403.9 22.5 17.4 230.6 225.1 127.1 19.5 77.0 430.8 483.9 552.7 20.6 73.8 251.0 260.3 378.5 14.5 22.6 111.2 114.5 160.4
Time (s)
1600 1200
0
Apptainer
Build Time (Pre-Build+Lazy-Build vs. Build)
CPU Server
0
CLIP
LoRA
SAM2
SB3
SD
Transf.
TTS
Whisper YOLO11
Figure 9: Build times for the benchmark suite on CPU and GPU servers, showing build time (top), deployment time (middle), and end-to-end time (bottom). Both servers connect to the component server via a 500 Mbps network.
5.7
Storage Sharing
1-CLIP 2-LoRA 3-SAM2 4-SB3 5-SD 6-Transf. 7-TTS 8-Whisper 9-YOLO11 100%
Docker and Buildah store images at the layer level, sharing identical layers across images to accelerate builds and pulls while reducing storage on both registries and deployment platforms. As shown in Table 1, storing all benchmark images individually requires 122.05 GB, whereas layer sharing reduces this to 113.90 GB (-6.7%). It also shortens build time by 2.4% (2616 s → 2553 s) and pull time by 6.8% (1644 s → 1533 s).
80% 60% 40% 20%
Layer
File
Chunk
Component (passive)
Before (GB) After (GB) Percentage
122.05 113.90 6.68%
107.78 91.11 14.57%
102.62 82.20 19.90%
100.02 78.40 21.62%
17.98 9.66 46.27%
54.24 16.53 69.52%
Before (Obj) After (Obj) Percentage
255 244 4.31%
614246 312730 49.09%
966273 390609 59.58%
3302 992 69.96%
1957 784 59.94%
2074 799 61.48%
Chunk
Component
0%
Figure 10: Pairwise sharing rate within benchmark suite.
Component (active) CPU GPU
Layer
File
sharing (14.6%) used by ORC [47], Gear [12] and DupHunter [65, 66], and chunks-level sharing (19.9%) used by Slacker [24] and Nydus [54]. However, finer granularity incurs heavy management overhead: in our benchmark suite, layer sharing required 255 objects, file-level 614k, and chunk-level 966k. CIR adopts component-level sharing, achieving 21.6% with only 3302 objects. The sharing rate was slightly higher than that achieved at the chunk level, because these containers are slimmer than their Docker counterparts, having excluded download caches and Git project caches. This sharing rate can be further increased through active sharing. Current sharing systems typically adopt a passive sharing method, converting and analyzing images built by other systems without altering their content. In contrast, the CIR build system is able to employ an active sharing method at component granularity, proactively selecting local reusable components that meet the specified
Table 1: Applying different granularity sharing policy on benchmark suite. (Up) Storage usage (Down) Object count
Layer-level sharing suffers from low reusability, as even small file changes invalidate entire layers [21, 48, 49, 51, 53, 62]. To improve the sharing rate, prior systems explored finer granularities: file-level 10
CIR: Lightweight Container Image for Cross-Platform Deployment
dependencies. This approach raises the sharing rate to 46.27% on a CPU server and 69.52% on a GPU server. Additionally, the lazy-build time of all projects was reduced by 40.5% (from 179.0 s to 106.6 s) on a CPU server and 68.2% (from 622.4 s to 197.6 s) on a GPU server under the representative hardware configuration. Figure 10 visualizes the pairwise sharing rates, which generally increase as granularity becomes finer, yet reach their highest value at the component level.
across heterogeneous platforms, the bar for validating final build outputs becomes higher. For applications that do not require crossplatform deployment, CIR does not introduce additional testing complexity compared to conventional workflows: the CIR can be lazily built on the target test platform, then after successful tests, all uniform components can be locked for that platform to guarantee subsequent deployments remain bit-for-bit consistent.
6
Cross-Platform Deployment: Costs and Benefits. For applications that do require cross-platform deployment, testing complexity does increase: teams must verify that containers lazily built from the same CIR behave as expected on each target platform. CIR can record platforms that have passed validation and prevent builds on untested platforms by default. Nevertheless, as emphasized by emerging paradigms such as sky computing and edge computing, the flexibility and reach enabled by robust cross-platform execution can outweigh the additional testing overhead, delivering outsized benefits in portability, performance placement, and operational resilience.
Related Work
Containers were initially adopted in cloud computing. Over time, their usage has expanded to high-performance computing (HPC) [16, 30, 39] and edge devices [32, 60], thereby supporting a wide range of computing environments. As container images encapsulate both application code and execution environments, the efficiency of image construction and distribution has therefore become a critical factor in container-based deployment. To accelerate image builds, prior work has proposed caching and reusing packages or images [26, 33], optimizing build strategies [13, 15, 19, 20], and reducing image size by multi-stage builds, removing redundant system software [18, 43], or pruning unused files [55, 64]. These approaches substantially reduce build time and image size during the development phase. However, they still construct platform-specific images on the development platform, limiting cross-platform reuse. Applying such build-time techniques at deployment time would incur higher latency than pulling pre-built images. In contrast, lazy-build enables deployment-time adaptation while achieving build latency even lower than image pulling. Several recent systems explore deployment-time construction for containerized applications, such as XaaS [7] and coMtainer [22], but primarily target compiled-language workloads (e.g., C and C++) and focus on improving execution performance, whereas CIR targets interpreted-language workloads and optimizes both deployment performance and execution performance. To improve container deployment performance, modern systems adopt lazy pulling technique. Lazy pulling prioritizes downloading only the essential parts of an image to start the container quickly, deferring the retrieval of non-essential parts to runtime. This approach can operate at the block level [24, 31, 54], file level [4, 5], and image level [56]. CIR focuses on the generation of image and container file directories, while lazy pulling accelerates startup by introducing new container runtime file systems. These two lines of research are orthogonal and complementary. When combined, CIR and lazy pulling yield up to approximately 32% additional performance improvement over existing methods.
7
Registry Feasibility. Unifying packages from multiple ecosystems has been demonstrated to be practical by conda and Nix, which convert heterogeneous package formats into their own formats and store them in their respective registries. These systems are designed for multi-version coexistence, consistency, and reproducibility, while CIR targets deployment performance. Currently, CIR intentionally focuses on Debian, Python, and R, which aligns with the ecosystem coverage prioritized by conda and covers the majority of machine learning and data analytics workloads. Due to the on-demand conversion strategy, the current uniform component repository uses about 1.6 TB of storage and serves the vast majority of needs. Fully converting all Debian packages adds 20 TB, and all Python packages add another 10 TB. Extensibility. CIR is designed to be ecosystem-pluggable. Extending CIR to another interpreted language ecosystem requires four more components: versioning rule, package conversion, registry API adapter, and (optionally) application dependency analysis. In practice, each additional ecosystem introduces only about 3,000 LoC. Extending CIR to compiled languages would require an additional on-node compilation stage and warrants further investigation to avoid hurting cold-start performance.
8
Conclusion
In this paper, we proposed a novel CIR that functions as a lightweight and cross-platform container format. Unlike current imagebuilding approaches that require developers to construct an execution environment for each platform, our CIR delegates this responsibility to the lazy-builder on the deployment platform. This approach enables the lazy-builder to choose the most suitable components based on the deployment platform’s hardware and software configurations. Consequently, pre-built components can be fetched on demand, thereby enhancing reusability and reducing network usage. As a result, CIR facilitates cross-platform container deployment and seamless compute migration, making it well-suited for application migration in emerging computing paradigms such as sky computing, multi-cloud computing, and edge computing.
Discussion
Compatibility with the Container Ecosystem. CIR is integrated with mainstream container runtimes, including containerd and CRI-O, at the image management layer of the container stack. To support practical adoption, CIR enables automated migration of legacy container images by inferring environment declarations from existing software installations, allowing legacy artifacts to be converted into CIR specifications without semantic loss. Implications for Existing Testing Pipelines. Delegating parts of the build process to the deployment platform may affect established CI/CD testing pipelines. Because a single CIR may be deployed 11
Fengzhi Li, Xiaohui Peng, Qingru Xu, Qisong Shi, Tuo Zhou, Yongxuan Dai, Yifan Wang, Ninghui Sun, Zhiwei Xu
References
doi:10.1109/INFOCOM42981.2021.9488918 [22] Yuhao Gu, Haoquan Chen, Xianjie Chen, Jiangsu Du, Zhiguang Chen, Nong Xiao, Xianwei Zhang, and Yutong Lu. 2025. coMtainer: Compilation-assisted HPC Container Images with Enhanced Adaptability. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC ’25). Association for Computing Machinery, New York, NY, USA, 586–601. doi:10.1145/3712285.3759790 [23] Carlos Guerrero, Isaac Lera, and Carlos Juiz. 2018. Resource optimization of container orchestration: a case study in multi-cloud microservices-based applications. The Journal of Supercomputing 74, 7 (1 July 2018), 2956–2983. doi:10.1007/s11227-018-2345-2 [24] Tyler Harter, Brandon Salmon, Rose Liu, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau. 2016. Slacker: Fast Distribution with Lazy Docker Containers. In 14th USENIX Conference on File and Storage Technologies (FAST 16). USENIX Association, Santa Clara, CA, 181–195. https://www.usenix.org/conference/ fast16/technical-sessions/presentation/harter [25] Edward J Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, and Weizhu Chen. 2022. LoRA: Low-Rank Adaptation of Large Language Models. In International Conference on Learning Representations. https: //openreview.net/forum?id=nZeVKeeFYf9 [26] Zhuo Huang, Song Wu, Song Jiang, and Hai Jin. 2019. FastBuild: Accelerating Docker Image Building for Efficient Development and Deployment of Container. In 2019 35th Symposium on Mass Storage Systems and Technologies (MSST). 28–37. doi:10.1109/MSST.2019.00-18 [27] Paras Jain, Sam Kumar, Sarah Wooders, Shishir G. Patil, Joseph E. Gonzalez, and Ion Stoica. 2023. Skyplane: Optimizing Transfer Cost and Throughput Using Cloud-Aware Overlays. In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23). USENIX Association, Boston, MA, 1375–1389. https://www.usenix.org/conference/nsdi23/presentation/jain [28] Glenn Jocher, Jing Qiu, and Ayush Chaurasia. 2023. Ultralytics YOLO. https: //github.com/ultralytics/ultralytics AGPL-3.0 License. [29] Norman P. Jouppi, Cliff Young, Nishant Patil, David Patterson, Gaurav Agrawal, Raminder Bajwa, Sarah Bates, Suresh Bhatia, Nan Boden, Al Borchers, Rick Boyle, Pierre-luc Cantin, Clifford Chao, Chris Clark, Jeremy Coriell, Mike Daley, Matt Dau, Jeffrey Dean, Ben Gelb, Tara Vazir Ghaemmaghami, Rajendra Gottipati, William Gulland, Robert Hagmann, C. Richard Ho, Doug Hogberg, John Hu, Robert Hundt, Dan Hurt, Julian Ibarz, Aaron Jaffey, Alek Jaworski, Alexander Kaplan, Harshit Khaitan, Daniel Killebrew, Andy Koch, Naveen Kumar, Steve Lacy, James Laudon, James Law, Diemthu Le, Chris Leary, Zhuyuan Liu, Kyle Lucke, Alan Lundin, Gordon MacKean, Adriana Maggiore, Maire Mahony, Kieran Miller, Rahul Nagarajan, Ravi Narayanaswami, Ray Ni, Kathy Nix, Thomas Norrie, Mark Omernick, Narayana Penukonda, Andy Phelps, Jonathan Ross, Matt Ross, Amir Salek, Emad Samadiani, Chris Severn, Gregory Sizikov, Matthew Snelham, Jed Souter, Dan Steinberg, Andy Swing, Mercedes Tan, Gregory Thorson, Bo Tian, Horia Toma, Erick Tuttle, Vijay Vasudevan, Richard Walter, Walter Wang, Eric Wilcox, and Doe Hyun Yoon. 2017. In-Datacenter Performance Analysis of a Tensor Processing Unit. SIGARCH Comput. Archit. News 45, 2 (June 2017), 1–12. doi:10.1145/3140659.3080246 [30] LLC LF Projects. [n. d.]. Apptainer: Application containers for Linux. https: //apptainer.org. Accessed: 2024-12-10. [31] Huiba Li, Zhihao Zhang, Yifan Yuan, Rui Du, Kai Ma, Lanzheng Liu, Yiming Zhang, and Windsor Hsu. 2024. Block-level Image Service for the Cloud. ACM Trans. Storage 20, 1, Article 1 (January 2024), 28 pages. doi:10.1145/3620672 [32] Meelis Lootus, Kartik Thakore, Sam Leroux, Geert Trooskens, Akshay Sharma, and Holly Ly. 2021. A VM Containerized Approach for Scaling TinyML Applications. In Research Symposium on Tiny Machine Learning. https://openreview.net/ forum?id=m7Aqzt7Xf4S [33] Zhigang Lu, Yuewen Wu, Jiwei Xu, and Tao Wang. 2019. An Acceleration Method for Docker Image Update. In 2019 IEEE International Conference on Fog Computing (ICFC). 15–23. doi:10.1109/ICFC.2019.00010 [34] Andrew Machen, Shiqiang Wang, Kin K. Leung, Bong Jun Ko, and Theodoros Salonidis. 2018. Live Service Migration in Mobile Edge Clouds. Wireless Commun. 25, 1 (Feb. 2018), 140–147. doi:10.1109/MWC.2017.1700011 [35] Dirk Merkel. 2014. Docker: lightweight Linux containers for consistent development and deployment. Linux J. 2014, 239, Article 2 (March 2014). [36] Sparsh Mittal. 2019. A Survey on optimized implementation of deep learning models on the NVIDIA Jetson platform. Journal of Systems Architecture 97 (2019), 428–442. doi:10.1016/j.sysarc.2019.01.011 [37] Omogbai Oleghe. 2021. Container Placement and Migration in Edge Computing: Concept and Scheduling Models. IEEE Access 9 (2021), 68028–68043. doi:10.1109/ ACCESS.2021.3077550 [38] Containers organization. [n. d.]. Buildah: A tool that facilitates building OCI container images. https://buildah.io/. Accessed: 2024-12-10. [39] Reid Priedhorsky and Tim Randles. 2017. Charliecloud: unprivileged containers for user-defined software stacks in HPC. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (Denver, Colorado) (SC ’17). Association for Computing Machinery, New York, NY, USA, Article 36, 10 pages. doi:10.1145/3126908.3126925
[1] Martín Abadi, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Geoffrey Irving, Michael Isard, Manjunath Kudlur, Josh Levenberg, Rajat Monga, Sherry Moore, Derek G. Murray, Benoit Steiner, Paul Tucker, Vijay Vasudevan, Pete Warden, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng. 2016. TensorFlow: A System for Large-Scale Machine Learning. In 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16). USENIX Association, Savannah, GA, 265–283. https: //www.usenix.org/conference/osdi16/technical-sessions/presentation/abadi [2] Advanced Micro Devices. 2023. RDNA3 Shader Instruction Set Architecture. Advanced Micro Devices, Inc. https://www.amd.com/content/dam/amd/en/ documents/radeon-tech-docs/instruction-set-architectures/rdna3-shaderinstruction-set-architecture-feb-2023_0.pdf [3] Neil Brown. 2019. Overlay Filesystem. https://www.kernel.org/doc/ Documentation/filesystems/overlayfs.rst. [4] Jun Lin Chen, Daniyal Liaqat, Moshe Gabel, and Eyal de Lara. 2022. Starlight: Fast Container Provisioning on the Edge and over the WAN. In 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22). USENIX Association, Renton, WA, 35–50. https://www.usenix.org/conference/nsdi22/ presentation/chen-jun-lin [5] Lorenzo Civolani, Guillaume Pierre, and Paolo Bellavista. 2019. FogDocker: Start Container Now, Fetch Image Later. In Proceedings of the 12th IEEE/ACM International Conference on Utility and Cloud Computing (Auckland, New Zealand) (UCC’19). Association for Computing Machinery, New York, NY, USA, 51–59. doi:10.1145/3344341.3368811 [6] Cloud Native Computing Foundation and The Linux Foundation. 2023. Cloud Native Computing Foundation Annual Survey 2023. https://www.cncf.io/reports/ cncf-annual-survey-2023/ Accessed: 2024-11-08. [7] Marcin Copik, Eiman Alnuaimi, Alok Kamatar, Valerie Hayot-Sasson, Alberto Madonna, Todd Gamblin, Kyle Chard, Ian Foster, and Torsten Hoefler. 2025. XaaS Containers: Performance-Portable Representation With Source and IR Containers. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC ’25). Association for Computing Machinery, New York, NY, USA, 533–555. doi:10.1145/3712285.3759868 [8] Steve Crago, Kyle Dunn, Patrick Eads, Lorin Hochstein, Dong-In Kang, Mikyung Kang, Devendra Modium, Karandeep Singh, Jinwoo Suh, and John Paul Walters. 2011. Heterogeneous Cloud Computing. In 2011 IEEE International Conference on Cluster Computing. 378–385. doi:10.1109/CLUSTER.2011.49 [9] Thomas Durieux. 2024. Empirical Study of the Docker Smells Impact on the Image Size. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (Lisbon, Portugal) (ICSE ’24). Association for Computing Machinery, New York, NY, USA, Article 208, 12 pages. doi:10.1145/3597503.3639143 [10] Gölge Eren and The Coqui TTS Team. 2023. Coqui TTS. doi:10.5281/zenodo. 10363832 [11] Hadi Esmaeilzadeh, Adrian Sampson, Luis Ceze, and Doug Burger. 2012. Neural Acceleration for General-Purpose Approximate Programs. In 2012 45th Annual IEEE/ACM International Symposium on Microarchitecture. 449–460. doi:10.1109/ MICRO.2012.48 [12] Hao Fan, Shengwei Bian, Song Wu, Song Jiang, Shadi Ibrahim, and Hai Jin. 2021. Gear: Enable Efficient Container Storage and Deployment with a New Image Format. In 2021 IEEE 41st International Conference on Distributed Computing Systems (ICDCS). 115–125. doi:10.1109/ICDCS51616.2021.00020 [13] Cloud Native Computing Foundation. [n. d.]. Cloud Native Buildpacks. https: //buildpacks.io. Accessed: 2024-12-10. [14] Martin Gebser, Benjamin Kaufmann, and Torsten Schaub. 2012. Conflict-driven answer set solving: From theory to practice. Artificial Intelligence 187-188 (2012), 52–89. doi:10.1016/j.artint.2012.04.001 [15] genuinetools. [n. d.]. img: Standalone, daemon-less, unprivileged Dockerfile and OCI compatible container image builder. https://github.com/genuinetools/img. Accessed: 2024-12-10. [16] Lisa Gerhardt, Wahid Bhimji, Shane Canon, Markus Fasel, Doug Jacobsen, Mustafa Mustafa, Jeff Porter, and Vakho Tsulaia. 2017. Shifter: Containers for HPC. Journal of Physics: Conference Series 898, 8 (oct 2017), 082021. doi:10.1088/17426596/898/8/082021 [17] Panagiotis Gkikopoulos, Valerio Schiavoni, and Josef Spillner. 2021. Analysis and Improvement of Heterogeneous Hardware Support in Docker Images. In Distributed Applications and Interoperable Systems, Miguel Matos and Fabíola Greve (Eds.). Springer International Publishing, Cham, 125–142. [18] GoogleContainerTools. [n. d.]. "Distroless" Container Images. https://github.com/ GoogleContainerTools/distroless. Accessed: 2024-12-10. [19] GoogleContainerTools. [n. d.]. Jib: Containerize your Java application. https: //github.com/GoogleContainerTools/jib. Accessed: 2024-12-10. [20] GoogleContainerTools. [n. d.]. kaniko - Build Images In Kubernetes. https: //github.com/GoogleContainerTools/kaniko. Accessed: 2024-12-10. [21] Lin Gu, Deze Zeng, Jie Hu, Hai Jin, Song Guo, and Albert Y. Zomaya. 2021. Exploring Layered Container Structure for Cost Efficient Microservice Deployment. In IEEE INFOCOM 2021 - IEEE Conference on Computer Communications. 1–9. 12
CIR: Lightweight Container Image for Cross-Platform Deployment
[40] Alec Radford, Jong Wook Kim, Chris Hallacy, Aditya Ramesh, Gabriel Goh, Sandhini Agarwal, Girish Sastry, Amanda Askell, Pamela Mishkin, Jack Clark, Gretchen Krueger, and Ilya Sutskever. 2021. Learning Transferable Visual Models From Natural Language Supervision. In Proceedings of the 38th International Conference on Machine Learning (Proceedings of Machine Learning Research, Vol. 139), Marina Meila and Tong Zhang (Eds.). PMLR, 8748–8763. https://proceedings.mlr.press/v139/radford21a.html [41] Alec Radford, Jong Wook Kim, Tao Xu, Greg Brockman, Christine McLeavey, and Ilya Sutskever. 2023. Robust speech recognition via large-scale weak supervision. In Proceedings of the 40th International Conference on Machine Learning (Honolulu, Hawaii, USA) (ICML’23). JMLR.org, Article 1182, 27 pages. [42] Antonin Raffin, Ashley Hill, Adam Gleave, Anssi Kanervisto, Maximilian Ernestus, and Noah Dormann. 2021. Stable-Baselines3: Reliable Reinforcement Learning Implementations. Journal of Machine Learning Research 22, 268 (2021), 1–8. http://jmlr.org/papers/v22/20-1364.html [43] Vaibhav Rastogi, Drew Davidson, Lorenzo De Carli, Somesh Jha, and Patrick McDaniel. 2017. Cimplifier: automatically debloating containers. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (Paderborn, Germany) (ESEC/FSE 2017). Association for Computing Machinery, New York, NY, USA, 476–486. doi:10.1145/3106237.3106271 [44] Thomas Rausch, Alexander Rashed, and Schahram Dustdar. 2021. Optimized container scheduling for data-intensive serverless edge computing. Future Generation Computer Systems 114 (2021), 259–271. doi:10.1016/j.future.2020.07.017 [45] Nikhila Ravi, Valentin Gabeur, Yuan-Ting Hu, Ronghang Hu, Chaitanya Ryali, Tengyu Ma, Haitham Khedr, Roman Rädle, Chloe Rolland, Laura Gustafson, Eric Mintun, Junting Pan, Kalyan Vasudev Alwala, Nicolas Carion, Chao-Yuan Wu, Ross Girshick, Piotr Dollar, and Christoph Feichtenhofer. 2025. SAM 2: Segment Anything in Images and Videos. In The Thirteenth International Conference on Learning Representations. https://openreview.net/forum?id=Ha6RTeWMd0 [46] Robin Rombach, Andreas Blattmann, Dominik Lorenz, Patrick Esser, and Bjorn Ommer. 2022. High-Resolution Image Synthesis with Latent Diffusion Models . In 2022 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). IEEE Computer Society, Los Alamitos, CA, USA, 10674–10685. doi:10.1109/ CVPR52688.2022.01042 [47] Vasily A. Sartakov, Lluís Vilanova, Munir Geden, David Eyers, Takahiro Shinagawa, and Peter Pietzuch. 2023. ORC: Increasing Cloud Memory Density via Object Reuse with Capabilities. In 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23). USENIX Association, Boston, MA, 573–587. https://www.usenix.org/conference/osdi23/presentation/sartakov [48] Tim Shaffer, Nicholas Hazekamp, Jakob Blomer, and Douglas Thain. 2020. Solving the Container Explosion Problem for Distributed High Throughput Computing. In 2020 IEEE International Parallel and Distributed Processing Symposium (IPDPS). 388–398. doi:10.1109/IPDPS47924.2020.00048 [49] Tim Shaffer, Thanh Son Phung, Kyle Chard, and Douglas Thain. 2023. Landlord: Coordinating Dynamic Software Environments to Reduce Container Sprawl. IEEE Transactions on Parallel and Distributed Systems 34, 5 (May 2023), 1376–1389. doi:10.1109/TPDS.2023.3241598 [50] Weisong Shi, Jie Cao, Quan Zhang, Youhuizi Li, and Lanyu Xu. 2016. Edge Computing: Vision and Challenges. IEEE Internet of Things Journal 3, 5 (2016), 637–646. doi:10.1109/JIOT.2016.2579198 [51] Dimitris Skourtis, Lukas Rupprecht, Vasily Tarasov, and Nimrod Megiddo. 2019. Carving perfect layers out of docker images. In 11th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 19). [52] Ion Stoica and Scott Shenker. 2021. From cloud computing to sky computing. In Proceedings of the Workshop on Hot Topics in Operating Systems (Ann Arbor, Michigan) (HotOS ’21). Association for Computing Machinery, New York, NY, USA, 26–32. doi:10.1145/3458336.3465301 [53] Kun Suo, Junggab Son, Dazhao Cheng, Wei Chen, and Sabur Baidya. 2021. Tackling Cold Start of Serverless Applications by Efficient and Adaptive Container Runtime Reusing. In 2021 IEEE International Conference on Cluster Computing (CLUSTER). 433–443. doi:10.1109/Cluster48925.2021.00018 [54] Nydus Development Team. [n. d.]. Nydus: Acceleration Framework for Container Image. https://nydus.dev/. Accessed: 2024-12-10. [55] SlimToolkit Development Team. [n. d.]. SlimToolkit: Optimize Your Experience with Containers. https://github.com/slimtoolkit/slim. Accessed: 2024-12-10. [56] Jörg Thalheim, Pramod Bhatotia, Pedro Fonseca, and Baris Kasikci. 2018. CNTR: lightweight OS containers. In 2018 USENIX Annual Technical Conference (USENIX ATC 18). 199–212. [57] Katrine Wist, Malene Helsem, and Danilo Gligoroski. 2021. Vulnerability Analysis of 2500 Docker Hub Images. In Advances in Security, Networks, and Internet of Things, Kevin Daimi, Hamid R. Arabnia, Leonidas Deligiannidis, Min-Shiang Hwang, and Fernando G. Tinetti (Eds.). Springer International Publishing, Cham, 307–327. [58] Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, Clement Delangue, Anthony Moi, Pierric Cistac, Tim Rault, Remi Louf, Morgan Funtowicz, Joe Davison, Sam Shleifer, Patrick von Platen, Clara Ma, Yacine Jernite, Julien Plu, Canwen Xu, Teven Le Scao, Sylvain Gugger, Mariama Drame, Quentin Lhoest, and Alexander Rush. 2020. Transformers: State-of-the-Art Natural Language
Processing. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing: System Demonstrations, Qun Liu and David Schlangen (Eds.). Association for Computational Linguistics, Online, 38–45. doi:10.18653/v1/2020. emnlp-demos.6 [59] Tong Xing, Antonio Barbalace, Pierre Olivier, Mohamed L. Karaoui, Wei Wang, and Binoy Ravindran. 2022. H-Container: Enabling Heterogeneous-ISA Container Migration in Edge Computing. ACM Trans. Comput. Syst. 39, 1–4, Article 5 (July 2022), 36 pages. doi:10.1145/3524452 [60] Dali Yang and Wenbin Dai. 2022. A Lightweight Container Design for Microservice-based Industrial Edge Applications. In 2022 IEEE 17th Conference on Industrial Electronics and Applications (ICIEA). 858–863. doi:10.1109/ICIEA54703. 2022.10006175 [61] Zongheng Yang, Zhanghao Wu, Michael Luo, Wei-Lin Chiang, Romil Bhardwaj, Woosuk Kwon, Siyuan Zhuang, Frank Sifei Luan, Gautam Mittal, Scott Shenker, and Ion Stoica. 2023. SkyPilot: An Intercloud Broker for Sky Computing. In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23). USENIX Association, Boston, MA, 437–455. https://www.usenix.org/conference/ nsdi23/presentation/yang-zongheng [62] Deze Zeng, Hongmin Geng, Lin Gu, and Zhexiong Li. 2023. Layered Structure Aware Dependent Microservice Placement Toward Cost Efficient Edge Clouds. In IEEE INFOCOM 2023 - IEEE Conference on Computer Communications. 1–9. doi:10.1109/INFOCOM53939.2023.10229030 [63] Ahmed Zerouali, Tom Mens, Alexandre Decan, Jesus Gonzalez-Barahona, and Gregorio Robles. 2021. A multi-dimensional analysis of technical lag in Debianbased Docker images. Empirical Softw. Engg. 26, 2 (March 2021), 45 pages. doi:10. 1007/s10664-020-09908-6 [64] Zhicong Zhang, Heqing Huang, Shaowen Xu, Qihang Zhou, Tianshu Zhang, Xiaoqi Jia, and Weijuan Zhang. 2024. SummSlim: A Universal and Automated Approach for Debloating Container Images. In 2024 IEEE 30th International Conference on Parallel and Distributed Systems (ICPADS). 132–141. doi:10.1109/ICPADS63350.2024.00027 [65] Nannan Zhao, Hadeel Albahar, Subil Abraham, Keren Chen, Vasily Tarasov, Dimitrios Skourtis, Lukas Rupprecht, Ali Anwar, and Ali R. Butt. 2020. DupHunter: Flexible High-Performance Deduplication for Docker Registries. In 2020 USENIX Annual Technical Conference (USENIX ATC 20). USENIX Association, 769–783. https://www.usenix.org/conference/atc20/presentation/zhao [66] Nannan Zhao, Muhui Lin, Hadeel Albahar, Arnab K. Paul, Zhijie Huan, Subil Abraham, Keren Chen, Vasily Tarasov, Dimitrios Skourtis, Ali Anwar, and Ali Butt. 2024. An End-to-end High-performance Deduplication Scheme for Docker Registries and Docker Container Storage Systems. ACM Trans. Storage 20, 3, Article 18 (June 2024), 35 pages. doi:10.1145/3643819
13