SemComp-Bench:影片生成評測由「似樣」走向真正完成任務

SemComp-Bench 不只看生成影片是否逼真,還檢查指定結果有否完成,以及關鍵語義是否仍然保留。

Repository image for Kelly372/SemComp-Bench

一段影片畫面流暢、物件外觀相近,不代表它真的完成了指令。SemComp-Bench(Benchmarking Semantic Task Completion in Video Generation)把評測焦點放在「結果有否做到」和「是否仍然保留與任務相關的語義」;GitHub 項目則是一套用來建立 SemComp-Data 的資料處理管線,處理影片篩選、狀態定位、指令整理和結果標註。

由原始影片到可評測資料,流程分成 9 個階段:先按標題過濾及分類任務,再定位 reference frame 與 outcome state,檢查畫面質素和狀態順序,產生中英雙語的簡短及詳細指令,最後抽取 outcome-centric clips、標註 semantic alignment types,並描述結果狀態。這種做法把評測所需的參考畫面、指令和完成結果放在同一段真實影片脈絡中,較適合檢查模型是否真的做到指定改變,而不只是產生看似合理的畫面。

項目屬於影片生成評測的資料集建構工具,實際解決的是把零散影片整理成可驗證、可重複評分的任務樣本。SemComp-Bench 目前提供 1,273 個結構化樣本、6 個真實世界領域、60 個 SemComp-Core cases,平均 outcome-centric clip 約 4.03 秒,並配有兩種指令、四類 reference alignment types,以及 27 個評測取樣畫面。

使用者需要 Python 3.10 或更新版本、ffmpeg、ffprobe,以及供第 2 至第 5 和第 7 至第 9 階段使用的 multimodal model service;第 6 階段的 ImageBind inference 建議使用支援 CUDA 的環境。原始影片、模型權重、服務憑證和執行輸出均不隨儲存庫提供,因此較適合研究團隊按自己的影片及模型服務重建資料,而不是下載後即時取得完整數據集。

  • 以 outcome achievement 配合 semantic grounding,避免只用畫質或 prompt alignment 判斷成功
  • 透過 reference frame、outcome state 和短片建立完整評測三元組
  • 1 至 7 階段通常會輸出 snapshot、excluded set,技術失敗另有 error.parquet
  • 可用 tests/ 的離線回歸測試檢查處理流程
  • splitting/ 含改編自 Panda-70M 和 ImageBind 的元件,非商業授權限制需要先審閱

對研究生成影片、製作評測數據,或需要分析任務完成率的團隊而言,這套管線提供了清楚的重建入口;但它依賴外部多模態模型服務和本地媒體資源,資料建立成本與授權審查仍是採用前必須計算的部分。

項目主頁 · GitHub · 數據集

Categories: 開源, 視覺模型, 多模態模型, NVIDIA, Video, Python, Dataset 數據集

V-RAE 重整影片潛空間,生成更快更準

V-RAE把影片生成前最難處理的時間冗餘壓細,同時保住語意結構。對想做重建、生成同預測建模的團隊,呢個方向幾有參考價值。

V-RAE method

做影片生成時,潛空間一旦又大又雜,訓練速度、重建品質同後續生成都會一齊受拖累。V-RAE放喺呢個位置切入:它屬於影片表示自編碼器模型,將 frozen vision foundation model 的表徵再壓成更緊湊的 generative latents,處理的是影片表示太冗長、但又不能失去語意同動態連續性的問題。

V-RAE不是重新訓練整個視覺骨幹,而是接在 DINOv3、SigLIP2、V-JEPA2.1、EUPE 這類 frozen encoder 之上,用 lightweight temporal pooling module 減少時間維度上的重複資訊,再交由 video decoder 重建連續動作。這種做法的取捨在於,它更依賴現成視覺表徵的品質,但換來較輕量的影片 latent 壓縮流程,亦令 semantic latents 可以變成 directly decodable predictive state space。

V-RAE:重构视频潜在空间以实现高效生成 2026-08-16

