---
title: "A GPU Container Pull Size Does Not Set Its Runtime Disk Requirement"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/gpu-container-compressed-layers-versus-runtime-storage"
last-updated: "2026-10-20"
---

# A GPU Container Pull Size Does Not Set Its Runtime Disk Requirement

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

A GPU container's compressed layer total describes packaged content, not the disk capacity its application needs. Uncompressed layer archives describe ordered filesystem changes; the visible root filesystem is the result of applying them. Host storage can also hold retained blobs, unpacked layers, writable state, logs and separately supplied model data. Compare offers at the same storage boundary and lifecycle stage before treating a smaller pull as a smaller deployment.

## Identify which bytes the pull claim counts

An offer that says the GPU application is a 2.5 GiB container leaves an essential question unanswered: 2.5 GiB of what? It could mean compressed layer content, an uncompressed archive total or a reported local image size. Those quantities cannot be substituted for one another.

OCI Image Specification v1.1.1 gives a descriptor a media type, digest and size. Size is the byte count of the referenced content. The layer specification defines uncompressed tar layers and gzip- or zstd-compressed tar layers. For a compressed layer, the descriptor therefore counts the compressed blob; it does not estimate extracted file allocation.

The image manifest also references a configuration object. A sum of its layer sizes alone excludes that object and the manifest, as well as network-protocol overhead and retries. Label such a sum as layer payload rather than total network traffic. Establish which image variant the number concerns; the related Arm-versus-x86 article explains platform selection.

