실전 사례 — CXL.mem 추가로 LLM inference KV cache 처리량 회복

#한 줄 요약

“H100 96 GB 5장(총 HBM 480 GB)으로 LLaMA 70B inference를 돌리던 노드가 batch 96 이상에서 throughput이 무너졌습니다.” — 원인은 KV cache가 HBM 용량을 초과해 PCIe DMA swap thrashing. 해결은 Astera Leo 계열 CXL.mem pool 추가 + cold KV block을 CXL.mem에 자동 배치. 결과는 batch 96에서 throughput ~92% 회복, batch 128 확장 가능. 본 사례의 수치는 현장 관측을 일반화한 시나리오입니다.

#배경

운영 환경 (현장 일반화):

#증상

운영 중 batch 96 이상으로 부하 증가 시:

batch 96에서 throughput이 1/3로 떨어짐. 비정상.

#진단

#1. GPU 메모리 사용량 확인

1
$ watch -n 1 nvidia-smi
2
# batch 96 동안
3

4
| GPU  Name    | Mem Used / Total |
5
|  0   H100    | 92450 MiB / 96000 MiB |
6
|  1   H100    | 92312 MiB / 96000 MiB |
7
|  2   H100    | 92478 MiB / 96000 MiB |
8
|  3   H100    | 92501 MiB / 96000 MiB |
9
|  4   H100    | 92388 MiB / 96000 MiB |

총 462 GB / 480 GB 사용 — HBM 거의 가득.

#2. CUDA profiler 분석

1
$ nsys profile --gpu-metrics-device=all ./vllm-server

Nsight Systems에서 본 프레임당 시간 분해:

KV cache load가 90배 증가. 원인: HBM 부족분을 PCIe DMA로 Host RAM과 swap.

#3. Roofline 분석

Ch 16(메모리 대역폭 분석) Roofline plot 결과:

• 정상: memory-bound 영역의 상한선 근처 (HBM 8 TB/s 활용)
• 비정상: memory-bound 영역의 훨씬 아래 (PCIe 64 GB/s에 발목 잡힘)
• Compute 활용률 23% — GPU가 놀고 있는 상태

#원인

HBM·GDDR 심화 Ch 8에서 본 LLaMA 70B 메모리 분해:

HBM 총용량 480 GB. batch 64는 간신히 들어가고, batch 96은 158 GB 초과. 초과분이 PCIe로 host RAM과 swap.

PCIe 5.0 x16 양방향 64 GB/s로 수백 GB 데이터를 매 프레임 swap하니 throughput이 무너집니다.

#해결

#1. 하드웨어 추가

서버에 Astera Labs Leo CXL.mem 카드 2장 추가:

#2. 추론 엔진 측 설정 (개념적)

vLLM 계열 추론 엔진에서 KV cache를 HBM·CXL.mem에 분산 배치하는 설정 (실제 schema는 fork·버전에 따라 다름, 아래는 개념 표현):

1
# 개념적 예시 — 실 schema는 사용 엔진의 docs 참조
2
kv_cache:
3
  storage_tiers:
4
    - device: cuda           # HBM (hot tier)
5
      capacity: "70%"
6
      role: hot
7
    - device: numa:2,3       # CXL.mem nodes (warm tier)
8
      capacity: "100%"
9
      role: warm
10
  promotion_policy:
11
    type: lru
12
    window_size: 128         # 최근 128 token 이내 hot
13
  block_size: 16             # token 단위

핵심 아이디어: recent token KV는 HBM, old token KV는 CXL.mem. LRU 기반 promotion·demotion. 어느 vLLM fork·patch가 이를 native 지원하는지는 해당 프로젝트의 release note를 확인.

#3. Linux Tiered Memory 설정

1
# DAMON 활성화 (자동 promotion/demotion 보조)
2
$ echo on > /sys/kernel/mm/damon/admin/kdamonds/0/state
3

4
# NUMA balancing 활성
5
$ echo 1 > /proc/sys/kernel/numa_balancing
6

7
# CXL 노드를 movable zone으로 노출
8
$ daxctl reconfigure-device dax2.0 -m system-ram
9
$ daxctl reconfigure-device dax3.0 -m system-ram

#결과

해결 후 측정:

• batch 96에서 throughput 220 tok/s 회복 (해결 전 80 → 220, 275% 향상)
• batch 128까지 확장 가능 (해결 전 OOM)
• p99 latency 25% 증가하지만 throughput 우선 워크로드에는 OK

#DAMON로 본 access 분포

Ch 55에서 본 DAMON 출력:

recent token이 HBM에 머무름과 old token이 CXL로 demotion의 패턴이 자동으로 형성됨.

#재발 방지

운영에 추가한 모니터링:

이 5가지 지표를 Prometheus에 노출해 Grafana 대시보드로 본부 운영팀이 추적.

#자주 보는 함정과 안티패턴

⚠️ “GPU만 빠르면 LLM inference 빨라진다”

틀렸습니다. KV cache가 memory-bound 작업의 핵심. GPU compute가 남아돌아도 메모리가 병목이면 throughput이 안 올라갑니다. 메모리 용량·대역폭이 GPU compute만큼 중요.

⚠️ “CXL.mem 추가 = throughput 무조건 향상”

조건부입니다. memory-bound 워크로드에만 효과. compute-bound 워크로드는 CXL이 영향 없음. Roofline 분석으로 어느 영역인지 먼저 확인.

⚠️ Manual KV cache placement에 집착

DAMON 같은 자동 tiering이 manual placement보다 일반적으로 우수. application이 모든 KV block의 hotness를 정확히 알기 어렵습니다. 자동 메커니즘에 맡기고 monitoring이 권장.

⚠️ Tier 추가 후 batch size 같은 그대로

확장의 여지가 생겼는데 batch 64 그대로 두면 추가 비용만 발생. CXL 도입 후에는 workload 재튜닝이 반드시 필요합니다.

#정리

• LLaMA 70B inference가 batch 96 이상에서 throughput이 무너진 사례. 원인은 KV cache의 HBM 초과 + PCIe swap thrashing.
• 해결은 Astera Leo CXL.mem 4 TB 추가 + vLLM의 tiered KV cache + Linux DAMON 자동 promotion.
• 결과: batch 96 throughput 92% 회복, batch 128까지 확장 가능, p99 latency 25% 증가는 throughput 우선 워크로드 수용 가능.
• 핵심 lesson: HBM은 대역폭 우위, CXL.mem은 용량 우위. 상보적 활용이 memory-bound 워크로드의 정답.
• 재발 방지는 5가지 지표(HBM 사용률, PCIe swap rate, CXL 사용률, false promotion, CXL latency) 상시 모니터링.

다음 편은 Embedded Performance Engineering 시리즈의 마무리 영역으로 들어갑니다. CXL 관련 다음 깊이는 Embedded Security Ch 11~13의 보안 측면, Memory Diagnostics Ch 6~7의 진단 측면으로 이어집니다.

#관련 항목

• Ch 7: 성능 모델링 — Roofline
• Ch 16: 메모리 대역폭 분석
• Ch 47: NVIDIA Nsight Systems
• Ch 54: CXL.mem 지연·대역폭 실측
• Ch 55: CXL 성능 프로파일링 도구
• HBM·GDDR 심화 Ch 8: NPU·GPU에서의 HBM 활용
• HBM·GDDR 심화 Ch 9: CXL.mem 분석