Praxis-1

praxis là bộ adapter LeRobot của Praxis-1, mô hình World Action Model mã mở của Runway dành cho robot. Praxis-1 là một mô hình video-hành động: một bộ khung video diffusion chunk-causal (một transformer mixture-of-experts 27B tham số, khoảng 3B tham số hoạt động mỗi token) khử nhiễu 1,6 giây video tiếp theo của hai camera trên giá đỡ, trong khi một chuyên gia hành động, đọc các trạng thái ẩn của bộ khung, khử nhiễu 24 lệnh Cartesian tương ứng ở 15 Hz. Video autoencoder Wan2.2 và text encoder Qwen3.5-2B được đóng băng và lấy từ trọng số công khai của chúng. Checkpoint được phát hành, praxis-1-droid, điều khiển một giá đỡ DROID một cánh tay: một cánh tay Franka với một camera bên ngoài và một camera cổ tay. Một checkpoint DROID trước đó, chưa được phát hành, có cùng kiến trúc nhưng với các trọng số khác và một canvas camera khác; config.json của checkpoint phân biệt chúng (xem “The checkpoints”). praxis-1-yam, checkpoint hai cánh tay cho hai cánh tay YAM, được phát hành với cùng bố cục (xem “The bimanual YAM checkpoint”). praxis-1-base, bộ khung video và thân chuyên gia hành động không có các đầu ra của một giá đỡ, là điểm khởi đầu để fine-tune cho một giá đỡ một cánh tay mới (xem “Fine-tune the base checkpoint”).

Tài nguyên:

Mã mô hình nằm trong cây thư mục tại lerobot/policies/praxis/praxis_core (được đưa vào từ kho praxis tại commit 8dad1a4 cùng với quy tắc canvas của praxis-1-droid, các đường dẫn import đã được viết lại; phần đầu tệp ghi rõ các commit nguồn gốc). Mô phỏng MuJoCo là gói praxis-sim trên PyPI (được phát triển trong packages/praxis-sim của kho praxis, không có torch); LeRobot không có môi trường cho nó.

Cài đặt

pip install -e ".[praxis,dataset]"   # the policy; `lerobot-eval` and `lerobot-train` also need `dataset`

Các checkpoint đã chuyển đổi nằm trên Hub: --policy.path=runwayml/praxis-1-droid-lerobot nạp checkpoint một cánh tay đã phát hành (54 GB, tải về một lần). runwayml/praxis-1-yam-lerobot là checkpoint hai cánh tay. runwayml/praxis-1-base-lerobot là checkpoint cơ bản, cần chạy init_heads.py trước.

Chính sách được chạy trên các phiên bản mà LeRobot 0.7 khóa (0.7.1 tại thời điểm viết: torch 2.15.0 với CUDA 13.2, transformers 5.22.2, triton 3.9). Các kết quả dưới đây được đo trên bộ công cụ đó (với transformers 5.22.1 và 5.22.2, cho ra cùng các lệnh) và trên bộ công cụ của LeRobot 0.6 (torch 2.11.0 với CUDA 12.8, transformers 5.5.4); các lệnh tương đương từng bit với các lệnh trong kho praxis trên mỗi bộ công cụ.

Các kernel tùy chọn trong cấu hình xác thực của checkpoint. flash-attn-4 cung cấp backend chú ý flash của cấu hình checkpoint (chú ý linh hoạt với kernel FlashAttention-4 CuTe); nếu không có nó, chính sách sẽ sử dụng kernel Triton của chú ý linh hoạt. flash-linear-attention và causal-conv1d là các kernel nhanh cho các lớp chú ý tuyến tính của Qwen3.5; nếu không có chúng, transformers sẽ chạy triển khai PyTorch của mình. Cả ba đều thay đổi các bit cuối cùng của đầu ra, chứ không thay đổi mô hình:

pip install "flash-attn-4[cu13]==4.0.0b36"        # the CUDA 13 build for torch 2.15; "flash-attn-4==4.0.0b36" on a CUDA 12 torch
pip install "flash-linear-attention==0.6.0"       # 0.5.0 does not run on triton 3.9
CAUSAL_CONV1D_FORCE_BUILD=TRUE MAX_JOBS=16 pip install --no-build-isolation "causal-conv1d==1.6.1"   # compiles against torch; the praxis repository's setup

Việc suy luận cần một GPU có 80 GB bộ nhớ (các trọng số là 54 GB ở bfloat16).

Trên các GPU Blackwell của datacenter (B200 và GB200 là SM100, B300 và GB300 là SM103; Jetson Thor, SM110, có cùng FlashAttention-4 forward):

• B300 và GB300 cần một bản build của torch cho CUDA 12.9 trở lên, chẳng hạn như torch 2.15.0+cu132 mà LeRobot 0.7 cố định. Các chuyên gia MoE gọi torch._grouped_mm, và bản build của torch 2.11.0+cu128 (LeRobot 0.6) không có kernel SM103 cho nó: lần gọi policy đầu tiên sẽ thất bại với RuntimeError: cutlass cannot run, error 7, giống như pipeline của kho praxis. B200 chạy được trên cả hai stack.
• FlashAttention-4 chỉ chấp nhận các mặt nạ block-sparse theo các khối 256 token (nó sẽ gây ra ValueError: Block sparse tensorsforward have block size 128, which must be a multiple of 256). Với backend flash, chính sách sẽ xây dựng các mặt nạ backbone theo các khối 256 token trên các GPU này thay vì backbone.attention.flex_block_size là 128 của checkpoint. Kích thước khối chỉ nhóm các cặp token lại với nhau: hàm mặt nạ vẫn quyết định cho từng cặp. Kho praxis chạy cùng cấu hình với "flex_block_size": 256 trong config.json của checkpoint. Backend triton giữ nguyên giá trị 128 của checkpoint.

Trên các GPU RTX Blackwell (khả năng tính toán 12.x; RTX PRO 6000 Blackwell có 96 GB bộ nhớ mà các trọng số cần), FlashAttention-4 không có chế độ forward block-sparse ở bất kỳ kích thước block nào (với các block 128-token của checkpoint, nó sẽ gây ra lỗi Block sparsity requires sparse_block_size[1]=128 to match tile_n=64), do đó backend flash không thể chạy trên đó. attention_backend="auto" sẽ chọn triton trên các GPU này, ngay cả khi đã cài đặt flash-attn-4, và "flash" sẽ gây ra ValueError khi chính sách được xây dựng. Kho praxis sẽ thất bại ở lần gọi đầu tiên với flash của checkpoint và chạy bình thường nếu đặt "backend": "triton" trong config.json của checkpoint. Hai backend này khác nhau ở các bit cuối, vì vậy hãy so sánh các lần chạy trên các GPU này với các lần chạy triton ở nơi khác. Không có gì thay đổi khác trên RTX PRO 6000: các bản build torch của cả hai stack bên dưới đều cung cấp các kernel SM120 (bao gồm cả torch._grouped_mm của MoE), và suy luận với các cài đặt của praxis-1-droid đạt đỉnh khoảng 62 GB.

Các quy tắc này tuân theo các kiểm tra riêng của FlashAttention-4. Kết quả parity bên dưới được đo trên một GB300, một B200 và một RTX PRO 6000 Blackwell.

transformers từ 5.4.0 đến 5.5.4 (LeRobot 0.6; đã sửa trong 5.6.0, và LeRobot 0.7 khóa phiên bản 5.22) nạp checkpoint Hub Qwen/Qwen3.5-2B với tất cả 320 tensor của mô hình ngôn ngữ được báo cáo là thiếu (nó đổi tên các tên model.language_model.* đã lưu trước khi khớp) và âm thầm khởi tạo chúng ngẫu nhiên. Bộ mã hóa văn bản của chính sách phát hiện điều này và nạp các tensor theo tên đã lưu của chúng, kèm theo một cảnh báo trong nhật ký. Một bộ mã hóa văn bản được khởi tạo ngẫu nhiên sẽ tạo ra một chính sách vẫn di chuyển nhưng hiếm khi thành công (7 trên 56 tập hợp bảo vệ trong lần chạy đầu tiên của chúng tôi).

Đầu vào và đầu ra

Policy tự duy trì lịch sử của riêng mình: một ring buffer chứa 25 quan sát gần nhất cho mỗi môi trường trong batch (gồm chunk đã thực thi và khung hình hiện tại) được truyền vào lần gọi tiếp theo làm ngữ cảnh, do đó n_obs_steps vẫn giữ ở 1 và select_action phải được gọi ở mỗi tick 15 Hz với quan sát của tick đó. Lần gọi đầu tiên của một cửa sổ ngữ cảnh trả về 21 lệnh, mọi lần gọi sau đó trả về 24. Khi n_action_steps nhỏ hơn 24, mọi lần gọi đều là khởi động lạnh không có ngữ cảnh, giống như trong praxis. drop_queued_actions (ví dụ một lệnh mới giữa rollout) cũng khởi động lại ngữ cảnh thời gian, vì mô hình điều kiện hóa dựa trên toàn bộ chunk trước đó đã được thực thi. Người gọi thực thi các chunk hoàn chỉnh (predict_action_chunk) sẽ truyền các khung hình đã thực thi kể từ lần gọi trước đó dưới dạng một stack, các camera (B, T, 3, H, W) với các trạng thái (B, T, 7), khung cũ nhất ở đầu; chunk tiếp theo khi đó sẽ là chunk của một rollout gọi mỗi tick. Một lần gọi chunk với một khung hình sẽ khởi động lại ngữ cảnh.

Bộ xử lý

Bộ tiền xử lý chuẩn bị các đầu vào theo cách mà mã dữ liệu và mã phục vụ của praxis thực hiện, dưới dạng các bước được lưu lại, có thể kiểm tra:

Giữa hai thành phần này, policy nhìn thấy các tile và các hàng pose8, rồi phát ra các wire poses, đúng những gì mà Session của praxis tiêu thụ và tạo ra. Việc chuẩn hóa hành động q99, việc chuẩn hóa proprio theo mean/std và việc giải mã hành động tương đối được giữ bên trong session: chúng được neo vào pose tại thời điểm bắt đầu của mỗi chunk được thực thi, mà session theo dõi trong suốt quá trình rollout, và thống kê của chúng chính là checkpoint (PraxisConfig.model_config["normalization"]); các bước chuẩn hóa mặc định là identity. Policy cũng chấp nhận pose thô 7 giá trị, các khung camera thô và chuỗi task, nhờ đó nó có thể được gọi mà không cần pipeline: các khung có kích thước tile được coi là tile, các kích thước khác đi qua quy tắc canvas của checkpoint (quy tắc fit của praxis-1-droid không có tính idempotent, nên một tile không bao giờ đi qua nó hai lần), và một task không có token sẽ được token hóa bởi policy. Các tile được giữ trên thiết bị mà pipeline đặt chúng cho đến khi autoencoder đọc chúng, và các lệnh được trả về trên CPU: không có gì vượt qua ranh giới thiết bị hai lần.

