Accelerate agentic AI with NVIDIA Nemotron models on Amazon EKS and SageMaker HyperPod EKS

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS는 추론·도구 사용과 시각 이해를 결합한 NVIDIA Nemotron 3.5 Super VL을 Amazon EKS, EKS Auto Mode, SageMaker HyperPod EKS에 배포하고 성능과 용량을 평가하는 방법을 소개한다.

📌 핵심 요약

• Nemotron 3.5 Super VL은 Nemotron 3 Ultra에서 증류한 공개 멀티모달 모델로, 전체 120B 파라미터 중 토큰당 12B를 활성화한다. 최대 1M 토큰 문맥과 텍스트·이미지·문서·비디오 입력을 지원하며 출력은 텍스트다. NVIDIA는 가중치, 학습 데이터셋, 후속 학습 방법을 공개한다.
• 모델은 Mamba-2·MoE·어텐션 계층과 RADIO 비전 인코더를 결합하고 BF16·NVFP4 체크포인트를 제공한다. vLLM 기준 최소 GPU 수는 BF16/NVFP4 순서로 B200/GB200이 8/2개, B300/GB300이 4/1개, H200이 8/4개, H100이 16/8개다.
• NVIDIA가 보고한 성능은 Hermes Bench 63.44%, LangChain 에이전트 평가 87.05%, CharXiv 차트 추론 평가 80.8%다. 활용 분야로 코딩, 웹 조사, 문서 이해, 사이버 보안, 비디오 이해를 제시한다.
• 참조 구현은 Amazon EKS, EKS Auto Mode, SageMaker HyperPod EKS에서 동일한 모델 배포용 Kubernetes 매니페스트를 사용한다. NVIDIA Dynamo는 단일 노드 통합 배포와 프리필·디코드 분리 배포를 지원하며, 시각 언어 모델의 이미지·비디오 인코딩도 별도 노드로 분리할 수 있다.
• 아키텍처는 B200 GPU 8개의 p6-b200.48xlarge와 H200 GPU 8개의 p5en.48xlarge에서 검증됐다. NCCL all-reduce로 GPU·EFA 동작을 확인하고 NVIDIA aiperf로 TTFT·ITL·TPS를 동시 요청 수별로 측정한다. 원문의 용량 산정 예시는 TTFT 600ms 미만·ITL 100ms 미만 조건에서 c32, 약 320토큰/초를 복제본 하나의 처리량으로 삼는다.

🧩 주요 포인트

1. 희소 활성화와 정밀도별 GPU 요구량 → 토큰당 연산량 절감과 전체 가중치의 GPU 메모리 수용 조건을 함께 고려해야 한다.
2. 공통 Kubernetes 매니페스트와 aws-do-eks 참조 구현 → 세 가지 AWS 배포 환경에서 클러스터 생성부터 모델 배포·검증·정리까지 같은 패턴을 적용할 수 있다.
3. 동시 요청 수에 따른 TTFT·ITL·TPS 변화 → 서비스 수준 목표에 맞는 처리량으로 복제본 수를 산정하고, ITL 상승 시 디코드 용량, TTFT 상승 시 프리필 용량의 확장을 판단할 수 있다.

🧠 상세 정리

1. 공개 멀티모달 모델의 특징과 평가 결과

Nemotron 3.5 Super VL은 AWS에서 제공되는 NVIDIA Nemotron 제품군에 추가된 모델로, Nemotron 3 Ultra에서 증류한 공개 멀티모달 모델이다. 전체 파라미터는 120B이며 토큰당 12B를 활성화하고, 최대 1M 토큰의 문맥을 지원한다. 텍스트·이미지·문서·비디오를 입력받아 텍스트를 출력하므로 하나의 모델로 텍스트 작업과 시각 정보 처리 작업을 수행할 수 있다. NVIDIA는 가중치와 학습 데이터셋, 후속 학습 방법을 공개해 도메인별 맞춤화와 사용자가 통제하는 인프라에서의 실행을 지원한다. NVIDIA가 보고한 평가 점수는 Hermes Bench 63.44%, LangChain 에이전트 평가 87.05%, CharXiv 차트 추론 평가 80.8%이며, 원문은 기술 보고서를 근거로 제시한다.

