InferNews

StreamPI 機械人模型的記憶系統

2026 年 8 月 27 日 Share to X Copy link

StreamPI 為單幀 Vision-Language-Action 模型加入記憶與幾何線索，並將多幀推理的延遲增幅壓至較低水平。

機械人執行抓取、插入等連續任務時，只看當前畫面容易失去物件位置變化；StreamPI 將每組視覺觀察與語言指令視為一個時序單元，屬於為 Vision-Language-Action (VLA) 模型加入串流時序推理能力的框架，針對的正是單幀 π₀.₅ 無法保留歷史觀察的限制。

它沒有額外加入模型參數，而是把多組 token 接在同一序列，再用 block-wise attention mask 控制資訊流。每個單元內採用雙向注意力，讓視覺與語言充分融合；單元之間採用因果注意力，配合 KV cache 保留過去內容，避免每次重新處理完整歷史。重複放入語言指令亦可令任務目標在視覺內容增加後保持清晰。

• 以預訓練單幀模型延伸至單幀或多幀推理
• 不增加參數，支援彈性上下文長度
• 以 random-interval sampling 配合 temporal masking，模擬非固定觀察時間
• KV cache 適合串流推理及非同步機械人控制
• RTX 4090 由一幀增至五幀，平均延遲只由 94.4 ms 升至 103.6 ms

訓練時加入隨機幀間隔，讓模型接觸不同觀察節奏；研究資料亦提到每三幀取樣可令動作更快、更平順。這比固定時間同步的訓練更貼近真實機械人環境，但效果仍取決於感測器頻率、控制週期及任務本身，不能只以幀數推斷所有場景都會改善。

項目建基於 openpi，並提供 JAX multi-node distributed training 的額外支援；README 同時列出 real-robot 任務及示範影片。現有資料未提供完整安裝流程、可直接下載的模型權重或測試指令，官方項目頁只表示程式碼及權重預定於 2026 年 8 月 30 日公開，因此目前較適合機械人研究團隊參考其架構和評測方向，而非當作即時可用的套件。

項目主頁 · GitHub

Categories: 開源, 香港大學, Agentic, 視覺模型, 多模態模型, 模型訓練, VLA, Robotic, 香港, Dataset 數據集

---

JIT-Agent：讓模型即時寫出專屬代理框架

2026 年 8 月 27 日 Share to X Copy link

JIT-Agent-27B會按任務即時組合可執行的代理框架，令同一個 Agentic LLM 更貼近研究、辦公及規劃工作。

面對深度研究、日常工作或工作區操作等不同任務，固定不變的代理框架未必能有效轉用。JIT-Agent 屬於一個 meta-agent 模型項目，接收任務規格、協議、工具及技能註冊表，再為現成的 agentic LLM 生成特定任務的可執行 harness，處理代理流程難以適配的問題。

JIT-Agent-27B 並非直接取代底層模型，而是負責組合包裝模型的工作方式。每個 harness 由 memory、planning、action 及 capability orchestration 四個模組組成，並透過 HarnessFactory 的共享介面輸出結構化程式碼，避免每次都由模型自由撰寫整套代理程式。

• 按任務生成不同的記憶、規劃和行動流程
• 可包裝不同的 off-the-shelf agentic LLM
• 測試期間會根據 trace 與 feedback 修訂 harness
• 生成器保持 frozen，改進內容寫入 harness archive
• 涵蓋研究、辦公、規劃及 workspace 類代理基準

同類方案通常先準備一個通用 scaffold，再期待它在不同任務中轉移；JIT-Agent 將可轉移的能力放在 harness 生成與演化，而不是只依賴 base model 擴大。代價是系統需要任務規格、工具註冊表、過往 harness 及測試回饋，生成品質亦會受這些輸入影響。

JIT-Agent 把 jit/、scripts/、harness_factory/、benchmark/ 及 dataset/ 分開，涵蓋生成與修復提示、代理核心、評估器和基準適配器。 JIT-Agent-27B 在九個代理基準中領先八個。適合研究代理架構、需要為多類工作測試流程的團隊，以及想比較「擴大底層模型」與「改進 harness」效果的人員。

