Tiered KV cache for large LLMs on Amazon SageMaker HyperPod with Curvine

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker HyperPod에 Curvine 기반 공유 NVMe L2 캐시와 지능형 라우팅을 결합해 vLLM의 KV 캐시를 GPU·CPU·노드 간 스토리지로 확장하고, 테스트에서 교차 Pod 캐시 적중률 최대 100%와 TTFT 최대 2.7배 개선을 달성한 아키텍처와 구축 절차를 설명한다.

📌 핵심 요약

• 대규모 LLM 추론에서는 모델 가중치와 런타임이 GPU 메모리를 점유해 prefix cache 공간이 줄고, 서로 격리된 vLLM 복제본이 동일 프롬프트를 반복 계산하면서 비용과 TTFT가 증가한다.
• 제안 구조는 L0 GPU HBM, L1 로컬 CPU 메모리, L2 Curvine 공유 NVMe로 KV 캐시를 계층화하며, LMCache의 파일시스템 커넥터를 통해 여러 Pod가 같은 L2 블록을 재사용한다.
• HyperPod Intelligent Routing은 prefix-aware, kv-aware, round-robin 전략을 제공하고, Inference Operator는 캐시 계층과 라우터를 관리하지만 Curvine 연동에는 LMCACHE_REMOTE_URL을 FUSE 경로로 지정하는 패치가 필요하다.
• 테스트에서는 교차 Pod 캐시 적중률 최대 100%, TTFT 최대 2.7배 개선, 약 1,900토큰 프롬프트의 노드 간 L2 읽기 지연 약 56ms를 기록했으며 P5 대신 G6e를 사용할 가능성을 보였지만 실제 절감액은 모델 크기와 트래픽 프로필에 따라 달라진다.
• 구축에는 로컬 NVMe를 갖춘 최소 2개 GPU 노드, Amazon EKS 기반 HyperPod 클러스터, 관련 CLI와 CSI 구성요소가 필요하며, 예시는 Qwen2-7B와 Tiered Storage의 호스트 메모리 할당률 20%를 사용한다.

🧩 주요 포인트

1. GB GPU의 제한된 여유 메모리와 복제본별 독립 캐시는 긴 공통 프롬프트를 반복 prefill하게 만들며, 공유 캐시가 없으면 다른 복제본으로의 라우팅이 사실상 콜드 스타트로 이어진다.
2. Curvine가 노드 로컬 NVMe를 단일 공유 namespace로 묶고 지능형 라우팅이 적중 가능성이 높은 Pod를 선택함으로써, GPU와 CPU를 넘어 복제본 간 KV 블록 재사용이 가능해진다.
3. 최대 100% 적중률, 최대 2.7배 TTFT 개선, 약 56ms의 L2 읽기 결과는 G6e 비용 최적화 가능성을 보여주지만, 효과와 절감 폭은 프롬프트 중복도·모델 크기·트래픽 특성에 종속된다.

🧠 상세 정리

1. 대규모 추론의 KV 캐시 딜레마

대규모 LLM 추론에서는 증가하는 KV 캐시를 수용하기 위해 큰 GPU 인스턴스를 사용하거나, 동일한 프롬프트를 요청마다 다시 계산하면서 느린 첫 토큰 응답 시간인 TTFT를 감수해야 하는 선택이 발생한다. Qwen, Llama, DeepSeek 같은 여러 공개 파운데이션 모델을 업무별 endpoint, RAG pipeline, 다중 턴 대화에 배포하면 이 문제는 인프라 비용 상승과 사용자 경험 저하로 직결된다. vLLM은 이미 처리한 토큰의 attention key와 value를 KV 캐시에 저장하고, prefix caching으로 같은 선두 토큰을 공유하는 요청 간 캐시를 재사용하지만 사용할 수 있는 용량은 모델 가중치와 런타임 할당 이후 남은 GPU 메모리로 제한된다. ml.g6e.4xlarge처럼 GPU당 48GB인 인스턴스에서는 모델이 커지거나 동시성이 높아질수록 긴 프롬프트의 적중률이 낮아지고 공통 system prompt가 반복 prefill된다. 수평 확장된 vLLM 복제본도 각자 독립된 캐시를 유지하므로 다른 복제본으로 요청이 전달되면 기능적으로 콜드 스타트와 같은 재계산이 발생한다.

