제9부 로보틱스

9.13 Isaac Lab I — GPU 병렬 RL 구조

9.13.1 이 장에서 배우는 것 / 선수 지식

9.11에서 PhysX의 GPU 병렬 물리가 "수천 환경을 한 GPU에서 동시에" 굴릴 수 있다고 했고, 9.12에서 시뮬을 코드 검증(SIL)·데이터 생성(SDG)에 이었다. 이 장은 시뮬의 가장 강력한 쓰임 — 대규모 병렬 강화학습(RL) — 의 구조를 판다. 로봇이 걷고·뛰고·물건을 집는 정책을, 수천 개의 로봇 환경을 한 GPU에서 동시에 실행해 분~시간 단위로 학습하는 Isaac Lab의 아키텍처다. 실제 학습·도메인 랜덤화 실습은 9.14.

핵심 통찰: RL의 적은 "샘플 비효율"이고, 그 해법은 "병목인 환경을 GPU로 옮겨 대량 병렬"이다. RL은 정책을 시행착오로 배우느라 수억~수십억 번의 환경 스텝이 필요하다(샘플 비효율). 전통적으로 환경(시뮬)은 CPU에서 실행되고 정책만 GPU라, 매 스텝 CPU↔GPU를 오가며 환경이 병목이 되어 며칠~몇 주가 걸렸다. Isaac Lab의 통찰은 환경 자체를 GPU로 옮기는 것 — PhysX GPU 물리로 수천 환경을 하나의 배치 텐서로 시뮬하고, 관측·보상·정책까지 전부 GPU에 두어 전송 없이 실행한다. 그러면 처리량이 수백~수천 배 뛰어 같은 정책을 분 단위로 학습한다. "환경을 GPU로, 데이터를 GPU에 묶어둔다" — 9.7의 zero-copy 정신이 RL에.

배우는 것:

• 왜 병렬 RL — RL의 샘플 비효율, 실로봇 불가, CPU 시뮬의 한계.
• 병목은 환경 — 전통 RL 루프의 CPU↔GPU 전송 병목 vs Isaac Lab의 전부 GPU(end-to-end).
• 벡터화 환경 — 수천 환경을 하나의 배치 텐서(관측 [N×obs]·행동 [N×act]·보상 [N])로, PhysX 배치 아티큘레이션·자동 리셋.
• 태스크 해부 — 씬(복제)·관측·보상·종료/리셋 함수, 도메인 랜덤화 훅(9.14).
• 처리량 산수·알고리즘 — 왜 분 단위 학습이 되나, 왜 PPO(대규모 병렬 on-policy).

선수 지식: 9.11(PhysX GPU 물리·아티큘레이션·결정성)·9.12(시뮬 워크플로우·도메인 랜덤화 개요)·0.1(3개의 컴퓨터: 시뮬·학습 vs 엣지 배포)·5.2(TensorRT — 학습된 정책 엣지 배포). 강화학습(상태·행동·보상·정책·PPO)·텐서 연산의 기초는 가정(BK-02). 도메인 랜덤화·실제 학습·Sim2Real은 9.14·10.7, 휴머노이드 파운데이션 모델은 10.10·10.11.

정직: Isaac Lab은 Isaac Gym·Orbit의 계보로 빠르게 진화 중이고, 프레임워크 구조·API·RL 라이브러리 통합·환경 정의 방식은 릴리스 의존이 크다. 이 장은 "왜 GPU 병렬이 RL을 바꾸는가, 벡터화 환경이 어떻게 구성되는가의 원리·구조"를 가르치고, 구체 클래스·API·메뉴는 "그 릴리스 문서로 확인". 처리량·학습 시간 수치(스텝/초·분)는 태스크·GPU·하이퍼파라미터 의존 개략값/발표 기준이다. 학습된 정책의 실로봇 전이는 보장되지 않음(Sim2Real 갭 10.7 — 도메인 랜덤화 9.14 필요). GPU 비결정(9.11)으로 비트 단위 재현은 어렵다.

9.13.2 왜 RL에 대규모 병렬인가 — 샘플 비효율

강화학습(RL)은 정책을 시행착오로 배운다 — 환경에서 행동하고, 보상을 받고, 정책을 조금 고치고, 반복. 문제는 얼마나 많이 반복해야 하나다.

RL의 샘플 비효율(sample inefficiency): 정책이 쓸만해지려면 환경 스텝(경험)이 수억~수십억 번 필요(태스크 의존). 예: 보행/매니퓰레이션 정책 ~10^7~10^9 스텝(개략, 태스크·알고리즘 의존).

• 샘플 비효율은 RL의 본질: 지도학습은 라벨 데이터를 한 번 보지만, RL은 자기가 만든 경험으로 배우느라 같은 상황을 수없이 겪어야 한다. 알고리즘 개선(샘플 효율↑)도 있으나, 여전히 막대한 스텝이 필요.
• 실로봇 불가: 수억 스텝을 실로봇으로 = 비현실적 시간 + 로봇이 수억 번 넘어짐(파손) + 안전. 그래서 시뮬 필수(9.11).
• CPU 시뮬도 부족: 시뮬이라도 CPU에서 단일·소수 환경을 실행하면 처리량이 낮아 며칠~몇 주. RL 연구가 느렸던 이유.
• 병렬의 두 축: 학습 시간 = 샘플 수 ÷ 처리량(스텝/초). 샘플 수는 태스크가 정하니, 처리량을 키우는 것이 실용화의 핵심 요인 — 그것이 대규모 병렬 환경이다. 수천 환경을 동시에 = 처리량 수천 배.

핵심: RL은 샘플 비효율(수억~수십억 스텝)이 본질이라, 실로봇은 불가능(시간·파손·안전)하고 CPU 시뮬도 느리다(며칠~몇 주). 학습 시간 = 샘플 ÷ 처리량이므로 처리량을 키우는 대규모 병렬 환경이 해법 — 수천 환경 동시 = 분~시간 단위 학습. 이것이 Isaac Lab의 존재 이유.

9.13.3 병목은 환경이다 — CPU 시뮬 vs GPU 시뮬

처리량을 못 키운 근본 원인은 RL 루프의 구조에 있다. 전통적 셋업과 Isaac Lab을 비교하자.

전통 RL(환경=CPU, 정책=GPU):

매 스텝마다 CPU↔GPU 전송: obs를 GPU로(정책 입력)·action을 CPU로(환경 입력) → 환경(CPU)이 병목 + 전송 오버헤드. 처리량 ≈ CPU 환경 속도(낮음) + 전송 — 환경이 병목.

Isaac Lab(환경·관측·보상·정책 모두 GPU):

처리량 ≈ GPU 병렬(수천 환경) + 전송 0 — 환경 병목 해소.

• 전통의 병목: 환경(CPU)이 느린 데다, 매 스텝 obs(CPU→GPU)·action(GPU→CPU) 전송이 개입해 GPU가 유휴 상태다. 환경을 늘려도 CPU 코어 한계.
• Isaac Lab의 전환: 환경을 GPU로(PhysX GPU 물리, 9.11) 옮기고, 관측·보상·종료까지 GPU에서 텐서로 계산하고, 정책도 GPU. 그러면 데이터가 GPU를 떠나지 않는다(9.7 zero-copy 정신의 RL판) — 전송 0, 수천 환경 병렬.
• end-to-end GPU의 힘: 관측을 PhysX의 GPU 버퍼에서 직접 읽어 정책에 넣고, 정책 출력을 바로 드라이브에 적용. CPU는 학습 오케스트레이션만. 이것이 처리량을 수백~수천 배 끌어올린다.
• 결정성 주의(9.11): GPU 병렬·부동소수로 비트 단위 재현은 어렵다 — 시드·결정 모드로 근사하되 완벽 재현 기대 금지(학습 재현·디버깅 시 유의).