項目主頁 · GitHub · 模型

Categories: 開源, Agentic, 模型, 框架, 編程, Dataset 數據集

---

VGI-Bench 揭示影片模型推理仍未可靠

2026 年 8 月 27 日 Share to X Copy link

影片生成模型不只要畫面合理，還要令事件按正確過程演變。VGI-Bench以27項任務測試這種能力，最高分只有51%。

當影片生成模型要處理空間關係、時間變化、物理操作或結構謎題時，畫面好看並不代表推理正確。VGI-Bench屬於影片模型視覺推理評測基準，實際處理的是如何檢查模型能否生成符合條件、而且過程連貫的影片，而非只交出一個合理的最後畫面。

VGI-Bench包含27項任務及810個測試實例，按任務領域和 skill tags 分成兩層分類，並設有 easy、mid、hard 三個難度級別。測試輸入盡量貼近現時影片模型熟悉的視覺先驗，同時要求輸出反映有效的 evolving process；評分採用 rubric score × completeness score，兼顧答案是否正確及是否完成要求。

結果反映模型能力仍有明顯缺口：Seedance 2.0以51.0%取得最高總分，在 Visual Organization、Spatiotemporal 和 Physical Manipulation 領域領先；MiniMax-H3則以50.6%在 Structured Puzzles 領先。Sora 2、Gen-4.5、Wan 2.7及Veo 3.1等模型亦被納入比較，方便分辨影片品質與視覺推理能力之間的差距。

• 生成畫面合理，不等於推理過程正確
• 覆蓋視覺組織、時空推理、結構謎題及物理操作
• 最高總分只有51.0%，可靠性仍不足
• 分析涵蓋輸出失敗模式及輸入條件敏感度
• 去噪後期主要修整早期假設，未必能修正推理錯誤

研究團隊亦檢查 synthetic fine-tuning 的性能轉移邊界，並從 internal denoising 角度分析模型如何修正答案。結果指向有限的 self-correction：後續步驟多數是在完善早期假設，而不是重新推翻錯誤推理。這個基準較適合影片模型研究團隊、模型供應商及需要比較生成式視覺推理能力的評測項目；GitHub資料提供 project page 及 Hugging Face Data & Res 連結，但所給資料沒有列出安裝步驟或完整測試流程，不能直接假定可下載後即時重現。

項目主頁 · GitHub · 數據集

Categories: 開源, 模型訓練, Robotic, Dataset 數據集, MiniMax, Skill 技能

---

阿里巴巴 PAI 以 PDD 加速 MiniMax-H3 影片生成

2026 年 8 月 27 日 Share to X Copy link

阿里巴巴 PAI 團隊把 MiniMax-H3 變成少步數就能出片的版本。你可以把它理解成針對影片生成速度做加速的 LoRA。

阿里巴巴 PAI 團隊針對 MiniMax-H3 做了 Parallel Decoding Distillation（PDD），目標是用更少推理步數完成影片生成。這份項目同時保留 MiniMax-H3 的兩條路線，分別對應 FL2VA 和 Ref2VA，方便按不同基礎版本套用加速 LoRA。

兩個官方 8-step Acc LoRA，檔名分別是 MiniMax-H3-FL2VA-Acc-8Step.safetensors 和 MiniMax-H3-Ref2VA-Acc-8Step.safetensors，兩者都標示 rank=64、network_alpha=64，並以 BF16 形式提供。這表示它們不是完整底模，而是掛在對應 base model 上的加速適配器。

8-step Acc LoRA 可配合 768p 生成流程，並對比 baseline、Turbo 4-step 版本和 8-step Acc LoRA。

實務上，8-step Acc LoRA 代表在速度和畫面穩定度之間做取捨，重點是把影片生成的推理成本壓低，而不是追求最長流程。相較原始 MiniMax-H3，這類 LoRA 的用途更偏向快速出樣和迭代，適合需要較短等待時間的影片生成工作流。

