具身智能軍備競賽，勝負手在工程生態

開源工程底座 FluxVLA Engine 技術報告全解讀。作者丨鄧哲敏 編輯丨齊鋮湧 一個模型在論文中取得好成績，距離它真正驅動機器人完成任務，還有多遠？模型能否接入現有的數據與訓練流程，推理速度能否跟上機器人的控制節奏，生成的動作能否連續、穩定地執行，實驗結果又能否在不同機器人上得到驗證——這些問題，未必能靠再提升幾個百分點的模型成功率來解決。

過去半年，AI科技評論（）在與業內人士交流時發現，一些反覆出現的工程問題正在消耗大量研發資源：不同模型的數據格式難以統一，訓練和評測流程各自為政，仿真中的結果到了真機上未必成立；好不容易跑通一套流程，換個模型、換份數據或換臺機器人，又可能需要重新適配。模型在不斷迭代，工程積累卻未必能隨之沉澱。這讓想起深度學習的發展歷程。2017 年，PyTorch 正式開源，此後，框架、工具鏈與開發者社區不斷完善，研究者得以在更成熟的基礎設施上開展實驗，而不必每次從底層重新搭建環境。

今天的具身智能雖然面臨不同的技術挑戰，但同樣需要解決一個問題：如何讓已有的研發成果更容易複用，讓不同技術路線能夠在統一的工程框架下協作。逐際動力開源的 FluxVLA Engine，試圖從工程層面回應這一問題。它並非又一個爭奪模型性能排名的 VLA 模型，而是一套面向具身智能研發的工程底座，貫通數據、訓練、評測、推理與真機部署。10 月 22 日，FluxVLA Engine 完成重要更新。我們拆解了它的最新技術報告，並重點關注四個問題：不同架構的模型能否接入同一套研發體系？模型從仿真走向真機，需要跨過哪些工程障礙？真實交互經驗如何低成本地迴流到模型優化中？

當同一套流程覆蓋更多模型與機器人時，它究竟展示出了怎樣的能力？01新模型請先登記一套工程底座是否真正有用，首先要看它能否接納不同的模型。對具身智能來說，模型是迭代最快的。今天使用一種 VLA 架構，明天可能嘗試另一種動作生成方式；同一團隊也可能同時研究多個策略模型。如果每換一次模型，就要重新整理數據、編寫評測代碼、改造部署接口，那麼此前積累的工程經驗很難持續發揮價值。模型可以不斷更換，但圍繞數據、評測和部署建立起來的工程能力，不應該每次都從頭再來。FluxVLA Engine 的做法，是通過統一配置與組件註冊機制，把不同模型接入研發流程時需要處理的差異，儘可能收斂到明確的接口中。

可以理解為一份統一的實驗清單，加上一套可供調用的組件目錄。配置文件負責聲明一次實驗需要使用什麼模型、如何處理數據、怎樣開展評測，以及通過什麼接口進行部署。註冊機制則將視覺骨幹、動作頭、訓練運行器和機器人相關操作組件等分別組織起來。開發者可以按需組合已經適配的組件，而不必為每一種模型重新搭建整套工程流程。這並不意味著任何模型都能在不做適配的情況下直接運行。不同架構仍然可能需要各自的適配器、動作空間轉換和歸一化處理。真正的價值在於：把不可避免的差異放到可管理的組件層，讓已經打通的公共流程能夠繼續複用。

從技術報告來看，FluxVLA 已經將多種架構差異明顯的策略納入同一套研發與評測體系，包括採用自迴歸路線的 OpenVLA、採用 flow-matching 路線的 π0.5，以及 DiT4DiT、GR00T 等不同技術路線的模型。這意味著，統一工程框架不必以犧牲模型多樣性為代價。FluxVLA 的模型接入並不侷限於開放權重的模型。GPT-6 Astra 此前就以純 API 的方式接入，同一套閉環評測，不提供權重、不參與訓練，評測器照常跑完流程、留好證據。就在最新技術報告發布後兩天，MiniMax-M3.

1-Flash 成為繼 GPT-6 Astra 之後第二個 checkpoint-free 的純 API 推理策略，開箱即可在 LIBERO 與 RoboCasa GR1 上跑評測。數據層面也遵循同一套邏輯。不同機器人、不同仿真環境產生的軌跡數據，統一轉成標準格式後，可以在同一套管線裡混合訓練，也可以分組保留各自的歸一化約定。今天為某個模型整理好的數據集，明天換個模型照樣能用。工程積累不隨技術路線切換而清零——這才是讓行業研發成果能夠持續疊加、而不是互相抵消的前提。說到底，數據是具身智能最貴的資產，能讓這份資產少貶值、多複用，本身就是一種行業級的降本。

