이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
대규모 LLM 추론에서는 GPU 메모리와 Pod별 고립된 KV cache 때문에 동일한 prefix를 반복 Prefill하는 비용이 커집니다. 이 구조는 vLLM GPU L0, LMCache CPU L1, Curvine 공유 NVMe L2를 연결하고 HyperPod Intelligent Routing으로 캐시 적중 가능성이 높은 replica를 선택합니다. 두 Pod 검증에서 1,925개 token의 100% cross-Pod hit을 기록했으며, 2,500-token prompt에서는 cold 774 ms가 warm 287 ms로 줄어 2.7× TTFT 개선을 얻었습니다. 다만 1,000 token 미만 prompt에서는 L2 네트워크 비용이 재계산과 비슷하므로 L0와 L1 중심 구성이 더 적합합니다.
섹션별 상세
대규모 LLM 추론에서는 GPU 메모리에 KV cache를 모두 보관하기 어렵고, 복제본마다 캐시가 고립되어 같은 prefix를 반복 Prefill하는 문제가 생깁니다. 글의 구성은 vLLM의 GPU L0, LMCache의 Pod-local CPU L1, Curvine의 공유 NVMe L2를 계층으로 연결해 저장 용량과 접근 속도의 균형을 맞춥니다. Amazon SageMaker HyperPod의 Managed Tiered KV Cache와 Intelligent Routing을 결합하면 비용 효율적인 G6e instance에서도 긴 프롬프트의 캐시 재사용을 유지할 수 있습니다.
각 vLLM Pod의 L0는 모델 weight를 제외하고 남은 GPU HBM에 hottest KV block을 보관하고, GPU에서 밀려난 block은 LMCache가 host DRAM L1으로 옮깁니다. L1에서도 빠진 데이터는 fs:// connector와 FUSE mount를 통해 Curvine의 ReadWriteMany namespace로 기록되며, Curvine Worker가 각 GPU node의 local NVMe에 실제 데이터를 저장합니다. 글은 48 GB GPU에서 7B 모델 weight가 약 14 GB를 차지하는 반면 32B 모델은 단일 GPU에 맞지 않아 KV 여유가 급격히 줄어든다는 사례로 L2 확장의 필요성을 뒷받침합니다.
근거
- Curvine Worker는 node-local NVMe에 데이터를 저장하고 Primary Node는 metadata와 journaling을 Amazon EBS에 지속합니다. — Solution design의 L2 계층 설명과 Figure 1·Figure 2의 Master/Worker 및 저장 계층 구조에 근거가 있습니다.
Curvine은 여러 node-local NVMe를 하나의 distributed cache filesystem으로 묶고, Primary Node가 metadata와 journaling을 Amazon EBS에 저장하며 Worker가 data I/O와 local disk cache를 담당합니다. 요청이 들어오면 Intelligent Router가 prefix tree 또는 worker cache state를 이용해 적중 가능성이 높은 replica를 고르고, 해당 replica는 L0, L1, L2 순서로 KV block을 조회합니다. 모든 계층에서 miss가 난 경우에만 전체 Prefill을 다시 수행하므로 공통 system prompt, RAG context, 누적 대화 기록을 공유하는 workload에서 TTFT 절감 효과가 커집니다.
구현은 HyperPod cluster에서 Tiered Storage를 켜고 ai-toolkit DaemonSet을 배치한 뒤, EKS add-on으로 Inference Operator와 의존성을 설치하고 Curvine CSI 및 Worker를 배포하는 다섯 단계 흐름으로 구성됩니다. InferenceEndpointConfig CRD에서 enableL1Cache, enableL2Cache, l2CacheBackend, routingStrategy를 지정하지만 Curvine FUSE 경로는 native backend 값에 포함되지 않아 vLLM container의 LMCACHE_REMOTE_URL을 fs://localhost:0/mnt/curvine/l2cache/로 patch해야 합니다. 두 GPU node의 Pod에 같은 1,925-token 요청을 차례로 보낸 검증에서 첫 번째 Pod가 1,925 token을 기록하고 두 번째 Pod가 1,925 token을 읽어 100% cross-Pod hit을 달성했습니다.
bash
aws sagemaker update-cluster \
--cluster-name hyperpod-cluster-eks \
--tiered-storage-config Mode=Enable,InstanceMemoryAllocationPercentage=20 \
--node-recovery Automatic기존 SageMaker HyperPod cluster에서 Tiered Storage와 호스트 메모리 20% 할당을 활성화합니다.
단일 요청 benchmark에서 약 1,000 token 이상인 prompt는 cross-Pod L2 reuse가 100% token을 적중시키며 Prefill을 건너뛰었고, 2,500 token에서 cold 774 ms가 warm 287 ms로 줄어 2.7× TTFT 개선을 기록했습니다. 500 token에서는 184 ms와 187 ms로 0.99×에 그쳐 네트워크 왕복 비용이 재계산 비용과 비슷했으며, 3,000 token에서는 2.2×였지만 절대 절감 시간은 490 ms로 가장 컸습니다. 네 턴 대화 재생에서는 총 지연이 4.21 s에서 3.25 s로 줄고 턴별 개선 폭이 1.22×에서 1.34×로 증가했지만, 실제 수치는 GPU 세대와 node 간 네트워크, prompt overlap에 따라 달라집니다.
용어 해설
- KV 캐시(KV Cache)
- — LLM이 이미 처리한 토큰의 attention key와 value를 저장해 다음 생성 단계에서 재계산을 피하는 메모리 구조입니다. vLLM은 이를 토큰 블록 단위로 관리하고, Prefix Caching은 동일한 앞부분을 공유하는 요청 사이에서 저장된 블록을 재사용합니다. 캐시가 GPU·CPU·NVMe로 확장되면 긴 프롬프트와 여러 복제본 사이의 중복 연산을 줄일 수 있습니다.
- Prefix Caching
- — 여러 요청이 동일한 선행 토큰을 공유할 때 해당 구간의 KV 블록을 재사용하는 추론 최적화 기법입니다. 시스템 프롬프트나 반복되는 RAG 컨텍스트를 캐시 키로 삼아 Prefill을 건너뛰며, vLLM의 GPU 캐시가 주된 실행 계층으로 작동합니다. 복제본별 캐시가 분리된 환경에서는 Intelligent Routing과 공유 L2 계층이 재사용 범위를 넓힙니다.
- LMCache
- — LLM 추론 중 생성된 KV 블록을 GPU 외부 저장 계층으로 이동하고 필요할 때 다시 읽어오는 캐시 구성 요소입니다. 이 글에서는 GPU의 L0 다음에 호스트 DRAM 기반 L1을 두고, fs:// connector를 통해 Curvine의 공유 NVMe L2와 연결합니다. Pod 내부의 CPU 오프로딩과 복제본 간 캐시 공유를 함께 처리해 긴 프롬프트의 Prefill 비용을 낮춥니다.
- FUSE
- — 사용자 공간 프로그램이 분산 저장소를 일반 디렉터리처럼 마운트하도록 만드는 파일시스템 인터페이스입니다. Curvine의 FUSE client는 여러 GPU 노드의 NVMe 풀을 하나의 namespace로 노출하고, 각 inference Pod가 ReadWriteMany PVC를 통해 같은 경로에 접근하게 합니다. 따라서 한 Pod가 기록한 KV cache file을 다른 Pod가 동일한 파일 경로에서 읽을 수 있습니다.
- Intelligent Routing
- — 요청의 prefix 또는 각 worker의 KV cache 상태를 조회해 캐시 적중 가능성이 높은 vLLM replica로 요청을 보내는 라우팅 기능입니다. prefix-aware 전략은 prefix tree를 사용하고 kv-aware 전략은 worker별 cache state를 활용하며, round-robin은 상태 비저장 배치에 적합합니다. 올바른 replica를 선택하면 수십 밀리초가 걸리는 L2 네트워크 읽기 대신 GPU L0 또는 CPU L1에서 캐시를 가져올 수 있습니다.
기술
- Amazon SageMaker HyperPod
- Amazon SageMaker HyperPod Inference Operator
- vLLM
- LMCache
- Curvine
- Amazon EKS
- FUSE
- Kubernetes CSI
- Amazon EBS
- Amazon S3
- HDFS
- NVMe
- Qwen2-7B-Instruct
활용 사례
- 공통 system prompt를 사용하는 multi-tenant LLM endpoint
- 반복 검색 context를 사용하는 RAG pipeline
- 대화 history가 누적되는 multi-turn dialogue
- 여러 vLLM replica 사이의 KV cache 공유
- Prefill/decode-disaggregated serving
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 12.수집 2026. 08. 12.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