• 開發團隊是 Alibaba-PAI，並以 MiniMax-H3 做 PDD 加速
• 提供兩個 8-step 官方 Acc LoRA，分別對應 FL2VA 和 Ref2VA
• 檔案以 BF16、rank=64、network_alpha=64 方式發布
• 頁面有 768p Demo，但未交代 GGUF、mmproj 或硬體需求

項目主頁 · 模型

Categories: 開源, 阿里巴巴, AI productions, 多模態模型, 視頻模型, Video, MiniMax

---

Google Antigravity 把版本控制與終端機帶入 AI 開發流程

2026 年 8 月 27 日 Share to X Copy link

Google Antigravity 將版本控制和終端機操作納入 AI 輔助開發，讓編程工作由單次指令延伸至可追蹤、可檢查的完整流程。

當 AI 不只產生程式碼，還要修改檔案、執行指令及整理變更時，版本控制和終端機就成為確保工作可追蹤的關鍵。Google Antigravity 將這些開發工具納入同一套 AI 輔助流程，協助使用者管理由模型完成的程式編輯工作。

流程可以涵蓋檢視程式庫狀態、執行終端機指令，以及核對 AI 作出的檔案變更。使用者毋須只依賴對話內容判斷結果，而是可以配合版本差異和指令輸出，逐步確認每項修改是否符合預期。

這種安排適合需要反覆修改程式、測試結果及回溯變更的編程工作流。它處理的不是單純產生範例程式碼，而是 AI 參與開發後，如何保留人手審查、版本記錄和操作可見性的問題。

• 將 AI 編程與版本控制流程連接
• 支援透過終端機執行開發指令
• 方便檢視及核對檔案變更
• 適合需要測試、回溯和協作的項目

使用時仍然需要檢查指令內容、檔案差異和執行結果，尤其涉及刪除檔案、修改設定或操作外部服務的情況。版本控制可以降低回復成本，但不能取代開發者對變更風險的判斷。

項目主頁

Categories: Agentic, Google, Gemini, IDE, 編程

---

Gemini Live 語音代辦操作，對話直接推進工作流程

2026 年 8 月 27 日 Share to X Copy link

Gemini Live 開始將語音對話變成可執行動作，減少你在應用程式之間來回切換。這次更新瞄準的是日常處理待辦事項時最容易中斷節奏的那一步。

一邊講電話、一邊行路，或者手上正做緊其他事時，最麻煩往往唔係記低待辦，而係之後仲要再打開日曆、記事或清單工具逐個輸入。Gemini Live 今次更新，正正係想將語音對話直接接駁到生產力工作流，令你講完就可以即時推進下一步，而唔係停留喺一段只會回應問題嘅聊天。

Google 把這次升級放在 Gemini Live 內，主打用聲音委派待辦事項。公開內容雖然未詳細列出所有支援動作，但方向已經相當明確：Gemini app 不再只做對答，而係更貼近可代你整理、記錄同安排事項嘅 Agentic 工具。對平日靠手機快速處理雜務、會議後即場補記重點，或者想減少手動輸入嘅人，分別會幾直接。

同常見語音助理只幫你查資料、設鬧鐘相比，呢類整合更著重「講完之後有冇後續動作」。價值唔單止在於語音輸入，而係把理解內容、整理意圖同觸發下一步放入同一段互動入面。代價亦好清楚：功能好不好用，仍然取決於它能接到幾多工具、判斷待辦內容有幾準，以及會唔會喺多步操作中出錯。

• 把語音對話直接轉成待辦相關動作，減少手動整理
• 焦點放在生產力場景，而不只是語音問答
• Gemini Live 朝住 Agentic assistant 方向再行前一步
• 真正體驗取決於工具整合深度同指令理解準確度

現時公開資訊較似功能發布預告，未見完整技術細節、評測數字或支援範圍清單。不過訊號已經好明顯，Google 想令 Gemini app 在對話之外，開始處理更多可落地執行的工作。對想用語音把碎片化雜務一次過交畀系統處理的人，這次更新比單純加強聊天自然度更有實際意義。