Các checkpoint

Canvas được lấy từ config.json của checkpoint (video.tile_height, video.antialias) thông qua trình chuyển đổi; các cài đặt của sampler là các trường của PraxisConfig, do đó một lần chạy của checkpoint DROID trước đó sẽ truyền các giá trị của riêng nó (--policy.t_shift=8.0 --policy.cfg_video_scale=1.0 --policy.max_context_chunks=3).

Chuyển đổi checkpoint

Checkpoint praxis là một thư mục chứa config.json, 17 shard safetensors, model.safetensors.index.json và SHA256SUMS. Chuyển đổi nó thành thư mục policy của LeRobot:

python examples/praxis/convert_checkpoint.py \
    --checkpoint /path/to/praxis-1-droid --out outputs/praxis-1-droid --link

Bộ thiết bị được lấy từ embodiment của checkpoint: checkpoint bimanual nhận các khóa camera của nó (dùng --camera-keys để đổi tên) và các cài đặt serve của checkpoint đó. Checkpoint cơ bản nhận một thư mục không có processors, được init_heads.py hoàn thiện. runwayml/praxis-1-droid-lerobot và các checkpoint đã chuyển đổi khác là kết quả đầu ra của script này.

--link tạo symlink cho các shard thay vì sao chép 54 GB. Thư mục chứa config.json của LeRobot, các shard, index và file SHA256SUMS riêng của nó (sha256sum -c chạy thành công trong thư mục đó) (các policy của LeRobot đọc và ghi sharded safetensors theo layout của transformers; PraxisPolicy.save_pretrained ghi các shard 5 GB), cùng hai file processor. --vae-id và --text-encoder-id xác định nguồn của các phần đóng băng (mặc định là Hub ids).

Kết quả

Các số liệu vòng kín dưới đây được lấy từ hệ thống MuJoCo của kho praxis (gói praxis-sim: Franka + Robotiq 2F-85, camera 512 x 288, 15 Hz) và các bộ đánh giá cố định của nó; hạt giống LeRobot của một tập là hạt giống cảnh của tập đó. Môi trường chạy các bộ đánh giá thông qua lerobot-eval không phải là một phần của LeRobot.

Trong khi lấy mẫu, chính sách cố định các cài đặt số học mà praxis chạy (không dùng chế độ benchmark của cuDNN, phép nhân ma trận float32 cho bộ định tuyến MoE, cho phép TF32 trong cuDNN) và khôi phục các cài đặt của host sau đó, do đó --tf32, torch.backends.cudnn.benchmark và kích thước lô không làm thay đổi đầu ra của nó.

Bộ droid_guard (7 tác vụ DROID x 8 cảnh, 56 tập, hạt mẫu 0) với checkpoint DROID trước đó, chưa được phát hành (gạch 256 x 416) ở các cài đặt bộ lấy mẫu của kho praxis tại thời điểm đó (2 bước Euler, dịch chuyển luồng 1.0, dẫn động hành động 3.0, không có dẫn động video, 1 khối ngữ cảnh) và backend chú ý flash của nó, trên một H100 80 GB (khoảng 10 phút). Cùng các tập đó được chạy theo năm cách: trình chạy riêng của kho praxis trong môi trường riêng của nó (torch 2.13, transformers 5.2.0, causal-conv1d), cùng trình chạy đó và lerobot-eval trên bộ công cụ của LeRobot 0.6 (torch 2.11, transformers 5.5.4), và cả hai lần nữa trên bộ công cụ mà LeRobot 0.7 khóa (torch 2.15 với CUDA 13.2, triton 3.9, flash-linear-attention 0.6.0; transformers 5.16.1 tại thời điểm đó). Lặp lại các lần chạy torch 2.15 với transformers 5.22.1 cho ra các lệnh giống hệt nhau từng bit và cùng kết quả 46/56 tập cho cả trình chạy praxis và lerobot-eval, và 5.22.2 (phiên bản mà LeRobot 0.7.1 khóa) cho ra các lệnh giống nhau cho praxis-1-droid và checkpoint YAM: phiên bản transformers không đi vào các con số.

Được ghép qua 56 tập (praxis_sim.compare), lerobot-eval trừ tham chiếu:

Mọi khoảng đều chứa số 0: chính sách và môi trường LeRobot tái tạo kết quả của kho praxis, và cả phần mềm (kernels, phiên bản transformers) lẫn harness đều không thay đổi chúng ngoài nhiễu giữa các episode. Bản thân runner praxis cũng di chuyển với cùng mức độ giữa các stack (từ 44 đến 46 trong 56). press_button là khó đối với checkpoint này trong mọi cấu hình.

Với các đầu vào giống hệt nhau, chính sách sẽ bằng nhau từng bit so với pipeline praxis trên cả hai stack (xem bên dưới); giữa hai stack, các lệnh của các đầu vào giống hệt nhau có sự khác biệt lên đến 0.04 (flash) và 0.02 (triton), đây là yếu tố làm thay đổi từng episode.

praxis-1-droid , checkpoint đã phát hành

Cùng 56 tập với praxis-1-droid (các ô gạch 224 x 416 khử răng cưa) ở các cài đặt khuyến nghị của nó (2 bước Euler, flow shift 12.5, video guidance 4.0, không có action guidance, 1 context chunk) và backend flash, trên một H100 80 GB: runner của kho praxis (hàm main của nó với sampler hiện tại, trong môi trường praxis: torch 2.13, transformers 5.2.0), lerobot-eval trên stack của LeRobot 0.6 (torch 2.11, transformers 5.5.4), và cả runner lẫn lerobot-eval trên stack mà LeRobot 0.7 khóa (torch 2.15 với CUDA 13.2, transformers 5.22.1).

