LLM_Modularity:MIT 研究拆解 LLM 模組化認知架構

同一類推理會反覆動員同一批神經元,跨領域則明顯分開。這個項目把 LLM 內部的「分工」做成可重跑的分析流程。

probe.py types a reasoning prompt for each cognitive domain; the model

人腦展現出顯著的功能特化程度,不同的神經網路分別支持語言、形式推理、對他人心智的推理以及對物理世界的推理。這種模組化組織是智慧系統建構的基本原則,還是生物大腦特有的進化偶然現象?本文檢驗了大型語言模型(LLM)——另一類透過截然不同的最佳化過程所建構的智慧系統——是否也呈現出類似的組織結構。

值得留意的不是它再講一次模型會推理,而是它嘗試回答:大型語言模型做語言、數理、物理同社交推理時,內部是否真的有近似人腦功能網絡的分工。Pengrui-Han/LLM_Modularity 屬於研究分析工具與資料流程項目,核心工作是用 attribution patching、neuron overlap 同 causal ablation,定位 46 個任務在四個認知領域各自依賴的神經元群。

結論唔止停留在可視化。項目整理出六個 24B 至 123B frontier LLMs 的一致結果:同領域任務的神經元重疊高出 4.3 倍,ARI = 0.78;把某個領域相關神經元做 lesioning 或 ablation,該領域準確率下降幅度比跨領域高 10.3 倍。換句話說,模組化唔係單靠圖像解讀,而係有因果干預支持。

跟一般只看 attention pattern 或 embedding 聚類的做法相比,這個項目更著重「哪些單元真的支撐任務完成」,所以會用 full-sequence teacher-forcing metrics、corrupted-activation ablation,同按模型家族調整的 nnsight 載入流程。代價亦很直接:它不是輕量級 demo,需要 Linux、torch 2.10.0、nnsight 0.4.1,同 NVIDIA GPU;24B 至 123B 模型更要多 GPU 才較可行。

  • 覆蓋 Language、Formal reasoning (Multiple-Demand)、Physical reasoning、Social reasoning (Theory of Mind) 四類推理
  • 提供 46 個任務配置、clean/corrupted data pair、分析腳本與已整理 results CSV
  • 重點不在訓練新模型,而在檢查現有 LLM 內部神經元是否出現穩定分工
  • 已附 figures、overlap matrix 同 ablation analysis,適合延伸做復現或二次研究

較適合做 mechanistic interpretability、認知科學、AI 安全,或者想比較 Qwen、其他大型模型內部推理結構的研究團隊。它暫時更接近研究管線,而不是即裝即用產品;不過資料夾結構、config、scripts 同 results 已經足夠完整,對想重跑實驗、改任務集,或者把 OSWorld 以外的複雜推理基準接入分析流程的人,參考價值相當高。

項目主頁 · GitHub

Categories: 開源, Embedding, Qwen, NVIDIA, Linux, 安全

VoxWeave:Windows 本機 RVC 變聲工作站

把音頻、影片、麥克風同批次任務收在同一個桌面工作站,VoxWeave 走的是本機離線處理路線。它重點解決變聲流程分散、結果難追蹤,同時保留即時變聲與批量轉換。

VoxWeave

VoxWeave 是一套面向 Windows 的 RVC(Retrieval-based Voice Conversion)變聲工作站,定位很清楚:把離線轉換、即時麥克風變聲、批量處理和結果追蹤放進同一個桌面流程。它適合要穩定處理音頻、歌曲或影片音軌的人,也適合需要交付產物、查看失敗原因和保存位置的工作場景。

使用方式偏向本機部署而不是雲端服務。EXE 不內置大體積環境或模型,首次使用可在介面內按需下載經哈希校驗的運行組件與推薦模型;來源倉庫也保留 Linux 和 macOS 的邊界,但目前真機驗收集中在 Windows 11 與 NVIDIA CUDA。