項目提供了訓練、評估與重建示例所需的程式結構,安裝條件寫明要用 Linux、NVIDIA GPUs、CUDA 相容驅動、FFmpeg,以及 Python 3.10 或以上。可配合已釋出的 checkpoints 與對應 frozen encoder 做重建測試,但能否自由下載、下載範圍是否完整,仍要以當前發佈頁面為準,不適宜直接假設任何人都可無限制取得全部模型。

結果 V-RAE在 K600 reconstruction 取得 2.13 rFVD,數值優於文中比較的大型 pretrained video VAEs;class-conditional generation 則在 UCF101 與 K600 分別達到 117.86 與 19.16 gFVD,並提到可快最多 6 倍收斂。作者亦提出 tFVD,令它與人類判斷的一致性提升,在 UCF101 與 K600 的 Pearson correlation 分別達到 r = 0.621 與 r = 0.919,這點對影片生成評測有直接意義。

  • 接在 frozen vision foundation model 後面做壓縮,避免由零建立整套影片表徵
  • 用 temporal pooling 減少時間冗餘,同時保住 semantic structure
  • 同時覆蓋 reconstruction、class-conditional generation 與 predictive modeling 場景
  • 倉庫已包含 training、evaluation、sampling 所需結構,但部署前提偏向研究級 Linux + NVIDIA GPU 環境
  • 適合研究影片生成、世界狀態建模、長序列表示學習的團隊參考其 latent 設計

V-RAE較適合有影片模型實驗能力的研究團隊、做 VideoDiT 類生成流程的人,以及想把影片 latent 拿去做預測狀態空間建模的項目。對於怎樣把強大的視覺表徵轉成更可生成、可重建、可評測的影片 latent,已經給出一條相當具體的路線。

項目主頁 · GitHub · 模型

Categories: 開源, 模型, 視頻模型, 模型訓練, NVIDIA, Video, Linux, Python

needle:14MB 本地工具模型,專攻結構化操作

Needle 2 把工具呼叫、裝置操作和結構化抽取收進單一 14MB 引擎,本地跑完整對話只需約 28MB RAM。它適合要低記憶體、離線部署又要輸出 JSON 的工作流。

Needle

Needle 2 屬於用於 tool calling 的小型模型,同時處理 device use 和 structured extraction。它把輸入文字轉成可直接接入工作流的結構化結果,適合在本地裝置、隔離網絡環境或資源很緊的情況下部署。

這個 Python package 提供 inference、LoRA fine-tuning 和 export,安裝後會先從 Hugging Face 下載一次 engine,再在本機快取,之後不再依賴網絡。開發者只要描述工具,模型就會按 schema 產生 JSON,並用 byte-level grammar 收窄輸出範圍,減少格式跑偏。

This 14MB AI Model Runs Locally — Needle 2 Explained

它和同類小模型的取捨很明確:45M 參數、單一 14MB binary,換來的是極低記憶體佔用和離線運行能力;官方測試也顯示,它會和 FunctionGemma 270M、LFM2.5 230M 及 Apple FM 互有勝負,但體積小得多。另一個做法是加入 confidence score,低於門檻就可以交回人工或上層流程處理。

  • 單一引擎打包,部署時不用分開管理權重檔
  • 以 JSON 與 schema 約束輸出,方便串接工具鏈
  • 支援大量工具目錄,但每輪只取 top five
  • 256-token sliding window 令記憶體維持在約 28MB
  • 適合離線裝置、邊緣設備和需要穩定結構輸出的團隊

GitHub · 模型

Categories: 開源, 模型, 模型訓練, Python, 庫, 蘋果

EditBridge 更穩定的4K 影像編輯

EditBridge 把低解析度編輯和高解析度修復接起來,避免放大時細節走樣。它適合要保留原圖紋理、文字和結構的影像編輯流程。

Overview of the EditBridge paradigm

EditBridge 是一個影像編輯框架,目標很直接:在 1K 到 4K 的高解析度輸出下,仍然保住原圖細節,而不是放大後再補出一堆不一致的紋理。它把粗編輯結果先交給 diffusion bridge 再修復,讓高解析度原圖繼續參與推理,不用把整張圖重生成一次。

