챗봇의 다회차 대화는 이전 문맥을 다시 읽을 때마다 GPU에서 프리필 연산을 수행합니다. 중국에서 128K 토큰 컨텍스트를 소비자 기능으로 제공한 Moonshot AI는 반복 계산 대신 캐시 재사용을 선택했습니다. 한 번 계산한 결과를 저장한 뒤 필요할 때 다시 불러오는 방식입니다. 칭화대와 함께 발표한 FAST 2025 최우수 논문은 이 서빙 플랫폼을 Mooncake라는 이름으로 설명합니다[1]. Mooncake는 GPU 서버의 유휴 CPU 메모리와 DRAM, SSD, RDMA NIC를 클러스터 전체의 KV 상태 캐시로 묶고, 필요한 캐시의 위치에 따라 요청을 스케줄링합니다. 회사 집계에 따르면 같은 A800과 H800 장비군은 이전 시스템보다 각각 115%와 107% 많은 요청을 처리하며, 수천 노드에서 하루 1,000억 토큰 이상을 처리합니다.
아래는 그 논지를 우리 표현으로 정리한 것입니다. 논문의 표어인 “저장을 더 쓰고 연산을 덜 쓴다”가 성립하려면 캐시된 프리픽스를 가져오는 시간이 같은 구간을 다시 계산하는 시간보다 짧아야 합니다. 논문은 이 조건을 모델과 장치별 대역폭으로 계산합니다.
풀을 정당화하는 부등식
각 토큰의 KV 항목은 앞선 토큰들에만 의존하므로, 이전 트래픽과 프리픽스를 공유하는 요청은 캐시된 상태가 HBM에 제때 도착하면 해당 프리픽스의 연산을 건너뛸 수 있습니다. 논문은 이 조건을 대역폭 임곗값으로 나타냅니다. A800 GPU 8장의 LLaMA3-70B 구성에서는 캐시 전송 대역폭이 6 GB/s 이상이면 첫 토큰 시간(TTFT) 기준으로 재사용이 유리하고, H800에서는 임곗값이 19 GB/s로 높아집니다. 노드 하나의 여유 DRAM(약 1 TB, 토큰당 KV 상태 320 KB 기준 약 300만 토큰)은 Kimi 트레이스에서 달성 가능한 적중률의 절반에도 못 미칩니다. 거의 모든 재사용 가능 상태를 담으려면 약 5,000만 토큰, 즉 노드 20개 이상의 메모리를 모아야 합니다. 필요한 전송 대역폭은 100 Gbps NIC 하나로 제공할 수 있으므로, 캐시를 클러스터 전체에 분산하고 서빙 스케줄러가 위치를 직접 고려하는 구조가 필요합니다.
그래서 Mooncake는 장비군을 세 갈래로 나눕니다. 프리필 인스턴스와 디코딩 인스턴스는 이제 익숙해진 분리형 스타일로 별도 풀이고[3][5], 그 아래에 KV 블록(평가 기준 블록당 256 토큰)을 프리픽스 인지 해시로 키잉해 담는 분산 캐시 Mooncake Store가 깔립니다. 뜨거운 블록은 여러 노드에 복제되고 차가운 블록은 LRU로 밀려납니다. 요청은 네 단계로 흐릅니다. 전역 스케줄러 Conductor가 프리필과 디코딩 인스턴스 쌍을 고르고, 재사용 가능한 캐시 블록이 프리필 노드로 흘러들어오고, 증분 프리필이 레이어 단위로 돌며 새로 생긴 KV 상태를 만들어지는 족족 디코딩 노드로 흘려보내고, 요청은 디코딩 쪽의 연속 배칭에 합류합니다. 긴 컨텍스트의 프리필은 청크 단위 파이프라인 병렬화로 여러 노드에 걸쳐 병렬화되는데, 활성값을 청크 경계에서만 넘기므로 노드 간 텐서 병렬화의 레이어당 올리듀스 비용도, 시퀀스 병렬화의 끊임없는 재분할도 피합니다.
스토리지 시스템처럼 지은 전송 엔진
핵심 구현은 캐시를 메모리 접근에 가까운 속도로 옮기는 전송 엔진입니다. 각 서버는 NIC과 메모리(소켓별 DRAM, GPU별 VRAM)의 거리 정보를 토폴로지 행렬로 제공하고, 전송 엔진은 이에 맞춰 경로를 선택합니다. 요청 하나를 16 KB 조각으로 나눠 사용 가능한 NIC에 분산하고, 엔드포인트 풀링과 고장 링크 자동 우회도 지원합니다. 200 Gbps NIC 4장에서는 87 GB/s, 400 Gbps NIC 8장에서는 190 GB/s를 유지했습니다. 40 GB 캐시 데이터(128K 토큰 문맥) 기준으로 TCP 전송보다 각각 2.4배와 4.6배 빨랐습니다. 네트워크가 약 100 Gbps 아래로 내려가면 TTFT가 재계산 수준으로 늘어나므로, 저자들은 이를 배치에 필요한 최소 대역폭으로 제시합니다. 이 전송 엔진은 오픈소스로 공개되어 Kimi 이외의 시스템에서도 사용되고 있습니다.
캐시가 수동적인 풀이기를 멈추는 지점이 스케줄링입니다. Conductor는 도착한 요청마다 후보 프리필 노드별 TTFT를 대기 시간, 프리필 시간(입력 길이와 프리픽스 적중 길이에 대한 회귀 모델), 캐시 전송 시간의 합으로 추정해 총합이 가장 작은 곳에 배치하고, 어느 노드도 SLO를 못 맞추면 천천히 실패하도록 들이는 대신 앞단에서 거절합니다. 뜨거운 프리픽스는 저절로 이주합니다. 가장 잘 맞는 캐시가 과부하 노드에 있으면 선택된 노드가 사본을 끌어오므로, 시스템 프롬프트 같은 공유 프리픽스는 사용량 예측 없이도 거의 모든 프리필 인스턴스에 복제되어 있게 됩니다. 논문의 재생 실험에서 이 캐시·부하 동시 인지 정책은 평균 TTFT를 3.07초로 깎습니다. 부하 분산만 하면 5.27초, 무작위 배치면 19.65초입니다.
운영 환경과 시험대에서 확인한 결과
8-GPU 노드 16대에서 LLaMA3-70B급 대역 모델로 운영 환경 트레이스를 재생한 실험에서, Mooncake의 우위는 작업부하가 얼마나 많은 이력을 지니는지에 비례해 커집니다. vLLM 계열(기본, 프리픽스 캐싱, 청크 프리필)[2][4]을 상대로 대화 트레이스에서는 토큰 간 마감시한의 엄격함에 따라 SLO 안에서 처리한 요청이 59~498% 많고, 반복적인 시스템 프롬프트로 캐시 비율이 59%까지 오르는 도구·에이전트 트레이스에서는 로컬 프리픽스 캐싱 대비로도 42%, 장문 합성 믹스에서는 40%를 더 냅니다. 그 기제는 프리필 결산에서 그대로 보입니다. 전역 캐싱이 세 작업부하의 프리필 GPU 시간을 36~64% 줄이고, 128K 토큰 입력에서 95% 프리픽스 적중은 프리필 시간의 92%를 지웁니다. 스토어 설계만 떼어 보면, 같은 용량의 로컬 캐시 대비 전역 풀이 적중률을 최대 2.36× 올리고 프리필 연산을 최대 48% 줄입니다. 이런 시스템을 꾸릴 사람을 위한 실무적 각주 하나. 프리필과 디코딩 노드의 비율을 훑으면 최적은 대략 1:1이고, Moonshot은 노드 역할을 동적으로 뒤집는 대신 비율을 고정해 둡니다. 운영 환경 트래픽의 통계는 느리게 움직이기 때문입니다.
결과의 적용 범위도 구분해야 합니다. 재현 가능한 수치는 공개 트레이스를 재생한 대역 모델에서 나왔고, 운영 환경 수치는 이전 vLLM 기반 시스템과 비교한 과거 통계입니다. 이득은 Kimi의 채팅 작업부하가 유지하는 프리픽스 적중률(공개 트레이스 기준 40~66%)에 비례합니다. 유효 용량은 시스템이 받아들인 요청만 세므로, 조기 거절 정책도 결과에 영향을 줍니다. 토큰당 320 KB라는 캐시 크기 역시 LLaMA3-70B 어텐션 구조에서 나온 값입니다. 딥시크의 공동 설계[8]처럼 KV 상태를 줄이는 어텐션을 사용하면 같은 메모리 풀에 더 많은 토큰을 저장할 수 있으므로 손익분기점도 달라집니다.
KV 캐시는 서빙 시스템의 중심 자원
Mooncake의 의미는 KV 캐시를 부수적인 최적화가 아니라 서빙 시스템의 중심 자원으로 다뤘다는 데 있습니다. 이후 Beluga는 풀링된 캐시를 CXL 메모리에 배치해 네트워크를 거치던 가져오기 경로를 바꾸었고, Aegaeon[7]은 토큰 단위 스케줄링을 모델 배치 문제까지 확장했습니다. Mooncake가 남긴 비교 기준도 중요합니다. 원격 캐시가 유리해지는 대역폭 조건, 로컬 메모리만으로는 수용하지 못하는 용량 곡선, 실제 프리픽스 재사용을 담은 공개 트레이스를 함께 제시했기 때문입니다. 어텐션이 KV 상태를 압축하거나 메모리 패브릭이 전송 비용을 낮추면 손익분기점은 다시 계산해야 하지만, 어떤 입력으로 계산해야 하는지는 이 논문이 분명히 만들었습니다.
캐시의 경제성은 피한 프리필 연산에서 시작하는 지점
KV 캐시는 현재의 서비스 목표에서 가져오는 비용이 다시 계산하는 비용보다 낮을 때만 가치가 있습니다. 재계산은 GPU 프리필 용량을 쓰고 같은 배치의 다른 요청을 늦출 수 있습니다. 적재는 호스트나 SSD 대역폭, 네트워크, 목적지 메모리를 사용합니다. 접두부 길이, 캐시 위치, 링크 부하, 대기 중인 프리필 양에 따라 더 싼 경로가 달라집니다.
따라서 적중률 하나로는 부족합니다. 피한 프리필 토큰, 이동한 바이트, 전송 시간, 목적지 대기, 해당 요청과 주변 요청의 TTFT 변화를 함께 기록해야 합니다. 짧은 접두부는 적중으로 잡혀도 이동 비용보다 적은 시간을 아낄 수 있고, 긴 접두부는 재사용 빈도가 낮아도 한 번의 적중이 큰 연산을 피할 수 있습니다.
과부하 제어도 아키텍처의 일부
처리 가능한 범위를 넘었을 때 모든 요청을 받으면 전체가 SLO를 놓칠 수 있습니다. Mooncake의 조기 거절은 비싼 부분 실행을 시작하기 전에 요청을 걸러 유효 처리량을 보호합니다. 오판의 비용은 대칭이 아닙니다. 잘못 받은 요청은 다른 요청까지 늦추고, 잘못 거절한 요청은 쓸 수 있는 용량을 남깁니다. 수용률, 수용한 요청의 SLO 충족률, 오거절 추정치, 가속기 시간당 완료 요청을 같은 부하에서 보고해야 합니다.
분리형 구조에서는 프리필을 끝냈는데 KV 상태를 받을 디코드 용량이 없는 경우도 생깁니다. 이때 큰 중간 상태가 새 대기열을 만듭니다. 비싼 프리필을 시작하기 전에 디코드 메모리와 실행 구간을 예약하거나 확률적으로 반영해야 합니다.
캐시 풀에는 거리와 장애 영역이 있는 구조
같은 호스트, 같은 랙, 다른 장애 영역의 캐시 복사본은 지연시간과 가용성이 다릅니다. 인기 접두부를 복제하면 핫스폿을 줄일 수 있지만 과도한 복제는 풀의 용량을 줄입니다. 배치 정책은 재사용 가능성, 링크 경합, 장애 복구를 함께 고려해야 합니다.
캐시 항목이 사라져도 서비스는 잘못된 답을 내지 않고 재계산으로 돌아가야 합니다. 모델 가중치, 토크나이저, 프롬프트, 어텐션 구현이 바뀌면 KV 상태도 버전을 구분해야 합니다. Mooncake는 캐시 용량보다 캐시 경제성을 설계의 중심에 둡니다. 어떤 접두부가 어느 연산을 피하고, SLO 전에 도착하며, 전체 클러스터의 완료 대화를 얼마나 늘리는지가 최종 판단 기준입니다.
용량 계획도 완료한 대화를 기준으로 시작해야 합니다. 문맥과 출력 길이 분포, 재사용 거리, TTFT와 토큰 지연 목표, 수용하려는 요청 비율에서 프리필 GPU, 디코드 GPU, 캐시 바이트, 패브릭 수요를 계산합니다. 어텐션 구조와 KV 표현이 바뀌면 토큰당 캐시가 줄어 분리형 풀의 경제성이 달라질 수 있고, 프리필 커널이 빨라지면 적재보다 재계산이 유리한 구간도 넓어집니다. 캐시 중심 시스템도 캐시를 가져오지 않는 선택과 계속 비교해야 합니다.
운영 화면에는 캐시 적중률보다 피한 프리필 토큰과 실제로 줄어든 TTFT를 우선 표시하는 편이 좋습니다. 적중했지만 늦게 도착한 상태와 미리 가져와 제시간에 쓴 상태를 나누면 용량 확대와 스케줄링 개선 중 어느 투자가 필요한지 판단할 수 있습니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 요약으로, 아래에 인용한 논문의 논지를 우리 표현으로 재서술한 것입니다. 원문의 문장, 도판, 표는 이 글에 재사용하지 않았으며, 이 페이지의 도판은 모두 이 요약을 위해 새로 제작했습니다. 논문은 제23회 USENIX Conference on File and 스토리지 Technologies(FAST 2025)에서 발표되었고 USENIX에서 오픈 액세스로 열람할 수 있습니다. (c) 2025 the authors.