多模態模型

StreamPI 機械人模型的記憶系統

2026 年 8 月 27 日

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

Overview of the StreamPI architecture and streaming inference workflow

機械人執行抓取、插入等連續任務時，只看當前畫面容易失去物件位置變化；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 數據集

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

2026 年 8 月 27 日

阿里巴巴 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

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

2026 年 8 月 27 日

由家居整理到工業操作，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 日

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 六格分鏡生成多鏡頭 AI 影片

2026 年 8 月 26 日

MiniMax H3 加入六格分鏡網格參考功能，用戶可直接餵故事板圖，再生成多鏡頭連貫短片，解決單鏡頭 AI 影片動作細節不足的問題。

AI 影片生成最常見的痛點之一，是鏡頭內動作幅度細，剪接起來又欠缺段落感。MiniMax H3 這次加入的 6-Grid Reference（六格分鏡網格）功能，嘗試從輸入端就解決這個問題：使用者把一張包含六格分鏡的故事板圖丟入模型，H3 會按格子內容分別生成對應鏡頭，再組成一條多鏡頭短片，避免單次生成只能「前後郁幾吋」的局限。

對熟悉影視分鏡流程的人來說，這等於把前期 storyboard 直接搬進生成管線。對一般創作者而言，操作門檻也比逐個鏡頭獨立 prompt 再拼接低很多——畫好六格、寫好提示詞，剩下的運鏡與節奏交給模型處理。

以下是這次教學與功能值得留意的幾個重點：

六格分鏡直接餵入：以一張 2×3 或 3×2 的網格圖作為視覺參考，模型按格生成對應鏡頭，無需逐個 cut 分開生成。
多鏡頭連貫輸出：最終成品會包含多個 shot，而非單一長鏡頭，方便直接接上剪接流程。
適合分鏡先行的工作流：對動畫短片、廣告腳本、遊戲過場等已有 storyboard 習慣的團隊特別受用。
降低逐鏡 prompt 成本：一次輸入即可覆蓋多個鏡頭，減少重複描述角色、場景、風格的工序。
與 H3 既有能力整合：可與 H3 的角色一致性與風格控制一併使用，保持多鏡頭之間的人物與美術統一。

教學影片示範的工作流程大致是：先準備好六格分鏡圖，每格代表一個鏡頭的構圖與動作重點，提示詞內描述場景氛圍與鏡頭運動方向，再由 H3 一次過輸出。對於想快速測試分鏡概念、或者要把動畫前期視覺化的人，這條工作流比起從零開始寫分鏡 prompt 更直觀。

需要留意的是，六格分鏡的格數、比例與每格內容差異會直接影響成品質素，每格的構圖與動作如果太擠迫或太模糊，模型理解鏡頭意圖時容易出錯。建議先用簡潔構圖測試，再逐步加入複雜元素。

影片主頁 • ComfyUI 工作流 • 特別版 H3 模型

Categories: 開源, ComfyUI, AI productions, 多模態模型, Video, MiniMax

OraRL：標註即 Rollout，統一多模態模型強化學習

2026 年 8 月 26 日

OraRL 把影片標註轉成可靠的正向 rollout，令同一模型兼顧定位、分割、追蹤、問答與空間理解。

面對一段長影片，模型要同時回答內容問題、找出時間片段、定位畫面區域，往往要在多套任務方法之間取捨。OraRL 是一個用於統一影片多模態模型（video MLLMs）強化學習的研究項目，將原本只用來評分答案的標註，序列化成模型可直接學習的 oracle rollout。

它的核心做法是把一條標註答案加入同一提示的 policy samples，再只用 policy rewards 計算 on-policy baseline，避免準確標註扭曲模型原本的相對比較；annotation-policy reward gap 則用於方向性修正，最後以 sign-balanced pruning 篩選更新訊號。這個安排保留探索，同時不需要 chain-of-thought supervision 或額外解碼。

同一套更新規則覆蓋 temporal grounding、spatial grounding、segmentation、tracking、spatial-temporal grounding、video QA 及 spatial intelligence，Video-ORA-9B 則以一個模型處理七類影片理解任務。4B 設定的更新時間由每步 92.5 秒降至 62.4 秒，速度提升 1.48 倍，單張 GPU 峰值記憶體亦由 62.4 GB 降至 50.9 GB。

推理部分提供較實用的取捨參考：H20 以 vLLM 和 BF16 載入時，4B 及 9B 分別佔 8.6 GiB 和 17.6 GiB；十分鐘、每秒兩幀的影片採用 answer-only decoding 後，總延遲由 29.03 秒降至 24.30 秒。儲存庫列出 Environment、Training 及 Evaluation 文件，但提供的資料未包含完整安裝步驟或可直接下載模型的細節，較適合研究團隊按文件檢查環境後測試。

