CIR: Lightweight Container Image for Cross-Platform Deployment

Abstract: 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 our evaluation, CIR reduces deployment time by 40-60% compared with pre-built images, outperforming state-of-the-art systems such as Docker, Buildah, and Apptainer.

• The paper introduces CIR, a novel container image paradigm that defers hardware-specific specialization to deployment time for enhanced portability.
• It employs a lazy-build architecture and uniform component model to reduce image size by up to 96% and lower build time by over 90%, outperforming traditional methods.
• Quantitative evaluations demonstrate significant improvements in network, compute, and storage efficiency for ML/AI applications deployed on heterogeneous infrastructures.

CIR: Lightweight Container Image for Cross-Platform Deployment

Overview

The paper "CIR: Lightweight Container Image for Cross-Platform Deployment" (2604.10411) introduces the Container Intermediate Representation (CIR), a novel image format and supporting ecosystem designed to substantially improve the portability, efficiency, and maintainability of container-based deployments in heterogeneous cloud and edge infrastructures. The CIR paradigm fundamentally diverges from conventional container building, which tightly couples application packaging with specific deployment hardware, by deferring environment specialization to deployment time. Through this lazy-build approach, CIR decouples software dependency specification from platform realization, enabling a single image artifact to instantiate correct, optimized containers across diverse CPU/GPU combinations with minimal developer intervention.

Figure 1: CIR enables a single image to be specialized for heterogeneous CPU and GPU configurations at deployment time, mitigating the need for platform-specific container builds inherent in traditional approaches.

Motivation and Systemic Analysis

Prevailing container image formats (e.g., Docker/OCI, SIF) require developers to construct platform-specific images incorporating compiled binaries, system libraries, and environment managers tailored to target architectures. This results in redundant build scripts (e.g., YOLO11 maintaining 10 different Dockerfiles), bloated registry storage, network transfer inefficiency, and high maintenance overhead for dependency updates and security patches. Importantly, this separation of build environment (opaque to hardware specifics) and runtime platform (opaque to build assumptions) induces mismatch and workload duplication, especially for interpreted-language workloads (Python, R) where application code is inherently portable but dependencies are not.

CIR directly addresses the core inefficiency: developer effort is wasted on speculative environment construction without access to deployment platform’s configuration. Instead, CIR proposes declarative specification of direct dependencies, with all platform specialization deferred to deployment via an intelligent lazy-builder and a componentized dependency graph.

CIR Abstractions and Lazy-Build Architecture

CIR introduces two primary architectural innovations:

1. Declarative Container Specification: CIR images encode only direct dependency identifiers and essential metadata (as opposed to imperative build scripts), enabling the lazy-builder to resolve and assemble full, platform-resolved environments on demand. All indirect and cross-manager dependencies are recursively resolved by the deployment platform in context.
2. Uniform Component Model: CIR uses uniformly packaged, immutable components—extracted from extant image, package, and source registries via automated converters—and catalogs these in a scalable uniform component registry. The lazy-builder deterministically constructs containers by evaluating deployability metrics (architecture, drivers, platform versioning, local cache status) for each dependency, ensuring correctness, consistency, and optimal reuse.

   Figure 2: Left—traditional image builders orchestrate several environment managers with imperative instructions; Right—the CIR lazy-builder assembles containers from uniform components managed by a dedicated registry, supporting fully declarative specification and optimal reuse.

The build pipeline comprises a pre-builder to analyze and codify direct dependencies (or import extant descriptors), and a lazy-builder which resolves, selects, caches, and assembles components using OverlayFS and OCI runtime standards at deploy time. Dependency resolution leverages a uniform, conflict-driven algorithm with context propagation for architecture- and device-aware specialization.

Figure 3: The CIR build system architecture—developers build CIRs locally, deployment platforms resolve and assemble containers using uniform components, with automatic sourcing and conversion as needed.

Quantitative Evaluation