2. 하이브리드 구조와 에이전트 활용

모델은 Mamba-2, 어텐션, 전문가 계층을 교차 배치한 하이브리드 Mamba-Transformer MoE 구조에 RADIO 비전 인코더를 결합한다. 희소 라우팅으로 토큰당 연산량은 훨씬 작은 모델 수준으로 줄이지만, GPU 메모리에는 전체 가중치를 수용해야 한다. Mamba-2 계층은 생성 중 일정한 크기의 상태를 유지하므로 해당 계층의 메모리는 KV 캐시처럼 시퀀스 길이에 따라 증가하지 않으며, 재귀적으로 공유되는 Multi-Token Prediction(MTP) 헤드는 네이티브 추측 디코딩을 지원한다. 활용 사례에는 코드 테스트·오류 분석·수정 제안, 검색 도구가 반환한 출처의 교차 검증, 표·차트·페이지 배치 해석, 취약점 식별과 위협 분류, 비디오 검색·검토·사건 분석이 포함된다. 주요 공개 에이전트 프레임워크 및 오케스트레이션 시스템과의 통합은 NVIDIA 참조 구현, 쿡북, NVIDIA Agent Toolkit을 통해 제공된다.

3. 정밀도별 GPU 요구량과 배포 절차

Nemotron 3.5 Super VL은 BF16과 NVFP4 체크포인트를 제공하며, 원문은 vLLM 사용 시 GPU 모델과 정밀도에 따른 최소 GPU 수를 제시한다. BF16/NVFP4 순서로 B200/GB200은 8개/2개, B300/GB300은 4개/1개가 필요하다. 같은 순서로 H200은 8개/4개, H100은 16개/8개가 필요하므로 정밀도와 GPU 종류에 따라 최소 구성이 크게 달라진다. 상세 배포 안내는 aws-do-eks 프로젝트에 있으며, Nemotron 3.5 Super VL과 Nemotron 3 Ultra의 사전 준비, 클러스터 생성, 가중치 다운로드, 배포, 테스트, 벤치마킹, 정리 절차를 다룬다. 원문은 이 배포 패턴을 NVIDIA Nemotron 제품군의 다른 모델에도 적용할 수 있다고 설명한다.

4. AWS 배포 아키텍처와 단계별 분리

참조 구현은 표준 Amazon EKS, EKS Auto Mode, SageMaker HyperPod EKS에서 실행되며, 세 환경에서 모델 배포용 Kubernetes 매니페스트는 동일하다. EKS Auto Mode에서는 AWS가 클러스터의 확장과 GPU·EFA 지원을 관리한다. 각 클러스터는 Kubernetes API를 제공하는 제어 영역과 CPU·GPU 노드로 구성된 데이터 영역을 갖추고, CPU 노드는 시스템·테스트 파드를, GPU 노드는 모델을 실행한다. 컨테이너 이미지는 Amazon ECR에 저장하고 모델 가중치는 공유 Amazon FSx for Lustre 볼륨에 보관하며, GPU 노드 간 연결에는 EFA를 사용한다. NVIDIA Dynamo는 단일 노드에 통합한 서빙 또는 프리필과 디코드를 서로 다른 노드에 배치하는 분리 서빙을 지원하며, 시각 언어 모델에서는 이미지·비디오 인코딩 단계도 자체 노드로 분리할 수 있다.

5. 클러스터 검증과 추론 성능 측정