Xét trên 56 tập được ghép cặp, lerobot-eval trừ đi praxis runner là +0,0 điểm trên cả hai stack (95 % khoảng tin cậy bootstrap [-7,1 %, +7,1 %], thắng 2 / thua 2, McNemar p 1,00 mỗi stack). Các tập bị đảo chiều không phải là cùng một tập trên hai stack: các kernel của torch 2.15 làm dịch chuyển các lệnh lên tới 0,02, và một vài tập ở mức ranh giới theo sau. praxis-1-droid với các cài đặt của nó giải được press_button, trong khi checkpoint DROID trước đó với các cài đặt của nó phần lớn thất bại.

Sự tương đồng với kho praxis

• Với các quan sát giống hệt nhau trong một tiến trình, chính sách LeRobot và Session của praxis cho ra các nhúng văn bản, ẩn VAE, proprio, hành động được lấy mẫu và lệnh bằng nhau từng bit (cùng trọng số đã nạp). tests/policies/praxis/test_praxis.py lặp lại kiểm tra này trên một mô hình ngẫu nhiên nhỏ trên CPU.
• Giữa các tiến trình, pipeline praxis chạy qua gói praxis gốc và chính sách LeRobot cho ra các lệnh bằng nhau từng bit trên checkpoint thực, trên cả backend flash và triton (hai backend này khác nhau tối đa 0.055 trong các lệnh), trên stack của LeRobot 0.6 (torch 2.11.0+cu128, transformers 5.5.4, flash-attn-4 4.0.0b36) và trên stack mà LeRobot 0.7 khóa (torch 2.15.0+cu132, transformers 5.22.1 và 5.22.2, triton 3.9, flash-attn-4 4.0.0b36). Bản tham chiếu tự nó thay đổi giữa hai stack (tối đa 0.019 trên flash, 0.015 trên triton); chính sách bám theo nó từng bit trên mỗi stack.
• praxis-1-droid: phép kiểm tra liên tiến trình so với pipeline praxis của nhánh main trong kho praxis (với bộ lấy mẫu hiện tại) cho kết quả bằng nhau từng bit trên cả hai backend và cả hai stack trong tám cách gọi chính sách: thông qua các pipeline processor đã lưu (như lerobot-eval làm), trên các khung hình thô và tư thế 7 giá trị không dùng pipeline, với hai môi trường trong một batch (lệnh và hạt cảnh khác nhau), thông qua predict_action_chunk (khởi động lạnh, và chunk tiếp theo dựa trên các khung hình đã thực thi dưới dạng stack), với n_action_steps=12 (một chunk mỗi 12 lệnh, điều kiện trên các khung hình đã thực thi), với hướng dẫn hành động bật (cfg_scale=3), và trên 70 lệnh với ba chunk ngữ cảnh (sâu 0 đến 3). Phép kiểm tra vẫn đúng dưới các cờ TF32 mặc định và benchmark cuDNN của lerobot-eval: chính sách cố định các phép tính số của praxis trong khi lấy mẫu và trả lại cờ của host. Bước tile tính toán canvas trên CPU bất kể thiết bị của các khung hình: phép resize khử răng cưa CUDA làm tròn khác nhau một mức trên khoảng một phần ba số pixel, điều này đã làm dịch chuyển các lệnh tới 0.02 trước khi bước đó thực hiện.
• Huấn luyện: trên các trọng số đã phát hành, PraxisPolicy.forward và praxis.train.objective của kho praxis cho ra cùng một giá trị loss (và các số hạng video và hành động) giống hệt nhau từng bit cho cùng một cửa sổ và cùng các lần rút ngẫu nhiên, cũng như cùng các gradient trên tất cả 200 tensor của chuyên gia hành động. Chỉ số cân bằng MoE được báo cáo thay đổi một hoặc hai ulp float32 giữa các lần chạy ở cả hai phía (một phép giảm không xác định trong thống kê cân bằng; nó đi vào loss với trọng số 1e-4).
• GB300 (SM103, host aarch64): trên stack LeRobot 0.7 khóa (torch 2.15.0+cu132, cuDNN 9.26, transformers 5.22.1, triton 3.9, flash-attn-4 4.0.0b36, flash-linear-attention 0.6.0), kiểm tra liên tiến trình so với nhánh main của kho praxis cho kết quả bằng nhau từng bit trên cả hai backend (flash với khối mask 256 token ở cả hai phía): với praxis-1-droid trong bảy cách gọi policy (các pipeline đã lưu dưới cờ của lerobot-eval, khung hình thô 720 x 1280, hai môi trường trong một batch, predict_action_chunk với chồng khung hình, n_action_steps=12, cfg_scale=3, và 94 lệnh với ba khối ngữ cảnh), với praxis-1-yam qua các pipeline, trên khung hình thô và với hai môi trường, và với bộ khung DROID được dựng lại từ praxis-1-base. forward cho ra loss của mục tiêu praxis và gradient của tất cả 200 tensor chuyên gia hành động khớp từng bit trên trọng số đã phát hành.
• RTX PRO 6000 Blackwell (SM120, 96 GB, host x86_64), triton ở cả hai phía: trên stack của LeRobot 0.6 (torch 2.11.0+cu128, cuDNN 9.19, transformers 5.5.4, triton 3.6, flash-linear-attention 0.5.0) và trên stack mà LeRobot 0.7 khóa (torch 2.15.0+cu132, cuDNN 9.26, transformers 5.22.1, triton 3.9, flash-linear-attention 0.6.0 và causal-conv1d 1.6.1, để Qwen3.5 chạy các kernel của chúng), cả hai đều cài đặt flash-attn-4 4.0.0b36, kiểm tra liên tiến trình so với main của kho praxis bằng nhau từng bit theo cách của GB300: praxis-1-droid trong bảy (463 lệnh, độ sâu ngữ cảnh từ 0 đến 3), praxis-1-yam trong ba, và bộ DROID được xây dựng lại từ praxis-1-base (sáu tensor đầu của nó và cấu hình của nó bằng với init_heads của kho praxis). forward cho ra loss của mục tiêu praxis và gradient của tất cả 200 tensor action-expert bằng nhau từng bit trên cả hai stack, với backbone được đóng băng ở cả hai phía (54 GB gradient của nó không vừa cạnh bên trọng số). Trên stack của LeRobot 0.6, phía praxis cũng cần bản sửa lỗi Qwen3.5 của cảnh báo ở trên: praxis-1 ghim transformers 5.2.0, và dưới 5.5.4 bộ mã hóa văn bản của nó vẫn ngẫu nhiên. Vòng kín trên droid_guard với praxis-1-droid trên stack của LeRobot 0.6: lerobot-eval 53/56 (94,6 %), trình chạy praxis 54/56 (96,4 %, như trên H100 và GB300); ghép cặp, -1,8 điểm, khoảng 95 % [-8,9, +5,4], thắng 2 / thua 3, McNemar p 1,00. Một lần tinh chỉnh LoRA qua lerobot-train (r 16, alpha 32, các mục tiêu mặc định, một cửa sổ mỗi bước) chạy trên một GPU: 5,5M tham số có thể huấn luyện, 1,1 giây mỗi bước, 62 GB.
• B200 (SM100, host x86_64): trên stack của LeRobot 0.6 (torch 2.11.0+cu128, cuDNN 9.19, transformers 5.5.4, triton 3.6) và trên stack mà LeRobot 0.7 khóa (torch 2.15.0+cu132, cuDNN 9.26, transformers 5.22.1, triton 3.9, flash-linear-attention 0.6.0), cả hai đều dùng flash-attn-4 4.0.0b36, kiểm tra liên tiến trình so với nhánh main của kho praxis cho kết quả bằng nhau từng bit trên cả hai backend (flash với các khối mask 256 token ở cả hai phía) theo cách của GB300: praxis-1-droid trong bảy (463 lệnh cho mỗi backend và stack, độ sâu ngữ cảnh từ 0 đến 3), praxis-1-yam trong ba, và bộ khung DROID được xây dựng lại từ praxis-1-base (sáu tensor đầu và cấu hình của nó bằng với init_heads của kho praxis). Hai backend khác nhau nhau tối đa 0.19 trong các lệnh. forward cho ra loss của mục tiêu praxis, các số hạng video và hành động của nó, cùng gradient của tất cả 200 tensor chuyên gia hành động, bằng nhau từng bit trên cả hai backend và cả hai stack, với backbone đã được huấn luyện. Một lần fine-tune LoRA qua lerobot-train chạy trên một GPU (1,2 giây mỗi bước, 62 GB), và adapter cùng checkpoint đã hợp nhất của nó được nạp trong lerobot-eval.
• Vòng lặp kín trên B200 (droid_guard, praxis-1-droid, flash): trình chạy praxis đạt 54/56 trên cơ sở torch 2.15 và 55/56 trên torch 2.11, lerobot-eval đạt 53/56 và 51/56 (đôi: -1,8 điểm, khoảng 95 % [-8,9, +5,4]; và -7,1 điểm, [-14,3, -1,8], thắng 0 / thua 4, McNemar p 0,125). Mỗi harness lặp lại chính nó theo từng tập, nên khoảng cách không phải là nhiễu giữa các lần chạy, và cũng không phải do chính sách: lerobot-eval mang trạng thái và các lệnh dưới dạng 7 giá trị DROID float32 (PraxisSimGymEnv, các bước của bộ xử lý tư thế và lệnh), trong khi trình chạy praxis truyền các tư thế và lệnh của phiên như chúng là. Chuyến đi vòng làm dịch chuyển một tư thế khoảng 1e-7, và trong một tập, sự khác biệt lớn dần thành một quỹ đạo khác. Trình chạy praxis với trạng thái và lệnh của nó được gửi qua cùng một phép chuyển đổi float32 cho ra kết quả lerobot-eval trong cả 56 tập, trên cả hai cơ sở.
• So với môi trường của chính kho praxis (torch 2.13.0+cu130, transformers 5.2.0, causal-conv1d), các đầu ra không bằng nhau theo từng bit: các kernel khác nhau, embedding của Qwen3.5 khác nhau tới 0.125 trong bfloat16, và các bit cuối cùng của các hành động cũng theo đó. Do đó, việc kiểm tra giữa các kho là đánh giá vòng kín ghép cặp ở trên.
• Mô phỏng được render với 4x multisampling, và một vài pixel mỗi khung hình khác nhau giữa các lần render của cùng một cảnh, do đó hai tập hợp episode vòng kín của cùng một policy sẽ phân kỳ sau chunk đầu tiên ngay cả khi trọng số giống hệt nhau. Các cặp episode được so sánh về mặt thống kê, không phải theo từng khung hình.

