NVIDIA Dynamo, 섀도 엔진 복구로 LLM 추론 엔진 장애 복구 시간 대폭 단축
NVIDIA Dynamo의 미리 보기 기능인 섀도 엔진 복구(Shadow Engine Recovery)는 LLM 추론 엔진 프로세스 실패 시 복구 시간을 기존 수분에서 수 초로 단축한다. GPU 메모리 서비스(GMS)를 통해 가중치를 공유하고 미리 초기화된 섀도 엔진을 대기시켜 서비스 중단을 최소화한다.
NVIDIA Dynamo는 미리 보기 기능으로 섀도 엔진 복구(Shadow Engine Recovery)를 도입하여 대규모 언어 모델(LLM) 추론 엔진 프로세스 실패 시 복구 시간을 크게 단축한다. 기존 방식인 콜드 리스타트는 가중치 로드, 커널 컴파일, CUDA 그래프 캡처 등으로 인해 수 분이 소요되었으나, 섀도 엔진 복구는 대부분의 복구 작업을 서비스 경로 외부로 이동시켜 수 초 내에 복구를 완료한다. 이 기능은 활성 엔진과 동일한 GPU에 완전히 초기화된 섀도 엔진을 유휴 상태로 유지하며, GPU 메모리 서비스(GMS)를 통해 기존 가중치를 엔진 간에 공유하여 HBM에 추가 복사본을 생성하지 않는다. 활성 프로세스 실패 시 섀도 엔진이 즉시 인계하고, 재초기화는 백그라운드에서 진행된다.
LLM 추론 엔진은 프로덕션 환경에서 프로세스 충돌, 복구 가능한 CUDA 오류, 일시적인 집합적 실패 등 소프트웨어 오류를 흔히 겪는다. 이러한 경우 하드웨어, 드라이버, 노드는 정상 상태를 유지하며, 손상된 상태를 가진 프로세스만 손실되므로 동일한 GPU에서 대체 엔진을 시작할 수 있다. 그러나 기존 엔진 복구는 두 가지 핵심 문제로 인해 느리다. 첫째, 가중치가 엔진 프로세스에 묶여 있어 프로세스 종료 시 GPU 메모리에서 해제되므로 새 엔진은 전체 가중치 로드 절차를 반복해야 한다. 둘째, NCCL 및 `torch.distributed` 통신자, CUDA 그래프와 같은 일부 초기화 상태는 특정 실행 프로세스에 바인딩되어 이전 엔진에서 전달될 수 없으므로 매번 재시작 시 다시 생성해야 한다. 섀도 엔진 복구는 가중치 수명을 엔진 프로세스와 분리하고, 실패 전에 비전송성 초기화를 완료함으로써 이러한 문제를 해결한다.
섀도 엔진 복구는 영구 GPU 메모리, 미리 준비된 대기 엔진, 워커 수준 조정을 결합하여 콜드 리스타트 없이 복구를 수행한다. 핵심 구성 요소 중 하나인 GPU 메모리 서비스(GMS)는 가중치와 같은 특정 메모리 영역을 엔진 프로세스와 독립적으로 관리한다. GMS는 엔진과 별개의 프로세스를 사용하여 이러한 영역을 소유함으로써 엔진이 재시작되어도 가중치가 메모리에 상주하도록 유지한다. 이는 CUDA 가상 메모리 관리 API를 기반으로 하며, 물리적 GPU 메모리와 관련 가상 주소의 수명을 독립적으로 유지한다. 결과적으로 새 엔진은 기존 메모리에 즉시 연결할 수 있다. GMS는 GPU당 사이드카로 작동하며, `vLLM`, `SGLang`, NVIDIA `TensorRT-LLM`과 같은 추론 프레임워크는 사용자 정의 `torch.cuda.CUDAPluggableAllocator`를 통해 GMS를 통합한다. GMS 채택은 시작 시 플래그를 전환하는 것만으로 가능하며, 현재 미리 보기 버전은 KV 캐시에 GMS를 사용하는 것을 지원하지 않지만, 이 기능은 활발히 개발 중이다.
섀도 엔진은 활성 엔진과 동일한 GPU에 유휴 상태로 상주하는 완전히 초기화된 엔진 프로세스다. 가중치 공유 덕분에 두 번째 엔진이 가중치의 전체 복사본을 필요로 하지 않아 메모리 사용량을 절감하며 이러한 구성이 가능하다. 섀도 엔진은 활성 엔진과 동일한 시작 경로를 거쳐 GMS에 연결하고 가중치 매핑을 가져오며, 통신자(NCCL 및 NIXL)를 설정하고 CUDA 그래프를 캡처하는 등 필요한 워밍업을 수행한다. 초기화가 완료되면 서비스 준비 상태가 되지만, 실제 서비스를 시작하는 대신 대기 상태로 전환하여 메모리의 구체화 가능한 부분을 해제하고 블록한다. 대기 중인 섀도 엔진은 CUDA 컨텍스트, 캡처된 그래프, 통신자, 가중치 매핑을 미리 계산해두며, KV 캐시 구체화는 지연시킨다. 이처럼 대기 중인 섀도 엔진은 가중치 복사본이나 KV 캐시를 보유하지 않아 메모리 점유율이 작아 활성 엔진과 함께 동일 장치에 상주할 수 있으며, 이를 통해 수 초 내 복구가 가능해진다.
각 워커는 두 개의 엔진 컨테이너, GPU 메모리 접근을 중재하는 GMS 사이드카, 그리고 활성 엔진을 선출하는 공유 잠금을 포함하는 단일 배포 가능 단위로 구성된다. 안정 상태에서는 한 엔진이 잠금을 보유하고 활성화되어 GMS에 연결되고 KV 캐시를 구체화하며 프론트엔드 라우터에 등록된다. 다른 엔진은 완전히 초기화되고 GMS에 연결된 상태로 대기하며, KV 캐시를 보유하지 않고 잠금을 기다린다. 복구 시퀀스는 네 단계로 진행된다. T₀(안정)에서 엔진 A가 활성 상태이고 엔진 B가 대기한다. T₁(실패)에서 엔진 A 프로세스가 종료되면 커널이 잠금을 해제한다. T₂(전환)에서 엔진 B가 잠금을 획득하고 활성화되며 GMS를 통해 가중치를 재매핑하고 KV 캐시를 구체화한 후 라우터에 재등록한다. 엔진 A 컨테이너는 오케스트레이터에 의해 재시작된다. T₃(재시작)에서 엔진 A는 초기화를 마치고 섀도 상태로 진입하여 역할이 바뀐 안정 상태로 돌아간다. 워커는 POSIX `flock`을 공유 파일에 사용하여 상호 배제와 안정적인 릴리스를 보장하며, 메모리 회계는 가중치를 GMS가 한 번 할당하고 모든 엔진이 읽기 전용으로 매핑하여 중복을 방지한다. KV 캐시는 현재 활성 엔진만 보유하며, 버퍼와 그래프는 각 엔진이 유휴 상태일 때도 보유한다.
NVIDIA는 GLM-5.2 모델을 사용하여 섀도 엔진 복구의 이점을 정량화하는 벤치마크를 수행했다. NVIDIA B200 노드에서 NVFP4로 양자화된 GLM-5.2를 서비스하는 두 개의 워커(노드당 1개 워커, TP=8, 200K 최대 컨텍스트, FP8 KV 캐시)로 구성된 환경에서 테스트를 진행했다. 부하는 32,000 입력 토큰과 1,000 출력 토큰의 요청이 초당 0.7회 도착하는 합성 부하를 사용했다. 한 워커에 SIGKILL을 주입한 결과, 콜드 리스타트 방식은 두 번째 워커가 다시 서비스를 시작하는 데 283초가 걸린 반면, 섀도 엔진 복구는 7.3초 만에 복구를 완료하여 약 39배 빠른 성능을 보였다. 장애 후 첫 토큰 시간(TTFT) p50은 콜드 리스타트 시 23,815ms였으나, 섀도 엔진 복구 시 1,311ms로 크게 단축되었다. 또한, 디코드 속도 p50은 콜드 리스타트 시 12 tok/s/user에서 섀도 엔진 복구 시 46 tok/s/user로 향상되었다. 5초 이상 첫 토큰 시간을 보인 요청은 콜드 리스타트 시 399개 중 201개였으나, 섀도 엔진 복구 시 398개 중 1개에 불과했다.
이러한 결과는 섀도 엔진 복구가 LLM 추론 서비스의 안정성과 가용성을 크게 향상시킬 수 있음을 보여준다. 엔진 프로세스 실패 시 서비스 중단을 최소화하여 사용자 경험 저하를 방지하고, 서비스 수준 협약(SLA) 위반 가능성을 줄인다. 개발자 관점에서는 GMS 통합이 시작 시 플래그 전환만으로 가능하여 통합 부담이 적으며, 복구 로직의 복잡성을 줄여 개발 및 운영 효율성을 높일 수 있다. 빠른 복구 시간은 특히 실시간 응답이 중요한 LLM 기반 애플리케이션에서 핵심적인 이점으로 작용한다.
현재 미리 보기 버전의 섀도 엔진 복구는 몇 가지 제한 사항과 배포 요구 사항을 가진다. 이 기능은 일반적인 엔진 프로세스 실패를 다루지만, 하드웨어, 노드 또는 다중 노드 실패는 다루지 않으며, 이러한 경우에는 표준 재스케줄링에 의존한다. 또한, Kubernetes 1.34 이상 버전에서 DRA(Dynamic Resource Allocation)가 활성화되고 NVIDIA GPU DRA 드라이버가 설치되어야 한다. 승격된 섀도 엔진은 빈 KV 캐시로 시작하므로 전환 후 첫 토큰 시간(TTFT)에 약간의 지연이 발생할 수 있으며, 캐시 상태를 유지하는 기능은 현재 활발히 개발 중이다. 현재 `vLLM`이 주요 지원 백엔드이다. NVIDIA는 향후 몇 달에 걸쳐 섀도 엔진 복구 구현을 안정화하고 더 넓은 범위의 워크로드로 지원을 확장할 계획이다. Dynamo Snapshot 기능과 함께 사용하여 섀도 엔진 초기화 중 경합을 최소화할 수도 있다.
섀도 엔진 복구 기능을 사용하려면 Kubernetes 퀵스타트를 통해 실행 중인 배포를 생성한 후, 섀도 엔진 복구 배포 워크플로를 따르고 `vLLM` 페일오버 예제를 완전한 매니페스트로 활용할 수 있다. 추가 질문, 문제 보고 또는 기여를 위해서는 `ai-dynamo/dynamo` 저장소를 방문하면 된다.
데빈은 실제 기자가 아닌 AI 기술 에디터입니다. 출처의 공개 기사 본문 또는 RSS 제공 정보에서 사실을 추려 배경과 기술적 영향을 독립적인 한국어 기사로 재구성합니다. 직접 취재한 기사나 원문 전문의 번역·재게시가 아닙니다.
출처 · 원문 확인
NVIDIA Developer Blog · Michelle Horton
Restore LLM Inference Capacity in Seconds with Shadow Engine Recovery in NVIDIA Dynamo
원문 발행: 2026-08-26 05:57:54
원문과 이미지의 권리는 해당 권리자에게 있습니다. 정정·게재 중단 요청은 문의 안내를 이용해 주세요.
관련 소식
- xAI 최신 AI 모델 'Grok 4.7', 아마존 베드록 출시… 50만 토큰 문맥과 추론 제어 지원 · AWS Machine Learning Blog · 2026-09-29
- 구글·XPRIZE '퓨처 비전' 대상에 제프 신세사이즈드의 '더 기프티드' 선정 · Google AI Blog · 2026-09-29
- 프로덕션 AI 배포를 위한 릴리스 매니페스트와 통합 운영 체계 분석 · Stack Overflow Blog · 2026-09-29
- 아마존웹서비스, 다중 계정 환경에서 텍스트랙트 어댑터 수명 주기를 자동화하는 아키텍처 공개 · AWS Machine Learning Blog · 2026-09-29
- Hcompany, GUI·코드·API를 단일 모델로 제어하는 업무용 에이전트 'Holo4' 공개 · Hugging Face Blog · 2026-09-28
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.