May đường chạy cho robot học

May đường chạy cho robot học

Playbook triển khai robot RL: tách thử nghiệm ngắn, training dài, guardrail vận hành và tiêu chí dừng trước khi đốt GPU.

Có lần mình thấy một team robotics ngồi debug lúc gần nửa đêm, không phải vì robot té, mà vì job training chết sau nhiều giờ chạy. Log thì nằm rải rác, GPU đã ăn tiền, reward function vẫn chưa rõ có tiến bộ thật hay chỉ đang làm màu. Cảnh đó hơi đau: robot chưa kịp bước ra nhà kho, team đã vấp ngay ở lớp hạ tầng.

Điểm mình muốn chốt trong bài này: triển khai reinforcement learning cho robot không nên bắt đầu bằng câu hỏi dùng cụm GPU nào mạnh nhất, mà bằng câu hỏi workflow của bạn đang ở pha nào.

Robot học trong simulation giống như may một tấm vải dài: có đoạn cần khâu thử từng mũi, có đoạn cần đưa lên máy chạy đều nhiều giờ. Dùng cùng một cách cho cả hai pha là công thức rất nhanh để rối chỉ.

Sơ đồ minh họa cho bài May đường chạy cho robot học

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu thật: giảm vòng lặp, không khoe cụm máy

Nguồn AWS về NVIDIA Isaac Lab trên Amazon SageMaker AI đưa ra một bối cảnh đáng chú ý: physical AI đang dịch từ research sang production. Robot được train trong simulation có độ chân thực cao trước khi đem ra nhà máy, kho hàng, logistics center, vì train ngoài đời thật vừa chậm, vừa đắt, vừa có rủi ro an toàn.

Nhưng khi đưa training vào simulation tăng tốc bằng GPU, vấn đề không biến mất. Nó đổi tên thành compute orchestration — điều phối tài nguyên tính toán, driver, network, job lifecycle và health check sao cho team không phải tự chăm từng node.

Với robot reinforcement learning, hay RL — cách model học bằng phần thưởng và hình phạt qua nhiều lần thử — workflow thường có hai nhịp rất khác nhau:

  1. Vòng thử ngắn: chỉnh reward function, observation space, model architecture.
  2. Lượt train dài: chạy cấu hình đã tương đối ổn đến khi hội tụ.

Nếu bạn dùng cùng một hạ tầng, cùng checklist, cùng tiêu chí thành công cho cả hai nhịp, bạn sẽ hoặc chậm khi cần thử nhanh, hoặc mong manh khi cần chạy lâu.

Dịch sang tiếng người: đừng lấy thước đo của xưởng may hàng loạt để đánh giá bàn khâu mẫu, và cũng đừng đem cách vá thử một đường chỉ để sản xuất cả lô áo.

Checklist trước khi bấm chạy

Trước khi chọn SageMaker HyperPod, SageMaker Training Jobs, cụm tự quản, hay bất kỳ managed service nào, mình sẽ bắt team trả lời 7 câu này. Không cần họp dài; một buổi chiều là đủ để ra bản đầu.

1. Job này thuộc pha nào?

2. Tiêu chí dừng là gì?

Không có tiêu chí dừng thì training sẽ thành kiểu cứ chạy vì chưa ai dám tắt. Với RL, nên có ngưỡng về reward, stability, crash rate trong simulation, hoặc số lần không cải thiện liên tiếp.

3. Metric nào là operational, metric nào là behavior?

Operational metric là GPU utilization, job failure, queue time, cost. Behavior metric là robot đi được không, té bao nhiêu lần, có ổn trên terrain lạ không.

4. Artifact nào phải được lưu lại?

Policy checkpoint, config, seed, simulator version, reward definition, dataset hoặc scene definition. Thiếu một thứ là vài tuần sau không biết vì sao model cũ chạy tốt hơn model mới.

5. Ai có quyền scale?