이 아키텍처는 NVIDIA B200 GPU 8개를 갖춘 p6-b200.48xlarge와 NVIDIA H200 GPU 8개를 갖춘 p5en.48xlarge에서 검증됐다. 클러스터와 네트워크는 NVIDIA Collective Communications Library(NCCL)의 all-reduce 마이크로벤치마크로 확인할 수 있으며, 실행 중 모든 GPU의 사용과 모든 EFA 어댑터의 트래픽을 관찰하는 것이 정상 동작의 검증 근거다. 배포한 모델의 성능은 NVIDIA aiperf로 측정하며, 주요 지표는 첫 토큰까지의 시간인 TTFT, 토큰 간 지연인 ITL, 초당 토큰 처리량인 TPS다. 동시 요청 수를 달리해 이 지표들을 측정하면 요청 부하에 따른 지연과 처리량의 관계를 파악하고 용량 및 배포 구성을 결정할 수 있다. aws-do-eks 컨테이너는 GPU·EFA 사용률 시각화, aiperf 실행, 동시 요청 수 변화 실험을 각각 단일 명령으로 수행하는 자동화를 제공한다.

6. 지연 목표를 활용한 용량 산정과 확장 판단

원문은 두 노드에서 통합 배포와 분리 배포를 비교한 동시 요청 수 실험을 소개하며, TTFT는 더 낮고 ITL은 대체로 비슷하다고 서술하지만 어느 구성이 더 낮은 TTFT를 보이는지는 본문 문장만으로 명확하지 않다. 용량 산정 예시에서는 TTFT 600ms 미만과 토큰당 ITL 100ms 미만을 지연 한도로 두고, 두 조건을 모두 충족하는 가장 오른쪽 지점을 선택한다. 제시된 예시의 해당 지점은 c32이며, 이 구성의 복제본 하나가 서비스 수준 목표 안에서 제공하는 처리량은 약 320토큰/초다. 목표 초당 토큰 수를 이 처리량으로 나누면 배포할 프리필·디코드 쌍의 수를 산정할 수 있다. 정밀도, TP/PP 구성, 통합·분리 방식, Dynamo 또는 vLLM 버전이 바뀌면 같은 실험을 반복해 비교하며, 곡선이 오른쪽 아래로 이동하면 개선으로 해석한다. ITL 상승은 디코드 용량, TTFT 상승은 프리필 용량을 늘릴 필요가 있음을 판단하는 신호로 제시된다.

🧾 핵심 주장 / 시사점

• 토큰당 활성 파라미터가 12B라는 사실만으로 GPU 요구량을 판단할 수는 없다. 전체 120B 가중치를 수용해야 하므로 연산량과 메모리 요구량을 구분해 배포 구성을 검토해야 한다.
• 세 AWS 환경에서 모델 배포용 매니페스트를 공유하므로, 모델 배포 방식의 공통성을 유지하면서 클러스터 관리 방식과 추론 단계의 배치를 선택할 수 있다.
• TTFT와 ITL을 별도로 측정하면 전체 처리량뿐 아니라 프리필과 디코드 중 어느 단계의 용량을 확장해야 하는지도 판단할 수 있다.

✅ 액션 아이템

• aws-do-eks 참조 구현과 BF16·NVFP4별 최소 GPU 요구량을 바탕으로 Nemotron 3.5 Super VL의 배포 구성 검토.
• NCCL all-reduce로 GPU·EFA 동작을 검증하고 NVIDIA aiperf로 동시 요청 수별 TTFT·ITL·TPS 측정.
• 서비스 수준 목표를 충족하는 복제본 하나의 처리량으로 필요 복제본 수를 산정하고, TTFT·ITL 변화에 따라 프리필·디코드 확장 방향 판단.

❓ 열린 질문

• Nemotron 3.5 Super VL의 BF16·NVFP4별 최소 GPU 요구량을 고려할 때 어떤 GPU 구성이 배포 조건에 적합한가?
• Amazon EKS, EKS Auto Mode, SageMaker HyperPod EKS 중 어떤 환경과 프리필·디코드 배치 방식이 적합한가?
• 실제 동시 요청 수에서도 TTFT 600ms 미만·ITL 100ms 미만을 충족하며 복제본 하나당 약 320토큰/초를 제공할 수 있는가?