非同步推論

透過我們的 SmolVLA，我們引進了一種在真實世界機器人上執行推論的新方法，即將動作預測與動作執行解耦 (decoupling)。在本教學中，我們將示範如何使用經微調的 SmolVLA 版本以及所有 LeRobot 支援的策略來使用非同步推論 (async inference)。歡迎嘗試使用所有 LeRobot 支援的策略進行非同步推論！

您將學到：

1. 為什麼非同步推論很重要，以及它與較傳統的順序推論相比有何差異。
2. 如何啟動 PolicyServer 並在同一台機器（甚至跨網路）連接 RobotClient。
3. 如何針對您的機器人與策略調整關鍵參數（actions_per_chunk、chunk_size_threshold）。

如果您遇到困難，歡迎加入我們的 Discord 社群！

總而言之：透過非同步推論，您的機器人在策略伺服器忙於計算下一批動作片段 (chunk of actions) 時仍能持續運作——消除了「等待推論」造成的延遲，並解鎖了更流暢、反應更靈敏的行為。這與同步推論 (sync) 有本質上的不同，在同步推論中，當策略計算下一批動作片段時，機器人會處於閒置狀態。

開始使用非同步推論

您可以在我們的 部落格文章 中閱讀更多關於非同步推論的資訊。本指南旨在協助您快速在您的環境中設定並執行非同步推論。

首先，使用 async 標籤安裝 lerobot，以安裝執行非同步推論所需的額外依賴套件。

pip install -e ".[async]"

接著，啟動策略伺服器（在一個終端機中，或是在另一台機器上），並指定客戶端要連接的主機位址與連接埠。您可以透過以下方式啟動策略伺服器：

python -m lerobot.async_inference.policy_server \
     --host=127.0.0.1 \
     --port=8080

這將啟動一個監聽 127.0.0.1:8080（localhost，連接埠 8080）的策略伺服器。此時，策略伺服器是空的，因為所有關於要執行哪種策略以及使用哪些參數的資訊，都會在與客戶端進行第一次交握時指定。接著，啟動客戶端：

python -m lerobot.async_inference.robot_client \
    --server_address=127.0.0.1:8080 \ # SERVER: the host address and port of the policy server
    --robot.type=so100_follower \ # ROBOT: your robot type
    --robot.port=/dev/tty.usbmodem585A0076841 \ # ROBOT: your robot port
    --robot.id=follower_so100 \ # ROBOT: your robot id, to load calibration file
    --robot.cameras="{ laptop: {type: opencv, index_or_path: 0, width: 1920, height: 1080, fps: 30}, phone: {type: opencv, index_or_path: 0, width: 1920, height: 1080, fps: 30}}" \ # POLICY: the cameras used to acquire frames, with keys matching the keys expected by the policy
    --task="dummy" \ # POLICY: The task to run the policy on (`Fold my t-shirt`). Not necessarily defined for all policies, such as `act`
    --policy_type=your_policy_type \ # POLICY: the type of policy to run (smolvla, act, etc)
    --pretrained_name_or_path=user/model \ # POLICY: the model name/path on server to the checkpoint to run (e.g., lerobot/smolvla_base)
    --policy_device=mps \ # POLICY: the device to run the policy on, on the server (cuda, mps, xpu, cpu)
    --actions_per_chunk=50 \ # POLICY: the number of actions to output at once
    --chunk_size_threshold=0.5 \ # CLIENT: the threshold for the chunk size before sending a new observation to the server
    --aggregate_fn_name=weighted_average \ # CLIENT: the function to aggregate actions on overlapping portions
    --debug_visualize_queue_size=True # CLIENT: whether to visualize the queue size at runtime

總結來說，您需要為以下項目指定指令：

• SERVER：策略伺服器的位址與連接埠
• ROBOT：要連接的機器人類型、連接埠，以及機器人的本地 id
• POLICY：要執行的策略類型，以及伺服器上檢查點 (checkpoint) 的模型名稱/路徑。您還需要指定伺服器應使用的裝置，以及一次輸出的動作數量（上限為策略設定的最大動作值）。
• CLIENT：在向伺服器發送新的觀測資料之前的片段大小閥值 (threshold)，以及在重疊部分聚合動作的函式。您可以選擇性地在執行階段視覺化佇列大小，以協助您調整 CLIENT 參數。

重要的是，

• actions_per_chunk 與 chunk_size_threshold 是您的設定中需要調整的關鍵參數。
• aggregate_fn_name 是在重疊部分聚合動作的函式。您可以將新的函式加入函式註冊表，或在 robot_client.py 中加入您自己的函式（請參閱 此處）
• debug_visualize_queue_size 是調整 CLIENT 參數的實用工具。

完成！您現在應該可以看到您的機器人開始移動了 😉

非同步與同步推論

同步推論依賴於交替進行動作片段預測與動作執行。這本質上會導致閒置影格 (idle frames)，即機器人處於閒置狀態等待策略輸出的影格：一個新的動作片段。反過來說，推論會受到明顯的即時延遲困擾，因為缺乏可用的動作，機器人會暫停運作。隨著機器人模型規模越來越大，這個問題風險只會變得更嚴重。

同步推論會使機器人在策略計算下一批動作片段時處於閒置狀態。

為了克服這一點，我們設計了非同步推論，這是一種將動作規劃與執行解耦的範式，結果是 (1) 更高的適應性，以及最重要的 (2) 沒有閒置影格。關鍵在於，透過非同步推論，下一個動作片段會在目前片段耗盡之前計算出來，從而實現零閒置。更高的適應性是透過在重疊部分聚合不同的動作片段來確保的，從而獲得最新的計畫與更緊密的控制迴路。

非同步推論不會造成閒置，因為下一個片段在目前片段耗盡之前就已經計算完成了。

啟動策略伺服器

策略伺服器是 PreTrainedPolicy 的封裝器，使其能與來自機器人客戶端的觀測資料對接。策略伺服器初始化為空的容器，並會在機器人客戶端與策略伺服器之間的初始交握時，載入所要求的策略。因此，啟動策略伺服器就像指定主機位址與連接埠一樣簡單。如果您是在與機器人客戶端相同的機器上執行策略伺服器，可以使用 localhost 作為主機位址。

python -m lerobot.async_inference.policy_server \
     --host=127.0.0.1 \
     --port=8080

這會在 localhost:8080 進行監聽，等待來自關聯 RobotClient 的連線，該客戶端會在第一次客戶端-伺服器交握期間溝通要執行的策略。

啟動機器人客戶端

RobotClient 是 Robot 實例的封裝器，負責將機器人連接到（可能是遠端的）PolicyServer。RobotClient 會將觀測資料串流傳送給 PolicyServer，並接收在伺服器上進行推論後獲得的動作片段（我們假設伺服器擁有比機器人控制器更強大的運算資源）。

python -m lerobot.async_inference.robot_client \
    --server_address=127.0.0.1:8080 \ # SERVER: the host address and port of the policy server
    --robot.type=so100_follower \ # ROBOT: your robot type
    --robot.port=/dev/tty.usbmodem585A0076841 \ # ROBOT: your robot port
    --robot.id=follower_so100 \ # ROBOT: your robot id, to load calibration file
    --robot.cameras="{ laptop: {type: opencv, index_or_path: 0, width: 1920, height: 1080, fps: 30}, phone: {type: opencv, index_or_path: 0, width: 1920, height: 1080, fps: 30}}" \ # POLICY: the cameras used to acquire frames, with keys matching the keys expected by the policy
    --task="dummy" \ # POLICY: The task to run the policy on (`Fold my t-shirt`). Not necessarily defined for all policies, such as `act`
    --policy_type=your_policy_type \ # POLICY: the type of policy to run (smolvla, act, etc)
    --pretrained_name_or_path=user/model \ # POLICY: the model name/path on server to the checkpoint to run (e.g., lerobot/smolvla_base)
    --policy_device=mps \ # POLICY: the device to run the policy on, on the server
    --actions_per_chunk=50 \ # POLICY: the number of actions to output at once
    --chunk_size_threshold=0.5 \ # CLIENT: the threshold for the chunk size before sending a new observation to the server
    --aggregate_fn_name=weighted_average \ # CLIENT: the function to aggregate actions on overlapping portions
    --debug_visualize_queue_size=True # CLIENT: whether to visualize the queue size at runtime

以下兩個參數在每個設定中都是關鍵：

不同的 `actions_per_chunk` 與 `chunk_size_threshold` 值確實會導致不同的行為。

一方面，增加 actions_per_chunk 的值會降低沒有動作可執行的可能性，因為在計算出新的片段時會有更多的動作可用。然而，較大的 actions_per_chunk 值也可能導致動作精確度下降，這是因為在較長的時間跨度內預測動作會導致累積誤差。

另一方面，增加 chunk_size_threshold 的值會導致更頻繁地向 PolicyServer 發送觀測資料以進行推論，從而產生更多更新的動作片段，並在重要部分產生重疊。這會帶來高度的適應性，極限情況下是每個觀測資料都預測一個動作片段，這反過來又是在產生新片段的同時僅消耗邊際部分。由於請求數眾多，此選項也會對推論管線造成更大的壓力。相反地，接近 0.0 的 chunk_size_threshold 值會退化為同步的邊緣情況，即只有在當前片段耗盡時才會發送新的觀測資料。

我們發現預設的 actions_per_chunk 與 chunk_size_threshold 值在我們為 SmolVLA 論文 開發的實驗中表現良好，但建議嘗試不同的數值，以找到最適合您設定的參數。

為您的設定調整非同步推論

1. 謹慎選擇您的運算資源。 PI0 在推論時佔用 14GB 記憶體，而 SmolVLA 僅需約 2GB。您應該考慮較小的策略需要較少的運算資源，並為您的使用案例識別出最佳的運算資源。策略與所用裝置（CPU 密集型、使用 MPS，或給定 NVIDIA GPU 上的 CUDA 核心數量）的組合，會直接影響您預期的平均推論延遲。
2. 根據推論延遲調整您的 fps。 當伺服器產生新的動作片段時，客戶端並非閒置，而是正在執行當前的動作佇列。如果這兩個程序發生的速度完全不同，客戶端的佇列可能會變空。因此，如果您持續遇到佇列中沒有動作的情況，您應該降低 fps。
3. 調整 chunk_size_threshold.
   • 越接近 0.0 的值會產生幾乎順序的行為。越接近 1.0 → 每個步驟都發送觀測資料（頻寬需求較高，依賴良好的世界模型）。
   • 我們發現 0.5-0.6 左右的數值效果很好。如果您想調整此參數，請啟動一個將 --debug_visualize_queue_size 設為 True 的 RobotClient。這將會在執行階段繪製動作佇列大小的演變，您可以用它來找到最適合您設定的 chunk_size_threshold 值。

當傳入 `--debug_visualize_queue_size` 旗標時，動作佇列大小會在執行階段繪製，以對應不同等級的 `chunk_size_threshold`（SmolVLA 論文中的 `g` 值）。

結論

非同步推論代表了即時機器人控制的一項重大進展，解決了長期以來困擾機器人應用的推論延遲這一基本挑戰。透過本教學，您已學會如何實作完整的非同步推論管線，消除了閒置影格，並使機器人行為更流暢、更具反應性。

關鍵要點

• 範式轉移：非同步推論將動作預測與執行解耦，允許機器人在平行計算新的動作片段時持續運作
• 效能優勢：消除了同步方法中固有的「等待推論」延遲，這隨著策略模型越來越大變得日益重要
• 靈活架構：伺服器-客戶端設計實現了分散式運算，可以在強大的遠端硬體上執行推論，同時保持即時的機器人控制
• 可調參數：成功取決於針對您的特定硬體、策略與任務需求正確配置 actions_per_chunk 與 chunk_size_threshold
• 通用相容性：適用於所有 LeRobot 支援的策略，從輕量級 ACT 模型到如 SmolVLA 等視覺語言模型

請嘗試使用預設參數進行實驗，監控您的動作佇列大小，並反覆調整您的設定，以針對您的特定使用案例實現最佳效能。如果您想進一步討論，歡迎加入我們的 Discord 社群，或在我們的 GitHub 儲存庫上開一個 Issue。