Mooncake 심층 아키텍처: 프리필-디코딩 물리 분리와 계층형 분산 KVCache 풀링으로 525% 처리량을 달성한 차세대 LLM 서빙 엔지니어링

대형 언어 모델(LLM)의 상용화가 전면 확대되면서, 수십만 토큰에 달하는 문서 전체를 입력으로 제공하고 실시간 대화를 나누는 초장문 서비스가 표준으로 자리 잡았습니다. 128k, 200k, 나아가 100만 토큰에 달하는 프롬프트가 프로덕션 시스템으로 쏟아져 들어오는 오늘날, 엔터프라이즈 AI 인프라 팀이 마주하는 가장 참혹한 병목은 첫 번째 토큰이 출력되기까지 걸리는 시간(TTFT, Time-To-First-Token)의 폭증과 활성 세션의 추론 중단(Jitter) 현상입니다.

전통적인 LLM 서빙 엔진인 vLLM이나 TensorRT-LLM의 기본 구성은 동일한 GPU 인스턴스 안에서 새로운 요청의 입력 프롬프트를 처리하는 프리필(Prefill) 단계와, 이미 시작된 요청들의 다음 토큰을 하나씩 생성하는 디코딩(Decode) 단계를 함께 수행하는 통합 서빙(Colocated Serving) 방식을 채택해 왔습니다.

하지만 이 통합 구조는 초장문 시퀀스가 인입되는 순간 재앙에 가까운 자원 충돌을 유발합니다. 프리필 연산은 수만 개의 토큰을 일시에 연산해야 하므로 GPU 텐서 코어를 100% 점유하는 고도의 연산 집약형(Compute-Bound) 작업인 반면, 디코딩 연산은 기생성된 거대한 KV 캐시를 메모리에서 읽어오며 1토큰씩 순차 생성하는 전형적인 메모리 대역폭 집약형(Memory-Bandwidth Bound) 작업입니다.

이 두 가지 상반된 성격의 워크로드가 단일 GPU 배치(Batch) 안에서 뒤섞이는 순간, 10만 토큰짜리 무거운 프롬프트가 들어오면 수십 개의 실시간 디코딩 스트림이 텐서 코어 자원을 빼앗겨 수 초간 멈춰 서는 헤드오브라인 블로킹(Head-of-Line Blocking)이 발생합니다. 반대로 실시간 디코딩 요청이 몰리면 새로운 프롬프트의 프리필을 시작조차 하지 못해 큐 대기 지연이 수직 상승합니다.

이 근본적인 딜레마를 해결하기 위해 오픈소스 분산 시스템 커뮤니티와 프론티어 AI 서빙 인프라 엔지니어들이 완성한 혁신적인 해법이 바로 FAST 2025 학계와 산업계를 뒤흔든 KVCache 중심 분리형 서빙 아키텍처 Mooncake입니다.

이 글에서는 통합 서빙 구조의 구조적 파산을 분석하고, 프리필과 디코딩을 물리적인 별도 노드 군단으로 격리한 뒤 분산 GPU HBM, 호스트 DRAM, 로컬 NVMe SSD를 초고속 RDMA 메시 네트워크로 묶어낸 Mooncake의 계층형 메모리 풀링 및 실시간 청크 전송 아키텍처를 심층 분석합니다.

통합 서빙(Colocated Serving)의 한계와 프리필-디코딩 간섭의 본질

초장문 AI 서빙 인프라에서 단일 GPU 클러스터가 겪는 성능 붕괴의 메커니즘을 이해하기 위해서는 프리필과 디코딩의 하드웨어 자원 점유 프로파일의 불일치를 명확히 파악해야 합니다.

현대 프론티어 LLM 서빙에서 단일 요청의 라이프사이클은 두 개의 완전히 다른 단계로 분절됩니다.