和常見做法相比,它的取捨在於把「補細節」改成「沿著已對齊的內容做橋接」。核心做法是 PG-BSA(prior-guided block-wise sparse attention),用先前編輯階段的對應關係去挑選需要看的區塊,減少密集全局注意力帶來的成本,同時降低高頻細節失真。

倉庫已經交代了基本使用路線:先建立 Python 環境,再安裝項目,下載 Qwen-Image-Edit-2509 checkpoint,之後用 CSV 準備 source_image、target_image、condition_image 和 prompt。訓練時還要先抽取 target-to-source correspondences,1K、2K 與 4K 的流程分開處理,4K 版本則透過降低記憶體消耗來跑。

這套方法較適合做高解析度修圖、產品圖改寫、海報文字修正,或者任何不能接受放大後失真、塗抹感太重的工作流。它的評估重點也很清晰:在 1K 到 4K 的 reconstruction 和 perceptual metrics 都維持領先,推理時間比直接高解析度生成和傳統 diffusion 超解析度方案更實用。

  • 保留原始高解析度 source 作為條件,減少細節漂移
  • 用 coarse edit 接 diffusion bridge,再做高解析度修復
  • PG-BSA 透過區塊級稀疏注意力控制計算量
  • 1K、2K、4K 都有對應訓練流程
  • 適合重視文字、邊緣、紋理一致性的編輯任務

項目主頁 · GitHub

Categories: 開源, 阿里巴巴, Qwen, Image, Python

Agent Lightning v1.0:把代理訓練接回真實工具流

Agent Lightning v1.0 讓代理在保留工具、上下文和環境的情況下直接訓練。它也把 Kubernetes、程式編寫和獎勵防作弊流程一併整合起來。

logo

Agent Lightning v1.0 針對一個常見卡位:代理訓練往往要靠額外沙箱或改寫流程,令工具、控制流和環境脫節。這個項目把訓練直接接回真實 agent harness,代理可以經由 Agent Lightning v1.0 proxy 運作,而不用改動原本架構。

它的設計取向相當清晰,核心程式碼大約 3,500 行,重寫後把複雜度壓低。代理亦可直接作為 Kubernetes Jobs 執行,不必依賴外部 sandbox 服務,對要跑長時間 rollout 或分散式訓練的團隊會方便很多。

文檔同時提供完整的 coding-agent 訓練流程,涵蓋資料清理、reward-hacking 防護和訓練腳本。這代表它不只停留在概念層面,而是把一條可落地的訓練管線交到使用者手上。

  • 保留工具、上下文、控制流和環境在訓練迴圈內
  • 透過 proxy 接入現有 agents,減少改動成本
  • 原生支援 Kubernetes Jobs,部署更直接
  • 提供 coding agent 範例,連資料清理和防作弊流程都包進去
  • 適合做具互動工具、程式執行或多步推理的 agent 訓練

項目主頁

Categories: 開源, Agentic, 模型訓練, 微軟, DeepSeek, API, Vibe Coding, Python, 編程

HRM-Text 把基礎模型預訓練門檻壓到千美元級

想自己預訓練文字模型,通常先被算力同數據成本勸退。HRM-Text嘗試把呢道門檻大幅壓低,連完整訓練流程都一併開放。

banner

最值得留意的地方,不是又多一個 1B 級文字模型,而是有人把「由零開始預訓練 foundation model」整理成一個可落地的開源項目。HRM-Text 屬於模型加訓練框架類型,處理的是中小團隊想自建文字生成模型時,算力、數據量同工程門檻都過高的問題。

它採用 Hierarchical Recurrent Model(HRM)架構,並加入 task completion 同 latent space reasoning,重點不是單純追更大參數,而是用 hierarchical recurrent architecture、PrefixLM sequence packing、FlashAttention 3 同 PyTorch FSDP2,把預訓練成本壓到傳統做法的 130 至 600 倍更低算力需求,以及 150 至 900 倍更低數據需求。呢個取捨很鮮明:換來的不是萬能部署環境,而是一條偏向研究與訓練端、對 Hopper-class GPU 仍有明確要求的路線。

