$UBER $ORCL EXECUTIVE SUMMARY
The source material describes a 24-month, 3-party co-optimization program among Uber Engineering, Oracle Cloud Infrastructure (OCI), and Ampere that culminated in the OCI AmpereOne M A4 instance family, with design inputs explicitly grounded in empirical issues observed when onboarding large-scale production services onto earlier OCI Ampere A1 and A2 generations during Uber’s cloud migration that began in 2/2023. The technical narrative is anchored on 3 bottleneck classes encountered during initial Arm adoption—(1) latency degradation on multi-socket Arm systems attributable to cross-socket link bandwidth limitations, (2) Go runtime instability and throughput loss under GOMEMLIMIT associated with TLB and cache constraints that amplified page faults and garbage-collection overhead, and (3) shortfalls in 1-thread performance versus on-prem x86 for select latency-critical services due to fixed-frequency behavior and lack of turbo clocking in Ampere Altra—followed by a set of silicon and system-level responses embodied in AmpereOne M and the A4 shape portfolio. The instance family is positioned as a workload-segmented platform rather than a monolithic “faster CPU” upgrade, with 2 explicitly stated workload archetypes (latency-sensitive stateless services and throughput-oriented storage systems) driving distinct choices across CPU frequency bins, VM versus bare metal deployment, core counts, memory-to-core ratios, and local NVMe versus network block storage. Independent OCI documentation clarifies that A4 is operationalized as VM.Standard.A4.Flex (up to 45 OCPU, where 1 OCPU equals 2 AmpereOne-M cores) and BM.Standard.A4.48 (48 OCPU, 768 GB, 1 x 3.84 TB NVMe, up to 1 x 100 Gbps), with Windows images not supported on these Arm shapes, reinforcing that the target environment is predominantly Linux-based cloud-native infrastructure. Oracle and Ampere marketing materials assert that A4 combines materially higher per-core performance and materially higher memory bandwidth than A2 and, in select benchmarks, competitive or superior price-performance relative to AMD EPYC-based OCI E6; these claims are directionally consistent with the architectural deltas (DDR5 bandwidth uplift, larger private and system caches, higher frequency bins) but remain benchmark- and configuration-dependent, with tail latency, allocator/GC behavior, and NUMA/I/O topology likely to dominate realized outcomes for Uber’s microservices and storage fleet.
CONTEXT AND SCALE SIGNALS
The co-optimization effort sits inside a broader platform-level transition to multi-architecture execution at Uber that is characterized, in the related Uber Arm enablement post, as a fleet of 5000+ services with CPU allocation concentrated in Go (60%) and Java (20%), and a migration path that has already resulted in 2800+ stateless Go services running on Arm and nearly 20% of OCI capacity shifted from x86 to OCI Ampere A1/A2 without a “serious incident.” Those disclosures matter because they imply that the A4 design targets not a narrow HPC niche but the median characteristics of a hyperscale microservice fleet: many small-to-medium services, relatively high sensitivity to jitter and tail latency, heavy allocator and GC activity (Go and Java), and substantial benefits from improving “performance per $ and per watt” at fleet scale. The source material also indicates that Uber’s migration uses both OCI and Google Cloud Platform, which frames the A4 effort as part of a multi-cloud procurement and resilience strategy where instance-level price-performance can translate into negotiating leverage and dynamic placement across providers, but also raises the bar on portability, observability parity, and architectural consistency across heterogeneous CPU ISAs.
ROOT-CAUSE LEARNINGS AND WHAT THEY IMPLY ABOUT UBER’S FLEET
The first learning—reduced latency-sensitive performance on multi-socket Arm during specJBB2015 critical Java operations per second and in Go benchmarks—was attributed to cross-socket link bandwidth limits in a multi-socket system. This is a particularly informative diagnosis because it suggests that early Arm capacity available to Uber for high core counts likely required multi-socket topologies where remote-memory access, cache-coherency traffic, and inter-socket synchronization were sufficiently costly to manifest in application-level throughput and latency, even in synthetic Java benchmarks designed to stress server-side execution paths. The implication is that Uber’s relevant workloads had either (a) enough shared-state synchronization and/or memory locality sensitivity that cross-socket effects were not masked by request-level parallelism, or (b) a tail-latency SLO regime where “average throughput” is less important than the slowest critical path, which is consistent with large microservice graphs in which the end-to-end latency is bounded by the slowest dependency call. Under either interpretation, a central design objective becomes minimization of NUMA complexity and cross-socket dependencies, which is explicitly connected in the source material to the preference for high core counts per socket to avoid multi-socket servers.
The 2nd learning—Go OOM errors under GOMEMLIMIT and degraded Go performance driven by smaller TLB and cache sizes—identifies a failure mode where architectural microdetails (TLB reach, cache capacity/latency hierarchy) interact with runtime memory management policy. This is a non-trivial observation because GOMEMLIMIT is intended to give a hard or semi-hard cap that shapes GC pacing; if the runtime is forced to collect more aggressively at a given memory ceiling, the efficiency of page scanning, heap metadata traversal, and allocator fast paths becomes materially more important. The disclosed root cause (TLB/cache artifacts leading to more page faults and slower GC) suggests that early-generation Arm cores, as deployed in the relevant OCI shapes, had insufficient translation and cache capacity for Uber’s Go service heap access patterns, turning GC into a higher-variance, more expensive tax. A direct implication is that “Arm readiness” in hyperscale microservices is not only a compiler/ABI problem but also a microarchitectural fit problem: identical code can behave differently under the same container memory regime when TLB miss rates or cache miss rates shift. As a portfolio signal, this supports the view that Arm datacenter adoption is increasingly gated by deep co-optimization of runtimes and silicon (and not just by availability of Arm server instances), and that customers with the scale and telemetry to isolate such effects can directly influence chip roadmaps.
The 3rd learning—performance shortfalls for latency-sensitive services requiring strong 1-thread performance (example given: Gurobi mixed integer programming solver) because Ampere Altra operated at a fixed 3.0 GHz with no turbo clocking—highlights a segmentation boundary inside the fleet. For horizontally scalable stateless services, 1-thread performance is often diluted by request-level parallelism and replicated deployment; however, services that embed computational kernels that are difficult to parallelize (optimization solvers, certain ML feature computations, scheduling algorithms, some encryption/compression paths, and other serial bottlenecks) can become “clock-bound,” especially when latency budgets prevent simply adding replicas. The “stranding of unused resources” framing is economically salient: in a fixed-frequency, no-turbo architecture, a partially utilized host yields no opportunistic frequency uplift to accelerate the active threads, so the marginal cost of provisioning extra cores for occasional spikes is higher than in turbo-enabled designs. This observation can be generalized into a deployment principle: Arm CPUs that emphasize predictable per-core behavior and high core density can be highly efficient for throughput-oriented, multi-threaded workloads, but will require either (a) higher base clocks, (b) turbo-like opportunistic boosting, or (c) workload-aware SKU binning to address the long tail of serial or latency-critical workloads in heterogeneous fleets.
A4 SILICON-LEVEL DELTAS AND HOW THEY MAP TO THE LEARNINGS
The Uber post presents a condensed specification comparison in which AmpereOne M materially increases clock headroom (up to 3.6 GHz for the 96-core model used in OCI), doubles L2 cache per core (2 MB versus 1 MB), increases system cache to 64 MB (from 16/32 MB), shifts memory from 8-channel DDR4-3200 to 12-channel DDR5-5600, and moves from PCIe Gen4 (up to 128 lanes) to 96 lanes of PCIe Gen5. Each of these deltas can be tied to the earlier pain points: larger L2 and system cache and (implicitly) a more capable memory subsystem reduce sensitivity to allocator/GC working sets and to instruction and data locality; higher base clocks reduce the gap to turbo-heavy x86 systems for serial bottlenecks; and higher bandwidth DDR5 helps workloads where memory throughput and latency are first-order constraints, including modern LLM inference with large token buffers and wide parallelism across cores.
OCI documentation adds precision to how these silicon attributes are packaged operationally. For A4 compute, 1 OCPU is defined as 2 AmpereOne-M cores (2 hardware execution threads), aligning with OCI’s cross-architecture billing normalization where x86 OCPU is typically mapped to 2 vCPUs due to SMT, while Ampere lacks SMT and instead maps OCPU to 2 physical cores for A2/A4. This definition has non-obvious consequences for benchmarking and capacity planning: “16 vCPU” equivalence across x86 and A4 does not imply equivalence in the underlying physical-core scheduling model, and comparisons can be skewed if software is tuned for SMT behavior (e.g., thread pools sized assuming 2 threads per core) or if performance counters are interpreted without accounting for “core as the scheduling quantum.” For Uber, whose fleet is described as already operating multi-arch and presumably multi-scheduler (Kubernetes, Mesos, or equivalent), this implies that scheduling policies and per-service CPU requests likely had to be normalized to “physical-core-like” units to prevent systematic overcommit or underutilization on Arm hosts.
A notable addition in OCI’s compute documentation is the explicit description of c-states and frequency scaling behaviors: on standard VM shapes, the hypervisor manages c-state transitions to avoid deep sleep states that can introduce wake-up latency, and it may disable c-states under sustained high utilization to keep CPUs in the C0 state at base frequency. For latency-sensitive microservices, this is relevant because frequency stability and avoidance of deep sleep can reduce jitter, but it can also raise baseline power draw, changing the price-per-watt dynamics that originally motivated Arm adoption. The hypervisor control plane thus becomes part of the performance envelope; this reinforces the Uber post’s preference to use VM deployment for latency-sensitive stateless services to avoid NUMA/I/O tuning and keep migrations simple, effectively outsourcing part of the power-state management complexity to OCI.
INSTANCE FAMILY CONFIGURATION: EXPLICIT WORKLOAD SEGMENTATION
The Uber post states that exploration spanned high-frequency Flex SKUs (3.6 GHz versus 3.2 GHz), bare metal versus VM, 92–192 cores, multiple core-to-memory ratios using 12-channel DDR5, and local NVMe versus remote block storage. This is best interpreted as an optimization over a multidimensional resource vector (core count, clock bin, memory capacity, memory bandwidth, storage locality, and virtualization overhead) rather than a 1-dimensional “bigger CPU” transition. The segmentation into 2 workload archetypes is operationally consistent with hyperscale infrastructure economics: (1) latency-sensitive stateless services prioritize predictable GC and per-core speed, and (2) throughput-oriented storage systems prioritize parallelism, memory efficiency, and storage capacity-to-locality fit.
For latency-sensitive stateless services, the post indicates an approximate design point of about 8 GB per vCore and a preference for VM deployment to avoid NUMA/I/O tuning. OCI’s published A4 shapes align almost exactly with this heuristic: BM.Standard.A4.48 provides 96 cores and 768 GB (8 GB per core), and VM.Standard.A4.Flex at its published maximum provides 90 cores and 700 GB (7.8 GB per core), placing the productized shapes directly on Uber’s stated memory-per-core target. This tight fit is a strong indicator that Uber’s memory-per-core telemetry was treated as a hard constraint in system configuration. It also suggests that A4 is optimized for “balanced” microservice deployments rather than for extreme memory-per-core ratios (e.g., in-memory analytics), consistent with the lower maximum memory capacity (768 GB in the A4 bare metal shape) relative to some high-memory x86 configurations. The 8 GB per core target also implies that, for a large fraction of stateless services, memory rather than compute may be a binding cost driver, since OCI prices CPU and memory separately; the co-optimization thus likely focused on improving per-core performance enough that fewer cores are needed for a given service, which indirectly reduces the required memory footprint under a fixed GB-per-core provisioning rule.
For throughput-oriented storage systems, the post emphasizes flexible memory-to-core ratios aligned to observed working-set sizes to improve packing efficiency without over-provisioning, and storage sized to locality, with local NVMe used when it matters and remote block storage when it does not. OCI’s A4 portfolio materially differentiates VM and bare metal on local storage: VM.Standard.A4.Flex is documented as “block storage only,” while BM.Standard.A4.48 includes 1 x 3.84 TB NVMe in addition to block storage. This structure is consistent with a pattern where stateful systems that benefit from local scratch (write-ahead logs, compaction buffers, cache layers, transient indexing, spillover for query engines) use bare metal for deterministic local I/O, while systems that prioritize durability and disaggregated storage use network block volumes and accept higher I/O latency in exchange for operational simplicity and elasticity. The implied risk is that local NVMe usage can create “hidden state” that complicates failover and rolling upgrades unless data placement, replication, and recovery semantics are explicitly engineered for ephemeral local devices; the upside is materially lower latency and higher throughput for I/O-bound phases that dominate end-to-end storage system performance. The post’s language (“when it matters”) suggests that Uber’s storage portfolio likely contains both patterns, and that the A4 design intends to provide a coherent host family that can serve both without forcing a global architectural choice.
PERFORMANCE CLAIMS: WHAT IS STATED VERSUS WHAT CAN BE INFERRED
The Uber post itself does not publish quantified end-to-end production metrics (e.g., p50/p95/p99 latency deltas, $/request deltas, or fleet-level utilization changes) but it provides the causal chain from observed bottlenecks to architectural responses. Quantified performance claims are instead found in Oracle and Ampere collateral. Oracle states that A4 has 20% higher core frequency, 50% more memory channels at 40% higher memory speeds (implying 2x memory bandwidth), and that customers migrating from A2-based VMs can expect up to 35% per-core performance improvement depending on workload, with benchmark callouts including up to 24% SPECint, 34% SPECfp, 35% STREAM Triad, up to 34% SPECjbb, and 35% Llama TPS. Ampere’s GA blog reiterates pricing and reports, for a 16 vCPU (8 OCPU) configuration, a reference 24% improvement on SPECrate2017_int_base (est.) versus A2, and it claims 16% higher performance and 27% better price-performance for A4 versus AMD EPYC Turin-based OCI E6 shapes on that benchmark. Ampere also reports a STREAM Triad result of 143 GB/s for A4 versus 53 GB/s for E6 (3.8x), and it frames CPU-based inference as economically competitive by claiming a 2x price-performance advantage for a 90-core A4 VM versus an NVIDIA A10 bare metal GPU instance on Llama 3.1 8B, under a constraint of 10 tokens/second per-user SLA.
Several analytical constraints apply to these claims. First, “per-core performance” comparisons can be confounded by OCPU definitions and by baseline configurations; A4’s OCPU maps to 2 physical cores, so any “16 vCPU” mapping must be verified as an apples-to-apples physical resource comparison. Second, benchmark sensitivity is high for workloads explicitly cited by Uber as problematic: GC-heavy runtimes and tail-latency sensitive services are not always well characterized by throughput-style benchmarks, and microarchitectural features (TLB sizes, cache hierarchy, prefetchers, branch predictors) can dominate. The Uber post’s emphasis on TLB/cache-induced page faults and GC slowdown indicates that improvements in caches and memory subsystem are likely to translate into practical gains for Go and Java services, but the realized benefit will vary by heap sizes, allocation rates, and memory locality patterns. Third, the GPU comparison for Llama inference is highly dependent on batch size, quantization, context length, parallelism strategy, and the operational definition of “simultaneous users” under a tokens/sec SLA; CPU-based inference can be compelling for small-to-mid models and for workloads where elasticity and cost granularity dominate, but GPUs retain structural advantages for high-throughput dense matrix operations and for larger models where compute intensity dominates memory bandwidth. The Ampere claims nevertheless highlight an important strategic vector for cloud economics: if a meaningful portion of inference demand shifts to CPU-based deployments for smaller models, the addressable market for high-cost “small inference GPUs” could be pressured, while demand for high-end training GPUs remains structurally supported.
ECONOMICS AND RESOURCE PRICING: IMPLICATIONS FOR CLOUD UNIT COST
OCI positions A4 pricing at $0.0138 per OCPU-hour and $0.0027 per GB-hour, with A4 built on the A2 model of resource-based pricing where CPU and memory are separate SKUs. OCI documentation states that A4 provisioning uses 1 OCPU = 2 AmpereOne-M cores, implying a compute-only list price of $0.0069 per core-hour, excluding memory and storage. Under Uber’s stated “about 8 GB per vCore” heuristic for latency-sensitive services, memory cost dominates: 8 GB per core equates to $0.0216 per core-hour in memory charges at list price, approximately 3.1x the compute charge per core-hour. This creates a structurally different optimization problem than in clouds that bundle memory with compute or price memory less aggressively: improvements that reduce required cores also reduce implied memory, producing a nonlinear cost benefit, whereas improvements that increase throughput without reducing core count may not reduce the dominant memory bill. The A4 shape design (8 GB per core at the top end) suggests that Uber and OCI are optimizing for a “balanced” microservice packing ratio where per-core memory is treated as necessary headroom for GC stability and latency predictability, not as optional overhead.
At the shape level, OCI documents BM.Standard.A4.48 as 48 OCPU (96 cores) and 768 GB memory with 1 x 3.84 TB NVMe and up to 1 x 100 Gbps; using the published list unit prices, this corresponds to a blended on-demand list cost of approximately $2.736 per hour (CPU plus memory) or approximately $1997 per 730-hour month, before storage, egress, and discounts. VM.Standard.A4.Flex at 45 OCPU (90 cores) and 700 GB corresponds to approximately $2.511 per hour or approximately $1833 per 730-hour month at list prices, again excluding storage and network egress. These calculations are illustrative rather than definitive, as negotiated rates, reserved capacity, and workload duty cycles typically dominate realized economics; nonetheless, the published unit economics reinforce why a hyperscale operator would engage in silicon-to-system co-design: small per-core improvements or small packing improvements can translate into very large absolute savings across 1000s of hosts when memory is the dominant line item and when core count reductions cascade into memory reductions under a fixed GB-per-core provisioning policy.
From a sustainability and efficiency perspective, Oracle and Ampere highlight performance per watt as a motivator, and Oracle explicitly claims that Uber runs over 20% of total OCI capacity on Ampere, cutting infrastructure costs and reducing power consumption by 30%. While the denominator (“total OCI capacity”) is ambiguous in the excerpted language and may refer to Uber’s OCI footprint rather than OCI’s global footprint, the magnitude indicates that energy efficiency is being treated as an economically material attribute, not only a CSR metric. If the 30% reduction is interpreted as power per unit of work for a meaningful portion of Uber’s OCI fleet, it implies that cost improvements are coming not only from lower $/OCPU but also from reduced power and cooling charges embedded in OCI’s infrastructure economics, which can support aggressive customer pricing without compressing provider margins.
COMPETITIVE POSITIONING: WHAT A4 SIGNALS ABOUT OCI’S STRATEGY
The A4 narrative reinforces OCI’s strategy of competing on price-performance and workload-specific infrastructure, similar in positioning (though not in vertical integration) to AWS Graviton. A4’s differentiators are framed around (a) core-density and predictable performance, (b) high memory bandwidth via 12-channel DDR5, and (c) broad availability of Arm compute across regions, with A1/A2 described as serving 1000+ customers in 65+ regions and A4 initially expected in major US/EU regions. The Uber case study is particularly valuable for OCI because it is a credible hyperscale workload with demonstrated multi-arch adoption and explicit performance root-cause analysis, rather than a contrived benchmark. As a strategic signal, co-optimizing silicon and instance configuration based on Uber’s telemetry suggests a willingness by OCI to tailor its fleet for high-volume customers, which can be a competitive lever in winning and retaining large accounts in a market where compute is increasingly commoditized.
However, OCI’s approach also embeds a supplier strategy trade-off. Unlike hyperscalers that design proprietary Arm CPUs, OCI relies on Ampere; the associated upside is speed-to-market and leveraging Ampere’s cloud-focused roadmap, while the downside is reduced control over long-term silicon cadence and differentiation. SoftBank’s completion of the acquisition of Ampere on 11/25/2025 is relevant in this context because it can change Ampere’s strategic priorities, capital structure, and ecosystem alignment (particularly given SoftBank’s majority ownership of Arm). The acquisition could accelerate Ampere’s ability to invest in next-generation cores and platform features, but it can also introduce strategic coupling that OCI does not control. OCI’s continued use of Ampere after Oracle’s reported stake sale (as described in external coverage) would be consistent with a “best available supplier” approach, but the dependency remains a structural consideration for long-term cloud differentiation.
