At Uber, we innovate where software meets hardware, building a deep understanding of our workloads so we can shape infrastructure around how we actually consume compute,  not how we provision it. This starts at the silicon layer, where we now collaborate with chip providers to optimize silicon and tailor OCI (Oracle Cloud Infrastructure^™), instance configurations for Uber’s real workloads.

Uber’s migration to Arm-based cloud infrastructure exemplifies deep cross-company collaboration that harnesses the strengths of OCI, Ampere Computing, and Uber Engineering. In February 2023, Uber began transitioning from on-premise data centers to the cloud using OCI and Google Cloud Platform^™, taking on the dual challenge of shifting massive workloads and introducing Arm-powered compute instances into a previously x86-dominated environment, supporting thousands of microservices and storage databases.

OCI’s leadership in adopting Ampere Arm-based processors reflected a strategic decision to drive cloud efficiency, with Ampere offering higher performance per watt, reduced energy consumption, and greater compute density—factors that benefit hyperscale providers and their enterprise customers. For Uber, partnering with OCI and Ampere brought the dual advantages of energy efficiency and hardware diversity, aligning with Uber’s sustainability goals and supporting operational flexibility in a dynamic supply chain landscape.​

Over the past 24 months, Uber, OCI, and Ampere have worked closely on numerous technical challenges and key innovations to dramatically improve price-performance curves for a large footprint of Uber workloads, setting the stage for supporting multi-architecture environments for years to come. 

In this blog, we discuss key innovations born from this partnership: the OCI AmpereOne^® M A4 instance family, which incorporates key optimizations and features informed by Uber Engineering’s experience with the previous generations of OCI Ampere A1 and A2 instances.

To fully appreciate the learnings and insights that went into designing the OCI Ampere A4 instances, it’s important to understand the technical challenges encountered while using the previous generation instances, as workloads were onboarded to Arm architecture for the very first time in the history of Uber. 

OCI Ampere A1 and A2 instances provided the foundation for the Uber platform to become Arm-ready. Uber implemented a strategic, multi-phase approach to enable Arm-based Ampere systems in its predominantly x86 environment, focusing on deep infrastructure, build, and deployment changes to support multi-architecture workloads.  

It was during early phases of onboarding that many of the learnings were discovered. Throughout this journey, Uber, Oracle Cloud Infrastructure, and Ampere engineering teams worked closely to innovate and successfully resolve issues to enable them the onboarding of additional workloads. As we got closer to testing production workload services, we learned more about how Uber’s software code interacted with the Arm instruction set architecture—insights that provided a crucial customer perspective for Ampere’s next-generation silicon development and OCI’s instance configurations.

Right out of the gate, when we started with synthetic benchmarking using specJBB2015^®, we noticed dual socket systems showed reduced performance for latency-sensitive operation (critical java operations per second). Go benchmarks also show sensitivity in operations execution speeds.  Collaborative efforts to debug these issues allowed us to identify root cause with the cross-socket link bandwidth in a multi-socket system. With the option to use high core counts per socket offered by Ampere^®, there was no longer the need for multi-socket servers that introduced communication latency between processors

Uber’s initial cohort of Go services showed out-of-memory (OOM) errors for the GOMEMLIMIT setting. We isolated the degradation in Go performance as mainly an artifact of smaller Translation Lookaside Buffers (TLB) and cache sizes in the silicon that led to more page faults and slower garbage collection. 

Uber’s compute platform also runs a set of very latency-sensitive services with single-threaded performance requirements that can’t be addressed through horizontally scaling alone. For example, services running the Gurobi^® mixed integer program solver that rely on the highest clock speeds. Uber services using Gurobi saw slow performance on the OCI A1 systems compared to the existing on-prem x86 servers due to the fixed 3.0GHz single-core frequency. The Ampere Altra^® CPU doesn’t support turbo clocking of cores, which meant that for workloads not running on all cores, there was stranding of unused resources.

OCI Ampere A1 and A2 instances provided the foundation to onboard Arm-based instances in Uber’s fleet. In addition, the learnings from benchmarks and running workloads at scale in production highlighted an opportunity to improve the price-performance of the OCI Ampere instance family. These insights catalyzed deeper collaboration to optimize the instances from silicon to system.

Our learnings led to Uber Engineering sharing detailed workload characteristics and performance targets with Ampere architects, which were instrumental in informing the design and optimization of the AmpereOne^® M silicon. Oracle and Ampere engineering also enabled a FlexSKU option based on Uber’s feedback for CPUs that had the highest single-thread performance.

Our collaboration focused on optimizing the OCI Ampere A4 instance family. Uber’s services at scale provided critical insights, enabling OCI and Ampere to translate observed workload attributes into optimal system configurations and instance specifications. We explored combinations of high-frequency Flex SKUs (3.6 GHz versus 3.2 GHz), bare-metal and virtual-machine deployments, 92-192 cores, multiple core-to-memory ratios using 12-channel DDR5, and local NVMe (Non-Volatile Memory Express) versus remote block storage. This close three-way collaboration involved co-optimization for the A4 instance family.

We anchored on two broad workload classes. For latency-sensitive stateless services, we prioritized per-core performance and predictable garbage collection: higher CPU frequency (about 8 GB per vCore) and VM deployment to avoid NUMA/I/O tuning and keep migrations from the previous generation simple. For throughput-oriented storage systems, we favored parallelism and memory efficiency at efficient clocks, with flexible memory-to-core ratios that align with observed working-set sizes to improve packing efficiency without over-provisioning, and storage sized to workload locality—local NVMe when it matters, remote block when it doesn’t—to meet demand without stranding capacity.

The journey from the first Arm-based deployments on OCI Ampere A1 and A2 to the collaborative optimization of OCI Ampere A4 represents more than an architectural upgrade. It’s a transformation in how Uber approaches infrastructure innovation. By engaging deeply from silicon to system, Uber Engineering has evolved from adapting to existing hardware influencing the next generation of compute optimized for our real workloads.

This collaboration between Uber, Oracle Cloud Infrastructure, and Ampere showcases what’s possible when software, systems, and silicon capabilities are precisely aligned to meet demanding workload needs. OCI Ampere A4 instances aren’t just faster or more efficient,  they embody a deeper integration between platform needs and hardware design, setting the foundation for Uber’s future of performance-driven, energy-efficient, and cost-optimized computing at scale.

To learn more about the new OCI Ampere A4 Compute, visit the Oracle Cloud Infrastructure Launch Blog, and the Ampere Launch Blog.

We’d like to thank the contributions of engineers across teams in Uber, Oracle and Ampere.  From Uber, Maz Zabaneh, Dan Song, Kshtiij Doshi, Shashi Aluru, Ben Wang, Amulya Nanjajjar

Stay up to date with the latest from Uber Engineering—follow us on LinkedIn for our newest blog posts and insights.