본문으로 건너뛰기

AI Inference Memory & Storage Architecture

LMCache, Tensormesh, WEKA, 그리고 FDP SSD 기반 AI Storage Stack 분석​

초록 (Abstract)

대규모 언어 모델(LLM) inference 시스템은 점차 단순한 연산(Compute) 중심 구조에서 메모리 및 스토리지 중심 구조로 변화하고 있다. Context window의 증가, Retrieval-Augmented Generation(RAG)의 확산, AI Agent 기반 워크로드의 등장으로 인해 KV(Key-Value) Cache의 저장, 이동, 재사용이 AI inference 시스템의 핵심 병목으로 부상하고 있다.

기존 inference 시스템은 KV Cache를 GPU HBM 내부에만 저장하는 구조를 전제로 설계되었다. 그러나 modern AI workload에서는 context length가 급격히 증가하고 있으며, GPU 메모리 용량만으로 모든 KV 데이터를 유지하는 것은 비용 및 확장성 측면에서 한계에 도달하고 있다.

이 문서는 LMCache와 Tensormesh를 중심으로 등장하고 있는 AI inference memory architecture를 분석하며, WEKA와 같은 distributed storage platform 및 Samsung FDP(Flexible Data Placement) SSD, High-Capacity SSD(HC SSD)가 이러한 workload에 어떤 방식으로 연결될 수 있는지 설명한다.

또한 AI inference 시대에서 storage system이 단순 persistence layer가 아니라 GPU memory hierarchy를 확장하는 active memory tier로 진화하고 있는 흐름을 다룬다.

1. Background

1.1 AI Infrastructure의 변화​

과거 AI 인프라의 중심은 Training이었다.

주요 목표는 다음과 같았다.

  • 더 많은 GPU 확보
  • 더 높은 FLOPS
  • Distributed training scalability
  • Gradient synchronization 최적화
  • Training throughput 향상

그러나 최근 AI 산업은 점차 inference 중심으로 이동하고 있다.

특히 다음과 같은 서비스들이 증가하고 있다.

  • Enterprise Copilot
  • Retrieval-Augmented Generation(RAG)
  • AI Agent
  • Long-context Assistant
  • Conversational AI
  • Persistent AI Memory

이러한 workload에서는 모델 학습보다 inference serving 비용이 더 중요해지고 있다.

즉:

Training 중심 시대:
Compute scaling

Inference 중심 시대:
Memory / Storage / Data movement scaling

으로 패러다임이 변화하고 있다.

1.2 KV Cache의 중요성​

Transformer 기반 모델은 attention 연산 과정에서 KV(Key-Value) tensor를 생성한다.

Inference 과정은 크게 두 단계로 구분된다.

Prefill Phase​

  • 입력 prompt 전체 처리
  • Attention 계산 수행
  • KV tensor 생성
  • KV cache 저장

Decode Phase​

  • 이전 token의 KV cache 재사용
  • 신규 token만 계산
  • 전체 prompt 재계산 회피

KV cache 크기는 다음과 같이 증가한다.

genui{"math_block_widget_always_prefetch_v2":{"content":"\text{KV Cache Size} \propto \text{Context Length} \times \text{Layer Count} \times \text{Hidden Dimension}"}}

Long context 및 대형 모델에서는 KV cache 크기가 요청당 수 GB 수준까지 증가할 수 있다.

이로 인해 GPU HBM 용량이 inference scalability의 핵심 제약 조건이 되고 있다.

2. 기존 LLM Inference Architecture의 한계

2.1 GPU HBM 중심 구조​

기존 inference engine(vLLM 등)은 일반적으로 KV cache를 GPU HBM 내부에 유지한다.

GPU HBM
 └── KV Cache

이 구조는 매우 빠른 access latency를 제공하지만 다음과 같은 한계를 가진다.

문제점​

  • GPU 메모리 용량 제한
  • Long context 확장 어려움
  • Worker 간 cache 공유 어려움
  • Process restart 시 cache 손실
  • Multi-node reuse 어려움
  • GPU 비용 증가

특히 GPU HBM은 매우 빠르지만 매우 비싼 자원이다.

GPU HBM:
Fast but expensive and capacity-limited

2.2 Prefill 재계산 문제​