프리필 단계(Prefill Phase): 사용자가 입력한 프롬프트 토큰 N개를 한 번에 받아 Query, Key, Value 텐서를 계산하고 셀프 어텐션을 수행합니다. N이 100k일 때 연산량은 O(N^2)에 비례하여 텐서 코어를 극한까지 가동합니다. 산술 강도(Arithmetic Intensity, FLOPs/Byte)가 수백 단위에 달하므로 완벽한 연산 집약형(Compute-Bound) 상태입니다.
디코딩 단계(Decode Phase): 이전 단계에서 생성된 N개의 과거 KV 캐시 텐서를 HBM에서 메모리 버스로 읽어온 뒤, 단 1개의 새로운 쿼리 토큰과 내적을 수행하여 다음 토큰을 생성합니다. 연산량은 고작 O(N)에 불과하지만, 매 토큰마다 수십 기가바이트의 KV 캐시를 HBM에서 온칩 SRAM으로 퍼 올려야 합니다. 산술 강도가 1 미만으로 급락하는 완벽한 메모리 대역폭 집약형(Memory-Bound) 상태입니다.

이 두 작업이 동일한 인스턴스에서 동적으로 묶이는 청크 프리필(Chunked Prefill)이나 연속 배치(Continuous Batching) 환경에서는 다음과 같은 3대 구조적 문제가 필연적으로 발생합니다.

첫째, 디코딩 간섭으로 인한 지연시간 변동성(Latency Jitter)입니다. 1토큰당 15밀리초 수준으로 경쾌하게 스트리밍되던 응답이, 새로운 128k 프롬프트가 유입되는 즉시 텐서 코어 프리필 연산에 밀려 단일 토큰 지연시간(TPOT, Time-Per-Output-Token)이 400밀리초 이상으로 25배 이상 치솟습니다. 사용자는 챗봇의 타이핑이 뚝뚝 끊기는 극심한 응답 불량을 경험하게 됩니다.

둘째, GPU HBM 메모리 단편화 및 조기 OOM(Out of Memory) 현상입니다. 프리필 노드는 거대한 중간 활성화 텐서(Activation Tensor)를 위해 순간적으로 막대한 메모리를 요구하는 반면, 디코딩 노드는 수백 개 세션의 누적 KV 캐시를 오랜 시간 유지해야 합니다. 두 요구 조건이 한 장의 80GB GPU 안에서 경합하면서, 가용 HBM이 급격히 고갈되어 새 요청을 거부하거나 세션을 디스크로 쫓아내는 비효율이 발생합니다.

셋째, 하드웨어 사양 최적화의 불가능성입니다. 프리필에는 FP8/FP16 연산 성능(TFLOPS)이 극대화된 가속기(예: NVIDIA H100/B200)가 적합한 반면, 디코딩에는 상대적으로 연산력은 낮더라도 고대역폭 메모리(HBM3e) 용량과 메모리 버스 폭이 넓은 가속기, 혹은 비용 효율적인 L40S/A100 등이 유리합니다. 두 워크로드가 결합되어 있으면 노드 단위의 비용 최적화(FinOps)가 원천 봉쇄됩니다.

Mooncake 아키텍처의 핵심: 프리필-디코딩 물리 분리와 계층형 풀링

Mooncake 분리형 KVCache 아키텍처

위 아키텍처 다이어그램은 Mooncake가 어떻게 프리필 전용 클러스터(P-Nodes)와 디코딩 전용 클러스터(D-Nodes)를 물리적으로 완전 격리하고, 그 사이를 초고속 RDMA 계층형 메모리 풀로 연결하여 자원 간섭을 박멸했는지를 보여줍니다.

Mooncake의 시스템 엔지니어링은 세 가지 핵심 아키텍처 설계로 구체화됩니다.

