Suy Luận Robot Bất Đồng Bộ: Tách Rời Dự Đoán Hành Động và Thực Thi

TL;DR Các chính sách robot ngày càng cồng kềnh, và dự đoán các khối hành động trong tương lai thay vì một hành động tiếp theo duy nhất. Điều này dẫn đến việc robot ở trạng thái chờ trong khi chờ đợi các hành động mới để thực hiện, gây ra độ trễ đáng chú ý khi thực hiện và thiếu khả năng phản hồi. Suy luận bất đồng bộ thắt chặt vòng điều khiển, loại bỏ độ trễ khi chạy và dẫn đến kiểm soát thích ứng hơn bằng cách tách rời dự đoán hành động khỏi thực thi hành động. Trong bài đăng trên blog này, chúng ta sẽ đề cập đến những điều cơ bản đằng sau suy luận bất đồng bộ và cách nó có thể được sử dụng để cải thiện hiệu suất của các chính sách robot trong thế giới thực.

Mục lục

• Bắt đầu
• Suy luận bất đồng bộ: một cái nhìn sâu sắc
• 1. Tại sao suy luận tuần tự không hiệu quả
• 2. Suy luận bất đồng bộ, tóm tắt
• 3. Kiến trúc hệ thống
  • Robot Client
  • Policy Server
• 4. Phân tích suy luận bất đồng bộ
• 5. Sử dụng bất đồng bộ trong thiết lập của bạn
• Kết luận

Bắt đầu

Bắt đầu với suy luận bất đồng bộ bằng cách làm theo hướng dẫn của chúng tôi.

Suy luận tuần tự (đầu tiên) so với suy luận bất đồng bộ (thứ hai). Cho phép lập kế hoạch lại và vòng điều khiển chặt chẽ hơn, suy luận bất đồng bộ dẫn đến (1) các nỗ lực phục hồi và (2) tăng tốc ~ 2 lần trong việc hoàn thành nhiệm vụ. Suy luận tuần tự tiếp tục thực hiện khối hành động hiện tại ngay cả sau khi không nắm bắt được đối tượng, trong khi suy luận bất đồng bộ có thể lập kế hoạch lại và thực hiện khối hành động mới. Cả hai thiết lập đều sử dụng cùng một chính sách!

Suy luận bất đồng bộ: một cái nhìn sâu sắc

Với suy luận bất đồng bộ, chúng ta tách rời thực thi hành động khỏi dự đoán hành động. Điều này đặc biệt phù hợp khi xem xét xu hướng của các mô hình hiện đang phổ biến như [ACT], [OpenVLA], [PI0], và [SmolVLA] xuất ra các đoạn hành động $a_{t:t+H}$ thay vì các hành động đơn lẻ $a_t$ cho một quan sát $o_t$. Hãy tự thuyết phục mình về điều này bằng cách chạy tất cả các mô hình này bằng LeRobot.

Sử dụng các đoạn tuần tự dẫn đến (1) độ trễ khi chạy, ảnh hưởng đến thời gian thực hiện nhiệm vụ và (2) thiếu khả năng phản hồi, do hành động vòng hở rộng rãi. Suy luận bất đồng bộ tránh giảm thiểu cả hai hạn chế này bằng cách tách rời dự đoán hành động khỏi thực thi hành động. Chúng tôi đã giới thiệu suy luận bất đồng bộ trong SmolVLA và thấy rằng nó dẫn đến tốc độ tăng tốc ~ 2 lần trong thời gian hoàn thành nhiệm vụ với tỷ lệ thành công nhiệm vụ tương đương.

Đặc biệt, chúng ta thiết kế một hệ thống gồm 2 thành phần, trong đó suy luận chính sách và thực thi hành động được thực hiện trong hai quy trình khác nhau, có thể trên hai máy khác nhau được kết nối thông qua mạng:

• Một PolicyServer, được lưu trữ trên phần cứng tăng tốc và có khả năng chạy suy luận bằng cách sử dụng nhiều tài nguyên tính toán hơn so với các tài nguyên được phân bổ trên một robot thế giới thực.
• Một RobotClient xếp hàng các hành động nhận được và thực hiện chúng trong khi đoạn tiếp theo đang được tính toán.

Giao tiếp giữa PolicyServer và RobotClient dựa vào gRPC, đảm bảo hiệu suất nhanh hơn ~ 5 lần so với API REST có thể so sánh được. Kết quả của tất cả những điều này là một robot không bao giờ chờ đợi suy luận.

---

1. Tại sao suy luận tuần tự không hiệu quả

