NVIDIA가 Kubernetes용 오픈소스 도구 Snapshot을 공개했다. 초기화가 끝난 GPU 실행 환경에서 처리하는 작업인 워크로드의 상태를 저장해 새 인스턴스에서 되살리므로, 추론 서비스를 운영하는 팀은 모델을 다시 준비하는 시간을 줄이고 장애 복구와 수요 대응을 앞당길 수 있다.

1. 준비가 끝난 실행 상태를 재사용한다

Snapshot은 NVIDIA DSX AI Factory Platform의 일부로, 준비가 끝난 시점의 실행 상태를 저장했다가 복원하는 시스템이다. CPU와 GPU 메모리를 이동 가능한 파일 묶음인 아티팩트로 저장해 새 작업에서 되살린다. 모델 가중치를 다시 읽고 실행을 최적화하는 준비 단계를 반복하지 않는 방식이다.

처음에는 NVIDIA Dynamo 추론 워커용으로 개발됐지만, 다른 추론 엔진과 실행 작업의 배치를 정하는 스케줄러, 요청한 상태에 맞게 조정하는 컨트롤러, 플랫폼도 통합할 수 있다.

한 노드의 여러 GPU를 함께 쓰는 호환 워크로드도 하나의 아티팩트로 저장한다. 계산을 여러 GPU로 나눠 처리하는 병렬화를 이용하는 대형 모델에도 적용할 수 있다.

2. 요청 객체를 만들어 저장하고 복원한다

실행 상태 저장인 체크포인트와 복원은 Kubernetes에 별도 요청 객체를 만드는 방식으로 처리한다. 실행 중인 작업을 저장하려면 PodSnapshot을 만들고, 템플릿에서 시작해 준비되는 즉시 저장하려면 SnapshotJob을 쓴다.

복원할 때는 새 Pod에 nvidia.com/restore-from 주석을 붙여 기준 체크포인트를 지정한다.

워크로드는 체크포인트 직전에 잠시 멈추고 복원 뒤 다시 실행되도록 연동해야 한다. NVIDIA 저장소에는 vLLM, SGLang, TensorRT LLM 연동 예제가 있어 플랫폼 팀이 기존 추론 환경에 맞춰 통합할 수 있다.

3. B200 시험에서 복원은 3.6~42.7초다

회사 발표 기준 시험은 NVIDIA B200 GPU, 615.71.09 드라이버, VAST(NFS) 저장소에서 진행됐다. 아래는 같은 모델을 GPU 하나에서 실행한 결과로, 각 엔진을 처음부터 실행하는 콜드 스타트와 저장 상태 복원을 비교한다.

콜드 스타트, 실행 환경을 처음부터 초기화하는 방식은 프로세스 실행부터 엔진 초기화 완료까지, 복원은 요청부터 서비스 재개까지를 쟀다.

표: Qwen3-0.6B의 콜드 스타트와 Snapshot 복원

조건: NVIDIA B200, 드라이버 615.71.09, VAST (NFS), Qwen3-0.6B, TP1(1 GPU)

단위: 시간은 초, 배속은 배

Qwen3-0.6B의 엔진별 시작 시간 비교vLLM 0.31.0: 콜드 스타트(초) 104.43, 복원(초) 4.66; SGLang 0.5.21: 콜드 스타트(초) 87.08, 복원(초) 3.59; TensorRT LLM 1.3.0: 콜드 스타트(초) 121.26, 복원(초) 8.15콜드 스타트(초)복원(초)vLLM 0.31.0104.434.66SGLang 0.5.2187.083.59TensorRT LLM 1.3.0121.268.15
Qwen3-0.6B의 엔진별 시작 시간 비교
B200 시험에서 복원은 3.6~42.7초다
추론 엔진콜드 스타트(초)복원(초)속도 향상(배)
vLLM 0.31.0104.434.6622.40
SGLang 0.5.2187.083.5924.26
TensorRT LLM 1.3.0121.268.1514.88

B200과 VAST 저장소를 쓴 위 결과에서는 세 엔진 모두 복원이 콜드 스타트보다 짧았다. 회사 발표 기준 전체 시험 구성의 복원 시간은 3.6~42.7초로, 콜드 스타트보다 8~36배 빨랐다. 8개 GPU를 쓴 대형 모델은 약 600GB~1TB 체크포인트를 43초 안에 복원했으며, 해당 구성의 콜드 스타트는 6~19분이었다.

설계 파트너인 Crusoe는 NVIDIA HGX B300에서 GLM-5.3 Pod 준비 시간을 약 8분에서 31초로 줄였다고 밝혔다. Saturn Cloud도 NVIDIA HGX B300에서 vLLM 시작 시간을 2~8.5분에서 6~34초로 단축했다고 발표했다.

4. 큰 모델은 GPU 상태 이동이 복원 시간을 좌우한다

콜드 스타트는 엔진 시작, 가중치 로드, 메모리 준비, 커널 컴파일·자동 튜닝·그래프 캡처로 이어진다. 회사 발표 기준 DeepSeek-V4.1-Flash의 vLLM 구성에서는 마지막 컴파일·튜닝·캡처 단계가 784.54초였고 전체 시작은 1,110.65초였다. Snapshot은 이미 끝낸 초기화 과정을 저장해 이 반복 비용을 건너뛴다.

복원은 아티팩트를 찾아 CPU 프로세스 상태와 GPU 메모리를 되돌린 뒤 실행을 재개하는 순서다. CPU 상태는 리눅스 프로세스 저장·복원 도구인 CRIU로 읽는다.

회사 발표 기준 8개 GPU를 쓴 대형 모델의 복원 중 GPU 상태 이동은 18~29초, CPU 상태 복원은 4.2~10.8초였다. 큰 모델의 복원 시간을 줄이려면 GPU에 데이터를 되돌리는 구간을 살펴야 한다.

5. 기동 시간을 줄이는 대신 저장 작업과 공간이 든다

회사 발표 기준 체크포인트 생성에는 구성에 따라 15초~5.5분이 걸리고, 아티팩트는 8.04GB~1,039.09GB다. 생성 시간은 모델과 구성별로 한 번 치르는 비용이며, 시험한 모든 구성에서 저장과 첫 복원을 합친 시간이 콜드 스타트 한 번보다 짧았다. 초기화 반복을 줄이는 대신 저장 작업과 대용량 아티팩트를 운영에 반영해야 한다.

측정 시간에는 컨테이너 이미지 내려받기와 컨테이너 런타임 준비가 포함되지 않는다. 복원에는 같은 GPU 모델·드라이버와 실행 호환성이 필요하며, 저장 전에 비우는 대화 문맥을 임시 저장하는 KV 캐시는 아티팩트에 포함되지 않는다.

Snapshot은 GPU 워크로드의 초기화 상태를 재활용해 기동 시간을 줄이며, 그 효과를 얻으려면 체크포인트 시간과 저장 공간을 운영 설계에 포함해야 한다.