Inferensys

Glossary

NUMA Affinity

A hardware-aware scheduling policy that pins a model serving process to a specific CPU socket and its local memory banks to minimize cross-socket memory access latency.
MLOps engineer reviewing model serving infrastructure on laptop, container orchestration visible, technical workspace.
HARDWARE-AWARE SCHEDULING

What is NUMA Affinity?

A hardware-aware scheduling policy that binds a process to a specific Non-Uniform Memory Access (NUMA) node to eliminate cross-socket memory access penalties.

NUMA Affinity is a kernel-level scheduling constraint that pins a software process or thread to a specific CPU socket and its directly attached local memory banks. In a multi-socket server, accessing memory attached to a remote socket incurs significantly higher latency and lower bandwidth than accessing local memory. By enforcing affinity, the operating system ensures that a model serving process allocates and accesses memory exclusively from the local NUMA node, preventing performance-degrading remote memory fetches during inference.

For latency-optimized model serving, NUMA affinity is critical to achieving deterministic P99 latency targets. Without it, the OS scheduler may migrate a serving process across sockets, causing unpredictable spikes in memory access time as the process suddenly references remote DRAM. This is enforced using tools like numactl or Linux cgroup cpuset controllers, which constrain the process's CPU and memory allocation to a single node, maximizing local cache hit rates and ensuring consistent, low-latency predictions.

HARDWARE-AWARE SCHEDULING

Key Characteristics of NUMA Affinity

NUMA affinity is a critical optimization for latency-sensitive model serving. By binding a process to a specific CPU socket and its directly attached memory, it eliminates the performance penalty of accessing remote memory across the inter-socket interconnect.

01

Local vs. Remote Memory Access

In a Non-Uniform Memory Access (NUMA) architecture, each CPU socket has its own local memory controller. Accessing local memory offers full bandwidth and minimal latency. Accessing remote memory attached to another socket traverses the inter-socket interconnect (e.g., AMD Infinity Fabric, Intel UPI), introducing a significant latency penalty—often 50-100% higher—and reduced bandwidth. NUMA affinity ensures the process's memory allocations are satisfied from the local node.

03

First-Touch Memory Allocation Policy

The Linux kernel's default memory policy is first-touch. A physical memory page is allocated on the NUMA node where the CPU first writes to it. To leverage this without explicit membind, an initialization routine can be run on the target NUMA node that sequentially writes to every element of a large tensor. This ensures the data is physically placed in the local memory banks of the socket that will perform the inference, maximizing bandwidth for subsequent reads.

04

Mitigating Cross-Socket Snooping

Modern CPUs maintain cache coherence across sockets using protocols like MESI. When a process bounces between sockets, it generates excessive cross-socket snoop traffic as the new socket's cache controller must probe the old socket's caches for modified data. This consumes QPI/UPI bandwidth and introduces latency. NUMA pinning eliminates this by ensuring all cache lines are owned and modified within a single socket's coherent domain.

05

NUMA-Aware Thread Pool Design

For multi-process serving engines like NVIDIA Triton Inference Server, NUMA affinity is applied per model instance. A common pattern is to launch one instance per NUMA node, each bound to its local GPUs and memory. This avoids the catastrophic scenario where a single instance's threads span sockets, causing half of every tensor operation to incur remote memory latency. This design treats each socket as an independent, high-performance compute island.

06

Performance Impact on Inference

The latency penalty for ignoring NUMA affinity is non-trivial for real-time inference. Benchmarks show that cross-socket memory access can increase P99 latency by 30-60% for large transformer models. This is because the time to load model weights from remote memory dominates the fast matrix multiplication on the local accelerator. For a Service Level Objective (SLO) of 10ms, a 4ms penalty from remote memory access is an unacceptable degradation.

30-60%
P99 Latency Increase
2x
Remote Access Penalty
NUMA AFFINITY EXPLAINED

Frequently Asked Questions

Clear, technically precise answers to the most common questions about Non-Uniform Memory Access and its critical role in optimizing high-throughput, low-latency model serving infrastructure.

NUMA affinity is a hardware-aware scheduling policy that pins a specific process or thread to a single CPU socket and its directly attached local memory banks. In a Non-Uniform Memory Access (NUMA) architecture, each CPU socket has its own dedicated memory controller and local RAM. Accessing this local memory is extremely fast, while accessing memory attached to a remote socket requires traversing an inter-socket interconnect, introducing significant latency. NUMA affinity works by leveraging operating system APIs like numactl or libnuma to restrict a process's memory allocation and thread execution to a single NUMA node, ensuring that the vast majority of memory accesses are local. This prevents the operating system scheduler from migrating threads across sockets and forces the memory allocator to prioritize local DIMMs, eliminating the performance penalty of remote memory access.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.