部署同測試方式亦算完整。儲存庫已包含 training、checkpointing、evaluation,同 checkpoint 轉成 Hugging Face Transformers 格式的工具,配合 companion 的 data_io 管線準備 tokenized data 後,就可以按單節點或多節點方式開跑;不過 native Transformers 支援要等下一個 release,native vLLM 支援亦仍在進行中,所以現時較適合想重現訓練流程、驗證成本結構,或者研究 HRM 架構本身的團隊。

參考跑分不算保守:0.6B 版本用 8 張 H100、約 50 小時,GSM8k 有 77.6%,MATH 51.2%;1B 版本用 16 張 H100、約 46 小時,GSM8k 提升到 84.7%,MMLU 60.7%,ARC-C 81.9%。呢啲數字未必代表它已經適合所有產品化場景,但足以證明這條路不是紙上談兵,尤其對大學實驗室、國家語言模型計劃,或者想為小語種、自有語料建立 base model 的團隊,有相當現實的吸引力。

  • 把 foundation model 預訓練成本壓到約千美元級,重點在完整流程而不只是一個模型權重
  • 同時提供訓練、評估、checkpoint 轉換工具,方便重現與延伸研究
  • 目前較依賴 H100 等 Hopper-class GPU,部署彈性未算完全成熟
  • 適合研究機構、語言科技團隊,同要自建基礎模型能力的項目
  • 原生 Transformers 與 vLLM 支援仍在補齊,短期內較偏訓練端使用

項目主頁 · GitHub · 模型

Categories: 開源, 模型, 多模態模型, 模型訓練, Python, Dataset 數據集

SimpleOPD 把長思維蒸餾帶到異 tokenizer 學生模型

長上下文教師模型唔難找,難的是點樣穩定轉移到短上下文學生模型。SimpleOPD聚焦呢個落差,做法比一般蒸餾更貼近訓練現場。

Repository image for hhnqqq/SimpleOPD

想把長上下文推理能力交到較細、較短上下文的學生模型,卡位往往唔係只有模型強弱,而是 tokenizer 不同、輸出愈蒸餾愈長,最後連訓練都變得唔穩。SimpleOPD屬於模型訓練方法項目,處理的是 long-context reasoning teacher 到 short-context student 之間的 On-policy distillation(OPD)轉移,重點放在跨 tokenizer 仍然可以學到推理能力。

它冇硬做 token-level 對齊,而是改在 shared text space 對齊,只監督師生 tokenizer 剛好切出相同文字跨度的位置。呢個取捨很務實:少了強行對齊帶來的噪音,代價是可監督位置會收窄,但換來 arbitrary teacher-student tokenizer combinations 也能成立,對 Qwen3、Qwen3.5、Intern-S2、GLM-4.7、Gemma4 這類不同家族學生模型都更有通用性。

另一個關鍵,是它直接處理「答案愈生愈長」這個訓練現象。SimpleOPD加入 student-reference KL loss,再對 </think> 和 <|im_end|> 這類終止 token 做 advantage masking,目的不是單純加正則化,而是壓住學生模型偏離初始 policy 太遠,減少 teacher-student distribution mismatch、截斷率上升與訓練失穩。

  • 支援 long-context teacher 產生 100K+ token reasoning chains
  • 以 shared text space 對齊,避開 tokenizer 不一致帶來的蒸餾障礙
  • 透過 student-reference KL loss 與終止 token masking 控制長度膨脹
  • 在 ProofBench 對 Intern-S2-Preview 帶來 +21.2 分,升至 55.2
  • 結果已超過 Gemini-2.5-Pro,並提到對 HLE、HiPhO 也有外溢收益

它不是即裝即用的線上服務,而是偏研究與訓練流程的開源項目;環境依賴 SLIME 0.2.3、Python 3.10+、PyTorch 2.0+,並為 GPU、HTTP-based teacher inference、timeout、concurrency、batch processing 留好接口。受益最大的會是做蒸餾訓練、想把強教師推理能力壓到較易部署學生模型的團隊,尤其是要跨 tokenizer、又不想被超長 reasoning chain 拖垮訓練穩定性的情境。