02三步上真機一個策略的最終歸宿，還是得落到物理世界。模型在仿真裡跑出了很高的成功率，上了真機，性能可能大幅下滑。這不一定是模型本身的問題，而是模型推理和機器人執行之間存在一道系統性的工程鴻溝。這道鴻溝由三層問題疊加而成，每一層都不是單靠更好的模型能解決的，需要三個依次協作的機制來分別處理。第一層，模型推理太慢，跟不上機器人的控制節奏。人形機器人的控制迴路需要高頻率的動作指令，但大型 VLA 模型的推理速度往往遠不夠快——模型還在計算下一步，機器人已經完成當前動作在乾等了。兩者之間的時間差，直接造成機器人動作遲鈍或失步。FluxVLA 的解法是為同一組已學參數換一張更高效的執行圖。

具體來說，針對 GR00T 和 π0.5 兩條主流路線，系統通過把反覆執行的計算步驟預先“錄製”成固定執行圖（CUDA Graph），配合底層算子融合等優化，提高執行效率。這一步不碰模型權重——針對 GR00T 動作頭的數值對齊測試顯示，加速前後輸出動作的餘弦相似度超過0.99999。實測數據裡有一組數字，讓我們印象深刻。在英偉達 AGX Orin 64GB 這塊邊緣芯片上（大量人形機器人的“機載大腦”用的正是它），GR00T 的推理頻率從 3.2Hz 提升到了 7.4Hz，π0.5 從 1.4Hz 提升到 4.4Hz。同一塊芯片，同一個模型，優化之後，模型推理速率提升了兩三倍。

第二層，預測和執行之間存在時序錯位。VLA 模型通常一次預測一段動作序列，讓機器人邊執行、邊預測下一段，以此降低查詢頻率。但當新的預測結果計算完成時，它開頭部分對應的時刻往往已經過去，機器人已經走到那段時序之後了。直接把新的動作序列接上去，會產生明顯的跳變，表現為關節處的抖動和不連續。FluxVLA 選擇用 RTC（Real-Time Chunking）來解決這個時序錯位問題，把上一段動作序列裡還沒執行完的部分，當作下一次預測的前提。生成新序列時，模型已經知道機器人接下來會先做什麼，新動作從那個狀態自然地延續下去。

技術報告提供了兩種實現路線，一種在訓練階段就加入延遲條件模擬、推理時使用前綴條件；另一種不改變訓練過程，適合直接用在已有模型上。第三層，動作序列在物理上不一定能執行。解決了時序銜接，還有最後一道關。模型輸出的動作序列，在物理層面未必符合機器人的運動能力邊界。把歸一化的預測值還原成真實的關節角度、速度之後，一段序列裡可能隱含過大的加速度或局部振盪。簡單來說，動作可能太猛，或忽快忽慢，超出機器人能平穩執行的包絡。軌跡後處理做的事，是在動作序列真正發送給機器人之前，先做一次運動學約束優化，把速度、加速度以及它們的變化快慢都限制在可安全執行的範圍內。

FluxVLA 提供兩種後端，一種求解更精細，處理延遲約 4.9 毫秒；另一種快約 4 倍、延遲只有 1.17 毫秒，代價是跟蹤保真率略低、存在一定參考滯後。二者各有適用場景，可以在配置裡自由選擇。這三個機制最優雅的設計，在於順序協作。推理加速讓模型快到足以跟上控制迴路，RTC讓新動作序列與正在執行的動作自然銜接，軌跡後處理讓最終發出的指令符合機器人的物理約束。三步合起來，把模型預測到真機執行之間常被一筆帶過的工程落差，拆成了可定位、可分別解決的環節。03讓真實交互經驗進入訓練閉環把模型送上真機，然後呢？

在具身智能的主流開發範式裡，通常流程是：收集人類示教數據，訓練模型，測試，再收集，如此循環。這套方法已經推動了許多機器人操作能力的發展，但示教數據能夠覆蓋的情況終究有限，真實環境中的物體位置、光照、機器人初始狀態等因素不斷變化，模型可能遇到訓練數據中沒有充分覆蓋的情況。如果每次發現問題，都只能依賴人工補充示教數據，模型改進的速度就會受到數據採集和訓練流程的限制。FluxVLA 在這次更新中引入了在線強化學習後訓練，正面回應這個問題。從工程設計上來看，這套方案相當剋制。

