TTFT 2.7배 개선과 GPU 메모리 제약의 해결

대규모 언어 모델 추론 시 첫 토큰 생성 시간인 TTFT(Time-To-First-Token)를 최대 2.7배 개선하고 교차 포드 캐시 적중률을 100%까지 달성했다. 이는 GPU 메모리 용량 때문에 고가의 인스턴스를 선택해야 했던 운영 비용을 낮춘다.

LLM 추론 과정에서는 이전 토큰들의 계산 값을 저장하는 KV 캐시(Attention Key-Value cache)가 필수적이다. 캐시 공간이 부족하면 동일한 프롬프트가 입력되어도 매번 처음부터 다시 계산하는 과정이 발생하며, 이는 TTFT 저하로 이어진다. 그동안 엔지니어들은 지연 시간을 줄이기 위해 과도하게 큰 GPU 인스턴스를 사용하거나, 느린 응답 속도를 감수해야 했다.

특히 Qwen, Llama, DeepSeek 같은 공개 파운데이션 모델로 RAG(Retrieval Augmented Generation) 파이프라인이나 다회차 대화 애플리케이션을 구축할 때 메모리 부족 현상이 심화된다. 비즈니스 라인별로 엔드포인트를 분리해 운영하면 중복 프롬프트가 많아지지만, 각 포드가 독립적인 메모리를 사용하므로 인프라 비용은 상승하고 사용자 경험은 떨어진다.

이를 해결하기 위해 HyperPod 계층형 저장소를 활성화하고 노드 로컬 NVMe(Non-Volatile Memory express)에 Curvine 워커를 배치했다. 파일시스템 기반의 L2 캐시를 지원하도록 Inference Operator를 패치한 결과, 한 포드가 생성한 캐시를 다른 포드가 즉시 읽어 쓰는 교차 포드 캐시 적중률 100%를 구현했다. 약 1,900개 토큰 규모의 프롬프트에서 교차 노드 L2 읽기 지연 시간은 약 56ms로 측정되었다.

이 구조를 통해 하드웨어 요구 사양을 낮출 수 있다. 기존에 P5 인스턴스가 필요했던 워크로드를 더 저렴한 G6e 인스턴스에서 실행하여 엔드포인트당 운영 비용을 절감했다.

L0-L1-L2로 이어지는 3단계 캐시 계층 구조

48GB GPU에서 7B 모델을 bf16으로 구동하면 가중치에 약 14GB가 소요되어 30GB 이상의 여유 공간이 남는다. 반면 32B 모델은 가중치만으로 약 64GB를 사용하므로 단일 GPU에 담기지 않으며, 샤딩 후에도 KV 캐시를 위한 공간이 매우 부족하다. 이로 인해 동시 요청이 늘어나면 기존 캐시 블록이 빠르게 밀려나는 L0 압박이 발생한다. L0는 vLLM의 Paged-Attention 레이어로, 가장 낮은 지연 시간을 제공하는 최상위 계층이다.

GPU 메모리에서 밀려난 블록은 LMCache가 호스트 DRAM에 임시 저장하는 L1 계층으로 이동한다. 이 과정은 각 추론 포드 내부에서 수행되며, SageMaker HyperPod Inference Operator가 자동으로 제어한다. 사용자는 InferenceEndpointConfig CRD 설정에서 `enableL1Cache: true` 값을 입력해 기능을 활성화한다. L1은 GPU와 L2 사이의 임시 저장소로 작동하며, `InstanceMemoryAllocationPercentage` 설정을 통해 메모리 할당량을 결정한다. 초기 설정값으로는 20%를 권장한다.

L2 계층은 Curvine을 통해 여러 노드의 NVMe 드라이브를 하나의 네임스페이스로 통합한 공유 분산 풀이다. L0와 L1이 개별 포드에 종속되어 데이터가 휘발되는 것과 달리, L2는 여러 복제본이 데이터를 공유할 수 있는 확장 저장소로 작동하며 로컬 디스크에 근접한 속도로 데이터를 제공한다. 이를 통해 GPU HBM에서 시작해 CPU 메모리를 거쳐 공유 NVMe 풀로 이어지는 3단계 계층 구조가 완성되어 캐시 재사용률을 높인다.

요청이 라우터에 도착하면 우선 접두사 일치도가 가장 높은 복제본으로 전달된다. 해당 복제본은 L0 GPU 블록을 먼저 확인하고, 실패하면 L1 CPU 메모리를, 마지막으로 L2 공유 NVMe 풀을 순차적으로 탐색한다. 세 계층 모두에서 데이터를 찾지 못한 경우에만 처음부터 다시 계산하는 Re-prefill 과정을 거친다.

Curvine 분산 파일시스템과 지능형 라우팅의 결합

Curvine은 G6e나 P5 인스턴스에 탑재된 로컬 NVMe 드라이브를 하나의 네임스페이스로 풀링하여 관리한다. FUSE(사용자 공간 파일시스템 드라이버) 클라이언트를 통해 이 풀을 일반 마운트 디렉토리처럼 제공하며, 모든 추론 포드에 ReadWriteMany PVC 형태로 마운트한다. LMCache는 `fs://` 커넥터를 사용하여 분산 풀에 접근하며, 모든 포드가 동일한 네임스페이스를 공유하므로 특정 복제본이 기록한 KV 블록을 다른 복제본이 즉시 읽어 재사용할 수 있다.