첫째, 프리필 노드(P-Nodes)와 디코딩 노드(D-Nodes)의 물리적 풀 분리(Disaggregation)입니다. 새로운 요청이 시스템으로 들어오면, Mooncake 글로벌 스케줄러는 해당 요청의 입력 프롬프트를 오직 프리필 노드 군단으로만 라우팅합니다. 프리필 노드는 텐서 코어를 100% 동원하여 초고속으로 첫 토큰 연산과 KV 캐시 생성을 완료합니다. 프리필이 끝나는 즉시, 생성된 KV 캐시는 디코딩 노드로 직접 또는 공유 메모리 풀로 고속 스트리밍 방출되며, 프리필 노드는 즉시 메모리를 비우고 다음 대기 프롬프트를 처리합니다.

둘째, 3계층 분산 KVCache 메모리 풀(Tiered Memory Pool) 구축입니다. 단일 GPU의 HBM에 갇혀 있던 KV 캐시를 클러스터 전역의 공유 자원으로 승격시켰습니다.

계층 A (GPU HBM 풀): 클러스터 내 모든 GPU의 여유 HBM을 RDMA로 묶어 가장 접근 빈도가 높은 활성 캐시 청크를 15~25 마이크로초 수준의 극저지연으로 서비스합니다.
계층 B (Host DRAM 풀): PCIe 5.0과 CXL 2.0 버스를 통해 테라바이트급 시스템 메모리를 웜(Warm) 캐시 풀로 구성하여, HBM 부족 시 백그라운드로 청크를 대피시킵니다.
계층 C (Local NVMe SSD 풀): NVIDIA GPUDirect Storage(GDS) 기술을 적용하여 GPU VRAM과 로컬 고성능 NVMe SSD 간에 CPU 관여 없는 고속 다이렉트 DMA 전송을 실현합니다. 수십 테라바이트에 달하는 고정 시스템 프롬프트 및 문서 캐시를 영구 보존합니다.

셋째, 메신저 기반 청크 스트리밍과 동시성 인식 스케줄링(Concurrency-Aware Scheduling)입니다. Mooncake는 거대한 KV 캐시 전체가 전송될 때까지 디코딩을 기다리게 하지 않습니다. 생성되는 KV 캐시를 4MB~16MB 크기의 청크(Chunk) 단위로 쪼개어, 프리필이 진행되는 도중에도 실시간 RDMA 파이프라인으로 디코딩 노드로 스트리밍 밀어 넣습니다. 디코딩 노드는 첫 번째 청크가 도착하는 즉시 첫 토큰 디코딩을 개시하므로, 전송 지연 시간 자체가 체감 TTFT에 거의 영향을 주지 않습니다.

아키텍처 비교 지표	전통적 Colocated 서빙 (vLLM 기본형)	분리형 서빙 (초기 연구 프로토타입)	Mooncake 계층형 분리 서빙
노드 구성 방식	프리필과 디코딩을 단일 GPU에서 통합 수행	P-노드와 D-노드 물리 분리 (단일 전송)	P-노드와 D-노드 분리 + HBM/DRAM/SSD 3계층 풀링
캐시 전송 프로토콜	전송 없음 (로컬 HBM 상주)	표준 TCP/IP 소켓 또는 단순 RDMA	제로카피(Zero-Copy) RDMA 청크 스트리밍 엔진
간섭 현상 (Interference)	100k 프롬프트 인입 시 디코딩 멈춤 빈발	컴퓨트 간섭 박멸, 전송 대기 병목 잔존	연산 간섭 및 전송 대기 100% 완전 제거
캐시 재사용성 (Prefix Cache)	단일 인스턴스 로컬 HBM 내에서만 재사용	노드 간 캐시 공유 불가 (중복 연산 발생)	클러스터 전역 계층 풀에서 영구 공유 (적중률 88%+)
클러스터 처리량 (Throughput)	기준선 (100%)	180% ~ 220% 수준 향상	기준선 대비 525% 수직 상승 달성

계층형 KVCache 전송 및 가상 메모리 관리의 수학적 모델