Không nên để mọi experiment tự leo lên nhiều node. Quyền scale cần đi kèm budget guardrail.

6. Failure nào chấp nhận được?

Job thử chết sau 10 phút có thể ổn. Job production chết sau nhiều giờ mà không checkpoint thì không ổn.

7. Sau khi train xong, ai kiểm tra đường ra production?

Simulation chỉ là một lớp. Trước khi robot thật cử động, cần có bước kiểm tra an toàn, domain gap — khoảng lệch giữa môi trường giả lập và đời thật — và rollback plan.

Chọn compute theo pha, không theo cảm giác

AWS gợi ý hai lựa chọn trong SageMaker AI cho bài toán Isaac Lab: SageMaker HyperPod và SageMaker Training Jobs. Mình không xem đây là câu chuyện dịch vụ A tốt hơn B. Đây là câu chuyện đặt đúng loại job vào đúng mặt bằng vận hành.

| Pha triển khai | Việc chính | Hạ tầng nên ưu tiên | Dấu hiệu chọn sai |
|---|---|---|---|
| Thử reward nhanh | Chạy nhiều experiment nhỏ | Setup ít ma sát, teardown gọn | Mỗi lần đổi config phải chờ lâu |
| So sánh cấu hình | Chạy batch experiment có tracking | Job reproducible, log rõ | Không biết run nào thắng vì thiếu metadata |
| Train dài | Chạy lâu, có checkpoint | Resilience, monitoring node, phân tán tốt | Job chết là mất nhiều giờ |
| Chuẩn bị production | Kiểm định policy | Audit artifact, guardrail an toàn | Không tái tạo được kết quả cũ |

SageMaker Training Jobs hợp với kiểu đóng gói một job rõ ràng rồi chạy, tự provision tài nguyên và dọn sau khi xong. Với team nhỏ, đây thường là cách giảm gánh vận hành.

HyperPod hợp hơn khi bạn có nhu cầu distributed training dài hơi, cần cụm được quản lý với trọng tâm resilience. Nó đáng cân nhắc khi failure của node, driver, network, hoặc checkpointing bắt đầu ảnh hưởng trực tiếp đến tốc độ nghiên cứu.

Ví dụ cụ thể: giả sử team bạn 5 người đang train policy cho robot di chuyển trên nền gồ ghề. Tuần đầu, 80% việc là sửa reward vì robot học trò né lỗi rất sáng tạo: thay vì đi ổn định, nó tìm cách lắc người để ăn điểm. Lúc này, thứ bạn cần là vòng lặp ngắn và log dễ đọc, không phải ngay lập tức dựng một cụm hoành tráng. Nhưng khi reward đã ổn và mỗi lượt train kéo dài lâu, lúc đó resilience mới trở thành mũi chỉ cần gia cố.

Một buổi chiều để thử nhỏ

Nếu là mình, mình sẽ không bắt đầu bằng full pipeline. Mình sẽ làm một lát cắt dọc thật mỏng: từ config đến training job, checkpoint, metric, rồi đọc kết quả.

Bước 1: đóng gói config như artifact

Tạo một file config tối thiểu cho mỗi run. Đừng chỉ để trong notebook.

run_name: h1_rough_terrain_reward_v3
simulator: isaac_lab
policy: ppo
seed: 42
reward_version: reward_v3
max_steps: small_smoke_test
checkpoint_interval: frequent
stop_when:
  no_reward_improvement: true
  repeated_sim_crash: true

Điểm quan trọng không phải syntax. Điểm quan trọng là mọi run phải có danh tính.

Bước 2: chạy smoke test trước khi chạy dài

Smoke test là lượt chạy nhỏ để phát hiện lỗi rõ ràng: dependency sai, scene load lỗi, GPU không nhận, logging hỏng. Nếu smoke test chưa sạch, đừng scale.

Tiêu chí pass có thể rất thực dụng:

