InferNews

GRNEdit 用少量參數做通用影片編輯

Share to X

想改影片風格、背景或局部內容，又唔想整段重生成，GRNEdit 提出一條較慳參數的路線。它把可編輯範圍先用 binary evidence 拆清，再逐步細修畫面。

Xidian University

一段影片要改風格、換背景、刪走局部人物，最難通常唔係生成新畫面，而係改得準之餘，原本動作、主體身份同未編輯部分都要保持穩定。GRNEdit 屬於影片編輯框架，處理的正是這類通用影片編輯問題，而且走的是 Generative Refinement Networks 配合 binary evidence 的路線，不是靠大幅加參數去硬推效果。

GRNEdit 先用 binary evidence 分開哪些區域應該被改、哪些內容要盡量維持，之後再沿住 refinement 過程逐步生成目標語意、結構同細節。這樣做的取捨，在於它把編輯能力壓縮到相當輕量的增量上；公開資訊表示，相對 GRN backbone 只增加少於 3% 額外參數，但聲稱可跟領先的影片編輯模型競爭。

從示例看，GRNEdit覆蓋 global style、背景替換、local removal、加入新元素，以及移除字幕等多種任務，重點不是單一特效，而是同一套框架處理不同編輯指令。較適合研究影片生成、內容製作流程，或者想把多種編輯模式收斂到同一模型系統的團隊參考；不過目前公開內容仍以推理程式碼和預印本為主，training code 與 model weights 都未提供，部署與重現門檻仍然存在。

  • 以 binary evidence 先界定可編輯範圍，再逐步 refinement
  • 相對 GRN backbone，只需少於 3% 額外參數
  • 同一框架支援風格化、換背景、移除、添加與複合編輯
  • 公開資料主打推理與結果展示，完整訓練與權重尚未釋出

模型權重暫未開放，但有足夠資訊足夠理解它的方法定位。對關注影片編輯模型的人來說，GRNEdit最有意思的地方，是它把「改動範圍判定」放到生成前段處理，嘗試用更小的參數成本換取更穩定的時序保留與更通用的編輯能力。

項目主頁 · GitHub

Categories: 開源, 模型, 視覺模型, 視頻模型, 模型訓練

[技術文章] pixel-space 模型可以追平甚至超過 latent-space 對應模型

Share to X

研究聚焦 pixel-space text-to-image diffusion models 的訓練卡位，找出點樣喺大規模條件下兼顧畫質同速度。作者用 latent-to-pixel 策略，令 pixel-space 模型更接近甚至超過 latent-space 表現。

Hero image preview

上圖是透過 pixel-space text-to-image diffusion models 的方法訓練的 Z-Image-Turbo (Pixel) 產生的圖像。在企業級 H800 GPU 上，推理延遲僅約 0.2 秒。

Pixel-space text-to-image diffusion models 一直有兩個吸引位：直接生成像素，唔受 VAE 壓縮上限限制，亦可以省去解碼步驟。但喺大規模訓練下，佢哋收斂速度明顯慢過 latent-space 模型，令「畫質、效率、可訓練性」三者之間嘅平衡一直唔夠成熟。

呢篇工作針對嘅正係呢個落差。作者先比較 pixel-space 同 latent-space 喺大規模 pre-training 下嘅行為，再提出 latent-to-pixel 策略：先喺 latent space 學到生成先驗，再轉去 pixel space 做 post-training，避免一開始就喺難度更高嘅像素空間硬推。

佢哋亦系統研究咗多個轉換設計，包括 weight initialization、data composition、prediction target、decoder architecture 同 noise schedule，整理出一套可行做法。結果顯示，做法調整得當之後，pixel-space 模型可以追平甚至超過 latent-space 對應模型，推理端仲有 3.18 到 4.75 倍嘅速度提升。

  • 直接處理 pixel-space diffusion models 喺大規模訓練時收斂慢嘅問題
  • 用 latent-to-pixel 路線，先學先驗，再轉入像素空間微調
  • 檢視多個關鍵訓練選項，搵出實用 recipe
  • 在畫質不退讓之下，換取更快的 end-to-end inference
  • 對想做高效文生圖系統、又在意生成細節保留嘅團隊最有參考價值

Paper

Categories: 香港科技大學, 南京大學, 阿里巴巴, 模型, 模型訓練, Image, txt2img, 香港