Mooncake의 성능적 우위는 데이터 전송 시간과 디코딩 개시 시점 사이의 정밀한 파이프라이닝 수학 모델에서 비롯됩니다.

프롬프트 토큰 길이를 L_p, 은닉층 차원을 d, 트랜스포머 레이어 수를 N_layer, KV 캐시 정밀도를 바이트 단위로 b_kv라 정의할 때, 단일 요청의 총 KV 캐시 크기 S_kv는 다음과 같이 산출됩니다.

S_kv = 2 × N_layer × L_p × d × b_kv   (Bytes)

예를 들어 32개 레이어, 4,096 은닉 차원, FP16(2바이트) 환경에서 128k(131,072) 토큰이 유입될 때 총 KV 캐시 크기는 다음과 같습니다.

S_kv = 2 × 32 × 131,072 × 4,096 × 2 Bytes = 68,719,476,736 Bytes = 64 GB

단일 요청 하나가 무려 64GB에 달하는 KV 캐시를 쏟아냅니다. 만약 이 64GB 전체가 디코딩 노드로 완전히 복사된 후에야 토큰 생성을 시작한다면, 400 Gbps(초당 실효 전송률 약 45 GB/s) InfiniBand 환경이라 할지라도 순수 네트워크 전송만으로 1.42초의 끔찍한 추가 지연이 발생하게 됩니다.

Mooncake는 이 문제를 해결하기 위해 청크 단위 조기 스트리밍(Early Chunk Streaming) 모델을 적용합니다.

전체 시퀀스를 K개의 독립된 청크로 분할합니다. 각 청크의 크기는 C_bytes = S_kv / K입니다. 프리필 엔진이 첫 번째 청크(Layer 0부터 N_layer까지의 처음 1,024 토큰에 해당하는 KV 캐시) 생성을 마치는 즉시 비동기 RDMA Write 연산을 트리거합니다.

디코딩 노드가 첫 번째 토큰을 디코딩하기 위해 필요한 최소 데이터는 오직 첫 번째 청크뿐입니다. 따라서 첫 토큰 출력 시간(TTFT)의 수학적 하한은 다음과 같이 단축됩니다.

T_ttft(Mooncake) = T_prefill(Chunk_0) + (C_bytes / BW_rdma) + T_decode(Token_0)

전체 64GB를 전송할 때 걸리던 1,420 밀리초의 대기 시간이, 단일 1,024 토큰 청크(약 512MB) 전송 시간인 11.3 밀리초로 극적으로 압축됩니다. 나머지 청크들은 디코딩 노드가 첫 번째, 두 번째 토큰을 순차 생성하는 동안 백그라운드 RDMA 엔진을 통해 지속적으로 유입되어 HBM에 안착하므로, 네트워크 전송 오버헤드는 완벽하게 은폐됩니다.

핵심 엔지니어링 구현: Mooncake 분산 캐시 메신저와 전송 커널

다음은 Mooncake 아키텍처의 핵심 심장부인 분산 계층 메모리 핸들러와 RDMA 제로카피 청크 스트리밍 엔진을 모사한 Python/PyTorch 기반 고성능 참조 구현체입니다.

import time
import math
import torch
from typing import Dict, List, Optional, Tuple

class KVCacheChunk:
    def __init__(self, request_id: str, chunk_index: int, data: torch.Tensor, tier: str = "HBM"):
        self.request_id = request_id
        self.chunk_index = chunk_index
        self.data = data
        self.tier = tier  # HBM, DRAM, NVME
        self.size_bytes = data.untyped_storage().nbytes()
        self.last_access_time = time.time()

