Modal 이 cold start 를 40배 줄인 방법 — serverless GPU 의 새 경제학
Modal 이 cold start 를 40배 줄인 방법 — serverless GPU 의 새 경제학
Modal 은 어떻게 GPU 추론 컨테이너의 시작 시간을 33분에서 50초로 줄였는가. 그리고 이 변화는 “serverless GPU” 라는 표현이 마침내 진짜 의미를 가지게 되는 시점을 가리키는가.
도입 — 33분과 50초 사이의 거리
5월 14일에 Modal 이 공개한 기술 블로그 한 편이 시스템 엔지니어 커뮤니티에서 빠르게 회자됐다. 제목은 짧다. “Cutting inference cold starts by 40x with LP, FUSE, C/R, and CUDA-checkpoint.” HN 점수는 65점에 그쳤지만, 본문에 깔린 숫자가 너무 또렷해서 한번 본 사람은 잊기 어려웠다. 베이스라인 cold start 가 약 2,000초, 그러니까 33분이었다. Modal 의 새 스택을 거치면 같은 워크로드가 약 50초에 시작한다. 정확히 40배다.
이 숫자는 단순한 마이크로 벤치마크가 아니다. Modal 은 2026년 2월부터 4월까지 자체 트래픽 안에서 CPU 스냅샷 3,500만 회, CPU+GPU 스냅샷 1,500만 회를 복원했고, 그 사이에 만들어진 고유 스냅샷이 170만 개에 달한다고 적었다. 즉 이 스택은 이미 프로덕션에서 분기 단위로 검증된 인프라다. 같은 글에서 Reducto 라는 고객 사례를 짧게 인용한다. 문서 처리 워크로드에서 cold start 가 약 70초에서 약 12초로 떨어졌다는 것이다. 6배. 이 단축이 있었기에 Reducto 는 1,000개 이상의 GPU 규모에서 idle 용량을 따로 두지 않고도 안정적인 처리량을 유지할 수 있었다.
이 글이 진짜로 중요한 이유는 두 가지다. 하나는 cold start 가 지금까지 “serverless GPU” 라는 표현이 마케팅 용어에 머물게 만든 결정적 병목이었다는 점이다. 다른 하나는 Modal 이 그 병목을 단일 기술이 아니라 네 층으로 쌓인 인프라 — LP, FUSE, C/R, CUDA-checkpoint — 로 해체했다는 점이다. Modal 블로그가 본문 끝에 적은 한 줄, “인프라는 누적된다(infrastructure compounds)” 는 이 글의 진짜 논지를 압축한다.
이 글은 그 네 층을 차례로 따져 보면서, GPU 추론 인프라의 경제학이 5월의 이 발표를 기점으로 어떻게 바뀌는지를 정리한다. 마지막에는 이 변화가 LLM 가격 곡선과 신생 추론 회사의 진입 장벽에 어떤 영향을 미치는지를 따져 본다.
본문 1 — 네 층으로 쌓인 cold start 해체
Modal 의 스택을 가장 아래부터 본다.
가장 아래층은 GPU 할당의 선형계획(LP)이다. Modal 은 Google 의 GLOP 솔버를 써서 매 분 단위로 클라우드 제공자별 GPU 가격과 사용자 요청을 입력받아, “사용자 요청 + 버퍼” 만큼의 GPU 를 최소 비용으로 확보하는 최적화 문제를 푼다. 이 결정은 cold start 자체를 줄이지 않지만, idle 용량 버퍼를 얼마나 둘지를 가격 함수로 풀어 둠으로써 cold start 가 일어났을 때 시스템 전체가 무너지는 일을 막는다. Modal 은 같은 글에서 직설적으로 적는다. “100% 가동된 시스템은 오류에 대한 여유가 없다. 그래서 고장이 일상적으로 장애가 된다(A 100% utilized system has no margin for error, and so faults routinely become failures).” 이 한 줄은 GPU 인프라 운영의 핵심을 짚는다. 가동률을 100% 까지 올리려는 시도가 결국 신뢰성을 깎아먹기 때문에, 일정한 idle 버퍼를 둔다는 것 자체가 비용이 아니라 신뢰성 투자다.
두 번째 층은 FUSE 기반의 컨테이너 이미지 lazy loading 이다. 일반적으로 컨테이너 시작은 이미지 전체를 디스크에 푼 다음 프로세스를 띄운다. AI 추론 컨테이너는 30~50 GB 의 이미지가 흔하다. 50 GB 를 1 GB/s 의 대역폭으로 받아도 50초가 걸린다. Modal 은 libfuse 위에 자체 파일 시스템을 깔아, 컨테이너가 시작될 때 메타데이터(인덱스) 몇 메가바이트만 100ms 안에 읽고, 그 다음에 프로세스가 실제로 접근하는 파일만 비동기로 가져오는 구조를 만들었다. 콘텐츠 주소화 + 계층화 캐시 위에서 작동한다. 트레이드오프도 있다. 사용자 공간과 커널 사이를 두 번 오가야 하므로 character-device 연산은 약간 느려지지만, 추론 워크로드는 거의 throughput 중심이라 큰 영향이 없다. Modal 은 한 가지 의식적 결정도 적어 둔다. gzip 압축 풀기를 건너뛴다는 것이다. DEFLATE 가 단일 스레드 한계로 약 100 MB/s 에 묶이기 때문에, 빠른 캐시 층이 거꾸로 묶여 버린다.
세 번째 층은 호스트 측 checkpoint/restore(C/R)다. gVisor 의 runsc 런타임을 이용해, Python 프로세스가 라이브러리 import 를 끝낸 시점의 상태를 그대로 디스크에 스냅샷으로 떨군다. PyTorch, transformers, vLLM 같은 무거운 라이브러리의 import 시간은 작은 모델에서도 수십 초가 걸리는데, 이 단계를 매번 다시 실행하지 않고 직렬화된 힙·스레드 상태를 복원하는 것으로 우회한다. 호스트 측 C/R 의 효과는 작은 모델에서 특히 크다. vLLM 으로 Qwen 3 0.6B(1 GiB) 를 띄울 때 스냅샷 없이는 평균 95.7초, 스냅샷이 있을 때는 13.8초였다. SGLang 으로 같은 모델을 띄울 때는 83.7초가 17.5초로 떨어졌다. 두 경우 모두 7배 안팎이다.
네 번째 층, 그리고 가장 결정적인 층은 CUDA-checkpoint 다. Nvidia 의 드라이버 확장으로, GPU 디바이스 메모리를 호스트 메모리로 직렬화해 두고 나중에 그대로 복원할 수 있게 해 준다. 이 단계가 있어야 비로소 CUDA 그래프와 컴파일된 커널을 처음부터 다시 빌드하지 않고 그대로 들고 올 수 있다. Modal 은 이 단계에서 4~10배 추가 단축을 얻는다고 적었다. “컨테이너 시작 시간이 수 분에서 수십 초 단위로 떨어진다(reducing container start time from several minutes to tens of seconds).” 큰 모델일수록 이 단축이 크다. 7B 모델의 무거운 CUDA 컨텍스트가 디스크에서 그대로 복원되면, GPU 메모리 할당과 커널 컴파일에 들어가던 수 분이 통째로 사라진다.
여기서 핵심은 네 층이 독립이 아니라는 점이다. Modal 의 글이 본문 끝에 적은 한 줄, “디바이스 체크포인트/복원은 호스트 체크포인트/복원 위에 쌓이고, 그 위에 다시 파일 시스템이 깔린다. 인프라는 누적된다(The device checkpoint/restore builds on the host checkpoint/restore, which builds on the underlying filesystem. Infrastructure compounds).” 라는 표현은 단순한 수사가 아니다. CUDA-checkpoint 만 단독으로 쓰려고 해도, 호스트 측 Python 프로세스가 이미 import 를 마친 상태가 아니면 GPU 메모리만 복원해 봐야 다시 import 가 일어난다. 호스트 C/R 만 써도, 컨테이너 이미지를 50 GB 풀어야 하면 그 자체로 분 단위 시간이 깎인다. 네 층이 한 묶음으로 돌아가야 40배가 나온다.
본문 2 — 트레이드오프 가운데 무엇을 골랐는가
Modal 의 글이 인상적인 또 다른 이유는 트레이드오프를 숨기지 않는다는 점이다. 본문에는 한계가 두 가지 명시되어 있다.
첫 번째 한계는 CPU 스냅샷의 명령 집합 의존성이다. Modal 은 호스트 C/R 스냅샷이 호스트 CPU 의 명령 집합에 민감하다고 적는다. 구체적으로 AWS 의 g6.12xlarge 인스턴스에는 pclmulqdq 명령이 없어서, 다른 인스턴스에서 만든 스냅샷을 그대로 복원할 수 없다. 이 한계는 클라우드 운영자 입장에서 작지 않다. 같은 워크로드를 어느 인스턴스에서 시작했든 어디서든 cold start 가 동일하게 빠를 거라는 보장이 없다는 뜻이다. Modal 은 이를 해결하기 위해 호스트 그룹별로 별도 스냅샷을 관리한다고 적었다. 즉 같은 모델이라도 호스트 타입별로 따로 스냅샷을 만들어 두어야 한다. 운영 복잡도가 늘어나는 대가다.
두 번째 한계는 멀티 GPU 워크로드의 비호환성이다. 현재 GPU 스냅샷은 단일 GPU 워크로드에만 적용된다. Modal 은 그 이유를 한 줄로 적는다. “NCCL 프로그램은 일시 정지를 전제로 설계돼 있지 않고, 자주 데드락에 빠진다(nccl programs are not designed for pauses and frequently deadlock).” NCCL 은 멀티 GPU 통신 라이브러리로, GPU 사이의 collective 연산을 동기화한다. 이 동기화 상태를 한 GPU 만 정지시킨 다음 복원하려고 하면, 다른 GPU 들이 응답을 기다리다 멈춘다. 큰 모델일수록 멀티 GPU 가 필수인데, 그 영역에서 이 스택은 아직 효과가 없다. Modal 은 이를 솔직히 인정하고, 그 영역에서는 RDMA 기반 weight server 같은 다른 접근이 필요하다고 적었다.
세 번째 흥미로운 결정은 RDMA weight server 같은 더 공격적인 최적화를 일부러 추구하지 않았다는 점이다. Modal 은 그 가능성을 알면서도 “그게 가능하긴 하지만 비용이 많이 들고 까다롭다. 특히 여러 모델과 동적 워커 풀로 확장하려고 하면 더 그렇다(This is doable, but expensive and gnarly, especially when scaling to many models and dynamic worker pools)” 라고 적었다. 즉 Modal 은 의도적으로 “엔지니어링 합리성” 의 자리에서 멈추기로 했다. 이 결정 자체가 흥미롭다. cold start 를 1초 미만으로 더 줄이는 길은 있지만, 그 길은 운영 복잡도가 폭증해 작은 팀이 유지하기 어려워진다. 50초에서 40배 단축을 얻은 다음에는 더 공격적인 단축보다, 그 50초를 다양한 워크로드에서 안정적으로 재현하는 쪽이 더 가치 있다는 판단이다.
이 판단 자체가 GPU 인프라 회사들이 5월 시점에 다다른 합의를 드러낸다. 모델 자체의 성능은 비교적 평탄해진 반면, 모델을 서빙하는 인프라의 안정성과 비용 가시화는 여전히 차이가 크게 벌어진다. 그 차이는 cold start, throughput 안정성, 가격 예측 가능성, 멀티 모델 호스팅 효율 같은 운영 디테일에서 결정된다. Modal 의 발표가 단순한 자랑이 아니라 산업 표준이 어디로 굳고 있는지를 보여 주는 글로 읽히는 이유다.
본문 3 — serverless GPU 의 경제학이 바뀌는 지점
“serverless GPU” 라는 표현은 2023년부터 자주 쓰였지만, 실제로는 마케팅 용어에 가까웠다. GPU 가용성이 분 단위로 출렁이는 상황에서, 사용자는 어쩔 수 없이 idle 용량을 어느 정도 미리 잡아 두어야 했다. 이 idle 시간은 곧 가격이었다. 1초 단위로 결제한다고 해도, 사용자가 실제로 사용하지 않은 분 단위의 시간이 가격에 포함됐다. 그게 진짜 serverless 가 아닌 이유다. AWS Lambda 가 millisecond 단위로 결제할 수 있는 것은 cold start 가 짧기 때문이고, cold start 가 길면 어떤 결제 단위로도 진짜 serverless 가 되지 않는다.
Modal 의 5월 발표가 의미하는 바는 이 경제학이 바뀐다는 점이다. cold start 가 50초로 떨어지면, 가격 모델이 “idle 시간을 사용자에게 떠넘기는 분 단위 결제” 에서 “초 단위 또는 분 단위 사용 결제 + 인프라가 떠안는 idle 버퍼” 로 옮길 수 있게 된다. 이게 진짜 serverless 의 정의다. 인프라 공급자가 idle 비용을 어떻게 처리하든, 사용자는 자기가 쓴 만큼만 낸다. Reducto 사례가 그 변화의 첫 가시 신호다. 1,000개 이상의 GPU 위에서 idle 용량을 따로 두지 않고도 안정적인 처리량을 유지할 수 있게 된 데에는, cold start 가 70초에서 12초로 떨어졌다는 사실이 결정적이었다.
이 변화는 LLM 가격 곡선에도 영향을 준다. 지금까지 추론 가격은 토큰당 가격으로 표시돼 왔지만, 그 가격에 깔린 비용 구조는 단순히 GPU 시간만이 아니라 idle 시간을 포함한다. cold start 가 길수록 그 idle 비용이 가격에 더 많이 들어간다. cold start 가 짧아지면, 동일한 GPU 가동률을 유지하면서도 더 많은 모델을 더 작은 단위로 서빙할 수 있다. 즉 작은 모델, 특수 목적 모델, 사용자별 fine-tune 모델 같은 long-tail 워크로드의 단위 비용이 떨어진다. 5월 들어 작은 fine-tune 모델 한 개를 별도 서비스로 띄우는 게 경제적으로 의미를 가지기 시작한 배경에는 이런 인프라 변화가 있다.
이 변화는 신생 추론 회사의 진입 장벽에도 영향을 준다. 작년까지만 해도 LLM 추론을 전문으로 하는 회사를 만들려면, 큰 GPU 클러스터를 미리 확보해 idle 용량을 부담할 수 있어야 했다. 이게 진입 장벽이었다. 5월의 Modal 같은 회사가 cold start 와 비용 구조를 풀어 두면, 작은 팀도 자체 GPU 클러스터 없이 좋은 cold start 와 좋은 가격을 동시에 제공할 수 있다. 이 흐름이 굳어지면 LLM 추론 시장의 신생 회사 수가 늘어날 가능성이 있다. 단 모델 자체의 차별화는 점점 어려워지고 있으니, 새 진입자들의 차별화 지점은 모델이 아니라 운영 ergonomics — 가격 예측, 모니터링, MCP 도구 통합 — 쪽으로 옮겨갈 것이다. 5월 18일 Anthropic 이 Stainless 를 인수한 것도 같은 방향을 가리킨다. 운영 디테일이 새 경쟁축이 됐다.
결론 — “인프라는 누적된다” 가 가리키는 것
처음의 두 질문으로 돌아가자. Modal 은 어떻게 cold start 를 33분에서 50초로 줄였는가. 그리고 이 변화는 serverless GPU 가 마침내 의미를 가지는 시점인가.
첫 번째 질문에 대한 답은 단일 기술의 마법이 아니다. LP, FUSE, C/R, CUDA-checkpoint 네 층이 한 묶음으로 작동하는 결과다. 어느 한 층만 빼도 다른 층의 효과가 절반 이하로 떨어진다. Modal 의 “infrastructure compounds” 라는 표현이 가리키는 것은 이 곱셈 구조다. 그리고 그 곱셈을 가능하게 한 결정은 단순한 기술 선택이 아니라 엔지니어링 합리성의 자리에서 멈췄다는 점이다. RDMA weight server 같은 더 공격적인 최적화를 추구하면 cold start 를 더 줄일 수 있겠지만, 운영 복잡도가 폭증해 작은 팀의 손에서 굳기 어려워진다. 40배를 안정적으로 얻고 거기서 멈춘 결정이, 분기 단위로 검증된 인프라를 만들었다.
두 번째 질문에 대한 답은 “그렇다, 그러나 부분적으로” 다. 단일 GPU 워크로드에서 cold start 가 50초 안쪽으로 떨어졌다는 사실은 진짜 serverless GPU 의 시작을 가리킨다. 그러나 멀티 GPU 가 필요한 큰 모델에서는 여전히 이 스택이 작동하지 않고, 호스트 타입에 따라 스냅샷 호환성이 갈리는 문제도 남아 있다. 가장 큰 모델을 가장 빠르게 띄우는 영역은 아직 옛 방식의 idle 용량 확보가 필요하다. 그러나 long-tail 영역에서는 5월의 발표가 게임의 룰을 바꾼다.
이 글이 남기는 메시지는 한 줄로 요약된다. AI 추론 인프라의 다음 분기는 단일 마법 기술이 아니라, 네 층의 인프라가 어떻게 누적되는가로 결정된다. Modal 의 발표는 그 누적 구조의 첫 가시 신호다. 다음 분기에 OpenAI, Anthropic, Google 의 자체 추론 인프라가 같은 패턴을 따르는지, 아니면 다른 길을 찾는지를 보면 GPU 추론 시장의 새 균형이 보일 것이다. 그 사이에 작은 추론 회사들은, “infrastructure compounds” 라는 한 줄을 자기 로드맵의 첫 페이지에 적어 두는 게 좋다. 한 층만 깔아서는 부족하다.
출처: