서버리스는 응용이 실행될 때만 비용을 내는 모델입니다. 그러나 기존 GPU 추론은 첫 요청이 오기 전부터 이 원칙을 깨기 쉽습니다. 모델을 전용 가속기에 미리 올려 두고, 요청이 없는 동안에도 GPU를 예약하며, 다시 적재하는 데 오래 걸린다는 이유로 장시간 인스턴스 비용을 받습니다. API는 서버리스처럼 보여도 장비 비용은 상시 점유 방식입니다.
Torpor는 함수를 배포할 때가 아니라 요청이 도착할 때 실행 GPU를 정합니다[1]. CUHK-Shenzhen, HKUST, Alibaba Group, Nokia Bell Labs 연구진이 시스템을 만들고 Alibaba Cloud에서 파일럿을 운영했습니다. 모델 상태를 없앤 것은 아닙니다. 쉬는 모델은 호스트 DRAM으로 옮기고, 한 워커의 GPU 네 장을 여러 함수가 공유하며, 실제 작업이 생길 때만 가속기로 복사합니다.
이 구분이 논문의 핵심입니다. GPU 메모리를 장기 임대 공간이 아니라 실행 캐시로 사용합니다. 다만 70%의 평균 사용자 비용 절감은 모델 이동, 꼬리 지연, 호스트 메모리 비용, 순간 수요를 함께 제어한 특정 운영 결과입니다. 모든 서버리스 추론에 적용되는 고정 할인율로 읽어서는 안 됩니다.
미리 정한 GPU가 드문 요청을 상시 임대로 바꾸는 방식
Torpor가 분석한 일주일 운영 기록에서는 함수 호출이 드뭅니다. 관측한 추론 함수의 85%는 분당 한 번 이하, 97%는 초당 한 번 이하로 호출됐습니다. 비밀 유지를 위해 CPU 함수와 GPU 함수를 합친 분포를 제시했으며 두 집단의 양상이 비슷하다고 설명합니다. GPU 함수만의 히스토그램은 없으므로 이 비율은 수요 형태를 보여 주는 근거이지 GPU 용량을 직접 산정하는 값은 아닙니다.
함수를 배포할 때 GPU를 정하면 요청이 없는 시간에도 한 장치의 메모리와 연산 자원을 비워 두게 됩니다. 장치를 회수하면 다음 요청이 컨테이너, 런타임, 모델을 다시 준비할 때까지 기다립니다. 논문의 운영 경로에서 일반 콜드 스타트는 ResNet-152가 8초, Llama-2-13B가 61초입니다. 수십 또는 수백 밀리초로 정한 서비스 목표에는 들어갈 수 없는 시간입니다.
유지 시간을 늘리는 방법은 지연을 줄여도 서버리스 문제를 해결하지 못합니다. 앞으로 올지 모르는 요청을 위해 GPU 시간을 먼저 구매하기 때문입니다. 유지 시간을 줄이면 회수율은 높아지지만 콜드 스타트가 많아집니다. Torpor는 할당 단위를 바꿉니다. 특정 GPU를 계속 차지하지 않아도 모델 이미지는 사용할 수 있는 상태로 남깁니다.
호스트 DRAM은 대기 계층이고 GPU 네 장은 실행 계층
각 워커에는 호스트 메모리 풀과 GPU 네 장이 있습니다. 실행하지 않는 모델 이미지는 호스트 DRAM에 둡니다. 요청이 오면 배포 때 지정한 장치로 보내지 않고, 워커 안에서 조건에 맞는 GPU를 선택합니다. 기존 복사본이 남아 있으면 다시 사용하고, 없으면 모델을 적재합니다. GPU 메모리가 부족하면 다른 이미지를 내보냅니다.
호스트에서 GPU로 복사하는 시간은 무시할 수 없습니다. Torpor는 비동기 CUDA 호출을 전달하고, 페이지 고정 호스트 메모리를 사용하며, 모델 전송과 실행을 겹칩니다. 다른 GPU에 복사본이 있으면 항상 PCIe를 거쳐 호스트로 돌아가지 않고 NVLink 경로를 사용할 수 있습니다. 동시에 여러 모델을 옮길 때 링크가 겹치면 추론 지연이 늘어나므로 스케줄러가 경로 간섭도 고려합니다.
런타임 구성은 시험 환경과 파일럿에서 다릅니다. 시험 환경은 Torpor의 모델 관리 효과를 분리해 보기 위해 GPU 런타임을 공유합니다. 운영 파일럿은 사용자마다 런타임을 분리하므로 시작 시간에 모델 적재와 런타임 재개가 모두 들어갑니다. 실험실의 복사 스케줄 결과만으로 멀티테넌트 보안이나 운영 시작 시간을 입증할 수는 없습니다.
호스트 DRAM은 공짜 자원이 아닙니다. GPU보다 싼 상태 보관 계층으로 사용해 실행 계층을 여러 함수가 나누어 쓰는 구조입니다. 파일럿에서는 함수가 쉬면서 호스트 메모리에 남아 있는 동안 GPU 요금의 10%를 받습니다. 호출이 극히 드문 함수도 메모리 비용을 계속 쌓을 수 있습니다. 따라서 비교에는 활성 GPU 시간뿐 아니라 DRAM 예약량과 보관 시간을 포함해야 합니다.
스케줄러의 목표는 이용률이 아닌 SLO를 지킨 함수 수
요청마다 GPU를 정하면 대기열과 모델 캐시가 하나의 문제가 됩니다. 한 워커에 요청 빈도, 마감 시간, 모델 크기, 적재 비용이 다른 함수가 함께 있습니다. 빈 GPU부터 쓰면 큰 전송이 작은 요청을 막을 수 있고, 당장 점유율을 높이는 배치는 여러 함수의 꼬리 지연을 악화시킬 수 있습니다.
Torpor는 필요한 요청 수(required request count, RRC)라는 지표로 각 함수가 SLO 범위에 남기 위해 얼마나 더 성공적으로 처리돼야 하는지 추정합니다. 목표를 위반하기 직전인 함수를 여유가 큰 함수보다 먼저 처리합니다. 고정 우선순위가 아니라 워커의 부하에 따라 경계를 조정합니다. 모든 GPU를 계속 바쁘게 만드는 대신 지연 목표를 지킨 함수 수를 늘리는 방향입니다.
배치와 퇴거도 간섭을 함께 봅니다. 같은 PCIe 경로에서 전송이 겹치지 않게 하고, 다른 GPU의 복사본을 이용할 수 있으면 NVLink 관계를 반영합니다. 적재 부담이 큰 모델과 빨리 다시 가져올 수 있는 가벼운 모델도 구분합니다. 하나의 우선순위 식이 모든 서비스에 맞는다는 증명은 아닙니다. 모델 캐시와 요청 대기열을 따로 최적화해서는 안 된다는 구체적인 설계 사례입니다.
플랫폼 지표도 달라져야 합니다. 평균 GPU 이용률이 올라가도 큰 모델 몇 개가 마감 시간을 계속 놓칠 수 있습니다. 반대로 전송 경로를 잠시 비워 두는 편이 이후에 SLO를 지킨 요청을 더 많이 처리할 수 있습니다. 분자는 지연 목표 안에서 완료한 요청이고, 분모에는 GPU와 호스트 메모리, 다음 호출을 위해 보관한 상태가 모두 들어가야 합니다.
시작 시간은 모델 준비와 런타임 격리를 나누어 봐야 할 이유
논문은 파일럿 운영 경로에서 모델 준비와 런타임 재개 시간을 따로 제시합니다. Llama-3-8B는 모델 준비 1.6초와 런타임 격리 1.4초를 합쳐 3.0초이며, 일반 콜드 스타트는 48초입니다. Qwen-14B는 57초에서 3.6초, Llama-2-13B는 61초에서 4.4초로 줄었습니다. 작은 모델도 ResNet-152가 0.29초, BERT 질의응답이 0.33초입니다.
감소 폭은 크지만, 이 값은 항상 준비된 모델의 요청 지연이 아닙니다. 한 요청이 3초의 시작 시간을 모두 부담하면 80ms나 200ms의 목표를 넘습니다. Torpor는 대기열 정책, 남아 있는 복사본, 전송과 실행의 중첩, 이후 요청으로의 비용 분산을 함께 사용합니다. 구매자는 콜드 스타트 막대의 양끝만 볼 것이 아니라 각 시작 경로를 실제 요청의 몇 퍼센트가 밟는지 확인해야 합니다.
통제된 클러스터는 최대 워커 여섯 대입니다. 워커마다 가상 CPU 48개, 호스트 메모리 384GB, 32GB NVIDIA V100 네 장을 사용합니다. 영상, 질의응답, 확산 모델, 언어 모델을 포함한 모델 여덟 개를 평가했습니다. 기본 목표는 컴퓨터 비전의 P98 지연 80ms 이하, BERT 질의응답은 200ms 이하입니다.
워커 한 대에 함수 160개를 배치한 실험에서 Torpor는 모두 실행했고 모두 SLO를 지켰다고 보고합니다. 네이티브 방식은 72개까지 실행했습니다. 유지 시간을 적용한 INFless는 112개를 실행했지만 목표를 지킨 함수는 7개였습니다. 함수 1,000개의 클러스터 실험에서는 Torpor가 거의 모든 마감을 지킨 반면, 단순 교체 방식의 꼬리는 마감의 4배를 넘고 교체하지 않는 방식은 7배를 넘었습니다. 선택한 모델과 기록에서는 통합 정책의 가치를 보여 주지만, 최신 가속기나 다른 링크, 초대형 텐서 병렬 모델에서도 같은 비율이 나온다는 뜻은 아닙니다.
파일럿의 비용은 분모가 정해진 운영 근거
Alibaba Cloud 파일럿은 사용자 150명 이상, GPU 350장 이상을 서비스했고 하루 최대 46만5천 요청을 처리했습니다. 이전의 장시간 GPU 유지 방식과 비교해 사용자 비용을 평균 70% 줄였다고 보고합니다. 여러 함수를 통합하면서 플랫폼이 필요한 GPU 수와 관련 비용은 65% 줄었습니다. 별도의 운영 사례에서는 비용이 84% 감소했고, 모델과 런타임 적재가 종단 간 시간의 약 30%를 차지했습니다.
세 값은 서로 다른 질문에 답합니다. 70%는 파일럿 요금 정책에서 고객이 낸 비용입니다. 65%는 플랫폼의 장비 수와 비용입니다. 84%는 고유한 요청 패턴을 가진 함수 한 개의 사례입니다. 이를 하나의 효율 수치로 합치면 누가 어떤 조건에서 비용을 줄였는지 사라집니다.
상업적 작동 원리도 분명합니다. 쉬는 모델은 호스트 메모리를 차지하므로 요금이 0이 아니며 GPU 가격의 10%를 냅니다. 활성 실행에는 GPU 요금을 적용합니다. 절감 폭은 대기 시간, 실행 시간, 모델 크기, 순간 요청의 비율에 따라 달라집니다. 자주 호출되는 모델은 GPU가 계속 일하므로 이득이 작을 수 있습니다. 시간당 몇 번만 부르는 함수는 DRAM 보관료만으로도 더 싼 저장장치로 옮기는 편이 나을 수 있습니다.
시뮬레이션을 넘어 실제로 늦은 바인딩을 운영했다는 근거는 중요합니다. 그러나 무작위 클라우드 가격 비교는 아닙니다. 같은 공급자가 플랫폼, 요금 정책, 비교 기준을 설계했으며 논문은 워크로드별 비용 분포를 공개하지 않습니다. 도입을 검토하는 운영자는 전체 평균 대신 모델 크기와 호출 빈도별 비용 백분위를 요구해야 합니다.
구매자와 플랫폼이 측정해야 할 항목
먼저 상태 원장을 만들어야 합니다. 함수마다 모델 바이트, 런타임 상태, 호스트 메모리 보관량, GPU 상주 시간, 적재 출발점, 전송 경로, 퇴거 횟수를 기록합니다. 그래야 10%의 대기 요금을 검증하고 DRAM이 다음 병목인지 알 수 있습니다. 호스트 메모리 점유율은 중앙값, P95, 최고값과 함께 수용하지 못한 함수 수도 보고해야 합니다.
둘째, 요청 경로를 나눠야 합니다. GPU에 남은 복사본을 쓰는 경우, 호스트에서 적재하는 경우, 다른 GPU에서 옮기는 경우, 런타임까지 다시 시작하는 경우의 지연과 간섭은 다릅니다. 각 경로가 전체 요청에서 차지하는 비율과 P50, P95, P98 완료 시간을 공개해야 합니다. 평균 하나로는 드문 콜드 경로가 SLO 예산을 모두 쓰는 상황을 찾기 어렵습니다.
셋째, 순간 수요를 보존해야 합니다. 평균 호출률만으로는 동시에 필요한 복사본과 워커 수를 정할 수 없습니다. 요청 간격 분포, 집중 구간의 길이, 모델 인기도, 입력과 출력 크기, 배치 정책, 노드 사이에 만든 복제본 수를 함께 봐야 합니다. 정한 순간 수요 백분위에 필요한 여유 용량을 남긴 뒤의 절감액을 제시해야 합니다.
마지막으로 성공한 작업의 비용을 계산해야 합니다. 활성 GPU 시간, 비활성 호스트 메모리, 실패하거나 늦은 요청, 데이터 전송, 순간 수요에 필요한 여유분을 포함합니다. SLO를 지킨 요청당 비용은 GPU 초당 비용보다 판단에 유용합니다. 더 많은 함수를 받아 놓고 꼬리 지연을 놓치는 방식으로 저렴해 보이는 것을 막을 수 있습니다.
Torpor의 적용 범위를 정하는 세 가지 한계
호출이 극히 드문 함수는 호스트 복사본 비용이 남습니다. 더 싼 저장장치에 차가운 이미지를 두고 수요가 늘면 올리는 다계층 구조를 생각할 수 있지만 논문에서는 향후 과제입니다. 이 방식은 더 긴 시작 경로를 다시 만들기 때문에 별도 SLO가 필요합니다.
현재 구현은 하나의 초대형 모델을 여러 GPU에 나누어 실행하지 않습니다. 입증한 범위는 지원 장치에 맞는 함수의 늦은 바인딩입니다. 모델 병렬 추론으로 확장하려면 분할된 가중치 적재, 병렬 런타임 상태, 한 장이 아니라 토폴로지 전체의 배치를 조정해야 합니다.
순간 요청이 큰 함수는 여러 워커에 복제본이 필요할 수 있습니다. 복제는 지연을 보호하지만 호스트 메모리와 전송량을 늘립니다. 논문은 RDMA를 포함한 빠른 노드 간 이동을 향후 방향으로 제시했지만 평가하지 않았습니다. 통제 실험의 GPU도 V100입니다. 최신 가속기는 메모리 용량, 호스트 링크, 동료 장치 패브릭, 분할 기능, 적재 비율이 다르므로 절대 시작 시간을 현재 장비의 예측값으로 사용해서는 안 됩니다.
Torpor가 남긴 판단은 보편적인 속도 향상보다 좁고 유용합니다. 모델 상태와 가속기 점유를 분리해야 GPU 추론의 비용도 서버리스에 가까워집니다. 호스트 메모리는 실행할 수 있는 상태를 보관하고, 로컬 GPU 풀은 요청이 있을 때 연산을 제공합니다. 플랫폼은 이 새로운 상태 계층, 대기열 정책, 전송 패브릭이 더 낮은 전체 비용으로 SLO를 지킨 요청을 늘렸는지 증명해야 합니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 독립적으로 작성한 편집 요약입니다. 원 논문의 주장과 결과를 우리 표현으로 다시 썼으며, 문장·표·도판을 옮기지 않았습니다. 물성 하드웨어 바탕은 이 글을 위해 생성한 뒤 코드로 설명 요소를 올렸고, 수치 도판은 보고된 값으로 다시 그렸습니다. 원문은 USENIX ATC 2025 회의록에 공개돼 있습니다. 저작권 (c) 2025 원저자. Alibaba Group과 Nokia Bell Labs는 저자 소속을 표시한 것이며 해당 기관의 보증을 뜻하지 않습니다. 전체 논문은 USENIX 논문 페이지에서 확인할 수 있습니다.