The accelerator does not execute an AI service alone. An agent generates a plan, calls a search or database tool, parses the result, transforms inputs and returns to the model, often one dependent step at a time. GPU throughput remains essential during model execution, but the gaps between those calls put serial control flow, pointer-heavy software and shared state back on the critical path. NVIDIA’s Vera white paper is therefore less interesting as another CPU launch than as an argument about system balance: a CPU paired with a large accelerator complex should not be provisioned like a conventional host. It should supply enough single-thread work, memory bandwidth and coherent data movement to keep the accelerators from waiting[1].
Vera implements that argument with 88 custom Armv9.2 Olympus cores, 176 hardware threads, 164 MB of shared last-level cache and eight SOCAMM2 memory modules. The modules hold 256 GB to 1.5 TB of LPDDR5X and reach 1.2 TB/s at 9600 MT/s. A dual-socket system doubles those resources to 176 cores, 3 TB and 2.4 TB/s. The architecture also exposes 88 PCIe 6.4 lanes per socket, CXL 3.1 Type-3 attachment and a 1.8 TB/s NVLink-C2C path to the GPU side. Peak quantities are not the main story, however. The important question is whether the CPU, cache, fabric and memory were sized against the same workload.
A wide core for dependent work
Olympus is a ten-wide design, which tells us where NVIDIA spent its transistor budget. Rather than using a larger count of narrower cores, Vera tries to retire more useful work from each thread. The front end can recognize as many as two taken branches per cycle and uses neural as well as specialized predictors. Each core has 64 KB of instruction cache, 96 KB of data cache and 2 MB of private L2. The white paper reports up to 1.9× the single-thread instructions per cycle of its comparison x86 processor, along with 2.3× more branch predictions and 3.5× more taken branches per cycle in selected microbenchmarks[1].
That choice matches the awkward part of agent execution. Tool dispatch, interpreters, retrieval logic and graph traversal do not present the regular matrix arithmetic that fills thousands of GPU lanes. They frequently wait on a branch, an object or a cache line before discovering the next unit of work. More cores help only when independent tasks exist; a wider core reduces the time of one dependency chain. Spatial Multithreading adds a second execution context per core for throughput, but it does not change the central wager: 88 stronger threads can be more useful beside GPUs than a larger headline core count starved by the memory system.

Memory bandwidth is provisioned per core
Vera’s clearest architectural statement is the ratio between cores and memory. Eight LPDDR5X controllers feed eight replaceable SOCAMM2 modules at an aggregate maximum of 1.2 TB/s, or nearly 14 GB/s for each of the 88 cores. NVIDIA reports 12.7 GB/s per core in a loaded measurement, versus 3.1 GB/s for the two-socket AMD EPYC 9755 system used as its reference[1]. Thus the measured figure reaches roughly 91% of the architectural per-core ceiling. This distinction matters: 14 GB/s is a quotient of peak interface bandwidth, while 12.7 GB/s is the result reported under the vendor’s test.
LPDDR5X supplies the bandwidth without reproducing the power profile of a high-capacity DDR5 subsystem. NVIDIA estimates approximately 30 to 40 W for a fully populated Vera memory configuration, depending on capacity, while stating that large DDR5 systems can exceed 100 W and MRDIMM configurations can pass 200 W. Those are system-level vendor estimates, not an independent module comparison. Still, they explain why the design accepts a less conventional server memory path. SOCAMM2 restores the field-replaceable module that soldered LPDDR lacked, and the white paper lists multi-symbol error correction, post-package repair, page retirement, channel sparing and module replacement among the RAS provisions.
The operational trade is not gone. SOCAMM2 is a newer supply and service ecosystem than DDR5 RDIMM, and fleet reliability cannot be inferred from a feature checklist. Capacity upgrades also depend on a compact module market that has not accumulated the breadth of conventional server memory. What Vera establishes is a plausible electrical and mechanical solution; failure rates, replacement logistics and pricing require production evidence.

