NVIDIA, Dynamo용 AICR Kubernetes 기반 설명… 모델 배포 전에 runtime 검증

NVIDIA는 2026년 10월 30일 AI Cluster Runtime(AICR)으로 Dynamo 추론 서비스의 검증 가능한 Kubernetes 기반을 만드는 과정을 설명했다. DynamoGraphDeployment는 모델 제공 구성을 정의하지만 GPU 드라이버, 자원 할당, 일정 관리, 네트워크 진입점, 모니터링의 준비를 보장하지는 않는다. AICR은 Dynamo와 지원 구성요소를 버전이 정해진 레시피로 묶고 선택한 클러스터가 요구 조건을 충족하는지 검사한다. 이는 runtime 배포와 검증 절차이지 새 모델의 학습이나 특정 앱의 처리량 향상을 측정한 발표가 아니다.

글은 요청 경로 두 가지를 구분한다. 간단한 경로는 Dynamo Frontend를 Kubernetes Service 뒤에 둔다. KV 라우팅을 켜면 Frontend가 요청을 토큰화하고 공통 접두부와 현재 부하를 고려해 worker를 고른 뒤 요청을 직접 전달한다. 모델별 진입점 또는 Frontend로만 넘기는 기존 프록시에 알맞다. 다른 경로는 Gateway API와 Inference Extension을 쓴다. HTTPRoute가 InferencePool을 가리키고 Dynamo operator가 DynamoGraphDeployment로부터 풀과 Endpoint Picker 참조를 만든다. Gateway가 Dynamo EPP를 호출하면 EPP가 KV 정보로 worker를 골라 경로 정보를 반환한다. 실제 HTTP 요청을 선택된 worker의 Frontend sidecar로 전송하는 주체는 Gateway다. 선별과 전송은 서로 다른 책임이다.

두 경로 모두 HTTPRoute 뒤에 올 수 있으므로 차이는 단순히 게이트웨이 유무가 아니다. worker로 가는 전송, 시간 초과, 재시도, fallback을 Frontend와 Gateway 중 어느 쪽이 관리하는지가 핵심이다. 두 번째 경로에는 호환 Gateway, InferencePool, EPP, worker sidecar가 추가된다. NVIDIA는 첫 번째가 가장 작고 운영 경험이 많은 구성이라고 설명한다. 이 글의 두 번째 경로는 operator가 관리하는 DynamoGraphDeployment 통합이며 실험적인 독립 vanilla vLLM 연결과 다르다. Dynamo 1.4의 EPP는 Go 프레임워크에 CGO로 Rust KV 라우터를 넣는다. 순수 Rust EPP는 이후 1.5 방향이지 현재 1.4.2 레시피의 기능이 아니다.

에이전트 대화는 시스템 지시, 도구 정의, 이전 대화 같은 긴 접두부를 반복한다. 필요한 KV 캐시 블록을 가진 worker로 요청을 보내면 입력의 재처리를 줄일 수 있다. worker가 로컬 ZMQ로 캐시 이벤트를 내보내고 Dynamo가 이를 정리해 자체 이벤트 평면에 다시 게시한다. 요청 평면은 기본 TCP, 캐시 이벤트 평면은 ZMQ로 서로 다르다. 두 라우팅 방식 모두 worker가 공개한 실제 캐시와 부하 상태를 사용할 수 있다. 예측 캐시 지도도 설정 가능하지만 NVIDIA는 축출을 놓쳐 실제 상태에서 벗어날 수 있다고 경고한다. prefill과 decode 분리도 설명하지만 캐시 미스 비율은 실제 부하에 달려 있어 구조 그림만으로는 알 수 없다.

AICR 절차는 순서가 있다. aicr snapshot으로 클러스터 상태를 기록하고 aicr recipe로 이에 맞는 Dynamo 추론 레시피를 선택해 구성요소 버전, 플랫폼 제약, 검사를 고정한다. 글의 AICR v1.0.0 Amazon EKS 예제는 GB200 NVL72와 GB300 NVL72에서 Dynamo Platform 차트를 1.4.2로 고정한다. 이는 특정 플랫폼에서 시험한 조합이지 모든 환경의 최신 버전이라는 뜻이 아니다. 선택적인 오프라인 검사는 다른 기록된 snapshot과 비교하지만 실제 클러스터가 없으면 동작 검사는 건너뛴다. 이어 aicr bundle로 Helm 설정과 명세를 만들고 runtime을 설치한 뒤 aicr validate로 실제 클러스터의 배포와 적합성을 확인한다. 앱의 DynamoGraphDeployment는 그 이후 설치한다.

레시피에는 Helm 구성요소 버전뿐 아니라 노드 선택 조건, 허용되는 taint, 검증 기준과 체크섬도 들어간다. 따라서 EKS와 특정 GB200·GB300 환경을 위해 고정한 표를 다른 클러스터에 그대로 적용할 근거는 없다. 오프라인에서 다른 snapshot과 비교할 때는 선언된 제약을 살필 수 있지만 실제 Kubernetes 동작 검사는 수행하지 못한다. 또 요청 전달은 기본적으로 TCP를 사용하고, worker의 KV 캐시 이벤트는 로컬 ZMQ 소스에서 나와 Dynamo의 이벤트 경로로 다시 배포된다. 예측 캐시만 쓰면 축출을 놓쳐 실제 worker 상태와 달라질 수 있다. 모든 기반 검사를 마친 뒤에도 앱의 DynamoGraphDeployment를 설치해야 하며, 처리량 확인에는 GPU를 소비하는 별도 성능 검증이 필요하다.

일반적인 검사 대상은 GPU 용량과 nvidia-smi, GPU Operator와 Dynamo 상태, DRA 접근, gang scheduling과 자동 확장, Prometheus 지표, Kubernetes 고유 진입점을 쓸 때 Gateway 준비 상태다. NVIDIA는 성능 검증을 별도 단계로 구분한다. 임시 서비스 부하를 띄워 GPU를 소비하기 때문이다. 기반 배포와 적합성 검사를 통과해도 앱 처리량이 증명되는 것은 아니다. 레시피마다 검사 범위가 다르며 이 글은 이 매체나 독자의 클러스터가 통과했다고 말하지 않는다. 클러스터 기록부터 고정 버전, 설치, 실제 검사까지의 재현 가능한 순서가 핵심이다.