Image Size and Build Latency

Empirical analysis using nine ML/AI applications across multiple platforms demonstrates that CIR reduces image size by up to 96% relative to Docker/Buildah/Apptainer. On the deployment side, CIR containers are constructed by fetching ~188MB CIR images and ~1822MB of uniform components, yielding significant decreases in both transfer volume and final container footprint by leveraging host-side component reuse and omitting redundant managers and caches.

Figure 4: CIR dramatically reduces image size for both CPU and GPU platforms by retaining only the necessary componentized dependencies and application code.

Network and Compute Efficiency

CIR consistently achieves 54–87% reductions in build time compared to baseline systems, with larger relative gains at higher network bandwidths—reflecting the overheads in baseline systems due to sequential layer construction and dependency installation. The CIR system's use of pre-processed and context-aware component selection demonstrates robust performance regardless of available compute or memory.

Figure 5: CIR outperforms other build systems under all tested bandwidth regimes, with divergence increasing at higher bandwidths due to removal of staging and compilation overhead.

Figure 6: Build times for CIR are resilient to variation in CPU core count and memory allocation, while baseline systems show significant sensitivity, especially those employing runtime image compression (e.g., Apptainer with SquashFS).

End-to-End Deployment

Results on full-scale ML/AI applications indicate CIR reduces end-to-end image build + deployment pipeline time by over 90% compared to Docker, Buildah, and Apptainer, translating to substantial improvements in developer productivity and resource utilization.

Figure 7: End-to-end metrics for representative applications show strong performance margins for CIR across build, deployment, and total times—on both CPU and GPU hosts.

Storage and Sharing Efficiency

By managing dependency granularity at the component (rather than layer, file, or chunk) level, CIR achieves higher cross-image sharing rates (21.6% passive, up to 69.5% GPU-active) while incurring lower object management overhead compared to chunk- and file-level deduplication strategies.

Figure 8: The pairwise component sharing rate within the benchmark suite; active component reuse dramatically increases storage efficiency.

Correctness, Consistency, and Workflow Integration

The lazy-build lifecycle guarantees functional correctness by only assembling containers from immutable, versioned components, subject to rigorous context-based dependency satisfaction. The determinism in the lazy-builder ensures that CIRs rebuilt on the same platform yield bit-identical results. This supports a reproducible, auditable deployment process—necessary for production, CI/CD, and regulated environments. The CIR ecosystem includes tool support for inferring CIR manifests from legacy images, facilitating gradual adoption and backward compatibility.

Implications and Future Directions

By decoupling dependency declaration from platform realization, CIR fundamentally improves maintainability, cross-platform migration, and operational agility in cloud-native and edge workloads. For interpreted-language systems, CIR eliminates redundant effort in maintaining heterogeneity-specific scripts and artifacts, accelerates patching cycles, and supports transparent workload mobility key to sky, edge, and multi-cloud computing paradigms.

The approach is orthogonal and complementary to runtime lazy-pulling methodologies—combining both could yield further reductions in cold start and migration latency. Extending the CIR approach to compiled languages remains challenging due to the centrality of architecture-specific binaries and the need for on-node compilation, demanding further exploration.

Potential future directions include:

• Expansion of supported ecosystems (JavaScript/Node, Julia, etc.)
• Integration with platform security attestation and signature schemes
• Enhanced policy models for active sharing under multi-tenant or restricted trust boundaries
• Automated dependency analysis and transitive vulnerability reporting

Conclusion

CIR presents a robust, practical realization of cross-platform, lightweight, and reproducible container image deployment for the modern, heterogeneous compute landscape. Its declarative, lazy-build abstraction, uniform component model, and aggressive deduplication enable high-performance, maintainable deployment pipelines aligned with the needs of machine learning, data analytics, and AI practitioners—marking a significant advance in the operationalization of cloud, edge, and hybrid computing workflows (2604.10411).