피지컬 AI의 확장 한계와 단일 파이프라인으로의 전환
로봇 공학 및 자율주행(AV)과 같은 피지컬 AI(Physical AI) 시스템은 단일 훈련 작업만으로 완성되지 않습니다. 실제 환경의 데이터를 수집하고, 합성 데이터를 생성하며, 인지 및 정책 모델을 사후 훈련(post-training)하고, 폐쇄 루프(closed-loop) 시뮬레이션에서 평가하는 지속적인 파이프라인이 필수적입니다. 종전의 피지컬 AI 파이프라인은 각 단계마다 별도의 GPU 용량을 프로비저닝하여 관리하는 구조였습니다.
- 실세계 데이터 수집 및 큐레이션
- 합성 데이터 생성
- 정책 사후 훈련
- 폐쇄 루프 시뮬레이션 평가
이러한 구조는 단계별 GPU 획득에 따른 가용성 변동성과 데이터 이동 오버헤드로 인해 비용 효율성이 저하되는 문제를 안고 있었습니다. 이에 따라 개별 작업의 최대 처리량(peak throughput) 대신 전체 루프 동안 예약된 GPU 시간당 유효 파이프라인 진행률을 의미하는 GPU 굿풋(GPU goodput)이 핵심 비용 지표로 부상했습니다.
단일 토큰 스트림과 MoT 기반의 NVIDIA Cosmos 3
엔비디아가 리눅스 재단의 OpenMDW-1.1 라이선스로 공개한 Cosmos 3는 비디오, 이미지, 행동(Action), 음향을 단일 토큰 스트림으로 통합 처리하는 개방형 옴니모달 월드 파운데이션 모델입니다. 확산 트랜스포머(DiT)와 비전-언어 모델(VLM)을 별도로 결합하던 기존 방식과 달리, 단일 트렁크(trunk)의 모든 계층에서 이해와 생성을 통합합니다.
Cosmos 3 핵심 아키텍처 구조
- 단일 토큰 스트림: 이미지 이해는 비전 트랜스포머(ViT)가, 픽셀 생성은 동결된 Wan2.2 비디오 VAE가 담당하며 포즈 델타 및 파지 상태 벡터를 함께 시퀀스화합니다.
- 계층별 결합 전문가(MoT): 각 레이어에 다음 토큰을 예측하는 Reasoner와 노이즈를 제거하는 Generator가 듀얼 스트림 어텐션으로 연결됩니다.
- 추론 비대칭성: 훈련 시에는 완전한 디노이징 및 비디오 디코딩을 수행하지만, 로봇 배치 시에는 비디오 디코딩을 건너뛰고 조인트 위치를 제어하는 행동 토큰만 디코딩합니다.
| 모델 티어 | 파라미터 수 | 백본 구성 | 비고 |
|---|---|---|---|
| Cosmos3-Nano | 16B | Qwen3-VL 8B (Dense) | 사후 훈련 정책 모델용 |
| Cosmos3-Super | 64B | Qwen3-VL 32B (Dense) | 고품질 합성 데이터 생성용 |
| Cosmos3-Edge | 4B | 자체 2B (Dense) | Jetson Thor/Orin 온디바이스 배포용 |
노이즈를 시작하는 토큰의 종류에 따라 세 가지 동작 모드로 전환됩니다. 순방향 역학(Forward dynamics)은 행동을 유지하고 미래 비디오를 생성하며, 역방향 역학(Inverse dynamics)은 비디오로부터 행동 레이블을 추출합니다. 마지막으로 정책(Policy) 모드는 DROID 데이터셋 등에서 15Hz 주파수와 32단계 예측으로 로봇을 구동합니다.
SageMaker HyperPod 기반 모델 팩토리 통합
Amazon SageMaker HyperPod와 Amazon EKS 환경은 Cosmos 3의 단일 풀 공유 아키텍처를 지원합니다. Elastic Fabric Adapter(EFA) 기반의 Amazon FSx for Lustre 스토리지와 S3를 단일 마운트하여 데이터 이동 없이 세 단계를 오케스트레이션합니다.
"합성 데이터 생성은 vLLM-Omni 서버에서 실행되고, 사후 훈련은 FSDP2와 Ulysses 컨텍스트 병렬 처리를 결합한 torchrun 기반 cosmos-framework에서, 평가는 단일 GPU 정책 서버에서 단일 클러스터 풀로 스케줄링됩니다."
HyperPod는 불량 노드를 감지해 자동으로 재부팅하거나 교체하며, 장애 발생 시 Kubeflow PyTorchJob과 NCCL을 복구하여 중단 없는 지속 학습을 유지합니다.
HyperPod InstantStart를 통한 인프라 자율 운용
대규모 분산 인프라 구축의 복잡성을 줄이기 위해 오픈소스 컨트롤 플레인인 HyperPod InstantStart가 도입되었습니다. 이는 AWS 관리형 영역(HyperPod 인프라 복구, Karpenter 기반 노드 오토스케일링 등)과 사용자 관리형 영역(EKS 컨트롤 플레인, HyperPodPyTorchJob 리소스) 사이의 경계를 체계화합니다.
InstantStart는 단일 대역 외(out-of-band) 관리 컨테이너로 동작하며, 모델 컨텍스트 프로토콜(MCP) 도구를 활용해 Kiro CLI 기반 에이전트 및 웹 UI 모두에서 동일한 백엔드 REST API를 구동합니다.
- 단계적 프로비저닝: EKS 컨트롤 플레인 생성(약 8~12분 소요), 의존성 조정, HyperPod 클러스터 생성, 스토리지 마운트를 단계별로 격리해 부분 장애 시 전체 롤백을 방지합니다.
- 네트워크 자동화: 대규모 가속기 플릿을 수용하기 위해 컴퓨팅 서브넷을 `/20` 크기로 기본 할당하고 고유 함수(`ensureComputeSubnet()`)로 관리합니다.
- 사전 딥 헬스체크: OnStartDeepHealthChecks를 통해 EFA 연결 및 GPU 스트레스 테스트를 통과한 노드만 파드 스케줄링에 편입시킵니다.