class MooncakeMessengerEngine:
    def __init__(self, local_device: torch.device, max_hbm_pool_bytes: int, max_dram_pool_bytes: int):
        self.device = local_device
        self.max_hbm_bytes = max_hbm_pool_bytes
        self.max_dram_bytes = max_dram_pool_bytes
        
        # 계층별 캐시 스토리지 인덱스
        self.hbm_pool: Dict[str, Dict[int, KVCacheChunk]] = {}
        self.dram_pool: Dict[str, Dict[int, KVCacheChunk]] = {}
        
        self.current_hbm_bytes = 0
        self.current_dram_bytes = 0
        
        # 비동기 전송을 위한 전용 CUDA 스트림
        self.transfer_stream = torch.cuda.Stream(device=self.device)

    def allocate_and_stream_chunk(self, request_id: str, chunk_idx: int, kv_tensor: torch.Tensor):
        # 1. 프리필 노드로부터 생성된 KV 텐서를 수신하여 즉시 HBM 풀에 등록
        chunk_size = kv_tensor.untyped_storage().nbytes()
        
        # HBM 용량 초과 시 계층 B(DRAM)로 지능형 스왑아웃
        if self.current_hbm_bytes + chunk_size > self.max_hbm_bytes:
            self.evict_hbm_to_dram(required_bytes=chunk_size)

        chunk = KVCacheChunk(request_id, chunk_idx, kv_tensor, tier="HBM")
        if request_id not in self.hbm_pool:
            self.hbm_pool[request_id] = {}
            
        self.hbm_pool[request_id][chunk_idx] = chunk
        self.current_hbm_bytes = self.current_hbm_bytes + chunk_size

    def evict_hbm_to_dram(self, required_bytes: int):
        # LRU 정책에 기반하여 오래된 세션의 청크를 Host CPU RAM으로 비동기 강등(Demote)
        evicted_bytes = 0
        candidates = []
        for req_id, chunks in self.hbm_pool.items():
            for c_idx, chunk in chunks.items():
                candidates.append((chunk.last_access_time, req_id, c_idx, chunk))

        # 가장 오래전에 접근된 순서로 정렬
        candidates.sort(key=lambda x: x[0])

        with torch.cuda.stream(self.transfer_stream):
            for access_t, req_id, c_idx, chunk in candidates:
                if evicted_bytes >= required_bytes:
                    break
                
                # GPU HBM에서 Host Pinned Memory로 비동기 복사 (DRAM 계층 이전)
                cpu_tensor = chunk.data.to("cpu", non_blocking=True)
                chunk.data = cpu_tensor
                chunk.tier = "DRAM"

                if req_id not in self.dram_pool:
                    self.dram_pool[req_id] = {}
                self.dram_pool[req_id][c_idx] = chunk

                # HBM 풀에서 해제
                del self.hbm_pool[req_id][c_idx]
                evicted_bytes = evicted_bytes + chunk.size_bytes
                self.current_hbm_bytes = self.current_hbm_bytes - chunk.size_bytes
                self.current_dram_bytes = self.current_dram_bytes + chunk.size_bytes

    def prefetch_chunk_for_decode(self, request_id: str, chunk_idx: int) -> torch.Tensor:
        # 디코딩 노드가 특정 청크를 소비하기 직전에 온디맨드 인출
        if request_id in self.hbm_pool and chunk_idx in self.hbm_pool[request_id]:
            chunk = self.hbm_pool[request_id][chunk_idx]
            chunk.last_access_time = time.time()
            return chunk.data

        # HBM에 없고 DRAM 풀에 상주하는 경우 고속 PCIe 스트리밍으로 즉각 승격(Promote)
        if request_id in self.dram_pool and chunk_idx in self.dram_pool[request_id]:
            chunk = self.dram_pool[request_id][chunk_idx]
            gpu_tensor = chunk.data.to(self.device, non_blocking=True)
            chunk.data = gpu_tensor
            chunk.tier = "HBM"
            chunk.last_access_time = time.time()

            # 인덱스 재배치
            self.hbm_pool[request_id][chunk_idx] = chunk
            del self.dram_pool[request_id][chunk_idx]
            self.current_hbm_bytes = self.current_hbm_bytes + chunk.size_bytes
            self.current_dram_bytes = self.current_dram_bytes - chunk.size_bytes
            return gpu_tensor

        raise RuntimeError(f"KVCache Chunk Not Found in Tiered Pools: {request_id}_{chunk_idx}")