它和常見變聲工具最大的分別,在於把狀態、任務、批量規則、即時會話、產物與歸檔都收進 SQLite 作為單一真源,連診斷匯出都會帶上運行時、模型和日誌清單。這種做法讓問題排查和重試更直接,但代價是它明確不提供虛擬聲卡、模型訓練或 GPT-SoVITS,定位比完整聲音工坊收得更窄。

  • 支援音頻、影片、資料夾和麥克風輸入,流程集中。
  • 可做離線轉換、即時變聲與批量處理,結果可追蹤。
  • 模型按原路徑登記,會計算權重和索引的 SHA-256,不會複製或改名。
  • URL 模型需要提供來源、最終大小和 SHA-256,授權不明時會明確標示。
  • 目標較適合 Windows 本機使用者、內容製作流程,和需要留存產物與錯誤記錄的團隊。

GitHub

Categories: 開源, AI productions, NVIDIA, Mac, Linux, 語音, Win

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 數據集

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

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

NeMo Switchyard:幫 AI Agent 自動揀模型,慳成本又唔跌質素

NVIDIA 推出 NeMo Switchyard,等開發者用同一套 SDK 為 Agent 動態揀選最啱用嘅模型,兼顧成本、延遲同質素。

Og image

揀模型往往是部署 AI Agent 嘅最大難題之一。每一個請求嘅需要都唔同:有時要做分類,有時要做推理,亦可能只係簡單跟進任務。如果全部交俾最貴嘅模型,成本同延遲即刻飆升;硬揀細模型又會喺複雜任務上跌質素。NVIDIA NeMo Switchyard 就係為咗處理呢個矛盾而設計嘅 routing 框架。

開發者可以將 Switchyard 理解為一個智能分流器:每次有請求進入,router 會根據模型能力、成本同基建狀況等即時訊號,決定交俾邊個模型處理。整個判斷過程毋須事先大量微調,支援 tuning-free 同 tunable 兩種路由演算法,亦因為採用 provider-agnostic SDK,邏輯同具體模型供應商解耦,轉換模型時無需重寫應用。

Switchyard NVIDIA's Local Agent Router

呢套做法同「全部用一個模型」嘅常見做法相比,最大差異在於將選模型變成可調控嘅政策。LangChain 同 Cognition 等合作實測顯示,路由後既能維持高準確率,又能明顯降低成本。對於需要同時處理多類任務、又關心成本曲線嘅 Agent 工作流,呢種 system-of-models 嘅思維比起死鎖單一模型更貼近實際環境。

重點摘要:

  • 動態路由:根據每次請求嘅 context、能力、成本同延遲限制,即時揀選最合適嘅模型。
  • 彈性 SDK:provider-agnostic 設計令開發者無需為每個模型供應商重寫應用。
  • 支援兩種路由策略:由 tuning-free 到可微調演算法,畀開發者按需要調整。
  • 成本與質素平衡:實測顯示可以在保持高準確率嘅同時顯著降低開支。
  • 即時訊號驅動:用 runtime 訊號做調度,適合 production 環境嘅 agent workflow。

對於正在建構多步驟 Agent、又唔想被單一模型綁死嘅團隊,NeMo Switchyard 提供咗一個相對務實嘅選擇:將「揀模型」變成可觀察、可調校嘅環節,而唔係每次模型換代都要由頭來過。

項目主頁

Categories: Agentic, 模型訓練, NVIDIA, API, 框架, LangChain

WorldTrace 令世界模型影片記住更遠場景

影片世界要模型生成得夠長,往往先開始失憶。WorldTrace 針對呢個斷層,想保住長時段生成同遠距場景回想能力。

Og image

做長時間影片生成時,Video World Models 最易出現的問題唔係畫面唔夠靚,而是走出訓練長度之後開始「唔認得之前見過乜」。WorldTrace 針對的正是呢種視覺記憶失效:它屬於 Video World Models 的記憶機制改良方法,重點是令 Key-Value (KV) cache 裡已壓縮的內容,過了原本訓練範圍之後仍然可以被模型重新定位和讀取。

