📃StarVLA 리뷰

StarVLA: A Lego-like Codebase for Vision-Language-Action Model Developing

• Paper Link (arXiv:2604.05014v1)

• Project Page

• Code (GitHub) — 공개됨, MIT, 기본 브랜치 starVLA_dev (2026-08-13 확인 기준 ⭐3,448 / fork 446 / 최근 push 2026-08-09)

• 저자: “StarVLA Community & Von Neumann Institute, HKUST” (표지 명의). 실제 명단은 본문 §9에 별도 공개 — Jinhui Ye, Ning Gao, Yilun Chen†, Weiyu Guo, Zixuan Wang, Yuxing Chen, Fangjing Wang, Senqiao Yang, Chengyao Wang, Yuqi Liu, Meng Chu, Changsheng Lu, Pengguang Chen, Shu Liu†, Jiaya Jia†* (†교신저자, *Von Neumann Institute, HKUST) + Community Contributors 14인

• 기술 리포트, 2026년 4월 (arXiv v1 2026-04-06, cs.RO). 학회 게재 정보 없음

1. 💡 VLA 연구가 “아키텍처·코드베이스·평가 프로토콜이 제각각인 바벨탑”이 되어 비교와 재현이 불가능해졌다는 진단에서 출발해, backbone(VLM 또는 world model)과 action head를 공유 계약 아래에서 서로 독립적으로 갈아 끼우는 단일 코드베이스를 제안한다.
2. ⚙️ 모든 방법을 forward() / predict_action() 두 메서드를 가진 프레임워크 클래스로 통일하고(입력은 전처리된 텐서가 아니라 로봇이 배포 시 받는 그대로의 원본 관측), 그 내부를 VL backbone + pluggable action head로 쪼갠다. 학습 목표는 \mathcal{L}=\mathcal{L}_{\text{action}}+\mathcal{L}_{\text{aux}} 하나로 통일되고, VLM 계열·world model 계열의 차이는 \mathcal{L}_{\text{aux}}의 형태 차이로 환원된다.
3. 🎯 최소한의 데이터 엔지니어링만으로 LIBERO 평균 96.6%(30K steps, OpenVLA-OFT는 175K steps에 97.1%), SimplerEnv WidowX 최고 65.3%, RoboTwin 2.0 clean/random 88.2/88.3, RoboCasa-GR1 24태스크 평균 48.8%를 냈고, 4개 벤치마크를 합쳐 학습한 단일 generalist 모델이 RoboCasa-GR1에서 57.3%로 오히려 specialist를 앞선다.

---

🔍 Ping Review

🔍 Ping — A light tap on the surface. Get the gist in seconds.

이건 모델 논문이 아니라 연구 인프라 논문이다. 새 알고리즘을 제안하지 않고, “이미 나와 있는 VLA 설계들을 하나의 추상화 밑으로 모을 수 있는가”를 묻는다. 저자들의 진단은 명확하다 — VLA 연구는 세 층위에서 파편화됐다. 아키텍처 층에서는 autoregressive tokenization·parallel regression·diffusion·flow matching이 서로 비교 불가능하게 흩어져 있고, 시스템 층에서는 각 방법이 모델 구조·데이터 처리·학습 파이프라인을 한 덩어리로 묶어 배포해 부품 재사용이 안 되며, 평가 층에서는 논문마다 다른 벤치마크 부분집합을 다른 프로토콜로 보고한다. 논문은 이걸 VLA 연구의 “Tower of Babel”이라 부르고, 원인을 통일된 추상화의 부재로 지목한다.

StarVLA가 채택한 통일 VLA 정식화(Fig. 1) — 정책 \pi가 시각 관측과 언어 지시를 미래 action chunk로 사상하고, 모델 계열(VLM-VLA / WM-VLA / Policy-VLA)의 차이는 보조 손실 \mathcal{L}_{\text{aux}}의 형태 차이로 정리된다.

핵심 방법론:

VLA 시스템을 행동 생성 중심의 정책 하나로 정식화한다.

\pi\!\left(\mathbf{a}_{t:t+k},\ \mathbf{y}_{\text{aux}}\ \middle|\ \mathbf{x}_{\leq t},\ \ell\right)

여기서 \mathbf{x}_{\leq t}=\{o^{\text{vis}}_{\leq t},o^{\text{depth}}_{\leq t},o^{\text{tactile}}_{\leq t},\dots\}는 시각·깊이·촉각·고유수용감각을 포함할 수 있는 관측 이력, \ell은 언어 지시, \mathbf{a}_{t:t+k}는 k-스텝 action chunk, \mathbf{y}_{\text{aux}}는 미래 관측 예측이나 중간 언어 추론 같은 선택적 보조 출력이다. 학습 목표는

\mathcal{L}=\mathcal{L}_{\text{action}}+\mathcal{L}_{\text{aux}}

로 통일되고, 세 계열은 \mathcal{L}_{\text{aux}}의 선택으로 갈린다 — Direct VLA는 \mathcal{L}_{\text{aux}}=0, VLM-based VLA는 하위 태스크 계획·공간 grounding 같은 언어 정렬 보조 목표, WM-based VLA는 미래 관측(이미지/비디오) 예측. 저자들은 이를 generalized VLA perspective라 부르며, VLM 기반과 world model 기반이 근본적으로 다른 패러다임이 아니라 같은 구조 안에서 귀납 편향만 다른 변종일 수 있다고 주장한다.

시스템 층에서 이 관점을 떠받치는 것은 두 개의 계약이다. 바깥 계약은 모든 프레임워크가 노출하는 forward()(원본 샘플 배치 → 손실 dict)와 predict_action()(같은 관측 형식 → 예측 action chunk) 두 메서드다. 핵심은 학습 입력이 전처리된 dataloader 텐서가 아니라 배포 시 로봇이 실제로 주는 원본 관측과 동일한 형식이라는 점 — train/test 분포 불일치를 애초에 만들지 않겠다는 설계다. 안쪽 계약은 VL backbone(원본 멀티모달 입력 → hidden state)과 action head(hidden state → 모터 명령) 사이의 표현 규격이다. 두 경계가 모두 표준화돼 있으므로 backbone과 head를 각각 독립적으로 교체할 수 있다는 것이 논문이 말하는 양방향 모듈성(bidirectional modularity)이고, 조합은 YAML로 선언한다.

이 추상화 위에 네 가지 대표 패러다임이 구현돼 있다 — StarVLA-FAST(FAST tokenizer로 LLM 어휘 공간에서 이산 action token 자기회귀 생성), StarVLA-OFT(사전 정의된 action token의 hidden state를 읽어 연속 행동을 병렬 회귀, L1 손실), StarVLA-\pi(다층 VL hidden state에 cross-attention으로 조건화된 layer-wise cross-DiT flow-matching action expert), StarVLA-GR00T(VL backbone = System 2 느린 추론, DiT flow matching = System 1 빠른 행동 생성의 이중 시스템).

주요 결과:

• LIBERO(Table 2, 4개 스위트 통합 단일 정책, 스위트당 500 trial) — StarVLA-OFT 96.6% / GR00T 96.5% / \pi 95.7% / FAST 95.4% (모두 Qwen3-VL-4B, 30K steps = 9.54 epochs). 비교군은 OpenVLA-OFT 97.1%(175K steps, 223 epochs), \pi_0 94.1%, GR00T-N1.5 86.5%, \pi_0+FAST 85.5%.
• backbone 교체(Table 2) — Qwen3-VL-4B를 Cosmos-Predict2-2B(비디오 world model)로 갈아 끼워도 OFT 95.8 / \pi 95.5 / GR00T 95.2로 평균 95.2% 이상 유지.
• SimplerEnv(Table 3·4) — WidowX Visual Matching 최고 65.3%(GR00T), Cosmos backbone 최고 61.6%. Google Robot에서 StarVLA-OFT가 VM 76.0 / VA 70.2로 CogACT(74.8 / 61.3)·SpatialVLA(75.1 / 70.7)와 대등하거나 앞섬.
• RoboTwin 2.0(Table 7, 50태스크 단일 정책, 10,000 trial) — StarVLA-OFT clean/random 88.2 / 88.3, GR00T 88.0 / 88.5, \pi 88.1 / 88.8. 비교군 \pi_{0.5} 82.7 / 76.8, Lingbot-VLA 88.6 / 86.7, X-VLA 72.9 / 72.8.
• RoboCasa-GR1(Table 5, 24태스크) — OFT 48.8% > GR00T 47.8 > GR00T-N1.6 47.6 > \pi 43.9 > FAST 39.0 > \pi_{0.5} 37.0. 연속 행동 head가 이산 head를 9.8점 앞선다.
• Generalist(Table 9) — LIBERO·SimplerEnv·RoboTwin·RoboCasa를 합쳐 학습한 단일 모델이 RoboCasa-GR1에서 57.3%, SimplerEnv WidowX 70.2 / Google VA 73.8 / VM 79.3으로 specialist를 상회.
• 학습 비용(Table 10·11) — 8×A100 단일 노드에서 per-GPU batch 8일 때 1.131 s/step, 100K step에 31시간 26분. 256 GPU까지 확장 시 병렬 효율 79~80%로 안정.

결론:

“backbone × action head를 레고처럼 조립한다”는 발상 자체는 새롭지 않지만, VLM 백본과 비디오 world model 백본을 같은 계약 아래 놓고 4종 action head 전부와 교차 평가한 공개 코드베이스는 이전에 없었다는 것이 이 리포트의 실질적 기여다. 성능 수치는 “우리 방법이 낫다”는 주장이라기보다 “최소 가정으로도 여기까지는 나온다”는 재현 가능한 앵커 포인트 성격이 강하고, 실제로 저자들도 그렇게 위치시킨다. 다만 리포트로서의 완성도에는 구멍이 있다 — 통합했다고 선언한 7개 벤치마크 중 결과가 보고된 것은 4개뿐이고, 초록이 내세운 실기 배포는 인터페이스 서술만 있을 뿐 실험이 하나도 없다. Table 9의 LIBERO 평균 열은 자기 행의 산술평균과 맞지 않는다.

---

🔔 Ring Review

🔔 Ring — An idea that echoes. Grasp the core and its value.

한 줄로 시작하면

이 리포트의 진짜 주장은 “우리가 좋은 모델을 만들었다”가 아니라 “VLM 기반과 world model 기반은 애초에 다른 패러다임이 아니었다”이고, 그 주장의 증거는 성능표가 아니라 코드베이스의 존재 자체다. 논리 구조가 흥미롭다 — 보통 논문은 가설을 세우고 실험으로 검증하는데, 여기서는 “하나의 추상화가 두 계열을 모두 담을 수 있는가”라는 질문에 담아 봤더니 담기더라로 답한다. Table 2에서 Qwen3-VL-4B를 Cosmos-Predict2-2B로 바꿔도 평균이 96.6 → 95.8로 0.8점밖에 안 떨어진다는 사실이, “backbone은 교체 가능한 부품이다”라는 명제의 실증이다. 반대로 말하면 이 리포트에서 가장 약한 부분도 같은 자리에 있다 — 추상화가 성립한다는 것은 코드로 보였지만, 그 추상화가 O(n+m)의 비용으로 성립하는지(즉 backbone n개와 head m개를 조합에 비례하는 코드 없이 붙일 수 있는지)는 논문 어디에도 검증돼 있지 않고, 레포를 열어 보면 실제로는 조합마다 파일이 하나씩 있다(아래 코드베이스 대조 노트).

배경: VLA의 바벨탑과 기존 코드베이스 지형

VLA 연구는 두 갈래로 갈라져 왔다. VLM 기반은 언어모델의 표현 능력을 행동 디코딩에 재활용하고, world model 기반은 생성 아키텍처로 행동 분포와 미래 관측을 함께 모델링한다. 두 갈래가 각자의 코드베이스·인터페이스 가정·평가 프로토콜을 갖고 따로 자라면서, 설계 선택 사이의 트레이드오프를 체계적으로 비교하는 일이 사실상 불가능해졌다는 것이 §1의 문제 제기다. 이 진단 자체는 VLA 서베이나 언어 조건 조작 서베이가 나열식으로 보여 준 지형을 엔지니어링 문제로 재정의한 것에 가깝다.

대표 오픈소스 VLA 시스템 비교(Table 1) — 8개 능력 축에서 StarVLA만 전부 채워져 있다. 캡션에 각 열의 정의가 붙어 있다.

Table 1은 8개 축(모듈형 action head / 모듈형 VLM / 모듈형 world-model backbone / 혼합 dataloader / 오픈소스 멀티모달 co-training / 오픈소스 cross-embodiment co-training / 통합 벤치마크 수 / 멀티벤치마크 통합 학습)에서 OpenPI·Isaac-GR00T·OpenVLA-OFT·Dexbotic·X-VLA와 자신을 비교한다. 읽어 보면 지형이 선명하다 — “모듈형 action head” 열은 StarVLA를 제외한 전원이 ✗이고, Dexbotic만 모듈형 VLM과 멀티모달 co-training을 갖췄으며, world model을 VL backbone으로 지원하는 것은 StarVLA뿐이다. 벤치마크 수는 Isaac-GR00T 6, Dexbotic·X-VLA 5, StarVLA 7.

다만 이런 표는 저자가 열을 고를 수 있는 형식이라는 점을 짚고 가야 한다. RCS 리뷰에서도 똑같은 구조의 표(Table I)를 두고 같은 유보를 달았는데, 여기서는 그 성격이 더 강하다 — “모듈형 world model backbone”이라는 열을 세우는 순간 OpenPI·OpenVLA-OFT는 자동으로 진다. 반대로 “실기 배포 검증 사례 수”, “사전학습 체크포인트 공개”, “문서·튜토리얼 성숙도”, “단일 GPU 학습 가능성” 같은 열을 세웠다면 표 모양은 달라졌을 것이다. Table 1은 StarVLA의 설계 의도를 요약한 그림으로 읽는 것이 정확하다.

방법 ①: 통일된 정식화 — 차이를 보조 손실로 환원하기

§2의 정식화는 짧지만 이 리포트의 사상적 중심이다. 정책을

\pi\!\left(\mathbf{a}_{t:t+k},\ \mathbf{y}_{\text{aux}}\ \middle|\ \mathbf{x}_{\leq t},\ \ell\right)

로 쓰면 중간 표현이 추상화되고, 잠재 예측이 있는 경우 그것들이 암묵적으로 주변화된다. 그래서 직접 정책과 모델 기반 접근이 같은 인터페이스로 표현된다. 손실은

\mathcal{L}=\mathcal{L}_{\text{action}}+\mathcal{L}_{\text{aux}}

이고 \mathcal{L}_{\text{aux}}는 표현을 특정 방향으로 형성하는 귀납 편향의 자리다. 언어 정렬 보조 목표를 넣으면 VLM 기반, 미래 관측 예측을 넣으면 world model 기반, 0으로 두면 direct policy가 된다.

이 환원의 값어치를 정확히 매기자면 — 설명력은 크고 예측력은 없다. 기존 방법들이 이 틀에 들어맞는다는 것은 보여 주지만, 어떤 \mathcal{L}_{\text{aux}}가 어떤 상황에서 유리한지에 대한 이론이나 실험은 없다. 논문 스스로도 “관점(perspective)”이라 부르고, 그 근거를 “인프라 차이를 제거하면 공통점이 드러난다”는 경험적 관찰에 둔다. 정직한 서술이라고 본다. 다만 Fig. 1에서 GR00T가 VLM-VLA 칸에 들어가 있는 것처럼 계열 분류가 다소 느슨한 곳이 있고, 셋째 줄 Policy-VLA(ACT·Diffusion Policy·RT-1·HPT·GR-2·Seer)는 §2 본문의 세 가지 분류(Direct/VLM-based/WM-based)와 이름이 정확히 대응하지 않는다.

방법 ②: 두 겹의 계약 — I/O 인터페이스와 backbone–head 분해

같은 인터페이스 아래 구현된 네 가지 행동 디코딩 패러다임(Fig. 2) — 왼쪽부터 FAST(이산 토큰 자기회귀), OFT(CLS 토큰 hidden state → MLP 병렬 회귀), GR00T(VL 출력 1회 조건화 → DiT), \pi(다층 hidden state를 cross-attention으로 DiT에 주입). GR00T와 \pi의 차이가 DiT로 들어가는 화살표 개수로 드러난다.

바깥 계약(forward / predict_action)의 설계 근거가 인상적이다. 논문은 이것을 배포 시점의 불변량으로 정당화한다 — VL foundation model이 어떤 토크나이저를 쓰든, 이미지를 어떻게 리사이즈·분할하든, 사전학습에서 어떤 보조 목표를 최적화했든, 추론 시점에는 결국 로봇이 주는 동일한 원본 센서 스트림을 받아 실행 가능한 모터 명령을 내야 한다. 그 불변량을 시스템의 1급 계약으로 못박으면, “원본 관측을 소비할 수 있는 추론 경로를 가진 모든 VL 모델”이 곧바로 호환된다. 사용자가 모델별 전처리 파이프라인을 역공학할 필요가 없어진다는 것이 실무적 이득이고, 부수 효과로 train/test 분포 불일치라는 조용한 성능 저하 원인이 제거된다.

안쪽 계약은 backbone과 head 사이의 표현 규격이다. 조립은 항상 같은 2단계 — 백본을 먼저 로드하고, action head를 붙인다. 두 경계 모두 표준 계약이므로 학습 파이프라인·벤치마크 하네스·배포 서비스가 backbone·head에 무관하게 유지된다. Fig. 2의 네 변종은 이 계약을 얼마나 다양한 계산 패턴이 견디는지 보여 주는 스트레스 테스트에 가깝다 — 자기회귀 디코딩(FAST)과 이중 시스템(GR00T)은 추론 시점 계산 패턴 자체가 근본적으로 다른데도 같은 인터페이스 아래 공존한다는 것이 논문의 논거다.

여기서 \pi_0 리뷰와 겹쳐 읽으면 재미있는 지점이 하나 있다. Fig. 2에서 StarVLA-\pi는 VL 모델의 여러 층에서 DiT로 화살표가 들어가는데(layer-wise cross-attention), StarVLA-GR00T는 화살표가 하나다. 원 논문 \pi_0는 action expert를 VLM과 같은 트랜스포머 안에 섞어 넣는 구조였으므로, StarVLA-\pi는 “\pi_0의 재구현”이라기보다 \pi_0의 아이디어를 이 코드베이스의 계약에 맞게 번역한 변종으로 읽는 것이 정확하다. 리포트가 “re-implementations that match or in some cases exceed reported performance”라고 쓴 대목은 이 번역이 성능을 깎지 않았다는 뜻이지, 구조가 동일하다는 뜻은 아니다.

방법 ③: 시스템 파이프라인 — 학습 세 갈래와 서버-클라이언트 평가

StarVLA 전체 파이프라인(Fig. 3) — 왼쪽 이질적 데이터 소스와 pluggable dataloader, 가운데 build_framework(cfg) → forward()/predict_action(), 오른쪽 학습(Accelerate + DeepSpeed)과 테스트/배포(Policy Server → 시뮬 평가 / 실기 제어).

학습은 명시적 PyTorch 루프 위에 Accelerate + DeepSpeed로 구현되고, YAML 설정 인터페이스가 모든 방법에 공통이다. 세 가지 정규 모드와 한 가지 예고가 있다.

모드	구현	요지
지도학습 SFT	training/train_starvla.py	프레임워크 forward()가 반환하는 action loss만 최적화. 전체 파인튜닝 또는 trainer.freeze_modules로 선택적 동결, 서브모듈별 학습률 분리(qwen_vl_interface vs action model), bf16 autocast·gradient accumulation·clipping·최소 학습률 cosine 스케줄
멀티모달 co-training	training/train_starvla_cotrain.py	dataloader 두 개(VLA·VLM), 최적화 스텝당 forward/backward 2회. VLM 손실은 trainer.loss_scale.vlm으로 가중 → 행동 학습과 VLM 능력 보존의 트레이드오프를 계수 하나로 조절
cross-embodiment co-training	datasets.vla_data.data_mix	(데이터셋명, 샘플링 가중치, 로봇 타입) 튜플 리스트를 이름으로 선택 → 런타임에 LeRobotMixtureDataset으로 실체화. “cross-embodiment 사전학습”이 별도 스크립트가 아니라 설정 항목이 된다
RL 파인튜닝	(미구현)	RLinf 프로젝트와 협업해 지원 예정. 리포트 작성 시점 공개 코드베이스는 지도학습·co-training만

평가 쪽 설계도 실용적이다. 체크포인트를 baseframework.from_pretrained()로 로드해 경량 WebSocket policy server로 띄우고, 벤치마크 평가기는 자기 시뮬레이터 의존성을 가진 별도 conda 환경에서 얇은 클라이언트로 붙는다. 페이로드는 msgpack으로 직렬화되고, image·lang + 선택적 state·타임스탬프가 dict 하나로 오간다. 통신 계약이 action head에 무관하므로 OFT → FAST → \pi → GR00T 전환에 벤치마크 코드를 손댈 필요가 없다.