Tencent UI-Mate 桌面操作示範變成可重用工作流

Share to X

開源權重的通用 GUI 智能體：環境驅動訓練 + 上下文演示學習——流程演示一次即可，不必把所有約定寫進提示。

UI Mate icon

很多桌面任務難寫成一段完整提示，問題不在指令太短，而是在檔名規則、視窗擺位、公司流程這些細節往往靠示範更容易講清。UI-Mate 就是朝這個位置切入的開源 GUI agent 項目：它在原生桌面看螢幕畫面，用鍵盤和滑鼠跨應用程式執行長流程工作，並且支援把一次人手操作示範轉成可重用工作流。

UI-Mate 把示範當成建議。當畫面內容、資料、視窗狀態或任務目標有變化，代理仍會按即時畫面重新判斷，避免變成只懂重播錄製腳本的 Computer-use agents（CUAs）。這個取捨很重要，因為它直接回應了 GUI 自動化最常見的失敗位：流程相似，但畫面從來不會完全一樣。

訓練方法亦反映它想處理真實環境，而不只是跑單一 benchmark。項目提到 closed-loop data engine，會串連任務合成、環境建構、rollout、驗證與 filtering，再用 capability tree 補回覆蓋不足的能力；同時支援 Ubuntu、Windows 和 macOS 的統一 rollout layer，並以 asynchronous group-relative optimization 處理長而且變化大的 rollout。整體方向很清晰：先把可執行環境和驗證機制搭好，再談代理怎樣學會跨系統做事。

公開結果亦有參考價值。UI-Mate 在 OSWorld-Verified 達到 77.0%，WindowsAgentArena 為 66.2%，而 OSWorkerBench 嚴格成功率 41.0%、progress 76.9%；加入一次 same-task demonstration 後，OSWorker self-demo strict success 由 17.2% 升到 35.4%。這些數字未必代表它已經能穩定接手所有桌面工作，但至少說明示範式引導不只是概念包裝，對長流程任務有明顯幫助。

  • 屬於開源 GUI agent 項目，重點是處理跨應用、跨作業系統的長流程桌面任務
  • 核心差異在於支援 in-context demonstrations，把一次示範整理成可重用工作流
  • 示範不是腳本重播，代理會按 live screenshot 即場重新規劃
  • 較適合需要固定流程但畫面與資料經常變動的團隊、營運與辦公自動化場景
  • 目前已公開模型與結果，但 OSWorkerBench 等配套仍有部分內容標示為 Coming Soon

部署與理解方式上，現有資料較接近研究原型加可試權重，而不是開箱即用的完整產品。官方已放出 code、weights、technical report 和 Try App，較合理的看法是先把它當成可驗證 demonstration-guided GUI agent 能力的開源基線，再看後續 benchmark、資料集與工具鏈是否補齊。對研究 GUI agent、企業桌面自動化，或者想比較文字指令與示範引導差異的團隊，這個項目很值得跟進。

項目主頁 · GitHub · 模型

Categories: 開源, 騰訊, Agentic, 模型, Mac, Linux, Dataset 數據集, UI/UX

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

Share to X

想自己預訓練文字模型，通常先被算力同數據成本勸退。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 數據集

LittleLearner 把語言模型的知識邊界控制在小學五年級

Share to X

LittleLearner 透過受控課程資料訓練模型，研究能力究竟來自學習，還是只是被提示引出。

Hero image preview

模型能否回答問題，不一定代表它真正學過相關知識。LittleLearner 將語言模型（Language Models，LMs）的預訓練資料限制在美國小學 K–5 課程，建立一個可觀察知識邊界的研究沙盒，讓研究者分辨能力是從資料中獲得，還是只是在提示下被引出。

項目的核心是 LittleCurriculum，一個由 FineWeb-Edu 蒸餾而成、約 880 億個 token 的語料庫。資料經過五階段篩選，並按照 Common Core standards 對齊，明確排除五年級以上教授的概念、事實和詞彙；模型則從零開始訓練，並配備使用相同架構、token 數量和訓練配方的 Unfiltered control，方便作出乾淨比較。

LittleLearner 提供 0.6B、1.3B 和 5B 三種規模，另有 Base、GRPO 及 Chatty 版本。研究測試 scaling、SFT+GRPO post-training 和 in-context learning 後發現，這些方法可以放大課程範圍內的能力，卻未能明顯提升範圍以外的表現，顯示預訓練資料可能設定了有效能力上限。

