InferNews

阿里巴巴 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: 開源, 阿里巴巴, Video, AI productions, 多模態模型, 視頻模型, MiniMax

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

2026 年 8 月 27 日

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

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

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

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

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

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

項目主頁

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

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

2026 年 8 月 27 日

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

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

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

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

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

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

項目主頁

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

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

2026 年 8 月 27 日

這份 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 日

由家居整理到工業操作，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: 開源, 多模態模型, 模型, 模型訓練, 視覺模型, Robotic, VLA, 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: 開源, Qwen, Video, Audio, AI productions, 多模態模型, 語音

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

2026 年 8 月 26 日

它把單次輸出的 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

[教學影片]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, Video, AI productions, 多模態模型, MiniMax

[影片教學] 利用開源探索 3D 世界

2026 年 8 月 26 日

這個開源項目讓你用一張圖或一段文字 prompt，在本地免費生成可自由行走的 3D 世界，毋須依賴雲端服務。

過往要把一張圖變成可探索嘅 3D 場景，往往需要動用雲端 GPU 或者封閉式商業工具。一個新開源嘅世界生成項目反其道而行，主打「本地、免費、完全開源」，用家只需要餵一張圖片，或者寫一段文字 prompt，就可以產出一個可以行入去慢慢逛嘅 3D 場景。對遊戲開發、空間設計或者 VR 內容創作嚟講，呢種「零門檻起手」嘅流程可以省卻大量建模時間。

同一般文生圖或者文生影片模型唔同，呢類世界生成系統要處理嘅唔係單一畫面，而係保持視點一致嘅連續空間。背後通常會結合影像生成、深度估計同體積渲染（volumetric rendering）等幾組技術，再用 NeRF（Neural Radiance Fields，神經輻射場）或類近嘅 3D 表徵方式重建場景，等用家可以即時改變視角行入去睇。

對玩家嚟講，最直接嘅體驗係輸入一張京都街景相或者一句「霧夜嘅科幻實驗室」，幾分鐘之後就有一個可以操控角色行入去嘅小型世界；對開發者嚟講，由於整套工具鏈都係本地行得通，唔使擔心 prompt 或者素材被上傳到第三方伺服器，私隱同成本都較易掌控。

不過本地跑呢類模型對 GPU 仍然有要求，視訊記憶體唔夠嘅話生成時間會明顯拉長；另外世界嘅規模同互動深度仲未去到遊戲引擎嗰種水平，比較適合作為概念驗證或者素材起手稿，而唔係完整場景嘅最終方案。

以下係幾個值得留意嘅重點：

支援圖生世界（image-to-world）同文生世界（text-to-world）兩種入口
完全開源，可在本地離線運行
採用神經輻射場或類近技術做 3D 重建，保持視角一致
私隱同成本上比雲端方案更具優勢
對 GPU 仍有要求，目前較適合做概念驗證階段

項目主頁

Categories: Image, 3D, AI productions, 影像處理, 教學, 世界模型

OpenAI Jalapeño：為大型語言模型推理而造的 ASIC

2026 年 8 月 26 日

OpenAI 夥拍 Broadcom 打造 Jalapeño，瞄準大型語言模型推理，並以每兆瓦吞吐量挑戰 NVIDIA GPU 的效率優勢。

當模型推理成本受到功耗和硬件供應限制，單靠通用 GPU 未必能兼顧速度與效率。OpenAI 以空白設計打造 Jalapeño，屬於專為大型語言模型（Large Language Model，LLM）推理而設的應用專用集成電路（Application-Specific Integrated Circuit，ASIC），並非只針對 OpenAI 自家模型。

Jalapeño 由 OpenAI 與 Broadcom 合作開發，設計工作於 2024 年中開始，約 16 個月後完成製造流片。晶片採用 HBM4 高頻寬記憶體，配合硬件與軟件協同設計，目標是在不同模型及推理工作負載下維持高效能，而非過度優化單一推理環節。

在 OpenAI 實驗室以 InferenceX 測試套件進行的基準測試，聲稱 Jalapeño 的每兆瓦吞吐量優於已測試的 NVIDIA、AMD 及 Google 晶片，亦在效能功耗比上勝過 Blackwell。比較時 Jalapeño 沒有使用 Multi Token Prediction（MTP），其他晶片則採用各自最佳配置，因此結果仍需配合完整測試條件理解。

以通用 AI 推理為設計方向，可運行多類模型
HBM4 令記憶體頻寬接近高階 GPU 的配置
核心指標聚焦每兆瓦的 token throughput
文章未提供公開下載、安裝或一般用戶使用流程

這類晶片最適合大型模型服務商及資料中心，用於推理量大、電力成本高的工作流。Jalapeño 的價值在於能否把高吞吐量延伸至不同模型和長期運行環境，而不只是單次基準測試中的優勢。

新聞主頁

Categories: 開源, NVIDIA, OpenAI, 新聞

Page 1 of 142

1 2 3 … 142 Next »