項目主頁 · GitHub

Categories: 開源, Qwen, OpenAI, Gemini, Python

spark-to-paper-skills:14 個 Claude Code 技能把點子直出論文 PDF

由一句想法走到可編譯論文,連引用、圖表同數字來源都一併追蹤。呢個 Claude Code 插件瞄準的,不是寫草稿,而是把研究寫作流程拆成可驗證工序。

spark-to-paper-skills

研究寫作最麻煩的地方,往往不是起草,而是引用會唔會失真、圖表能否修改、數字有冇來源可追。spark-to-paper-skills 把呢件事做成 Claude Code 插件型工具鏈,用 14 個可組合技能,將一句想法推進到可編譯 PDF,處理的是論文生成流程入面最容易出錯的核對與整理工作。

它吸引人的地方,在於唔靠獨立 app 或伺服器,而是直接掛入 Claude Code 會話。安裝前提相對簡單,重點是有 Claude Code,另外部分圖像流程需要 Python 3.10+ 同指定依賴;換句話說,這不是雲端代寫服務,而是偏向本機、插件式、可拆件調用的研究寫作工作流。

  • 14 個技能可分步串接,涵蓋資料整理、成稿到 PDF 編譯
  • 引用強調 verified,數字強調 traced to source,主打可追溯性
  • v1.2.0 加入 PaperBanana+ figure engine,圖可重畫成原生 editable vector figures
  • 新版支援 Claude Code plugin 自動載入,部署方式比早期版本完整

同類做法多數把重點放在生成速度,這個項目則把可信度同後續可編輯性放得更前。PaperBanana+ 的做法幾值得留意:先由官方 PaperBanana 產生候選圖,再用 ts-figure-svg 學習該渲染風格,根據論文事實原生重繪,並以 stdlib-only geometry audit 反覆修正至少 4 輪,換來的是圖像更容易進一步編修,但流程也明顯比單次出圖更講究。

目前公開資訊較多集中在工作流完整度。它已展示 7 篇跨 6 個領域的端到端樣本,並支援 ICML 2025、NeurIPS 2025 風格輸出,足以說明這套技能並非只停留在片段 demo。較適合研究助理、學術團隊、技術內容作者,或者需要快速整理初稿但又唔想放棄引用與圖表可追蹤性的人;最終學術品質,仍然要視乎輸入構想、來源材料同人工審稿力度。

GitHub

Categories: 開源, Python, Anthropic, Skill 技能

360CityArena 把城市導航基準拉近真街景

想測試 Embodied Agents 喺城市場景到底識唔識搵路,360CityArena 提供咗一個更貼近真實街區的基準,但結果亦直接揭示現時模型離人類判斷仲有一大段距離。

360CityArena teaser showing a panoramic Akihabara scene and an embodied navigation agent

喺模擬城市入面叫 Embodied Agents 認路、數物件、跟地圖行,難度一向唔低;換成秋葉原的 360 度真實街景之後,問題就由「會唔會做任務」變成「可唔可以喺複雜環境保持判斷」。360CityArena 屬於 benchmark,核心用途係評估 multimodal large language models 喺 embodied navigation 同 visual reasoning 上,到底有幾接近真實城市探索需求。

呢個項目最有意思的地方,在於它唔係靠乾淨的 3D 合成地圖,而係用 602 段 360° 影片重建東京秋葉原 85 條街道,再放入 Unity 環境,用 pose graph 方式讓 agent 沿既定節點移動。換句話說,代理唔可以自由行去任何 3D 座標,也唔涉及實體互動;它測的是在受限移動下,模型能否理解街景、地圖、語言提示同空間關係。