重點包括：
– 88B-token LittleCurriculum 將知識暴露範圍控制在 K–5 課程
– 三種模型規模均設有匹配的 Unfiltered control
– scaling 可改善課程範圍內表現，外推能力只有限度增加
– SFT+GRPO 和 in-context learning 未能突破知識邊界
– 網頁提供 5B 模型的瀏覽器聊天介面、Dataset 和 Model checkpoints

對研究模型能力來源、知識遷移和 post-training 效果的人，LittleLearner 提供了較容易重現和比較的實驗基礎；對一般使用者而言，瀏覽器內的 live chat 則可直接感受一個受控知識範圍模型的回答方式。

項目主頁 · 模型

Categories: 開源, 模型, 模型訓練, Dataset 數據集, Skill 技能

Qwen3.8 系列的 27B 開放權重模型

Share to X

Qwen3.8-27B以 27B 密集模型同時處理文字、圖片與影片，重點不只在識別內容，而是更穩定完成多步驟任務。它延續 Qwen3.5 架構，但頁面公開的本地量化與 GGUF 資訊仍未齊。

Og image

由 Qwen3.5 的架構基礎延伸而來，Qwen3.8-27B把長流程推理、Agentic 任務同原生視覺理解放入同一個 27B dense 模型。使用時最直接的差異，是它不只看圖答題，亦針對編程、專業工作、研究與多步驟任務完成度作強化，並保留可調整的 thinking control。

模型層面採用 Causal Language Model with Vision Encoder，屬於經過 pre-training 與 post-training 的 image-text-to-text 模型。27B 參數、64 層、hidden size 5120，以及混合 Gated DeltaNet 與 Gated Attention 的 hidden layout，反映它不是單純沿用傳統 dense Transformer 堆疊，而是針對長程依賴與效率作結構調整。

Qwen 3.8 27B BLOWS MY MIND! Best Local AI Model Yet! Basically Opus Locally! (Fully Tested)

對開發者而言，較有用的是推理行為控制：thinking mode 預設開啟，可按請求關閉；reasoning_effort 可調整推理深度；preserve_thinking 可保留歷史訊息中的 reasoning context。

  • 基礎模型可確認為 Qwen3.5 架構系統上的後訓練版本，而非獨立另起爐灶
  • 原生支援圖片與影片理解，定位比純文字模型更貼近 Agentic 與多模態工作流
  • 相容 Transformers、vLLM、SGLang、TokenSpeed，方便接入現有堆疊
  • 頁面未提供 GGUF 格式、量化檔名、mmproj、Ollama／llama.cpp／LM Studio 建議配置
  • 亦未見 MTP draft speculation、v2 檔名變更或 chat template 注意事項的具體說明

與同系前代相比，Qwen3.8主打的是可靠完成整段任務，而不只是單輪回答更聰明；與一般視覺語言模型相比，它更強調 environment feedback 下的自主規劃。目前公開的是 Transformers 格式權重與設定檔，未足以直接判斷本地量化部署門檻，所以硬件需求、推薦量化等級與不同量化之間的取捨，現階段只能等後續模型檔或社群移植版本補上。

模型

Categories: Agentic, 模型, 視覺模型, 多模態模型, 模型訓練, Qwen, API, 編程

MiniMax-Music3 開放權重音樂模型

Share to X

你可以把它理解成一個把歌詞、風格與編曲意圖直接變成完整歌曲的模型，重點不只係出聲，仲要保住前後段落的連貫感。它適合做 demo、原型同內容製作，代價是控制得愈細，提示詞就要寫得愈具體。

MiniMax

MiniMax Music 3 是一個音樂生成模型，重點在於把「可唱、可編、可聽完整首歌」串成一體，直接產出最長五分鐘的完整歌曲。對內容創作團隊來講，它最有價值嘅位唔係單句旋律，而係可以連住 intro、verse、chorus 到 outro，維持人聲、節奏同編曲走向一致。

輸入通常分兩層：歌詞負責唱咩，同時可以加上 [Intro]、[Verse]、[Chorus] 呢類段落標記；另一層音樂描述就交代風格、情緒推進、人聲質感、樂器配置同空間感。官方亦建議用 Structured Caption，將 Global Metadata、Vocal Details、Arrangement 分開寫，方便模型對長段落做更穩定嘅控制。