Curvine의 운영 구조는 메타데이터를 관리하는 Primary Node와 실제 데이터를 저장하는 Worker로 구분된다. Primary Node는 메타데이터와 저널링을 담당하며 Amazon EBS에 정보를 저장한다. Worker는 각 GPU 노드에서 실행되며 실제 데이터를 노드 내부 NVMe에 저장한다. 데이터 저장 경로는 다음과 같이 설정된다.

/opt/dlami/nvme/curvine-data

Worker 노드가 중단되어 캐시가 소실되더라도, KV 블록은 입력 프롬프트를 통해 다시 계산할 수 있는 재현 가능한 데이터이므로 서비스에 치명적인 문제는 발생하지 않는다.

지능형 라우터는 캐시 적중률이 가장 높을 것으로 예상되는 복제본을 선택해 요청을 전달한다. 프롬프트 접두사 트리 기반으로 노드를 찾는 Prefix-aware 전략과 각 워커의 캐시 상태를 직접 쿼리하는 KV-aware 전략을 지원한다. 이러한 라우팅 과정은 인프라 계층에서 처리되므로 클라이언트 측의 API 호출 방식이나 코드 수정은 필요하지 않다.

vLLM 복제본 간 격리 해소와 인프라 비용 효율화

공유 저장소 기반의 L2 캐시가 도입되기 전, 수평 확장된 vLLM 복제본들은 각각 독립적인 GPU 블록과 CPU 스필 영역(GPU 메모리 부족 시 데이터를 임시 저장하는 호스트 메모리 공간)을 유지했다. 이로 인해 요청이 다른 복제본으로 라우팅되면 기존 캐시를 전혀 사용할 수 없어 처음부터 다시 계산하는 콜드 스타트가 발생하며, 동일한 시스템 프롬프트를 매 요청마다 재계산하는 낭비가 반복되었다.

모든 vLLM 포드가 동일한 L2 네임스페이스를 마운트하면 이러한 복제본 간 캐시 격리가 해소된다. 특정 복제본이 생성해 기록한 KV 블록을 다른 복제본이 즉시 읽어올 수 있는 구조가 되어, 라우팅 대상이 바뀌더라도 이전 복제본이 처리한 데이터를 즉시 가져올 수 있다. 결과적으로 복제본 간의 데이터 단절을 없애고 전체 클러스터가 하나의 거대한 캐시 풀을 공유하는 효과를 낸다.

이러한 구조는 GPU 메모리 용량의 물리적 한계를 외부 공유 저장소로 보완하여 엔드포인트당 운영 비용을 낮춘다. 가중치가 GPU 메모리를 초과하는 대형 모델 환경에서도 캐시 적중률을 유지함으로써, 고가의 고사양 인스턴스 의존도를 낮추고 하드웨어 효율성을 극대화한다.

실무 적용을 위한 패치 방법과 도입 판단 기준

InferenceEndpointConfig CRD의 l2CacheBackend 필드는 현재 redis 또는 tieredstorage만 기본으로 지원한다. Curvine FUSE 마운트를 L2 캐시로 활용하려면 vLLM 컨테이너 스펙의 환경 변수를 직접 수정하는 패치 과정이 필요하다. `LMCACHE_REMOTE_URL` 변수를 다음과 같이 설정하여 L2 캐시가 Curvine 마운트 경로를 바라보게 한다.

LMCACHE_REMOTE_URL=fs://localhost:0/mnt/curvine/l2cache/

전체 인프라의 생명주기는 Amazon EKS 애드온으로 설치되는 Inference Operator가 통합 관리한다. 이 오퍼레이터는 vLLM 포드와 LMCache 사이드카, 그리고 라우터를 한 번에 배포한다. 사용자가 CRD에 `enableL1Cache`나 routingStrategy 같은 캐시 토폴로지를 선언하면, 오퍼레이터는 이를 해석해 적절한 볼륨 마운트와 라우팅 규칙을 생성한다. 사이드카 컨테이너가 L1과 L2 사이의 데이터 이동을 전담 처리하므로, 메인 추론 엔진은 캐시 계층의 물리적 위치를 알 필요 없이 요청을 처리한다.

실제 도입 여부는 워크로드의 프롬프트 중복률, 즉 Shared leading tokens의 비중으로 결정한다. 프롬프트 중복률이 약 40% 이상인 환경에서는 TTFT 감소 효과가 뚜렷하게 나타난다. 대표적으로 모든 요청에 동일한 시스템 프롬프트를 포함하거나, 대규모 문서 집합을 공유하는 RAG 컨텍스트를 사용하는 사례가 이에 해당한다. 중복도가 높은 프롬프트가 반복될수록 L2 캐시에서 KV 블록을 빠르게 읽어올 수 있어, Re-prefill 과정을 생략하고 추론 속도를 높인다.

따라서 프롬프트 중복률이 40%를 초과하는 워크로드라면, 고비용 P5 인스턴스 대신 저비용 G6e 인스턴스에 L2 캐시 인프라를 구성하는 것이 효율적인 선택이다.

이처럼 SageMaker HyperPod의 계층형 캐시 구조는 인프라 계층의 최적화를 통해 하드웨어 제약을 극복하고 LLM 서비스의 경제성과 성능을 동시에 확보하는 실질적인 방안을 제시한다.