Coherency must scale with the memory
A wide memory interface is wasted if a central cache or coherence point serializes requests. Vera distributes that work across a scalable coherent fabric (SCF) with 3.4 TB/s of bisection bandwidth and 164 MB of shared cache. The cache is physically partitioned around the fabric, allowing memory controllers, CPU cores and I/O agents to participate without funneling every transaction through one block. Within one socket, NVIDIA presents the machine as one NUMA domain. Two sockets become two NUMA nodes, which preserves a boundary software already knows how to manage rather than exposing every memory controller as a separate placement problem.
The external paths are similarly deliberate. NVLink-C2C provides 1.8 TB/s of coherent CPU-to-GPU bandwidth, PCIe 6.4 serves conventional devices, and CXL 3.1 permits Type-3 memory expansion. This does not make every byte equally close. Software still needs to distinguish local LPDDR5X, remote-socket memory, accelerator memory and CXL-attached capacity. However, the interfaces give the runtime a hierarchy it can reason about. Vera’s architectural claim is that coherence should remove unnecessary copies without hiding the placement costs that remain.

What the evaluation proves, and what it does not
The white paper supplies enough configuration detail to keep unlike results separate. In its memory tests, NVIDIA reports more than 3× the aggregate bandwidth of the comparison system, up to 40% lower loaded memory latency and 12.7 versus 3.1 GB/s per core. A graph traversal benchmark reports 2.6× performance, and ClickHouse reaches 1.2×. Four internal proxies for agentic work show up to 1.8× higher fully loaded per-core performance. Reinforcement-learning training, where CPUs prepare and route work around GPU phases, is reported at 1.8×[1]. These results support the thesis that the core and memory ratios matter most when the workload has irregular access or substantial CPU participation.
They do not establish a universal CPU ranking. NVIDIA authored the architecture, selected the workloads and ran the measurements. The principal comparison uses AMD’s 128-core EPYC 9755, while Vera has 88 cores per socket; per-core and system-wide charts therefore answer different questions. The estimated SPEC CPU 2026 rate is especially narrow evidence: the reference Vera system does not satisfy the benchmark’s availability rule, both machines use GCC 15.2 with vendor-specific architecture flags, and NVIDIA labels the result as estimated. Its reported two-socket rates, 925 for Vera and 898 for the AMD platform, are useful as a sanity check that Vera has not sacrificed general compute, but they should not be treated as submitted SPEC results.
Power evidence needs the same restraint. The CPU offers a configurable 250 to 450 W thermal design point, yet the white paper does not provide complete wall-power measurements for the application comparisons. A memory subsystem that saves tens of watts can still sit beside a CPU operating at the top of that range. The procurement question is energy per completed agent task, including memory and accelerator idle time, not the memory-module power in isolation.

What we take from it
Vera’s durable idea is not that LPDDR belongs in every server. It is that the host CPU beside an AI accelerator should be evaluated as part of the accelerator’s utilization loop. A narrow or memory-starved host can be inexpensive on its own and costly at system level whenever tools, retrieval, preprocessing or orchestration leave GPUs idle. NVIDIA responds by keeping the core count moderate, making each core wide, and assigning unusually high memory and coherence bandwidth to each one.
The design therefore changes the buying checklist. Core count and socket price are insufficient. Operators should measure CPU time on the dependency chain, achieved bandwidth per active core, accelerator bubbles attributable to host work, and joules per completed workflow. They should also test whether their software can place data across LPDDR, GPU memory, the second socket and CXL without turning the new hierarchy into copy traffic. Vera has a coherent architectural answer and detailed vendor evidence. Independent systems will determine whether that answer survives production software, fleet failures and total-platform power.
Source and attribution
This article is an editorial review prepared for Silicon & Systems from the NVIDIA Vera CPU Architecture White Paper, version 1.11, and the public materials cited above. We rewrote the architecture, evaluation conditions and limitations in our own words. No source sentence, table or figure is reproduced, and every figure on this page was created for this review. The white paper and product materials are (c) NVIDIA Corporation 2026.