InferNews

Color Pass-Through 重新做色彩校準

Share to X
Color Pass-Through teaser

想像你透過手機或頭戴裝置睇現場畫面，明明場景喺眼前，畫面顏色同亮度卻總有一層隔膜。Color Pass-Through 針對的正正係呢種 camera-display 不一致：它屬於影像處理研究項目，以端到端方式學習固定裝置上的 camera-display 路徑，目標唔係單獨校正相機或螢幕，而係令人經過裝置觀看時，感知上更接近真實場景。

作者明確反對傳統 ICC workflow 呢種兩段式校準範式。舊做法會先分開處理相機同顯示器，再靠預先定義的中介色彩空間接駁，誤差容易逐步累積；Color Pass-Through 改為直接學完整投影路徑，並為每位觀察者做 one-step calibration。呢個取向的好處係更貼近人眼最終見到的結果，代價就係它依賴特定 device pair，同時帶有 observer-specific 設定，泛化方式同傳統標準化流程唔一樣。

目前公開資訊顯示，項目已放出完整 training and inference pipeline，並提供兩款支援裝置的 pretrained checkpoints，所以較合理的理解方式係：它首先係研究原型，其次先係可重現的程式碼。資料集仲準備公開，Android toy example 亦仍在開發中，部署重點暫時仍然放喺已支援裝置上重現論文結果，而唔係即插即用地套入任何手機。

  • 核心改動係把 camera 與 display coupling，唔再經固定中介色域分開校正
  • 以每位使用者一次校準換取更貼近主觀觀感的色彩與亮度表現
  • 人類評分提升 +2.0 分（5 分制），亮度 4.32/5，色彩 4.03/5
  • 定量結果亦有明顯優勢，PSNR、ΔE、STRESS 在兩款商用手機上都優於列出的基線

同類方法很多時會加強 white balance、ColorChecker mapping，或者在既有 ISP 後面再補一層修正；這個項目則直接把問題重寫成特定裝置、特定觀察者的整體感知重建。對做 AR/VR pass-through、顯示校準、計算攝影研究的人最有參考價值，尤其當重點唔係標準色彩流程有幾完整，而係人眼最後見到的畫面到底似唔似真景。

項目主頁 · GitHub · Paper

Categories: 開源, 香港中文大學, 華為, 模型訓練, 蘋果, Dataset 數據集

GraphVid 把圖生影片拆解成圖節點關係圖

Share to X
Og image

PLAN-Lab（伊利諾伊大學厄巴納-香檳分校）開源的 GraphVid 採用 Diffusers 框架，用 Stable Diffusion 類的 Diffusion Pipeline 配 bfloat16 精度載入，適用於 CUDA 與 Apple MPS 裝置。這個名稱裡的「Graph」不是社群網絡圖，而是把影片拆成多個關鍵畫面節點，再用一張小型關係檔 graph.pth（約 118 MB）描述節點之間如何銜接——模型先理解這些畫面該怎樣排序與過渡，再交由 transformer、VAE 等模組逐段生成。

頁面沒有公開 base model 來源，也沒有說明訓練資料或評測指標，因此難以判斷它的整體品質，只能從架構面推測它把控制粒度從「逐幀文字描述」轉移到「節點拓樸」。使用 DiffusionPipeline.from_pretrained 配合 torch_dtype=torch.bfloat16，屬於現今影片擴散模型常見的省記憶體做法。

從模型卡提供的程式碼範例可見，GraphVid 直接接受文字 prompt 即可生成畫面，毋須手動編排節點，這層抽象對一般使用者比較友善；進階用家則可透過 graph.pth 微調節點關係，控制運鏡節奏。整個 gvc_ckpt_folder 容量約 64.3 GB，包含 scheduler、text_encoder、tokenizer、transformer、VAE 等標準組件，搭配 Hugging Face 提供的 Colab / Kaggle 範例即可快速試跑。

  • 關係圖驅動：以 graph.pth 定義畫面節點與時序關係，再交由擴散模型生成影片。
  • Diffusers 相容：透過 DiffusionPipeline 載入，支援 bfloat16 與 CUDA / MPS。
  • Apache-2.0 授權：可自由下載研究與再分發，但頁面未提供量化版本。
  • 硬體需求高：完整 checkpoint 約 64.3 GB，建議使用高階 GPU。
  • 缺乏評測數據：原始頁面沒有提供基準分數或與其他影片模型的直接比較，採用前宜自行測試。