訓練方法：標註同時作為正向 rollout 和任務有效的學習目標。
涵蓋範圍：一套 RL recipe 支援七類影片感知任務。
效率改善：4B 更新速度提升 1.48 倍，記憶體需求下降。
推理優化：支援影片快取、一次解碼重用及 answer-only decoding。
適合情境：需要統一處理影片定位、追蹤、分割、問答和空間推理的研究或工程團隊。

項目主頁 · GitHub · 模型

Categories: 開源, 模型, 多模態模型, 世界模型, 模型訓練, Video, 影像處理, 框架, Dataset 數據集

WeMM-Embedding 統一多模態向量

2026 年 8 月 26 日

WeMM-Embedding 把文字、圖片、影片和視覺文件放進同一套向量空間，適合要做檢索、比對和跨模態搜尋的場景。它同時提供不同尺寸選擇，方便在準確度與成本之間取捨。

WeMM-Embedding 是一組多模態 embedding 模型，目標是把文字、圖片、影片、視覺文件和交錯式多模態輸入，轉成可直接比對的統一向量。對要做搜尋、相似度比對、內容檢索或跨媒體匹配的團隊來說，這種做法比逐一分開處理不同素材更省事。

它提供 2B、4B、9B 三個版本，還支援 Matryoshka dimensions，代表可以按需要輸出不同長度的 embedding，減少計算和儲存成本。README 也提到，向量來自 <embedding> token 的最後一層 hidden state，再做 L2 normalization；目前不支援 audio。

實作和試跑方式都算直接，既可以用 transformers，也可以用 SentenceTransformer 直接載入 Hugging Face 模型 ID。作者同時標明推理較建議用 transformers==5.2.0，原因是較新的版本在前處理行為上可能有差異；serving 方面則測過 vLLM 和 SGLang。

統一處理 text、image、video、visual document 和 interleaved multimodal inputs
支援 Matryoshka dimensions，可按成本需要縮短 embedding 長度
適合做跨模態搜尋、內容去重、相似度比對和檢索索引
推理可用 transformers 或 SentenceTransformer，部署可接 vLLM、SGLang
現階段不支援 audio，做語音相關流程要另配其他模型

對要處理多媒體內容的應用團隊、檢索系統、內容平台和資料整理流程，這類模型最直接的價值是減少多套表示法之間的銜接成本。它在多個基準上取得領先結果，但實際選型仍要看你要的是完整維度、較低成本版本，還是偏向部署效率的配置。

GitHub · 模型

Categories: 開源, 騰訊, AI productions, Embedding, 模型, 多模態模型, Video, Image, Audio

JoyAI-Echo: 拓展長音訊視訊生成技術

2026 年 8 月 26 日

它把文字轉影片做成可跨鏡頭延續的音畫生成流程，重點不只是一段片，而是人物、聲音同場景連貫下去。ComfyUI 節點版本可配合官方推理管線，方便逐鏡調整。

JoyAI-Echo 是一個面向 text-to-video（T2V）同多鏡頭長片段生成的模型項目，處理的是短提示詞難以撐住長篇敘事、角色外觀與聲音容易斷裂的問題。它的做法不是單段出片，而係用跨鏡頭 memory 去維持故事連貫，連動音畫一致性。

官方說明強調它走 full bf16 precision，唔採用 GGUF quantization，目標係貼近正式推理管線的輸出。現階段支援 T2V，同多鏡頭長視頻；image-to-video（I2V）未支援。另有 ComfyUI_JoyAI_Echo 節點包，適合想喺工作流入面逐鏡改 prompt、即時預覽、再串接後續鏡頭嘅人。

可做長篇音畫故事，展示例子去到 10 分鐘
支援少步數生成，長片與 causal world model 都偏向快速推理
cross-shot memory 會保留角色外觀、聲線同連貫性
ComfyUI 版本方便分鏡調整，同官方管線保持一致
目前重點在 T2V，多鏡頭長片段，未覆蓋 I2V

它和一般單段影片模型最大分別，在於將「一段生成得像」推進到「多段接得住」。如果要放進實驗室、內容團隊，或者做互動世界、長敘事原型，這種可續接的記憶機制會比只看單次輸出更實用；但代價是對 GPU 記憶體要求高，官方節點提到 48GB VRAM 同 GPU memory hot-swap 才較穩陣。

項目主頁 · GitHub

Categories: 開源, ComfyUI, 多模態模型, 視頻模型, 世界模型, Video, Image, Audio

UniSpace：把理解、生成與編輯放進同一視覺空間

