AI

KV Cache: AI 인프라 전쟁의 심장 - 엔비디아, ByteDance, Alibaba, Tencent가 모두 사활을 건 AI 인프라 전쟁의 진짜 심장부를 해부한다

marvin-jung 2026. 4. 14. 19:16
반응형
SMALL
왜 다들 KV Cache에 미쳐 있는가?

2024~2025년, AI 인프라 세계에서 가장 치열한 경쟁이 벌어지는 곳은 어디일까? 새로운 모델 아키텍처? 더 빠른 칩? 아니다. KV Cache(Key-Value Cache)다.

엔비디아는 Dynamo 인퍼런스 프레임워크를 GTC 2025에서 공개하며 KV Cache 분산 관리를 핵심 기능으로 내세웠다. ByteDance는 Mooncake 아키텍처로 KV Cache를 물리적으로 분리해 수십억 건의 요청을 처리한다. Alibaba는 PD-Disaggregation으로 서빙 효율을 혁신했고, Tencent는 독자 Eviction 기술로 메모리 한계를 돌파했다.

💡 핵심 명제: LLM 추론(inference)에서 KV Cache는 전체 GPU 메모리의 40~60%를 차지하는 동시에, 응답 속도와 처리량을 결정하는 가장 중요한 변수다. KV Cache 관리 능력이 곧 서비스 비용과 경쟁력을 결정한다.

80B
Llama-3
파라미터
~50%
KV Cache가 차지하는
GPU HBM 비율
10x
최적 KV Cache 관리 시
처리량 향상
$0
캐시 히트 시
추가 연산 비용

KV Cache가 도대체 뭔가? — 아주 쉽게
📖 비유: 회의록 작성자의 딜레마

당신이 긴 회의의 회의록을 작성하는 사람이라고 상상하자. 다음 문장을 적을 때마다, 이전의 모든 발언을 다시 처음부터 읽고 문맥을 파악해야 한다면? 100번째 문장이면 99개를 다시 읽어야 하고, 1000번째라면 999개를 읽어야 한다. 끔찍하게 비효율적이다. LLM이 정확히 이 상황이다.

Transformer는 새 토큰을 생성할 때마다 이전 모든 토큰과의 관계(Attention)를 계산해야 한다. KV Cache는 이미 처리한 토큰들의 "기억"을 메모리에 저장해두는 것이다.

Token Generation Flow — Without vs With KV Cache
▌ WITHOUT KV CACHE — 매번 처음부터 재계산
The
quick
brown
fox
jumps
over ← 앞 5개 다시 계산!
▌ WITH KV CACHE — 저장된 값 재사용
The
quick
brown
fox
jumps
over ← K, V 캐시에서 로드 ✓
KEY CACHE (K)
token[0] "The"✓ HIT
token[1] "quick"✓ HIT
token[2] "brown"✓ HIT
token[3] "fox"✓ HIT
token[5] "over"✗ MISS
VALUE CACHE (V)
v_emb[0] [0.82,...]✓ HIT
v_emb[1] [0.31,...]✓ HIT
v_emb[2] [0.67,...]✓ HIT
v_emb[3] [0.11,...]✓ HIT
v_emb[5] [계산중...]✗ NEW
🔬 Attention 수식으로 보면
Attention(Q, K, V) = softmax( QKT / √dk ) · V
Scaled Dot-Product Attention — Vaswani et al., 2017

이 수식에서 Q(Query)는 현재 생성 중인 토큰, K(Key)V(Value)는 이전 모든 토큰에서 파생된 벡터다. 핵심은 K와 V는 이미 처리된 토큰들에 대해 변하지 않는다는 것이다. 그러니 저장해두면 된다. 이게 KV Cache의 전부다.

LLM 추론의 두 단계:
Prefill — 입력 프롬프트 전체를 한 번에 처리하며 KV Cache를 초기 생성. 연산 집약적(Compute-bound).
Decode — 토큰을 하나씩 생성하며 KV Cache를 조회·갱신. 메모리 집약적(Memory-bound).


그래서 뭐가 문제인가? — 메모리가 폭발한다
💾 KV Cache 메모리 사용량 계산
# KV Cache 메모리 크기 계산 # KV_Size = 2(K+V) × layers × kv_heads × head_dim × seq_len × bytes # 예시: LLaMA-3 70B, 4096 컨텍스트, FP16 num_layers = 80 num_kv_heads = 8 # GQA 적용 head_dim = 128 seq_len = 4096 bytes = 2 # FP16 kv_cache_gb = 2×80×8×128×4096×2 ÷ 1e9~1.34 GB # 요청 단 하나당! # 동시 요청 100개라면? total134 GB # A100 80GB × 2장이 통째로 사라짐