벤치마크별 차이는 model2libero_interface.py·model2simpler_interface.py·model2robotwin_interface.py 같은 얇은 어댑터 파일에 격리된다. 이 어댑터들이 실제로 하는 일 — 학습 해상도로 이미지 리사이즈, 체크포인트 디렉터리의 dataset_statistics.json을 읽어 행동 역정규화, chunk 예측을 실행 가능한 행동으로 변환, action ensembling 적용, sticky gripper나 delta↔︎absolute 변환 같은 벤치마크 고유 관례 처리 — 는 VLA를 실제로 굴려 본 사람이라면 성능의 절반이 여기서 갈린다는 것을 아는 항목들이다. 이걸 코드로 공개했다는 점이 이 리포트의 가장 실질적인 기여일 수 있다. 같은 문제를 통합 시뮬레이션 플랫폼 쪽에서 접근한 것이 RoboVerse이고, 로봇 스택(제어·미들웨어) 쪽에서 접근한 것이 RCS다. StarVLA는 정책 모델 쪽에서 같은 파편화를 공격한다.

실기 배포는 같은 클라이언트-서버 계약의 연장으로 서술된다 — 로봇 컨트롤러가 벤치마크 클라이언트 역할을 맡아 카메라 관측을 모아 같은 dict를 만들고, 원격 policy server에 질의해 받은 행동을 하드웨어에서 실행한다. 제어 루프·안전 로직·벤더 SDK/ROS 노드는 StarVLA 런타임 바깥에 남고, 모델 스택은 GPU 지향 추론 환경에 그대로 있는다. 시뮬레이션과 실기가 동일한 체크포인트를 쓴다는 것이 논지다.

벤치마크 통합: 세 부품으로 정의된 온보딩 규약

각 벤치마크 통합은 세 부품으로 구조화된다 — ① config.yaml과 dataset_statistics.json을 담은 체크포인트 패키지, ② 실행 가능한 학습 진입점(examples/<BENCH>/train_files/의 YAML + 실행 스크립트), ③ policy server를 띄우고 공식 평가기를 그대로 호출하는 평가 워크플로(examples/<BENCH>/eval_files/). 원칙은 “공식 워크플로에 최대한 붙고, 정책 쪽 인터페이스만 표준화한다”이다.

§4.2가 소개하는 벤치마크는 7개다.

벤치마크	규모(논문 서술)	결과 보고
LIBERO	130 태스크 / 4 스위트, 태스크당 50 데모 ≈ 6.5K 궤적	✅ Table 2
SimplerEnv	WidowX(BridgeData V2)·Google Robot(RT 계열), Visual Matching / Variant Aggregation	✅ Table 3·4
RoboCasa-GR1	24 태스크, 태스크당 ≈1,000 데모 ≈ 24K 궤적	✅ Table 5·6
RoboTwin 2.0	50 태스크 × (clean 50 + randomized 500) ≈ 27.5K 궤적, 평가 10,000 trial	✅ Table 7
LIBERO-Plus	테스트 전용, 7개 교란 요인 · 21개 저수준 구성요소 · 10,030 태스크	❌ 없음
BEHAVIOR-1K	1,000 활동 / 50 씬 / 9,000+ 객체. BEHAVIOR Challenge는 50 태스크 · 10,000 데모(1,200시간+), 태스크당 200개 학습 공개	❌ 없음
CALVIN	4 환경(A–D) / 34 태스크, ABC→D 설정에서 길이 5 시퀀스 1,000개	❌ 없음

결과가 있는 것은 4개뿐이다. 특히 LIBERO-Plus는 “분포 변화에서의 강건성”을 재는 테스트 전용 벤치마크라 학습이 전혀 필요 없는데도 수치가 없다. LIBERO에서 96%대를 내는 정책이 LIBERO-Plus에서 얼마나 무너지는지는 이 코드베이스가 가장 값싸게 답할 수 있는 질문이었고, 그게 빠진 것이 이 리포트에서 가장 아쉬운 공백이다.

실험 ①: 단일 벤치마크 SFT — “최소 가정 앵커”

실험 절의 프레이밍이 명확하다. VLA 특화 사전학습(대규모 로봇 혼합 데이터), 데이터 증강, DAgger류 온라인 정제를 의도적으로 전부 배제하고, 공개된 VL 사전학습 가중치에서 시작해 벤치마크 표준 데모셋만으로 파인튜닝한다. 목적은 SOTA 경쟁이 아니라 추가 사전학습·증강·co-training의 한계 효용을 재는 기준점을 세우는 것이다.

LIBERO 결과(Table 2) — 4개 스위트에 단일 정책, 스위트당 500 trial(10 태스크 × 50 에피소드). 아래 두 블록이 Qwen3-VL-4B와 Cosmos-Predict2-2B 백본이다.

LIBERO 셋업은 그대로 재현 레시피로 쓸 수 있게 적혀 있다 — LeRobot 포맷 원본 샘플 dict(3인칭 + 손목 RGB, 고유수용감각·히스토리 스태킹·이미지 증강 없음), 출력은 action chunking = 8의 연속 EEF 행동 벡터, 8×A100(Accelerate + DeepSpeed ZeRO-2), per-device batch 16, 100K step 학습에 10K step마다 체크포인트.

수치를 읽을 때 주의할 점이 둘 있다. 첫째, “6배 적은 step, 23배 적은 epoch”라는 비교는 학습 대상이 다르다. StarVLA는 4개 스위트를 합쳐 단일 정책을 학습하는데(캡션 명시), OpenVLA-OFT의 175K step / 223 epoch가 스위트별 정책인지 통합 정책인지 리포트는 밝히지 않는다. 통합 학습이면 epoch 하나가 4배 큰 데이터를 도는 것이므로 epoch 비교는 그대로 성립하지 않는다. 산술 자체는 맞다(175K/30K ≈ 5.8, 223/9.54 ≈ 23.4). 둘째, 체크포인트 선택 방식이 “평균 성공률이 가장 좋은 가장 이른 체크포인트”다. 평가 지표로 체크포인트를 고르는 것은 VLA 관행이지만, 그 결과 Table 3에서 StarVLA 변종들의 step이 15K·65K·40K·20K로 제각각이 된다. “모든 조건을 고정하고 한 가지 설계 선택만 격리한다”는 이 코드베이스의 핵심 명분이 정작 head 비교 실험에서는 지켜지지 않은 셈이다.

Cosmos backbone 블록에서 하나 더 눈에 띄는 것이 있다. Table 2와 Table 3 모두 Cosmos-Predict2-2B 블록에는 OFT·\pi·GR00T만 있고 FAST가 없다. 본문은 이 부재를 언급하지 않는다. 이유를 추론하기는 어렵지 않다 — FAST head는 LLM 자신의 어휘 공간에서 이산 action token을 자기회귀 생성하는데, 비디오 world model에는 그 어휘·언어모델 디코더가 없다. 즉 “backbone과 head를 각각 독립 교체”라는 명제에는 구조적 예외가 있고, 그 예외가 표에 침묵으로만 나타난다. 이 관찰은 아래 코드 대조에서 정확히 확인된다. Cosmos predict/transfer 2.5 리뷰에서 본 것처럼 Cosmos 계열은 텍스트 인코더 + VAE + DiT 구성이라 LLM 디코더가 없다.

나머지 세 벤치마크는 이렇게 정리된다.

• SimplerEnv(16×A100, per-device batch 16, Bridge + Fractal 병합) — 평가 분산이 크다는 점을 인정하고 각 설정을 5회 재실행해 평균을 보고한다. 이 리포트에서 반복 측정을 명시한 유일한 벤치마크다. WidowX에서 가장 구조화된 태스크(Put Eggplant in Yellow Basket)는 100.0%가 여럿 나오는 반면 Stack Green Block on Yellow Block은 최고 30.2%로, 태스크 간 편차가 방법 간 편차보다 크다.
• RoboCasa-GR1(16×A100, 24 태스크 단일 정책, 태스크당 50 rollout) — LIBERO·SimplerEnv보다 확실히 어렵고, action head 선택이 가장 크게 갈리는 벤치마크다. 이산 FAST 39.0 vs 연속 계열 43.9~48.8. Table 6의 태스크별 표를 보면 편차 원인이 보인다 — PnPCanToDrawerClose에서 GR00T-N1.6은 13.0인데 StarVLA-GR00T는 80.0, 반대로 PnPPotatoToMicrowaveClose는 41.5 vs 28.0. 평균이 비슷해도(47.6 vs 47.8) 태스크별로는 완전히 다른 정책이라는 뜻이고, 이런 표를 낼 수 있다는 것 자체가 통합 평가 인프라의 값어치다.
• RoboTwin 2.0(48×A100, per-device batch 4, 150K step, 50 태스크 단일 정책) — 네 변종 모두 clean/random 88%대로 수렴하고 randomized가 clean보다 높은 경우도 나온다(FAST 72.5 → 83.2). RoboTwin 2.0 리뷰에서 본 대로 randomized 셋은 태스크당 데모가 10배(500 vs 50) 많으므로, 이 역전은 강건성보다 데이터 양의 효과로 읽는 것이 자연스럽다. 리포트는 이 해석을 달지 않는다.

실험 ②: 멀티모달 co-training — 망각을 계수 하나로 막기

co-training 전략별 지각-행동 공동 최적화 동역학(Fig. 4) — (a) RefCOCO-g IoU@0.5, (b) SimplerEnv WidowX 성공률, (c) 공간 grounding과 행동 목표 사이의 gradient subspace 정렬(PSS). ST4VLA 연구에서 가져온 그림이다.

동기는 명확하다 — 사전학습된 VLM을 행동 예측에만 파인튜닝하면 수천 스텝 만에 시각·언어 능력을 잊는다. 그 결과 객체 grounding·지시 따르기·장면 이해가 함께 무너지는데, 이것들은 강건한 조작의 전제조건이다.

Fig. 4가 이 붕괴를 그림 하나로 보여 준다. Vanilla VLA의 RefCOCO-g IoU@0.5는 20K step 안에 거의 0으로 떨어진다(그림에서 읽으면 시작 ≈55에서 20K 이후 바닥에 붙는다). Vanilla co-training은 부분적으로 지키지만 불안정하게 진동하고(20K 부근 ≈21까지 떨어졌다 회복), 공간 유도 변종 ST4VLA만 ≈70 수준의 안정적 고원을 유지한다. (c) 패널의 PSS(projection matrix similarity)는 두 목표의 gradient 부분공간 정렬을 재는데, vanilla co-training은 0.5 근처에서 시작해 0.20 부근으로 급락하며 심하게 요동치는 반면 ST4VLA는 0.40대에서 완만하게 내려간다.

Table 8의 정량 결과는 이렇다. Vanilla co-training만으로도 조작 성능이 오르고(Google Robot VM 66.1 → 70.2 = +4.1, WidowX 54.7 → 61.1 = +6.4) 멀티모달 능력이 회복되며(MME 1106, RefCOCO-g IoU@0.5 47.1), 공간 사전학습까지 더한 최종 행은 Google Robot VM/VA 84.6 / 75.9, WidowX 73.2, RefCOCO-g 71.2에 이른다. 흥미로운 것은 이 최고치가 단일 벤치마크 SFT의 SimplerEnv 결과(WidowX 65.3, Google VM 76.0)를 크게 웃돈다는 점이다 — co-training이 “능력 보존”만이 아니라 성능 자체를 끌어올린다는 증거로 읽힌다.

다만 이 절의 실험은 StarVLA의 실험이 아니다. Fig. 4와 Table 8은 모두 ST4VLA(Ye et al., 2026a, arXiv:2602.10109 — StarVLA 제1저자가 이끄는 동반 연구)에서 재현한 것이고, 리포트도 그렇게 명시한 뒤 자세한 내용은 그 논문을 보라고 넘긴다. 즉 세 기여 중 “재사용 가능한 학습 전략”의 실증은 코드베이스가 그 연구를 가능하게 했다는 간접 증거이지, 이 리포트가 직접 측정한 것이 아니다. 인프라 논문으로서는 정당한 논법이지만(“우리 위에서 연구가 나왔다”), 독자가 co-training 계수 loss_scale.vlm을 어떻게 잡아야 하는지에 대한 정보는 여기서 얻을 수 없다.

실험 ③: generalist — 벤치마크 경계를 지우면 어떻게 되는가

generalist vs specialist 비교(Table 9) — 위 다섯 행은 벤치마크별로 따로 학습한 specialist, 마지막 행은 4개 벤치마크를 합쳐 한 번 학습한 단일 모델.

셋업은 간단하다 — LIBERO·SimplerEnv·RoboTwin 2.0·RoboCasa-GR1의 학습셋을 병합해 한 모델을 학습하고, 각 벤치마크 공식 프로토콜로 추가 파인튜닝 없이 바로 평가한다. 학습률 1\times10^{-4}, 총 배치 256. 임보디먼트 간 행동 공간 차이는 태스크별 action head를 쓰지 않고 저-DoF 행동을 32차원 공용 벡터로 패딩하는 단순한 방식으로 흡수한다.

결과의 핵심은 RoboCasa-GR1이다 — §7.2 본문 기준으로 specialist 최고 48.8%(§5.3 Table 5의 값)에서 generalist 57.3%로 8.5점 뛴다(단 Table 9 안의 최고 specialist는 53.8이라 그 기준이면 3.5점이다 — 아래 검산 참조). SimplerEnv도 WidowX 70.2 / Google VA 73.8 / VM 79.3으로 모든 specialist보다 높다. LIBERO는 97.8로 소폭 하락, RoboTwin은 clean* 88.7 / random* 87.8로 사실상 동률. 가장 데이터가 적고 어려운 벤치마크가 가장 크게 이득을 본다는 패턴이고, cross-embodiment 사전학습의 전형적 거동과 일치한다.

다만 이 표는 인용하기 전에 검산이 필요하다. LIBERO 블록의 avg 열을 자기 행의 네 스위트로 직접 평균해 보면 6행 중 4행이 어긋난다.

행	Spatial	Object	Goal	Long	보고된 avg	직접 계산
\pi_{0.5}	98.8	98.2	98.0	92.4	96.9	96.85 ✅
GR00T-N1.6	97.5	98.5	97.5	94.4	94.1	96.98 ❌
StarVLA-\pi	98.0	99.2	98.2	93.6	98.1	97.25 ❌
StarVLA-GR00T	98.9	99.6	98.4	95.3	98.7	98.05 ❌
StarVLA-OFT	99.0	99.8	98.5	94.1	98.8	97.85 ❌
StarVLA (generalist)	98.7	99.7	98.6	94.2	97.8	97.80 ✅

게다가 Table 9의 specialist 수치는 §5의 같은 모델 수치와도 다르다 — StarVLA-OFT의 LIBERO 평균이 Table 2에서는 96.6인데 Table 9에서는 98.8이고, RoboCasa는 Table 5에서 48.8인데 Table 9에서는 53.8이다. 그런데 §7.2 본문은 “최고 specialist 평균 48.8%에서 57.3%로 올랐다”고 쓴다 — 자기 표의 최고 specialist(53.8)가 아니라 다른 절의 표(48.8)를 인용해 개선폭을 계산한 것이다. Table 9 안에서만 계산하면 개선폭은 8.5점이 아니라 3.5점이다. 어느 쪽이 맞는지 리포트에 설명이 없으므로, 이 리뷰에서는 두 수치를 모두 적어 두고 독자가 원문과 대조할 근거를 남긴다. (같은 부류의 문제가 Table 3에도 하나 있다 — \pi_0-FAST의 WidowX 행 29.1 / 21.9 / 10.8 / 66.6의 평균은 32.1인데 Average 열은 48.3이다. 베이스라인 수치라 원 논문에서 다른 집계 규칙으로 옮겨 왔을 가능성이 있지만, 같은 표의 다른 행은 전부 단순 평균과 일치한다.)

실험 ④: 계산 비용 — 이 코드베이스를 돌리려면 무엇이 필요한가

단일 8-GPU 노드 학습 효율(Fig. 5) — 왼쪽은 per-GPU batch에 따른 step 지연(A100·H200), 오른쪽은 8×A100의 throughput과 GPU 사용률. 왼쪽 그림에만 있는 값: per-GPU batch 32, 8×H200에서 StarVLA 0.78 s/step vs LingBot-VLA 1.12 vs Dexbotic 1.98.

이 절이 재현을 고민하는 사람에게 가장 실용적이다. 측정은 StarVLA-GR00T + Qwen3-VL-4B를 RoboCasa-GR1 데이터로 A100 80GB에서 학습한 기준이고, 원 데이터가 GitHub 이슈 #158의 공개 프로파일링이라는 점을 명시한다.

단일 노드 8×A100(Table 10): per-GPU batch 2 → 0.703 s/step · 22.7 samples/s · GPU util 74%, batch 8 → 1.131 s/step · 56.6 samples/s · 92%, batch 24 → 2.404 s/step · 79.9 samples/s · 96%. 100K step 기준 실측 시간은 각각 19:32:17 / 31:25:38 / 66:47:02. 즉 batch 24는 사용률을 96%까지 올리지만 step 지연을 3.4배로 부풀린다(검산: 2.404/0.703 = 3.42 ✅).

멀티 노드(Table 11, per-GPU batch 8 고정): 8 GPU 0.735 s/step · 87.0 samples/s(100%) → 32 GPU 0.899 · 284.7(81.9%) → 256 GPU 0.931 · 2200.0(79.1%). 노드 간 통신이 한 번의 고정 오버헤드(0.735 → 0.93)만 물리고 그 뒤로는 더 나빠지지 않는다는 것이 핵심 메시지다.

실험에 실제로 쓰인 하드웨어를 모으면 규모가 드러난다 — LIBERO 8×A100, SimplerEnv 16×A100, RoboCasa-GR1 16×A100, RoboTwin 2.0 48×A100. RoboTwin 기준 150K step을 위 표의 8-GPU 실측(0.735 s/step)으로 대충 환산하면 48 GPU에서도 하루 단위 작업이다. “진입 장벽을 낮춘다”는 리포트의 목표와 이 하드웨어 요구는 솔직히 긴장 관계에 있다 — 낮아지는 것은 코드를 짜는 장벽이지 실험을 돌리는 장벽이 아니다. 단일 GPU나 4-GPU 환경에서 무엇을 할 수 있는지에 대한 안내는 리포트에 없다.

🔧 코드베이스 대조 노트

아래는 논문의 주장이 아니라 필자가 공개 레포(starVLA/starVLA, 브랜치 starVLA_dev)를 2026-08-13에 직접 열어 확인한 구조다. 모델을 학습시키거나 성능을 재현한 것이 아니고, 디렉터리 구조와 파일 내용을 읽은 수준의 확인이다. 논문 수치는 이 노트로 검증되지 않는다.

논문이 이름을 밝힌 파일들은 실재한다 — starVLA/training/에 train_starvla.py·train_starvla_cotrain.py가 있고(추가로 train_starvlm.py·train_starvln.py), starVLA/model/framework/base_framework.py가 공통 기반 클래스다. 프레임워크 파일을 열어 보면 forward()와 predict_action() 두 메서드가 실제로 계약을 이루고 있다.

① 벤치마크·실기 지원은 논문보다 레포가 앞서 있다. examples/simBenchmarks/에는 13개 디렉터리가 있다 — Behavior, DOMINO, LIBERO, LIBERO-plus, MetaWorld, RoboDojo, Robocasa_365, Robocasa_tabletop, Robotwin, SimplerEnv, VLA-Arena, VLN-CE, calvin. examples/realRobots/에는 EgoVLA·Franka·Realman·RoboChallenge_table30v2·UnitreeG1_WholeBody 5종이 있다. 논문이 “actively maintained and expanded; we will update this report”라 쓴 그대로다. 리포트의 Table 1(#Bench = 7)은 이미 낡았다고 보는 게 맞다.

② 추상화는 “조합마다 파일 하나”로 구현돼 있다. starVLA/model/framework/는 세 갈래로 나뉜다 — VLM4A/(VLM backbone), WM4A/(world model backbone), VM4A/(비전 전용: ACT·DiffusionPolicy). 그런데 그 안의 파일명이 backbone × head의 곱이다.

	FAST	OFT	\pi	GR00T
Qwen	QwenFast.py	QwenOFT.py	QwenPI.py	QwenGR00T.py
Gemma4	—	—	Gemma4PI.py	Gemma4GR00T.py
MiniCPM	—	—	MiniCPMPI.py	MiniCPMGR00T.py
Cosmos-Predict2 (WM)	—	CosmoPredict2OFT.py	CosmoPredict2PI.py	CosmoPredict2GR00T.py
Wan2.2 (WM)	—	WanOFT.py	WanPI.py	WanGR00T.py

두 가지가 바로 읽힌다. 첫째, world model 백본 쪽에 FAST 구현이 없다 — Table 2·3의 Cosmos 블록에 FAST 행이 빠진 이유가 코드에서 확인된다(이산 action token을 LLM 어휘로 생성하는 head라 언어모델 디코더가 없는 백본에는 붙지 않는다). 논문은 이 구조적 예외를 서술하지 않는다. 둘째, 조합 수만큼 파일이 늘어난다. 파일 크기도 얇은 어댑터 수준이 아니다(4.5~17KB, WanOFT.py는 250줄).

③ 실제로 두 world-model 프레임워크는 거의 복제본이다. WanOFT.py와 CosmoPredict2OFT.py는 바이트 수가 9,671로 동일하다. diff를 떠 보면 차이는 ⓐ docstring의 백본 이름, ⓑ 체크포인트 경로(Wan2.2-TI2V-5B-Diffusers ↔︎ Cosmos-Predict2-2B-Video2World), ⓒ hidden 차원(3072 ↔︎ 2048), ⓓ 클래스·레지스트리 이름뿐이다. 즉 “백본을 갈아 끼운다”는 조작이 설정 변경이 아니라 프레임워크 파일을 복사해 상수 몇 개를 고치는 일로 구현돼 있다. 게다가 두 파일 모두 설정 필드 이름이 qwenvl로 남아 있고, Wan 쪽 데모 코드는 cfg.framework.qwenvl.base_vlm에 Wan 체크포인트 경로를 넣는다 — 공유 설정 스키마가 아직 Qwen 시절의 이름을 그대로 물고 있다는 뜻이다.

이 관찰은 논문을 깎으려는 것이 아니라 추상화의 성숙도를 정확히 표시하기 위한 것이다. 계약(forward/predict_action, backbone→hidden→action 경계)은 실재하고 작동한다. 하지만 리포트가 “backbone and action head can each be replaced independently”라고 쓸 때 독자가 상상하는 것 — YAML에서 backbone 항목 한 줄만 바꾸면 되는 조합적 자유 — 과 현재 구현 사이에는 거리가 있다. 새 backbone B를 추가하려면 지원하려는 head 수만큼 프레임워크 파일을 써야 한다.

비판적으로 보면

강점

• 파편화를 “연구 문제”가 아니라 “인터페이스 문제”로 재정의한 것. \mathcal{L}=\mathcal{L}_{\text{action}}+\mathcal{L}_{\text{aux}}와 두 겹의 계약(원본 관측 I/O, backbone→hidden→action)은 단순하지만, 이 단순함 덕분에 자기회귀 디코딩부터 이중 시스템까지 추론 시점 계산 패턴이 근본적으로 다른 방법들이 한 지붕 아래 들어간다. 계약을 “배포 시점 불변량”에서 도출한 논증은 특히 설득력 있다.
• VLM 백본 ↔︎ world model 백본의 직접 비교를 처음으로 통제된 조건에서 제공한다. Qwen3-VL-4B → Cosmos-Predict2-2B 교체에도 LIBERO 평균이 95.2% 이상 유지된다는 결과는, 두 계열의 우열보다 “백본은 교체 가능한 부품”이라는 명제 자체가 성립함을 보여 준다. 이런 실험은 통합 코드베이스 없이는 애초에 불가능하다.
• 평가 인프라의 실질적 공개. policy server / 벤치마크 클라이언트 분리로 시뮬레이터 의존성 지옥을 프로세스 경계로 잘라낸 것, 그리고 어댑터가 담당하는 실무 항목들(행동 역정규화, action ensembling, sticky gripper, delta↔︎absolute 변환)을 코드로 낸 것. VLA 재현이 실패하는 지점의 상당 부분이 여기라는 걸 아는 사람에게는 성능표보다 값어치가 크다.
• 결과가 “최소 가정 앵커”로 정직하게 프레이밍된다. 사전학습·증강·DAgger를 전부 배제하고, 무엇을 쓰지 않았는지 명시하고, 재현 스크립트 경로를 적는다. LIBERO 30K step으로 96.6%가 나온다는 사실은 “이 정도는 인프라만 제대로 갖춰도 나온다”는 기준선을 세워 준다.
• Table 6 같은 태스크별 표를 낼 수 있다는 것 자체가 인프라의 증거다. 평균이 47.6 vs 47.8로 같아 보이는 두 모델이 태스크 수준에서는 13.0 vs 80.0으로 갈린다는 관찰은, 통합 평가 없이는 아무도 볼 수 없다.

약점·한계

• 실기 배포 결과가 하나도 없다. 초록과 §3.2.2가 “simulation and real-robot deployment”를 통합 인터페이스의 핵심 이점으로 내세우지만, 리포트 전체에 실기 실험 수치가 없다. 서술은 “같은 체크포인트를 시뮬과 실기에 쓸 수 있다”는 설계 논증에 머문다. 레포에는 실기 예제 5종이 있으므로 데이터가 없는 것은 아닐 텐데, 리포트에서는 측정되지 않고 선언만 된 항목이다.
• 통합했다는 7개 벤치마크 중 4개만 결과가 있다. 특히 학습이 필요 없는 테스트 전용 강건성 벤치마크 LIBERO-Plus의 부재가 뼈아프다. LIBERO 96%가 분포 변화에서 얼마나 유지되는지가 이 코드베이스의 가장 값싼 기여였을 것이다. BEHAVIOR-1K·CALVIN도 소개만 되고 비어 있다.
• Table 9의 산술이 맞지 않는다. LIBERO avg 열이 자기 행의 네 스위트 평균과 6행 중 4행에서 어긋나고(위 검산표), specialist 수치가 §5의 같은 모델 수치(Table 2의 96.6, Table 5의 48.8)와도 불일치하며, §7.2 본문은 자기 표가 아니라 다른 절의 값을 인용해 개선폭을 계산한다. Table 3의 \pi_0-FAST WidowX 평균(48.3 vs 계산값 32.1)도 같은 부류다. 리포트의 헤드라인 수치를 인용할 때는 어느 표에서 왔는지를 반드시 밝혀야 한다.
• “통제된 비교”라는 명분이 head 비교 실험에서 지켜지지 않는다. 체크포인트를 “평균 성공률이 가장 좋은 가장 이른 것”으로 고르기 때문에 Table 3의 네 변종이 15K·65K·40K·20K로 서로 다른 step에서 비교된다. 코드베이스의 존재 이유가 “다른 모든 것을 고정하고 하나만 바꾸는 것”이라면, 이 실험은 그 기준을 자기가 어긴 셈이다. 또한 평가 지표로 체크포인트를 고르는 것은 사실상 테스트셋 선택이므로, 보고된 수치는 낙관 편향을 갖는다.
• 모듈성 주장에 구조적 예외가 있고 그 예외가 침묵으로 처리된다. world model 백본에는 FAST head가 붙지 않는다(표에서 행 부재, 코드에서 파일 부재로 이중 확인). “각각 독립 교체”라는 문장은 head 종류에 따라 백본 종류가 제한된다는 단서를 달아야 정확하다.
• 추상화의 비용이 보고되지 않는다. 위 코드 대조 노트에서 본 것처럼 조합마다 프레임워크 파일이 하나씩 있고, 서로 다른 백본의 같은 head 구현이 사실상 복제본이다(WanOFT.py ↔︎ CosmoPredict2OFT.py가 바이트 수까지 동일). 인프라 논문이라면 “새 backbone 하나를 붙이는 데 몇 줄이 필요한가”, “새 head 하나는?” 같은 수치가 성능표보다 중요한데, 그런 측정이 없다. 리포트가 반복하는 “lightweight adapter”라는 표현도 정량화되지 않는다.
• 하드웨어 요구가 “진입 장벽 완화”라는 목표와 어긋난다. 실험에 8~48×A100이 쓰였고, 단일 GPU·소규모 환경에서 무엇이 가능한지에 대한 안내가 없다. 효율 절의 측정도 GitHub 이슈에 올라온 커뮤니티 프로파일링을 근거로 하며, 통제된 실험 조건(데이터로더 병목 여부, 시퀀스 길이, 저장 방식)은 서술되지 않는다.
• 세 기여 중 하나(재사용 가능한 학습 전략)의 실증이 외부 논문에서 왔다. co-training 절의 Fig. 4·Table 8은 전부 ST4VLA(같은 팀의 동반 논문)에서 재현한 것이고, 이 리포트가 직접 측정한 co-training 실험은 없다. cross-embodiment co-training은 §3.1.3에서 설정 항목으로 서술될 뿐 단독 실험이 없고, generalist 실험(§7)이 그 역할을 대신하지만 그건 “벤치마크 혼합”이지 “이질적 로봇 데이터 혼합”의 통제된 검증은 아니다.
• RL 파인튜닝은 예고 상태다. §3.1.4가 RLinf와의 협업을 언급하지만 “ongoing integration effort”이고 현재 공개 코드베이스에는 없다. Table 1의 능력 매트릭스에는 이 축이 아예 없다.
• 비교 대상 코드베이스의 능력 판정이 저자 자평이다. Table 1의 ✗/✓는 각 프로젝트를 언제 기준으로, 어떤 근거로 판정했는지 밝히지 않는다. 특히 Dexbotic·X-VLA처럼 활발히 개발되는 프로젝트는 판정 시점에 따라 결과가 달라진다.

관련 연구와의 자리 매김

같은 파편화, 다른 층위. 최근 1~2년 사이 “로봇 학습의 파편화를 인프라로 풀자”는 논문이 층위별로 나오고 있다. RoboVerse는 시뮬레이터·데이터셋·벤치마크 층에서, RCS는 로봇 제어 스택·미들웨어 층에서 같은 문제를 공격한다. StarVLA는 정책 모델 아키텍처 층이다. 셋은 경쟁이 아니라 스택의 다른 높이에 있고, 실제로 StarVLA는 RoboVerse가 다루는 벤치마크들(LIBERO·RoboCasa·CALVIN·BEHAVIOR)을 소비하는 쪽에 선다. 재미있는 것은 세 논문 모두 Table 1/I에 자기만 전부 ✓인 능력 매트릭스를 싣는다는 점이다 — 인프라 논문의 장르적 관습에 가깝고, 독자는 그 표를 우열이 아니라 설계 의도의 요약으로 읽어야 한다.

모델 계보와의 관계. StarVLA의 네 변종은 각각 원 논문의 재구현이다 — FAST(Pertsch et al., 2025), OFT(OpenVLA-OFT, Kim et al., 2025), \pi(\pi_0, Black et al., 2024), GR00T(GR00T N1.5, Bjorck et al., 2025). 백본 쪽은 Qwen3-VL-4B와 Cosmos-Predict2-2B이고, 레포에는 Wan2.2·Gemma4·MiniCPM·Molmo2·VILA·Florence2도 들어와 있다. 즉 이 리포트는 새 계보를 만들지 않고 기존 계보들의 교점에 서기를 선택했다. MolmoAct2나 SmolVLA처럼 “하나의 좋은 VLA”를 내는 논문과는 목적이 다르고, 오히려 그 논문들이 StarVLA 위에서 재구현·비교되는 것이 이 프로젝트가 바라는 그림이다.

벤치마크 쪽과의 관계. 통합 대상인 RoboTwin 2.0은 도메인 랜덤화로 강건성을 재는 양팔 벤치마크인데, StarVLA가 clean/random 양쪽에서 88%대를 내면서 벤치마크의 난이도 자체가 재조정되는 국면이 왔다. 반대로 RoboCasa-GR1은 40%대에 머물러 있어 현재 VLA의 실질적 한계선을 보여 준다. 이런 “어느 벤치마크가 아직 살아 있는가”에 대한 판단도 통합 평가가 있어야 가능한 것이다.

같은 팀의 동반 연구. ST4VLA(Ye et al., 2026a)는 이 코드베이스 위에서 공간 유도 co-training을 다룬 별도 논문이고, 이 리포트의 co-training 절 근거 전부가 거기서 왔다. “플랫폼 논문 + 그 위의 연구 논문”이라는 짝이 명시적으로 설계돼 있다는 점은, 이 프로젝트를 논문 하나가 아니라 연구 프로그램으로 봐야 한다는 신호다.

요약

StarVLA는 “VLA 연구의 파편화”라는 널리 공유된 불만을 코드로 답한 기술 리포트다. 기여를 정확히 매기면 이렇다. ① VLM 기반과 world model 기반 VLA를 \mathcal{L}=\mathcal{L}_{\text{action}}+\mathcal{L}_{\text{aux}}라는 하나의 정식화와 두 겹의 계약(원본 관측 I/O, backbone→hidden→action) 아래 놓고, 4종 action head를 실제로 교차 구현했다. ② 사전학습·증강 없이 공개 가중치에서 시작하는 최소 가정 베이스라인을 4개 벤치마크에서 재현 스크립트와 함께 냈다(LIBERO 96.6, SimplerEnv WidowX 65.3, RoboTwin 88.2/88.3, RoboCasa-GR1 48.8). ③ 4개 벤치마크를 합쳐 학습한 단일 generalist가 어려운 벤치마크에서 오히려 더 낫다는 것(RoboCasa 57.3)을 보였다.

한계도 분명하다. 실기 배포는 선언만 되고 측정되지 않았으며, 통합했다는 7개 벤치마크 중 3개(LIBERO-Plus·BEHAVIOR-1K·CALVIN)는 결과가 비어 있다. Table 9는 산술이 맞지 않아 그대로 인용하기 어렵고, head 비교는 서로 다른 step의 체크포인트를 놓고 이뤄진다. 모듈성 주장에는 구조적 예외(world model 백본 + FAST 불가)가 침묵으로 처리돼 있고, 추상화의 비용 — 새 백본·헤드를 붙이는 데 드는 실제 작업량 — 은 측정되지 않는다. 레포를 열어 보면 그 비용이 조합마다 파일 하나의 형태로 드러난다.

그럼에도 이 리포트가 값어치 있는 이유는 판단의 기준이 다르기 때문이다. 모델 논문은 수치로 평가되지만 인프라 논문은 그 위에서 다른 연구가 나오는가로 평가된다. 그 기준에서 StarVLA는 이미 답을 냈다 — ST4VLA가 이 위에서 나왔고, 레포는 리포트가 서술한 7개를 넘어 13개 시뮬 벤치마크와 5개 실기 셋업으로 확장돼 있으며, MIT 라이선스로 커뮤니티 기여를 흡수하고 있다. 리포트 스스로 “프로젝트가 진화하면 이 문서를 갱신하겠다”고 쓴다. 그러니 이 글도 2026년 4월 시점의 스냅샷에 대한 리뷰로 읽는 것이 맞다.

코드 재현 관점(2026-08-13 기준): 코드·학습 스크립트·데이터셋(HuggingFace의 LeRobot 포맷 LIBERO/RoboTwin 컬렉션)이 모두 공개돼 있어 재현 조건은 이 계열 논문 중 최상급이다. 다만 논문에 보고된 수치를 재현하려면 최소 8×A100급이 필요하고(LIBERO 30K step ≈ 10시간대, RoboTwin은 48 GPU × 150K step), 단일 GPU 환경을 위한 축소 레시피는 리포트에도 레포 문서에도 명시되지 않았다. 현실적인 재현 범위는 “설치 → 프레임워크 조립(build_framework)이 도는지 확인 → 소규모 step 학습 루프 검증 → 공개 체크포인트가 있다면 평가 서버 기동” 정도이며, 이 리뷰는 레포 구조 확인까지만 수행했고 학습·평가는 돌리지 않았다.