Checkpoint YAM hai tay

praxis-1-yam ("embodiment": "bimanual", runwayml/praxis-1-yam-lerobot) điều khiển hai cánh tay YAM với một camera trên đỉnh và hai camera cổ tay (góc nhìn ZED 16:10, 1920 x 1200). Cùng một mô hình chạy cho nó; checkpoint khác nhau ở độ rộng của expert head (20 giá trị hành động: [xyz, rot6d, gripper] cho mỗi cánh tay), bảng canvas ba ô và phép chuẩn hóa. Bộ thích ứng LeRobot làm theo praxis/bimanual.py của kho praxis (được đóng gói thành praxis_core/bimanual.py):

Cấu hình phục vụ của checkpoint (tệp configs/serve_yam.yaml trong kho praxis: 2 bước Euler, flow shift 1.0, không có text guidance, 1 context chunk, rig bimanual không có control mode) là những gì trình chuyển đổi ghi vào config, do đó --policy.path=runwayml/praxis-1-yam-lerobot sẽ chạy chúng. Prompt được đưa vào text encoder nguyên văn; checkpoint được huấn luyện trên các caption như “Pick up the pen from the center of the table, then place the pen in the bag”, không có dấu chấm kết thúc.

Parity: trên checkpoint thực, chính sách LeRobot và pipeline praxis BimanualServeSession cho ra các lệnh bằng nhau từng bit cho cùng ba view, tư thế và chỉ thị (22 tick: chunk khởi động lạnh và lệnh đầu tiên của chunk độ sâu 1) thông qua các pipeline đã lưu, trên các khung hình thô không có chúng, và với hai môi trường có chỉ thị khác nhau trong một batch. Kiểm tra mô hình nhỏ lặp lại việc kiểm tra trên CPU đối với Session của praxis.