核心思路不是再訓練一個新生成器,而是用 training-free 方式處理記憶可尋址性。研究指出,問題關鍵在 temporal Rotary Positional Embeddings (RoPE) 偏移超出訓練 horizon 後,注意力機制即使保留了舊畫面資訊,都未必再讀得到;再加上在 RoPE 旋轉空間直接平均 key,會令不同 phase 互相抵消,令記憶內容變得模糊。WorldTrace 透過固定、仍屬 in-distribution 的 slot 位置保存壓縮記憶,避免記憶「存在但搵唔返」。

同一套記憶框架下,它分成兩個方向:WorldTrace-Field 用 rotation-invariant 的歷史聚合方式,支援較連貫的長 rollout;WorldTrace-Landmark 則保留較接近原樣的 scene traces,讓模型隔了更長時間後,仍有機會回想曾經到過的場景。這種分工反映出一個很實際的取捨:有些情境重視連續生成的穩定性,有些則更需要精準回憶特定地點或視覺片段。

  • 針對訓練 horizon 以外的記憶失效,而不是單純提升畫質
  • 保持壓縮後的 KV memory 可尋址,重點在 fixed in-distribution slot positions
  • WorldTrace-Field 偏重長序列生成的一致性
  • WorldTrace-Landmark 偏重遠距離場景召回與保留視覺痕跡
  • 原始資料將它描述為 training-free,未見提供安裝、下載或部署流程

這類方法較適合需要長時間互動、持續追蹤場景變化,或者要求模型記得自己曾經去過哪裡的工作流,例如互動式模擬、可探索影片環境與長時段世界狀態建模。現有資料亦提到它獲 ICML 2026 F2S Workshop Best Paper。

項目主頁 · 項目

Categories: Embedding, 世界模型, 模型訓練, NVIDIA, Video, 框架, Dataset 數據集

WorldTrace 令影片世界模型記住更遠場景

影片世界要模型生成得夠長,往往先開始失憶。WorldTrace 針對呢個斷層,想保住長時段生成同遠距場景回想能力。

Og image

做長時間影片生成時,Video World Models 最易出現的問題唔係畫面唔夠靚,而是走出訓練長度之後開始「唔認得之前見過乜」。WorldTrace 針對的正是呢種視覺記憶失效:它屬於 Video World Models 的記憶機制改良方法,重點是令 Key-Value (KV) cache 裡已壓縮的內容,過了原本訓練範圍之後仍然可以被模型重新定位和讀取。

核心思路不是再訓練一個新生成器,而是用 training-free 方式處理記憶可尋址性。研究指出,問題關鍵在 temporal Rotary Positional Embeddings (RoPE) 偏移超出訓練 horizon 後,注意力機制即使保留了舊畫面資訊,都未必再讀得到;再加上在 RoPE 旋轉空間直接平均 key,會令不同 phase 互相抵消,令記憶內容變得模糊。WorldTrace 透過固定、仍屬 in-distribution 的 slot 位置保存壓縮記憶,避免記憶「存在但搵唔返」。

同一套記憶框架下,它分成兩個方向:WorldTrace-Field 用 rotation-invariant 的歷史聚合方式,支援較連貫的長 rollout;WorldTrace-Landmark 則保留較接近原樣的 scene traces,讓模型隔了更長時間後,仍有機會回想曾經到過的場景。這種分工反映出一個很實際的取捨:有些情境重視連續生成的穩定性,有些則更需要精準回憶特定地點或視覺片段。

  • 針對訓練 horizon 以外的記憶失效,而不是單純提升畫質
  • 保持壓縮後的 KV memory 可尋址,重點在 fixed in-distribution slot positions
  • WorldTrace-Field 偏重長序列生成的一致性
  • WorldTrace-Landmark 偏重遠距離場景召回與保留視覺痕跡
  • 原始資料將它描述為 training-free,未見提供安裝、下載或部署流程

這類方法較適合需要長時間互動、持續追蹤場景變化,或者要求模型記得自己曾經去過哪裡的工作流,例如互動式模擬、可探索影片環境與長時段世界狀態建模。現有資料亦提到它獲 ICML 2026 F2S Workshop Best Paper,但公開內容目前集中在方法動機與設計,效能細節在這份摘要材料中仍然有限,閱讀時應留意完整論文是否提供更完整的量化結果與測試設定。