若以本地消費級 GPU 試跑，建議先把 torch_dtype 設為 bfloat16，並留意 VRAM 是否足以容納 transformer 與 VAE 的權重；想進一步壓縮，可留意社群後續是否釋出量化或 LoRA 版本。

項目主頁

Categories: 開源, Google, NVIDIA, Stable Diffusion, Image, Python, 教學, 蘋果, 框架

OpenWorker – Andrew Ng 開發桌面 AI 龍蝦

Share to X
How OpenWorker works

對好多打工仔嚟講，最大嘅困擾唔係 AI 唔夠聰明，而係佢只識得「答問題」而唔識得「做完件事」。OpenWorker 嘅切入點正正喺呢度：佢定位係一個會跑喺你電腦上面嘅 AI 同事，可以幫你整理 calendar、寫 follow-up email、甚至自動出一份 customer brief，最後畀你一份可以直接開嚟用嘅文件，唔係一串對話。

OpenWorker 由 Andrew Ng（吳恩達）相關團隊推出，引擎建基於佢哋自己開發嘅 Python 開源庫 aisuite，呢個庫提供統一嘅 chat-completions API 以及支援工具調用（tool calling）、MCP 等功能。簡單講，OpenWorker 唔係從零寫起嘅 wrapper，而係將 aisuite 包成一個真正面向桌面用戶嘅應用，並且喺原本 aisuite 倉庫入面開發咗一段時間之後，先搬出嚟獨立成 repo。

目前支援 macOS（Apple Silicon）以及 Windows 10/11，用家可以貼上自己嘅 API key 去用 OpenAI、Anthropic、Google Gemini、DeepSeek、Kimi、Qwen、Mistral 等模型，亦可以經 Ollama 完全本地跑開源模型。所有嘢都喺本機行，只有用家授權嘅 model call 或者連接工具先會接觸到網絡。對於注重私隱或者公司政策唔畀數據出 cloud 嘅人，呢個係一個幾實際嘅選擇。

OPENWORKER: The Free AI Desktop Agent That Isn't Locked to One Model

佢亦內建 25+ 個整合，包括 GitHub、Slack、Jira、Notion、Linear、HubSpot、Outlook、Gmail、Google Calendar 等，亦支援任何可以經 MCP（Model Context Protocol）接駁到嘅工具。最令筆者欣賞嘅係佢嘅審批機制：寫訊息、發送郵件、執行 shell 指令呢類「對外有影響」嘅動作，全部都要先經你確認先至會執行，唔會自己靜靜雞撳掣。

以下係幾個用家會比較關心嘅重點：

  • 定位係桌面 AI 同事，目標係交到「成品」而唔止係聊天回覆，例如 HTML brief、Markdown 報告、排好嘅 calendar 更新等。
  • 完全開源、MIT 授權，由 Andrew Ng 團隊開發，引擎建基於佢哋嘅 aisuite 開源庫。
  • 模型自選，支援多間主流 cloud provider，亦可以經 Ollama 完全本地執行開源模型。
  • 重視私隱，對話、token、API key 都儲喺本機 secret store，唔需要登入亦可以用。
  • MCP + 審批機制，所有對外動作（發訊息、執行指令）都會先問過你先做，減低「AI 自行撳掣」嘅風險。

如果你係一個人或者小型團隊，想搵一個可以幫你「跑手」而唔係淨係「傾偈」嘅 AI 工具，又唔想將公司敏感資料送去閉源服務，OpenWorker 算係一個值得試嘅選擇。佢而家仲喺 open beta，官方表示會自動更新、不斷執吓啲 bugs，畀用家提交 issue。適合想認真將 AI 融入日常工作流、對私隱同可控性有要求嘅人。

項目主頁 · GitHub

Categories: 開源, Qwen, Google, Gemini, DeepSeek, OpenAI, API, MCP, 工具, Mac, Ollama, Python, Anthropic, 蘋果, Kimi

ABot-World 把互動世界模型帶上桌面 GPU

Share to X
ABot World 0

