OpenMetal XL v5 Adds No Cores over XL v4. It Reworks Everything Around Them

The constant is the point: 64 cores, both generations

The most useful fact about the XL generation jump is a number that does not move. Per Intel ARK and the OpenMetal hardware specs, the Xeon Gold 6530 and the Xeon 6530P are both 32-core, 64-thread parts, so both XL tiers land at 64 cores and 128 threads per dual-socket node. For anyone sizing a fleet, this removes a variable. Core-licensed software (per-core database, hypervisor, or observability licensing) costs the same on either tier. NUMA layout stays two nodes. Thread-level capacity models carry straight across.

That constant reframes the decision. You are not choosing v5 for more compute lanes. You are choosing it for what each lane can do, how fast it is fed, and how much power it draws doing it. Everything below is a consequence of that framing.

Intel 7 to Intel 3: the same work at lower power, sustained higher

The move from Intel 7 (Emerald Rapids) to Intel 3 (Granite Rapids) is the root cause of most of the v5 gains. Its clearest system effect is thermal. The 6530 carries a 270 W TDP per socket; the 6530P carries 225 W, a 45 W reduction per socket and 90 W per node, and it does so while raising base clock from 2.1 to 2.3 GHz with an all-core turbo of 3.7 GHz.

For an SRE, the interesting part is not peak clock, it is sustained clock under an all-core load. Lower TDP at a higher base frequency means the part has more thermal margin before it has to pull frequency back during long vectorized or matrix-heavy runs. On a densely populated rack, 90 W less per node also compounds across a cabinet as real power and cooling budget that can go toward more nodes rather than more cooling. The node shrink is why the rest of this list is possible without a larger power envelope.

The cache that went down, and why bandwidth answers for it

Here is the number that regresses. The Emerald Rapids 6530 has 160 MB of shared L3; the Granite Rapids 6530P has 144 MB. Per core, that is 5.0 MB on v4 against 4.5 MB on v5. A generation newer, and less last-level cache. This is a real consequence of Granite Rapids using a smaller tile configuration for this SKU class, and it is worth stating plainly rather than hiding.

It matters most for workloads whose hot working set sits near the L3 boundary: certain in-memory indexes, tightly looped analytics kernels, and latency-sensitive caches that were tuned to fit inside 160 MB. For those, v4 can hold a genuine edge. What answers for the smaller cache on v5 is memory bandwidth. The moment a working set spills to DRAM, the v5 memory subsystem feeds it faster: 8 channels of DDR5-6400 deliver roughly 410 GB/s per socket against roughly 307 GB/s on v4’s DDR5-4800, about 33 percent more, at the same channel count. The design trade is less cache, much faster refill. For streaming and bandwidth-bound work, that is a win; for cache-resident work, it is a wash or a slight loss. We treat the full bandwidth story, including the network and PCIe fabric, in the companion editorial What OpenMetal v5’s Bandwidth Actually Unlock; the point here is narrower: the cache regression is real, and bandwidth is the reason it is an acceptable trade rather than a step back.

Lane budget and interconnect: feeding an all-NVMe node at full width

OpenMetal builds XL nodes as single-tenant, no-oversubscription machines, and on the storage tiers the drives are all-NVMe Ceph OSDs with no separate journal media. That design only pays off if the PCIe lane budget can carry the drives and the network adapters at full width at the same time. Granite Rapids raises PCIe 5.0 lanes from 80 to 88 per socket, which is 16 more lanes per node. Those lanes are the headroom that lets a node populate more NVMe bays and a wider NIC without the drives and the network contending for the same root-complex bandwidth.

The inter-socket link widens too. UPI moves from three links at 20 GT/s to four links at 24 GT/s, which increases cross-socket bandwidth for any workload that spans both NUMA nodes, including a Ceph OSD host whose network traffic and drive traffic cross the socket boundary. Granite Rapids also advances the platform from CXL 1.1 to CXL 2.0 with Type 3 memory-expansion support, which opens the door to memory tiering over CXL where a deployment calls for it. Treat CXL as a platform capability to validate against a specific build rather than a default of the shipping XL configuration.

AMX FP16 and doubled accelerators: more offload without discrete cards

On a single-tenant node, on-die accelerators are attractive because there is no neighbor to contend with and no discrete card to provision. XL v5 improves this surface in two ways. First, AMX, Intel’s matrix engine, gains the FP16 datatype on Granite Rapids; Emerald Rapids AMX supported INT8 and BF16 only. AMX throughput is on the order of 2,048 INT8 and 1,024 BF16 or FP16 operations per cycle per core, so FP16 support widens the set of inference models that run efficiently on the CPU itself before a workload needs a GPU.

Second, the data-path accelerators double. The 6530P exposes two instances each of DSA (data streaming), IAA (in-memory analytics), DLB (dynamic load balancing), and QuickAssist (crypto and compression offload), against a single default DSA device on the 6530. For a Ceph or database node, that is more headroom to offload compression, encryption, and data movement from the general cores, which keeps those cores available for the workload rather than for plumbing.

Confidential computing is a constant, not a v5 gain

It is worth stating what did not change, because it is easy to assume a newer generation adds it. Both XL v4 and XL v5 ship 1 TB at their base configuration, 16 modules of 64 GB in a full one-DIMM-per-channel fill, which already meets OpenMetal’s Intel TDX memory requirement. TDX is therefore enabled out of the box on both, and activation is a firmware step rather than a memory upgrade. SGX is available on both with 128 GB of enclave memory. Confidential computing is table stakes on the XL tier, not a reason to prefer one generation over the other. TDX on OpenMetal is a bare-metal capability; the OpenStack Hosted Private Cloud path does not provide TDX guest semantics.

What the generation adds up to

XL v5 is a generation that gets faster, cooler, and more capable at the same core count. The node shrink funds a 45 W per socket power reduction at a higher base clock; the memory subsystem delivers about a third more bandwidth; the I/O fabric gains lanes, interconnect, and drive bays; and AMX gains FP16 while the offload accelerators double. Confidential computing (TDX and SGX) is enabled at the 1 TB base on both generations, so it is a constant rather than a differentiator. The one honest caveat is that L3 cache is smaller than on v4, which is why the right choice is workload-shaped rather than automatic. If your hot path lives inside cache and rarely touches DRAM, v4 remains a serious option. If your work is bandwidth-bound or benefits from CPU-side FP16 inference or accelerator offload, v5 is the clear pick. Either way, the cores are the same; the question is what you need feeding them.