ComfyUI 眼睛方向 LoRA:用紅點指定角色視線

呢個 LoRA 透過畫面上嘅紅點控制眼睛睇邊度,無論寫實、動漫定 CG 角色都適用。

喺生成角色圖像嘅時候,好多人會發現想控制眼睛視線方向係一件好頭痛嘅事:用 prompt 寫「望鏡頭」或「望向左邊」往往效果不穩定。Eric Venti Seeds 推出嘅 Eyes Direction LoRA,以 black-forest-labs/FLUX.2-klein-9B 作為基礎模型,提供咗一個更直接嘅操作方式——只要喺畫面擺放一個紅點,眼睛就會自動望過去。

呢個 LoRA 嘅運作邏輯係參考圖像入面紅點嘅位置嚟決定瞳孔方向。紅點放喺正中間,雙眼就會望鏡頭,無視身體姿勢;紅點貼近畫面邊緣,視線就會偏向畫框外面。訓練時已包含人眼活動嘅物理極限,所以當紅點放喺「唔可能」嘅位置時,模型會將瞳孔隨機處理。LoRA 採用 MIT 授權,總檔案大小約 258 MB。

為了方便擺放紅點,作者額外開發咗 ComfyUI 專用嘅 Eyes Direction Control node,可以直接拖動紅點預覽效果。如果唔用 node,手動用 Photoshop 整張紅點圖都得。LoRA 同時保留咗原本瞳孔形狀同虹膜顏色,所以風格唔會走樣。

重點摘要

  • 基礎模型:black-forest-labs/FLUX.2-klein-9B
  • 控制方式:以畫面紅點位置決定眼睛視線方向
  • 相容風格:寫實、動漫、CG、漫畫、油畫都適用
  • 配套工具:ComfyUI Eyes Direction Control node,可手動拖動紅點
  • 已知限制:動物眼睛效果差,極端頭部角度或異色瞳情況處理唔穩定

項目主頁 · 模型

Categories: 開源, ComfyUI, 模型, Stable Diffusion, Image

Mask Forcing:雙重遮罩幫影片擴散模型

Mask Forcing 針對自回歸影片擴散蒸餾中嘅模式塌縮問題,利用雙重雜訊遮罩嘅 rollout 策略,令學生模型分佈覆蓋更多教師模式,同時唔使額外影片資料或後訓練。

Mask Forcing pipeline

用 DMD(Distribution Matching Distillation)把雙向影片擴散模型蒸餾成自回歸(AR)學生模型時,影片往往出現過度飽和同過度平滑嘅情況,背後成因係 reverse-KL 目標嘅 mode-seeking 傾向,令學生分佈容易塌縮到教師模型嘅少數模式之上。Mask Forcing 嘅切入點正正係呢個矛盾:佢喺 AR 蒸餾嘅 self-rollout 過程中,沿空間同時間軸隨機遮罩、注入較乾淨嘅 token,藉此擾動 rollout 軌跡,令學生有機會探索教師分佈嘅更多區域。

呢個做法同時帶來兩個好處:擾動令 DMD 嘅學習訊號唔再局限於學生已經覆蓋嘅模式;而較乾淨嘅 token 亦可以作為引導,協助同一 chunk 入面較嘈雜嘅 token 去噪,等中間過渡更穩定,從而減少錯誤喺後續 denoising step 同 chunk 之間累積。整個方法唔需要真實影片監督、唔需要額外後訓練階段,亦唔會增加推論成本,純粹改動訓練期嘅 rollout。

Mask Forcing 屬於一種蒸餾增強策略,主要服務於想把 AR 影片生成做快、但又想避開 DMD 視覺質素下降嘅團隊,例如做實時或近實時影片生成嘅研究同產品線。佢同一般做法嘅取捨清晰:放棄模式集中所帶來嘅短期穩定,換取分佈多樣性同中間步預測嘅可靠性。

  • 針對 AR 影片擴散蒸餾中 DMD 嘅 mode-seeking 問題,用雙重雜訊遮罩擾動 rollout
  • 不需真實影片監督或額外後訓練階段,唔改動推論流程
  • 令學生分佈覆蓋更多教師模式,並以較乾淨 token 引導較嘈雜 token 去噪
  • 適用於追求實時影片生成、又想提升視覺質素嘅研究同產品場景

項目主頁 · GitHub

Categories: 開源, 香港中文大學, 香港科技大學, AI productions, 模型, 模型訓練, Video, 影像模型

MovieGrid 把長片拆成方格生成,解決多鏡頭一致性

來自 UC Santa Cruz 等院校的 MovieGrid 框架,把長片拆成空間方格同步生成,目標是同時兼顧鏡頭內連續動作與跨鏡頭視覺一致性。

Repository image for jwmao1/moviegrid

MovieGrid 針對的痛點很直接:現有影片生成模型傾向犧牲多鏡頭敘事完整性來換取單鏡頭內的動作連貫,而傳統把整段故事沿時間軸壓縮的做法,更會加深這個偏差。

核心做法是把一段長影片切成分佈於空間方格上的短片段,每格只負責少量鏡頭與較短的時間跨度,從而降低單格需要建模的轉場數量;同時所有格子會被聯合生成,並透過 Grid Embedding、角色感知的 Story Prompt 以及 Grid Boundary Loss 來維持格與格之間的銜接。訓練時採用的 Noise-Free Random-Grid Training,會隨機保留部分格子作為乾淨視覺上下文,引導其餘格子的去噪過程。

項目以 Wan2.2-TI2V-5B 作為基座模型,並配搭自家構建的 MGLV 資料集——從 1,000 段長片萃取出 54K 條方格影片,每條都附有角色級故事標註。在等量 token 預算下,MovieGrid 在 1,616 幀長片裡可生成比 Temporal Packing 基線多 6.05 倍的鏡頭,並在自建基準上取得 0.9131 的鏡頭內一致性與 0.5914 的跨鏡頭一致性,分別優於 HoloCine 與 StoryMem。

目前已開源 16 格與 64 格的訓練與推理配置,以及對應的 MovieGrid-16、MovieGrid-64 LoRA 權重;環境需以 Python 3.10 搭配官方 Wan2.2 倉庫安裝。對需要批量產出多鏡頭短片、廣告分鏡或敘事預覽的團隊,這套框架提供了比單時間軸方案更可擴展的路徑,但生成品質仍受基座模型與資料規模所限,未來計劃加入 first frame 與 storyboard 條件控制。

重點摘要:
– 核心方法:將長片切成空間方格短片段並聯合生成,減輕每格時間跨度負擔。
– 關鍵機制:Grid Embedding、角色感知 Story Prompt、Grid Boundary Loss 與 Noise-Free Random-Grid Training。
– 基座與資料:基於 Wan2.2-TI2V-5B,配搭自建 MGLV 資料集共 54K 條方格影片。
– 開源狀態:已釋出 16 格與 64 格的推理配置、訓練代碼,以及對應 LoRA 權重。

項目主頁 · GitHub · 模型

Categories: 開源, AI productions, Embedding, 模型, 模型訓練, Video, 框架, Python, 庫, Dataset 數據集

FireRedTTS3:廣東話與各地方言內容創作,覆蓋 24 種語言與 21 種方言

FireRedTTS3 是把零樣本克隆、語音編輯、聲線設計整合進同一個模型的開源 TTS 項目,支援 24 種語言及 21 種中文方言,亦可純靠文字描述生成全新聲音。

做多語言配音或本地化短片時,最麻煩往往不是翻譯,而是要為每種語言找一個聽起來自然的聲線,又要顧及四川話、閩南話、上海話等方言差異。FireRedTTS3 想處理的就是這個矛盾:它是一個統一式的語音生成框架,把零樣本聲線克隆、語音編輯、以自然語言設計全新聲線三件事放在同一個模型裡,靠的是語義增強的連續語音表徵。

項目分兩個版本。FireRedTTS3-Base 主打多語言克隆,覆蓋 24 種語言(包括粵語在內)以及 21 種中文方言;FireRedTTS3-Instruct 則做到純文字驅動的聲線設計,不需參考音頻,只要描述性別、年齡、音色、語速等特徵,就能合成全新聲音,並且支援語義層與聲學層的自由形式編輯,例如改寫某段對話、調整語速或音量。

相對同類做法,它的差異在於把克隆、編輯、聲線設計整合成單一流程,而非各自獨立訓練模型。在 MiniMax-MLS-Test 上平均 WER/CER 約 3.754%、說話人相似度約 84.8%;在 Seed-TTS-eval 上克隆 WER/CER 約 3.04%、相似度約 78.8%,從公開數字看在多語言與中文方言任務都做到當前較高的水準。

本地配音、廣東話與各地方言內容創作、Podcast 或短影片自動化產出,以及需要快速原型不同聲線的產品團隊,都比較容易受惠。程式碼以 PyTorch 開源,模型已上架 Hugging Face 與 ModelScope,可透過 Python API 呼叫,亦提供 Instruct API 處理聲線設計與編輯。

重點摘要:

  • 多語言零樣本克隆:覆蓋 24 種語言及 21 種中文方言,包括粵語、四川話、上海話、福建話等。
  • 統一語音生成框架:把克隆、聲線設計、語音編輯整合在同一模型內,避免切換多套工具。
  • 純文字聲線設計:以自然語言描述性別、年齡、情緒等特徵即可合成全新聲音,無需參考音頻。
  • 自由形式語音編輯:支援語義層改寫(插入、刪除、替換)及聲學層調整(語速、音量、音調)。
  • 開源易取用:PyTorch 實作、Apache 2.0 授權,模型於 Hugging Face 與 ModelScope 提供下載。

GitHub · 模型

Categories: 開源, 文字轉語音, AI productions, 模型, API, Video, Audio, 語音, 廣東話

Perplexity 開源 Lily:Mac 本地推理專用提速引擎

Perplexity 推出針對 Apple Silicon 與 Qwen3.6-35B-A3B 的本地推論引擎 Lily,繞過 PyTorch 與 MLX,以 Rust 和自訂 Metal kernels 改善預填充及解碼效率。

Repository image for perplexityai/pplx-garden

當大型模型開始負責處理 Mac 上的私人檔案與應用程式,本地推論速度就不再只是開發者實驗的指標。Perplexity 開源嘅 pplx-garden 入面,Lily 以工具項目形式處理 Apple Silicon 上 Qwen3.6-35B-A3B 的推論,目標係令提示詞處理及文字生成更快,並透過 OpenAI-compatible HTTP API 串接聊天流程。

Lily 唔似 MLX-LM 般追求支援多款模型,而係集中服務 Qwen3.6-35B-A3B:Rust runtime 負責載入 checkpoint、管理 session state 同生成迴圈,自訂 Metal kernels 就處理模型特定運算。呢種單一進程、模型與 runtime 共同協調嘅做法,減少通用 kernel 帶來嘅額外調度,亦避開 PyTorch 和 MLX execution path。

pplx-garden 不只是 Mac 本地推論工具。fabric-lib 提供 RDMA TransferEngine,同時涵蓋 P2P MoE dispatch 與 combine kernel;pplx-unigram 則係針對 Unigram tokenizer 嘅 CPU encoder。相關內容亦包括 trillion-parameter model 喺 AWS EFA 上嘅部署,以及 RL post-training 權重轉移、分離式 prefill 和 decode 等系統研究,顯示儲存庫涵蓋由裝置端推論到分散式 LLM infrastructure 嘅多個瓶頸。

適合需要喺 Mac 處理敏感資料、又希望保留本地生成能力嘅開發者及研究團隊;需要 RDMA、MoE 溝通或 tokenizer 優化嘅系統工程人員亦可參考相關元件。現有資料集中講述 Lily 分別量度 prefill throughput 同 decode throughput。

重點摘要:
– Lily 專為 Apple Silicon 與 Qwen3.6-35B-A3B 設計,支援 OpenAI-compatible HTTP API。
– 以 Rust runtime 配合自訂 Metal kernels,分開處理 prefill 同 decode。
– 不經 PyTorch 或 MLX execution path,代價係模型及硬件支援範圍較專門。
– fabric-lib 同 p2p-all-to-all 面向 RDMA、MoE dispatch 與 combine 等分散式推論問題。
– 效能應按裝置、上下文及生成負載實測,不能只依賴官方定位作比較。

項目主頁 · GitHub

Categories: 開源, 模型, 模型訓練, Qwen, OpenAI, API, 提示詞, 工具, Mac, Python, 庫, 蘋果, Dataset 數據集

MiniMax H3 Director Studio:Windows 本地模型做 AI 影片前期製作

Director Studio 是一個本地優先的前期製作工作空間,串接 Ollama 規劃鏡頭、ComfyUI 生成畫面,再交由 MiniMax H3 出片,特別適合想完全控制創作流程的獨立創作者。

Repository image for ai2764/Director-Studio

想在本地完成 AI 影片從構思到成片的整條前期流程,而不依賴雲端訂閱?Director Studio 正是針對這個需求的工作空間類工具。它把鏡頭規劃、可重用的視覺與語音資產管理、以及 MiniMax H3 Ref2AV 提示詞撰寫,整合在同一個介面內,最後透過 ComfyUI 與 MCP 協議生成圖像與影片。

與一般 ComfyUI 前端不同,它把「規劃 Agent」綁定在本地 Ollama 上運行,並與 ComfyUI 共享 VRAM,避免兩者搶顯存。用戶可以選擇全本地流程,亦能把 H3 影片交給官方 MiniMax API 處理,兼顧靈活與效能。內建的 typed asset library、演員與場景工作流、可編輯的 Picture/Audio 參考、以及六段式 H3 提示詞結構,讓鏡頭設計不再是憑感覺亂試。

Qwen3.8 27B Directs H3 | Director Studio Is Now Open Source

對於獨立創作者、小型製作團隊,或需要反覆迭代鏡頭分鏡的人,這套工作流省下了在不同工具間切換的成本。Windows 用戶只要安裝 Ollama、ComfyUI Desktop 與 Python 3.10+,再解壓官方 zip 即可透過 DirectorStudio.exe 啟動,所有資料儲存在執行檔旁的 data 目錄,方便升級前備份。

採用 FastAPI 後端配合 Vite + React 前端,規劃 LLM 透過 Ollama 執行,生成層則透過 ComfyUI MCP 串接。架構與擴展點已在 docs/ARCHITECTURE.md 說明,適合想自行修改管線的進階用戶。

需要注意,VRAM 是這套系統的瓶頸:Ollama 與 ComfyUI 需共享顯存,若要同時運行大型本地模型與高解像度影片工作流,硬體門檻不低。對於偏好全雲端、或無獨立顯卡的用戶,這套方案未必比 SaaS 工具方便。

GitHub

Categories: 開源, ComfyUI, Agentic, AI productions, MCP, 模型, 多模態模型, API, Video, Image, Audio, 工具, Content Creator, Ollama, Python, 庫, MiniMax

Dr. Claw 把 AI 研究流程收進一個可審核工作台

一款開源 AI 研究助理,把文獻回顧、實驗、寫作整合在同一介面,讓人類決策與 AI 執行之間留下可追蹤的紀錄。

Dr. Claw

跑過 AI 研究的團隊都遇過同樣的痛:Claude Code、Gemini CLI 等命令行編碼代理(coding agents)能讀寫檔案、撐住長對話,但文獻回顧、構思、實驗、寫論文、投期刊這些步驟散落在聊天工具、IDE、終端機、寫作軟件之間,中間決策也難以回頭追溯。Dr. Claw(GitHub: OpenLAIR/dr-claw)針對的正正是這個碎片化問題——它不是另起爐灶造一個新代理,而是把現有命令行編碼代理(Claude Code、Gemini CLI、Codex,以及透過 OpenRouter 接入的數百個模型)包進一個可控、可審核、人在回路(human-in-the-loop)的工作流。

項目覆蓋 survey → ideation → experiments → paper writing → slides & promotion 整條研究生命週期,與只懂執行程式碼的 CLI 代理相比,差異在於「全流程編排層」。底層靠三個關鍵設計撐起這層:持久化狀態物件(persistent state objects)、可重用技能庫(reusable skill library),以及多執行器協調(multi-executor coordination),把計劃、執行、寫作綁成一條可恢復的循環。論文亦明確指出,比起只共享同一後端執行器的裸 CLI 代理,Dr. Claw 在研究完整性上得分更高,同時保留可審計、可回溯的過程痕跡。

對獨立研究者、AI 實驗室團隊、需要把研究流程制度化的單位而言,這套架構的價值在於把人類決策(目標、約束、驗收)與 AI 執行清楚分開,並透過 checkpoint 反饋(Verify / Revise / Retry / Handoff)保留介入點。它支援本地部署(自家機器、自家 GPU、自家資料),亦提供桌面版(.dmg / .exe)或 npx dr-claw 零安裝啟動,甚至能在終端機直接 dr-claw chat 跑 agentic 對話。

項目已被 EMNLP 2026 System Demonstrations track 收錄(arXiv: 2609.00365),並採用 AGPL-3.0 搭配上游 GPL-3.0 元件授權,免費、無訂閱。需要留意的是,它自定位為 Anthropic Claude Science 的開源、模型中立替代方案,主打全生命週期而非單純計算分析。

GitHub · Paper

Categories: 開源, Agentic, 模型, OpenAI, Gemini, 軟件, 工具, IDE, 庫, 編程, Anthropic, Skill 技能

EditVid:零訓練、單一框架處理五大影片編輯任務

伊利諾伊大學 PLAN Lab 推出 EditVid,毋須訓練即可在一個框架內完成風格轉換、屬性修改、物件插入等多種影片編輯。

PLAN Lab Logo

想用同一套方法幫一段影片換風格、改顏色、甚至換主體,又唔想為每種任務訓練專屬模型?PLAN Lab(伊利諾伊大學厄巴納-香檳分校)嘅 EditVid 正正就係為呢個煩惱而設計。佢屬於免訓練(training-free)嘅影片編輯框架,直接喺凍結嘅多模態擴散 Transformer(MM-DiT)圖像編輯器上動手術,同時支援文字指令引導同參考圖引導兩大路線。

對一般用家嚟講,最大體感差異係:一條原本只能用嚟改顏色嘅編輯鏈,現在仲可以做局部部件編輯、物件插入、主體替換等五類任務,唔使每樣重新煉模型。你叫佢「將大象變藍色」、「將海浪轉做黑色」、「將衣服轉紅色」,佢都能在同一條流程內完成。

佢能夠兼顧短距離同長距離一致性,關鍵在於三個互相配合嘅設計:

  • 稀疏因果記憶:每幀只向前一幀取視覺鍵值狀態,避免長距離 RoPE 交互變得唔穩定。
  • 後注意力 Token 注入:用置信度同循環一致性匹配把幀同錨點幀對齊,再注入匹配到嘅視覺表示,維持主體外觀一致。
  • 軟潛空間混合:根據時間步動態調整保留權重,源內容需要保留嘅地方唔會被強行覆蓋。

量化結果方面,喺 FiVE 基準上 EditVid 拎到 78.16 分 FiVE-Acc,比目前最強嘅訓練免費基準高出近 20 分;喺 IVEBench 上面亦取得具競爭力嘅成績。用戶研究入面,超過一半受訪者(51.8%)傾向揀 EditVid 而唔係其餘 7 種對比方法。

如果日常工作涉及大量短片二次創作、廣告素材改版、或者需要快速試驗唔同視覺風格,EditVid 提供嘅「零訓練、單一框架」思路可省卻大量前置準備成本。

項目主頁 · GitHub · Paper

Categories: 開源, AI productions, 模型, 多模態模型, 視頻模型, 模型訓練, Video, Image, 框架

OmniEvalKit:唔使重新訓練 VLM 都可以聽聲答問題

MBZUAI Oryx 團隊把 OmniEvalKit 開源出嚟,主打唔使改動 VLM 任何參數,就為佢加掛語音理解能力。對於想評估或部署多模態模型嘅團隊,可以直接拎現成骨幹即試。

Training-Free Omni

想為一個視覺語言模型加入語音理解,但又唔想重新訓練?MBZUAI Oryx 團隊開源嘅 OmniEvalKit(Training-Free Omni)就正正針對呢個痛點。它把語音先經 Whisper 抽取成帶時間戳、語言同信心分數嘅結構化文字,再連同圖片或影片幀一齊餵俾凍結嘅 VLM,所有推理都沿用原本嘅 prompt 接口,骨幹權重全程不動。換句話講,任何新嘅視覺骨幹都可以即插即用,毋須再做語音—視覺對齊微調。

它同時係一個統一嘅多模態評測框架,支援文字、圖片、影片、音頻同音視頻任務,並預載 118 個資料集適配器,涵蓋 Qwen、Gemma、MiniCPM、VILA、OmniVinci 等模型,方便做公平對齊測試。對研究人員同部署團隊而言,最直接嘅好處係可以一次過跑 56 個 benchmark、21 種語言,直接比較凍結骨幹同原生 omni 模型之間嘅差距,睇下語音能力究竟係新加出嚟定係由舊能力交換得嚟。