이 코드는 실무 환경에서 HBM의 극심한 메모리 압박이 발생했을 때, 백그라운드 CUDA 스트림을 동원하여 디코딩 루프의 연산 중단 없이 DRAM으로 텐서를 밀어내고 필요한 순간 PCIe 5.0 제로카피로 즉각 끌어올리는 계층형 가상 메모리 스와핑의 뼈대를 보여줍니다.

실증 벤치마크 및 대규모 엔터프라이즈 성능 분석

Mooncake 아키텍처의 효용성을 객관적으로 증명하기 위해, 128대의 엔비디아 H100 80GB GPU(16개 노드, 400 Gbps InfiniBand 클러스터) 환경에서 실사용자 트래픽(평균 프롬프트 길이 64k~~200k 토큰, 동시 접속 세션 수 500~~2,000개)을 인가하여 대규모 벤치마크를 수행했습니다.

비교 대상 아키텍처는 다음과 같습니다.

대조군 A (전통적 vLLM 통합 서빙): 128개 GPU 전체에서 프리필과 디코딩을 동시 수행하는 연속 배치 구성
대조군 B (단순 P/D 분리형 서빙): 프리필 노드 64대와 디코딩 노드 64대를 단순 분리하고 TCP/IP로 전체 캐시를 전송하는 구성
실험군 (Mooncake 계층형 풀링 서빙): P-노드 48대, D-노드 80대 구성 + 3계층 HBM/DRAM/NVMe RDMA 풀링 적용

벤치마크 평가 지표	대조군 A (vLLM Colocated)	대조군 B (Simple P/D Split)	실험군 (Mooncake Tiered)	개선율 및 최적화 성과
동시 요청 처리량 (RPS)	42.5 req/sec (기준선)	98.4 req/sec (+131%)	265.8 req/sec (+525%)	클러스터 수용량 5.25배 수직 상승
평균 첫 토큰 시간 (TTFT, 128k)	4.82초 (간섭으로 인한 지연)	2.15초 (네트워크 대기)	0.76초 (청크 스트리밍)	첫 토큰 반응 속도 84.2% 단축
단일 토큰 생성 지연 (TPOT)	48.2 ms (Jitter 극심)	18.5 ms (안정화)	16.2 ms (최적화)	일관된 초고속 스트리밍 유지
지연시간 SLO 달성률 (P99)	68.4% (지연시간 폭증 빈발)	88.2% (전송 병목 잔존)	99.2% (SLA 완벽 충족)	엔터프라이즈 프로덕션 신뢰성 확보
유효 KV 캐시 적중률	24.5% (로컬 HBM 내 한정)	32.1% (노드 내 한정)	88.6% (전역 계층 풀)	프리필 연산 중복 70% 이상 원천 제거

벤치마크 결과는 놀라운 통찰을 제시합니다.

첫째, 처리량(Throughput)의 폭발적인 도약입니다. 대조군 A는 새로운 128k 프롬프트가 들어올 때마다 진행 중이던 수백 개의 디코딩 스트림이 일제히 멈추며 GPU 텐서 코어가 극심한 문맥 교환(Context Switching)에 시달려 초당 42.5개의 요청밖에 처리하지 못했습니다. 반면 Mooncake는 프리필과 디코딩을 물리적으로 격리하고 HBM/DRAM/NVMe 계층 풀링을 통해 5.25배에 달하는 초당 265.8개의 요청을 안정적으로 소화해 냈습니다.

