RynnValue 用秒估計機械人完成時間

它不只判斷機械人有冇做對,仲會估計距離完成仲差幾多秒。呢種時間式價值訊號,令強化學習獎勵設計變得直接得多。

RynnValue overview

機械人操作最難的不只是識別動作成敗,而是要持續知道距離完成指令仲有幾遠。RynnValue 就是針對呢個空缺而來的模型項目:它把機械人影片連同文字指令一齊讀入,逐格預測剩餘完成時間,並輸出自然語言分析,讓進度估計、失敗偵測與 VLA(vision-language-action)policy 的獎勵建構可以共用同一套訊號。

它和常見進度分數或偏好標註做法的分野很清楚。RynnValue 不靠人工標出「較好」軌跡,也不把進度硬壓成 0 到 1,而是直接學習 goal-conditioned cost-to-go 的物理時間;標籤來自時間戳,配合子任務切分與 cutoff relabeling,於是能擴展到 7,000 多小時、約 300 萬段 instruction-conditioned clips 的異質機械人資料。這個取捨帶來的好處是可擴展,代價則是模型必須更好地處理長尾任務時長與不同視角、不同 embodiment 的差異。

RynnValue 連同完整工具鏈一併提供。你可以把它理解成一套由 HuggingFace 相容模型、影片推理示範,到 reward-model benchmark 與強化學習介面都包起來的研究型工具組;當中 RynnValue 建基於 RynnBrain,實作在 Qwen3-VL architecture 之上,除了預測 absolute 與 relative temporal value,亦會生成影片描述,並判斷 instruction–video 是否匹配、任務是否成功。

  • 核心能力是把「距離完成尚餘幾多秒」變成稠密 value signal
  • 訓練毋須 preference 或 progress annotations,較易放大量異質資料
  • 8B 版本在 RBM-EVAL-OOD 的平均 Kendall’s τₐ 達 0.675,高於文中對照的 fully preference-supervised 方法 0.655
  • 可直接接到 reward shaping,用作 policy ranking、evaluation 與 reinforcement learning critic

為免模型偷看序列位置去猜進度,作者加入 temporal-order shuffling、random temporal sampling,以及 value-isolation attention;消融結果亦顯示這些設計不是裝飾,拿走後指標會明顯下跌。再進一步,它把輸出的 value 轉成 potential-based shaping reward,在雙臂 Franka 的真實機械人學習中,無論 online 定 offline 都比最強 reward-model baseline 有更高成功率。

最受惠的會是做機械人操作、VLA 訓練、reward modeling 與 embodied AI 評測的團隊,尤其想減少人手標註成本、又需要跨資料來源泛化能力的人。限制同樣存在:這類時間距離訊號雖然比二元成敗更細緻,但對任務切分、影片品質與觀測覆蓋仍然敏感,而且它目前聚焦於 robot manipulation,不代表可直接外推到所有 agent 場景。

項目主頁 · GitHub · 模型

Categories: 開源, 阿里巴巴, Qwen, Agentic, Video, 多模態模型, 模型訓練, 視覺模型, Robotic, VLA, Dataset 數據集

OasisKV 把 LLM KV Cache 帶出 HBM 瓶頸

HBM 容量已成為一種稀缺且昂貴的資源,嚴重限制了推理批量大小和系統吞吐量。OasisKV 以記憶體為中心進行推理,透過解碼期間將完整的 KV 快取儲存與 HBM 解耦來減輕 HBM 容量壓力。

Hugging Face

OasisKV 來自 Microsoft Research、Imperial College London、KAIST 和 University of Edinburgh。是建基於 vLLM 的 LLM 推理系統設計。

長上下文及長篇推理會令 Large Language Model (LLM) 的 key-value (KV) cache 佔用大量記憶體和頻寬,High Bandwidth Memory (HBM) 容量遂成為批次大小與吞吐量的限制。OasisKV 不再把完整 KV cache 全部放在 HBM,而是在解碼階段只保留注意力較高的 KV 項目,其他資料存放於主機或遠端記憶體。

系統利用 speculative decoding (SD) 產生的 lookahead tokens,預測下一步可能重要的 KV blocks,再透過背景 attention pipeline 預先載入 HBM。論文報告指,在 2,048-token KV 預算下,準確度只比 full attention 低最多 0.7 分,推理工作負載吞吐量可達 dense vLLM 的 1.69 倍,多 GPU 長上下文服務最高達 2.1 倍。

  • 預取稀疏 KV,降低 HBM 容量壓力
  • 支援 host 或 remote memory 作較大容量層級
  • prefill–decode disaggregation 下吞吐量約為 dense 方法 2 倍
  • 每個請求所需 KV 可減少 6.5 至 9.7 倍
  • decode node host memory 可降低 2.2 至 2.6 倍

取捨在於系統依賴 lookahead 預測及稀疏 attention;預測失準可能影響準確度,且跨記憶體層級預取會增加系統複雜度。暫時只確認以 vLLM 實作,沒有提供 GGUF 檔案、量化版本、mmproj 附加檔案、Ollama 或 LM Studio 支援資料。

項目主頁 · Paper

Categories: 微軟, 推理引擎

Ouroboros 把 AI 代理變成「自我演化」

它不只會接任務,還會記住自己做過什麼,甚至改寫自己。對想長期運行 AI agent 的團隊,呢種設計幾有吸引力。

Terminal-Bench 2.1: Ouroboros against Claude Code, Codex CLI, Cursor CLI, and Hermes on matched models, with a same-harn

一次性完成指令的 AI agent 已經不少見,但能夠跨任務、跨重啟保留身份、記憶同歷史,仲可以持續修改自己運行方式的並不多。Ouroboros 屬於開源通用型 AI agent,處理的是長週期工作會斷線、失憶,同埋難以持續改進代理本身的問題。

它不是單純能開多個 specialist agents,而是保留「同一個負責任主體」去協調研究、建構、驗證同審查。呢種做法對外部程式碼項目、需要長時間追蹤證據的工作流特別有用;代價是系統野心很大,對使用者來說亦意味要接受一個會動到自身程式碼、prompt、tools 甚至 dependencies 的代理。

Ouroboros 可當原生桌面程式使用,也可走 headless CLI,Windows x64 同多種 Linux 發行版都有發佈版本。執行期會把 repository、durable memory、history 同介面留在本機,模型推理則可接駁你自行設定的遠端 API,或者用本地 GGUF 模型,對想保留資料控制權的人較有吸引力。

  • 開源通用型 AI agent,重點在持續身份、durable memory 與自我修改
  • 可協調一組 specialist agents,但最終責任仍由單一 root agent 承擔
  • 支援桌面 app 與 CLI,適合長時間運行或接手外部程式碼項目
  • 本機保存記憶與歷史,模型可用遠端 API 或本地 GGUF 格式在本地執行推理
  • 官方列出 Terminal-Bench 2.1、OSWorld-Verified、CL-Bench 的 self-reported 成績

Ouroboros 公開了在 Terminal-Bench 2.1、OSWorld-Verified 同 CL-Bench 的 self-reported 結果,並以 matched model 或公開排行榜對照 Codex、Claude Code、Cursor、Hermes。呢類數字有參考價值,但仍要留意它屬自報結果;較可取的是,項目同時強調 traces、evidence 同可重現性,顯示它想把重點放在可檢查的過程,而不只是最終分數。

整體來看,Ouroboros 適合研究型開發者、想建立長記憶 agent 的團隊,以至需要代理長期接手軟件工作流的人。它吸引人的地方在於把 agent 由「一次性助手」推向「可延續個體」,但同時也把風險一併帶進來:自我演化愈強,愈需要清楚邊界、驗證流程同責任歸屬。

項目主頁 · GitHub

Categories: 開源, Agentic, API, IDE, Linux, Mac, Dataset 數據集

Meta Muse Glimmer:為本地多模態代理而生

Muse Glimmer 30B 針對本地部署而設,把圖文理解和代理式操作放在同一個模型裡。它同時提供 BF16、GGUF 與 ExecuTorch 版本,方便不同裝置取用。

Meta

Muse Glimmer 30B 屬於多模態 agentic model,重點放在本地部署時的可用性。對需要在自己裝置上處理圖文輸入、又想保留代理式工作流的用戶來說,這種設計比只提供單一格式的模型更實用,因為可以按硬件環境選擇合適版本。

Meta 這次一口氣放出多種包裝,包括 BF16 權重、GGUF k-quants、ExecuTorch builds,還有一個較細的 assistant 版本。這代表它不是只面向單一推理環境,而是嘗試覆蓋桌面、本地推理引擎,以及流動裝置部署等不同需求。

從現有資訊看,Muse Glimmer 的核心價值在於把多模態能力和本地執行的彈性結合起來。GGUF 版本方便在本地執行推理,ExecuTorch 版本則指向更輕量的裝置端部署;對想控制資料流向、減少依賴雲端服務的工作流,會更有吸引力。

  • 支援多模態輸入,適合圖文混合任務
  • 針對 local deployment 設計,部署選擇較多
  • 提供 BF16、GGUF k-quants、ExecuTorch 等不同格式
  • 有 30B 主模型與較小的 3B assistant 版本
  • 適合需要本地推理、裝置端或代理式工作流的場景

現時公開資料較集中在模型包裝與部署形式。就定位而言,它更像是一個面向實用部署的多模態模型系列,而不是只靠單一規格吸引注意的發佈。

項目主頁 · 模型

Categories: 開源, Agentic, API, Image, LLaMa, 多模態模型, 安全, 模型, 視覺模型, Meta

MiniMax H3 Turbo:4 步加速的影音生成 LoRA

MiniMax H3 的 ComfyUI 加速 LoRA,把 10 秒影片生成壓到固定 4 步。它適合要在速度、畫質和可控性之間取平衡的 T2V 與 I2V 工作流。

Og image

MiniMax H3 Turbo 走的是 ComfyUI 用途的加速路線,核心價值在於把 MiniMax H3 的文本生成影片(Text-to-Video, T2V)和圖像轉影片(Image-to-Video, I2V)流程固定到 4-step Euler 推理。它不是獨立模型,而是要配合 Comfy-Org/MiniMax-H3 的 BF16 base model 使用;頁面未提供更完整的 base model 參數規模或訓練細節,所以不能再往下猜。

這種設計的取捨很直接:步數少,生成時間通常更短,但對動作細節和穩定性的容錯也會更窄。頁面列出的比較都在同一個 BF16 base model、同一輸入與 10 秒、約 0.9MP 解析度條件下做,LoRA strength 固定 1.0;不同場景下,時間大概落在 174 到 190 秒之間,速度提升存在,但不是壓倒性。

重點摘要:
– 支援 T2V 與 I2V,I2V 走第一幀路徑,亦可用最後一幀收尾
– 固定 4-step Euler,重點是縮短推理流程而非擴大模型能力
– 需要配對 Comfy-Org/MiniMax-H3 的 BF16 base model
– 頁面未列出 GGUF、mmproj、上下文長度或量化檔案資訊
– 與 lightx2v LoRA 的比較屬同級加速方案,差距主要體現在時間與輸出取向

從檔案描述看,這個項目是 LoRA,不是完整 diffusion checkpoint,所以它的定位比較像「推理策略補丁」而不是全新模型。頁面也沒有提供 llama.cpp、Ollama 或 LM Studio 的支援資訊,顯示它主要面向 ComfyUI 工作流,而不是通用本地推理框架。

檔案命名上,頁面強調這是 v2 類型的更新版本脈絡;因此可確認的只有它圍繞 H3 的 joint audio-video diffusion path,並以固定 4 步作為加速契約。若要和原始 base model 比,差別不在功能範圍,而在於把生成速度和步數控制收緊,換取更快的工作流回饋。

模型

Categories: 開源, ComfyUI, Video, Image, Audio, 數字人, 視覺模型, 視頻模型, MiniMax

Hermes WebUI 把代理搬到瀏覽器

想長開一個會記住上下文的 AI agent,又不想長期困在 terminal,Hermes WebUI 正好補上這個缺口。它保留 CLI 能力,同時把多裝置存取整理得更順手。

Workspace file browser with inline preview

把一個長時間運行、會累積記憶的 autonomous agent 放到瀏覽器,而且幾乎不削弱原本 CLI 操作,正是 Hermes WebUI 最值得留意的地方。它屬於 Agent 介面工具,實際處理的是 Hermes Agent 在日常使用裡不夠方便的互動問題,讓你不必只靠 terminal 或訊息 app 才能管理對話、工作區與設定。

跟不少另起一套前端堆疊的 Web 介面不同,Hermes WebUI 走得相當克制:不用 build step、不用 framework、也不用 bundler,只靠 Python 和 vanilla JS。這種取捨帶來的好處很直接,部署比較輕、維護點較少,亦更貼近原本 Hermes Agent 的運行方式;代價是它的重點明顯放在功能對齊,而不是做一個花巧的前端展示層。

介面設計本身也有明確工作流考量。三欄布局把 session、聊天區與 workspace 檔案瀏覽分開,模型、profile 同 workspace 控制則固定放在 composer footer,減少來回切換;再加上 token context ring、Hermes Control Center、voice、mobile 與主題切換,較適合需要長時間跟 agent 協作、又要隨時查看檔案與工具呼叫紀錄的人。

  • 1:1 對齊 Hermes CLI,終端可做的操作基本都能在 WebUI 完成
  • 支援 session、workspace、voice、profiles、安全設定與手機存取
  • 可用自動探索、手動啟動、SSH tunnel、Tailscale、Docker、Nix 等方式部署
  • 建基於既有 Hermes Agent 與現成模型,毋須另設一套推理環境

安裝理解上,它不是獨立 agent,而是 Hermes Agent 的瀏覽器前端,所以前提仍然是先把 Hermes 本體跑在伺服器,再用 bootstrap、start/ctl 腳本、Docker 或 Nix module 把介面掛上去。在存取方式、部署彈性與跨裝置操作一致性;對於已經在自架 AI agent、想把 CLI 工作流延伸到桌面與手機的人,這個項目的價值相當明確。

GitHub

Categories: 開源, Agentic, Python, 語音, 框架

MatrAIx-Persona-8B: 模擬現實中的人性

MatrAIx 把人性化模擬用戶搬入評估流程,讓產品在推出前先看見不同人會點互動。它特別適合做問卷、聊天、網頁同 App 測試。

Watch the MatrAIx demo on YouTube

MatrAIx 是一套以多樣化模擬用戶做核心的評估基建,目標是補足只看單一指標、卻看不到不同人實際反應的盲點。它把 persona 變成 LLM agents,分別在 Survey、AI Chatbot、Web 同 App 四種環境跑可重現的任務,適合用來看產品、介面同互動流程會點影響不同用戶。

它的做法唔係只生成幾個虛構角色,而係用 1,290 個人格維度去組合背景、心理、能力同行為,再加上依賴關係處理同 evidence-aware human grounding。這種設計令評估結果唔止係一條總分,而係可以分辨邊類用戶受影響、邊種流程出問題。

MatrAIx: Simulating the World with 8.3B Persona Agents
  • 可用於市場研究、概念測試、客服對話、網頁原型同 App 流程評估
  • 介面前有 Playground 同 visual runner,方便先睇互動再做批量測試
  • persona-agent 範例需要 Model API keys,Playground / viewer 前端只要求 Node.js 20+
  • 內文提到嘅公共 persona 資料集同評估報告,顯示它偏向研究同產品驗證兩用。

同一般只做通用 benchmark 的方法相比,MatrAIx 強調人口規模同可重現的模擬軌跡,重點唔係單次對錯,而係不同 persona 之間的差異。這對做 AI 產品、用戶研究、RL 訓練前資料收集的團隊較有價值,因為佢提供的是互動過程同行為痕跡,而唔只是結果分數。

項目主頁 · GitHub

Categories: 開源, Agentic, API, Medical醫學, Dataset 數據集

round-trip-consistency:雙向 diffusion 幫長序列預測錯誤

遇上長步數 rollout,最難不是生成下一步,而是知道幾時開始唔可信。round-trip-consistency 用一次來回推演,直接估計模型當下誤差。

Bidirectional round-trip consistency overview

長序列 rollout 最棘手的位,在於錯誤會一路累積,但部署之後偏偏冇真值可以對照。round-trip-consistency 針對的正正是呢個缺口:它屬於一個研究型模型項目,用單一 conditional latent diffusion model 同時向前、向後推演 dynamical system,然後用來回一次嘅落點差距 round-trip consistency 當成自監督誤差訊號,判斷當前預測仲值唔值得信。

相比靠 ensemble、外部觀測、保留測試資料,甚至依賴 governing equations 去估可信度,呢個做法嘅取捨幾直接:代價係多做一次反向 rollout,換來唔需要額外真值。模型關係亦唔複雜,高維輸入先經 VAE 壓到 latent space,再由同一個 bidirectional latent diffusion model 配合 direction flag 做 forward 或 backward rollout,所以 backward 不只是檢查工具,亦順手變成 inverse solver。

現有資料已經講清楚它較適合點樣理解和測試:重點唔係即裝即用嘅應用介面,而係跟隨論文與程式碼重現 rollout、計算 C_i(Confidence Interval),再觀察它同真實 rollout error 嘅關係。對做科學模擬、時序生成、物理場預測,或者想為 autoregressive generative model 加一層 test-time trust signal 嘅研究團隊,呢類方法比單純看步數深度更有參考價值。

  • 用 forward 再 backward 嘅差距作為無需量測嘅 test-time error signal
  • 同一個 bidirectional diffusion model 包辦雙方向推演,訓練成本冇因雙向設計而上升
  • 在 MHD、turbulent Navier-Stokes 同 CelebV-HQ 呢類資料上驗證,覆蓋物理場與影像序列
  • 可用來做 error ranking、OOD flags 同 selective prediction,而唔止係生成結果本身

結果 C_i 在 held-out MHD trajectory 與 rollout error 有高相關,固定深度下 Spearman 可達 0.91 至 0.98;面對 out-of-distribution 的 Orszag-Tang vortex,AUROC 達 0.98,到 depth 10 去到 1.0。它亦能在 80% coverage 下將 incurred error 降低 15%,而在 LE-PDE-UQ 的 benchmark,一個 bidirectional model 已接近十模型 ensemble 嘅水位,訓練成本只係十分之一。不過呢個項目仍然偏研究原型,價值最大嘅場景係替長 rollout 模型補上「幾時應該停、幾時可以信」呢個判斷層,而唔係即時提供完整產品化流程。

項目主頁 · GitHub

Categories: 開源, , World-Action Model, Dataset 數據集

UA-NWM 不確定性無人機導航

無人機朝目標圖片飛行,最難唔係預測一條路,而係判斷目標畫面是否仍屬合理路徑。UA-NWM 解決「模型解釋唔到」的誤差。

Repository image for DurYi/UA-NWM

戶外無人機導航最易出錯的位置,在於前方畫面未必只有一種合理變化。UA-NWM 把這個問題當成 world model 的評分工作處理,面向 aerial image-goal navigation,唔再只估一個未來畫面再同目標硬碰硬,而係判斷目標圖片是否落在模型預測的未來狀態分佈之內。