它用 8B Global LLM 處理長距離結構，再配 0.6B Local LLM 補足逐幀聲學細節，並結合 Flow Matching 同 Flow-VAE 做連續 hidden-state 合成。這種分工換來較完整的長歌一致性，但亦意味住提示詞要寫得有層次，否則編排同人聲變化未必會完全跟足預期。

  • 最適合做完整歌曲草稿、廣告歌、遊戲音樂同內容原型
  • 由歌詞加音樂描述共同控制，細節比一般單一句 prompt 更可預期
  • 支援 32 kHz、16-bit stereo WAV 輸出，方便接入後期流程
  • 強項係長段落連貫與結構完整，唔係只生成短片段
  • 目前較適合重視創作速度與可控性嘅團隊，而唔係追求即用即完美成品嘅場景

項目主頁 · GitHub · 模型

Categories: 開源, 模型, 音樂, MiniMax

NanoVDR：70M 文字編碼器取代 2B VLM：視覺文檔檢索的輕量化新嘗試

Share to X

NanoVDR 把 2B 參數嘅視覺語言模型蒸餾成 69–151M 嘅純文字編碼器，查詢時完全唔需要視覺模型，CPU 51 毫秒即可完成。

NanoVDR

處理幾十萬張文件圖片嘅時候，每次查詢都要過一次 2B 嘅視覺語言模型（VLM），開銷大到令人卻步。NanoVDR 想解決嘅就係呢個落差：文件索引由教師模型離線建好，查詢階段只用一個 DistilBERT 規模嘅純文字編碼器，CPU 上 51 毫秒出結果，2048 維嘅單一向量直接做點積，扔得入 FAISS。

佢嘅做法係將 Qwen3-VL-Embedding-2B 凍結做教師，提早把目標向量快取落嚟，學生只係學一個餘弦距離嘅 loss——即係 loss = 1 - cos(student, teacher)。訓練時冇相關性標註、冇負例採樣，兩邊完全解耦，所以查詢端同索引端可以分開換組合。DistilVDR 進一步把文件端都換走，做到成個流程都唔再需要教師。

對於做企業 RAG、法律文件搜尋、學術庫檢索嘅團隊，最大吸引力係每頁索引得 4 KB，比 ColPali 嗰類多向量檢索慳 64 倍儲存，而且唔使 GPU 即可頂住查詢負載。ViDoRe v1 上面，NanoVDR-S-Multi 拎到 82.2 NDCG@5，保留咗教師大約 95% 嘅能力，呢個取捨對批量部署嚟講好實際。

重點摘要：

  • 極輕量查詢端：文字編碼器僅 69–151M 參數，無需視覺模型參與查詢
  • 高效索引：每頁僅 4 KB（float16），比多向量方案節省約 64 倍儲存
  • 簡易整合：輸出為單一向量，FAISS 即可處理，無需 MaxSim 池化
  • 教師-學生解耦：目標向量預先快取，兩端可獨立訓練與組合
  • 完整資源：模型、訓練數據集、線上 Demo 同論文均已開源

多向量查詢塔嘅程式碼已就位，但 checkpoint 要等 NanoVDR-v2 先出齊，想要更高召回嘅人需要留意後續更新。

項目主頁 · GitHub

Categories: 開源, RAG, Embedding, 模型, 視覺模型, 多模態模型, Qwen

MiLMMT-v1.0：小米升級開源翻譯模型：支援至 46 種語言

Share to X

小米把旗下開源多語翻譯項目 GemmaX 升級至 MiLMMT-v1.0，支援語言一舉擴至 46 種，並透過強化學習與模型合併提升翻譯品質。

gemmax

過去想用開源 LLM 做多語翻譯，往往要遷就 20 多種語言的覆蓋，遇上東歐、非洲或東南亞較少見的語種就容易撞牆。MiLMMT-v1.0 把覆蓋範圍一口氣推至 46 種，這個改變對做跨國內容本地化、跨境電商文案，或是需要處理多語客戶查詢的團隊尤其受用。