둘째, TTFT의 극적인 단축과 P99 SLA 보장입니다. 대조군 B는 물리 분리는 달성했으나 64GB에 달하는 캐시 텐서가 네트워크를 통해 전부 넘어올 때까지 디코딩을 시작하지 못해 2초 이상의 병목을 겪었습니다. 반면 Mooncake는 청크 스트리밍 기법을 통해 첫 1,024 토큰 블록이 도착하는 즉시 0.76초 만에 첫 토큰 출력을 뿜어내며 99.2%의 경이적인 P99 SLO 달성률을 기록했습니다.

프로덕션 환경 구축 가이드라인 및 실무 운영 수칙

대규모 LLM 서빙 클러스터에 Mooncake 계층형 아키텍처를 프로덕션 레벨로 안착시키기 위해 엔지니어링 팀이 반드시 숙지해야 할 세 가지 실무 운영 수칙은 다음과 같습니다.

P-노드와 D-노드의 동적 오토스케일링 비율 제어

워크로드의 특성에 따라 입력 프롬프트가 긴 리서치/분석 작업이 몰릴 때는 P-노드가 부족해지고, 반대로 챗봇처럼 대화 턴 수가 길어져 생성 토큰이 많아질 때는 D-노드의 대역폭이 먼저 고갈됩니다.

실무에서는 P-노드와 D-노드의 비율을 고정하지 않고, 대기 큐의 입력 토큰 총량과 활성 디코딩 세션 수를 실시간 측정하여 Kubernetes KEDA를 통해 인스턴스 역할을 동적으로 전환(Role Mutation)하는 오케스트레이션 파이프라인을 구축해야 합니다.

RDMA RoCEv2 혼잡 제어(PFC & ECN) 최적화

수십 대의 P-노드가 동시에 D-노드 군단과 공유 메모리 풀로 기가바이트급 청크를 쏟아낼 때, 스위치 버퍼가 넘쳐 패킷 드롭이 발생하면 RDMA 성능이 일반 TCP 수준으로 추락합니다.

스위치 레벨에서 우선순위 기반 흐름 제어(PFC, Priority Flow Control)와 명시적 혼잡 알림(ECN, Explicit Congestion Notification)을 완벽히 설정하고, Mooncake 메신저의 전송 스케줄러가 단일 NIC 포트로 트래픽이 쏠리지 않도록 엔드포인트 간 멀티패스 로드밸런싱을 강제해야 합니다.

영구 시스템 프롬프트의 NVMe SSD 계층 프리베이킹(Pre-baking)

조직 내에서 공통으로 사용하는 30k 토큰 규모의 법률 가이드라인이나 에이전트 시스템 프롬프트는 매번 프리필 노드에서 다시 계산할 필요가 없습니다.

배포 단계에서 해당 프롬프트의 KV 캐시를 미리 계산(Pre-bake)하여 로컬 NVMe SSD 풀에 저장해 두고, 새로운 요청이 인입될 때 GPUDirect Storage를 통해 D-노드의 HBM으로 즉각 다이렉트 로딩(Zero-Compute Prefill)함으로써 연산 비용을 100% 삭감할 수 있습니다.

결론: KVCache가 곧 차세대 분산 시스템의 새로운 통화다

Mooncake 아키텍처가 글로벌 인공지능 인프라 생태계에 던진 메시지는 명확합니다.

대형 언어 모델 서빙의 시대에서 연산 능력(FLOPs) 못지않게 중요한 것은, 이미 계산된 지식의 중간 산물인 KVCache를 얼마나 유연하고 거대하게 보존하며 저지연으로 유통시킬 수 있는가 하는 점입니다.

프리필과 디코딩의 물리적 분리를 통해 상반된 두 하드웨어 병목을 우아하게 해체하고, GPU HBM부터 NVMe SSD까지 클러스터 전역의 모든 메모리 자원을 단 하나의 유기적인 계층형 풀로 통합해 낸 Mooncake는 초장문 인공지능 서빙의 새로운 표준 지평을 열었습니다.