2. GPU·CPU·공유 NVMe의 3계층 설계

해결책의 핵심은 한 Pod 안에 갇힌 KV 캐시를 L0 GPU HBM, L1 로컬 CPU 메모리, L2 Curvine 공유 NVMe의 3계층으로 확장하는 것이다. L0에는 가장 자주 쓰이는 KV 블록을 가장 낮은 지연으로 유지하고, GPU에서 밀려난 블록은 L1 host DRAM이 받아 보존하며, 여러 노드에서 재사용할 블록은 L2의 단일 공유 namespace에 기록한다. 이 구조는 Amazon SageMaker HyperPod의 Managed Tiered KV Cache와 Intelligent Routing 위에 Curvine를 공유 L2 계층으로 추가해 복제본 사이에서도 거의 로컬 디스크에 가까운 속도로 캐시를 재사용하도록 설계됐다. 테스트 배포에서는 교차 Pod 캐시 적중률 최대 100%, TTFT 최대 2.7배 개선, 약 1,900토큰 프롬프트에 대한 노드 간 L2 읽기 지연 약 56ms가 보고됐다. 이에 따라 기존에 P5가 필요했던 일부 workload를 더 저렴한 G6e에서 실행할 가능성이 생기지만, 실제 비용 절감은 모델 크기와 트래픽 프로필에 따라 달라진다.

3. L0 GPU 캐시와 L1 CPU 오프로딩

L0는 vLLM의 native paged-attention 계층으로, 가장 뜨거운 KV 블록을 GPU에 보관하지만 용량은 모델 가중치를 적재한 뒤 남은 메모리로 한정된다. 48GB GPU에서 bf16 형식의 7B 모델은 가중치에 약 14GB를 사용해 KV 블록에 30GB 이상을 남길 수 있으므로 L0 압력이 비교적 작다. 반면 32B 모델은 가중치만 약 64GB가 필요해 48GB GPU 한 장에 들어가지 않으며, sharding을 적용하더라도 KV에 남는 공간이 줄어 동시 요청 아래에서 캐시가 빠르게 차고 축출된다. L1에서는 GPU에서 축출된 블록을 LMCache가 각 inference Pod의 host DRAM에 저장하며, InferenceEndpointConfig CRD의 enableL1Cache를 true로 설정하면 HyperPod Inference Operator가 이를 자동으로 관리한다. L1은 빠른 Pod 로컬 안전망으로 작동하고 InstanceMemoryAllocationPercentage로 크기를 정하며, 본문은 시작값으로 20%를 권장한다.

4. Curvine 기반 공유 L2 계층

L2는 G6e나 P5 인스턴스에 포함된 노드 로컬 NVMe를 Curvine가 하나의 분산 캐시 파일시스템으로 묶어 복제본 간 재사용을 가능하게 하는 계층이다. 사용자 공간 드라이버인 FUSE client가 이 pool을 일반 directory처럼 제공하고, ReadWriteMany PVC를 통해 모든 inference Pod에 mount하며, LMCache는 fs:// connector로 KV 블록을 읽고 쓴다. 모든 Pod가 같은 namespace를 보기 때문에 한 복제본이 기록한 블록을 다른 복제본이 바로 읽을 수 있어 복제본별 캐시 격리를 해소한다. Curvine의 Primary Node는 metadata와 journal을 관리하고 이를 Amazon EBS에 지속시키며, 각 GPU node의 Worker는 일반적으로 /opt/dlami/nvme/curvine-data에 위치한 NVMe에 실제 cache data를 저장한다. Worker가 중단돼 일부 캐시가 사라져도 KV 블록은 다시 계산할 수 있으므로 원본 데이터 손실 문제로 취급하지 않는다.