핵심: RL이 느렸던 근본 원인은 환경(CPU)이 병목 + CPU↔GPU 전송이었다. Isaac Lab은 환경·관측·보상·정책을 전부 GPU에 두어 데이터가 GPU를 안 떠나게(전송 0) 하고 수천 환경을 배치 텐서로 병렬 실행한다 — 9.7 zero-copy 정신의 RL판. 환경 병목이 사라져 처리량이 수백~수천 배.

9.13.4 벡터화 환경 — 수천 환경을 한 텐서로

Isaac Lab의 핵심은 벡터화 환경(vectorized environment) — N개의 환경을 하나의 배치된 시뮬레이션으로 다루는 것이다.

벡터화 환경의 텐서 구조(N = 환경 수, 예: 4096):

한 step():

→ 모두 GPU 텐서. 루프가 CPU를 안 거침.

• N개 환경 = 하나의 배치: 같은 로봇·태스크를 N벌 복제(cloner)해, 각각 다른 상태로 동시에 시뮬. PhysX의 배치 아티큘레이션이 N개 로봇을 한 번에 물리 스텝(9.11 GPU 병렬). 환경끼리는 충돌 안 하게 격리(또는 의도적 배치).
• 모든 것이 텐서: 관측·행동·보상·종료가 [N×…] GPU 텐서라, 정책(배치 NN)·보상 계산·종료 판정이 전부 벡터 연산(torch/warp). 루프 한 번에 N개 환경이 진행.
• 자동 리셋: 어떤 환경이 done(넘어짐·목표 달성·타임아웃)이면 그 환경만 초기 상태로 리셋하고 나머지는 계속 — 비동기 에피소드. 마스킹으로 done 환경만 처리.
• 관측을 GPU 버퍼에서 직접: 관측은 PhysX의 GPU 상태 버퍼(관절각·속도·바디 자세)에서 직접 읽어 텐서로 — CPU 복사 없음(9.13.3).
• 스케일 손잡이 N: N(환경 수)을 키우면 처리량↑(GPU 포화까지). 단 메모리·환경당 연산이 한계 — 무한정은 아니다(9.13.6).

견해: 벡터화 환경은 "N개 환경을 [N×…] 배치 텐서로 묶어 한 step()에 동시에 진행"이다 — 물리(PhysX 배치)·관측·보상·종료·정책이 전부 GPU 텐서 연산이라 루프가 CPU를 안 거친다. 자동 리셋으로 done 환경만 비동기 초기화. 환경 수 N이 처리량 손잡이(GPU 포화까지). 이 구조가 "수천 로봇이 동시에 학습"을 가능케 한다.

9.13.5 Isaac Lab의 구성 — 태스크 해부

하나의 RL 태스크(예: "사족 로봇 보행")를 Isaac Lab에서 정의하는 요소를 해부하자(구조 — API는 릴리스 의존).

RL 태스크의 구성 요소:

# 벡터화 보상·종료의 골격(개념 — torch 텐서 [N], API는 릴리스 의존)
import torch
def compute_reward(state):                      # 전부 [N] 텐서 연산(GPU)
    forward_vel = state.base_lin_vel[:, 0]       # [N] 전진 속도
    energy      = torch.sum(state.torques**2, 1) # [N] 에너지(페널티)
    upright     = state.projected_gravity[:, 2]  # [N] 자세(똑바로?)
    reward = (1.0 * forward_vel                   # 전진 보상
              - 0.001 * energy                    # 에너지 절약
              + 0.5 * upright)                     # 자세 유지
    return reward                                # [N]

def compute_done(state, episode_len):            # [N] bool
    fell = state.base_height < 0.3               # 넘어짐
    timeout = episode_len >= MAX_LEN             # 타임아웃
    return fell | timeout                         # [N]

• 보상 설계가 RL의 절반: 보상 함수가 행동을 정한다 — 전진은 +, 에너지·충격·넘어짐은 −, 자세·부드러움은 +. 보상 셰이핑(reward shaping)이 학습 성패·기행(reward hacking)을 좌우(6.5 정렬의 reward hacking과 같은 함정). 벡터화라 [N] 텐서로 전부 동시 계산.
• 관측·행동 설계: 관측에 무엇을 넣나(자기 상태·목표·명령·지형), 행동을 어떻게 적용하나(관절 목표 vs 토크, 스케일·클립)가 학습성·Sim2Real에 직결. 관측에 노이즈를 더해(9.14) 강건성.
• 리셋·커리큘럼: done 시 랜덤 초기 상태(다양성)·커리큘럼(쉬운→어려운 지형)으로 학습 안정·일반화.
• RL 라이브러리 통합: Isaac Lab은 환경을 표준 벡터 환경 인터페이스로 노출해, rl_games·RSL-RL·SKRL·Stable-Baselines3 등 RL 라이브러리가 그 위에서 PPO 등을 실행한다(9.13.7). 환경(Isaac Lab)과 학습 알고리즘(RL 라이브러리)의 분리.
• 도메인 랜덤화 훅(9.14): 마찰·질량·게인·외란·지형·관측 노이즈를 무작위화하는 자리 — Sim2Real(10.7)의 핵심. 이 장은 구조만, 전략·실습은 9.14.

견해: RL 태스크 = 씬(복제)·관측·행동·보상·종료/리셋·랜덤화의 조합이고, 전부 [N] 벡터 연산(GPU)이다. 그중 보상 설계가 행동을 정하는 절반(셰이핑·reward hacking 주의, 6.5). Isaac Lab은 환경을 표준 벡터 인터페이스로 노출해 RL 라이브러리(rl_games·RSL-RL 등)와 분리 — 환경은 Isaac Lab, 알고리즘은 라이브러리. 랜덤화 훅이 Sim2Real(9.14)의 자리.

9.13.6 처리량 산수 — 왜 분 단위 학습이 되나

대규모 병렬이 학습 시간을 얼마나 줄이는지 산술로 따져 본다(개략, 환경·GPU 의존).

학습 시간 = 필요 샘플 수 ÷ 처리량(스텝/초). 예(보행 정책, 개략): 필요 샘플 ~ 10^8 스텝(환경 스텝, 태스크 의존).

→ 수백~수천 배 처리량 → 며칠/몇 주가 분/시간으로.

• 집계 처리량: N개 환경이 한 step()에 동시에 N스텝을 만든다 → 집계 스텝/초 = step()/초 × N. N을 키우면 step()당 비용은 늘지만 GPU 병렬이라 준선형으로 처리량↑(포화 전까지).
• 유명한 결과(발표 기준): 사족 로봇(ANYmal류) 보행이 단일 GPU에서 분~수십 분에 학습된 사례가 보고됐다 — CPU 시대의 며칠과 대비. (구체 수치는 태스크·GPU·하이퍼파라미터 의존, 발표 기준·개략.)
• 스케일의 한계(정직): N을 무한정 키운다고 계속 빨라지진 않는다 — ① GPU 메모리(환경당 상태·관측·물리 버퍼) ② GPU 연산 포화(이미 꽉 차면 N↑가 step() 시간↑로 상쇄) ③ 알고리즘(너무 큰 배치는 PPO 샘플 효율↓·수렴 변화). 최적 N은 GPU·태스크별로 스윕해 찾는다(9.14).
• 샘플 효율 vs 처리량: 병렬은 처리량을 키울 뿐 샘플 효율(스텝당 학습량)은 안 바꾼다 — 둘은 직교. 처리량으로 벽시계를 줄이되, 더 적은 샘플로 배우려면 알고리즘·보상·커리큘럼.

견해: 학습 시간 = 샘플 ÷ 처리량이고, 대규모 병렬은 처리량을 수백~수천 배 키워 며칠을 분으로 만든다(집계 스텝/초 = step()/초 × N). 단 N은 무한정이 아니다 — GPU 메모리·연산 포화·PPO 배치 효율로 최적점이 있어 스윕(9.14). 처리량과 샘플 효율은 직교 — 병렬은 벽시계를, 알고리즘·보상은 샘플당 학습을.

9.13.7 RL 알고리즘 — 왜 PPO(대규모 병렬 on-policy)

대규모 병렬 환경에서 가장 널리 쓰이는 알고리즘은 PPO(Proximal Policy Optimization) — on-policy 계열이다. 왜인지가 구조를 이해하는 핵심 요인.

on-policy(PPO) vs off-policy(SAC/DDPG):

• 왜 PPO인가: 대규모 병렬은 매 스텝 N개의 신선한 경험을 대량으로 산출한다 — on-policy PPO는 이 거대 배치를 그대로 정책 업데이트에 쓴다(궁합 ★). PPO는 안정적·튜닝이 비교적 쉽고·병렬 확장이 좋아 이 체제의 일꾼이 됐다. 샘플 효율은 off-policy보다 낮지만, 처리량(9.13.6)으로 상쇄 — 샘플을 펑펑 써도 벽시계가 짧다.
• off-policy의 자리: SAC·DDPG는 샘플 효율(리플레이 재사용)이 높아 샘플이 고비용 곳(실로봇 일부)엔 유리하나, 거대 병렬 시뮬에선 신선 배치의 강점을 덜 살리고 복잡. 그래서 Isaac Lab 체제는 PPO 우세(태스크에 따라 다름).
• RL 라이브러리: 알고리즘 구현은 rl_games·RSL-RL·SKRL·Stable-Baselines3 등이 제공하고, Isaac Lab 환경(벡터)에 연결(9.13.5). 환경(시뮬)과 알고리즘(라이브러리)의 분리라 알고리즘을 교체 쉽다.
• 네트워크는 작다(엣지 배포): 보행·매니퓰레이션 정책 NN은 보통 작다(MLP 수 층) — 학습은 거대 병렬이지만 추론은 경량이라 엣지(Jetson 9.1)에서 실시간, TensorRT(5.2)로 최적화. 0.1 "학습=데이터센터, 배포=엣지"의 정확한 사례.

견해: 대규모 병렬의 일꾼은 PPO(on-policy) 다 — N환경이 매 스텝 산출하는 거대 신선 배치를 그대로 업데이트에 써 궁합이 좋고, 안정·확장성이 강하다. 낮은 샘플 효율은 처리량으로 상쇄(샘플을 펑펑, 벽시계는 짧게). off-policy(SAC)는 샘플 효율이 높아 다른 체제에. 정책 NN은 작아 엣지 배포(TensorRT 5.2)가 쉽다 — 학습은 거대, 추론은 경량으로(0.1).

9.13.8 중간 점검 (체크포인트)

• [ ] RL의 샘플 비효율(수억~수십억 스텝)과 실로봇 불가·CPU 시뮬 한계를 안다.
• [ ] 전통 RL의 환경(CPU) 병목 + 전송과 Isaac Lab의 전부 GPU(end-to-end, 전송 0) 차이를 안다.
• [ ] 벡터화 환경이 N환경을 [N×…] 배치 텐서로 한 step()에 진행하고 자동 리셋함을 안다.
• [ ] 태스크 구성(씬 복제·관측·행동·보상·종료/리셋·랜덤화)과 보상 설계의 중요성(셰이핑·hacking, 6.5)을 안다.
• [ ] 처리량 = step()/초 × N으로 학습이 분 단위가 됨과, N의 한계(메모리·포화·PPO 배치)를 안다.
• [ ] 대규모 병렬에 PPO(on-policy) 가 우세한 이유와, 정책 NN이 작아 엣지 배포(5.2) 가 쉬움을 안다.