References: [O1](https://raw.githubusercontent.com/opencontainers/image-spec/v1.1.1/descriptor.md), [O2](https://raw.githubusercontent.com/opencontainers/image-spec/v1.1.1/layer.md), [O4](https://raw.githubusercontent.com/opencontainers/image-spec/v1.1.1/manifest.md)

## Layers describe changes, not independent folders to total

OCI layers can add, modify or remove paths. The manifest orders them from the base upward, and their application produces the final image filesystem. A later version of a library at the same path replaces the version visible from an earlier layer. A whiteout records removal of an earlier path; the marker itself is hidden from the resulting view.

That operation does not edit the earlier layer blob. Its older content remains in the referenced image even though the final view no longer exposes that file. Counting every file represented across the layers consequently answers a different question from counting the files visible after all changes are applied.

The image configuration reinforces the distinction between representations. Its DiffID identifies a layer's uncompressed tar archive, whereas the corresponding manifest layer digest identifies the referenced blob, which may be compressed. Neither identifier states a disk requirement. Even an uncompressed tar byte count describes an archive, including its serialization, rather than the physical allocation of files on a particular host filesystem.

References: [O2](https://raw.githubusercontent.com/opencontainers/image-spec/v1.1.1/layer.md), [O3](https://raw.githubusercontent.com/opencontainers/image-spec/v1.1.1/config.md), [O4](https://raw.githubusercontent.com/opencontainers/image-spec/v1.1.1/manifest.md)

## Work a 2.5 GiB pull through two layers

Consider a fictional GPU application image with two compressed layer blobs. Layer A is 0.5 GiB and layer B is 2 GiB. Stipulate that neither is present locally, both are transferred exactly once, and the comparison counts only those layer payloads. The transferred layer total is 0.5 + 2 = 2.5 GiB.

Separately stipulate that their uncompressed tar streams are 2 GiB and 8 GiB. Their combined archive length is 10 GiB. These are invented sizes, not measured results for an application or a guaranteed compression ratio. Throughout this example, 1 GiB means 1,073,741,824 bytes; it is not a decimal GB.

Suppose A supplies a runtime library and a tool directory. B supplies a replacement for that library and records removal of the tool directory. The final view exposes the replacement and hides the removed tools. A's blob still belongs to this two-layer image.

The example gives no complete file-size inventory, so it cannot yield a final visible file total. The 10 GiB archive sum also cannot yield host allocation. A proposal calling 2.5 GiB its cold layer-transfer payload is making an interpretable claim. Calling it the application's disk requirement changes the claim without adding the evidence needed to support it.

A second proposal that labels 10 GiB as the uncompressed archive total is also interpretable. Relabeling that total as required free disk space would repeat the same mistake at a different boundary.

References: [O2](https://raw.githubusercontent.com/opencontainers/image-spec/v1.1.1/layer.md), [U1](https://physics.nist.gov/cuu/Units/binary.html)

## Host allocation depends on what the runtime retains

Docker's containerd image-store documentation, consulted on October 20, 2026, provides a concrete reason to distinguish an image view from its storage. It describes retaining compressed layers received from the registry as well as their unpacked contents. That is a named storage arrangement, not a rule that every runtime retains the same representations.

Docker's classic storage-driver documentation separately describes containers sharing read-only image layers while maintaining their own writable layers. A modification to an existing image file can introduce copy-on-write allocation; the behavior depends on the storage implementation. Launching another container is therefore neither necessarily another complete image copy nor necessarily zero additional storage.

The same distinction affects transfer comparisons. Docker documents reusing a layer already present locally instead of downloading it again. A warm host can receive fewer layer bytes than the cold-host example without reducing the application's contents. Conversely, another host with an empty store needs its own supply unless the delivery arrangement provides otherwise.

Retained application releases, caches, filesystem metadata and allocation behavior also affect the host total. Their treatment has to be established for the actual environment. Adding 2.5 GiB to 10 GiB does not establish an installation allowance or a runtime peak, even for a store retaining compressed and unpacked representations.

References: [D1](https://docs.docker.com/engine/storage/drivers/), [D2](https://docs.docker.com/engine/storage/containerd/), [D4](https://docs.docker.com/reference/cli/docker/image/pull/)

## Model weights and working data can sit outside the image

An application image may contain its model weights, or the deployment may supply them separately. For a fictional variation of the example, stipulate that the image contains the program and libraries while its selected weights live in a separate mounted volume. The 2.5 GiB layer payload then says nothing about the weight population in that volume.

Docker describes volumes as data stores whose contents exist outside a container's writable layer and lifecycle. A volume can consume storage even when a container-size figure excludes it. The same directory visible inside the application does not tell the buyer whether its contents arrived in the image or through a mount.

Separate weights, datasets, generated outputs, temporary working files and logs by where they are actually stored. Some may share a local device with the image store; others may belong to a remote service or another allocation. Their location determines which capacity boundary must accommodate them. Do not assume every GPU application downloads weights at startup or requires a new external storage appliance.

This leaves a specific purchasing comparison: one offer may include only the program image, while another includes separately delivered model data or a defined data allocation. Compare those deliverables explicitly. The related raw-versus-client-usable storage article owns the further question of how a storage capacity offer reaches the application's allocation.

References: [D1](https://docs.docker.com/engine/storage/drivers/), [D3](https://docs.docker.com/engine/storage/volumes/)

## Compare the same deployment stage before selecting equipment

A useful supplier statement connects the selected image to the storage resource and stage being described. Cold transfer, locally retained image content, initial container state and storage during the intended workload are separate observations. Ask the appointed platform team to reconcile them for its runtime, storage backend, retained releases, container population and separately supplied data.

For the fictional image, the evidence supports a 2.5 GiB cold layer payload and a 10 GiB uncompressed tar total. It supports no host-capacity target. A smaller compressed offer could reduce transfer while leaving other storage populations unchanged; an offer with the same image could require more local storage because it places additional model data there. The buyer needs the actual configuration and appropriate measurement, including the lifecycle stage relevant to the requirement.

Storage sizing and runtime configuration remain with the appointed platform and application teams. If their selected equipment requires physical installation, Leviathan's rack-and-stack service covers agreed equipment mounting, IT cabling, labels and physical installation records. Use the service and project-inquiry links to discuss that surrounding work with a nonconfidential equipment list, site, released rack and connection plans, and required physical handoff.

References: [L1](https://www.leviathansystems.co/services/rack-and-stack)

## Primary sources

- [O1 — OCI Image Specification v1.1.1: Content Descriptors](https://raw.githubusercontent.com/opencontainers/image-spec/v1.1.1/descriptor.md). Checked 2026-10-20. Descriptor size is the raw byte length of the referenced content, interpreted with its media type; it is not an expanded filesystem allocation.
- [O2 — OCI Image Specification v1.1.1: Image Layer Filesystem Changeset](https://raw.githubusercontent.com/opencontainers/image-spec/v1.1.1/layer.md). Checked 2026-10-20. Defines tar, gzip and zstd layer representations, path changes and whiteouts that affect the resulting filesystem view.
- [O3 — OCI Image Specification v1.1.1: Image Configuration](https://raw.githubusercontent.com/opencontainers/image-spec/v1.1.1/config.md). Checked 2026-10-20. Distinguishes an uncompressed-tar DiffID from the corresponding manifest layer digest.
- [O4 — OCI Image Specification v1.1.1: Image Manifest](https://raw.githubusercontent.com/opencontainers/image-spec/v1.1.1/manifest.md). Checked 2026-10-20. References configuration and layer objects separately and specifies the order producing the final image filesystem.
- [D1 — Docker Docs: Storage drivers](https://docs.docker.com/engine/storage/drivers/). Checked 2026-10-20. Explains shared image layers, writable state, copy-on-write and storage omitted from container-size reporting. Its implementation examples concern classic storage drivers.
- [D2 — Docker Docs: containerd image store with Docker Engine](https://docs.docker.com/engine/storage/containerd/). Checked 2026-10-20. Describes retaining compressed and unpacked layers in this image store. It supplies no universal allocation multiplier.
- [D3 — Docker Docs: Volumes](https://docs.docker.com/engine/storage/volumes/). Checked 2026-10-20. Volume contents exist outside a container's writable layer and lifecycle; mounted data must retain its own storage boundary.
- [D4 — Docker Docs: Image pulling and layer reuse](https://docs.docker.com/reference/cli/docker/image/pull/). Checked 2026-10-20. Its layer-reuse example explains why locally present content changes transfer without changing image contents.
- [U1 — NIST: Prefixes for binary multiples](https://physics.nist.gov/cuu/Units/binary.html). Checked 2026-10-20. Defines GiB as 1,073,741,824 bytes, distinct from decimal GB.
- [L1 — Leviathan Systems: Rack-and-Stack and Colocation Installation](https://www.leviathansystems.co/services/rack-and-stack). Checked 2026-10-20. Defines the agreed physical mounting, IT cabling, labeling and installation-record service relevant to a surrounding equipment project.

## Related Leviathan resources

- [Identify the selected Arm or x86 image variant](/articles/gpu-containers-arm64-versus-x86-platform)
- [Distinguish software components from build provenance](/articles/gpu-software-sbom-versus-build-provenance)
- [Resolve disconnected-deployment dependency supply](/articles/disconnected-gpu-deployment-artifacts-and-licenses)
- [Compare raw, protected and client-usable storage](/articles/gpu-storage-raw-versus-protected-usable-capacity)
- [Scope physical rack-and-stack installation](/services/rack-and-stack)
- [Discuss the surrounding physical installation project](/contact?service=rack-and-stack&from=%2Farticles%2Fgpu-container-compressed-layers-versus-runtime-storage)

## Discuss the physical installation around the selected equipment

Share a nonconfidential equipment list, site, released rack and cable plans, and required physical handoff to discuss installation scope and availability.

[Discuss the scope](/contact?service=rack-and-stack&from=/articles/gpu-container-compressed-layers-versus-runtime-storage)