Hạn chế: không có mô phỏng bộ khung YAM, do đó không có bộ kiểm thử vòng kín; forward (fine-tuning) chỉ hỗ trợ một cánh tay, vì kho praxis chưa có công thức huấn luyện hai cánh tay.

Huấn luyện

lerobot-train tinh chỉnh chính sách theo mục tiêu của kho praxis (praxis/train): mất khớp dòng chung của video và các hành động, dropout văn bản và cảm biến vị trí, số hạng cân bằng chuỗi MoE và cập nhật thiên lệch định tuyến sau mỗi bước tối ưu hóa. Với cùng một cửa sổ và các lần rút ngẫu nhiên, PraxisPolicy.forward bằng nhau từng bit với mục tiêu của trình huấn luyện praxis trên checkpoint đã phát hành. Một cửa sổ là 93 khung hình liên tiếp (các khối 21, 24, 24, 24) từ cả hai camera, kèm theo tư thế flange quan sát được và tư thế flange được lệnh của mỗi khung hình, cùng với lệnh; chính sách khai báo điều này thông qua observation_delta_indices / action_delta_indices (93 khung hình) và giữ các cửa sổ bên trong các tập dữ liệu bằng drop_n_last_frames (93, để trình lấy mẫu rút các điểm bắt đầu cửa sổ của công thức). Các ô camera tuân theo quy tắc canvas của checkpoint (video.antialias), giống như trong module dữ liệu praxis. forward chạy dưới các phép tính số của praxis bất kể trình khởi chạy cài đặt gì: không có autocast (điểm số bộ định tuyến MoE vẫn là float32), không có TF32 trong các phép nhân ma trận float32. Số lượng cửa sổ huấn luyện đã thấy là một bộ đệm của chính sách (train_counter): nó khởi tạo các lần rút, di chuyển cùng checkpoint và adapter, và một chạy tiếp tục sẽ nối tiếp chuỗi; một đánh giá giữ lại không làm tăng nó.

Dữ liệu

Công thức huấn luyện trên DROID. lerobot/droid_1.0.1 lưu trữ tư thế Cartesian dưới dạng sáu cộng một cột; các cột observation.state.cartesian và action.cartesian 7 chiều của PR #11 đã lắp ráp sẵn chúng (dùng --dataset.revision=refs/pr/11 cho đến khi được hợp nhất). Các cột observation.state và action của chính bộ dữ liệu là không gian khớp; bản đồ đổi tên đặt các cột Cartesian vào vị trí của chúng (một khóa được đổi tên sẽ thay thế một khóa hiện có) và hai camera dưới các khóa mà chính sách đọc:

RENAME='{"observation.state.cartesian":"observation.state","action.cartesian":"action",
"observation.images.exterior_1_left":"observation.images.exterior","observation.images.wrist_left":"observation.images.wrist"}'

lerobot-train áp dụng map lên batch thô và một lần nữa bên trong pipeline của processor, vì vậy nó không được hoán đổi các key (việc ánh xạ observation.state sang tên khác sẽ bị hoàn tác).

Khoảng một nửa số episode của DROID không có instruction và một số ngắn hơn một window; công thức loại bỏ chúng. examples/praxis/select_droid_episodes.py ghi danh sách cho --dataset.episodes:

python examples/praxis/select_droid_episodes.py --repo-id lerobot/droid_1.0.1 \
    --revision refs/pr/11 --out droid_episodes.json

Bản sao trên Hub lưu trữ video 180x320; checkpoint được huấn luyện trên các bản ghi DROID 1280x720. Các tile là các bản upscale có ít chi tiết hơn trên bản sao Hub, điều này là chấp nhận được cho một smoke test. Để fine-tune trung thực, hãy xây dựng một bản sao cục bộ với các video thô như được mô tả trong praxis/train/README.md của kho praxis, và trỏ --dataset.root đến nó.

Fine-tune toàn bộ

