모델 마켓플레이스에는 아무도 광고하지 않는 회계 문제가 있다. 알리바바 클라우드의 Model Studio는 API 하나 뒤에서 수천 개의 모델을 서빙하는데, 트래픽은 모든 마켓플레이스가 아는 그 모양을 따른다. 논문의 프로덕션 표본에서 779개 모델 중 94.1%가 1억 6,760만 요청의 1.35%를 나눠 받았다. 그런데도 서빙의 예법상 그 차가운 모델들 각각이 따뜻한 GPU 위에 앉아 있어야 하니, 약 3만 장 규모 함대의 17.7%가 장당 초당 0.2 요청도 안 되는 부하로 놀았고, 인기 모델들은 또 다른 시간 축에서 예약분을 넘는 버스트를 일으켰다. 알리바바와 북경대의 SOSP 2025 논문은 이 낭비에 숫자를 붙인 다음 그 대부분을 걷어낸다[1]. Model Studio 베타에서 돌아가는 풀링 시스템 Aegaeon은 마켓플레이스 모델 수십 개가 쓰던 GPU를 1,192장에서 213장으로, 82% 줄였고, 이 주장은 석 달의 프로덕션 트래픽을 견뎠다.

아래는 그 논지를 우리 표현으로 정리한 것이다. 흥미로운 대목은 풀링이 도움이 된다는 사실이 아니라(풀링은 모두가 한다), 기존의 모든 풀링 접근이 왜 GPU당 모델 2~3개의 벽에 부딪혔는지, 그리고 그 벽을 넘는 데 무엇이 필요했는지다.

요청 단위 스케일링이 셋에서 멈추는 이유

기존 연구는 두 갈래다. 멀티플렉싱은 모델 여럿을 한 장치에 올려 공간적·시간적으로 나눠 쓰지만[3], 제약은 가중치다. 이 워크로드의 모델은 평균 25.1 GB라서 80 GB 카드에 둘, 잘해야 셋이 들어간다. 서버리스 계열의 오토스케일링[2]은 가중치를 호스트 메모리나 SSD에 두고 필요할 때 올려 메모리 천장을 걷어내지만, 모델 교체는 요청이 끝나야만 일어난다. 논문의 가장 날카로운 분석적 한 수는 이 선택에 관한 작은 정리다. 각 모델의 요청이 비율 λ의 포아송 과정으로 도착하고 요청 하나가 시스템을 T초 점유한다면, 동시에 활성인 모델 수의 기댓값은 M·(1−e^(−λT))다. 프로덕션 수치(λ=0.037, T=16.79초)를 대입하면 모델 100개 중 평균 46.55개가 활성이다. 총 부하가 고작 초당 3.7 요청인데도 그렇다. 요청 단위 시스템은 활성 모델 전부를 어딘가에 상주시켜야 하므로 풀링 비율은 100/46.55 근처, 즉 GPU당 모델 3개 아래에 묶인다. 멀티플렉싱보다 나을 것이 없는 셈이다. LLM 요청은 길어서 “활성”은 “바쁨”보다 훨씬 약한 조건이고, 나머지는 대기열 선두 차단(HOL blocking)이 해치운다. 새 모델의 첫 토큰이 남의 생성 전체가 끝나기를 기다리는 것이다.

Aegaeon의 답은 스케줄링의 양자를 토큰으로 만드는 것이다. 임의의 두 토큰 사이에서 시스템은 상주 모델을 선점 중단하고, 그 KV 캐시를 호스트 메모리에 내려놓고, 다른 모델을 올려 명시적 시간 예산 아래 잠시 생성한 뒤 다시 돌아올 수 있다. 모든 요청이 여전히 마감시한을 지킨다는 조건에서다. 서비스 품질도 토큰 단위로 정의된다. 첫 토큰에는 TTFT 목표(프로덕션 기준 10초), 이후 토큰에는 토큰 간 간격(TBT) 목표(100 ms)가 붙고, 디코딩된 출력은 버퍼링할 수 있으므로 버스트 속도로 디코딩한 요청은 여유 시간을 벌고, 스케줄러는 그 여유를 다른 모델을 서빙하는 데 쓴다. 프리필과 디코딩은 GPU 풀과 정책이 분리된다[5]. 프리필 인스턴스는 그룹 단위 선착순 큐를 돌리고(같은 모델의 요청을 최대 8개까지 그룹으로 묶어 모델 교체 한 번을 여러 도착에 상각한다), 디코딩 인스턴스는 모델별 배치에 대한 가중 라운드로빈을 돌리는데, 각 배치의 시간 할당량은 토큰 마감 여유와 회전 목록에 든 모델들의 교체 비용에서 계산된다.