Bước 3: thêm monitoring tối thiểu

Từ bài về observability cho LLM inference trên SageMaker AI, có một ý rất đáng mượn: production AI cần nhìn cả quantity và quality. Với robot RL, mình chuyển ngữ như sau:

Một endpoint LLM có thể healthy về hạ tầng nhưng trả lời kém. Tương tự, một job robot RL có thể dùng GPU rất đẹp nhưng học hành vi vô dụng. Đừng để dashboard chỉ toàn số máy móc mà thiếu tín hiệu hành vi.

Bước 4: quyết định scale bằng cổng kiểm tra

Trước khi cho chạy dài, đặt một gate đơn giản:

Scale nếu:
- smoke test pass
- checkpoint đọc lại được
- reward không bị NaN
- log đủ để so sánh với run trước
- budget owner đã đồng ý

Dừng nếu:
- 3 run liên tiếp lỗi cùng một nhóm
- reward tăng nhưng behavior xấu hơn
- không tái tạo được run tốt nhất

Cái gate này nghe nhỏ, nhưng nó ngăn team biến cloud thành cuộn vải bị kéo bung: càng kéo càng tốn, mà không ra được áo.

Bẫy hay gặp khi đem robot RL lên managed cloud

Bẫy 1: tưởng simulation nhanh là iteration nhanh

Simulation chạy nhanh hơn đời thật không có nghĩa team ra quyết định nhanh hơn. Nếu mỗi run thiếu metadata, thiếu so sánh, thiếu tiêu chí dừng, bạn chỉ có nhiều kết quả lộn xộn hơn.

Bẫy 2: scale trước khi hiểu reward

RL rất giỏi tối ưu thứ bạn viết, không phải thứ bạn muốn. Reward function lệch thì scale chỉ giúp robot học sai nhanh hơn.

Bẫy 3: gom mọi bài toán AI vào một đường triển khai

Các nguồn liên quan của AWS cho thấy nhiều workload AI đang có lối đi rất khác nhau: object detection có thể dùng foundation model đa phương thức như Nova 2 Lite qua prompt và JSON bounding box; tabular prediction có thể dùng model chuyên cho bảng như NEXUS; inference có thể cần cross-Region routing để xử lý capacity và ràng buộc dữ liệu. Bài học cho builder: đừng mặc định cứ có AI là phải train từ đầu.

Với robot RL, training là lõi. Với object detection hoặc tabular prediction, đôi khi triển khai managed model sẵn có mới là đường ngắn hơn. Quyết định kỹ thuật tốt không phải quyết định oai nhất, mà là quyết định làm giảm rủi ro đúng chỗ.

Bẫy 4: thiếu đường về sau khi deploy

Robot khác chatbot ở một điểm lạnh gáy: output có thể thành chuyển động vật lý. Vì vậy, checkpoint, rollback, test scene, safety constraint và audit log không phải giấy tờ trang trí. Chúng là đường may mép để sản phẩm không bung khi bị kéo mạnh.

Khi nào nên scale, khi nào nên dừng

Mình sẽ scale khi có đủ bốn tín hiệu:

  1. Run nhỏ ổn định: không còn lỗi hạ tầng cơ bản.
  2. Metric hành vi đáng tin: reward đi cùng video hoặc event kiểm tra, không chỉ là con số.
  3. Artifact tái tạo được: config, seed, checkpoint, simulator version đều lưu.
  4. Chi phí có chủ: ai đó chịu trách nhiệm nhìn budget và quyết định dừng.

Mình sẽ dừng hoặc thu nhỏ khi:

Sau bài này, nếu bạn đổi cách nghĩ từ chọn công cụ triển khai sang thiết kế cổng quyết định cho từng pha training, vậy là đủ. Robot RL không thua vì thiếu compute nhiều bằng thua vì team không biết lúc nào nên thử, lúc nào nên chạy dài, lúc nào nên cắt chỉ.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo