Memory tiering is a hardware and software architecture that creates a hierarchy of memory types—such as High Bandwidth Memory (HBM), GDDR, DDR system RAM, and NVMe storage—based on their performance, capacity, and cost. The system automatically promotes frequently accessed 'hot' data to faster tiers (like GPU HBM) and demotes less-used 'cold' data to slower, higher-capacity tiers (like host RAM or SSD) using techniques like demand paging and page migration. This creates a unified virtual address space, allowing applications to allocate more memory than physically exists in the fastest tier.
Glossary
Memory Tiering

What is Memory Tiering?
Memory tiering is a system architecture that organizes different types of memory into a performance and capacity hierarchy, automatically moving data between tiers based on usage.
This architecture is critical for large language model inference and data-intensive workloads, where model weights or context lengths exceed fast GPU memory capacity. By treating slower tiers as a backing store, it prevents out-of-memory errors and reduces the need for explicit, programmer-managed data swapping. Effective tiering relies on memory access pattern prediction and low-latency interconnects like PCIe and NVLink to minimize the performance penalty of fetching data from a lower tier, balancing the trade-off between massive working sets and high-speed computation.
Key Tiers in a GPU-Centric Hierarchy
Memory tiering organizes storage into a performance and capacity hierarchy, automatically moving data between tiers based on usage frequency to optimize cost and latency for large-scale AI workloads.
HBM: The On-Chip Performance Tier
High Bandwidth Memory (HBM) is the fastest tier, physically stacked on the GPU package using through-silicon vias (TSVs). It provides extreme bandwidth (>1 TB/s) and low latency for active tensors and the KV cache during inference.
- Primary Role: Holds the working set—the model weights, activations, and cache data actively being computed.
- Characteristics: Very high cost per GB, limited capacity (tens of GBs).
- Example: NVIDIA H100 GPU features 80GB of HBM2e with 3.35 TB/s bandwidth.
GDDR: The High-Capacity Device Tier
Graphics Double Data Rate (GDDR) memory is the traditional, high-capacity DRAM soldered onto the GPU board. It acts as a secondary, larger pool for less frequently accessed data or for GPUs without HBM.
- Primary Role: Expands the total device memory capacity beyond HBM limits at a lower cost.
- Characteristics: Lower bandwidth and higher latency than HBM, but higher capacity (up to hundreds of GBs).
- Use Case: Storing less-active model parameters or serving as a spillover for large batch inference.
DDR System RAM: The Host Backing Store
The server's DDR system memory (RAM) is a slower, CPU-accessible tier that serves as a backing store for GPU memory overcommit. Data is swapped via page migration triggered by GPU page faults.
- Primary Role: Holds evicted pages from GPU memory and acts as a staging area for data in transit.
- Characteristics: Accessed over PCIe, leading to significantly higher latency (microseconds vs. nanoseconds).
- Mechanism: Enabled by Unified Virtual Memory (UVM), allowing the GPU to directly address host memory.
NVMe SSD: The Nearline Storage Tier
NVMe Solid-State Drives represent a high-performance storage tier for cold data. With technologies like GPU Direct Storage (GDS), the GPU can bypass the CPU to fetch data directly, reducing I/O bottlenecks.
- Primary Role: Holds checkpointed models, massive datasets, or infrequently accessed parameters.
- Characteristics: Very high capacity (multiple TBs), but latency measured in milliseconds.
- Optimization: Demand paging can load model layers from SSD to GPU memory just before they are needed for computation.
Network & Object Storage: The Archival Tier
Remote network-attached storage (NAS) or cloud object stores (e.g., S3) form the coldest, highest-latency tier. Access requires network traversal and often CPU intervention.
- Primary Role: Archival storage for model repositories, training datasets, and logs.
- Characteristics: Latency can be seconds, but cost per GB is extremely low.
- Workflow Integration: Model serving systems pre-fetch from this tier into hotter tiers (SSD or RAM) during initialization or based on predictive loading.
The Tiering Controller & Policy Engine
Intelligent software manages data movement across tiers. It uses access heat tracking (frequency, recency) and predictive policies to make promotion/demotion decisions.
- Key Metrics: Monitors page fault rates, access patterns, and tier bandwidth utilization.
- Policies: Can be LRU (Least Recently Used), LFU (Least Frequently Used), or workload-aware.
- Goal: Maximize the residency of the working set in the fastest tiers (HBM/GDDR) to minimize latency, while using cheaper tiers for capacity.
How Does Memory Tiering Work?
Memory tiering is a system architecture that organizes different types of memory into a performance and capacity hierarchy, automatically moving data between tiers based on usage.
Memory tiering is a hierarchical system architecture that integrates multiple memory technologies—such as High Bandwidth Memory (HBM), GDDR, system DRAM, and NVMe storage—into a single, managed pool. The system automatically promotes frequently accessed 'hot' data to faster tiers (like GPU HBM) and demotes less-used 'cold' data to slower, higher-capacity tiers (like host RAM or SSD) based on access patterns. This is managed transparently by hardware and driver-level page migration, creating the illusion of a vast, fast memory space.
The mechanism relies on demand paging and GPU page faults. When a GPU kernel attempts to access a memory address not resident in its local HBM, a page fault occurs. The memory management unit then fetches the required memory page from a slower tier, potentially evicting another page. This dynamic movement, orchestrated by technologies like NVIDIA's Unified Memory, optimizes for both performance and capacity, allowing workloads to exceed physical GPU memory limits without manual data management from the programmer.
Primary Use Cases in AI/ML
Memory tiering is a foundational system architecture for managing the memory capacity and bandwidth demands of large-scale AI workloads. Its primary applications focus on cost-effectively scaling model size and improving hardware utilization.
Multi-Model & Multi-Tenant Inference Clusters
In shared GPU clusters serving diverse models (e.g., text, vision, embedding), memory tiering maximizes aggregate throughput and GPU utilization. The system acts as a global memory manager, automatically tiering models based on real-time request heat:
- Hot Models: Actively serving models remain GPU-resident.
- Idle Models: Models without recent requests are evicted to host memory. This enables dynamic model swapping, allowing the cluster to serve a larger portfolio of models than could fit simultaneously in GPU RAM. It's critical for cost optimization in SaaS inference platforms, turning GPU memory into a cache for a larger model library.
Overcoming GPU Memory Fragmentation
Long-running inference services suffer from memory fragmentation due to variable-sized KV caches and transient allocations. Memory tiering mitigates this by using a unified virtual address space that spans all memory tiers. When fragmentation prevents a large contiguous GPU allocation, the allocator can satisfy the request using non-contiguous pages from slower tiers, with the memory management unit handling the complexity. This increases effective memory utilization and reduces out-of-memory errors, providing more predictable performance for continuous batching workloads with dynamic request sizes.
Cost-Effective Fine-Tuning & Training
For full-parameter fine-tuning or training of large models, memory tiering expands effective working memory. The optimizer states, gradients, and model parameters that don't fit in GPU HBM can spill to CPU RAM or NVMe. While this introduces latency, it enables fine-tuning on consumer or lower-tier professional GPUs that would otherwise be impossible. Techniques like unified virtual memory with page migration are used, where pages are promoted to GPU memory when accessed frequently during backpropagation. This trades longer training time for significantly lower hardware capital expenditure.
Accelerating Data-Intensive Preprocessing
In multimodal pipelines (e.g., video understanding, medical imaging), the raw input data (videos, high-res images) can be terabytes in size, far exceeding GPU memory. A memory-tiered system streams data directly from NVMe storage to the GPU via GPU Direct Storage, bypassing the CPU and system RAM. The GPU's compute and decode engines process data in chunks, with the tiering manager ensuring the next data block is prefetched into a faster tier (e.g., CPU RAM) before the GPU needs it. This minimizes I/O wait time and keeps the GPU's tensor cores saturated, crucial for achieving high throughput in data-bound workloads.
Memory Tiering vs. Related Techniques
A comparison of system-level techniques for managing memory capacity and bandwidth across CPU, GPU, and storage.
| Primary Mechanism | Memory Tiering | Memory Overcommit (Oversubscription) | Unified Virtual Memory (UVM) | GPU Direct Storage (GDS) |
|---|---|---|---|---|
Core Objective | Organize memory types (HBM, DDR, NVMe) into a performance/capacity hierarchy for automatic data promotion/demotion. | Allow total allocated GPU memory to exceed physical capacity, using system memory/storage as a backing store. | Create a single, contiguous virtual address space shared between CPU and GPU for simplified data sharing. | Enable GPU to directly access data from storage (NVMe SSDs), bypassing CPU and host memory. |
Data Movement Trigger | Access heat (frequency/recency). Managed by OS/hardware. | Page fault on access to non-resident memory. Reactive migration. | Page fault on access to non-resident memory. Reactive migration. | Explicit application request or driver-managed prefetch. Proactive transfer. |
Typical Latency for Cold Data | Microseconds to milliseconds (depends on source: DDR vs. NVMe). | Milliseconds (involves CPU, host memory, and potential storage I/O). | Milliseconds (similar to overcommit, involves host memory/storage). | Tens to hundreds of microseconds (direct NVMe to GPU path). |
Transparency to Application | High. Managed automatically by system. | High. Managed by driver/OS with page migration. | High. Presents a unified pointer space. | Low. Requires API changes (e.g., cuFile) or compatible libraries. |
Primary Hardware/Software Enabler | OS memory management, CXL (Compute Express Link), smart memory controllers. | GPU page fault hardware, system memory as swap, driver-level page migration. | GPU page fault hardware, address translation services (ATS), IOMMU. | NVIDIA GPUs, NVMe SSDs, GPUDirect RDMA-capable NICs/HBAs. |
Optimal Use Case | Workloads with predictable, localized access patterns (hot/cold data). Large models with sparse active parameters. | Interactive or batch workloads where occasional high latency is acceptable for increased capacity. | Applications with complex, pointer-heavy data structures shared between CPU and GPU. | Data-intensive workloads (e.g., large-scale analytics, AI training) requiring high-throughput I/O to GPU. |
Key Advantage | Optimizes for both performance and cost by placing data in the appropriate tier automatically. | Maximizes GPU utilization by supporting larger working sets than physical VRAM allows. | Simplifies programming model by eliminating explicit memory copies and managing a single address space. | Minimizes I/O latency and CPU overhead, maximizing bandwidth for data ingestion. |
Key Limitation / Risk | Requires accurate heat tracking; mis-prediction can cause performance cliffs. Hardware support is evolving. | Can introduce unpredictable, high latency (stalls) if page fault rate is excessive. | Can suffer from high fault-handling overhead if data locality is poor, leading to thrashing. | Requires specific hardware and driver support. Application must be architected for direct access. |
Frequently Asked Questions
Memory tiering is a critical system architecture for managing the performance and capacity trade-offs in modern AI accelerators. These FAQs address its core mechanisms, benefits, and implementation.
Memory tiering is a system architecture that organizes different types of memory into a performance and capacity hierarchy, with data automatically promoted to faster tiers or demoted to slower tiers based on usage heat.
It works by treating the entire memory subsystem—from fast High Bandwidth Memory (HBM) on the GPU to slower system RAM (DDR) and even NVMe storage—as a single, unified virtual address space. A hardware or software-based memory management unit (MMU) tracks access frequency ("heat"). Frequently accessed ("hot") pages are kept in the fastest available tier, like HBM. Infrequently accessed ("cold") pages are transparently migrated to larger, slower, and cheaper tiers. This migration is often triggered by page faults when a GPU attempts to access a non-resident memory address.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Memory tiering operates within a broader ecosystem of memory technologies and management techniques. These related concepts define the hardware layers, software mechanisms, and performance characteristics that make tiered architectures possible and efficient.
Demand Paging & Page Faults
The core software mechanism that enables lazy, on-demand data movement in a tiered memory system.
- Demand Paging: Data resides in a slower tier (e.g., host RAM) until the GPU attempts to access it. Only then is it paged into fast GPU memory.
- GPU Page Fault: The exception raised when a GPU kernel accesses a virtual address whose physical page is not resident in GPU memory. This fault triggers the page migration engine to fetch the data.
- Analogy: Similar to virtual memory in traditional OSes, but optimized for high-throughput GPU workloads.
Memory Oversubscription
A technique where the total memory allocated to active GPU workloads exceeds the physical GPU memory capacity. It relies on system memory or storage as a backing store and is managed automatically by the tiering system via paging.
- Benefit: Allows users to run larger models or batch more requests than would physically fit in GPU RAM.
- Cost: Performance penalty due to page fault latency when accessing data not in the fast tier.
- Use Case: Essential for serving very large language models (e.g., 70B+ parameters) on GPUs with limited HBM.
Non-Uniform Memory Access (NUMA)
A memory design where access time depends on the memory location relative to the processor. In a tiered system with CPU host memory and GPU device memory, access is inherently non-uniform.
- Local vs. Remote: GPU access to its own HBM is 'local' (fastest). Access to CPU host memory over PCIe is 'remote' (slower). Access to NVMe over GDS is 'farthest' (slowest).
- System Design Implication: Tiering algorithms must minimize accesses to remote/far tiers by accurately predicting and promoting hot data.
- Contrast with UMA: In a Uniform Memory Access system, all memory is equidistant, which is not the case in CPU-GPU systems.

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.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us