這項由東南大學、南京大學、微軟研究院及清華大學人工智慧產業研究院聯合開展的研究，以arXiv預印本形式發布於2026年7月2日，論文編號為arXiv:2607.02501，有興趣深入了解的讀者可通過該編號查詢完整論文。
假設你家裡有一個機器人助手，它需要用眼睛看周圍的環境，用"大腦"理解你說的話，再把動作指令傳給手臂。現在問題來了——市面上這類機器人"大腦"軟體的種類越來越多，每一款都有自己的運行方式和配套工具，就像不同品牌的電器偏偏都用不同規格的插頭，你買了新設備還得換一整套插座。這種混亂狀態讓機器人的實際落地變得極其麻煩。這篇論文做的事情，就是打造一個"萬能插座"——一個名為Embodied.cpp的統一推理運行時，讓各種機器人AI模型都能順暢地插進去運行。
一、機器人AI的"插頭亂象"：為什麼現在的軟體生態一團糟
走進一家餐廳，廚房裡有炒鍋、蒸鍋、烤箱、微波爐，每一件設備處理不同的食材，服務員端盤子的節奏和廚師翻炒的節奏也完全不同。機器人AI的運行方式與此高度相似——它不是一個統一的整體，而是由若干個模組協同工作的複雜系統。
目前主流的機器人AI模型可以分成兩大家族。第一類叫做"視覺-語言-動作模型"，英文縮寫是VLA，顧名思義，它同時處理視覺資訊、語言指令，並輸出機器人的動作。第二類叫做"世界-動作模型"，英文縮寫是WAM，這類模型更進一步——它不僅要控制機器人動作，還會在腦子裡先"預測未來會發生什麼"，再根據這個預測決定怎麼動。打個比方，VLA模型像一位經驗豐富的廚師，看到食材、聽到菜名，直接下手操作；而WAM模型更像一位會下棋的大廚，在切菜之前先在腦海里推演幾步——"如果我先焯水再爆炒，效果會不會更好"。
這兩類模型目前的運行都依賴各自專屬的Python代碼棧，就像每位廚師只會用自己那套專用刀具，根本不能共用。研究團隊發現，哪怕一個模型在實驗室里表現再好，要把它真正部署到機器人上，工程師還得手寫傳感器數據的包裝代碼、給不同硬體平台寫特殊的運行路徑、在機器人控制邏輯里再拼上一堆膠水代碼。隨著模型種類越來越多，這種重複勞動只會越來越繁重。
與此同時，現有的通用AI推理框架，比如llama.cpp、ONNX Runtime、SGLang、vLLM等，都是為"問答式"場景設計的——用戶發一條請求，模型回一條回復，完成交互。但機器人運行在一個持續的閉環控制過程中，就像騎自行車，你不能騎一下停一下再騎，必須持續調整方向和力度。這種"持續閉環"與"一問一答"的本質差異，使得現有推理框架無法直接用於機器人AI部署。
二、機器人AI運行的三道"難關"：研究團隊面臨的真實挑戰
研究團隊在深入分析之後，把機器人AI部署的核心困難歸納為三個方面，每一個都需要在系統設計層面認真應對。
第一道難關是"多速度同步運行"。不同類型的機器人AI模型，其內部各個模組的運行頻率完全不同。感知攝影機數據的模組可能每隔幾幀才需要刷新一次，而機器人手臂的動作指令卻需要每秒鐘發出很多條。如果強制讓所有模組按同一個節奏運行，要麼浪費計算資源，要麼延誤了關鍵的控制信號。這就好比一個樂隊，小提琴手、打擊樂手、指揮各自有各自的節奏，不能強迫所有人同步敲擊同一個節拍。
第二道難關是"低延遲優先的閉環控制"。機器人控制對延遲極其敏感——如果AI模型的推理時間太長，機器人的反應就會滯後，動作就會出錯。更棘手的是，機器人通常運行在算力受限的邊緣設備上，比如英偉達
Jetson開發板、瑞芯微RK系列晶片、普通x86工控機等，這些設備的計算能力遠不及數據中心的伺服器。在這類硬體上做到低延遲、低抖動的實時推理，是一個真實且艱難的工程挑戰。
第三道難關是"可擴展的機器人專用接口"。機器人AI不只是輸入文字、輸出文字那麼簡單。輸入端可能包括RGB攝影機圖像、深度圖像、機器人自身的關節角度（專業叫"本體感覺"）、歷史動作記錄、力傳感器數據、觸覺傳感器數據，甚至是仿真環境提供的虛擬狀態資訊。輸出端同樣多樣，可能是離散的動作標記、連續的動作向量、一段時間窗口內的動作序列（專業叫"動作塊"）、對未來世界狀態的預測，或者是層級控制中的中間指令。一個固定的"文字進、文字出"接口根本無法承載這些需求。
三、解剖機器人AI的"大腦結構"：VLA模型與WAM模型的全景分析
在動手構建運行框架之前，研究團隊首先系統梳理了現有各類機器人AI模型的內部結構，這是整個工作的基礎。
在VLA模型家族中，研究團隊識別出四種主要的架構演化方向。最早期的形態叫"自回歸標記VLA"，代表作是谷歌的RT-2和OpenVLA。這類模型用一個統一的大模型骨幹網路，像寫作文一樣，一個字一個字地生成動作指令標記。這種方式結構簡單，但所有工作都由一個模組完成，靈活性不足。
第二種形態叫"VLM骨幹VLA"，代表作包括Octo、pi0、pi0.5以及MuseVLA。這類模型保留了一個強大的視覺-語言預訓練骨幹網路，但在輸出端專門配備了一個連續動作生成頭，專門處理平滑的運動輸出，而不是把動作硬塞進離散標記的框架里。
第三種形態叫"層級VLA"，代表作有Hi Robot、GeneralVLA、RT-H以及谷歌的Gemini Robotics 1.5。這類模型把任務拆成兩層：上層是一個"戰略規劃師"，負責理解高層目標並產生子目標或選項；下層是一個"執行者"，專門接收子目標並產生精細的動作指令。兩層之間有清晰的接口，各司其職。
第四種形態叫"異步VLA"，代表作有GR00T N1、Fast-in-Slow以及DAM-VLA。這類模型把執行分成快慢兩個時間尺度：負責"慢思考"的模組處理複雜語義理解，負責"快反應"的模組處理高頻動作執行，兩者通過緩衝區協調，互不阻塞。這一設計直接對應了前面說的"多速度同步運行"難題。
在WAM模型家族中，研究團隊同樣總結了四種組織方式。"預測後動作WAM"的代表作是UniPi，它把未來預測和動作執行明確分成兩個獨立階段，世界模型先算出未來的狀態，動作專家再根據這個預測輸出指令。"統一自回歸建模WAM"的代表作是WorldVLA和LingBot-VA，它把世界預測和動作生成壓縮到同一個自回歸標記空間裡聯合生成，結構更緊湊。"共享骨幹WAM"的代表作是DreamZero、Fast-WAM、Cosmos Policy以及統一影片動作模型UWM，這類模型讓世界建模和動作生成共用一個骨幹網路，但仍然暴露出可以獨立調度的功能塊。"潛空間WAM"的代表作是LaWAM和Being-H0.7，這類模型把未來預測壓縮成一個緊湊的"潛在未來"向量，交給下遊動作專家消費，而不是生成完整的未來幀，計算開銷更小。
通過這番全景掃描，研究團隊得出了三個關鍵洞察：首先，模組化結構已經成為現代機器人AI模型的核心特徵，而非例外；其次，子目標、緩衝狀態、預測未來、潛在子目標這些中間狀態，已經從模型內部的隱藏細節變成了必須在運行時顯式管理的對象；第三，時序結構越來越由模型本身定義，運行框架必須支持有狀態的多組件編排，而不能假設所有東西都是一次同步的請求-回復。
四、Embodied.cpp的設計藍圖：一套"萬能廚房"的建造方案
理解了問題所在，研究團隊把他們的解決方案設計成一個五層架構，可以用"萬能廚房"這個比喻來理解整個體系。
最外層是兩排接口：左邊是"食材入口"（輸入適配器），右邊是"出菜口"（部署適配器）。食材入口負責把各種來源的數據統一規範化——無論是真實攝影機的影片流、力傳感器的數值、IMU的姿態數據，還是LIBERO、DROID、BridgeData、RT-X等標準數據集裡的樣本，全部經過這個入口轉換成運行時內部統一認識的格式，就像餐廳的備料間，不管食材從哪裡買來，進入廚房之前都要洗淨、切好、分類。出菜口則負責把模型產生的動作指令翻譯成機器人或仿真器能理解的格式，支持ROS（機器人作業系統）、Apollo Cyber RT、Isaac Sim、Gazebo等主流機器人軟體生態。
進入廚房內部，第二層是"序列構建器"，負責把規範化的多模態輸入（圖像、語言、狀態）拼裝成模型骨幹網路能處理的輸入序列，就像把備好的食材按照食譜要求擺盤，等待下鍋。
第三層是"骨幹執行"，這是整個廚房的核心爐灶，承擔了最重的計算工作——運行大型視覺-語言骨幹網路（比如PaliGemma或Hunyuan-VL），提取跨模態的特徵表示。這一層的設計特別注重延遲優先的融合推理，支持圖計算重放、緩衝區復用、算子融合以及後端專屬分發，在CPU、GPU、NPU等不同硬體上都能高效運行batch-1的小批量推理。
第四層是"頭部插件"，這是可更換的出餐模組，專門處理各種不同類型的輸出。想要輸出連續動作流，就換上流式動作頭；想要輸出擴散模型預測的動作塊，就換上擴散頭；想要輸出世界狀態的預測，就換上世界預測頭。每種頭部都是一個獨立的插件，不需要改動底層廚房結構，只換前端出餐口就行。
貫穿整個體系的是一個"機器人AI算子倉庫"，收錄了各類機器人AI模型所需的專用算子和核心，就像廚房裡備齊了各種調料和烹飪工具，新來的模型只需要從倉庫里取用現成組件，不必從零搭建。
在運行調度層面，Embodied.cpp採用模組化多速率執行機制，讓不同的模組可以按照各自需要的頻率運行，互不干擾。感知編碼器可以每隔若干幀才刷新一次特徵緩存，預測分支只在需要世界預測時才激活，動作頭則以更高的控制頻率持續產出指令。這種設計直接對應了機器人AI的"多速度同步"難題。
五、實戰驗證：兩款VLA模型的實際部署數據
研究團隊在兩款代表性的VLA模型上對Embodied.cpp進行了完整的閉環評測。
第一款是HY-VLA，它的骨幹網路是騰訊混元VL大模型，同時處理來自三個不同角度攝影機的影片流，並利用影片歷史和記憶視覺路徑來增強場景理解，每次產生20個動作的動作塊。研究團隊在RoboTwin仿真平台的"place_empty_cup"任務（把一個空杯子放到指定位置）上進行測試，結果是100%的任務成功率，置信區間為83.9%到100%。這款模型的服務端推理延遲為1340.3毫秒，每個環境步驟的攤銷延遲為735.9毫秒，峰值顯存占用6850 MiB。延遲偏高是由於骨幹網路較大、三路視覺輸入以及影片歷史路徑的綜合影響。
第二款是pi0.5，出自Physical Intelligence，骨幹網路是PaliGemma，動作塊長度為50步。研究團隊對它進行了對應的C++部署配置測試，成功率為91%，置信區間為86%到94%。由於PaliGemma骨幹網路更輕量、動作塊更長（分攤了單步推理成本），pi0.5的每步延遲低至56.85毫秒，推理延遲266.6毫秒，峰值顯存6546 MiB，在實際機器人控制中具有更好的實時性。
兩款模型的對比充分說明了一個道理：同樣通過Embodied.cpp運行，不同架構的模型在延遲和內存上的差異是由骨幹網路規模、視覺輸入複雜度和動作塊長度決定的，而不是由推理框架本身造成的。這正是一個好的統一運行時應有的特性——它不引入額外開銷，只暴露模型本身的特性。
六、初步WAM評測：內存從312 MiB降到88 MiB，精度幾乎零損失
由於WAM模型（以LingBot-VA為代表）的完整閉環版本在受限的本地邊緣設備上尚未完全穩定，研究團隊採取了一個務實的做法：只對LingBot-VA的第一個Transformer塊進行微基準測試，評估Embodied.cpp在WAM側的能力。
LingBot-VA的骨幹網路基於萬象（Wan）影片生成模型的WanTransformerBlock，計算量相當可觀。研究團隊用Python原始實現（BF16精度，即16位腦浮點數格式）作為基準，與Embodied.cpp中對應的GGUF Q4_K量化版本（4位整數量化）進行對比。
量化是一種常見的模型壓縮技術，可以把模型參數從高精度數值壓縮成低精度整數，大幅減少內存占用，代價是可能帶來一定的精度損失。研究團隊用100個隨機輸入樣本，測量了兩個版本的輸出差異，使用"平均絕對誤差"（MAE，數值越小越好）和"餘弦相似度"（越接近1越好）兩個指標衡量精度損失。
結果相當亮眼：每個Transformer塊的內存占用從312.2 MiB大幅降低到88.1 MiB，縮減到原來的約28%；同時延遲從3.236毫秒降到3.171毫秒，略有改善；MAE保持在3.3×10??以內，餘弦相似度保持在9.997×10??以上，幾乎與原始版本一致。換句話說，內存省了超過70%，但模型的輸出幾乎沒有變化——就像用壓縮格式保存一張照片，文件小了很多，但肉眼看起來和原圖沒有區別。
這一結果表明，Embodied.cpp對WAM側Transformer組件的量化支持是有效且精確的，為後續完整閉環WAM部署奠定了基礎。
七、與現有系統的正面比較：Embodied.cpp填補了哪些空白
研究團隊對現有主流推理運行時做了一次系統性的橫向對比，維度包括：是否原生支持VLA模型、是否原生支持WAM模型、是否支持模組化多組件推理優化、是否能在邊緣設備上運行、是否支持異構硬體聯合使用、是否能直接連接真實機器人、是否能直接連接仿真器。
llama.cpp在邊緣設備運行上表現出色，但不原生支持VLA或WAM，沒有機器人接口，也沒有仿真器接口。ONNX Runtime支持邊緣部署和異構硬體，但對VLA/WAM的支持需要大量自定義集成。SGLang專注於大規模雲端LLM服務，既不支持邊緣部署，也沒有機器人接口。vLLM-Omni對VLA和WAM有部分支持，但缺乏邊緣能力和機器人接口。vla.cpp是目前最接近的相關工作，它把七種VLA架構統一到了一個可移植的C++運行時中，並且支持機器人連接，但它仍然僅限於VLA模型，不支持WAM，對模組化多組件推理的支持也有限，仿真器連接是部分支持狀態。Embodied.cpp在上述所有維度上均實現了原生支持，是第一個同時覆蓋VLA和WAM兩個家族、支持模組化執行、能在邊緣異構硬體上運行、並直接對接機器人和仿真器的統一推理運行時。
說到底，Embodied.cpp做的事情並不神秘，但它填補的是一個真實存在、且越來越重要的空缺。機器人AI模型的研究正在高速前進，模型架構越來越多樣，部署平台越來越碎片化，如果每個新模型都要重新搭一套部署工具，工程師的精力會大量消耗在重複勞動上，而不是真正有價值的模型創新。就像USB標準的出現讓各種外設終於能插到同一台電腦上一樣，Embodied.cpp試圖成為機器人AI部署領域的那個"通用插口"。
當然，這項工作目前仍處於早期階段，論文本身也坦率地承認WAM的完整閉環評測尚未完成，受限於本地邊緣設備的穩定性。但已經呈現的結果——兩款VLA模型的100%和91%成功率，以及WAM單塊內存縮減72%且精度幾乎無損——已經為這個方向提供了紮實的初步支撐。隨著越來越多的機器人AI模型從實驗室走向真實世界，這類可移植、可擴展、延遲優先的統一推理運行時的價值只會越來越凸顯。感興趣的讀者可以訪問該項目的GitHub倉庫（搜索SEU-PAISys/Embodied.cpp），或通過arXiv編號2607.02501查閱完整論文。
Q&A
Q1：Embodied.cpp和llama.cpp有什麼區別？
A：llama.cpp主要面向文字生成類的大語言模型，優化目標是在本地設備上高效完成"問答"式的請求-響應推理。Embodied.cpp則專門為機器人AI設計，支持持續閉環控制、多模組多速率協同運行，並直接對接攝影機、力傳感器等機器人硬體和Isaac Sim等仿真器，是兩個定位完全不同的運行框架。
Q2：VLA模型和WAM模型部署到機器人上最難的點是什麼？
A：最核心的難點有三個：一是感知、推理、動作各模組運行頻率不同，必須異步協調而非強制同步；二是機器人控制對延遲極敏感，但邊緣設備算力有限，需要專門優化batch-1小批量推理；三是機器人的輸入輸出種類繁多（圖像、關節角度、力傳感器等），現有框架固定的"文字進文字出"接口根本無法覆蓋。
Q3：LingBot-VA量化後內存下降那麼多，實際用起來精度會受影響嗎？
A：根據Embodied.cpp的測試，使用Q4_K量化將單個Transformer塊的內存從312.2 MiB降至88.1 MiB，同時用100個隨機樣本驗證，輸出的平均絕對誤差低於0.033，餘弦相似度高於0.9997，與原版BF16精度幾乎一致，實際使用中的精度損失非常有限。