項目主頁 · 項目

Categories: Embedding, 世界模型, 模型訓練, NVIDIA, Video, 框架, Dataset 數據集

free-claude-code:一個代理層打通 Claude Code 與 Codex

想保留原生開發代理體驗,又想自由換模型與供應商,free-claude-code 正正補上這個缺口。它把 Claude Code、Codex 同 Pi 接到同一個可管理入口。

用開 Claude Code 或 Codex 的人,最在意通常唔係再裝多一個聊天介面,而係可否繼續用原生 model picker、串流回應、tool use 同 image input,同時改用自己揀的模型供應商。free-claude-code 就係一個 proxy 工具,把 Claude Code、Codex、Pi 及其 IDE 擴充功能接到自管入口,處理多供應商切換同路由分發。

它的價值在於工作流幾乎唔使重學。你可以照用 fcc-claude、fcc-codex 或 fcc-pi 啟動對應代理,Windows 同 macOS 亦可放在背景執行,再到本地 Admin UI 揀選並驗證供應商。可在 31 個 cloud 與本地 providers 之間切換,亦可把 Fable、Opus、Sonnet、Haiku 同 fallback 流量分別導向不同模型,這點對想控制成本、速度同能力分工的團隊幾實用。

跟直接綁死單一 API 的做法相比,這個項目押注在「保留原生客戶端體驗,再用 proxy 抽換後端」。代價是相容性要靠代理層維持,所以它明確強調只會在兼容模型上保留 streaming、tool use、reasoning 同 image input;換句話說,模型可揀得更自由,但不是每個後端都保證功能完全一致。

  • 支援 Claude Code、Codex、Pi,同時保留各自原生 model picker
  • 透過本地 Admin UI 管理與驗證 31 個 cloud/本地 providers
  • 可把不同流量類型分流到不同模型,方便平衡成本與能力
  • 適合想用本地模型、付費模型或免費模型混搭的開發團隊

安裝與測試方式偏向開發者工具鏈:項目以 Python 3.14、uv、Pytest、Ruff、Ty 組成,部署重點不是雲端託管,而是先在本機跑起 proxy,再讓代理客戶端經它連線。現階段最適合已經在用 Claude Code 或 Codex、又想統一管理模型入口的人;追求零設定即用的讀者,會覺得它比較像一層需要自己維護的基建。

GitHub

Categories: 開源, NVIDIA, API, Image, 工具, IDE, Mac, Python, 編程, Anthropic, UI/UX

JoyAI 把即時串流影片編輯推向 720p

影片逐幀抵達便可按文字指令修改,JoyAI-Video-Edit 以 30.19 FPS 連接即時攝影與生成式編輯。

JoyAI-Video-Edit teaser

直播畫面或上載影片不必等到完整片段準備好,便能一邊輸入自然語言指令、一邊看到修改結果。JoyAI-Video-Edit 屬於開源影片生成及影像處理模型,處理的是影片串流中延遲高、必須預先知道片長,以及難以維持連貫性的編輯流程。

它支援主體修改、局部區域調整、背景替換、風格轉換、動作改變和參考影像引導,適合互動示範、直播效果及需要即時預覽的創作工具。系統以 Multimodal Large Language Model(MLLM)條件編碼器、causal video Variational Autoencoder(VAE)及 16B-parameter Multimodal Diffusion Transformer(MMDiT)組成,逐段處理新抵達的畫面。

同類影片生成方法往往先取得完整影片,再一次過進行離線處理;JoyAI-Video-Edit 改用 autoregressive diffusion,配合 aligned autoregressive distribution matching distillation、long-horizon optimization、bounded Key-Value state(KV-state)inference 和 deployment-oriented scheduling,換取串流速度。不過,這種設計仍要留意長時間輸出可能出現的 temporal drift,而且消費級 GPU 支援仍列為待辦工作。

