A 9-core OpenAI dot VM on an AMD EPYC 9V74 posts a Geekbench 7 multi-core score of 9435. The packet has no figure, only the Geekbench listing and VM specs. The host is an 80-core part. It is Genoa, Zen 4, with base near 2.6 GHz and turbo near 3.7 GHz.

Each instance gets 9.73 GB of memory and 32 GB of storage. That is a small envelope for a Linux computer preloaded with Blender, Chromium, a terminal, and a file manager. The Geekbench 7 listing says Ubuntu 24.04.3, while a screenshot points to Debian, so the image is not settled. The preloaded list includes GIMP and Inkscape.

Die Brief reads the constraint as memory and storage, not cores. A 9-core slice can carry an agent, but 9.73 GB leaves little room for creative tools, and 32 GB is thin for a persistent workspace. The document does not prove full-node throughput, memory bandwidth, storage I/O, or whether the slice is pinned, shared, or noisy.

The missing numbers are the full 80-core aggregate score, memory bandwidth, storage path, and fleet-wide OS distribution. Without them, the Geekbench result is a slice test, not a host benchmark. The buyer sees a dense AMD EPYC 9V74 fleet, but the fab gets no proof that the whole node is being used at the same efficiency.

Die Brief reads the constraint as memory and storage, not cores. The Geekbench result proves a 9-core slice, not the full 80-core host.

The document leaves out full-node Geekbench, memory bandwidth, storage I/O, and whether the 9-core slice is pinned or noisy.

The 9.73 GB memory and 32 GB storage cap the agent workload before CPU throughput becomes the bottleneck. The Geekbench slice is useful for VM sizing, but it does not validate host-level bandwidth, I/O, or core pinning.