這個項目屬於多語翻譯模型（multilingual machine translation model），並非框架或工具，核心目標是讓 Gemma3 等開放權重模型在多語翻譯場景下，貼近商用翻譯引擎的水準。它以 Gemma3-1B 與 Gemma3-4B 為基底，先做持續預訓練，再用翻譯指令微調，最後透過強化學習（GRPO）配合 xCOMET、OpenLID、CometKiwi 等無參考指標作為獎勵訊號。

與傳統依賴大型封閉模型、或需要平行語料的監督式微調不同，MiLMMT 強調 reference-free 後訓練：不需要人工對照譯文也能用 LLM-as-judge 改善翻譯結果。同時配合模型合併（model merging），在 1B 規模的小模型上嘗試兼顧多語泛化與低資源語種的穩定性，這點對硬體資源有限、想自建翻譯服務的工作場景相當關鍵。

重點摘要：

  • 支援語言從 28 種擴展至 46 種，覆蓋更多低資源語種
  • 基於 Gemma3-1B / Gemma3-4B 開放權重，可離線部署
  • 採用 GRPO 強化學習搭配 xCOMET、OpenLID 等無參考獎勵
  • 提供 Hugging Face Spaces 線上 Demo，亦有 RL launcher 與獎勵服務腳本可重現訓練流程
  • 相關論文已上 arXiv，紀錄後訓練與模型合併的實證結果

對本地化團隊、開發者或研究人員而言，這個項目提供了一條毋須依賴商業 API 的多語翻譯路線，1B 等級的模型體積亦令自部署門檻大幅降低。

項目主頁 · GitHub · 模型

Categories: 開源, 模型, 中國, 小米-Xiaomi

NVIDIA Nemotron 3.5 Lightning：專為長期運行 Agent 而生的輕量 MoE 模型

Share to X

AI Agent 大部分時間都在做工具呼叫、結果驗證等高頻次執行，而非高階推理。Nemotron 3.5 Lightning 以 30B MoE 架構瞄準這個執行層，速度比同級模型快 4 倍。

Og image

長期運行的 AI Agent 真正花時間的地方，往往不是規劃，而是工具呼叫、結果驗證、子代理分派這些高頻次的執行步驟。每一個小動作都用頂級推理模型去跑，會帶來明顯的成本與延遲壓力。NVIDIA 推出的 Nemotron 3.5 Lightning 就是針對這個「執行層」設計的開放模型，採用 30B 參數的 Mixture-of-Experts（MoE）架構，但每次只啟動 3B 參數，在維持效率的同時兼顧準確度。

與坊間常見做法不同，Nemotron 3.5 Lightning 並非要取代大型推理模型，而是與之分工——前者處理高頻執行，後者專注規劃與複雜推理。模型本身針對 agent harness（如 OpenClaw、Hermes Agent）做了訓練優化，並提供 speculative decoding、NVFP4 與 BF16 量化版本，宣稱輸出速度比同級模型快 4 倍。這對需要長時間在線、隨時待命的 Agent 來說，省下的不只是金錢，還有回應時間。

Nemotron Lightning - NVIDIA's Super Fast Agent MoE

NVIDIA 同時推出 NeMo Switchyard，一個負責任務分派的路由函式庫，能根據任務類型自動挑選最合適的模型。整個 Nemotron 系列定位有點像「模型版的軟件庫」，每次發佈都在累積可組合的元件。對於需要自己掌控成本與效能的開發團隊，這套組合提供了相當完整的權重、數據與訓練配方，加上寬鬆的開源授權，方便做深度客製化。

  • 專注 Agent 執行層：30B MoE 架構、3B 活躍參數，設計目標是高頻低延遲的工具呼叫與驗證。
  • 速度與成本取捨：相比同級模型，輸出速度提升達 4 倍，搭配 NVFP4 量化可在本地硬件運行。
  • 分層協作模式：與 Nemotron 3 Ultra 等大型推理模型分工，由 NeMo Switchyard 負責智能路由。
  • 完整開源：權重、訓練數據與配方一併釋出，授權寬鬆，方便客製與整合。
  • 生態整合：對應 NemoClaw 安全管理開源方案，支援 OpenClaw、Hermes Agent 等長期運行框架。

項目主頁

Categories: 開源, Agentic, 模型, NVIDIA, 軟件, 庫, 安全, OpenClaw
Page 7 of 37
1 … 5 6 7 8 9 … 37