무슨 일이 일어났나요?
NVIDIA는 대규모 언어 모델을 제공하기 위한 플랫폼인 Dynamo의 미리 보기 기능으로 섀도우 엔진 복구를 도입했습니다. 설계에서는 활성 엔진 옆에 완전히 초기화된 유휴 엔진을 유지하고 GPU 메모리 서비스를 사용하여 프로세스 오류 시 모델 가중치를 보존하고 공유합니다.
NVIDIA는 2026년 8월 25일자 기술 블로그에서 섀도우 엔진 복구를 NVIDIA Dynamo의 미리 보기 기능으로 설명했습니다. LLM 엔진 프로세스가 실패한 후 기존의 복구를 위해서는 모델 가중치를 고대역폭 메모리에 로드하고, 커널을 컴파일하고, 키-값 캐시 크기를 조정하고, 엔진을 조정하고, CUDA 그래프를 다시 캡처해야 한다고 회사는 말합니다. 대형 모델의 경우 콜드 스타트 시퀀스에 몇 분이 걸릴 수 있으므로 나머지 작업자가 실패한 작업자의 트래픽을 흡수하게 됩니다.
제안된 설계는 각 작업자의 GPU에 두 개의 엔진 프로세스를 배치합니다. 한 엔진은 요청을 처리하고 다른 엔진은 초기화를 완료한 후 휴면 상태에서 기다립니다. NVIDIA의 GPU 메모리 서비스(GMS)는 엔진 프로세스와 독립적으로 가중치에 사용되는 물리적 메모리를 소유합니다. 엔진은 동일한 물리적 가중치 페이지를 자체 CUDA 주소 공간에 매핑하므로 대기 엔진에는 HBM에 있는 모델 가중치의 두 번째 복사본이 필요하지 않습니다. NVIDIA는 GMS가 물리적 페이지를 할당하고 핸들을 제공하는 GPU별 사이드카라고 말합니다. 이후 커널 읽기 경로에 위치하지 않습니다.
휴면 상태가 되기 전에 섀도우 엔진은 CUDA 컨텍스트를 설정하고, 가중치 매핑을 가져오고, NCCL 및 NIXL 커뮤니케이터를 생성하고, CUDA 그래프를 캡처하고, 워밍업을 수행합니다. 주차 중에는 KV 캐시를 구현하지 않습니다. 활성 프로세스가 종료되면 공유 POSIX 파일 잠금이 운영 체제에 의해 해제되어 섀도우가 잠금을 획득하고, 가중치를 다시 매핑하고, 캐시를 구체화하고, 라우터에 등록할 수 있습니다. NVIDIA는 실패한 엔진이 백그라운드에서 다시 시작되어 다음 섀도우가 된다고 말합니다.
NVIDIA는 두 명의 작업자가 있는 GLM-5.2 배포에서 한 명의 작업자를 의도적으로 종료하여 설계를 측정했습니다. 이 설정에서는 양자화된 NVFP4 가중치, NVIDIA B200 노드, 8개의 텐서 병렬 처리, 200,000개의 토큰 최대 컨텍스트, FP8 KV 캐시 및 32,000개의 입력 토큰과 1,000개의 출력 토큰을 포함하는 합성 요청을 사용했습니다. 요청은 초당 0.7로 도착했으며 라운드 로빈 방식으로 배포되었습니다. 해당 테스트에서 두 번째 작업자는 섀도우 복구를 사용하여 7.3초 후에 서비스를 재개했는데, 콜드 재시작의 경우 283초가 걸렸습니다. NVIDIA는 실패 후 첫 번째 토큰까지의 평균 시간이 더 짧고 섀도우 구성에서 사용자당 디코드 속도가 더 높다고 보고했습니다.
소스 세부정보: developer.nvidia.com ↗
왜 중요한가요?
이 기능은 LLM 배포의 실질적인 약점을 겨냥합니다. 즉, 소프트웨어 오류로 인해 살아남은 작업자가 모든 트래픽을 운반하는 동안 교체 프로세스가 가중치를 다시 로드하고 실행 상태를 재구성할 수 있습니다. NVIDIA의 결과는 한 회사에서 실행하는 벤치마크에서 나온 것이며 하드웨어 또는 노드 오류를 다루지 않지만 복구 속도가 빨라지면 대기 시간 급증과 서비스 수준 중단을 줄일 수 있습니다.
즉각적인 가치는 기본 하드웨어를 손상시키지 않는 오류 클래스에 대한 서비스 연속성입니다. NVIDIA는 프로세스 상태가 손실되는 동안 노드와 GPU가 정상으로 유지될 수 있는 경우로서 프로세스 충돌, 복구 가능한 CUDA 오류 및 일시적 집합 오류를 구체적으로 설명합니다. 콜드 재시작 중에 살아남은 작업자가 과부하될 수 있습니다. 회사의 테스트에서는 실패 후 첫 번째 토큰까지의 평균 시간이 기준선에서 23,815밀리초인 것으로 보고되었으며, 섀도우 복구에서는 1,311밀리초가 소요되었습니다.
그 결과 추론 시스템이 값비싼 GPU 용량을 사용하는 방식에 영향을 미치는 메모리 관리 변경도 이루어졌습니다. 대기 엔진에는 일반적으로 가중치의 또 다른 전체 복사본이 필요하므로 요청 처리에 사용할 수 있는 메모리가 줄어듭니다. NVIDIA는 GMS를 사용하면 동시 엔진이 하나의 물리적 복사본을 공유할 수 있게 하고, 파킹된 섀도우는 해당 컨텍스트, 캡처된 그래프, 커뮤니케이터 및 매핑만 유지한다고 말합니다. 회사는 이를 보조 엔진에 대한 한계 중량 비용이 0이라고 규정하지만 소스는 추가된 모든 메모리, CPU, 스토리지 또는 조정 비용에 대한 완전한 설명을 제공하지 않습니다.
벤치마크에서는 모델 자체가 변경되지 않은 경우에도 가용성 엔지니어링이 사용자 경험에 실질적인 영향을 미칠 수 있음을 시사합니다. NVIDIA는 섀도우 암의 398개 요청 중 1개와 비교하여 399개 기준 요청 중 201개가 결함 주입 후 첫 번째 토큰까지 5초를 초과했다고 보고했습니다. 또한 226개의 기본 요청이 섀도우 암에서는 없는 것과 비교하여 사용자당 초당 20개 토큰 미만으로 떨어졌다고 보고했습니다. 이 수치는 NVIDIA가 명시한 종합 테스트에서 측정한 수치이며 모델, 트래픽 패턴 또는 생산 환경 전반에 걸쳐 동일한 개선이 발생할 것이라는 독립적인 증거는 아닙니다.
주장에는 중요한 경계가 있습니다. 이 기능은 미리 보기이며 하드웨어, 노드 또는 다중 노드 오류가 아닌 엔진 프로세스 오류를 해결합니다. 그들은 여전히 표준 재조정을 사용합니다. 승격된 섀도우는 빈 KV 캐시로 시작하므로 NVIDIA는 전환 후 첫 번째 토큰까지의 시간이 약간 증가한다고 말합니다. 회사는 접두사 캐시 인덱스와 캐시 메모리를 모두 이전하기 위해 노력하고 있지만 완료 날짜는 제공하지 않습니다. 또한 소스에는 설명된 구성을 넘어서는 워크로드에 대한 가격, 일반 공급 시기, 독립적 검증 또는 결과가 명시되어 있지 않습니다.
대화형 메커니즘: 실제로 작동하는 방식
이 개발의 이면에 있는 기본 기술을 대화식으로 살펴보세요.
crm_get_transaction(id='4092').Which component of an AI application is the machine-learning model itself?
다음에 무엇을 볼 것인가
NVIDIA는 이 기능이 앞으로 몇 달에 걸쳐 점진적으로 출시될 것이라고 말했습니다. 중요한 테스트에는 실제 워크로드, 더 광범위한 백엔드 지원, 운영 오버헤드 및 향후 버전이 승격 후 다시 구축하는 대신 장애 조치 중에 KV 캐시 상태를 유지할 수 있는지 여부가 포함됩니다.
NVIDIA는 vLLM를 기본 지원 백엔드로 사용하여 섀도우 엔진 복구가 앞으로 몇 달 동안 점진적으로 출시될 것이라고 말합니다. 블로그에는 vLLM, SGLang 및 TensorRT-LLM이 각각 웨이트 메모리 풀을 위한 맞춤형 CUDA 플러그 가능 할당자를 통해 GMS를 통합한다고 나와 있지만 문서화된 복구 예제는 vLLM를 중심으로 구축되었습니다. 향후 릴리스 노트에서는 어떤 백엔드가 전체 복구 워크플로를 사용할 수 있는지, 어떤 배포 조건에서 사용할 수 있는지 명확히 해야 합니다.
다음 기술 이정표는 캐시 연속성입니다. 현재 대기는 물리적 백업 없이 KV 캐시 주소 범위를 예약하고 승격 후에만 캐시를 생성합니다. 이는 주차 공간을 줄이지만 승격된 엔진에 사전 대화 및 접두사 캐시 상태가 부족함을 의미하기도 합니다. 해당 상태를 유지하면 컷오버 후 짧은 성능 저하를 더욱 줄일 수 있으며 소스에서 아직 자세히 설명하지 않은 추가 동기화 및 메모리 관리 요구 사항을 도입할 수 있습니다.
운영자는 자체 장애 모드 및 인프라에 대해 기능을 평가해야 합니다. 설명된 배포에는 Kubernetes 1.34 이상, 동적 리소스 할당 활성화, NVIDIA GPU DRA 드라이버가 필요합니다. NVIDIA는 주입된 결함을 감지하는 데 1.7초, 테스트에서 섀도우를 승격하는 데 5.6초를 보고하지만 이러한 타이밍은 프로브, 라우터, 모델 크기, 클러스터 구성 및 트래픽에 따라 달라질 수 있습니다. 소스는 휴면 엔진 실행에 필요한 비교 리소스 요구 사항을 제공하지 않습니다.
독립적인 테스트에서는 보고된 이득이 다양한 모델, 컨텍스트 길이, 요청 혼합, 자동 크기 조정 동작, 다중 GPU 또는 다중 노드 레이아웃에서 지속되는지 여부를 조사해야 합니다. 또한 오류가 얼마나 자주 감지되는지, 부분 오류 중에 잠금 기반 핸드오프가 안정적으로 유지되는지, 다시 시작된 엔진이 얼마나 빨리 섀도우 상태로 다시 들어갈 수 있는지를 측정해야 합니다. 이러한 질문에 답할 때까지 이 기능은 추론 중단에 대한 일반적인 솔루션이라기보다는 소프트웨어 오류 복구를 위한 유망한 미리 보기로 가장 잘 이해됩니다.