項目主頁

Categories: Agentic, Google, Gemini, 工具, 語音, 安全

---

awesome-smart-glasses：智慧眼鏡參考索引

2026 年 8 月 27 日 Share to X Copy link

這份 GitHub 項目整理了 smart glasses 的產品、核心能力和應用場景，適合想看清這條路線現況的人。你可以把它理解成一份把「看見」和「做事」串起來的參考索引。

這是一份開源整理型資源，目標是把 smart glasses 由感知走向行動的能力拆開來看，方便比較產品、平台、基礎能力同應用場景。對開發者、研究員同做可穿戴 AI 的團隊來說，它提供的是一個選型同對照框架，而唔係即插即用的應用。

它收錄代表性 smart-glasses products/platforms、foundational capabilities，同唔同 application scenes，等讀者可以順住一條線理解：眼鏡點樣接收第一身視角、點樣支援互動、再點樣落到日常協助、無障礙、工業流程、醫療同交通安全等場景。相關 paper 亦係主線之一，資料會持續更新。

• 將產品、能力、場景放喺同一個脈絡比較，唔使自己逐篇搵資料
• 適合做市場掃描、研究綜述同產品定位參考
• 對第一身 AI、穿戴式助手同 agentic workflow 特別有參考價值
• 現階段偏向知識整理，唔係部署型工具

GitHub

Categories: 開源, Agentic, 工具

---

GigaBrain-0.7 讓機械人跨場景理解並執行任務

2026 年 8 月 27 日 Share to X Copy link

由家居整理到工業操作，GigaBrain-0.7嘗試令機械人適應更多身體形態與工作環境。

由家居整理到工業操作，機械人要面對的不只是看懂畫面，還要理解指令、預測下一步並控制不同硬件。GigaBrain-0.7 屬於 Vision-language-action (VLA) embodied foundation model，透過統一 understanding、prediction 與 action，處理跨任務及跨機械人形態的泛化問題。

項目以 three-system architecture 組織模型能力，並把預訓練資料擴展至超過 37,000 小時的異質 embodied data，再以 one-stage alignment training 同時優化 vision-language understanding 和 multi-embodiment action generation。相比 GigaBrain-0 系列及包括 π 0.5 在內的先進模型，開發團隊聲稱它在 foundation zero-shot capabilities、language-conditioned instruction following 及 post-training task success rates 均有明顯提升。

GigaBrain-0.7 已提供程式碼、模型和 sample data，模型及資料亦連接至 Hugging Face；但 VLM evaluation code、RoboColiseum、RoboTwin2.0 和 EBench benchmark code 仍列在待辦清單。這代表項目適合研究團隊先重現流程及測試資料管線，未必已具備完整、即插即用的標準化評測環境。

讀者可從以下幾點理解其價值與取捨：
– 支援多種機械人形態，目標是提升跨硬件泛化能力。
– Maker H01 及主流機械人平台涵蓋家居和工業場景。
– 大規模異質資料有助擴闊任務範圍，但亦提高訓練及硬件需求。
– 開放程式碼、模型與樣本資料，方便研究及二次開發。

對機械人研究、具身智能及需要跨平台控制的團隊，GigaBrain-0.7提供了較完整的模型、資料與訓練實作入口；商業落地仍需自行驗證安全性、硬件兼容性、延遲及長時間任務穩定度。

項目主頁 · GitHub

Categories: 開源, 模型, 視覺模型, 多模態模型, 模型訓練, VLA, Robotic, Dataset 數據集

---

TLive-Omni：專攻直播電商的多模態理解模型

2026 年 8 月 26 日 Share to X Copy link

TLive-Omni 將影像、影片、語音和文字統一成文字輸出，特別適合要即時理解直播內容的場景。它同時處理商品畫面、聲音與對話脈絡，目標是減少直播電商裡資訊斷裂的問題。

TLive-Omni 是一個多模態理解模型，針對直播電商場景，把影像、影片、語音和文字整合到同一個文字輸出介面。對做直播監控、商品理解、內容標註或客服輔助的人來說，它處理的是同一場直播裡多種訊號難以對齊的問題。