Enterprise AI workload에서는 동일한 context가 반복적으로 등장한다.

예:

[System Prompt]
[Company Documents]
[Conversation History]
[User Question]

그러나 대부분의 inference engine은 매 요청마다 prefill을 다시 수행한다.

즉:

동일한 Attention 계산 반복
→ GPU FLOPS 낭비
→ TTFT 증가
→ GPU 비용 증가

문제가 발생한다.

3. LMCache Architecture

3.1 LMCache 개요​

LMCache는 LLM inference를 위한 KV cache offloading 및 reuse framework이다.

핵심 목표는 다음과 같다.

"이미 계산한 KV cache를 재사용하여
GPU 연산을 줄이자"

LMCache는 GPU 외부 memory/storage 계층을 활용하여 KV cache를 저장하고 복원한다.

3.2 Memory Hierarchy​

LMCache는 다음과 같은 hierarchical memory 구조를 사용한다.

GPU HBM
   ↓
CPU DRAM
   ↓
Local NVMe SSD
   ↓
Remote Distributed Storage

즉 GPU memory를 storage까지 확장하는 구조라고 볼 수 있다.

3.3 KV Offloading Flow​

Prefill 이후 생성된 KV cache는 다음 경로를 따라 저장된다.

GPU HBM
   ↓ DMA / memcpy
CPU pinned memory
   ↓ async I/O
NVMe SSD

LMCache의 중요한 특징은 asynchronous offloading이다.

Inference thread:
"KV 저장 시작"
→ decode 계속 수행

즉 storage write가 inference execution을 block하지 않도록 설계된다.

3.4 KV Restore Flow​

동일한 prompt 또는 reusable context가 다시 등장하면:

SSD / DRAM
   ↓
KV Restore
   ↓
GPU HBM 재주입

을 수행한다.

이를 통해:

  • Prefill 생략
  • TTFT 감소
  • GPU FLOPS 절감
  • GPU memory pressure 감소

효과를 얻을 수 있다.

4. Tensormesh의 역할

4.1 LMCache와 Tensormesh의 관계​

LMCache는 오픈소스 KV cache engine에 가깝다.

반면 Tensormesh는:

"Distributed AI Memory Infrastructure"

를 구축하려는 플랫폼 회사에 가깝다.

관계는 다음과 같이 이해할 수 있다.

LMCache:
KV cache 기능 제공

Tensormesh:
KV cache를 데이터센터 규모에서 운영/공유/최적화

4.2 Tensormesh가 해결하려는 문제​

1. GPU Memory 비용 문제​

KV cache를 GPU HBM에만 유지하면 비용이 매우 높다.

2. Repeated Prefill Problem​

동일한 system prompt 및 document context가 반복 계산된다.

3. Worker-local Cache 문제​

기존 cache는 worker 단위로 고립된다.

Worker A cache ≠ Worker B cache

4. Cluster-wide Reuse 부재​

Cluster 전체에서 reusable KV를 공유하기 어렵다.

5. WEKA와 Distributed Storage

5.1 WEKA란?​

WEKA는 GPU/AI workload를 위한 distributed storage platform이다.

기존 storage가 단순 file persistence 역할을 수행했다면, WEKA는 GPU에 매우 빠르게 데이터를 공급하는 memory-adjacent storage 역할을 목표로 한다.

5.2 LMCache + WEKA 구조​

vLLM
  ↓
LMCache
  ↓
WEKA Distributed Storage

WEKA는:

  • Distributed NVMe
  • RDMA networking
  • GPUDirect Storage(GDS)
  • Parallel storage access

를 활용하여 KV restore latency를 줄이려 한다.

6. Samsung SSD와 FDP

6.1 삼성의 역할​

Samsung은 AI inference stack에서 다음 계층에 해당한다.

Storage Device Layer

즉 LMCache/Tensormesh/WEKA가 저장하는 KV cache를 실제로 저장하는 physical storage device를 제공한다.

6.2 FDP(Flexible Data Placement)​

FDP는 host가 SSD 내부 data placement를 제어할 수 있도록 하는 기술이다.

핵심 목표:

Write Amplification 감소
GC 비용 감소
Tail latency 감소

