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.
Per-core bandwidth changes the software ceiling
Dividing 1.2 TB/s by 88 cores gives a useful balance indicator, but applications do not consume bandwidth evenly. A few streaming threads can approach the memory controllers while pointer-heavy or synchronized code waits on latency. The architecture must therefore be tested with concurrency and access patterns that resemble the control, preprocessing, storage, and communication work surrounding accelerators.
The important comparison is where performance stops scaling. Increase active cores and record useful work, memory bandwidth, cache misses, queueing, and power. A balanced design should postpone the point at which additional cores add contention rather than throughput. The location of that point will differ for compression, embedding lookup, data loading, networking, and general cloud services, so one aggregate benchmark cannot establish it.
NUMA placement and accelerator locality also matter. A core may have access to high aggregate bandwidth while its data or device interrupts sit behind a less favorable path. Runtime and operating-system policy should keep memory, I/O queues, and the CPU threads that manage an accelerator within the intended locality domain. Otherwise, the platform can buy wide memory and expose only a fraction of it to the critical software path.
Coherence capacity needs a workload, not a port count
More coherent bandwidth expands the amount of shared state that CPUs and accelerators can access, but every sharing pattern does not benefit equally. Read-mostly metadata, producer-consumer queues, and ownership transfer have different invalidation and ordering costs. A system test should state who writes each region, how often ownership moves, and whether synchronization occurs in hardware, runtime software, or the application.
This is especially important when CXL or a coherent accelerator link extends the domain. The physical link can carry the traffic while a directory, home agent, or endpoint becomes the ordering bottleneck. Average bandwidth may remain low even as tail latency grows from contention on a small set of lines. Evaluation should include hot metadata and synchronization patterns, not only streaming copies across a large address range.
Security and isolation remain separate from coherence. Sharing an address space does not authorize an endpoint to access every page, and revoking access must not leave stale mappings or cache state. Platform qualification should test device reset, virtual-machine reassignment, and memory protection changes under active traffic. These transitions often determine whether a coherent feature can be offered safely in a multi-tenant service.
The CPU should be priced by accelerator work completed
Vera is positioned beside accelerated systems, so its value is not captured by CPU benchmark leadership alone. The CPU prepares batches, handles network and storage, launches kernels, manages collective progress, and runs serial or branch-heavy parts of the application. If those tasks delay an expensive accelerator, additional CPU bandwidth or single-thread performance can have a large system return.
An acceptance test should measure accelerator idle time attributed to the host, data-preparation throughput, I/O service latency, and power at the node input. It should compare the same accelerator and workload with the candidate CPU and a relevant host baseline. This keeps GPU improvements, software updates, and CPU changes from being credited to one another.
The result should also separate local and rack effects. A faster host can feed one node while network or storage limits prevent the cluster from scaling. Conversely, stronger CPU processing can reduce bytes before they enter the fabric and improve the rack. Reporting both makes the CPU’s role visible without claiming that every accelerator workload is host-bound.
We read Vera’s 88-core and 1.2 TB/s balance as an architectural proposition: fewer, wider cores with more memory and coherent I/O can be preferable to maximizing core count around accelerators. The white paper establishes design intent and selected evidence. A durable system claim requires matched node measurements, locality analysis, coherent-sharing stress, power, and completed accelerator work across representative workloads.
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.