모델 마켓플레이스에는 요청량과 GPU 점유율이 맞지 않는 자원 배분 문제가 있습니다. 알리바바 클라우드의 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% 줄였으며, 3개월의 실제 트래픽으로 결과를 검증했습니다.
아래에서는 그 논지를 우리 표현으로 정리합니다. 이 논문의 핵심은 풀링 자체보다 기존 접근에서 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개까지 그룹으로 묶어 모델 교체 한 번을 여러 도착에 상각합니다), 디코딩 인스턴스는 모델별 배치에 대한 가중 라운드로빈을 돌리는데, 각 배치의 시간 할당량은 토큰 마감 여유와 회전 목록에 든 모델들의 교체 비용에서 계산됩니다.
모델 교체 비용을 1초 아래로
교체가 수십 초씩 걸린다면 그 어떤 스케줄링도 소용이 없습니다. 13B vLLM 인스턴스를 내렸다 다시 올리는 데 최대 26.9초가 들고, 그중 대부분은 가중치 적재가 아니라 준비와 메모리 관리 단계에서 발생합니다. 논문의 시간 분석을 보면 엔진 재초기화(분산 실행기 구성, 프로파일링, KV 캐시용 메모리 고정), 파편화된 장치 메모리가 일으키는 가비지 컬렉션, 직렬화된 KV 캐시 전송이 지연을 만듭니다. Aegaeon은 지연 항목을 하나씩 줄입니다. 엔진 구성 요소는 인스턴스마다 한 번만 초기화해 모델들 사이에서 재사용하고, 가중치와 KV 캐시만 모델 고유로 취급합니다. 이것만으로 지연의 80% 이상이 사라집니다. 장치 메모리는 범프 할당 방식의 자체 관리 버퍼가 되고, 로드 시점에 파라미터 클래스를 바꿔치기해 텐서 라이브러리의 할당기를 우회하므로, 연달아 모델을 올려도 컬렉션이 발동하지 않습니다. 호스트 메모리에는 공유 모델 캐시와 고정(pinned) 스테이징 버퍼를 두어 멀티스레드 파이프라인 가중치 적재가 1초 안에 끝나고, 프리페치 스트림이 다음 스케줄된 모델을 실행 중인 모델 옆에 미리 올려 두어 전체 교체의 절반가량이 사실상 즉시 완료됩니다. 크기가 서로 다른 모델의 KV 캐시는 슬랩 할당으로 통합 풀에 담기고(파편화는 20% 아래로 유지), 전송은 요청 단위의 CUDA 이벤트로 동기화됩니다. 따라서 디코딩 인스턴스는 배치 전체가 아니라 해당 요청의 캐시가 도착하는 순간 생성을 시작합니다. 처음부터 끝까지 재면 교체 절차의 지연이 97% 줄어 1초 미만이 됩니다.
운영 환경과 시험대에서 확인한 결과
H800 16장 테스트베드에서 ServerlessLLM(출력 길이를 미리 아는 오라클 SJF 변형 포함)과 MuxServe를 상대로, Aegaeon은 같은 서비스 품질에서 2~2.5배의 요청 도착률을 감당하거나 1.5~9배의 굿풋을 냅니다. 디코딩 GPU 10장으로 모델 70개까지 서빙하므로 GPU당 모델 일곱이라는 결과가 나옵니다. 더 중요한 근거는 운영 환경 배치입니다. 리전을 가로지르는 H20 213장 규모의 클러스터가 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에 여유가 있는 모델의 유휴 시간을 다른 모델에 배분하는 방법이며, 모든 서빙 작업을 가속하는 방식은 아닙니다. 실제 배치에서도 호출이 많고 지연에 민감한 모델은 전용 인스턴스를 유지하고 롱테일 모델만 통합했습니다.
모델 풀링의 상한을 좌우하는 요청률과 SLO
캐시 배치를 추론의 중심 문제로 놓는 KV 캐시 중심 서빙 설계는 Mooncake의 분리형 아키텍처[6]에서, CXL을 사용한 형태는 Beluga에서 살펴봤습니다. Aegaeon은 같은 논리를 모델 배치까지 확장합니다. 요청의 캐시 위치뿐 아니라 어느 모델이 GPU를 사용하는지도 빠른 상태 이동을 전제로 토큰마다 다시 결정합니다. E[m]=M·(1−e^(−λT))는 요청 단위 서버리스 방식에서 풀링 비율이 제한되는 이유를 설명하고, 인프라 팀이 요청률과 서비스 시간으로 자체 상한을 계산하게 해 줍니다. 다만 82% 절감은 SLO에 여유가 있는 마켓플레이스 모델 47개를 선별하고 비교 시스템 양쪽에 예비 자원을 둔 조건에서 측정한 값이며, 전체 장비군에 그대로 적용되는 비율은 아닙니다. 이 논문이 입증한 범위는 GPU 한 장당 최대 일곱 개 모델을 운영한 배치와, 이를 가능하게 한 100 ms 단위 스케줄링입니다. 다른 서비스에서는 모델 크기, 요청률, SLO를 식에 넣어 풀링 가능한 수를 다시 계산해야 합니다.
토큰 마감 시간: 수용 제어의 필요성
토큰 단위 선점은 빈 시간을 만들지만 무한한 용량을 만들지는 않습니다. 요청 하나를 받으면 첫 토큰 마감 시간, 이후 토큰의 반복 마감 시간, 적재할 모델 가중치, 선점 중 보존할 KV 상태가 함께 늘어납니다. 개별 선택은 모두 합리적이어도 전체 회전 순서로는 모든 마감 시간을 지킬 수 없는 조합이 생깁니다. 따라서 가중 순환 스케줄 앞에 수용 가능성을 판단하는 단계가 필요합니다.
프리필과 디코드는 따로 계산해야 합니다. 프리필은 크고 불규칙한 연산이며 같은 모델 요청을 묶으면 이득을 얻습니다. 디코드는 작은 연산을 반복하지만 각 요청이 상태와 다음 토큰 마감 시간을 계속 보유합니다. 긴 응답 하나는 순간 연산량이 작아도 수 분 동안 가중치와 KV 캐시를 필요로 할 수 있습니다. 요청 수와 초당 토큰만으로는 부족하고 상주 바이트, 예상 디코드 시간, 전환 비용, 이미 약속한 여유 시간을 함께 봐야 합니다.
출력 토큰을 버퍼에 모아 두는 방식에도 한도가 필요합니다. 빠르게 만든 토큰으로 시간을 벌 수 있지만, 그 여유를 차가운 모델 적재에 모두 쓰면 사용자는 불규칙한 정지를 경험할 수 있습니다. 평균 처리량뿐 아니라 마감 시간 충족률과 토큰 사이 지연 분포를 함께 보고해야 합니다.
실제 풀링 비율을 좌우하는 상태 이동
요청 단위 스케일링의 한계를 토큰 단위 선점이 없애도 데이터 경로의 한계는 남습니다. 가중치는 호스트에서 GPU로 움직이고 KV 상태는 반대 방향이나 다른 디코드 인스턴스로 이동합니다. 다음 마감 시간 전에 옮길 수 있는 상태의 양이 GPU 한 장이 안전하게 공유할 모델 수를 정합니다.
따라서 엔진 구성 요소 재사용, 명시적 장치 메모리 관리, 동시 KV 이동은 부수적인 구현 최적화가 아닙니다. 어느 하나라도 엔진 갱신 뒤 느려지면 스케줄링 알고리즘이 같아도 가능한 회전 수가 줄어듭니다. 운영 화면에는 모델 크기별 전환 시간, 가중치와 KV 이동량, 호스트 메모리 압력, 전환 전후의 토큰 여유 시간을 표시해야 합니다.
마켓플레이스에서 이용률보다 우선할 공정성 정책
긴 꼬리 모델은 수요가 드물어 풀링 가치가 크지만 인기 모델에 밀리기 쉽습니다. 토큰 마감 시간을 지키는 순환 스케줄만으로는 모델 소유자 사이의 용량 예약과 거절 정책이 정해지지 않습니다. 최소 서비스 몫을 두고 남는 용량을 공동 풀로 보내거나, 가중치를 준비된 상태로 유지하는 비용을 별도로 가격화할 수 있습니다.
공정성은 동일한 GPU 시간이 아니라 약속한 TTFT와 토큰 간격을 지킨 요청 비율로 정의하는 편이 맞습니다. 드물게 호출되는 모델도 문맥이 길면 요청 수에 비해 큰 호스트 메모리를 쓸 수 있으므로 가중치와 KV 상태를 함께 계산해야 합니다. Aegaeon의 오래 남는 결론은 GPU당 모델 수가 고정값이라는 것이 아닙니다. 측정한 상태 이동 경로에서 토큰 단위 약속을 지킬 수 있는 서로 다른 모델 서비스의 수가 실제 풀링 용량이라는 점입니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 요약으로, 아래에 인용한 논문의 논지를 우리 표현으로 재서술한 것입니다. 원문의 문장, 도판, 표는 이 글에 재사용하지 않았으며, 이 페이지의 도판은 모두 이 요약을 위해 새로 제작했습니다. 논문은 SOSP 2025에서 발표되었고, 확정본은 Proceedings of the 31st ACM Symposium on Operating Systems Principles에 실려 있습니다. (c) 2025 the authors, publication rights licensed to ACM.