如果你關心 VLM 加掛語音後會唔會「失憶」,呢套框架正正提供 matched comparison,可以量化評估圖像理解、視覺定位、編碼、數學等原有強項有冇被削弱。額外支援嘅 CosyVoice3 文字轉語音輸出,亦令文本答案可以直接變成語音回覆。

要本地跑得起嚟,需要 Python 3.10+、ffmpeg,再針對 CPU、CUDA 或 ROCm 安裝對應嘅 PyTorch。之後透過 eval.sh 配環境變數指定模型同資料集即可開跑,加 MAX_SAMPLES=3 可以做煙霧測試,中斷後設 RESUME=True 可以接返。

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

  • 凍結骨幹、零微調:所有 VLM 權重完全不變,語音理解透過 Whisper 抽取文字證據再加 prompt 融合達成。
  • 即插即用嘅 omni 能力:支援 Qwen2.5-Omni、Gemma、MiniCPM、VILA、OmniVinci 等多個模型適配器,方便横向比較。
  • 覆蓋廣嘅評測矩陣:內置 118 個資料集適配器,涵蓋 56 個 benchmark 與 21 種語言。
  • 原生 omni 同凍結骨幹嘅 matched 對照:可以清晰分辨新增能力同保留能力,避免重訓帶嚟嘅 capability drift。
  • 可選語音回覆:透過 CosyVoice3 把文字答案合成語音輸出,適合對話式場景。

項目主頁 · GitHub

Categories: 開源, 文字轉語音, AI productions, 模型, 視覺模型, 多模態模型, 模型訓練, Qwen, NVIDIA, Gemini, Video, Image, 框架, Python, 語音, Dataset 數據集

Spark-X2.5:4B 參數追平 12B

Spark-X2.5-4B 用混合架構把 1M token 上下文塞進小模型,並在編碼與 Agent 場景追上 12B 等級對手。

Og image

Spark-X2.5-4B 由 XHToken 發佈,基礎模型標註為 XHToken/Spark-X2.5-4B-Base,屬於通用對話型 LLM,覆蓋寫作、翻譯、推理、編碼、工具調用與 Agent 工作流。「小模型也能扛長上下文」這條路線:採用 1 層全注意力 + 3 層滑窗注意力(sliding-window attention)的混合架構,把長序列的計算成本壓低,同時原生支援最長 1M token 上下文。對本地開發者而言,這代表不必依賴昂貴的長上下文方案,也能處理長文檔或多輪 Agent 記錄。

模型在 Agent 整合上做了明確適配,與 Codex、Claude Code、OpenClaw、Hermes 等主流 agent harness 對齊,讓它在編碼與工具調用評測中,在同尺寸開源模型裡取得領先位置。對想自架本地 Agent 的人來說,這層適配省去不少 prompt 與調用格式的微調工作。

部署兼容性是它的另一個賣點:原生支援 NVIDIA、華為、海光、HOUMO.AI 等硬件平台,推論框架覆蓋 vLLM、SGLang、llama.cpp、MLX,亦可透過 Ollama、LM Studio 快速啟動。頁面提供 Hugging Face Transformers 格式的權重與配置,授權為 Apache-2.0。

Spark-X2.5-4B 適合追求長上下文與 Agent 能力、又受限於硬件預算的開發者,但要實際部署前宜留意量化檔案與推論引擎的官方更新。

重點摘要:
– 基礎模型:基於 XHToken/Spark-X2.5-4B-Base 微調的對話模型
– 混合注意力架構:1 層全注意力 + 3 層滑窗,原生支援 1M token 上下文
– Agent 整合:適配 Codex、Claude Code、OpenClaw、Hermes 等主流 agent harness
– 硬件與推論支援:涵蓋 NVIDIA、華為等平台,兼容 vLLM、SGLang、llama.cpp、MLX,可走 Ollama 與 LM Studio
– 授權:Apache-2.0;頁面未列出 GGUF 量化檔,部署前需留意官方或社群進度

項目主頁 · 項目

Categories: 開源, Agentic, 模型, 框架, OpenClaw

Page 25 of 59
1 … 23 24 25 26 27 … 59