影片生成做到流暢並不罕見，但能一邊接收操作、一邊把世界延伸落去，門檻就高得多。ABot-World定位屬於模型加示範工具，核心處理的是 action-conditioned world rollout：用戶輸入動作之後，系統持續生成可探索的世界，而唔係播完就停的被動片段。

呢個項目的取向相當鮮明：它唔係先追求超高畫質，而是把「可互動、可持續、可在單張桌面顯示卡跑起來」放到前面。官方公開的數字是單張 NVIDIA RTX 5090 可在 720P、16 FPS、1.2 秒延遲、19GB GPU 記憶體下運行，配合 LongForcing training 減少 scene lock-in，令 rollout 期間可以擴展新場景同動態，唔使靠 prompt switching 硬接續。

測試方式算直接：項目已提供本地 gradio demo，同時有線上版 ABot World Studio；想自己部署，它在 Ubuntu 22.04、CUDA 13.3、NVIDIA RTX 5090 環境驗證過，並要先下載 ABot-World-0-5B-LF checkpoint。換句話說，現階段較適合把它理解成高階桌面 GPU 上的研究型互動系統，而唔係一般消費級硬件都能順手跑的輕量工具。

幾個重點值得留意：
– ABot-World-0-5B-LF 已公開，屬於 causal student model
– 互動重點在連續探索，不是固定長度 video generation
– 本地推理與線上 playground 都已提供，驗證路徑清楚
– Bidirectional Teacher Model 仍未釋出，生態暫時未算完整

適合研究 world model、interactive video generation、Agentic 模擬環境，或者想為遊戲原型與具身智能測試場景找參考的團隊。現階段的吸引力在於它把「無限 rollout」和「單桌面 GPU 即時推理」放到同一個項目內。

項目主頁 · GitHub · 模型

Categories: 開源, 阿里巴巴, Google, NVIDIA, Agentic, Video, Linux, 模型訓練, 視頻模型, 世界模型, 蘋果

OpenCoF 用影片學會推理

Share to X
Repository image for xinyan-cxy/OpenCoF

文字 Chain-of-Thought (CoT) 之外，OpenCoF 把推理搬到影片時間軸上，主打 Chain-of-Frame (CoF) reasoning：模型不是靠外部工具拆步驟，而是在連續生成的畫面裡理解因果、規則同狀態變化。這屬於一個研究型框架，核心想處理的問題，是現有影片生成模型多數只見過一般影片資料，未必學到穩定的時序推理能力。

作者對既有做法的批評很明確：以往影片模型通常用通用影片語料訓練，缺少專門針對 CoF reasoning 的監督，因此即使畫面能動起來，都未必真係「識推」。OpenCoF 於是補上兩層東西：先有 OpenCoF-17K 這個包含 17,312 段影片、覆蓋 11 類任務的資料集，再用它把 Wan2.2-I2V-A14B 經 LoRA 微調成 Wan-CoF，之後再加上 Visual Reasoning Tokens (vt) 與 Textual Reasoning Tokens (tt) 兩種設計。

OpenCoF 先用資料監督驗證影片推理能否被教出來，再用 token 設計補強中間推理狀態，而不是一開始就堆很多複雜推理機制。公開資訊顯示，Wan-CoF 單靠資料監督，已經在 MME-CoF、Gen-ViRe、VIPER、RULER-Bench 四個外部 benchmark 全面勝過基線；Wan-CoF vt 與 Wan-CoF tt 則再向前一步，但兩者偏重不同，vt 較擅長低階視覺線索，tt 較著重高階語意先驗。

  • OpenCoF-17K 由四條資料整理流程建成，兼顧規則型任務、程序生成場景與真實影片多樣性
  • Wan-CoF 以 Wan2.2-I2V-A14B 為底，靠 LoRA 微調驗證資料本身已可提升推理表現
  • Wan-CoF vt / Wan-CoF tt 分別從視覺 latent 與文字條件序列加入 reasoning tokens，走兩條互補路線
  • 評測覆蓋 MME-CoF、Gen-ViRe、VIPER、RULER-Bench，結果指向同一件事：時序監督對影片推理有明顯幫助

OpenCoF 適合研究團隊、做視覺推理評測的人，或者關注 Video reasoning 與 Video generation 交界的開發者參考：儲存庫已公開論文與方法框架，但 code、dataset 同 model checkpoints 仍在內部審核，暫時未能直接下載測試；現時較合理的理解方式，是先把 OpenCoF 視為一個針對 CoF reasoning 的資料與訓練範式，等正式釋出後再判斷重現成本與落地價值。

項目主頁 · GitHub · Paper

Categories: 開源, 香港中文大學, 字節跳動, Video, 多模態模型, 視覺模型, 視頻模型, 蘋果, Dataset 數據集

LiveEdit：串流影片編輯走向即時化

Share to X
Image 1

LiveEdit 是一個 diffusion-based streaming video editing 系統，屬於影片編輯模型與方法項目。它的核心任務是根據來源影片加上文字指令，逐段完成 causal chunk-by-chunk editing，並盡量保留背景與沒有修改的區域。

這個項目不是追求離線影片慢慢算到最靚，而是針對接近即時的串流編輯。它建基於 Wan2.1 和 Self-Forcing codebase，並用 three-stage distillation，把雙向編輯 teacher 的能力轉移到串流 student，再配合 AR-oriented Mask Cache 減少重複運算，換來較低延遲。

部署與測試資訊算是完整，提供 inference scripts、training code、checkpoint instructions，也講明建議在 Linux 配合 NVIDIA GPUs 執行；單 GPU 可做 inference，多 GPU torchrun 主要用於訓練。輸入方式是準備一個 JSON，填入 source video 路徑和 instruction，然後配合已釋出的權重與 Wan2.1 base model 進行推理。

有一個相當關鍵的參考值：項目頁列出 12.66 FPS，並表示透過 4-step distilled diffusion generation 達成 real-time streaming inference。這個成績對互動式影片編輯很重要，不過公開資訊未見更完整的硬件條件、顯存需求或不同解析度下的比較，因此判斷效能時仍要保留一點。

  • 重點不是一般文字生片，而是保留原片內容的串流影片編輯
  • 主要技術包括 three-stage distillation、Causal DiT、AR-oriented Mask Cache
  • 已公開 inference 與 training 程式碼，也提供 Hugging Face checkpoint 指引
  • 已知較適合 Linux、NVIDIA GPU 環境，研究團隊或影像生成工程師較易受益
  • 相關模型與基礎包括 Wan2.1-T2V-1.3B、bidirectional editing teacher、streaming student

整體來看，LiveEdit 的價值在於把 streaming video editing 做得更接近可互動系統，而不只是展示級效果。它較適合研究即時影片編輯、互動內容製作、直播視覺處理或需要低延遲生成的團隊；一般用家若想直接在圖形介面一鍵開用，現有資料未提供管理後台整合、免手動設定流程，仍然比較像面向研究與開發者的項目。

項目主頁 · GitHub · 模型

Categories: 開源, 香港科技大學, NVIDIA, Video, Linux, 模型, 視覺模型, 視頻模型, 蘋果, 框架

oMLX：把 Mac 變成本地 LLM 控制台

Share to X
oMLX

oMLX 是一個針對 Apple Silicon 的本地 LLM 推理工具，也是帶有圖形介面與 CLI 的伺服器管理項目。它主要解決的不是「能不能跑模型」，而是怎樣在 Mac 上較穩定地管理多個模型、保留 KV cache，並減少重複計算帶來的等待時間。

這個項目的取向很明確：用選單列介面處理常見操作，再配合終端機與 Apple Shortcuts 控制同一個服務。安裝路線亦相當直接，macOS 用戶可透過 .dmg 安裝，另有 Homebrew 方式；日志位置、背景服務與 CLI shim 都已交代，對需要長時間開著本地模型的人較友善。

Finally, The CORRECT Way to Run Local AI on a Mac

它和一般本地 LLM server 的差異，在於分層 KV cache 設計。oMLX 把常用內容留在 RAM 的 hot tier，不夠位時再轉去 SSD 的 cold tier，並以 safetensors 格式保存；即使伺服器重啟，遇到相同前綴內容仍可重用快取，這對長對話、編程輔助和工具調用尤其有價值。