公開版本有 175 個人工設計任務,涵蓋 localization、landmark search、counting、map navigation、language guided navigation 同 relational spatial reasoning。部署方式亦算清楚:Unity 6.5 負責環境,Python runner 接模型 API、送出相機與地圖觀察,再把每次執行結果寫入 outputs/<run_id>/,因此它比較適合研究團隊或評測項目直接重跑同對照。

  • 用 360° 真實街景而唔係純合成場景,城市細節更接近真實導航
  • 任務覆蓋找地標、看圖尋路、數物件、按文字指示前進等七類能力
  • Unity 環境配合 Python runner,方便接駁不同 MLLM API 做可重現測試
  • agent 只可沿 pose graph 移動,限制更明確,同時保留城市探索的推理壓力

最值得留意的是結果並唔樂觀。官方比較指出,Gemini 2.5 Flash 目前在整體任務只有 17.1%,人類則有 77.3%,差距大到足以說明:現時多模態模型即使已經能看圖和讀指令,一旦放入連續街景、地圖對位與空間推理混合的場景,穩定性仍然不足。對做 Agentic、Robotic、世界模型相關研究的團隊來講,360CityArena 的價值正在於它唔再只測單步理解,而係把城市級導航的瓶頸攤開畀人直接比較。

項目主頁 · GitHub

Categories: 開源, Agentic, 多模態模型, Gemini, API, Robotic, 3D, Python, Dataset 數據集

NeMo Speech:NVIDIA 把 ASR、TTS、語音 LLM 收進同一條 PyTorch 生產線

NVIDIA 把語音研究最常碰到的 ASR、TTS 與 Speech LLM 整合成單一框架,研究員和工程師不用再東拼西湊,也能用預訓練權重快速微調與部署。

Repository image for NVIDIA-NeMo/Speech

語音 AI 的痛點往往不是模型不夠強,而是開發者要同時面對 ASR、TTS、串流識別等好幾套獨立工具鏈。NVIDIA NeMo Speech 把這些任務收進同一個 PyTorch 框架,並提供預訓練權重,讓研究員可以把精力花在實驗設計,而不是從頭搭建訓練流程。

從近期更新可以看到三個值得留意的方向:MagpieTTS v2607 把支援語言擴展到 12 種,新增阿拉伯文、韓文、葡萄牙文;Nemotron-3.5-ASR-Streaming-0.6B 在單一 H100 上能同時處理最多 2400 條串流,並允許把延遲控制在 80ms 到 1s 之間;Parakeet-unified-en-0.6b 則把離線與串流推理合併成一個英文模型,最短延遲 160ms。

Nemotron 3 VoiceChat 把 LLM、骨幹與 TTS 解碼器串成全雙工對話,能自然處理打斷與插話,這對於想建立語音助理的團隊是比較完整的一條路。Fastconformer 等快取感知架構是背後的工程功臣,讓長音訊串流不需要犧牲太多吞吐量。

訓練階段必須配備 NVIDIA GPU 與 CUDA 環境,推薦使用 PyTorch 2.7 或以上版本;現時倉庫正進行拆分,下一個主要版本預定 2026 年 6 月發佈,短期內穩定使用可以考慮 26.02 NGC container。對做客服、會議記錄、媒體字幕或有聲書生成的團隊,這套框架能把語音模型從原型走到部署的距離明顯縮短。

重點摘要:

  • 單一框架覆蓋三大任務:ASR、TTS 與 Speech LLM 都在 NeMo Speech 內,減少切換工具鏈的成本。
  • 串流效能突出:Nemotron-3.5-ASR-Streaming-0.6B 支援 40 種語言,單張 H100 可並行 2400 條流,延遲可調。
  • 多語 TTS 擴張:MagpieTTS v2607 覆蓋 12 種語言,並提供 Hugging Face 線上 demo。
  • 全雙工語音助理:Nemotron 3 VoiceChat 把 LLM 與 TTS 解碼器結合,支援自然打斷與低延遲對話。
  • 硬體要求明確:至少配備 80 GB 記憶體。訓練需 NVIDIA GPU 與 CUDA,PyTorch 2.7 或以上版本,推理可在 CPU 或 GPU 執行。

GitHub · 模型

Categories: 開源, 文字轉語音, Agentic, NVIDIA, 框架, Python, 語音, Dataset 數據集

Page 12 of 21
1 … 10 11 12 13 14 … 21