Estimate HBM4 and SOCAMM2 Demand per Rack in Python
To estimate HBM4 and SOCAMM2 demand in Python, multiply rack count by the relevant GPU or CPU population, then calculate capacity and physical module counts separately. Keep an unknown CPU memory configuration unknown: a valid multiplication does not prove a supported server configuration or a customer order.
Quick check: Does your input describe memory per GPU, per CPU, or per module? Start with the no-CPU-population command below. Add module assumptions only when you can label their source. Never turn an “up to” capacity into an installed module count.
Checked October 19, 2026. Executed on Windows 11, Python 3.12.14 and 3.14.3, using only the standard library. This is a locally tested capacity worksheet—not a hardware measurement, an LLM benchmark, or a shipment forecast. No GPU, account, package installation, or API key is required.
- 1. Inputs: a reference specification describes a product; a scenario input describes what you assume.
- 2. Memory domains: HBM4 is GPU memory here; SOCAMM2 modules carry CPU-side LPDDR5X memory.
- 3. Python: a command-line argument is a value supplied when running a program; JSON is structured text output.
- 4. Results: capacity is an amount of data; module count is a number of assemblies.
- 5. Guardrails: null means not determined, not zero demand.
1. Separate reference inputs from assumptions
A reference input is a number tied to a named, dated specification. A scenario input is a value chosen to ask “what if?” Keeping them separate makes the output auditable: another reader can change a rack count without mistaking it for an announced deployment.
The current NVIDIA Vera Rubin NVL72 specification lists 72 Rubin GPUs, 36 Vera CPUs, and 288 GB of HBM4 per GPU. Those are the worksheet defaults. The rack-level GPU capacity is displayed as a rounded 20.7 TB. Do not apply these defaults to every system carrying the name NVL72.
Micron's March 16 announcement identifies a 192 GB SOCAMM2 product. That establishes a product capacity, not how many such modules populate any particular customer system. The program therefore has no default modules-per-CPU or module-capacity assumption.
For this worksheet, GB and TB are explicitly normalized as decimal units: 1 TB = 1,000 GB. GiB and TiB are different, binary units. Do not silently relabel a vendor capacity or an operating-system reading; check the original unit convention before adapting this worksheet.
2. Follow two separate multiplication paths
A memory domain is the memory associated with a particular processing side of this calculation. The GPU path produces HBM4 capacity. The CPU path first produces an assumed number of SOCAMM2 modules, then CPU memory capacity. Keeping two paths prevents a change in one input from silently changing the other.
Racks × GPUs/rack
× GB/GPU ÷ 1,000
Racks × CPUs/rack
× assumed modules/CPU
Then × GB/module ÷ 1,000
→ CPU memory in TB
For one reference rack, the GPU path is 72 × 288 = 20,736 GB, or 20.736 TB under the declared convention. This is more precise arithmetic from the selected inputs, not a claim that the vendor's rounded figure is wrong. Memory bandwidth, usable model capacity, and token throughput require different inputs; none is inferred here.
3. Run the standard-library Python worksheet
The worksheet is a small command-line program: it validates positive integer inputs, performs the two multiplications, and prints JSON. Save the complete block as rack_memory.py in a working folder. Open a terminal in that folder. Use the Python executable associated with your installation; python --version shows which interpreter that command selects.
"""Capacity worksheet, not an order forecast or hardware validator."""
import argparse
import json
def positive_int(text):
try:
value = int(text)
except ValueError as exc:
raise argparse.ArgumentTypeError("use a positive integer") from exc
if value <= 0:
raise argparse.ArgumentTypeError("use a positive integer")
return value
def main():
parser = argparse.ArgumentParser(description=__doc__)
parser.add_argument("--racks", type=positive_int, nargs="+", default=[1])
parser.add_argument("--gpus-per-rack", type=positive_int, default=72)
parser.add_argument("--cpus-per-rack", type=positive_int, default=36)
parser.add_argument("--hbm-gb-per-gpu", type=positive_int, default=288)
parser.add_argument("--modules-per-cpu", type=positive_int)
parser.add_argument("--module-gb", type=positive_int)
args = parser.parse_args()
if (args.modules_per_cpu is None) != (args.module_gb is None):
parser.error("supply --modules-per-cpu and --module-gb together")
rows = []
for racks in args.racks:
hbm_gb = racks * args.gpus_per_rack * args.hbm_gb_per_gpu
modules = None
cpu_tb = None
if args.modules_per_cpu is not None:
modules = racks * args.cpus_per_rack * args.modules_per_cpu
cpu_tb = modules * args.module_gb / 1000
rows.append({
"racks": racks,
"hbm4_tb": hbm_gb / 1000,
"socamm2_modules": modules,
"cpu_memory_tb": cpu_tb,
})
print(json.dumps({
"basis": "Capacity arithmetic only; not orders or a supported configuration",
"units": "decimal GB and TB; 1000 GB = 1 TB",
"inputs": vars(args),
"scenarios": rows,
}, indent=2, allow_nan=False))
if __name__ == "__main__":
main()
First run without a CPU population. The HBM4 result is calculated; the CPU results remain null.
python rack_memory.pyNext, try an explicitly hypothetical four-module-per-CPU population using a 192 GB module input. This combination has not been verified as an orderable configuration. Run the following as one line:
python rack_memory.py --racks 1 100 500 --modules-per-cpu 4 --module-gb 192--racks 1 100 500 runs three independent scenarios. It does not describe a rollout schedule, a market-size range, or a probability distribution. The output includes the supplied inputs so a copied result retains its assumptions.
4. Read the actual program output—not a hardware result
An execution result is what the program printed for the declared inputs. The following rows were produced on both tested Python versions. The calculation ran for real; the rack quantities and CPU population are still hypothetical.
| Racks | Calculated output |
|---|---|
| 1 | HBM4: 20.736 TB Modules: 144 CPU: 27.648 TB |
| 100 | HBM4: 2,073.6 TB Modules: 14,400 CPU: 2,764.8 TB |
| 500 | HBM4: 10,368 TB Modules: 72,000 CPU: 13,824 TB |
Try changing only --module-gb 192 to --module-gb 96. For one rack, CPU capacity becomes 13.824 TB while the module count stays 144 and HBM4 stays 20.736 TB. That is a useful sensitivity check, not a claim that a 96 GB population is validated.
One rack · 36 CPUs · four assumed modules/CPU · 144 modules in both cases
HBM4: 20.736 TB in both cases
5. Catch an invalid calculation before sharing it
Validation is checking whether an input meets the program's rules. Here that means positive whole numbers and a complete pair of CPU-population inputs. It does not establish electrical compatibility, permitted module populations, procurement lead times, or a supplier's share.
--racks 0, negative values, fractions, andNaNare rejected with exit code 2. No result JSON is printed.- Supplying only
--module-gb 192is rejected: module capacity and population must be provided together. - With neither CPU input supplied, the program succeeds but returns null CPU fields. Null is missing knowledge; zero would assert none.
- HBM4 capacity is not an HBM stack or die count. The code deliberately does not derive wafer needs, package yield, or supplier revenue.
- Hardware specification changes and unsupported configurations are not detected. Recheck the dated reference and exact bill of materials before interpreting a real deployment.
Seven CLI tests passed on each tested interpreter, including 24 bad-value subcases and two incomplete-pair cases. Tests checked decimal scaling, independent CPU/GPU inputs, preserved unknowns, and the density change shown above. Linux, macOS, actual racks, usable memory, and model-serving performance were not tested.
Summary: three outputs, three different claims
HBM4 TB describes calculated GPU memory capacity. SOCAMM2 modules describes an assumed assembly count. CPU TB adds the chosen module capacity. None describes orders or revenue. Before your next calculation, verify the generation, unit convention, and installed population; leave missing inputs null rather than filling them with a maximum.
Appendix: continue the same-language reading thread
- Vera Rubin NVL72 memory-demand scenarios explains the industry interpretation and why rack scenarios are not observed shipment volumes.
- Read SOCAMM2 capacity, bandwidth, and module-count specifications covers the unit and scope checks before you enter numbers.
- What Vera's reported memory cut means separates configuration changes from total market demand.
The program performs local arithmetic and prints to the terminal. It does not download specifications, write files, query a cloud account, or call a model. If you redirect output yourself, choose a new filename so you do not overwrite an existing file. Very large integer inputs are not a practical workload target for this teaching script.
Primary sources and reproducibility
- NVIDIA: Vera Rubin NVL72 specifications — dated reference inputs, checked October 19, 2026.
- Micron: March 16, 2026 production announcement — the 192 GB SOCAMM2 product, not a full system population.
- NIST: SI prefixes — decimal prefix convention.
- Python 3.12: argparse and json — command-line input and structured output. The code and diagrams here are original.
댓글
댓글 쓰기
안녕하세요 :)