只需點擊一下，即可直接從管理面板設定 OpenClaw、OpenCode、Codex、Hermes Agent、Copilot 和 Pi。無需手動編輯配置。

  • 支援 hot tier（RAM）與 cold tier（SSD）分層快取
  • 可自動以 LRU 方式卸載較少使用的模型
  • 管理介面可手動 load／unload 模型
  • 提供選單列操作、CLI 與 Apple Shortcuts 整合
  • 適合需要長上下文與多模型切換的 Mac 工作流程

現有資訊提到 continuous batching、context limits 與基準測試頁面，但 README 片段未列出具體數字，所以性能判斷宜保持審慎。可確定的是，它較適合在本地做持續開發、配合 Claude Code 一類工具，並集中管理「常駐小模型＋按需切換大模型」的團隊或個人環境；相關模型方面，內容明確提到 everyday models、heavier models，以及可選的 GLM-5.2、MiniMax M3 原生 custom kernels 支援。

GitHub

Categories: 開源, Agentic, Mac, 模型, 蘋果, 框架

WorldDirector 14B：可控影片世界模型點樣做長時記憶

Share to X
Repository image for pPetrichor/WorldDirector

WorldDirector 是一個影片世界模型框架，屬於研究原型兼開源推理項目。它的核心任務，是讓系統在生成長片段影片時，仍能記住動態物件的身份、位置變化與鏡頭運動，減少角色或物件一離開畫面就「變樣」或失去連續性的情況。

它的做法不是直接把所有事情交畀單一生成模型處理，而是先用 Large Language Model（LLM）規劃 3D 物件軌跡與相機路線，再把規劃投影成 2D 控制訊號交畀視覺生成模組。呢種拆分令項目的取向很清晰：先保住語意層面的動作因果，再處理畫面生成，因此比起只靠像素連續性的世界模型，更重視可控性、物件恆常性同長時段一致性。

目前已公開的是完整 inference code 同 WorldDirector-14B 權重，同時亦交代依賴 Torch 2.4.0、FlashAttention，以及 Hugging Face 下載模型的流程。換句話說，現階段較適合已有 GPU 環境、懂得整理 JSON 規劃輸入的人測試；它不是裝完即用的消費級工具，而較接近可重現論文結果的研究型項目。

項目展示的例子集中在人物、車輛、鏡頭切換與長時間事件編排，重點是物件暫時離開視野後再返回，外觀仍能維持穩定。公開資訊提到它支援 persistent dynamic object memory 同 unrestricted viewpoint exploration，但未見提供完整量化基準細節，因此現階段較適合把它理解為一個方向鮮明、控制力強的世界模型方案，而不是已全面驗證的通用產品。

  • 類型定位：影片世界模型框架，主打可控生成與長時記憶
  • 主要差異：把運動規劃同視覺生成拆開，先處理 3D 語意軌跡
  • 較適合情境：研究團隊、影片生成工作流、需要鏡頭與角色一致性的實驗
  • 部署理解：需先配置依賴、下載 WorldDirector-14B，並準備符合格式的 JSON 計劃輸入
  • 相關模型：WorldDirector-14B；流程中亦依賴 Large Language Model（LLM）參與動作與鏡頭規劃

整體來看，WorldDirector 最有價值的地方，在於它把「世界模擬」由單純畫面續寫，推進到可描述、可規劃、可回放的控制流程。對想研究影片 world model、角色一致性與可操控鏡頭生成的人來說，呢個項目值得留意；對只想快速出片的人，現有門檻仍然偏高。

項目主頁 · GitHub · 模型

Categories: 開源, 香港中文大學, 香港科技大學, Google, NVIDIA, 3D, 世界模型, 蘋果

ConvFill：即時語音代理的雙模型方案

Share to X
Teaser

ConvFill 是一個用來建立語音代理的開源系統與研究原型。能夠實現即時回應和準確回答——這兩個目標通常難以兼顧。它將本地運行的小型快速語言模型與在後台進行繁重推理的大型雲端模型相結合，使代理能夠立即開始對話，並在資訊可用時自動填充合理的答案。此程式碼庫包含完整的系統、一個即時語音演示、七個即用型模型以及訓練您自己的模型所需的一切資源。