증상→의심: 학습이 느림 → 환경 수 N 작음·GPU 미포화·CPU 경유(전송)·렌더 켜짐(상태 RL엔 불필요 9.11) → N↑·렌더 끄기·GPU 점유 확인. GPU OOM → N 너무 큼·환경당 상태 큼 → N↓·관측 축소. N 늘려도 안 빨라짐 → GPU 포화·step() 시간↑ 상쇄 → 최적 N 스윕(9.13.6). 정책이 기행(reward hacking) → 보상 셰이핑 결함(전진만 보고 넘어짐 무시 등) → 보상 재설계(6.5 정신). 학습 불안정/발산 → 보상 스케일·관측 정규화·PPO 하이퍼·물리 안정(게인·dt 9.11). 시뮬은 되는데 실로봇 실패 → Sim2Real 갭 → 도메인 랜덤화(9.14·10.6). 재현 안 됨 → GPU 비결정(9.11) → 시드·결정 모드(완벽 재현은 어려움).

9.13.9 트레이드오프·대안

견해: 로봇 정책을 RL로 배우려면 GPU 병렬 시뮬(Isaac Lab류)이 사실상 필수 — CPU·실로봇으로는 샘플 비효율을 못 푼다. 상태 기반 RL은 렌더를 끄고 N을 최대로(처리량), 비전 기반은 렌더가 비용이 커 N이 제한(충실도↔규모, 9.11). 대규모 병렬엔 PPO가 일꾼이되, 샘플이 고비용 체제엔 off-policy도. 학습은 시뮬(거대 병렬)이지만 실로봇 전이는 도메인 랜덤화(9.14)·실로봇 검증이 필요 — 시뮬 정책이 실세계서 그대로 되진 않는다(10.7).

비엔비디아 정직: GPU 병렬 RL은 NVIDIA만의 것이 아니다 — Brax·MJX(MuJoCo XLA) 는 JAX로 GPU/TPU 병렬 물리를, Isaac Gym(Isaac Lab의 전신)은 초기 GPU RL을, MuJoCo는 빠른 접촉으로 RL 연구 표준이다. Isaac Lab의 강점은 PhysX GPU 물리·RTX(비전 RL)·OpenUSD 에셋·도메인 랜덤화·Isaac ROS/Sim/GR00T 스택 통합·Sim2Real 도구다. 순수 RL 연구·경량 벤치마크엔 Brax·MJX·MuJoCo가 더 빠르거나 친숙할 수 있다 — 사실적 비전·복잡 로봇·USD 에셋·실로봇 파이프라인 통합이 필요하면 Isaac Lab. 처리량·학습 시간은 태스크·GPU 의존이라 자기 과제에서 측정(발표 수치를 자기 환경으로 단정 금지).

9.13.10 흔한 함정

• 환경 병목을 못 봄. CPU 경유·작은 N·렌더 켜짐으로 GPU가 놀면 느림 → end-to-end GPU·N↑·상태 RL은 렌더 끄기(9.13.3).
• N을 맹목적으로 키움. GPU OOM·포화로 안 빨라지거나 PPO 배치 효율↓ → 최적 N 스윕(9.13.6).
• 보상 셰이핑 결함(reward hacking). 전진만 보상하면 넘어지며 미끄러지기·진동 등 기행 → 다항 보상·페널티·검증(6.5 정신).
• 관측·보상 정규화 누락. 스케일이 제각각이면 학습 불안정 → 정규화·클립.
• 상태 RL에 렌더 켜둠. 불필요한 RTX 렌더로 느림 → headless·렌더 끄기(9.11).
• 물리 불안정. 게인·dt(9.11) 나쁘면 환경이 폭발해 학습 안 됨 → 물리 먼저 안정화.
• 도메인 랜덤화 없이 학습. 시뮬 한 모습에 과적합 → 실로봇 실패 → 랜덤화(9.14·10.7).
• 재현 과신. GPU 비결정(9.11)으로 비트 재현 어려움 → 시드·결정 모드, 통계로 비교.
• 거대 정책 NN. 학습은 되어도 엣지 추론 고부하 → 작은 NN·TensorRT(5.2·9.1).
• 발표 처리량을 자기 환경으로 단정. 태스크·GPU·하이퍼 의존 → 직접 측정.