Trọng số ở dạng bfloat16; cấu hình tối ưu hóa praxis_adamw là AdamW với làm tròn ngẫu nhiên (AdamW thông thường sẽ làm tròn các cập nhật 3e-6 đi mất), bộ lập lịch là làm nóng tuyến tính và suy giảm cosine xuống 3e-7, và mỗi khối transformer tính lại tiến trình thuận trong bước ngược (activation_checkpointing, bật theo mặc định). Trọng số, gradient và các moment của bộ tối ưu chiếm 8 byte cho mỗi tham số, tương đương 218 GB cho mô hình 27.2B, được phân bổ trên các GPU bởi FSDP: một lần tinh chỉnh đầy đủ cần ít nhất 4 x 80 GB. Công thức praxis dùng 96 cửa sổ mỗi bước trong 1.200 bước; trên 8 GPU, điều đó tương đương --batch_size=1 --accelerator.gradient_accumulation.steps=12. lerobot-train đếm các micro-batch (một bước vòng lặp là một batch trên mọi GPU) và cập nhật bộ lập lịch theo từng micro-batch, do đó 1.200 lần cập nhật tương ứng với --steps=14400, trong đó làm nóng và suy giảm được tính theo micro-bước.

torchrun --nproc-per-node=8 $(which lerobot-train) \
    --dataset.repo_id=lerobot/droid_1.0.1 --dataset.revision=refs/pr/11 \
    --dataset.episodes="$(cat droid_episodes.json)" --rename_map="$RENAME" \
    --policy.path=runwayml/praxis-1-droid-lerobot --policy.device=cuda --policy.push_to_hub=false \
    --parallelism.dp_shard=8 --accelerator.fsdp.mixed_precision_policy.reduce_dtype=float32 \
    --batch_size=1 --accelerator.gradient_accumulation.steps=12 --steps=14400 \
    --policy.scheduler_warmup_steps=600 --policy.scheduler_decay_steps=14400 \
    --num_workers=8 --save_freq=100 --output_dir=outputs/train/praxis_droid

Một lần lưu trữ chứa mô hình phân mảnh 54 GB (pretrained_model/, có thể tải bằng PraxisPolicy.from_pretrained và lerobot-eval) cùng khoảng 108 GB trạng thái optimizer. PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True tránh phân mảnh bộ cấp phát, giống như trong praxis trainer.

Đo trên 8 x H100 80 GB với praxis-1-droid, một cửa sổ trên mỗi GPU và --dataset.episodes là 256 tập DROID (các video trên Hub), 1.000 bước tối ưu hóa: 3,7 giây mỗi bước sau bước đầu tiên (bước này biên dịch các kernel), 48,5 GB bộ nhớ GPU trên mỗi rank, bộ nạp dữ liệu theo kịp với 8 worker trên mỗi rank. Mất giảm từ 0,216 trong 100 bước đầu xuống 0,190 trong 100 bước cuối (video từ 0,191 xuống 0,171, hành động từ 0,025 xuống 0,019). Một checkpoint lưu mô hình phân mảnh và trạng thái tối ưu hóa trong khoảng hai phút thông qua FSDP. Checkpoint đã tinh chỉnh đạt 50/56 trên droid_guard so với 54 của mô hình gốc: các video trên Hub là bản upscale 180x320, do đó việc tinh chỉnh trên chúng làm chính sách lệch khỏi các bản ghi 1280x720 mà nó được huấn luyện.

LoRA

Adapters thông qua PEFT (pip install -e ".[peft]"). Các mục tiêu mặc định là nhóm expert của praxis, các phép chiếu attention và MLP của action expert (PraxisPolicy.PEFT_TARGETS); các phép chiếu đầu ra attention của backbone là nhóm thứ hai, được truyền qua --peft.target_modules. Các trọng số expert của MoE không phải là các lớp tuyến tính và không nhận adapters. Khi các trọng số cơ sở bị đóng băng, một lần chạy LoRA sẽ chạy được trên ít GPU hơn:

torchrun --nproc-per-node=4 $(which lerobot-train) ... --parallelism.dp_shard=4 \
    --peft.r=16 --peft.lora_alpha=32 --output_dir=outputs/train/praxis_lora

Để --peft.full_training_modules không được đặt: giá trị mặc định modules_to_save của chính sách là bộ đếm huấn luyện, mà adapter phải mang theo (cấu hình sẽ từ chối adapter nếu thiếu nó); các module khác duy nhất mà nó chấp nhận là ba module head của rig, dành cho fine-tune từ checkpoint gốc (bên dưới). Các bias định tuyến MoE thuộc về phần gốc và được giữ cố định dưới PEFT. Đo với r 16, alpha 32 và các mục tiêu mặc định trên 4 x H100 (--parallelism.dp_shard=4): 5,5M tham số có thể huấn luyện, 2,3 giây mỗi bước với một cửa sổ trên mỗi GPU, 30 GB bộ nhớ GPU cho mỗi rank, adapter 22 MB; --parallelism.dp_replicate kết hợp với dp_shard (HSDP) cũng hoạt động tốt. Tổng loss duy trì gần 0,22 trong 500 bước vì backbone đóng băng sở hữu số hạng video; số hạng action giảm từ 0,026 xuống 0,022. Adapter của lần chạy đó đạt 52/56 trên droid_guard, được nạp lên trên phần gốc bởi lerobot-eval.

Checkpoint chứa adapter (adapter_config.json, adapter_model.safetensors); lerobot-eval nạp nó lên trên mô hình gốc thông qua --policy.path. Để có một checkpoint thuần túy cho mô phỏng, server và from_pretrained, hãy gộp adapter vào trọng số:

python examples/praxis/merge_praxis_adapter.py --base runwayml/praxis-1-droid-lerobot \
    --adapter outputs/train/praxis_lora/checkpoints/last/pretrained_model --out outputs/praxis-1-droid-lora

Sự khác biệt so với trình huấn luyện praxis

Mục tiêu, công thức cửa sổ, bộ tối ưu hóa và lịch trình là của praxis. Dữ liệu được lấy từ LeRobotDataset thay vì trình đọc tệp praxis, các lần rút ngẫu nhiên được đặt hạt giống từ hạt giống LeRobot, số lần gọi, rank và vị trí batch (do đó các giá trị loss có thể tái tạo được nhưng không khớp từng bước với một lần chạy praxis), và các checkpoint là checkpoint của LeRobot. Chưa được chuyển đổi: chế độ overfit với các lần rút cố định và no_sync.

Tinh chỉnh checkpoint gốc

praxis-1-base ("embodiment": "base", runwayml/praxis-1-base-lerobot) là video backbone và phần thân của action-expert ở cuối quá trình pre-training, không bao gồm sáu tensor head của một rig (action_encoder.w1, embed_proprio, head, weights và biases) và không có optimizer state. Nó không được load như một policy; hai script chuyển đổi nó thành điểm bắt đầu của một fine-tune cho rig single-arm của bạn, đó là dạng LeRobot của compute_norm_stats.py và init_heads.py trong kho praxis:

# the normalization statistics of your data: 1 % / 99 % quantiles of the relative actions and the
# mean and std of the proprio over random training windows (no video is read)
python examples/praxis/compute_norm_stats.py --repo-id lerobot/droid_1.0.1 --revision refs/pr/11 \
    --state-key observation.state.cartesian --action-key action.cartesian \
    --episodes droid_episodes.json --n-windows 2000 --out stats.json
# the base plus six new head tensors (`--seed`) and the rig fields: a policy directory that loads
python examples/praxis/init_heads.py --base runwayml/praxis-1-base-lerobot --out outputs/praxis-1-myrig \
    --stats stats.json --tile-height 224 --tile-width 416 --antialias --link
# then the full fine-tune command above with --policy.path=outputs/praxis-1-myrig, or LoRA with the
# six new head tensors trained in full next to the adapters:
torchrun --nproc-per-node=4 $(which lerobot-train) ... --policy.path=outputs/praxis-1-myrig \
    --parallelism.dp_shard=4 --peft.r=16 --peft.lora_alpha=32 \
    --peft.full_training_modules='["train_counter","action_expert.action_encoder.w1","action_expert.embed_proprio","action_expert.head"]'

Các cột state và action chứa tư thế DROID và kẹp [x, y, z, roll, pitch, yaw, gripper] cho mỗi khung hình (các cột riêng của bộ dữ liệu, hoặc một bản đồ đổi tên). --stats-from <single-arm checkpoint> sao chép một khối chuẩn hóa có sẵn thay thế (bộ khung DROID). Bộ khung DROID được xây dựng lại từ cơ sở và thống kê của checkpoint đã phát hành có cấu hình chính xác như praxis-1-droid, và các tensor đầu là những tensor của init_heads.py trong kho praxis cho cùng một seed, khớp từng bit. Trên tập con DROID của các lần chạy ở trên, compute_norm_stats.py tái tạo thống kê của checkpoint trong phạm vi 0,01 m trên các phân vị xyz với kẹp được cố định ở 0 và 1. Lần fine-tune cơ sở riêng của kho praxis (configs/finetune_base.yaml, một ngày trên 8 GPU) đạt 62,5 % trên droid_guard từ cơ sở này, so với 91 % của praxis-1-droid được huấn luyện với khoảng 40 lần số cửa sổ: cơ sở là điểm khởi đầu hướng dẫn cho một bộ khung mới, không phải là sự thay thế cho checkpoint đã phát hành. Lần fine-tune đầy đủ huấn luyện mọi trọng số ở optimizer_lr; dưới LoRA, các adapter và sáu tensor đầu được huấn luyện (PraxisPolicy.PEFT_HEAD_MODULES là các module duy nhất ngoài bộ đếm mà full_training_modules chấp nhận) và phần còn lại của thân mạng giữ nguyên; các bước warm-up chỉ cho đầu và hệ số học cho đầu trong công thức praxis không được chuyển sang.

Hạn chế đã biết

• Hai hệ thống: checkpoint DROID một cánh tay (embodiment: single_arm) và hệ thống YAM hai cánh tay (bimanual). Fine-tuning và mô phỏng đều là một cánh tay.
• Praxis tạo ra các mục tiêu tư thế Descartes cho cánh tay robot có bộ điều khiển trở kháng; các lớp robot của LeRobot không bao gồm Franka, do đó việc sử dụng trên robot thực sẽ được thực hiện thông qua một client thực thi các mục tiêu Descartes.
• Một batch select_action chạy các môi trường của nó theo tuần tự (một lần gọi mô hình cho mỗi môi trường).
• Việc phục vụ từ xa (remote serving) không được hỗ trợ. Bộ chạy chunk mặc định (lerobot/inference/policy_runner.py) từ chối các policy có điều kiện dựa trên các quan sát trong quá khứ, trong khi Praxis lại đặt điều kiện dựa trên các khung hình của các chunk đã thực thi (current_observation_only=False trong chunk_inference_spec); bước tile cũng thay đổi kích thước các khung hình camera để khớp với canvas của checkpoint, do đó chúng sẽ không khớp với các hình dạng mà validate_chunk_input_features kiểm tra. Hãy chạy policy trong tiến trình (lerobot-eval, một robot client).