A100 80GB × 4장 — GPU당 메모리 점유 현황 (70B FP16, 4-way Tensor Parallelism)

모델 가중치 (Weights, 140GB ÷ 4)~35 GB
WEIGHTS
KV Cache ← 전쟁터~35 GB
KV CACHE
기타 (활성화값, 임시 버퍼)~10 GB
OTHER

* 70B 모델 FP16 = 140 GB → A100 단일 GPU에 적재 불가, 반드시 멀티-GPU 서빙 필요

GPU HBM은 세상에서 가장 비싼 부동산이다.
KV Cache는 그 땅을 반쯤 점령하고 있다.
⛽ 왜 Decode가 Memory-bound인가?

GPU는 연산(FLOPS)이 빠른 장치다. 그런데 Decode 단계에서는 매 토큰 생성마다 전체 KV Cache를 메모리에서 불러와야 하기 때문에 병목이 발생한다.

Decode 단계 파이프라인 — 메모리 대역폭이 모든 것을 결정한다

쿼리 생성
(Q 계산)
KV Cache
로드
Attention
Score 계산
토큰
샘플링

A100 연산 대역폭: 312 TFLOPS (FP16, sparsity 제외)  ·  메모리 대역폭: ~2 TB/s (SXM4 80GB, 정확히는 2,039 GB/s)  ·  Decode 시 GPU 연산 효율: 종종 10% 미만


빅테크들이 내놓은 해법들

세계 최고의 AI 인프라 팀들이 각기 다른 방향으로 달려가고 있다.

NVIDIA
ICMS / CMX — GTC 2026

CES 2026에서 Jensen Huang이 직접 발표하고 GTC 2026에서 본격 공개한 ICMS(Inference Context Memory Storage), 현재는 CMX(Context Memory Storage)로 브랜딩됐다. "KV Cache 데이터가 이동하느라 네트워크가 터지고 있다"는 Jensen의 말처럼, 엔비디아가 KV Cache를 하드웨어 인프라 레벨에서 아예 새로운 티어로 정의한 것이다.

  • G3.5 컨텍스트 메모리 티어: GPU HBM(G1) → DRAM(G2) → ICMS NVMe SSD(G3.5) → 공유 스토리지(G4)의 4계층 구조. ICMS는 GPU와 일반 스토리지 사이의 전용 KV Cache 플래시 계층으로, 기존 대비 5배 높은 토큰/초와 5배 높은 전력 효율 달성
  • BlueField-4 DPU 기반: NVMe SSD 앞단에 BlueField-4 DPU를 배치해 KV Cache I/O 플레인을 전담. NVMe-oF와 RDMA 프로토콜을 가속화하고 호스트 CPU 부담을 제거. Rubin SuperPod 한 대에 최대 18,432TB 컨텍스트 메모리 수용 가능
  • STX 모듈러 레퍼런스 아키텍처: GTC 2026에서 공개. 기업/클라우드 사업자가 CMX 기반 가속 스토리지 인프라를 표준화된 방식으로 구축할 수 있는 참조 설계
  • Dynamo + NIXL 오케스트레이션: 기존 Dynamo 프레임워크와 NIXL이 KV 블록 매니저로서 ICMS에 KV Cache를 사전 스테이징(prestage)하고, Decode 단계 직전 GPU로 로드해 stall 최소화
BYTEDANCE
InfiniStore + ShadowKV

ByteDance는 KV Cache 문제를 스토리지·전송·압축 세 축으로 분리해 각각 독자 기술을 쌓고 있다. 틱톡·더우인 등 수십억 명 서비스의 AI 인프라에서 검증된 실전 기술들이다.

  • InfiniStore (오픈소스): 분산 LLM 추론 클러스터를 위한 고성능 KV Cache 전용 스토어. PD Disaggregation 모드에서는 Prefill→Decode 노드 간 KV 전송을 담당하고, 비분리 모드에서는 GPU+CPU 캐시 외 추가 KV Cache 풀로 동작. 크로스노드 KV Cache 재사용(reuse)이 핵심 기능
  • ShadowKV (ICML 2025 Spotlight): 긴 컨텍스트 고처리량 추론을 위한 KV Cache 압축 기법. KV Cache를 "그림자(shadow)" 형태로 저정밀도 압축 저장하고, 필요 시 원본 품질로 복원해 GPU 메모리 사용량을 획기적으로 절감하면서도 긴 컨텍스트 품질 유지
  • KVDirect: 분산 PD Disaggregation에서 노드 간 KV Cache 전송 최적화. Tensor-centric 통신 메커니즘과 Pull 기반 KV 전송 전략으로 요청당 레이턴시를 기존 대비 55% 감소
ALIBABA
HiCache + Llumnix