롱테일, 그리고 요청 단위 스케일링을 가두는 정리. a, 프로덕션 표본에서 마켓플레이스 모델 779개의 94.1%가 1억 6,760만 요청의 1.35%를 받으면서 약 3만 GPU의 17.7%를 점유한다. b, 비율 λ의 포아송 도착과 서비스 시간 T 아래에서 활성 모델 수의 기댓값은 M·(1−e^(−λT)). 실측값 λ=0.037, T=16.79초에서는 산발적으로 호출되는 모델 100개 중 약 47개가 활성이므로, 요청 경계에서만 모델을 바꾸는 시스템은 GPU당 모델 3개를 넘지 못한다. 토큰 단위 선점은 이 한계를 우회해 스케줄링한다. 이 글을 위해 새로 만든 도판.

모델 교체 비용을 1초 아래로

교체가 수십 초씩 걸린다면 그 어떤 스케줄링도 소용이 없는데, 기본 상태가 정확히 그렇다. 13B vLLM 인스턴스를 내렸다 다시 올리는 데 최대 26.9초가 들고, 그 대부분은 가중치 근처에 있지도 않다. 논문의 결산은 그 시간이 엔진 재초기화(분산 실행기 구성, 프로파일링, KV 캐시용 메모리 고정), 파편화된 장치 메모리가 강제하는 가비지 컬렉션, 그리고 직렬화된 KV 캐시 전송에 숨어 있음을 밝힌다. Aegaeon은 항목별로 공격한다. 엔진 구성 요소는 인스턴스마다 한 번만 초기화해 모델들 사이에서 재사용하고, 가중치와 KV 캐시만 모델 고유로 취급한다. 이것만으로 지연의 80% 이상이 사라진다. 장치 메모리는 범프 할당 방식의 자체 관리 버퍼가 되고, 로드 시점에 파라미터 클래스를 바꿔치기해 텐서 라이브러리의 할당기를 우회하므로, 연달아 모델을 올려도 컬렉션이 발동하지 않는다. 호스트 메모리에는 공유 모델 캐시와 고정(pinned) 스테이징 버퍼를 두어 멀티스레드 파이프라인 가중치 적재가 1초 안에 끝나고, 프리페치 스트림이 다음 스케줄된 모델을 실행 중인 모델 옆에 미리 올려 두어 전체 교체의 절반가량이 사실상 즉시 완료된다. 모양이 제각각인 모델들의 KV 캐시는 슬랩 할당으로 통합 풀에 담기고(파편화는 20% 아래로 유지), 전송은 요청 단위의 CUDA 이벤트로 동기화되어, 디코딩 인스턴스는 배치 전체가 아니라 해당 요청의 캐시가 도착하는 순간 생성을 시작한다. 처음부터 끝까지 재면 교체 절차의 지연이 97% 줄어 1초 미만이 된다.

선제적 모델 교체의 비용, 최적화 전과 후. 최적화 없는 절차(KV 캐시 하역, 가비지 컬렉션, 엔진 재초기화, 가중치 적재, KV 캐시 적재)는 13B 모델에서 26.9초에 이른다. 구성 요소 재사용이 재초기화를 없애고, 명시적 메모리 관리(범프 할당 장치 버퍼, 공유 호스트 모델 캐시, 슬랩 할당 KV 풀)가 컬렉션을 없애며 적재를 가속하고, 프리페치가 교체의 절반가량에서 적재를 완전히 숨기고, 요청 단위 CUDA 이벤트 동기화가 캐시 트래픽을 겹친다. 지연의 97%가 사라지고 교체는 1초 안에 끝난다. 이 글을 위해 새로 만든 도판.

숫자가 말하는 것

