Uber has introduced Normalized Compute Units, or NCUs, to make CPU allocation more consistent across a server fleet that mixes multiple generations of x86 hardware and ARM processors. The change is designed for Odin, Uber’s stateful orchestration platform, where treating every core as identical can lead to wasted capacity on fast machines or under-provisioned workloads on slower ones.
Why Uber moved beyond raw CPU cores
Uber says Odin manages about 5 million CPU cores across on-premises data centers and public clouds. In that environment, a core is not always a core in practical terms: single-threaded performance can vary by almost a factor of two between the fastest and slowest cores the company measured.
That variation creates a planning problem. If resource allocation is based on the slowest hardware in the fleet, faster machines may end up carrying less work than they could. If allocation is based on average usage, workloads can become too tight when they land on slower servers. For stateful workloads, that second failure mode is particularly risky because traffic often cannot simply be shifted elsewhere.
How Normalized Compute Units work in Uber’s Odin platform
Uber’s answer is to separate the compute performance a workload needs from the physical cores that provide it. Odin assigns each server type a performance factor, using an older server generation as the baseline value of 100. Some newer systems can reach factors approaching 190, according to Uber.
Those factors are not fixed forever. Uber said they are first established during hardware qualification and then refined using production workload data. The company also updates them based on observed behavior rather than relying only on synthetic benchmarks.
In practice, CPU usage is converted into normalized units through those performance factors. Odin can then translate the required computational capacity into a different number of physical cores depending on the server that will run the workload. A fast machine may receive fewer cores for the same workload, while a slower machine may receive more.
The point is not to force every instance to use the same number of cores. Instead, the goal is to make the amount of compute capacity represented by those cores more comparable across dissimilar hardware.
What changes for stateful workloads
Uber emphasized that this approach is especially useful for stateful systems. Stateless services can usually be balanced by sending traffic toward less loaded or faster machines. Stateful workloads do not always have that flexibility.
A request may need to reach the server that holds a specific shard or piece of data. Redirecting it to another machine does not eliminate the resource issue on the original server, which means CPU planning has to be more precise.
Uber gave an example in which a leader can consume more than ten times the CPU of its followers. If that leader moves from a fast server to a slower one, its CPU consumption can rise substantially even though the workload itself has not changed. That creates a real risk of resource pressure and instability, especially when capacity assumptions are based on average rather than actual performance.
Different hardware, different results
Uber also found that performance factors vary by technology. In its measurements for Kafka, the company saw meaningful differences between ARM systems, older on-premises hardware, and newer x86 systems. That is one reason the company relies on production measurements rather than depending only on benchmark scores gathered in isolation.
This matters because the same software stack may behave differently depending on the processor generation it runs on. The difference is not only theoretical: if an application needs more CPU on one platform than another, then a scheduling system that ignores hardware performance can easily misjudge how much capacity is really required.
Results from the Kafka rollout
Uber says it has already rolled the approach out across about 1.4 million CPU cores of automatically scaled Odin workloads. Kafka was one of the examples used in the post to show the effect of performance-aware allocation.
Before the change, CPU utilisation differed by around eight percentage points between server types, with the hottest hardware running at roughly 50% higher utilisation than the coldest. After introducing performance-aware allocation, that gap narrowed to around three percentage points, and the hottest hardware was only about 10% higher than the slowest.
Uber also reported a reduction in total Kafka CPU allocation of approximately 8%. Much of that reduction came from faster hardware, where the reclaimed capacity may be especially valuable.
Reported benefits from the new allocation model
- More consistent CPU utilisation across different server types
- Less over-provisioning on faster hardware
- Lower risk of under-provisioning on slower servers
- About 8% reduction in total Kafka CPU allocation
- Improved handling of leader-heavy stateful workloads
How this differs from Kubernetes CPU requests
Uber drew a distinction between its NCU model and the CPU abstraction used by Kubernetes. In Kubernetes, CPU requests are expressed as cores or millicores, and the abstraction deliberately treats a CPU unit as an absolute quantity of CPU time, regardless of the size of the underlying machine.
That model works well for portable workload definitions. It is useful when the main question is how much CPU time a container should reserve or how many workloads can fit on a node. But it does not, by itself, encode the relative performance differences between processor generations.
Uber’s approach is aimed at a different problem. Instead of asking only how many workloads can fit or how much CPU a service should get, it asks how much computational capacity a given CPU allocation actually represents on the hardware where the workload runs.
Why the distinction matters at scale
For smaller environments, CPU scheduling can often rely on a fairly simple assumption: a core is a core, and workloads can be moved when they need more room. Uber’s infrastructure is more complicated. With millions of cores spread across on-premises and cloud environments, and with a mix of architectures and hardware generations, the same allocation policy can produce very different results from one machine to another.
That makes performance-aware scheduling especially relevant for stateful systems, where rebalancing is limited by data locality and leadership roles. In that setting, a scheduler that understands relative performance can reduce noise in day-to-day operations and make capacity planning more stable.
Uber’s rollout suggests the model is already doing useful work in production rather than remaining an experimental concept. The Kafka results, in particular, show that normalization can reduce imbalance between machines while also trimming excess allocation.
What Uber’s NCU model signals for infrastructure teams
Uber’s move reflects a broader lesson for operators running mixed hardware fleets: not all CPU capacity is interchangeable, even when the units look the same on paper. As fleets age and new architectures are introduced, simple core counts can become less reliable as a planning tool.
NCUs offer one way to account for that reality without discarding the abstraction of CPU altogether. The model keeps the idea of a resource quantity, but layers in performance awareness so that the quantity reflects the real work a workload can do on a given server type.
For companies operating at similar scale, the appeal is clear. Better alignment between requested CPU and actual compute performance can improve utilization, reduce surprises, and make stateful systems easier to keep stable across diverse infrastructure.
Source: Original report
Was this helpful?
Explore more: DevOps Services More Cloud & DevOps Tech News
Last Modified: October 28, 2026 at 10:33 pm
2 views