Alibaba는 KV Cache 문제를 스토리지 계층(HiCache)스케줄링 계층(Llumnix)으로 분리해 각각 최적화한 뒤, 두 시스템을 결합해 시너지를 낸다. 단순 캐시 크기 늘리기가 아니라, 어떻게 스케줄링하느냐가 KV Cache 효율의 핵심이라는 통찰이 배경이다.

  • HiCache (Alibaba Cloud Tair × SGLang): Agentic AI 추론을 위한 계층형 KV Cache 인프라. GPU 메모리 → CPU 메모리 → DeepSeek 3FS 분산 파일시스템까지 3개 계층을 단일 통합 캐시로 관리. 열(hot)/냉(cold) 데이터를 자동 분류해 GPU 캐시 효율 극대화. 실제 Novita AI 도입 결과: Cache Hit률 40%→80%, TTFT 56% 감소, QPS 2배 향상
  • Llumnix (OSDI 2024): KV Cache 인식(KV-cache-aware) 로드 밸런싱 스케줄러. vLLM 위에서 동작하는 크로스 인스턴스 요청 스케줄링 레이어로, KV Cache가 이미 있는 인스턴스로 요청을 라우팅. 단순 Round-robin 대비 TTFT P99 최대 12.1배 개선, TBT P99 15% 개선
  • KV Cache 마이그레이션: Llumnix의 KV Cache 마이그레이션 메커니즘은 실행 중인 요청의 KV Cache를 다른 인스턴스로 실시간 이동 가능. Preemption stall을 기존 대비 2 오더(100배) 단축
  • HiCache + Llumnix 시너지: Llumnix가 KV Cache 위치를 인식해 라우팅하고, HiCache가 계층적으로 저장·제공. 둘을 결합하면 KV Cache 재사용률과 서빙 효율이 동시에 극대화
TENCENT
FlexKV + Sparse Eviction

위챗·QQ 등 수십억 명 기반의 Tencent는 FlexKV를 중심으로 KV Cache의 유연한 관리와 압축에 독자 기술을 집중하고 있다. 모든 것을 저장하지 않아도 품질이 크게 떨어지지 않는다는 통찰이 핵심이다.

  • FlexKV: KV Cache 관리의 유연성을 극대화한 Tencent의 핵심 기술. 다양한 모델 아키텍처와 서빙 시나리오에서 KV Cache 할당·이동·재사용 정책을 동적으로 조정. 위챗의 다종 다양한 AI 서비스(챗봇, 검색, 고객센터)에 걸쳐 단일 KV Cache 관리 레이어로 통합 운영
  • KV Cache Eviction Policy: Attention Score를 실시간 모니터링해 기여도가 낮은 과거 토큰의 K, V를 선택적으로 삭제. 컨텍스트의 5~20%인 핵심 토큰들의 K, V만 유지해도 품질의 90%+ 보존 가능
  • Cross-Request Cache Sharing: 유사한 질문들의 KV Cache를 사용자 간에 안전하게 공유하는 메커니즘. 위챗 내 동일 공식 계정 FAQ, 고객센터 질의 등에서 Cache Hit률 대폭 향상
  • Layer-wise 차별화 저장: 레이어별 중요도 차이에 기반해 레이어마다 다른 정밀도(FP16/FP8/INT4)와 보존 비율 적용. FlexKV가 이 정책을 동적으로 제어

왜 이것이 AI 인프라의 핵심 전쟁인가?
💰 비용의 문제

ChatGPT 하나의 쿼리 비용은 Google 검색의 약 10배로 추정된다. KV Cache 최적화로 GPU 처리량을 2배 높이면, 같은 하드웨어로 2배의 요청을 처리할 수 있다. 수천 대의 GPU를 운용하는 기업에게 이것은 수백억 원 단위의 절감이다.

⚡ 지연 시간의 문제

KV Cache Hit률이 높으면 Prefill 단계를 건너뛰거나 대폭 단축할 수 있다. KV Cache가 이미 GPU에 있는 요청은 TTFT(Time To First Token)가 5~20배 빠를 수 있다.

TTFT(Time To First Token)란? 사용자가 질문을 보낸 후 첫 번째 토큰이 도착하기까지의 시간. KV Cache Hit는 Prefill 비용을 0에 가깝게 만들어 이 값을 극적으로 줄인다.

📈 컨텍스트 길이 경쟁의 문제

GPT-4: 128K, Gemini 1.5 Pro: 1M, Claude: 200K. 컨텍스트가 길어질수록 KV Cache 문제는 기하급수적으로 커진다. KV Cache를 효율적으로 관리하지 못하면 긴 컨텍스트 모델은 서빙 자체가 불가능하다.

2022

KV Cache 메모리 단편화 문제 대두

대규모 LLM 서빙에서 KV Cache 단편화(fragmentation)로 GPU 메모리 낭비가 심각해짐