H800 16장 테스트베드에서 ServerlessLLM(출력 길이를 미리 아는 오라클 SJF 변형 포함)과 MuxServe를 상대로, Aegaeon은 같은 서비스 품질에서 2~2.5×의 요청 도착률을 감당하거나 1.5~9×의 굿풋을 낸다. 디코딩 GPU 10장으로 모델 70개까지 서빙하니, GPU당 모델 일곱이라는 헤드라인이 여기서 나온다. 더 무게 있는 결과는 프로덕션 배치다. 리전을 가로지르는 213장의 H20 클러스터가 1.8~7B 모델 28개와 32~72B 모델 19개를 싣고 있는데, 이 워크로드가 예전에는 H20 1,192장을 차지했다. 평균 GPU 사용률은 13.3~33.9% 범위에서 48.1%로 올랐고, 관측 기간 동안 SLO 위반은 없었다. 실리콘의 선택도 눈여겨볼 대목이다. H20은 수출 규제에 맞춘 가속기이고, 중국에서 그 희소가치를 생각하면 함대 82% 감축은 운영 각주가 아니라 전략적 숫자로 읽힌다.

접근이 얇아지는 지점에 대해서도 논문은 솔직하다. 마감시한을 기본값의 1/5(첫 토큰 2초, 토큰 간 20 ms)로 조이면 선점의 재원인 여유 시간이 사라지고, 가장 엄격한 구성에서는 교체 비용을 아예 내지 않는 정적 멀티플렉싱이 이긴다. 토큰 단위 풀링은 산발적 트래픽의 느슨한 SLO를 현금화하는 기계이지 만능 서빙 가속기가 아니며, 저자들의 배치도 그렇다. 뜨겁고 지연에 민감한 모델은 전용 인스턴스를 유지하고, 롱테일이 통합된다.

배치 결과, 그리고 유효 영역 표시. 프로덕션: 마켓플레이스 모델 47개에서 H20 1,192장이 213장으로(82%), 사용률은 13.3~33.9%에서 48.1%로, 베타 석 달간 SLO 위반 관측 없음. 테스트베드: 오토스케일링·멀티플렉싱 베이스라인 대비 감당 가능한 도착률 2~2.5×, 굿풋 1.5~9×, 디코딩 GPU당 모델 일곱. 경계: 마감시한을 5× 조이면 선점 여유가 사라져 정적 멀티플렉싱이 다시 앞선다. 이 글을 위해 새로 만든 도판.

우리가 읽어낸 것

캐시 배치를 추론의 중심 문제로 놓는 KV 캐시 중심 서빙 설계는 Mooncake의 분리형 아키텍처[6]에서, 그리고 CXL에 얹힌 형태로는 Beluga에서 만난 바 있다. Aegaeon은 같은 논리를 한 층 위로 확장한다. 요청의 캐시가 어디 사는지만이 아니라 어느 모델이 GPU를 소유하는지 자체가, 빠른 상태 이동이 뒷받침하는 토큰 단위 결정이 된다. 우리는 저 정리가 오래 남을 기여라고 본다. E[m]=M·(1−e^(−λT))는 요청 단위 서버리스 LLM 서빙이 시도한 모두를 실망시킨 이유의 한 줄 설명이고, 인프라 팀에게는 측정 가능한 숫자 둘로 자기 풀링 상한을 예측하는 공식을 쥐여 준다. 한편 82%라는 숫자에는 단서가 붙어야 한다. 느슨한 SLO 아래 선별된 마켓플레이스 모델 47개, 비교 양쪽 모두에 여유 자원이 깔린 조건의 기술이지 함대 전체의 법칙이 아니다. 이 논문이 확립한 것은, 차가운 모델 하나당 따뜻한 GPU 한 장으로 매겨져 있던 모델 마켓의 롱테일 가격이 이제 그 7분의 1 근처에서 결정된다는 것, 그리고 빠져 있던 재료가 이색적인 하드웨어가 아니라 100 ms마다 결정을 내릴 의지가 있는 스케줄러였다는 사실이다.

출처와 저작권 안내

이 글은 Silicon and Systems가 작성한 편집 요약으로, 아래에 인용한 논문의 논지를 우리 표현으로 재서술한 것이다. 원문의 문장, 도판, 표는 이 글에 재사용하지 않았으며, 이 페이지의 도판은 모두 이 요약을 위해 새로 제작했다. 논문은 SOSP 2025에서 발표되었고, 확정본은 Proceedings of the 31st ACM Symposium on Operating Systems Principles에 실려 있다. (c) 2025 the authors, publication rights licensed to ACM.