6.3 왜 LMCache Workload가 FDP에 잘 맞는가​

LMCache workload는:

  • Sequential append-heavy
  • WORM 성향
  • Similar lifecycle grouping 가능
  • Overwrite 비율 낮음

특성을 가진다.

이는 FDP가 target하는 workload와 매우 잘 맞는다.

즉:

KV chunk lifecycle-aware placement

최적화 가능성이 존재한다.

7. High-Capacity SSD(HC SSD)의 가능성

7.1 LMCache Workload와 HC SSD​

LMCache workload는:

Large Sequential Write
+
Read-heavy Reuse
+
WORM Pattern

특성을 가지므로 HC SSD와 상대적으로 잘 맞을 가능성이 있다.

특히:

  • 높은 capacity
  • 낮은 $/TB
  • Large KV pool 구성 가능

장점이 존재한다.

7.2 핵심 Tradeoff​

핵심 문제는 다음과 같다.

genui{"math_block_widget_always_prefetch_v2":{"content":"\text{GPU Stall Risk} \propto \text{KV Restore Tail Latency} + \text{Data Movement Overhead}"}}

즉:

  • Capacity 증가
  • Cost 절감

와 동시에:

  • Restore latency
  • Tail latency
  • GPU stall

을 얼마나 제어할 수 있는지가 핵심이다.

8. Storage Bottleneck Analysis

8.1 Write Path​

KV offloading path:

GPU HBM
   ↓
CPU DRAM
   ↓
SSD

주요 bottleneck:

  • GPU→CPU memcpy
  • CPU intervention
  • Filesystem overhead
  • SSD write latency

8.2 Restore Path​

Restore path는 훨씬 더 latency-sensitive하다.

SSD
   ↓
CPU buffer
   ↓
GPU restore

여기서:

  • Random read
  • Metadata lookup
  • Fragmentation
  • Tail latency

가 GPU stall을 유발할 수 있다.

9. Raw Block Backend와 io_uring

9.1 Filesystem Overhead​

기존 filesystem은:

  • inode lookup
  • metadata journaling
  • extent allocation
  • page cache

등의 overhead를 가진다.

그러나 LMCache workload는 사실상:

Append-only KV Object Store

에 가까운 특성을 가진다.

따라서 raw block backend 및 direct I/O 접근이 유리할 수 있다.

9.2 io_uring의 중요성​

KV restore path는 asynchronous parallel I/O가 핵심이다.

io_uring은:

  • Lower syscall overhead
  • Async batching
  • Submission/completion queue

를 제공하여 restore latency를 줄일 수 있다.

10. 미래 방향

10.1 AI-native Storage​

미래 storage system은 단순 persistence layer가 아니라 AI memory hierarchy 일부로 진화할 가능성이 높다.

HBM
 ↓
DRAM
 ↓
NVMe SSD
 ↓
Distributed Storage

전체가 하나의 hierarchical memory system처럼 동작하게 될 것이다.

10.2 미래 연구 방향​

KV-aware SSD​

KV workload에 최적화된 SSD firmware.

AI-aware Placement​

KV lifecycle 기반 placement optimization.

Computational Storage​

Storage device 내부 preprocessing.

GPU-memory Extension​

Storage를 사실상 GPU memory tier로 활용.

11. 결론

AI inference infrastructure는 빠르게 compute-centric 구조에서 memory-centric 구조로 이동하고 있다.

특히:

  • Long context
  • RAG
  • AI Agent
  • Persistent memory

등의 workload는 KV cache explosion 문제를 유발하고 있다.

LMCache와 Tensormesh는 이러한 문제를 해결하기 위해 GPU 외부 memory/storage 계층을 활용하여 reusable KV cache architecture를 구축하고 있다.

WEKA와 같은 distributed storage platform은 KV movement bottleneck을 완화하기 위한 high-performance storage fabric 역할을 수행한다.

Samsung FDP SSD 및 HC SSD는 이러한 AI-native workload에 대해 새로운 optimization opportunity를 제공할 수 있다.

결국 미래 AI infrastructure는:

Compute Scaling
→ Memory & Storage Scaling

으로 진화할 가능성이 높으며, storage system은 AI memory hierarchy의 핵심 구성 요소로 자리잡게 될 것이다.