部署基準在 720×1280 解像度達到 30.19 FPS end-to-end throughput,代表系統已接近互動式影片處理所需的速度,但不能直接等同於所有硬件和指令下都能保持相同表現。Hugging Face 提供 JoyAI-Video-Edit checkpoint,GitHub 同時提供部署程式碼和線上 Demo,較適合具備 GPU 資源、希望整合影片工作流,或研究 Computer Vision 與串流生成的團隊。

  • 即時串流:畫面逐幀處理,不要求預先提供完整影片或固定片長。
  • 指令範圍廣:涵蓋主體、局部、背景、風格、動作及參考影像編輯。
  • 速度指標:720×1280 下達到 30.19 FPS 的完整流程吞吐量。
  • 部署取捨:透過 bounded KV-state inference 控制計算量,但消費級 GPU 支援仍未完成。
  • 適用人群:影片工具開發者、直播創作者及需要即時預覽的研究團隊。

GitHub · 模型

Categories: 開源, 視覺模型, 多模態模型, 視頻模型, Google, NVIDIA, Video, 蘋果, Dataset 數據集

CADENA 把 3D 網格逐步還原成 CAD 程式

想由3D mesh 反推可編輯 CAD 流程,CADENA 提供了一條幾務實的路。它唔係一次過寫完整程式,而係每步都先執行、再比較幾何差異。

Repository image for zhemdi/cadena

做 3D reverse engineering,最大痛點唔係生成一段似樣代碼,而係生成之後能否真的建出可用、可編輯、而且封閉的幾何。CADENA 屬於模型加推理流程的參考實作,目標是把 3D mesh 重建成 parametric CAD program;它採用 stepwise inference,每次只發出一個 operation,先執行目前前綴,再用目標幾何與已建幾何的差距決定下一步。

這種做法的價值,在於把「一次過輸出整段程式」改成可檢查、可回退的逐步生成。倉庫內的 inference/ 會做 vLLM 服務、per-operation expansion 同 prefix selection,rl/ 則負責 sandboxed prefix rendering 與排序分數;系統只保留能令 IoU 改善的步驟,所以多走幾步不會令結果更差。代價同樣清楚:部署要 Python 3.10+、CUDA GPU、vLLM,同時依賴 OpenCASCADE via CadQuery,環境比一般 Vision-Language 模型推理更重。

模型本身用的是 Qwen2-VL-2B policy,Hugging Face 釋出 sft 與 rl 兩個階段,當中 rl 對應 CADENA-RL。輸入不是單張截圖,而是八個視角拼成一張圖,六個軸向視圖加兩個等角視圖;目標物放在綠色通道,當前已建立幾何放在紅色通道,模型讀到的其實是尚未補齊的殘差。這種設計直接把「下一刀應該補邊度」轉成視覺訊號。

幾個值得留意的重點:
– 倉庫提供完整推理、資料集建立、評分與可視化流程,但不包含用來合成訓練語料的 rule-based program generator。
– cadgen/ 只有 DSL runtime 的執行半部,較適合做還原、測試與基準比較,唔係完整資料生產管線。
– 預設流程會由 mesh 目錄建立 inference dataset,再輸出每一步的程式、輸入圖同 built STL,方便檢查中途錯誤。
– 無效預測會被剔除:建不出來,或者結果不是 watertight,都不算有效答案。
– 評分包含 GMS、IoU、CD,而且結果會按 family 及整體一併報告,避免單一類型零件拉高平均值。

適合研究 CAD reverse engineering、幾何生成、製造前處理,或者想把 mesh 轉回可參數化編輯流程的團隊。現階段最實際的理解方式,是把 CADENA 看成一套偏研究導向、但已經有明確 benchmark、checkpoint 同 rollout 腳本的開源項目;可重現性做得不錯,不過完整訓練資料生成鏈未公開,想延伸到自家資料或重訓流程,仍要補上不少工程工夫。

GitHub · 模型

Categories: 開源, 多模態模型, Qwen, Google, NVIDIA, 框架, 3D, Python, Dataset 數據集

Page 10 of 17
1 … 8 9 10 11 12 … 17