문케이크(Mooncake)는 Moonshot AI가 자체 LLM 서비스인 Kimi를 운영하기 위해 개발한 서빙 시스템입니다. 이 시스템은 KVCache 중심의 분리 아키텍처를 채택해 기존 방식 대비 훨씬 높은 처리 효율을 보여줍니다. 최근 공개된 논문에 따르면 실제 워크로드 기준으로 약 75% 더 많은 요청을 같은 SLO 안에서 처리했으며, 긴 컨텍스트가 많은 시나리오에서는 처리량이 최대 525%까지 증가했다고 합니다. 이 글에서는 mooncake의 구조와 작동 원리를 자세히 살펴보겠습니다. 특히 LLM 서빙에 관심이 있는 분이라면 캐시를 어떻게 활용하는지가 서비스 비용과 응답 속도를 좌우한다는 점을 깨닫게 될 것입니다.
핵심 구성 요소는 표와 같이 정리할 수 있습니다.
| 구성 요소 | 역할 |
|---|---|
| Conductor | 캐시 위치를 알고 라우팅하는 글로벌 스케줄러 |
| Mooncake Store | 흩어진 DRAM과 SSD를 묶은 분산 KVCache 풀 |
| Transfer Engine | KV 데이터를 노드 사이로 옮기는 고속 전송 계층 |
목차
mooncake 아키텍처의 핵심
mooncake는 기존의 서빙 시스템과 다르게 GPU 중심이 아닌 캐시 중심으로 설계되었습니다. 일반적인 시스템은 요청을 받으면 GPU 자원을 기준으로 분산 처리하지만, mooncake는 만들어진 KVCache가 어디에 있는지를 먼저 확인하고 그 캐시를 재사용할 수 있는 노드로 요청을 보냅니다. 이 과정에서 무거운 prefill 연산을 건너뛰어 응답 속도를 크게 높입니다.
Conductor: 캐시를 아는 스케줄러
Conductor는 전체 클러스터에서 KVCache가 어느 노드에 저장되어 있는지 실시간으로 추적하는 역할을 담당합니다. 단순히 캐시 위치만 아는 것이 아니라, 현재 노드의 부하량과 캐시 히트율을 함께 계산해 가장 효율적인 경로를 선택합니다. 예를 들어 캐시가 있는 노드라도 대기열이 길면 오히려 손해일 수 있습니다. 캐시 히트로 절약하는 연산 시간과 줄 서서 기다리는 시간을 동시에 비교한 뒤, 최적의 결정을 내리는 것이죠. 또한 과부하가 예상되는 상황에서는 Early Rejection 전략으로 수용 가능한 요청만 받아들여 전체 시스템이 과도하게 지연되는 것을 방지합니다. 이런 지능적인 조율 덕분에 시스템 전체의 처리량이 안정적으로 유지됩니다.
Mooncake Store: 유휴 자원의 재탄생
Mooncake Store는 GPU 메모리에만 의존하지 않고, 클러스터에 놀고 있는 CPU DRAM과 SSD를 모두 활용해 분산 캐시 풀을 만듭니다. 이렇게 확보한 대용량 저장 공간에 KVCache를 저장해 두면, 필요할 때 언제든 꺼내 쓸 수 있습니다. 특히 같은 프롬프트를 사용하는 요청이 많을수록 캐시 재사용률이 높아져 서버 비용을 크게 아낄 수 있습니다. 기존에는 KV 캐시를 버리는 경우가 많았지만, mooncake는 이 데이터를 자산으로 취급합니다. 평소라면 비어 있을 GPU의 CPU 메모리와 SSD 공간을 활용한다는 점에서 매우 경제적인 설계라고 할 수 있습니다.
Transfer Engine: 캐시를 옮기는 고속도로
캐시를 저장했다면 이제 그 데이터를 필요한 노드로 빠르게 옮겨야 합니다. Transfer Engine은 NVLink, RDMA, TCP 등 다양한 통신 경로를 자동으로 선택해 캐시를 전송합니다. 보내는 쪽이 받는 쪽의 메모리에 직접 데이터를 써넣기 때문에, 받는 쪽의 연산을 방해하지 않습니다. 이 덕분에 prefill 노드와 decode 노드가 물리적으로 분리되어 있어도 성능 저하 없이 데이터를 주고받을 수 있습니다. 사용자 입장에서는 마치 하나의 API 호출처럼 느껴지는데, 이렇게 간단한 인터페이스 덕분에 다양한 프레임워크와의 통합도 수월합니다.
실제 성능 개선 수치와 경험
mooncake 논문에서 보고된 성능 지표는 상당히 인상적입니다. 실제 운영 워크로드를 기준으로 약 75% 더 많은 요청을 같은 SLO 안에서 처리했다고 합니다. 특히 긴 컨텍스트가 많은 특정 시나리오에서는 처리량이 최대 525%까지 증가했다는데, 이는 KVCache를 재사용한 효과입니다. 저도 직접 vLLM에 mooncake 커넥터를 연결해 테스트했는데, 설정이 어렵지 않았고 적용 후 첫 토큰 지연(TTFT)이 눈에 띄게 개선되는 것을 확인했습니다. 아직 운영 환경에는 적용하지 않았지만, 다음 프로젝트에서는 꼭 도입해 볼 계획입니다.
기존 vLLM 환경에서는 prefill과 decode가 같은 GPU를 공유하기 때문에, 대규모 prefill 요청이 들어올 때마다 decode 응답 속도가 출렁거리는 문제가 있었습니다. mooncake는 이 둘을 물리적으로 분리해 decode가 prefill의 간섭을 받지 않으므로 토큰 간격(TBT)이 일정하게 유지됩니다. 이러한 차이는 긴 문맥을 다루는 서비스에서 특히 중요합니다.
vLLM에서는 공식적으로 mooncake 커넥터를 지원합니다. 적용 방법이 궁금하다면 를 참고하시면 좋습니다. 또한 더 자세한 아키텍처 설명이 필요하다면 를 읽어보시길 권합니다.
마무리 및 전망
mooncake는 KVCache를 단순한 임시 메모리가 아닌 클러스터 전체가 공유하는 자산으로 승격시킨 혁신적인 시스템입니다. prefill과 decode를 분리한 아키텍처 위에 유휴 DRAM과 SSD를 활용한 멀티레벨 캐시 풀을 구축하고, Conductor와 Transfer Engine이 이를 효율적으로 운영합니다. 그 결과 같은 GPU 자원으로도 훨씬 더 많은 요청을 처리할 수 있게 되었습니다.
앞으로 LLM 서빙을 운영하려는 기업이라면 mooncake라는 선택지를 반드시 검토해야 할 것 같습니다. 특히 캐시 최적화가 곧 비용 절감으로 이어지는 상황에서 이 기술은 큰 경쟁력이 될 것입니다. 저도 계속해서 관련 기술을 지켜보며 다음에 더 깊은 내용으로 다시 찾아뵙겠습니다.
FAQ
Q: mooncake는 무료로 사용할 수 있나요?
A: mooncake는 오픈소스로 공개되어 있어서 누구나 사용할 수 있습니다. vLLM과 같은 오픈소스 LLM 서빙 프레임워크에서 커넥터로 함께 활용할 수 있습니다.
Q: mooncake를 사용하려면 어떤 하드웨어가 필요한가요?
A: 기본적으로 GPU 서버가 필요하지만, CPU DRAM과 SSD를 추가로 활용할 수 있어서 비교적 저렴한 스토리지로도 큰 효과를 볼 수 있습니다.
Q: 기존의 vLLM과 함께 사용할 수 있나요?
A: 네, vLLM에서 mooncake 커넥터를 공식 지원하므로 기존 vLLM 설정에 손쉽게 추가할 수 있습니다.
