Why AI native teams are asking for NVIDIA Vera to run their workloads on an 88 core agentic Arm CPU
For most of the last decade the interesting question about a data center CPU was how many cores it had and what they cost per hour. That question is now less useful than it looks. The workloads that determine how much an AI system costs to run have moved off the model and onto the layer around it. Orchestration, tool dispatch, sandboxed code execution, retrieval, and the operational plumbing that keeps an agent loop alive are all CPU work, and they are increasingly on the critical path. NVIDIA built Vera for exactly that path, and OCI will be the first cloud to deploy it at hyperscale.
OCI = First Hyperscaler with Vera Sysems
Oracle was thrilled to be one of the companies to receive the first Vera CPU Systems back in May of 2026, which were hand delivered by Ian Buck, VP of hyperscale and performance computing at NVIDIA, to OCI, Anthropic, OpenAI, and SpaceX.
First Vera CPU System delivered to Oracle AI Center of Excellence
(Left to Right: Gary Miller, EVP, Oracle Customer Success; Karan Batta, SVP, Oracle Cloud Infrastructure; Ian Buck, VP, Hyperscale and Performance Computing, NVIDIA)
As a result, we’ve had more time than most to evaluate the power of Vera CPU Systems across multiple workloads; from agentic, inference, and GPU fleet orchestration to in-memory databases and vector search and retrieval. This post is about what you would actually run on Vera once it is in your account. Not the architecture story, which NVIDIA has told well, but the concrete list of workloads that map onto an 88 core Olympus part with 1.2 TB per second of memory bandwidth, and why several AI native companies have already told us they want to move those workloads to Vera on OCI.
Start with what Vera is
Vera is NVIDIA’s first fully custom CPU, with a ground-up core called Olympus, built around the agent loop rather than around raw floating point throughput. Each socket carries 88 cores and 176 threads through NVIDIA’s spatial multithreading, up to 1.5 TB of LPDDR5X memory, and 1.2 TB per second of memory bandwidth. That bandwidth number is roughly three times what a current high-end x86 server part delivers per core, and it is the single spec that decides which workloads win on this chip.
Two facts follow from that. First, Vera is a strong host for the Rubin GPU inside the Vera Rubin platform, connected over NVLink C2C at 1.8 TB per second. Second, and more relevant for most readers, Vera is a serious CPU in its own right. NVIDIA ships it as the CPU behind standalone Vera servers, not only as a GPU head node. On OCI you will see it in both roles very soon.
A word on the numbers below. Some come from independent testing, the Phoronix suite in particular, which put a single-socket Vera on top of the field across code compilation, Python, Java, compression, and database work. Some come from NVIDIA’s own published claims, which are vendor figures and not yet independently reproduced. Where a number is NVIDIA’s rather than a third party’s, that is stated below. This distinction matters when you take these to a customer.
Why AI native companies want to move workloads to Vera on OCI
Three things come up consistently when we talk to AI native teams about Vera on OCI.
- The first is price and performance on the workloads they actually run. These are companies that measure cost per token and cost per completed task across the full stack, not cost per GPU-hour. When the layer around the model is a large and growing share of that cost, a CPU that is purpose-built for that layer changes the economics in a way a faster GPU does not. The memory bandwidth per core in particular gets called out as exceptional, because it maps directly to the concurrent, memory-scattered work these teams are bound by.
- The second is that OCI is first. OCI will be one of the first cloud providers to deploy Vera at hyperscale, with plans to deploy hundreds of thousands of units beginning this year. For a company whose product depends on agentic infrastructure, being able to run production agentic AI on Vera before that capacity is broadly available elsewhere is a real advantage, not a marketing point.
- The third is deployment flexibility. On OCI, Vera will be available as both bare metal and virtual instances, which suits the CPU nature of the offering and lets teams start small and grow. The teams we are working with are talking about starting with a handful of racks and scaling from there as the workloads prove out, and OCI’s model supports exactly that shape of adoption.
Uday Ruddarraju, CTO of Compute for OpenAI, put it best by stating “NVIDIA Vera’s high memory bandwidth and per-core performance on OCI make it a promising platform for emerging agentic AI workloads.” That is the workload thesis of this entire post, stated by a customer rather than by us. Loaded-core performance, meaning throughput when every core is busy under real concurrency, is precisely what the memory subsystem delivers, and agentic ai workload execution is precisely the workload it was built for.
Ideal workloads for Vera
Agentic orchestration and tool serving
This is the workload Vera was designed for, and it is the one AI native teams keep raising with us first. An agent platform spends most of its wall-clock time not inside the model but around it. Planning a task, deciding which tool to call, dispatching that call, waiting on it, parsing the result, and deciding what to do next. All of that runs on the CPU. When you are running thousands of concurrent agent sessions, the orchestration layer becomes the bottleneck long before the GPU does.
Vera’s core count and thread density help here, but the memory subsystem is what actually moves the needle. An orchestration layer under load is constantly touching small, scattered pieces of state. Session context, tool metadata, routing tables, and short-lived working data. Memory latency and bandwidth, not peak FLOPS, decide whether an agent step completes in nanoseconds or microseconds, and at high concurrency that difference compounds into your tail latency and your cost per completed task. With 1.2 TB per second of bandwidth sustained at around 90 percent of peak in STREAM TRIAD, Vera holds its throughput under exactly the kind of scattered, concurrent access pattern an orchestration layer generates.
Sandbox execution at density
Agents execute code. They spin up a sandbox, run something a model wrote, capture the result, and tear the sandbox down. Reinforcement learning environments do the same thing at larger scale, running many environment instances in parallel to generate training signal. Both are CPU workloads, and both are bound by how many isolated execution contexts you can pack onto a socket without them interfering with each other.
Independent testing from Prime Intellect put 176 virtual machines on a single Vera socket with spatial multithreading enabled and measured roughly 30 percent greater throughput per CPU than AMD Zen 5 on realistic RL sandbox workloads. Their steady state is 10 to 60 concurrent sandboxes per socket, each one small, single-threaded, bursty, and sensitive to startup latency and to memory latency under snapshotting. That profile is a close match for Vera’s strengths.
This is the workload that has generated the most direct pull from AI native companies. One team told us this is ideally suited to their rapidly growing agentic sandbox workloads, and that they plan to deploy at scale beginning in Q3. When a company running frontier-scale training tells you where they want to put a workload, that is the strongest signal you get about where a chip fits.
Control plane and orchestration for GPU fleets
There is a quieter use case that comes up in almost every conversation once the obvious ones are covered. The control plane. The scheduler, the placement logic, the health and telemetry pipeline, the routing layer that decides which request goes to which endpoint. Today most teams run that on general purpose CPU instances alongside their GPU fleet, and it works, but it is exactly the branch-heavy, latency-sensitive, memory-scattered work that Vera accelerates. Any GPU fleet running inference has a control plane, and that control plane is a natural Vera workload whether or not the GPUs themselves are Rubin.
Moving it to Vera is not glamorous, but it is high leverage. The control plane sits on the critical path of every request, so shaving latency there improves the whole system, and consolidating it onto a denser, more memory-capable part reduces the instance count you are paying for to keep the lights on.
Vector search and retrieval
Retrieval is memory-bound almost by definition. A vector index lives in memory, similarity search streams through it, and throughput tracks memory bandwidth far more closely than it tracks core clock. Vera’s 1.5 TB of LPDDR5X in a single socket is enough to hold a substantial index, a KV cache warm tier, and a working set of operational data without touching disk, and its bandwidth keeps the search itself fast under concurrency.
For a retrieval-augmented agent, this pairs naturally with the orchestration workload. The same socket that runs the agent brain can hold the retrieval index the agent queries, which removes a network hop from the hot path. That co-location is worth more to end-to-end latency than most retrieval-side optimizations people reach for first.
In-memory databases and columnar analytics
The database result is where the independent benchmarks are strongest. Phoronix ran Vera through code compilation, compression, Java, Python, and a ClickHouse OLAP workload, and the single socket came out ahead of a current 128 core x86 part on overall geomean by about 1.5 times, and ahead of Grace by about 1.6 times. Columnar analytics and in-memory databases are bandwidth-bound and cache-sensitive, which is Vera’s profile, so this result is consistent with the architecture rather than a surprise.
If you run operational analytics next to your AI workloads, an in-memory database, a feature store, a real-time aggregation layer, Vera is a strong home for it, and putting it on the same Arm platform as your orchestration simplifies your fleet.
Operational applications and general services
Not everything in an AI native company is an agent. There is a large surface of ordinary services. APIs, queues, schedulers, data pipelines, log processing, the middleware that holds a product together. Several teams have told us they intend to run operational apps on Vera alongside the agentic workloads, and the Phoronix results across compression, regex, JIT, and general compute say the chip is competitive on that broad category, not only on the AI-specific ones. Consolidating general services onto the same high-density Arm platform as the agentic workloads is a real operational simplification, one fewer architecture to run and reason about.
What is still being verified
Honesty about what is not yet nailed down matters more than one more benchmark chart. A few things are still open.
The independent testing so far ran on pre-production silicon in an open chassis, , so per-watt and per-dollar comparisons are not yet possible from public data. Real production thermal and power behavior will only be visible once the platform ships. The standalone Vera comparison against the parts it competes with most directly in the Arm category have not been run in public yet. OCI’s own benchmark work is aimed at closing exactly those gaps, on the real fabric with realistic data sizes, and we will publish it soon.
None of that changes the workload map. The architectural reasons Vera is ideal for orchestration, sandbox density, retrieval, and in-memory analytics are sound, and the independent numbers we do have point in the same direction. The precise multiples will move as the benchmarks mature. The list of what belongs on this chip will not.
Where to start
If you are running agentic workloads today on general purpose Arm or x86 instances, the migration path is short. The orchestration layer, the sandbox fleet, the control plane, and the retrieval tier are the four workloads that see the most benefit and carry the least migration risk, because they are already CPU work and already memory-bound. You do not need Rubin to start. A standalone Vera shape on OCI runs all four.
We are working with AI native teams on exactly these moves right now, and the pattern is consistent enough that it is worth stating as a recommendation. Put the layer around the model on the CPU built for it. That is what Vera is, and OCI is where you’ll be able to run it first.
Join us, live or virtually, at Oracle AI World 2026 to learn more about NVIDIA Vera CPUs on OCI!