2023.06

vLLM & PagedAttention 발표 (UC Berkeley)

OS 가상 메모리에서 영감받은 PagedAttention으로 메모리 단편화 해결. GPU 처리량 최대 24배 향상

2024

Llumnix (Alibaba, OSDI 2024) · InfiniStore (ByteDance)

Alibaba의 KV Cache 인식 동적 스케줄러 Llumnix 공개. ByteDance의 분산 KV Cache 전용 스토어 InfiniStore 오픈소스화

2025

ShadowKV (ByteDance, ICML 2025 Spotlight) · HiCache (Alibaba)

ByteDance의 장문 컨텍스트 KV 압축 기법 ShadowKV가 ICML Spotlight 수상. Alibaba Cloud Tair × SGLang의 계층형 KV Cache 인프라 HiCache 공개 — Cache Hit 2배, TTFT 56% 감소

2026.01

NVIDIA ICMS 발표 (CES 2026)

Jensen Huang이 직접 키노트에서 발표. BlueField-4 + NVMe SSD 기반 G3.5 KV Cache 전용 메모리 티어. "KV Cache 네트워크 트래픽이 심각하다"며 하드웨어 레벨 해결 선언

2026.03

NVIDIA CMX + STX 레퍼런스 아키텍처 공개 (GTC 2026)

ICMS가 CMX로 리브랜딩. STX 모듈러 레퍼런스 아키텍처 발표. Rubin SuperPod에 최대 18,432TB 컨텍스트 메모리 구성 가능. 스토리지 업계 판도 재편


알아두어야 할 핵심 기술들
1. PagedAttention — 가상 메모리의 AI 버전

vLLM이 제안. KV Cache를 고정 크기 "블록"으로 나누어 관리해 메모리 단편화를 거의 완전히 제거한다. 이 기법 하나만으로 GPU 처리량이 최대 24배 향상되었다.

2. Prefix Caching — 공통 부분은 한 번만

같은 시스템 프롬프트를 수백만 개의 요청에서 반복 계산하는 것은 극도로 비효율적이다. 프롬프트의 공통 접두사에 대한 KV Cache를 영구 저장해둔다. Anthropic의 Prompt Caching 기능이 바로 이것이다 — 최대 90% 비용 절감.

3. Prefill-Decode Disaggregation

Prefill(연산 집약)과 Decode(메모리 집약)를 물리적으로 분리된 GPU 풀에서 각각 실행해 양쪽 모두 최적화한다.

4. GQA (Grouped Query Attention)

Meta의 Llama 2부터 도입. 여러 Query Head가 하나의 K, V Head를 공유해 KV Cache 크기를 N배 축소. 품질 손실 없이 KV Cache를 8분의 1로 줄이는 것도 가능하다. 현재 대부분의 최신 LLM이 기본 채택 중.

5. KV Cache 계층화

GPU HBM → CPU DRAM → NVMe SSD의 계층을 활용해 자주 쓰이는 캐시는 GPU에, 덜 쓰이는 것은 DRAM이나 SSD에 보관한다. 어떤 캐시를 어디에 두느냐를 예측하는 지능이 핵심이다.


결론 — KV Cache는 AI 시대의 캐시 메모리다

컴퓨터 아키텍처 역사를 보면, CPU가 빨라질수록 CPU-메모리 간 속도 차이(Memory Wall)가 병목이 되어왔다. 이를 해결한 것이 L1/L2/L3 캐시 계층 구조였다.

LLM 추론도 정확히 같은 문제에 봉착해 있다. GPU 연산은 충분히 빠르다. 그런데 KV Cache를 읽어오는 메모리 대역폭이 병목이다. KV Cache는 AI 시대의 CPU 캐시 문제다.

엔비디아가 하드웨어+소프트웨어 레벨에서, ByteDance·Alibaba·Tencent가 시스템 아키텍처 레벨에서, Anthropic·OpenAI가 서비스 레벨에서 풀려 하는 것은 모두 같은 문제를 향하고 있다.

앞으로의 방향: 컨텍스트 길이가 수백만 토큰으로 늘어나고, AI 에이전트가 긴 대화를 이어가며, 멀티모달 입력이 늘어날수록 KV Cache 문제는 더욱 중요해진다. 이 전쟁의 승자가 AI 인프라 시장의 패권을 쥘 것이다. KV Cache는 단순한 최적화 기법이 아니다 — AI 경제의 근본 인프라다.

vLLM
PagedAttention 선구자
오픈소스 표준
ICMS
NVIDIA의 답
G3.5 하드웨어 계층
InfiniStore
ByteDance의 답
분산 KV 전용 스토어
HiCache
Alibaba의 답
계층형 KV 인프라
반응형
LIST