5. 지능형 라우팅과 Inference Operator 통합

공유 L2가 있어도 요청이 관련 KV 블록을 가진 복제본에 도달하지 않으면 전체 이점을 얻기 어렵기 때문에 HyperPod Inference Operator의 router가 cache-aware 배치를 담당한다. 기본값인 prefix-aware는 다중 턴 대화와 공통 system prompt에 적합하며 prefix tree를 사용하고, kv-aware는 각 worker의 cache state를 조회하므로 긴 문서 처리와 장기 session에 적합하며, round-robin은 상태 없는 batch inference와 부하 시험에 맞는다. 라우팅은 client 변경 없이 투명하게 수행되고, Operator는 Amazon EKS add-on으로 설치돼 vLLM Pod와 LMCache sidecar, L1·L2 backend, router, 단일 load-balanced endpoint의 lifecycle을 관리한다. 사용자는 InferenceEndpointConfig CRD에 enableL1Cache, enableL2Cache, l2CacheBackend, routingStrategy를 선언하지만, 현재 l2CacheBackend는 redis 또는 tieredstorage만 기본적으로 허용한다. 따라서 Curvine FUSE mount를 사용하려면 vLLM container spec의 LMCACHE_REMOTE_URL을 fs://localhost:0/mnt/curvine/l2cache/로 지정하는 패치가 필요하다. 요청은 router가 선택한 복제본에서 L0, L1, L2 순서로 조회되며, 모두 실패할 때만 처음부터 prefill되고 공통 선두 토큰 비율이 대략 40%를 넘는 workload에서는 재계산 생략이 TTFT를 크게 줄일 수 있다.

6. Curvine 클러스터의 내부 동작

Curvine는 application과 Amazon S3, HDFS, NAS 같은 기반 storage 사이에 위치하는 고성능 분산 cache filesystem이며 CLI, SDK, FUSE, CSI를 통해 접근할 수 있다. Client는 metadata RPC를 Primary Node에 보내고 실제 data I/O는 Worker에 전달하며, Primary Node는 heartbeat로 Worker를 조정하고 load balance와 고가용성을 고려해 block을 배치한다. Worker는 local storage tier에서 데이터를 읽고 쓰며 access heat에 따라 block을 승격하거나 강등해 자주 쓰이는 데이터를 낮은 지연으로 제공한다. Cache miss가 발생하거나 persistence policy가 요구되면 Curvine는 UFS에서 데이터를 불러오거나 UFS로 내보내므로, 장기 durability는 기반 storage가 담당하고 Curvine는 접근 가속에 집중한다. 이 역할 분리는 재생성 가능한 KV 블록에는 빠른 node-local NVMe를 사용하면서 metadata와 필요한 영속 상태는 별도 계층에 유지하는 구조와 연결된다.

7. 클러스터와 도구 사전 조건

HyperPod Tiered Storage는 cluster 수준 기능으로, 활성화되면 ai-toolkit DaemonSet을 각 GPU node에 배포하고 InstanceMemoryAllocationPercentage로 지정한 host memory를 L1 CPU offload용으로 예약하며 /opt/dlami/nvme 아래의 local NVMe를 노출한다. 예시는 Amazon EKS로 orchestration된 HyperPod cluster를 전제로 하고, cross-node 재사용을 확인하려면 최소 2개 GPU node가 필요하며 local NVMe를 제공하는 G6e 또는 P5가 권장된다. 작업 환경에는 AWS CLI v2, cluster에 연결된 kubectl, Helm v3가 필요하고, 작업 권한에는 sagemaker:UpdateCluster와 eks:CreateAddon이 포함돼야 한다. Curvine metadata node의 EBS volume 연결을 위해 EBS CSI driver role에는 sagemaker:AttachClusterNodeVolume, sagemaker:DetachClusterNodeVolume, eks:Describe* 권한이 요구되며 VPC CNI와 EBS CSI add-on도 최신 상태여야 한다. 예제는 HuggingFace에서 Qwen2-7B 가중치를 직접 가져오므로 bucket이 필수는 아니지만, 별도 staging을 선택하면 Amazon S3 read 권한을 HyperPod execution role에 부여해야 하고 TLS certificate는 자동 생성된다. 예시 cluster 이름 hyperpod-cluster-eks와 Region us-west-2는 placeholder이므로 실제 환경 값으로 대체해야 한다.

