Data Center Power and HDD Object Storage: A Modeling Framework
Workload structure: stock and flow
Traditional archives, media, backups, and data lakes can accumulate over time, but much data originates from users or devices rather than compute itself. Inference accumulates only persisted inputs, outputs, and logs. Reading shared models or retrieval corpora does not create new stored copies. Amazon Bedrock invocation logging is optional and disabled by default.
Training storage should start with shared cluster or project datasets, retained versions, and checkpoints, then add growth and retention policies. Repeated epochs increase reads rather than dataset size. NVIDIA distinguishes shared storage from local caches and recommends workload-specific sizing.
Model storage stock as surviving prior stock plus new unique persisted data. Do not subtract deletion twice if additions are already net of deletion. Deduplicate shared traditional and AI datasets across workload categories.
Traditional workloads: an illustrative calibration
Consider a hypothetical 10 kW compute rack adding 150 TB/year to HDD-resident logical storage, with 12% annual deletion of prior stock. That is approximately 411 GB/day or 4.8 MB/s of retained writes, and 15 EB of annual additions per GW of compute power. These are modeling assumptions, not measured industry averages.
The recurrence S(t) = 0.88 × S(t−1) + 150 TB has a steady-state stock of 1,250 TB/rack under constant generation and rack count. A cohort’s half-life is approximately 5.4 years. This can represent long-lived data, but not short-retention logs or rotating backups well.
Separate short-lived operational data from long-lived archives and fit cohort retention curves. Illustrative sensitivity cases of 75/150/300 TB per rack-year and 6%/12%/24% deletion test model sensitivity; they are not observed industry ranges. Historical GW/EB fit alone cannot uniquely identify generation and deletion.
AI inference: model persisted bytes, not only power
A hypothetical 130 kW rack adding 2,000 TB/year implies 5.5 TB/day, 63 MB/s, and 15.4 EB/GW/year—almost the same per-power intensity as the traditional example. The apparent per-rack uplift is therefore largely a power-density assumption.
Calculate additions from requests per year × unique bytes per request × persistence fraction × HDD-tier fraction, with compression handled consistently. Split text, generated media, and sensor analytics. An illustrative 100 requests/second retaining 10 KB each produces 31.5 TB/year before protection overhead; this is arithmetic, not a rack throughput benchmark.
Two PB/year may suit some media-heavy cases but overstate text services. Use separate expiry policies for logs and long-term retained content instead of applying 12% deletion universally.
AI training: size the shared cluster first
A hypothetical fixed 4,000 TB per 130 kW rack implies 30.8 EB/GW and 400 PB behind 100 racks. Validate that cluster total: a shared corpus does not grow automatically with rack count.
Use unique datasets plus retained versions plus retained checkpoints, multiplied by the HDD-resident share. Checkpoint size depends on model and optimizer state, while capacity depends on how many checkpoints survive. Active data may sit on SSDs while archival copies use HDDs. Derive TB/rack after cluster sizing; public evidence does not establish one reliable replacement average.
Converting GW into installed physical EB
Use occupied compute IT power, excluding cooling, networking, and storage power; distinguish nameplate capacity from average consumption and account for commissioning timing. If starting from facility power, establish the relevant IT-power and compute shares first.
Convert logical HDD-resident data to raw physical installed capacity using compression/deduplication, redundancy, spares, and operating headroom. Installed HDD stock is not annual HDD shipments, and not all HDD capacity serves object storage. Retained data can outlive the compute fleet that originally produced it.