APXInf 是什麼？機器人端側推理提速，26 毫秒數字該怎麼看

機器人看見環境變化後，模型還要把影像等觀測資料轉成下一步動作。如果推理耗時太長，即使模型能做出合理決策，動作也可能跟不上現場。APXInf 處理的就是這段「觀測輸入到模型輸出動作」的等待時間：它是無問芯穹（Infinigence AI）聯合清華大學、上海交通大學開源的具身 AI 端側推理引擎，讓模型更貼近機器人的感測器與執行裝置運行；它本身並不是負責驅動馬達的控制器。144

Rust 與 Python 各做什麼？

APXInf 以精簡的 Rust 執行環境管理推理執行、記憶體與資源，並提供 Python 介面，讓開發者能從熟悉的機器人程式呼叫模型。耗時的運算則交由底層算子處理。這種分工瞄準的不只是單次運算速度，也包括長時間部署時的資源管理與延遲可預測性。381

移植模型並非把權重載入新引擎就算完成。其文件描述的工作流程，是先固定作為對照的模型檢查點與測試輸入，核對移植版本的輸出及中間數值，再進一步最佳化。這有助於避免只看見速度提升，卻漏掉模型運算結果已經改變。35

延遲從哪裡省下來？

APXInf 的最佳化涵蓋整條推理路徑，而非只加快某一道運算：

• **Pipeline（流程排程）：**檢視各處理階段的銜接，減少整體等待時間。
• **Graph（運算圖）：**透過擷取並重複使用運算圖及緩衝區，降低反覆設定的成本。
• **Kernel（運算核心）：**針對耗時操作調校 GPU 算子。
• **量化：**視模型與硬體條件使用 FP8、INT8 等較低精度格式，以減少運算量與記憶體資料搬移。835

這些做法的目標，是讓機器人在收到新觀測後更快取得模型產生的動作，而不是保證任何機器人都能達到相同控制頻率。85

Jetson Thor 的「26 毫秒」代表什麼？

發布時的比較指出，π0.5 模型以 FP8 精度在 Jetson Thor 上，端到端推理延遲由未最佳化基準的 278 毫秒降至 26 毫秒以內，約為 10.7 倍的延遲改善；公布的推理頻率是 38.46 Hz，也就是約每秒 38.46 次推理。若單純以 278 毫秒換算，基準約為每秒 3.6 次。這裡的「端到端」指公布的推理測試範圍，不能直接等同於相機擷取、通訊、動作執行全部算進去的機器人閉迴路頻率。869

讀數字時還有兩點要留意。部分報導曾寫成 46 Hz，但同一批報導也出現與約 26 毫秒相符的 38.46 Hz；就這項比較而言，後者是較一致的表述。6 此外，專案儲存庫所列的 Jetson AGX Thor／FP8 數據是 41.16 毫秒、24.3 Hz，並非 26 毫秒、38.46 Hz。公開資料沒有在此交代足以把兩組數字視為相同測試條件的資訊，因此不宜把它們合併成單一、普遍適用的效能承諾。58

現在能接哪些模型與設備？

發布資訊列出首批模型 π0.5、WALL-OSS，以及 RTX 4090、Jetson Orin、Jetson Thor 等運算平台。專案儲存庫對首版高度最佳化路徑的描述則更具體：重點是 Thor 與 Orin 上的 π0.5，並列有 BF16、FP8、INT8 精度選項。發布時列名支援的模型與硬體，不等於每種模型、設備、精度組合都已有相同程度的最佳化或相同延遲。65

APXInf 可視為 RLinf 生態系中的推理與部署環節，與模型訓練、評估工作銜接。其機器人端套件也提供與 OpenPI 相容的 WebSocket 服務介面，方便透過既有呼叫方式接入；「介面相容」不代表所有 OpenPI 模型檢查點都已完成移植。51

下一步與實際部署的界線

公布的路線圖涵蓋更多視覺—語言—動作模型（VLA）、視覺語言模型（VLM）及世界模型；Qwen、GR00T 被列為適配中的方向，另包括更多晶片後端與平台工作。這些是計畫，不是目前已可使用的保證。9

對準備把 APXInf 裝上機器人的團隊而言，最有用的判斷方式是：以自己的模型檢查點、輸入、精度、硬體與功耗限制重新測試。換一個條件，延遲就可能改變；單次推理變快，也不能單獨證明任務成功率，或機器人在電力、散熱限制下能持續維持同樣表現。58