9.13.11 연습문제

연습 1 (왜 병렬). RL의 샘플 비효율을 설명하고, 왜 실로봇·CPU 시뮬로는 부족하며 대규모 병렬이 어떻게 학습 시간을 바꾸는지 — 학습 시간 공식으로 답하라.

연습 2 (환경 병목·end-to-end GPU). 전통 RL(환경=CPU, 정책=GPU)의 병목을 설명하고, Isaac Lab이 어떻게 그것을 없애는지 — 9.7(NITROS zero-copy)과 무엇이 닮았는지 답하라.

연습 3 (벡터화 환경). 벡터화 환경의 텐서 구조와 한 step()의 동작을 설명하고, 자동 리셋이 왜 필요하며 환경 수 N이 처리량·메모리와 어떤 트레이드오프인지 답하라.

연습 4 (태스크·보상 설계). 사족 보행 태스크의 구성 요소(관측·행동·보상·종료)를 설계하고, 보상 셰이핑이 왜 RL의 절반이며 reward hacking을 어떻게 피하는지 답하라.

연습 5 (알고리즘·배포). 대규모 병렬에 PPO(on-policy)가 우세한 이유를 off-policy와 비교해 설명하고, 학습된 정책을 엣지(Jetson)에 배포하는 흐름이 "3개의 컴퓨터"(0.1)와 어떻게 맞는지 답하라.

9.13.12 요약 · 다음 장

• 샘플 비효율: RL은 수억~수십억 스텝 필요 → 실로봇 불가(시간·파손)·CPU 시뮬 느림. 학습 시간 = 샘플 ÷ 처리량 → 처리량을 병렬로.
• 환경 병목 해소: 전통 RL은 환경(CPU)+전송 병목. Isaac Lab은 환경·관측·보상·정책 전부 GPU(end-to-end, 전송 0) — 9.7 zero-copy 정신의 RL판.
• 벡터화 환경: N환경을 [N×…] 배치 텐서로 한 step()에 동시 진행(PhysX 배치 아티큘레이션)·자동 리셋. N이 처리량 손잡이(GPU 포화·메모리 한계까지).
• 태스크·처리량: 씬(복제)·관측·행동·보상(셰이핑·hacking 주의 6.5)·종료·랜덤화. 처리량 = step()/초 × N → 분 단위 학습(발표 기준).
• 알고리즘·배포: 대규모 병렬엔 PPO(on-policy) 우세(신선 배치 궁합·안정·확장, 낮은 샘플 효율은 처리량으로 상쇄). 정책 NN은 작아 엣지 배포(TensorRT 5.2) 쉬움(0.1). 정직: 수치 발표/개략, GPU 비결정, Sim2Real은 9.14·10.7, 비NVIDIA(Brax·MJX·MuJoCo).

다음 장: 9.14 Isaac Lab II — 도메인 랜덤화·학습. 병렬 RL의 구조를 봤으니, 이제 실제로 정책을 학습하고 Sim2Real을 좁힌다 — 환경 설정·PPO 학습 루프 실행·곡선 읽기와, 도메인 랜덤화(마찰·질량·게인·외란·관측 노이즈를 무작위화)로 학습한 정책이 실로봇으로 전이되게 하는 전략을 직접 구성한다. 구조가 학습·전이로.