If LeRobot is the training stack, MuJoCo is the factory underneath it: real-robot demonstrations are robotics' true cost, and simulation is the only legal way around that cost. pip install mujoco gives you DeepMind's physics engine; MJX runs thousands of environments in parallel on a GPU. But sim throughput alone is worthless — productivity is throughput × sim-to-real transfer, and a fast simulator also teaches wrong physics faster.
Not yet scoped — the pipeline when it runs:
Install and describe.pip install mujoco; pull a validated robot from the Menagerie repo (Franka arm, Unitree quadruped, Shadow Hand) rather than hand-tuning MJCF parameters — validated actuator/contact constants are most of what the repo is worth.
Scale on MJX. Port the environment to the JAX backend and measure steps/second at batch 1,024 on one GPU — this is where buying-bandwidth-not-flops's hardware actually earns its keep, since batched rollouts are compute-bound, not bandwidth-bound.
Close the loop with the only number that matters. Train a policy in sim, run it on (or against recorded episodes of) the real robot, and record the success rate. The deliverable is the product: sim steps/sec × transfer rate. A 10× faster simulator with half the transfer is a downgrade.
Randomize by default. Domain randomization — friction, masses, latencies, visuals — is not a tuning option; it is the tax that keeps the policy from overfitting the simulator's own physics.
Source: 09-03 digest, robotics item — added 2026-09-04.
Why
Name the cost being avoided, and the tool makes sense. The LeRobot conclusion was that collecting real demonstrations is robotics' actual bottleneck — hours of human teleoperation per skill. Simulation converts that marginal cost to near zero: an MJX GPU batch generates in minutes what a teleoperation rig collects in months. That is why the simulator is best understood not as a physics toy but as a data factory — the upstream supplier of the training stack's raw material.
Contact is the moat. Rigid-body dynamics in free space is a solved textbook problem; what divides simulators is contact — the friction, impact and deformation where a gripper meets an object. It is exactly the part robotics needs most (manipulation is contact) and the part most simulators fudge. MuJoCo's contact model is the reason it became the de facto research standard, and the reason its results transfer at all.
But speed and truth pull apart, and the measurement must hold both. A policy trained at millions of steps per second converges fast — to the simulator's physics, not the world's. If the sim's friction constant is wrong, faster training means more confidently wrong. Hence the card's one deliverable: throughput × real-world success, never throughput alone — and domain randomization as a standing tax, not an option. The alternatives map the trade: Isaac Lab (NVIDIA-locked, strong rendering), Genesis (new, speed claims), PyBullet (light, aging) — robotics-entry-decision's stack question, one layer down.
How it works
The stack, top to bottom
Layer
Tool
What it supplies
Training stack
LeRobot
Policies, datasets, evaluation
Data factory
MuJoCo / MJX
Cheap rollouts at GPU batch scale
Robot descriptions
MJCF + Menagerie
Validated commercial-robot parameters
Reality
The physical robot
The only scoreboard that counts
What MJX changes
Classic MuJoCo
MJX
Where it runs
CPU, one env at a time
GPU/TPU via JAX
Parallelism
Process-level
Thousands of envs in one batch
Fits
Debugging, visualization
RL training at scale
Watch out
—
JIT compile times; feature gaps vs. CPU MuJoCo
The productivity equation
Term
Measured how
Sim throughput
Steps/sec at batch 1,024, one GPU
Transfer rate
Real-robot success of the sim-trained policy
Productivity
Throughput × transfer — the only number to optimize
The failure mode
High throughput, low transfer: confidently wrong physics, faster
The alternatives, honestly
Simulator
Trade
MuJoCo/MJX
Contact fidelity + open source; rendering is basic
LeRobot 이 학습 스택이라면 MuJoCo 는 그 아래의 공장입니다: 실물 로봇 시연이 로보틱스의 진짜 비용이고, 시뮬레이션은 그 비용을 피하는 유일한 합법적 방법입니다. pip install mujoco 면 DeepMind 의 물리 엔진이 깔리고, MJX 는 GPU 에서 수천 개 환경을 병렬로 돌립니다. 하지만 시뮬 처리량만으로는 무가치합니다 — 생산성 = 처리량 × sim-to-real 전이이고, 빠른 시뮬레이터는 틀린 물리도 더 빨리 가르칩니다.
아직 범위 미정 — 돌릴 때의 파이프라인:
설치와 기술.pip install mujoco; MJCF 파라미터를 손으로 맞추는 대신 Menagerie 저장소의 검증된 로봇(Franka 팔, Unitree 사족, Shadow Hand)을 가져옵니다 — 검증된 액추에이터·접촉 상수가 그 저장소 가치의 대부분입니다.
MJX 로 스케일. 환경을 JAX 백엔드로 옮기고 GPU 한 장, 배치 1,024 에서 초당 스텝을 측정합니다 — 배치 롤아웃은 대역폭이 아니라 연산 바운드라, buying-bandwidth-not-flops 의 하드웨어가 실제로 밥값을 하는 곳이 여기입니다.
유일하게 중요한 숫자로 루프를 닫기. 시뮬에서 정책을 학습시키고, 실물 로봇에서(또는 기록된 에피소드에 대해) 돌려 성공률을 기록합니다. 산출물은 곱입니다: 시뮬 초당 스텝 × 전이율. 전이가 절반인 10배 빠른 시뮬레이터는 다운그레이드입니다.
기본값으로 랜덤화. 도메인 랜덤화 — 마찰, 질량, 지연, 시각 — 는 튜닝 옵션이 아니라 정책이 시뮬레이터 자신의 물리에 과적합하는 것을 막는 세금입니다.
출처: 09-03 다이제스트 로보틱스 항목 — 2026-09-04 추가.
왜
회피되는 비용에 이름을 붙이면 도구가 이해됩니다. LeRobot 의 결론은 실물 시연 수집이 로보틱스의 실제 병목이라는 것이었습니다 — 스킬 하나에 사람 텔레오퍼레이션 몇 시간. 시뮬레이션은 그 한계 비용을 거의 0 으로 바꿉니다: MJX GPU 배치가 텔레오퍼레이션 장비로 몇 달 걸릴 것을 몇 분에 생성합니다. 시뮬레이터를 물리 장난감이 아니라 데이터 공장 — 학습 스택의 원자재를 대는 상류 공급자 — 으로 봐야 하는 이유입니다.
접촉이 해자입니다. 자유 공간의 강체 역학은 교과서에서 끝난 문제입니다; 시뮬레이터를 가르는 것은 접촉 — 그리퍼가 물체를 만나는 곳의 마찰·충격·변형 — 입니다. 로보틱스가 가장 필요로 하는 부분이면서(조작이 곧 접촉입니다) 대부분의 시뮬레이터가 얼버무리는 부분입니다. MuJoCo 의 접촉 모델이 사실상의 연구 표준이 된 이유이고, 그 결과가 조금이라도 전이되는 이유입니다.
하지만 속도와 진실은 서로 당기고, 측정은 둘을 함께 잡아야 합니다. 초당 수백만 스텝으로 학습된 정책은 빨리 수렴합니다 — 세계의 물리가 아니라 시뮬레이터의 물리로. 시뮬의 마찰 상수가 틀리면, 빠른 학습은 더 자신 있게 틀린다는 뜻입니다. 그래서 카드의 산출물은 하나입니다: 처리량 × 실물 성공률, 절대 처리량 단독이 아님 — 그리고 도메인 랜덤화는 옵션이 아니라 상시 세금. 대안들이 트레이드를 그립니다: Isaac Lab(NVIDIA 종속·렌더링 강함), Genesis(신규·속도 주장), PyBullet(가볍고 늙음) — robotics-entry-decision 의 스택 질문의 한 층 아래입니다.