2026 年 8 月 25 日

UniSpace 嘗試用同一套視覺表示處理影像理解、生成與編輯，但首個程式版本仍未包含訓練流程。

影像模型往往要在語意理解與畫面細節之間取捨，UniSpace 以統一視覺表示同時處理理解、生成和指令式編輯，定位是多模態模型及推理評估項目。它由 patch-reparameterized vision encoders 和 Qwen3-8B Mixture-of-Transformers 組成，前者保留預訓練模型的語意能力，再補足重建與生成所需的細節。

三款 encoder 分別是 PR-SigLIP2、PR-DINOv2 和 PR-Qwen-ViT；UniSpace 則使用配備 Qwen-based patch-reparameterized tokenizer 的視覺空間。這種分工讓同一套表示可以連接理解、文字生成影像及影像編輯，但也代表模型效果取決於 encoder、tokenizer 和多模態 backbone 能否協調工作。

ImageNet-1K 256 × 256 重建測試使用 50,000 張驗證影像，PR-DINOv2 取得最高 PSNR 30.84、SSIM 0.90 和最低 rFID 0.14。生成測試同樣使用 50,000 個樣本；PR-DINOv2 配合 Classifier-Free Guidance (CFG) 後，gFID 為 1.877、IS 為 274.16，但 Recall 由 0.637 降至 0.605，反映畫面品質與覆蓋範圍之間仍有取捨。

目前最需要留意的是可重現性，而不是安裝難度。儲存庫屬於 paper-time landing release，首個程式版本只會提供 inference 和 evaluation，訓練程式及內部數據管線不公開；在預期檔案和 checkpoints 尚未完整發布前，fresh clone 不能直接執行命令。研究團隊、模型評測人員和需要比較視覺 encoder 的開發者可先參考固定 seed、採樣步數及評測規則，待穩定版本發布後再驗證結果。

能力範圍： 統一支援影像理解、生成與 instruction-based editing。
模型關係： PR-SigLIP2、PR-DINOv2、PR-Qwen-ViT 提供視覺表示，Qwen3-8B Mixture-of-Transformers 負責多模態處理。
評測結果： PR-DINOv2 重建 rFID 0.14，UniSpace GenEval 整體分數 0.84，DPG-Bench 為 86.49。
限制： 目前欠缺可由 fresh clone 直接執行的完整程式、訓練流程及內部數據管線。

項目主頁 · GitHub

Categories: 開源, 多模態模型, Qwen, Clone, Dataset 數據集

[技術文章] RecVerse 讓購物代理更像真人行為

2026 年 8 月 25 日

RecVerse以分層記憶和整段軌跡訓練，模擬更貼近真人的網上購物流程。

網上購物模擬器要重現真人由瀏覽、比較到購買的連續決定，才能支援推薦系統的離線測試和 Reinforcement Learning（RL）訓練。RecVerse 是一個以 GUI 為基礎的模擬代理，透過螢幕截圖理解頁面，生成多輪購物軌跡，處理長時間瀏覽中用戶狀態不斷變化的問題。

現有做法各有缺口：Rule-based simulators 依賴向量化商品特徵和預設行動空間，難以涵蓋複雜的電商介面；Large Language Models（LLMs）和 Vision-Language Models（VLMs）代理雖然加入推理及 persona 建模，長會話仍可能丟失早期觀察，或者把所有歷史硬塞進 context window。逐步模仿每個已記錄行動，亦可能令整段流程出現過度探索或過分被動等不自然模式。

RecVerse以認知啟發的分層記憶處理長期資訊，包括短期焦點用的 Working Memory、保存本次會話軌跡的 Episodic Memory，以及記錄高層次意圖的 Preference Memory。記憶更新本身被視為行動，代理可以按情況學習何時及應該保存哪些資訊。

訓練時，系統改用 trajectory-level RL，直接為完整購物會話評分，同時對齊真人的宏觀行動類型分佈和微觀購物意圖。研究團隊亦發布 USB（UserSimulationBenchmark）互動式電商 GUI 軌跡數據集；實驗結果指 RecVerse 在行為忠實度和意圖一致性上均優於現有基線。

以螢幕截圖理解電商 GUI，生成多輪購物行為
透過三層記憶保留短期焦點、會話經歷和用戶偏好
用完整軌跡目標修正逐步模仿帶來的不自然行為
USB 提供互動式電商 GUI 軌跡數據集
可用於推薦策略的離線及反事實測試

Paper

Categories: 阿里巴巴, Agentic, 視覺模型, 多模態模型, 模型訓練, 中國

Page 4 of 23

« Previous 1 2 3 4 5 6 … 23 Next »