NVIDIA가 Dynamo용 Kubernetes 런타임 레시피를 상세히 설명합니다
NVIDIA는 Kubernetes에서 Dynamo를 배포하는 팀들이 서빙 프레임워크 자체뿐만 아니라 GPU 드라이버 스택, 스케줄링, 네트워킹, 관측 가능성 계층도 정렬되어야 신뢰성 있는 추론 엔드포인트가 가능하다고 밝혔습니다. 2026년 10월 30일에 발표된 기술 게시물에서 회사는 NVIDIA AI 클러스터 런타임(AICR)이 검증된 인프라 레시피를 포함해 다이나모를 패키징하여 해당 과정을 반복 가능하게 만드는 방식을 설명했습니다.
증거와 맥락
이 글은 다이너모를 GPU 작업자 간 모델을 조정하는 분산 추론 프레임워크로 구성하지만, 그 아래 런타임도 똑같이 중요하다고 말합니다. NVIDIA는 생산 추론 클러스터가 GPU 운영자와 드라이버 스택이 노드와 일치하는지 확인해야 하며, GPU 노드는 라벨링되어 발견 가능하며, Kubernetes는 동적 자원 할당을 통해 GPU를 노출하고, 스케줄러는 워커를 적절한 토폴로지와 갱 스케줄링 의미론으로 배치할 수 있으며, 노드 건강 신호는 워크로드가 도착하기 전에 제공되고, Prometheus에 메트릭 접근 가능하며, Kubernetes 네이티브 인그레스가 사용될 때 게이트웨이 API 경로가 설정되어야 한다고 밝혔습니다.
기사에 따르면, AICR은 이러한 요구사항을 레시피에 담아냅니다. 레시피에는 고정된 컴포넌트 버전, 호환성 제약, 노드 선택기, 허용 범위, 체크섬, 검증 기대치가 포함되어 있습니다. NVIDIA는 다이너모 레시피가 다이너모 플랫폼 차트의 1.4.2 버전을 제공하며, 다이너모 연산자, 런타임 이미지, nvidia.com/v1beta1 다이나모그래프 배포 맞춤 리소스 정의를 포함한다고 밝혔습니다. v1beta1 이전 v1alpha1 API 버전을 대체한다고 밝혔습니다.
게시물에는 AICR 레시피가 더 이상 기본적으로 Dynamo 1.4에 NATS를 설치하지 않는다고 적혀 있습니다; 대신 프론트엔드, 워커 및 선택적 게이트웨이 API 추론 확장 / 엔드포인트 선택기 플러그인 구성 요소가 쿠버네티스 리소스를 통해 서로 한 발견합니다. NVIDIA는 NATS가 여전히 필요한 배포에 대해 선택적으로 제공된다고 밝혔습니다.
Kubernetes에서 Dynamo용 라우팅 경로
NVIDIA는 두 가지 라우팅 토폴로지를 설명했습니다. 첫 번째는 Kubernetes 서비스 뒤에 위치한 Dynamo 프론트엔드 라우터를 사용합니다. 이 경로에서 프론트엔드는 요청을 토큰화하고, 접두사 중복과 현재 부하를 사용하여 자격 있는 워커를 점수 매기며, 워커를 선택하고 Dynamo TCP 요청 평면을 통해 요청을 디스패치합니다. 회사는 이것이 가장 작은 토폴로지이며, 모델별 엔드포인트나 Dynamo 프론트엔드 서비스로만 트래픽을 전달하는 기존 엣지 프록시에 적합하다고 밝혔습니다.
두 번째 경로는 Dynamo를 Gateway API 및 Gateway API 추론 확장과 통합합니다. 이 토폴로지에서는 agentgateway와 같은 게이트웨이가 HTTPRoute를 InferencePool로 해석하고, 운영자가 DynamoGraphDeployment에서 그 풀을 생성하며, Dynamo EPP가 토큰 인식 엔드포인트 선택을 수행합니다. NVIDIA는 게이트웨이가 HTTP 프록시로 남아 있고, 각 라우팅 가능한 워커 포드의 Dynamo 프론트엔드 사이드카는 직접 모드로 실행되어 요청을 워커 컨테이너로 전달한다고 밝혔습니다.
게시물에서는 두 경로 모두 라우팅 결정을 위해 작업자가 게시한 KV-캐시 이벤트를 사용한다고 밝혔습니다. 또한 Dynamo는 예측된 캐시 상태를 기반으로 라우팅할 수 있지만, 예측은 퇴출을 감지하지 못해 메모리 압력 시 라우팅 품질이 저하될 수 있다고 언급했습니다. 기사 내 AICR 구성은 대신 라이브 이벤트를 사용합니다.
배포 및 검증 워크플로우
NVIDIA는 다섯 단계로 구성된 AICR 워크플로우를 제시했습니다. 첫째, aicr 스냅샷 명령어로 클러스터 스냅샷을 수행합니다. 둘째, AICR은 선택한 플랫폼에서 추론 레시피를 생성합니다. 셋째, 런타임 번들을 배포 준비가 가능한 매니페스트와 Helm 값으로 렌더링합니다. 넷째, 런타임은 Helmfile 또는 다른 지원되는 배포기를 통해 배포됩니다. 다섯째, 애플리케이션 워크로드를 추가하기 전에 설치된 런타임을 검증합니다.
NVIDIA GB200 NVL72 및 NVIDIA GB300 NVL72 시스템에 대한 Amazon EKS Dynamo 추론 레시피에 대해, 게시물에는 NVIDIA GPU Operator v26.7.1, Node Feature Discovery 0.19.0, cert-manager v1.20.2, AWS EBS CSI Driver 2.59.0, AWS EFA v0.5.29등 고정 차트 버전들이 나열되어 있습니다. NVSentinel v1.25.0, NodeWright 운영자 v0.19.0, NVIDIA DRA GPU 드라이버 0.5.0, KAI 스케줄러 v0.16.9, Grove v0.1.0-alpha.13, Dynamo 플랫폼 1.4.2, 에이전트 게이트웨이 v1.5.0, 에이전트 게이트웨이 CRD v1.5.0, Kube Prometheus 스택 84.4.0, Prometheus Operator CRDs 28.0.1, Prometheus 어댑터 5.3.0 와 Kubernetes 임시 스토리지 메트릭 1.19.2.
기사에 따르면 검증 검사는 일반적으로 클러스터 기본 상태 상태, GPU 운영자 상태, 가속기 접근, 갱 스케줄링 및 자동 확장성 동작, Prometheus 기반 지표를 통한 관측성, 그리고 Kubernetes 네이티브 인그레스에 대한 게이트웨이 API 및 에이전트게이트웨이 준비 상태를 포함합니다. NVIDIA는 성능 검증이 임시 서비스 워크로드를 배포하고 테스트 중인 GPU를 소모하기 때문에 별개라고 밝혔습니다.
회사에서는 AICR과 Dynamo가 NVIDIA DSX AI Factory Platform의 오픈소스 구성 요소이며, 배포 사례와 커뮤니티 자원은 NVIDIA DSX AI Factory GitHub와 Slack 커뮤니티를 통해 제공된다고 말하며 마무리했습니다. 또한 KubeCon + CloudNativeCon 북미에서의 실습 워크숍 활동도 언급했으나, 해당 행사 언급 외에 향후 촉매 날짜는 명시하지 않았습니다.