Skip to content
TrainingSource reviewed

MicroDuck Training: Choose a Computer & Compute Route

Use a browser to try MicroDuck without installing Python. The official training stack uses CUDA; the reviewed revision requires Python 3.12. For a new policy, choose a compatible local GPU environment or review the official cloud job route.

Choose by the task you want to finish.

Choose a starting environment
Your goalStart hereWhat to check
Try walking and the controlsBrowser simulatorWait for the scene to load. No local training setup is needed.
Train on Linux with an NVIDIA GPULocal training preparationPython 3.12, the locked dependencies, driver access and CUDA visible inside the project environment.
Train from Windows with an NVIDIA GPUReview WSL 2 as a candidate Linux environmentFollow NVIDIA’s WSL guidance, then run the project checks inside WSL. CUDA support alone is not proof of full MicroDuck compatibility.
Use a Mac or a computer without CUDABrowser exploration; cloud compute for the official training routeA working browser or a Python install does not establish support for the official CUDA training backend.
Use DGX Spark, GB10 or Jetson hardwareRead the dependency sources for the exact boardARM is not one interchangeable environment. Jetson Thor has a separate open dependency report.
Replay your own exported policyExport and local replay guideMatch the input layout, model and control settings. CPU inference does not make dependency installation platform-independent.

The environment requirements come from MicroDuck RL quick start and task registry ↗ and Python, dependency pins and ARM package sources ↗. Windows guidance is a candidate route based on NVIDIA: CUDA on WSL 2 ↗, not a MicroDuck test performed by this site. For Thor, read Jetson Thor report #38 (community report, open at review) ↗ before applying advice intended for GB10.

What a GPU check can tell you.

A system utility seeing an NVIDIA GPU and Python being able to use it are two separate checks. Run the Python probe in the local setup guide from the same project environment that will run training. Record the GPU model, available memory, driver, Python version and revision before comparing your result to somebody else’s.

The official 4,096-environment example describes parallel simulated environments, not a universal memory requirement. Start smaller to check the installation. Do not treat a short successful run as a trained walking policy or use an estimated training time as a guarantee for your machine.

Plan a cloud job before starting one.

The official wrapper adds --hf-jobs to a training command. It also exposes the hardware flavor, namespace, timeout and a dry-run option. Read MicroDuck cloud job submission guide ↗ and check Hugging Face Jobs: current pricing and billing ↗ for current eligibility and compute charges.

  1. Choose the personal or organization namespace that should own the run and its bill.
  2. Choose the GPU and an explicit time limit.
  3. Check where the checkpoints will be stored.
  4. Preview the submission, then decide whether to start the paid job.
  5. Keep the job URL so you can check completion and cancel it if needed.

Keep an experiment small enough to explain.

Begin with an unchanged official walking task. Save the initial configuration and a playback observation. For a second run, change one setting and explain what you expected it to affect. This gives you a useful comparison even when the second result is worse.

Continue with your result.

A separate CPU route for Mac experiments.

Microduck Lab by jonathanhawkins ↗ is an independent project updated September 22, 2026. Its author provides an Apple Silicon CPU training harness and a setup script that pins upstream model and policy revisions, prepares Python and viewer dependencies, and runs contract checks. Start with a fresh checkout and read its requirements before running the script. This is useful for local reward-design experiments; its reported results and claims of compatibility are the author's, not a validation by this site or the official CUDA stack.

Keep the source revision, training environment, exported ONNX and evaluation results beside any comparison. The official daemon simulation answers a different question: how the robot software behaves against a simulated body.

CONTINUE THE CONVERSATION

What would you like to understand next?

Keep the source, your environment and your observations together.