피지컬 AI의 확장 병목과 통합 모델의 필요성
로봇과 자율주행차(AV) 등 현실 세계의 데이터를 물리적 행동으로 변환하는 피지컬 AI(Physical AI) 시스템은 단일 학습 작업으로 완성되지 않습니다. 합성 데이터 생성, 인식 및 정책 모델 사후 학습, 폐루프(closed-loop) 시뮬레이션 평가로 이어지는 지속적인 파이프라인 루프가 필수적입니다. 종전의 파이프라인은 각 단계마다 별도의 GPU 풀을 프로비저닝해야 했으며, 이는 GPU 유효 처리량(goodput, 예약된 GPU 시간당 유용한 파이프라인 진행률) 저하와 리소스 파편화를 유발했습니다.
엔비디아(NVIDIA)가 Linux Foundation OpenMDW-1.1 라이선스로 공개한 Cosmos 3는 이러한 파편화를 단일 모델 패밀리로 해소합니다. Cosmos 3는 비디오, 이미지, 행동, 음향을 단일 시퀀스로 취급하는 옴니모달 세계 기반 모델(world foundation model)입니다.
- 실세계 데이터 수집 및 선별
- Cosmos3-Super 합성 데이터 생성
- Cosmos3-Nano 정책 사후 학습
- 폐루프 시뮬레이션 평가 및 실패 사례 피드백
Cosmos 3의 핵심 아키텍처: MoT 및 3가지 작동 모드
Cosmos 3는 비전-언어 모델(VLM)에 확산 트랜스포머(DiT)를 단순 결합하는 기존 방식을 탈피하여, 모든 계층에서 결합되는 Mixture-of-Transformers (MoT) 구조를 채택했습니다.
- 단일 토큰 스트림: 이미지 이해를 위한 비전 트랜스포머(ViT), 픽셀 생성을 위한 동결된 Wan2.2 비디오 VAE, 포즈 델타 및 파지 상태를 나타내는 행동 벡터 인코더가 단일 공유 시퀀스로 입력됩니다. 텍스트·비전 입력은 자기회귀(AR) 영역에, 비디오·오디오·행동 출력은 확산(DM) 영역에 배치됩니다.
- 계층별 결합 어텐션: 각 계층은 다음 토큰을 예측하는 추론기(Reasoner)와 노이즈를 제거하는 생성기(Generator)를 동시에 실행하며, 듀얼 스트림 어텐션을 통해 생성 과정 전체가 추론기 출력에 직접 연결됩니다.
- 추론 비대칭성: 학습 단계에서는 전체 디노이징 스케줄을 거쳐 비디오 픽셀을 복원하지만, 로봇 배치 단계에서는 적은 수의 디노이징 스텝만 수행하고 비디오 디코딩을 건너뛰어 관절 위치 제어값만 복원합니다.
Cosmos 3 베이스 체크포인트는 어떤 토큰을 노이즈로 설정하느냐에 따라 3가지 모드로 전환됩니다.
| 작동 모드 | 입력 상태 (Clean) | 출력 대상 (Noisy 노이즈 제거) | 주요 용도 |
|---|---|---|---|
| 순역학 (Forward Dynamics) | 현재 프레임 + 행동 | 미래 비디오 | 롱테일 주행 및 조작 시나리오 합성 데이터 생성 |
| 역역학 (Inverse Dynamics) | 전후 2개 비디오 프레임 | 행동 | 원시 원격조작 영상 및 주행 영상의 행동 라벨링 |
| 정책 (Policy) | 3방향 뷰 이미지 + 고유수용감각 | 32개 미래 관절 위치 + 비디오 잠재변수 | 15Hz 제어 주기의 실기 로봇 배치 (예: DROID 데이터셋) |
모델 제품군은 Cosmos3-Nano(16B 파라미터, 8B Qwen3-VL 백본 기반), Cosmos3-Super(64B 파라미터, 32B Qwen3-VL 백본 기반), 그리고 Jetson Thor/Orin 온디바이스 배치를 위해 2B 기반 백본에서 스크래치 학습된 Cosmos3-Edge(4B 파라미터)로 구성됩니다.
SageMaker HyperPod 기반 피지컬 AI 팩토리 구성
Cosmos 3의 아키텍처는 Amazon SageMaker HyperPod와 Amazon Elastic Kubernetes Service (Amazon EKS) 인프라로 연결됩니다. 생성, 사후 학습, 평가 작업이 단일 클러스터 제어 플레인 하의 단일 GPU 풀을 시분할 공유합니다.
- 통합 런타임 엔진: 생성 단계는 vLLM-Omni 서버, 사후 학습은 torchrun 기반 Fully Sharded Data Parallel (FSDP2) 및 Ulysses 컨텍스트 병렬성, 평가는 단일 GPU 정책 서버에서 실행됩니다.
- 단일 스토리지 계층: Amazon Elastic Fabric Adapter (EFA) 기반의 Amazon FSx for Lustre 파일 시스템이 Amazon S3 버킷과 데이터 리포지토리 연결(DRA)로 마운트되어 모든 단계에서 동일 경로를 참조합니다.
- 자동 복구 및 회복 탄력성: Kubeflow PyTorchJob을 통해 워커 장애 발생 시 노드를 자동 재부팅·교체하고 통신(NCCL)을 재구성하여 분산 학습을 자동으로 재개합니다.
"이 루프를 지속적으로 실행하는 데 드는 비용을 결정하는 지표는 단일 작업의 최고 처리량이 아닙니다. 전체 루프에 걸쳐 예약된 GPU 시간당 유용한 파이프라인 진행률을 나타내는 GPU 유효 처리량(goodput)입니다."
HyperPod InstantStart를 통한 에이전트 기반 인프라 운영
복잡한 파운데이션 모델 인프라 운영 부담을 줄이기 위해 오픈소스 제어 플레인인 HyperPod InstantStart가 도입되었습니다. InstantStart는 AWS 계정 내 단일 아웃오브밴드(out-of-band) 관리 컨테이너 형태로 구동되며, 포트 3099에서 웹 UI를 제공하는 동시에 Model Context Protocol (MCP) 서버를 통해 AI 에이전트 제어를 지원합니다.
- 사용자 입력 (웹 UI 또는 Kiro CLI)
- HyperPod InstantStart 제어 플레인
- 단일 백엔드 REST API 및 검증
- Amazon EKS 및 SageMaker HyperPod API 프로비저닝
InstantStart는 다음과 같은 원칙으로 인프라 배포를 단순화합니다.
- 단계별 프로비저닝 격리: EKS 제어 플레인 생성(약 8~12분 소요), 활성 클러스터 선택, 의존성 조정, HyperPod 클러스터 생성, 스토리지 설정을 독립적인 단계로 분리하여 후속 단계 실패 시 이전 성공 단계가 롤백되지 않도록 보장합니다.
- Kiro CLI 및 hypd-inst-agent 연동: AI 에이전트가 가용 영역, 인스턴스 타입, 용량 유형 등 의사결정 수준의 매개변수만 질의하며, 서브넷 CIDR, 라우트 테이블 구성 등 복잡한 네트워크 배치는 제어 플레인 함수(`ensureComputeSubnet()`)를 통해 자동 처리합니다. 대규모 가속기 플릿을 위해 컴퓨트 서브넷은 /20 크기로 구성됩니다.
- 강건한 용량 관리 및 딥 헬스체크: 온디맨드, 스팟(Spot), Flexible Training Plan 예약 용량을 지원하며, `OnStartDeepHealthChecks`를 통해 작업 수락 전 GPU 및 EFA 연결 스트레스 테스트를 수행합니다. 또한 AWS 관리형 Karpenter 오토스케일링을 통해 0개 노드 기준 스케일업을 지원합니다.