現有做法通常要麼直接等大型模型完整生成，回應較慢；要麼改用較小模型追求低延遲，但複雜查詢、文件搜尋同工具調用能力會明顯下降。ConvFill 提出 conversational infill 這個新任務，將 Talker 與 Reasoner 分工：Talker 先即時說話，Reasoner 在背景處理慢工序，再把精簡知識流式交回 Talker 融入回答。

ConvFill 不是單純做語音介面，而是重新安排推理時序。Talker 可用 135M 到 1.7B 參數的小模型，在手提電腦或手機本地運行；Reasoner 則可接 Claude、GPT 或 Gemini。儲存庫已提供 live voice demo、七個現成模型，以及訓練自家 Talker 所需內容，理解上可視為「本地即時對話層 + 雲端能力層」的組合。

  • 內置七個已微調 Talker，涵蓋 Qwen、Llama、Gemma、SmolLM 家族
  • 配套 ConvFill dataset，含 290,571 個經驗證訓練樣本，覆蓋六個領域
  • Reasoner 可替換為 Claude、OpenAI 或 Gemini，毋須為更換 Reasoner 重新訓練
  • 論文指出系統可維持 millisecond-level time-to-first-response，準確度與對應 frontier Reasoner 的差距縮至 6.3% 內

受益最明顯的，會是想做客服、助理、查詢式語音介面或需要邊說邊找資料的團隊。它未必適合完全離線、又要求深度推理的場景，因為關鍵能力仍依賴雲端 Reasoner；但對希望保留本地回應速度，同時接入大模型能力的項目，這套設計比單模型方案更有工程上的彈性。

GitHub · Paper

Categories: 開源, Qwen, Gemini, OpenAI, LLaMa, 模型, 語音, Anthropic, 蘋果, Dataset 數據集

Apple container：Mac 原生容器新選擇

Share to X
Containerization logo

container 是一個工具，用來在 Mac 上建立及執行 Linux containers，做法更接近把容器當成輕量虛擬機處理；它要解決的，是 Mac 開發者在本機跑 Linux 工作負載時，如何兼顧隔離、速度與 OCI 相容性。

這個項目最明顯的取向，是 Apple 自己用 Swift 編寫，並且針對 Apple silicon 優化，同時依賴 Containerization 這個 Swift package 處理較底層的 container、image 與 process 管理。跟不少人熟悉的 Docker Desktop 或其他 Mac 容器方案相比，它不是強調整合一大堆開發配套，而是集中做好原生執行、標準映像相容，以及 Apple 平台能力。

安裝不算複雜：官方提供已簽署的安裝包，裝好後要啟動 system service，並且整個項目只支援 Apple silicon 與 macOS 26。這代表門檻很清楚：如果你仍在舊版 macOS，或者團隊有 Intel Mac，這個項目暫時就不會是通用解法。

Apple Just Built WSL for the Mac (Container Machines)

它支援讀寫 OCI-compatible container images，所以可以從標準 container registry 拉取映像、建立映像，再推回其他 OCI-compatible application 可用的環境。對開發團隊來說，這點很重要，因為它不是把流程鎖死在 Apple 自家格式，而是保留與現有容器生態互通。

  • 針對 Apple silicon 與 macOS 26，平台限制明確
  • 支援 OCI-compatible container images，可接標準 registry
  • 底層建基於 Containerization，偏向原生與輕量路線
  • 較適合 Mac 開發、測試、映像建置，不是全功能平台替代品

效能方面，暫時沒有提供完整官方基準數字，但外部已有文章把它放到 Docker Desktop、OrbStack 一類方案旁邊看 CPU、記憶體、啟動時間與 I/O。即使未能單靠儲存庫內容下定論，仍可合理判斷：Apple 想做的不是「功能最多」，而是在自家硬件上提供更貼近系統能力的容器執行方式。較受惠的會是以 Mac 為主要開發機、需要 OCI 相容流程、又願意接受新平台限制的工程團隊。

這個項目不是 AI 模型；若要說相關技術組件，主要是 OCI-compatible container images 與 Containerization。

GitHub： https://github.com/apple/container

項目： https://developer.apple.com/videos/play/wwdc2026/389/

Categories: 開源, 工具, Linux, Mac, 庫, 蘋果
Page 1 of 2
1 2