這個項目建基於 Qwen3.5 backbone，再接入 AuT audio encoder 和輕量 MLP 對齊層，並用 timestamped Per-vGrid 把聲音片段和對應畫面放在一起。它支援最長 256K tokens context，適合長時間直播流的連續理解，而不是只看單段截圖或單句語音。

訓練流程分三階段 SFT，先做語音與語言對齊，再擴展到完整多模態指令跟隨，之後加入 Faithful-RFT，強調回答要貼近直播場景的即時需要。README 亦列出聲音辨識、講者分析、商品視覺定位、文字辨識、時序定位、影片密集描述和 omni-modal QA 等能力，顯示它不是單一功能模型，而是面向直播任務的綜合型系統。

• 4B 和 9B 版本都已公開，方便按算力和部署成本選擇。
• 在直播電商的音訊、影像和影片任務上有不錯表現。
• 對一般基準也有泛化能力，不只局限於單一場景。
• 更適合需要長上下文、多訊號同步分析的團隊。
• 取捨在於它很聚焦直播電商，未必是通用多模態助手的最佳替代。

整體來看，TLive-Omni 把直播場景最麻煩的訊號對齊、長上下文理解和即時回答放在同一條路徑處理，對做電商直播分析、內容審核和銷售輔助的團隊會更實用。它的價值不在於把功能堆滿，而在於把多模態理解收斂到直播工作流裡真正會撞到的問題。

項目主頁 · GitHub · 模型

Categories: 開源, AI productions, 多模態模型, Qwen, Video, Audio, 語音

---

MiniMax-H3 一次生成 120 秒長影片

2026 年 8 月 26 日 Share to X Copy link

它把單次輸出的 MiniMax-H3 變成可接續的長片段影片流程，連音效也一併處理。角色、服裝和道具都會沿鏡頭延續，減少畫面在鏡頭交界處走樣。

H3-LongVideos 針對的是 MiniMax-H3 在長片段生成時最容易出現的問題：每個 shot 各自生成，角色外觀、服裝和道具很容易在鏡頭交界處漂移。這個 ComfyUI 節點把一段文字拆成多個 beats，再把每個 beat 變成一個 shot，並以前一鏡最後一幀接到下一鏡，令整條影片可以維持連貫。

這個項目是基於 ComfyUI 的 H3 支援來做，不是獨立模型訓練；因此只能確認它面向 MiniMax-H3 工作流。它同時處理 FL2VA 與 REF2VA 兩種條件方式，前者用一幀作為鏡頭錨點，後者用參考圖描述角色外觀，方便同一角色在多個 shot 裡保持一致。

輸出最長可到約 120 秒，並提供 soundscape、latent 和 info 等輸出。soundscape 會帶出場景實際使用的環境聲床，latent 則是按時間軸串接的 sampled latents，但在多 shot 情況下，它不是 images 的等價 latent 版本，因為 trim_seam 和 handoff_offset 截的是已解碼影格，H3 又會壓縮時間，所以 seam 附近的畫面仍會存在；只有單 shot 時才會完全對齊。

有用的是工作流層面的控制：prompt 第一段做 anchor，後續段落一段對應一個 shot；character_memory 管角色和服裝；resolution 與 megapixels 分開控制形狀和尺寸；shot_seconds 是上限而不是固定長度，先用 plan_only 預覽拆鏡、時長和警告，會比直接渲染更穩陣。

• 以 ComfyUI 把單次 shot 的 H3 生成改成多鏡頭串接，重點在長片段連貫性。
• 同時處理角色、衣著、道具和旁白/環境聲，減少鏡頭切換時的漂移。
• plan_only 可以先檢查拆鏡結果和警告，不用先燒算力。
• 頁面沒有提供 GGUF、量化版本、base model 或推論框架清單。
• latent 輸出只在單 shot 時可視作等價結果，多 shot 時要留意 seam 與時間壓縮。

項目主頁

Categories: 開源, ComfyUI, 視頻模型, Video, MiniMax

---