它最值得留意的技術點,是用 Hierarchical Error Projection(HEP)把預測與目標之間的差距拆成可由不確定性子空間解釋的部分,同埋解釋唔到的殘差,最後只用後者作為 trajectory cost。呢種做法同單點預測式 ranker 的分別很直接:同樣見到偏差,UA-NWM 會先問偏差是否屬於合理未來變化,而唔係一概當成走錯路。

模型本身會預測未來的 DINO latent features,配合 deterministic future feature map 同 uncertainty subspace 做單次 forward scoring,避免靠隨機抽樣多個未來狀態先完成比較。同一個 checkpoint 可配合兩種 inference strategy,包括 uncertainty-aware 的 UA-NWM 與 deterministic baseline,適合研究團隊直接比較兩種評分邏輯帶來的差異。

  • 適合 UAV 導航、戶外機械人感知,以及要由目標圖片反推行進路線的團隊
  • 重點唔係生成最像的未來畫面,而係判斷目標是否仍在合理未來分佈內
  • 提供 AirGoal-10k 的 training、evaluation、trajectory ranking、CEM/MPC planning 與 visualization workflow
  • deploy/ 內有真實部署用的 server-side policy wrapper,但原始資料未完整交代整套部署步驟

它已對應 AirGoal-10k,並包含真機 UAV demo、資料集連結與 pretrained checkpoints;受益最大的是需要處理大範圍戶外場景、多解未來觀測,以及想把 world model 直接接到規劃器如 CEM/MPC 的團隊。

項目主頁 · GitHub · 模型

Categories: 開源, Image, 模型訓練, 世界模型, 百度, Dataset 數據集, 清華大學

WorldTrace 令世界模型影片記住更遠場景

影片世界要模型生成得夠長,往往先開始失憶。WorldTrace 針對呢個斷層,想保住長時段生成同遠距場景回想能力。

Og image

做長時間影片生成時,Video World Models 最易出現的問題唔係畫面唔夠靚,而是走出訓練長度之後開始「唔認得之前見過乜」。WorldTrace 針對的正是呢種視覺記憶失效:它屬於 Video World Models 的記憶機制改良方法,重點是令 Key-Value (KV) cache 裡已壓縮的內容,過了原本訓練範圍之後仍然可以被模型重新定位和讀取。

核心思路不是再訓練一個新生成器,而是用 training-free 方式處理記憶可尋址性。研究指出,問題關鍵在 temporal Rotary Positional Embeddings (RoPE) 偏移超出訓練 horizon 後,注意力機制即使保留了舊畫面資訊,都未必再讀得到;再加上在 RoPE 旋轉空間直接平均 key,會令不同 phase 互相抵消,令記憶內容變得模糊。WorldTrace 透過固定、仍屬 in-distribution 的 slot 位置保存壓縮記憶,避免記憶「存在但搵唔返」。

同一套記憶框架下,它分成兩個方向:WorldTrace-Field 用 rotation-invariant 的歷史聚合方式,支援較連貫的長 rollout;WorldTrace-Landmark 則保留較接近原樣的 scene traces,讓模型隔了更長時間後,仍有機會回想曾經到過的場景。這種分工反映出一個很實際的取捨:有些情境重視連續生成的穩定性,有些則更需要精準回憶特定地點或視覺片段。

  • 針對訓練 horizon 以外的記憶失效,而不是單純提升畫質
  • 保持壓縮後的 KV memory 可尋址,重點在 fixed in-distribution slot positions
  • WorldTrace-Field 偏重長序列生成的一致性
  • WorldTrace-Landmark 偏重遠距離場景召回與保留視覺痕跡
  • 原始資料將它描述為 training-free,未見提供安裝、下載或部署流程

這類方法較適合需要長時間互動、持續追蹤場景變化,或者要求模型記得自己曾經去過哪裡的工作流,例如互動式模擬、可探索影片環境與長時段世界狀態建模。現有資料亦提到它獲 ICML 2026 F2S Workshop Best Paper。

項目主頁 · 項目

Categories: NVIDIA, Video, Embedding, 模型訓練, 世界模型, Dataset 數據集, 框架

Page 1 of 130
1 2 3 130