8. 단계별 구축과 Stage 1 제약

구현 예시는 다섯 단계로 구성되며 Tiered Storage 활성화, node-local NVMe의 Curvine Worker 배포, filesystem-backed L2를 위한 Inference Operator 패치까지 이어지는 흐름을 제시한다. Stage 1에서는 기존 HyperPod cluster에 update-cluster를 실행해 Tiered Storage의 Mode를 Enable로 지정하고 InstanceMemoryAllocationPercentage를 20으로 설정하며, 예제에서는 node recovery를 Automatic으로 함께 전달한다. Stage 2에서는 Inference Operator, Amazon S3와 Amazon FSx CSI driver, Metrics Server, Cert Manager를 설치하고, Stage 3에서는 EBS CSI driver와 Curvine를 설치하며, Stage 4에서는 Curvine FUSE 경로를 사용하도록 LMCACHE_REMOTE_URL을 패치한다. 중요한 API 제약은 --tiered-storage-config만 단독으로 전달하면 ValidationException이 발생하고 --node-recovery 또는 --instance-groups 중 하나를 반드시 함께 제공해야 한다는 점이다. 본문은 describe-cluster로 현재 NodeRecovery 값을 먼저 읽은 뒤 해당 값을 update-cluster 호출에 함께 전달하는 접근을 제시하며, 제공된 source_body는 Stage 1의 이 주의사항에서 끝난다.

🧾 핵심 주장 / 시사점

• KV 캐시 용량 문제는 GPU 증설만으로 해결하는 대신 재생성 가능한 블록을 CPU와 공유 NVMe로 이동해 더 저렴한 GPU에서 추론을 수행하는 방향으로 완화할 수 있다.
• 공유 L2의 존재만으로는 충분하지 않으며, prefix-aware 또는 kv-aware 라우팅으로 관련 캐시를 가진 복제본을 선택해야 교차 Pod 재사용과 TTFT 개선이 결합된다.
• Curvine는 KV 블록의 재계산 가능성을 활용해 Worker의 NVMe를 성능 계층으로 사용하고, metadata journal과 기반 storage에 durability 역할을 분리한다.

✅ 액션 아이템

• L0 GPU HBM·L1 CPU·L2 Curvine 계층 구조를 기준으로 Amazon SageMaker HyperPod에서 KV 캐시 확장 범위를 먼저 설계한다.
• Qwen2-7B를 예시로 HyperPod Intelligent Routing의 prefix-aware·kv-aware·round-robin 조합과 LMCACHE_REMOTE_URL(FUSE) 패치를 결합해 동작을 검증한다.
• 교차 Pod 캐시 적중률 100%와 TTFT 최대 2.7배 개선을 목표로 Amazon EKS 기반 HyperPod에서 로컬 NVMe 2개 GPU 노드+CSI 구성요소를 적용한다.

❓ 열린 질문

• L2 Curvine 공유 NVMe에서 1,900토큰 프롬프트 기준 노드 간 읽기 지연 56ms 구간에서 실제 비용 절감 임계점은 어디인가?
• Curvine 공유 namespace에서 여러 vLLM 복제본이 KV 블록을 재사용할 때 prefix-aware·kv-aware·round-robin 중 어느 라우팅 조합이 적중률을 높일 것인가?
• 모델 크기·트래픽 프로파일별로 P5 대신 G6e를 썼을 때 TTFT 개선 폭은 언제 2.7배 미만으로 하락할 가능성이 있는가?