Giả sử một chính sách $\pi$ ánh xạ quan sát hiện tại $o_t$ sang một chuỗi gồm $H$ các hành động trong tương lai. Về mặt hình thức, $\pi : \mathcal{O} ;\mapsto; \mathcal{A}, \mathbf{A}t = \begin{pmatrix} a{t}, & a_{t+1}, & \dots & a_{t+H} \end{pmatrix} = \pi(o_t)$.

Do đó, một vòng điều khiển truyền thống sẽ bao gồm các bước sau:

1. Chụp $o_t$.
2. Chạy $\pi(o_t)$ để thu được $\mathbf{A}_t = \pi(o_t)$.
3. Xếp hàng $\mathbf{A_t}$ và bắt đầu hành động bật các hành động từ hàng đợi.
4. Nếu hàng đợi trống, hãy đợi $\mathbf{A}_{t+H}$, nếu không lặp lại bước 3.

Trong bước 2, robot ở trạng thái chờ. Độ trễ tăng lên theo kích thước mô hình (và các mô hình có xu hướng ngày càng cồng kềnh theo thời gian) và có thể nhanh chóng chi phối thời gian tương tác (thường là khoảng 1 / fps), như được hiển thị trong video bên dưới (đến từ cộng đồng Discord 🤗 của chúng tôi):

Điều này trực tiếp dẫn đến (1) giảm hiệu suất về thời gian hoàn thành nhiệm vụ—robot cần phải chờ đợi đoạn hành động tiếp theo được tính toán—và (2) giảm khả năng phản hồi, do (2.1) hành động vòng hở rộng rãi trong khi các hành động có sẵn và (2.2) hoàn toàn ở trạng thái chờ trong khi chờ đoạn hành động tiếp theo.

---

2. Suy luận bất đồng bộ, tóm tắt

Hệ thống của chúng tôi loại bỏ giai đoạn chờ bằng cách chồng chéo tính toán và thực thi:

1. RobotClient phát trực tuyến quan sát mới nhất tới PolicyServer.
2. Trong khi máy chủ thực hiện suy luận, máy khách thực hiện hàng đợi hiện tại các hành động.
3. Các hành động mới đến, được hợp nhất vào hàng đợi và vòng lặp tiếp tục.

Ý tưởng chính là robot đã biết phải làm gì cho một vài bước thời gian tiếp theo, vì vậy nó có thể tiếp tục di chuyển trong khi các hành động mới đang được tính toán trên máy chủ.

Điều này dẫn đến một vòng điều khiển chặt chẽ hơn và một robot không bao giờ chờ đợi suy luận. Đến lượt nó, điều này dẫn đến tốc độ tăng tốc ~ 2 lần trong thời gian hoàn thành nhiệm vụ với tỷ lệ thành công nhiệm vụ tương đương và kiểm soát thích ứng hơn đến từ một vòng lặp chặt chẽ hơn (xem video bên dưới).

---

3. Kiến trúc hệ thống

Thành phần	Vai trò	Công nghệ
RobotClient	Chạy trên bo mạch, phát trực tuyến quan sát, duy trì hàng đợi hành động, thực hiện hành động	Python, gRPC
PolicyServer	Lưu trữ chính sách, thực hiện suy luận hàng loạt, gửi lại các đoạn hành động	Python, gRPC, có thể là phần cứng tăng tốc (GPU/TPU)

Vì gRPC dựa trên HTTP/2 và sử dụng bộ đệm giao thức, nên nó đạt được nhắn tin nhị phân độ trễ thấp và các luồng hai chiều ngay lập tức, đến lượt nó giúp chúng ta duy trì vòng điều khiển chặt chẽ hơn và độ trễ khứ hồi dưới 100ms (trên mạng cục bộ của chúng ta và lưu trữ SmolVLA trên NVIDIA RTX 4090).

RobotClient chạy trên bo mạch và phát trực tuyến các quan sát tới PolicyServer thông qua gRPC. PolicyServer chuẩn bị các quan sát nhận được để suy luận và gửi lại cho RobotClient một đoạn hành động.

Robot Client

RobotClient duy trì hàng đợi hành động cục bộ và tuân theo một chiến lược đơn giản nhưng hiệu quả: gửi một quan sát mới khi độ dài hàng đợi giảm xuống dưới ngưỡng có thể định cấu hình ((g) trong bài báo SmolVLA, chunk_size_threshold trong mã). Giá trị ngưỡng này, được biểu thị dưới dạng một phần của kích thước đoạn tối đa, hoạt động như một điều kiện kích hoạt cân bằng tải tính toán với khả năng phản hồi.

Từ góc độ của máy khách, quá trình diễn ra như sau:

1. Giám sát hàng đợi: Máy khách liên tục theo dõi độ dài hàng đợi hành động của nó so với tham số ngưỡng kích thước đoạn. Khi hàng đợi giảm xuống dưới ngưỡng này, nó báo hiệu rằng một quan sát mới nên được gửi để xử lý.
2. Phát trực tuyến quan sát: Khi điều kiện ngưỡng được đáp ứng, máy khách chụp quan sát hiện tại và phát trực tuyến nó đến PolicyServer qua gRPC. Điều quan trọng là, các quan sát được phát trực tuyến thay vì được gửi qua RPC một ngôi vì chúng thường vượt quá kích thước tin nhắn tối đa là 4MB (nhiều ảnh chụp camera ở độ phân giải cao dẫn đến điều này).
3. Tổng hợp đoạn hành động: Khi một đoạn hành động mới đến từ máy chủ, máy khách sẽ hợp nhất nó với bất kỳ hành động còn lại nào trong hàng đợi hiện tại trên phần chồng chéo. Đây là nơi bộ tổng hợp tùy chỉnh phát huy tác dụng, xử lý các phần chồng chéo giữa đoạn hiện tại và đoạn đến khác nhau. Hiện tại, chúng ta hỗ trợ tổng hợp linh hoạt giữa các đoạn thông qua đặc tả của một hàm aggregate_fn(chunk1: torch.Tensor, chunk2: torch.Tensor) -> torch.Tensor tùy chỉnh, được gọi cho mỗi bước thời gian chồng chéo và có thể do người dùng cung cấp.

Các phần chồng chéo (được hiển thị bằng màu xanh nhạt trong sơ đồ) cần được xử lý cẩn thận. Chúng ta có thể thiết kế các chiến lược tổng hợp khác nhau:

• Thay thế: Chỉ cần thay thế các hành động chồng chéo bằng các dự đoán mới hơn
• Pha trộn có trọng số: Kết hợp các hành động chồng chéo bằng cách sử dụng trọng số thời gian (các hành động gần hơn có trọng số cao hơn)

Hệ thống này có khả năng cấu hình cao, vì ngưỡng kích thước đoạn có thể được điều chỉnh dựa trên độ trễ mạng, thời gian suy luận mô hình và khả năng phản hồi mong muốn. Ngưỡng thấp hơn có nghĩa là cập nhật thường xuyên hơn (và chi phí tính toán cao hơn), trong khi ngưỡng cao hơn làm giảm chi phí giao tiếp với chi phí có thể gây ra tình trạng đói hàng đợi. Cuối cùng, chúng ta thường nhận các hành động từ PolicyServer trong một luồng và thực hiện chúng trong một luồng khác. Điều này giúp máy khách luôn lắng nghe các đoạn đến trong một luồng riêng biệt, mà không chặn thực thi và luôn tiêu thụ đoạn hiện tại cho đến khi một đoạn mới có sẵn hoàn toàn.

Policy Server

Khi nhận được các quan sát từ RobotClient, PolicyServer nhận các quan sát từ RobotClient và thực hiện quá trình làm sạch quan sát cần thiết để làm cho các quan sát nhận được sẵn sàng cho suy luận. Quá trình này được minh họa trong hình ảnh bên dưới:

Sau khi quan sát đã được chuẩn bị, nó được so sánh với quan sát cuối cùng được sử dụng để suy luận. Điều này tránh sụp đổ thành một vòng lặp, trong đó các quan sát rất giống nhau được xử lý, do đó kích hoạt suy luận không cần thiết và các hành động tương tự đang được thực hiện (đến lượt, dẫn đến các quan sát rất giống nhau được xử lý lại). Chúng ta so sánh các quan sát về độ tương đồng không gian khớp của chúng, cung cấp cho chúng ta một cách gần đúng và nhanh chóng để đo lường những thay đổi trong robot. Rõ ràng, số liệu này không thích ứng với những thay đổi động trong môi trường (một đối tượng thay đổi vị trí hoặc các nhiễu loạn được áp dụng), nhưng chúng tôi thấy rằng nó là một sự đánh đổi tốt cho phần lớn các trường hợp và rất hiệu quả trong việc tránh suy luận không cần thiết và sụp đổ trạng thái. Điều quan trọng là, RobotClient vẫn giữ quyền kiểm soát việc một quan sát nhất định có phải được xử lý hay không, để tránh bế tắc. Các quan sát do máy khách gửi và được gắn thẻ với must_go=True được xử lý bất kể số liệu tương đồng.

Cuối cùng, để đảm bảo PolicyServer luôn xử lý quan sát có sẵn mới nhất, chúng ta chặn các quan sát đến cho đến khi quan sát trước đó đã được xử lý thành công. Trong đó, chúng ta tận dụng hàng đợi trên PolicyServer để đảm bảo các quan sát đến không được xếp hàng đợi cho đến khi máy chủ sẵn sàng xử lý chúng (xem bên dưới).

---

4. Phân tích suy luận bất đồng bộ

Đối với tất cả các mục đích thực tế, trong suy luận bất đồng bộ, có hai thang thời gian quan trọng:

• Bước môi trường environment_dt = 1/fps, mô tả robot có thể thực hiện một hành động nhanh như thế nào.
• Độ trễ suy luận inference_time: chuyển tiếp + khứ hồi mạng. Chúng ta có thể giả định khứ hồi mạng là không đáng kể so với thời gian suy luận chính sách, mặc dù điều này có thể không đúng đối với mọi thiết lập.

Điều quan trọng là, tỷ lệ $c = \frac{\texttt{environment_dt}}{\texttt{inference_time}}$ dẫn đến các hành vi khác nhau:

• $c \ll 1$: môi trường phát triển nhanh hơn suy luận. Trong kịch bản này, hàng đợi trống nhanh chóng và chúng ta thoái hóa thành điều khiển tuần tự.
• $c \ge 1$: máy chủ theo kịp. Hàng đợi luôn (gần như) đầy.

Điều quan trọng là, $c$ ảnh hưởng đến số lượng hành động có sẵn trong hàng đợi tại bất kỳ thời điểm nào. Để tránh giới hạn điều khiển tuần tự đã đề cập ở trên, người ta có thể:

1. Sử dụng nhiều tính toán hơn cho máy chủ chính sách, lưu trữ máy chủ trên GPU, giảm inference_time như một hệ quả của việc phân bổ nhiều tài nguyên tính toán hơn.
2. Gửi các quan sát đến máy chủ thường xuyên hơn, gửi một quan sát mới khi độ dài hàng đợi $k$ giảm xuống dưới phần $g = k/H$ của kích thước tối đa của nó.
   • $g=0$ tái tạo suy luận tuần tự (hàng đợi trống, chờ).
   • $g=1$ gửi một quan sát mỗi bước thời gian (tính toán tối đa, độ trễ tối thiểu).

Các thí nghiệm (xem các đồ thị bên dưới) cho thấy rằng $g\approx0.7$ cung cấp một sự đánh đổi tốt khi các quan sát được gửi không được lọc ra (tất cả chúng đều phải đi). Chúng ta khuyên bạn nên đặt $g=0.5$ và làm theo tài liệu của chúng tôi để điều chỉnh tham số này cho phù hợp với nhu cầu của bạn.

---

5. Sử dụng bất đồng bộ trong thiết lập của bạn

Suy luận bất đồng bộ là một cách đơn giản nhưng hiệu quả để cải thiện hiệu suất của các chính sách robot. Trong các thí nghiệm của chúng tôi sử dụng SmolVLA, suy luận bất đồng bộ dẫn đến tăng tốc ~ 2 lần trong thời gian hoàn thành nhiệm vụ với tỷ lệ thành công nhiệm vụ tương đương và kiểm soát thích ứng hơn đến từ một vòng lặp chặt chẽ hơn.

Để chạy chính sách của bạn bằng suy luận bất đồng bộ, bạn chỉ cần làm theo hướng dẫn của chúng tôi với các tham số tùy chỉnh của riêng bạn (ví dụ: đường dẫn chính sách hoặc ngưỡng kích thước đoạn). Suy luận bất đồng bộ đi kèm với hỗ trợ cho các chính sách hỗ trợ chia đoạn hành động!

---

Kết luận

Chúng tôi đã giới thiệu suy luận bất đồng bộ, một cách đơn giản nhưng hiệu quả để cải thiện hiệu suất của các chính sách robot. Trong các thí nghiệm của chúng tôi sử dụng SmolVLA, suy luận bất đồng bộ dẫn đến tăng tốc ~ 2 lần trong thời gian hoàn thành nhiệm vụ với tỷ lệ thành công nhiệm vụ tương đương và kiểm soát thích ứng hơn đến từ một vòng lặp chặt chẽ hơn.

Chúng tôi rất vui mừng chia sẻ công việc này với cộng đồng và xem nó có thể được sử dụng để cải thiện hiệu suất của các chính sách robot như thế nào. Chúng tôi hoan nghênh PR để cải thiện và mở rộng khung suy luận bất đồng bộ tại huggingface/lerobot và sẵn sàng thảo luận thêm về điều này trong cộng đồng Discord của chúng tôi, 🤗.

Link bài viết gốc

• Tags:
• Ai
• July 10, 2025
• Huggingface.co