FluxVLA 沒有選擇自己把 RL 做一遍，而是和專門做大規模 RL 訓練的 RLinf 系統對接，各做各最擅長的事：FluxVLA 保留模型構建、觀測處理、動作轉換這一層，RLinf 負責 rollout 採集、優化算法和權重同步。兩者靠接口銜接，同一套模型不需要改動，接上 RLinf 前端就能進入在線 RL 的訓練閉環。這個分工設計讓現有的監督訓練流程完全不受影響，RL 是可選的增量能力，而不是對已有工作流的替換。在開源項目裡，全部包攬是常態，把不擅長的交出去反而是稀缺的。FluxVLA 願意在邊界上留出接口、與外部系統協作，說明它對自己的定位是很清醒的，沒想著去做面面俱到的全家桶。

不過，在線強化學習並不意味著機器人可以自動理解每一次失敗，也不保證訓練時間越長、模型就一定越強。它提供的是一條利用交互數據優化策略的路徑，最終效果仍然取決於獎勵設計、訓練設置和任務條件。技術報告給出了一組配對實驗結果：SmolVLA 在 LIBERO-10 上，成功率從基線 66.2% 提升到 76.2%，提高 10 個百分點；在 RoboTwin Clean 設置的 10 個任務上，從 45.9% 提升到 61.3%，提高 15.4 個百分點。RoboTwin 實驗還記錄到，經過訓練後，有 231 個此前失敗的 episode 轉為成功，但也有 77 個原本成功的 episode 出現退步。

這意味著，策略的整體表現雖然有所改善，卻不是對所有情況都實現了同步優化。報告同時指出，隨著訓練繼續進行，LIBERO-10 上的成功率從峰值略有回落。這組實驗還驗證了一個重要方向：當策略交互、數據採集和訓練優化能夠在工程上形成閉環，真實執行過程中獲得的經驗就有機會被用於後續模型改進，而不只是停留在一次測試結果中。對於整個行業而言，這意味著研發流程可以從單向的“收集示教—訓練—測試”，進一步向“執行—採集經驗—優化策略—再次執行”擴展。04覆蓋度才是硬指標一套工程體系能否發揮價值，還需要看它在多大範圍內經過了驗證。如果只支持少數幾種模型，或只能在單一機器人上運行，那麼它的複用能力仍然有限。

反過來，如果多種異構策略能夠進入同一套評測體系，並在不同機器人平臺上完成相應的測試，就更有機會證明這套工程框架具備一定的通用性。FluxVLA技術報告中的評測結果，提供了幾個值得觀察的切面。仿真側，第一部分已經說過，內部結構差異極大的策略，能共用同一套數據管線和評測器。放到具體數字上，技術報告在 LIBERO 一共集成了 14 個策略，13 個本地 checkpoint 裡 11 個平均成功率超過 95%。有兩個細節此前沒展開。一是難度分層。LIBERO 測的是桌面級的短任務，高分有一部分原因來自基準本身的任務特點。

同樣的策略，換到更接近真實居家操作、難度更高的 RoboCasa GR-1，平均成功率掉到 8.75% 到 57.25% 之間。需要說明的是，這個落差來自任務難度的差異，而不是評測口徑的問題。報告也明確標註，兩組結果來自不同的模型架構、數據預算和訓練流程，不構成受控比較。把策略放到不同難度的任務中驗證，不只是為了得到一個成功率數字，更在於幫助開發者判斷模型當前能完成什麼、在哪些任務上仍有提升空間。FluxVLA 提供的統一評測流程，讓這類能力驗證能夠在相應的基準上持續開展。二是泛化。

RoboDojo 的 42 個任務、每個模型 2100 次試驗，大多數模型能完成任務的一部分，但能從頭到尾全部完成的比例低得多；當任務佈局從固定改成隨機，排名最靠前的 π0.5 成功率從 16% 跌到 2.33%，其餘七個模型最高只有 0.67%。通過這組數字，不難看出當前所有主流策略在沒見過的場景面前的共同窘境。真機側，平臺擴展到了四個：ALOHA 雙臂系統（6 個任務、7 種策略配置）、逐際動力自研的全尺寸人形機器人 Oli、Rebot，以及雙臂 Franka。在仿真裡訓練、驗證過的策略，通過同一套部署路徑，直接上了形態各異的四個平臺，並且都完成了閉環測試。

很有意思的是 Oli 上的一組細節：四階段箱子搬運裡，GR00T N1.5 和 π0.5 前三階段完成率幾乎相同（60% 對 61.67%），全程完成率卻只有 6.7% 和 33.33%。長程任務的成功率是乘法不是加法，前幾段積累的微小偏差會在後期被逐級放大。我們在和業內人士的交流中曾多次聽說這個問題，但也只能停留在理解和想象，這次 FluxVLA 分階段記錄完成情況的評測設計讓我們清晰地看到了這一點。最能體現閉環價值的，是用 ALOHA 疊毛巾的數據。先用傳統的行為克隆訓練，也就是讓模型照搬人類示教的動作，成功率只有 62.1%。

換了個思路，先訓練一個獎勵模型，讓系統學會判斷每個動作做得如何，再用這個判斷反過來指導策略訓練，成功率上升到 99.4%。從真機採集數據、訓練獎勵模型，到重訓策略，再部署回真機，整個過程都在 FluxVLA Engine 一套底座上完成。綜合來看，FluxVLA 的評測結果提供了兩類不同的證據。一類是工程能力：多種異構策略被納入統一評測體系，多個真機平臺完成了相應的閉環驗證，說明它已經展示出跨模型、跨平臺組織研發流程的能力。另一類是模型能力的可驗證性：不同基準下的表現差異、隨機佈局帶來的成功率變化，以及長程任務中的階段性損耗，都讓模型的能力邊界有了更具體的觀察依據。

工程底座並不替代模型本身的優化，也不意味著所有策略都能自動獲得出色的泛化能力；它所提供的，是一套相對統一的驗證路徑，讓開發者能夠更可靠地評估現有能力、發現問題，並在後續研發中持續改進。05軍無輜重則亡2026 年具身智能競爭的焦點，從誰的模型更牛，逐漸移到了誰的數據更多更泛、誰的本體更扛用、誰的商業化路徑更明確。前線拼火力，後方拼糧草，完整的工程生態就像靠譜的補給線，越到戰線後期，越能體現出價值。FluxVLA 的價值並不在於解決具身智能的所有工程難題，而在於試圖將其中一部分反覆出現的問題，變成可複用的工程機制。

模型註冊與統一配置，減少了重複搭建研發流程的需要；推理優化、RTC 與軌跡後處理，將部分真機執行障礙拆分為可處理的環節；在線 RL 對接，為交互數據進入策略優化提供了工程接口；跨模型和跨平臺評測，則讓不同策略能夠在相應條件下得到驗證。這些能力共同指向一個目標：讓研發團隊能夠把更多精力放在模型、數據與任務本身，而不是在每次實驗中重複處理相同的基礎工程問題。更重要的是，工程流程的統一不僅服務於研發效率，也讓模型能力的驗證與迭代有了更穩定的依託。開發者可以在相對一致的流程中比較不同方案，觀察策略在不同任務和平臺上的表現，再將發現的問題帶回數據、訓練與部署環節。

此外，FluxVLA 有一個容易被忽視、但在我們看來卻很關鍵的選擇：不追求讓所有組件無條件兼容。不同模型、數據集、機器人本體之間，數據結構、動作語義、接口的差異客觀存在，誰也抹不掉。FluxVLA 用標準接口和模塊化設計，把這些差異集中到可檢查、可適配的環節——組合出問題的時候，能讓人知道具體出在哪裡。在工程可靠性上，這種讓問題暴露出來的姿態，比假裝一切都兼容更有價值。

作為一傢俱身智能主機廠，逐際動力在本體、算法研發和真機運行中踩過的坑、驗證過的流程，本可以當作護城河，服務於自身產品，但他們選擇將一線經驗轉化為開放的標準化工程底座，以企業級資源為外部開發者、算法團隊和其他機器人平臺提供了使用與協作的更多可能性。當然，這並不意味著開源項目已經自然形成了成熟的行業生態。真正的生態還需要外部團隊持續使用、貢獻適配、反饋問題，並在不同場景中驗證其價值。但開放的接口與可複用的工具，至少為這樣的協作提供了基礎。FluxVLA Engine 代碼倉庫：https://github.com/FluxVLA/FluxVLA技術報告：https://arxiv.

org/abs/2609.17210Hugging Face：https://huggingface.co/limxdynamics/FluxVLAEngine