51c大模型~合集150

我自己的原文哦~? ? ? ??https://blog.51cto.com/whaosoft/14034001

#原來Scaling Law還能被優化

Meta這招省token又提效

2017 年,一篇《Attention Is All You Need》論文成為 AI 發展的一個重要分水嶺,其中提出的 Transformer 依然是現今主流語言模型的基礎范式。尤其是在基于 Transformer 的語言模型的 Scaling Law 得到實驗驗證后,AI 領域的發展更是進入了快車道。

圖片

現如今,這篇論文的引用量正向 19 萬沖刺,而 Transformer 和注意力機制本身也已經歷了很多改進和創新,比如我們前段時間報道過的「Multi-Token Attention」和「Multi-matrix Factorization Attention」等。

隨著 AI 的不斷發展,現如今的一個重要挑戰是如何獲得足夠多高質量的 token。又或者,該如何更高效地利用這些 token?為此,還必須對 Transformer 進行進一步的升級改造。

近日,Meta 的一篇論文公布了他們在這方面取得的一個新進展,提出了一種旋轉不變型三線性注意力機制,并證明其表示能力與 2-simplicial Transformer 相當。更重要的是,它的表現甚至足以改變 Scaling Law 中的系數。Meta 也用 Triton 實現了這種注意力機制。

圖片

該研究基于 RoPE 向三線性函數的泛化;而 2-simplicial Transformer 則源自 2019 年 Clift et al. 的研究《Logic and the 2-Simplicial Transformer》,其中將 Transformer 的點積注意力機制泛化到了三線性形式。

圖片

論文標題:Fast and Simplex: 2-Simplicial Attention in Triton

論文地址:https://arxiv.org/pdf/2507.02754.pdf

他們進一步證明,在有限的 token 預算下,2-simplicial Transformer 的擴展性優于 Transformer。

此外,他們的實驗還表明,2-simplicial Transformer 相對于 Transformer 具有更有利的參數數量 scaling 指數。這表明,與 Chinchilla scaling 不同,有可能以比 2-simplicial Transformer 的參數增長更慢的速度增加 token 數量。

研究結果表明,在 token 約束下運行時,與點積注意力機制 Transformer 相比,2-simplicial Transformer 可以更有效地逼近自然語言的不可約熵。

神經 Scaling Law 概述

要理解這項研究的意義,首先需要了解一下 Scaling Law。

簡單來說,就是損失 L 會隨模型參數總數 N 和 token 數量 D 呈冪律衰減:

圖片

其中,第一項 E 通常被描述為不可約損失,對應于自然文本的熵。第二項描述了這樣一個事實:具有 N 個參數的模型的表現達不到理想的生成過程。第三項則對應于這樣一個事實:我們僅使用有限的數據樣本進行訓練,并且沒有將模型訓練到收斂。

理論上,當 N → ∞ 且 D → ∞ 時,大型語言模型應該接近底層文本分布的不可約損失 E。

對于給定的計算預算 C,其中 F LOP s (N, D) = C,可以將最佳參數數量表示為 Nopt ∝ C a,將最佳數據集大小表示為 Dopt ∝ C b。Hoffmann 等人 (2022) 的作者進行了多項實驗,并將參數函數擬合到損失函數中,以估計指數 a 和 b:多種不同的方法證實,a 大約為 0.49,b 大約為 0.5。這引出了 Hoffmann 等人 (2022) 的核心論點:必須根據模型大小按比例縮放 token 數量。

對于給定的計算預算 C,其中 FLOPs (N, D) = C,可以將最佳參數數量表示為 N_opt ∝ C^a,將最佳數據集大小表示為 D_opt ∝ C^b。Hoffmann et al. (2022) 進行了多次實驗,并根據損失擬合了參數函數,以估計指數 a 和 b。

結果,通過多種不同方法發現:a 約為 0.49,b 約為 0.5。

如此,便引出了 Hoffmann et al. (2022) 的一個核心論點:必須根據模型大小按比例擴展 token 數量。

但是,正如前面討論的那樣,足夠高質量且足夠數量的 token 是預訓練擴展的新瓶頸,因此需要探索替代的訓練算法和架構。另一方面,最近的研究表明,之前文獻中提出的大多數建模和優化技術僅僅改變了誤差(偏移了 E),并沒有從根本上改變冪律中的指數。谷歌 DeepMind 的研究者 Katie Everett 對此進行過精彩的討論:

??https://x.com/_katieeverett/status/1925665335727808651??

圖片

2-simplicial Transformer

2-simplicial Transformer 由 Clift et al. (2019) 提出,他們將點積注意力機制從雙線性擴展為三線性形式,也就是從 1-simplex 擴展成了 2-simplex。

先來看看標準的注意力機制:

圖片

其中,每一項都是點積?

圖片

然后,通過逐行 softmax 運算將注意力分數(logit)轉換為概率權重:

圖片

注意力層的最終輸出是根據這些注意力分數對這些值進行線性組合得到的

圖片

Clift et al. (2019) 的 2-simplicial Transformer 論文將其推廣到三線性積,其中有兩個額外的鍵和值投射矩陣 W_K′ 和 W_V′,從而得到 K′ = XW_K′ 和 V′ = XW_V′。然后,2-simplicial Transformer 的注意力 logit 由 Q、K 和 K′ 的三線性積給出,從而得到以下三階張量:

圖片

從而注意力張量變為:

圖片

注意力運算的最終輸出定義為:

圖片

其中?

圖片

?表示兩個向量的元素級 Hadamard 積。2-simplicial Transformer 的偽代碼如算法 1 所示。注意,公式 5 不包含 RoPE 等任何位置編碼。

圖片

基于行列式的三線性形式

Su et al., 2024 提出 RoPE 時,是想將其作為一種用于 Transformer 語言模型的序列位置信息捕獲方法。RoPE 對查詢 q_i 和鍵 k_j 應用位置相關的旋轉,使得點積 <q_i, K_j> 是相對距離 i-j 的函數。特別需要注意的是,點積對于正交變換 R 具有不變性:

圖片

這對于 RoPE 至關重要,因為對于同一位置 i 相同的查詢 q_i 和鍵 k_i,我們期望其點積不會因基于位置的旋轉而發生變化。請注意,(5) 式中定義的三線性形式并非是旋轉不變,并且對 q_i 、k_i 和 k′_i 進行相同的旋轉不再保留內積。因此,為了將 RoPE 泛化到 2-simplicial 注意力模型,探索其他具有旋轉不變性的雙線性和三線性形式至關重要。

而 Meta 的這個團隊注意到,以下函數也具有旋轉不變性:

圖片

可以使用帶符號的行列式運算?

圖片

?來計算 A^(det) ∈ ?^n×n×n。對于任意向量 q,令 q^(l) = q = q [3 (l - 1) : 3l] 為其第 l 個大小為 3 的塊。其 logit 定義為:

圖片

由于公式 8 根據 Sarrus 規則包含 2 個點積項,因此需要修改算法 1,使用 2 個 einsum 而不是第 2 行中的 1 個。最終的注意力權重 S 是通過對上述 logit 應用 softmax 函數來計算的,類似于公式 6。然后,token i 的輸出是值向量的加權和,如公式 7 所示。

定理:對于任意輸入大小 n 和輸入范圍 m = n^{O (1)},存在一個具有單個注意力頭的 Transformer 架構,其 logit 計算方式如公式 (9) 所示,注意力頭維度為 d = 7,使得對于所有 X ∈ [M]^N,如果

圖片

,則 Transformer 對元素 x_i 的輸出為 1,否則為 0。

對該定理的證明請見原論文附錄。

模型設計

由于 2-simplicial 注意力在序列長度 n 上的擴展復雜度為 O (n^3),因此將其應用于整個序列是不切實際的。該團隊的做法是將其參數化為 O (n× w_1 × w_2),其中 w_1 和 w_2 定義的是序列上滑動窗口的維度。每個查詢向量 Q_i 會關注 w_1 個 K 鍵和 w_2 個 K′ 鍵的局部區域,從而減輕計算負擔。該團隊系統地評估了 w_1 和 w_2 的各種配置,以確定計算效率和模型性能之間的最佳平衡點(見表 1)。

圖片

對于因果點積注意力機制,長度為 n 的序列的復雜度由下式給出:

圖片

其中 n 是序列長度。這涉及兩次矩陣乘法:一次用于 Q@K,一次用于 P@V,每次乘法每個元素都需要兩次浮點運算。因果掩碼使其能夠跳過 1/2 的計算。

相比之下,以 w_1 和 w_2 為參數的 2-simplicial 注意力機制的復雜度表示為:

圖片

其復雜度的增長來源是三線性 einsum 運算,與標準點積注意力機制相比,它需要進行一次額外的乘法運算。

該團隊選擇窗口大小為 (512, 32),以平衡延遲和質量。在此配置下,2-simplicial 注意力機制的計算復雜度與 48k 上下文長度的點積注意力機制相當。

圖 2 給出了一個實現。因此,像在 Flash 注意力機制中那樣平鋪式查詢 Q 會導致計算吞吐量較低。受 Native Sparse Attention 的啟發,Meta 該團隊采用的模型架構利用了較高 (64) 的分組查詢注意力 (GQA) 比率。這種方法能夠沿著查詢頭高效地平鋪,確保密集計算,并消除昂貴的逐元素掩碼。

圖片

該團隊還引入了一系列針對 2-simplicial 注意力的核優化,這些優化基于使用在線 softmax 的 Flash Attention。詳見原論文。下面來重點看看實驗表現。

圖片

實驗與結果

這個團隊訓練了一系列 MoE 模型,其參數范圍從 1B 活動參數和 57B 總參數到 3.5B 活動參數和 176B 總參數。具體配置見原論文。

圖片

該團隊發現,從 1B (活動)參數模型到 3.5B (活動)參數模型,負對數似然的擴展(?)出現了下降。

此外,在小于 2B (活動)參數的模型中,使用 2-simplicial 注意力機制沒有任何好處。

基于此,該團隊估算了 2-simplicial 注意力機制與點積注意力機制的冪律系數有何不同。基于前述方法,其損失可以表示為:

圖片

由于訓練這兩個模型使用的 token 數量相同,因此可以忽略第三項,將損失簡化為:

圖片

其中 β = - log E′′ - logA ,由于 E′ 較小,E′′ 是 E′ 的近似值。注意,這里使用了 log (a + b) = log (1 + a/b) + log (b) 來分離這兩個項,并將 1 + a/b 項隱藏在 E′′ 中。

因此,可以根據表 2 中的損失估算兩組模型的 α 和 β,其中 N 代表每個模型中的有效參數。

該團隊在表 3 中估計了 Transformer 和 2-simplicial Transformer 的斜率 α 和截距 β。

圖片

可以看到,與點積注意力 Transformer 相比,2-simplicial 注意力具有更陡的斜率 α,即其 Scaling Law 的指數更高。

#Causal-Copilot

集成20+先進算法,優于GPT-4o,自主因果分析智能體來了

來自加利福尼亞大學圣迭戈分校(UC San Diego)Biwei Huang 實驗室的研究團隊提出了一種自主因果分析智能體 Causal-Copilot。該實驗室專注于因果推理與機器學習的交叉研究,在因果發現和因果表征學習領域取得了多項重要成果。論文共同第一作者 Xinyue Wang、Kun Zhou 和 Wenyi Wu 均來自 Biwei Huang 教授實驗室,他們在因果推理與大語言模型結合方面開展了這項創新性研究。同時這項研究也得到了創業公司 Abel.ai 的大力支持和協助。

一個普遍的困境

想象這樣一個場景:你是一位生物學家,手握基因表達數據,直覺告訴你某些基因之間存在調控關系,但如何科學地驗證這種關系?你聽說過 "因果發現" 這個詞,但對于具體算法如 PC、GES 就連名字都非常陌生。

或者你是一位社會學家,想要評估教育政策對學生成績的真實影響。你知道簡單對比可能受其他因素干擾,但面對雙重差分、傾向得分匹配等方法及其不同假設條件,你感到無從下手。

這就是因果分析的現狀:理論越來越豐富,工具越來越強大,但使用門檻卻始終居高不下。

預訓練模型的局限性

當前的 AI 系統,包括最先進的大語言模型,本質上都是模式識別器。它們可以發現 "A 和 B 經常一起出現",但無法理解 "A 導致了 B" 還是 "B 導致了 A",抑或是 "C 同時影響了 A 和 B"。

這種局限性在實際應用中帶來嚴重后果。數據顯示使用某款教育 App 的學生成績更好,基于相關性的 AI 可能建議推廣這款 App 來提高成績。但因果分析可能揭示:是成績好的學生更傾向于使用學習 App,而非 App 提高了成績。

因果分析包含兩個核心任務。因果發現 (Causal Discovery) 從數據中識別變量間的因果關系,構建因果圖,幫助我們理解系統的運作機制。因果推斷 (Causal Inference) 則基于這些因果關系,量化干預效應,回答 "如果我們這樣做會怎樣" 的問題。這兩個任務相輔相成,共同構成了理解世界運行機制的完整圖景。

然而,掌握這些方法需要深厚的統計學背景和豐富的實踐經驗。每種算法都有其適用場景和限制條件,選錯方法可能導致完全錯誤的結論。這種專業門檻將大量需要因果分析的研究者拒之門外。

Causal-Copilot:讓復雜變簡單

我們提出了一個優雅的解決方案:既然因果分析的使用難點主要在于方法選擇和參數調優,為什么不讓 AI 來承擔這部分工作?

Causal-Copilot 正是基于這一理念構建的自主因果分析智能體。這個系統的強大之處在于其前所未有的全面性 —— 集成了超過 20 種最先進的因果分析算法,真正實現了 "一站式" 因果分析。無論你的數據是表格形式還是時間序列,是線性關系還是復雜的非線性模式,是完美的實驗數據還是充滿噪聲的觀察數據,Causal-Copilot 都能自動找到合適的分析方法。

圖片

論文鏈接:https://arxiv.org/abs/2504.13263?

開源代碼:https://github.com/Lancelot39/Causal-Copilot?

在線體驗:https://causalcopilot.com/

圖片

統一因果發現與推斷的智能系統

Causal-Copilot 的核心創新在于將因果發現和因果推斷的完整流程智能化、自動化。該系統集成了 20 余種最先進的算法作為工具,覆蓋了從結構學習到效應估計的全過程:

圖片

因果發現能力:

  • 自動識別變量間的因果關系,構建因果圖
  • 可以處理線性 / 非線性、離散 / 連續、靜態 / 時序、高斯 / 非高斯噪音等多種數據特性
  • 處理潛在混雜、數據缺失、數據異質性等現實挑戰
  • 內置 CPU/GPU 算法加速實現更好解決大規模和高維應用場景

因果推斷能力:

  • 基于發現的因果結構,估計干預效應
  • 支持平均處理效應、異質性效應、反事實推理
  • 提供效應的不確定性量化和穩健性檢驗

圖片

Causal-Copilot 在 Online shop, Climate, Abalone 數據集上挖掘出的因果關系

模塊化技術架構

Causal-Copilot 采用模塊化架構設計,包含五個核心組件:

1. 用戶交互模塊:支持自然語言查詢輸入和交互式反饋例如指定偏好和約束。

2. 預處理模塊:執行全面的數據準備功能,包括缺失值檢測和插補、特征轉換、模式提取和適用于表格和時序數據的統計信息診斷。這些診斷結果直接指導后續的算法選擇。

3. 算法選擇模塊:根據數據特性和因果分析的專家知識和實證數據進行算法過濾和排名、結合上下文進行超參數配置、以及執行算法和處理可能的錯誤。

4. 后處理模塊:通過 Boostrap、利用 LLM 常識推理驗證因果連接的合理性,理解用戶反饋來增強因果圖的準確性。同時對于因果效應,進行敏感性分析和穩健性檢驗。

5. 報告生成模塊:將分析結果編譯成用戶友好的可視化研究報告包含因果分析全程、LLM 對分析結果的推斷和洞察。

圖片

因果發現與推斷的多維度評估

我們系統性地評估了 Causal-Copilot 在不同因果發現和因果推斷場景中的數據分析和算法決策能力,其中因果發現評估囊括時序和非時序數據。

我們在多維度場景中系統評估了 Causal-Copilot 的性能。在表格數據上,涵蓋了基本場景、數據質量挑戰(異質域、測量誤差、缺失值)和復合場景(臨床、金融、社交網絡數據),系統在極大規模網絡(高達 1000 節點)中仍保持優異表現。時間序列和因果推斷評估同樣證實了系統的強大適應性。在 CSuite 基準測試和真實數據集上,Causal-Copilot 顯著優于以 GPT-4o 直接調用因果算法為基線的方法,以及現有的傳統因果發現算法。

圖片

圖片

圖片

實際應用

用戶初始請求:這是一個關于地震的時序數據集,請幫我調查其中的因果關系。

圖片

結語

通過統一因果發現和推斷的全流程,Causal-Copilot 讓研究者能夠完整理解因果機制、做出可靠決策、加速科學發現。研究團隊已將系統完全開源,提供代碼、教程和在線演示平臺,邀請全球研究者共同參與改進。

#RoboRefer

復雜空間指令也能秒懂?讓機器人理解推理空間,開放世界也能精準行動!

本文的主要作者來自北京航空航天大學、北京大學和北京智源人工智能研究院。本文的第一作者為北京航空航天大學碩士生周恩申,主要研究方向為xx智能和多模態大模型。本文的共一作者兼項目負責人為北京智源研究院研究員遲程。本文的通訊作者為北京航空航天大學副教授盛律和北京大學計算機學院研究員、助理教授仉尚航。

機器人走出實驗室、進入真實世界真正可用,遠比想象中更復雜。現實環境常常雜亂無序、物體種類繁多、靈活多變,遠不像實驗室那樣干凈、單一、可控。

想象一下,你正在餐廳吃飯,身邊有個服務機器人。你對它說:「把第二列最遠的黃色壽司盤,放到離我最近的壽司和醬油碟之間的空位上。」(左圖)又或者,你希望它「拿起最左邊、飲料 logo 正對的蘋果,放到最近的桌子上,并與之前的蘋果排成一排、間距一致。」(右圖)

圖片

這些聽起來是我們日常再熟悉不過的指令,其實是一個典型空間指代(Spatial Referring)任務。簡單來說,就是讓機器人通過「最遠」「第二列」「等間距」「正對著」這類空間關系,搞清楚要抓哪個對象、放在哪里、或者走向哪個位置。

聽著簡單,做起來卻不容易。哪怕是目前最強大、最先進的多模態大模型,也依然難以準確理解復雜的三維場景,并根據指令動態推理出正確的交互位置。這是因為空間指代任務,背后其實包含了兩個維度的挑戰:

單步空間理解:機器人得先看懂世界。這要求模型能夠準確識別物體的空間屬性(比如位置、朝向)以及它們之間的空間關系(比如遠近、方向)。這是空間指代任務的基礎,大部分研究目前還停留在這一層。

多步空間推理:真正的挑戰來了:面對一連串復雜的空間關系約束,機器人不僅要理解,還要逐步推理、動態判斷,靈活應對各種開放世界中各種各樣的空間關系組合。這種能力對于實現真正的空間指代至關重要,但目前仍然是一個被嚴重低估和不足探索的方向。

為了破解空間指代的難題,北京航空航天大學、北京大學與北京智源人工智能研究院聯合提出了一個具備三維空間理解推理能力的多模態大模型 ——?RoboRefer。這個模型不僅通過全參數微調(SFT),實現了對空間信息的精準理解,還通過強化學習微調(RFT),大幅提升了推理與泛化能力,最終實現開放世界的空間指代。

  • 論文鏈接:https://arxiv.org/pdf/2506.04308
  • 論文標題:RoboRefer: Towards Spatial Referring with Reasoning in Vision-Language Models for Robotics
  • 項目主頁:https://zhoues.github.io/RoboRefer
  • 代碼倉庫:https://github.com/Zhoues/RoboRefer?
  • 數據鏈接:https://huggingface.co/datasets/JingkunAn/RefSpatial
  • 評測鏈接:https://huggingface.co/datasets/BAAI/RefSpatial-Bench

SFT 訓練下的 RoboRefer 在空間理解任務中達到了?89.6% 的平均成功率,刷新了當前最先進水平。而在研究者提出的高難度空間指代任務評測基準?RefSpatial-Bench?上,RFT 訓練后的 RoboRefer 更是領先所有其他模型,比 Gemini-2.5-Pro 高出 17.4% 的平均準確率,優勢顯著。

更重要的是,RoboRefer 并非「紙上談兵」。它可以靈活集成到不同類型的機器人上,比如 UR5 機械臂、G1 仿人機器人等,實現對現實世界中復雜、動態、多步驟任務的精準執行,真正讓機器人「聽得懂、看得清、動得準」。

RoboRefer 是什么

圖片

RoboRefer 是一個具備三維空間理解與推理能力的多模態大模型,擁有獨立的圖像編碼器和深度圖編碼器,其不僅能回答各種空間感知類問答,無論是「這個物體離我有多遠?」這樣的定量問題,還是「哪個物體在左邊?」這樣的定性問題;更厲害的是,它還能基于多種空間關系(比如物體的位置和朝向),進行復雜的組合式推理,最終準確定位需要交互的位置。

比如,面對一個指令:「把這個物體放在筆筒和鍵盤的中間,水瓶的 logo 要正對著你。」RoboRefer 不僅能理解這句自然語言的空間邏輯,還能在真實三維場景中,找到唯一正確的位置來完成任務。

RoboRefer 的核心是什么

為什么相較于以往的方法,RoboRefer 不僅可以精確的感知空間,而且又可以根據多個空間關系組合泛化推理出交互的位置呢?其關鍵因素在于以下幾點:

SFT 增強空間感知能力,RFT 搭配過程獎勵提升泛化推理能力

當前多模態大模型在 2D 預訓練階段缺乏對空間關系的深入理解,為了提升模型的單步空間理解能力,研究人員引入了一個獨立的深度編碼器,使模型能夠更有效地感知和利用三維信息,并通過全參數微調(SFT)進行訓練。

盡管 SFT 使用了各種空間感知和推理數據,但模型更傾向于記憶答案,而不是泛化到新的空間約束條件。為了解決這一問題,研究者進一步引入了基于 GRPO 的強化學習微調。

值得一提的是,團隊不僅關注結果導向的獎勵(outcome-based reward),還創新性地設計了基于過程的獎勵函數(process reward functions),這些函數能夠感知中間推理過程的質量,從而提升模型多步空間指代任務中的推理精度。最終,模型增強了顯式多步推理能力,實現了開放世界的空間指代任務。

提出 RefSpatial 數據集,教一個多模態大模型從 0 到 1 學會空間指代

圖片

為了支持前述的 SFT 和 RFT 訓練,研究團隊構建了一個大規模、高質量的數據集 ——RefSpatial,具有以下幾個核心特點:

  • 精細標注:每個物體都配有層級式描述,從「杯子」這類種類類別,到像「左數第三個杯子」「最靠近攝像頭的杯子」這樣的精確空間指代,確保在復雜場景中也能清晰用文字表述。
  • 多維推理:數據集不僅標注了目標,還附帶詳細的多步推理過程(最高有 5 步),為復雜空間指代提供支持。
  • 高質量篩選:數據經過嚴格篩選,確保標注準確、語義清晰。
  • 規模龐大:共包含 250 萬個樣本、2000 萬個問答對,數據量是同類數據集的兩倍。
  • 場景豐富:覆蓋室內外環境,涵蓋多種日常交互情境,并整合了 31 種空間關系(對比以往最多 15 種)。
  • 易于擴展:支持從多種來源生成空間指代數據,包括 2D 圖像、3D 視頻(含邊界框)和模擬資產,具備高度擴展性。

RoboRefer 到底有多厲害

單步空間理解評測

SFT 訓練后的 RoboRefer 在各種空間理解任務中達到了?89.6% 的平均成功率,取得了當前最先進水平。

圖片

多步空間指代評測

RFT 訓練后的 RoboRefer 在已有的機器人指代榜單上依舊超越現有方法,在研究者們提出的高難度空間指代任務評測基準?RefSpatial-Bench?上,其更是領先所有其他模型,比 Gemini-2.5-Pro 高出 17.4% 的平均準確率。

圖片

下面展示一些 RoboRefer 與其它模型輸出結果的可視化樣例:

圖片

仿真與真機實驗

在空間操控的機械臂仿真評測中,RoboRefer?的表現遠超現有的視覺 - 語言 - 動作(VLA)系統。不僅在模擬環境中成功率遙遙領先,面對開放世界中的多步推理與復雜指代任務,唯有 RoboRefer 能夠完成!

,時長01:18

,時長00:59

更多的實驗結果,可視化展示(包括更多的雜亂場景下的真機 Demo 視頻的空間指代結果)詳見論文和主頁!

#一個氣泡水廣告,為何幾十萬人圍觀

原來整個都是Veo 3生成的

最近,一個完全由 AI 制作的廣告在社交媒體上爆火,在 X 上有三十多萬人觀看。

圖片

這是一個叫 Too Short for Modeling 的團隊發布在 LinkedIn 上的作品,不過它并不是一個商業作品,而是該團隊為一直想合作的品牌制作的概念影片。

距離 Veo 3 發布已經過去一個半月了,雖然此前模型視頻生成已經能達到很逼真的狀態,但 Veo 3 的「音畫同步」功能,引領 AI 視頻創作進入了全新的聲畫一體化階段。同時它也讓 AI 視頻生成進入了更有實踐意義的階段,極大地降低了視頻創作的門檻。

我們先來看看這個廣告效果怎么樣。

,時長01:01

來源:https://www.linkedin.com/posts/arielyoriginal_veo3-aicreative-fakeads-activity-7346271275020902400-P9fd

人物1:下午好,小伙子。 (Good afternoon, son.)

人物2:想猜猜我為什么讓你靠邊停車嗎? (Wanna take a guess why I pulled you over?)

人物1:哦,不是你想的那樣。 (Oh, it's not what you think.)

人物1:這是“液態死亡”。是蘇打山泉水。 (It's liquid death. They're sparkling mountain water.)

人物2:嗯。哇。你沒開玩笑。 (Mmm. Wow. You weren't kidding.)

人物2:確實很清爽。 (That is refreshing.)

人物2:但這不是我讓你靠邊停車的原因。 (But it's not why I pulled you over.)

人物1:哦,天哪。 (Oh boy.)

人物1:是因為破損的尾燈嗎? (Is it the busted taillight?)

人物2:不是。 (Uh-uh.)

人物1:是因為車牌嗎? (Is it because of the license plate?)

人物2:不是。 (Nope.)

人物1:該死,伙計。是那個死人,對吧? (Shit, man. It's the dead guy, right?)

人物2:不,先生。 (No, sir.)

人物1:也許是人口販賣? (Is it the human trafficking, perhaps?)

人物2:不是。 (Uh-uh.)

人物1:伙計,是卡車的事嗎? (Man, is it the truck thing?)

人物2:我不這么認為。 (I don't think so.)

人物1:好吧,那到底是什么? (Well, what is it then?)

人物1:搶劫案? (The robbery?)

人物2:不。 (No.)

人物1:是保險杠貼紙? (The bumper sticker?)

人物2:不。 (No.)

人物1:是被車撞死的動物,對不對? (It's the roadkill, isn't it?)

人物2:沒聽說過。 (Haven't heard of it.)

人物1:是化學廢料? (The chemical waste?)

人物2:不是。 (Uh-uh.)

人物1:是過山車座位嗎? (Is it the roller coaster seat?)

人物1:是邪教的事嗎? (Is it the cult thing?)

人物2:絕對不是。當然不。 (Absolutely not. Hell no.)

人物1:好吧,我放棄了。 (All right, I give up.)

人物1:到底是什么? (What is it?)

人物2:因為今天是你的生日。 (It's because it's your birthday.)

人物2:生日快樂,凱文。 (Happy birthday, Kevin.)

人物1:爸爸,你還記得。 (Dad, you remembered.)

人物2:祝你生日快樂,祝你生日快樂,祝你生日快樂。 (Happy birthday to you, Happy Birthday to you, Happy Birthday to you.)

視頻字幕,上下滑動查看。

這個廣告的笑點密集,令人捧腹。但其真正的亮點在于驚人的「角色一致性」。在一分鐘內,視頻流暢地切換了10個場景,每個畫面的風格都保持了高度統一,核心人物和道具也完美銜接。盡管在車窗、內飾等細節上能察覺到微小的跳躍,但這絲毫未影響其出色的整體連貫性。

要知道 AI 生成視頻中經常出現容貌突變、物體錯亂等問題。

主創團隊分享了他們保持一致性的秘訣——超精細提示 (Hyper-specific Prompting):為模型提供極其詳盡、具體且包含大量上下文細節的指令或問題。

這種提示的設計目的是為了最大限度地減少模型的自由發揮空間,引導它生成高度精確、符合特定格式和要求的輸出。

image.png

相關的提示詞優化方法,在我們之前的文章中也提到過,讀者可以參考:實測驚艷全球的 Veo3!音畫同步無敵,貴是有原因的

值得一提的是,創意、策略與審美依然由人類主導。從最初的靈感、腳本,到由剪輯師完成的最終效果呈現,人的價值貫穿始終。AI 是強大的「執行者」,但遵循的是概率而非遠見——至少在今天,這道邊界依然清晰。

image.png

AI為何總在細節上「翻車」?

關于「角色一致性」的問題,技術層面來講,并非模型「犯了糊涂」,而是主流視頻生成模型背后的核心技術——擴散模型本身的工作原理、訓練數據以及從圖像到視頻的技術跨越之中,主要是以下幾點原因:

image.png

模型沒有「理解」世界,只有「概率統計」:模型并非真正理解「人有五根手指」這類事實,而是通過學習海量數據,知道「五指的手」是最高概率的模式。當生成過程中出現隨機偏差時,由于缺乏常識性規則的約束,它可能會生成一個概率上雖低但仍有可能的「六指」結果。

  • 局部生成與全局和諧的矛盾:模型更擅長生成逼真的局部細節(如皮膚紋理),但對整體結構(如完整的身體解剖)的把握較弱。它可能會因為專注于讓局部「看起來對」,而忽略了其在整體畫面中的邏輯是否合理,導致「只見樹木,不見森林」的結構性錯誤。
  • 從圖像到視頻的挑戰:視頻的本質是連續的圖像序列,而模型在生成每一幀時都可能存在微小的隨機差異。這種幀與幀之間的「失憶」累積起來,就會導致角色外觀、服飾或背景等元素在時間線上發生不連貫的漂移和變化,破壞了時間一致性。
  • 訓練數據的「不完美」:模型的知識完全來源于它所學習的訓練數據。網絡數據本身就包含大量錯誤、低質量和不合邏輯的內容。模型會將這些「壞數據」也一并學會,并在生成時復現出來,可謂「垃圾進,垃圾出」。

探索AI的創意玩法

當前,大量獵奇、同質化的 AI 視頻內容,正是 AI 技術被「降維使用」的體現。真正值得我們探索的,是 AI 作為「創意催化劑」的巨大潛力。

下面這些會不會是 AI 的正確打開方式?

  • 為你喜歡的電影制作一個平行宇宙。

image.png

  • 讓初音未來進入老頭環的世界,會不會是下一個爆款游戲的靈感?

image.png

  • 為公司做一個網站。

image.png

  • 或者做一個超炫酷的概念影片。

image.png

你覺得 AI 還能為我們的創意帶來什么驚喜?歡迎在評論區留下你的腦洞。

#MemOS

重塑AI記憶邊界:MemOS開源!時序推理較OpenAI提升159%

大模型記憶管理和優化框架是當前各大廠商爭相優化的熱點方向,MemOS 相比現有 OpenAI 的全局記憶在大模型記憶評測集上呈現出顯著的提升,平均準確性提升超過 38.97%,Tokens 的開銷進一步降低 60.95%,一舉登頂記憶管理的 SOTA 框架,特別是在考驗框架時序建模與檢索能力的時序推理任務上,提升比例更是達到了 159%,相當震撼!

圖片

圖 1. MemOS 項目官網報告的性能表現

在大型語言模型(LLM)一路狂飆的這幾年,參數規模和算力幾乎成了 AI 能力的代名詞。可當大模型逐漸走進科研、產業和生活,每個人都在問一個更深層的問題:它究竟能不能 “記住” 點什么?

從陪伴式對話、個性化推薦,到多輪任務協作,模型只靠一次推理、一次檢索,遠遠不夠。如何讓 AI 擁有可管理、可遷移、可共享的長期記憶,正在成為新一代大模型應用的關鍵挑戰。

近日,記憶張量(上海)科技有限公司聯合上海交通大學、中國人民大學、同濟大學、浙江大學、中國電信等多家頂尖團隊發布了?MemOS(Memory Operating System),一套面向大模型的工業級記憶操作系統。它的技術路線起步于 2024 年團隊推出的 Memory3(憶立方)記憶分層大模型 —— 當時首次提出了記憶分層的概念,讓模型可以把部分知識 “外化” 存儲,減少推理成本,也為后續的長期學習打下基礎。

項目官網:https://memos.openmem.net

項目論文:https://memos.openmem.net/paper_memos_v2

代碼倉庫:https://github.com/MemTensor/MemOS

Discord 討論組:https://discord.gg/Txbx3gebZR

OpenMem 社區聯系郵箱:contact@openmem.net

與傳統 RAG 或純參數存儲不同,MemOS 把 “記憶” 看作一種和算力同等重要的系統資源。它通過標準化的?MemCube?記憶單元,將明文、激活狀態和參數記憶統一在同一個框架里進行調度、融合、歸檔和權限管理。簡單來說,模型不再只是 “看完即忘”,而是擁有了持續進化和自我更新的能力。

在行業看來,這種面向 AI 長期記憶的操作系統思路,或許會重塑智能系統的應用邊界 —— 讓大模型真正從 “靜態生成器”,變成可以陪伴用戶長期成長的 “數字同事” 和 “數字助理”。

圖片

圖 2. MemOS 項目官網 https://memos.openmem.net/?

系統架構和核心創新

圖片

圖 3. MemOS 框架(源自 MemOS 官網)

在技術實現層面,MemOS 借鑒了傳統操作系統的分層架構設計,也融合了 Memory3(憶立方)大模型在記憶分層管理方面的核心機制。整個系統由?API 與應用接口層、記憶調度與管理層、記憶存儲與基礎設施層三大核心層次組成,構建了一套從用戶交互到底層存儲的全鏈路記憶管理閉環。

在?API 與應用接口層,MemOS 提供了標準化的 Memory API,開發者可以通過簡單的接口實現記憶創建、刪除、更新等操作,讓大模型具備易于調用和擴展的持久記憶能力,支持多輪對話、長期任務和跨會話個性化等復雜應用場景。

圖片

表 1. 從計算機操作系統到記憶操作系統

在記憶調度與管理層,MemOS 提出了記憶調度(Memory Scheduling)的全新范式,支持基于上下文的?“下一場景預測”(Next-Scene Prediction),可以在模型生成時提前加載潛在需要的記憶片段,顯著降低響應延遲、提升推理效率。

如圖 4 所示,MemOS 通過在不同的 Round、Session 或者 Agents 流程之間,異步對應用所需的潛在記憶進行預測與推薦,實現?Next-Scene Prediction。具體地,MemOS Scheduler 通過在應用的不同位置埋觸發點(Trigger),不斷搜集和匯總記憶需求。觸發器生產的這些記憶需求會被添加到調度器的監控隊列(Monitoring Queue)中,以供調度執行器(Scheduling Executor)去消費,從而將高頻、高相關的記憶提前預備到?MemCube 中合適的位置(或 KV Cache 緩存、或明文工作區記憶存儲等)去,大幅加速潛在的推理時間,提升記憶召回的準確性和效率。

圖片

圖 4. ?記憶調度的核心思路

而在記憶存儲與基礎設施層,MemOS 通過標準化的?MemCube?封裝,將明文記憶、激活記憶和參數記憶三種形態有機整合。它支持多種持久化存儲方式,包括 Graph 數據庫、向量數據庫等,并具備跨模型的記憶遷移與復用能力。

整體來看,MemOS 不僅在技術框架上實現了對 AI 記憶的結構化、系統化管理,也為未來構建可共享、可遷移、可演化的 AI 記憶生態奠定了基礎。

圖片

圖 5. 標準化 MemCube(記憶立方體)的基礎構成

應用場景

在應用層面,MemOS 的推出為大模型在未來多個關鍵場景中帶來了全新的能力突破:

  • 個性化智能體:MemOS 可以持續積累和管理用戶的偏好、歷史對話與行為習慣,讓每一次交互都在 “記憶之上” 不斷優化體驗,真正實現長期陪伴和個性化服務。
  • 科研與知識管理:在科研場景中,MemOS 支持將分散的項目資料、筆記、分析結果以結構化方式長期保存和動態調用,幫助研究人員打造具備深度 “記憶力” 的智能助手,提升知識管理效率和研究連續性。
  • 高可靠性場景:在金融、法律等對溯源和合規要求極高的領域,MemOS 將提供記憶溯源與權限審計功能,使模型的推理結果可以精準追溯到具體知識來源,增強透明度和可信性。
  • 企業級 RAG 應用:在企業級檢索增強生成(RAG)場景,MemOS 能夠有效解決新舊知識混用、信息沖突等問題,確保模型在多輪對話和長周期任務中依然保持穩定、一致的回答能力。

憑借對三類記憶的統一調度與封裝,MemOS 不僅顯著提升了模型的智能性和靈活性,也為企業構建安全、可控、持續演進的 AI 應用奠定了基礎。

接下來,MemOS 團隊將上線?Playground?功能,面向開發者和企業用戶開放體驗,直觀展示在多樣化任務中,記憶能力帶來的性能提升和應用潛力。

圖片

圖片

圖 6 . MemOS Playground 即將上線測試

開源框架

圖片

圖 7. 項目開源地址:https://github.com/MemTensor/MemOS

作為一套完全開源的工業級框架,MemOS 的設計理念強調?“標準化、模塊化、可組合”,面向開發者提供了清晰且易于集成的架構和工具鏈。

在 GitHub 公開的 Preview 版本中,MemOS 已實現包括 Memory API、核心調度模塊(MemScheduler)、樹 - 圖狀的明文記憶管理、KV Cache 激活記憶管理在內的多個關鍵功能,并提供了詳盡的示例代碼和演示腳本,幫助開發者快速上手,靈活構建具備持久記憶能力的智能應用。

圖片

圖 8. pip install MemoryOS 一鍵安裝使用

該框架遵循分層解耦的設計原則,所有核心能力均以?Python 類和 REST 接口兩種形式對外開放,既可用于輕量級本地測試,也能與生產環境下的大模型(如 HuggingFace、OpenAI、Ollama 等)實現無縫集成。

未來,MemOS 將持續完善記憶生命周期管理、參數記憶插拔、跨平臺記憶遷移等高級功能,并通過?MemCube 標準支持 “Memory-as-a-Service”(記憶即服務)的部署模式,幫助開發者和企業在不同場景下靈活構建具備持久記憶的 AI 系統。

MemOS-Preview 版本性能詳細評估

在當前版本中,MemOS 重點評估了框架在對話類場景下的記憶抽取與檢索效率,并采用行業公認的?LoCoMo(Long Conversational Memory)Benchmark?進行測評(Maharana A, Lee D H, Tulyakov S, et al. Evaluating Very Long-term Conversational Memory of LLM Agents. ACL, 2024)。

LoCoMo 評估集合由 Maharana 等人于 2024 年提出,并發表于 ACL 2024,旨在系統評估和強化 LLM 對極長對話歷史的記憶能力。目前,該基準已經成為包括 Mem0、Zep 等多種記憶管理框架的標準化測評工具。

本次評估主要考察模型在以下四項任務中的表現:

  • 單跳任務評估(Single Hop):測試模型在已知上下文中對單一事實的直接回憶能力。
  • 多跳任務評估(Multi Hop):考察模型能否通過多輪推理整合分散信息。
  • 開放問題評估(Open Domain):評估模型在非限定問題上的記憶準確性和靈活性。
  • 時序推理任務(Temporal Reasoning):檢驗模型處理事件順序和時間邏輯的能力。

當前 MemOS-Preview 版本在以上任務中的詳細評估結果如下表 2:

圖片

表 2. LoCoMo 端到端實驗性能對照表

從評估結果來看,MemOS-Preview-0630 版本相比 OpenAI 的全局記憶方案,在性能表現和 Tokens 開銷方面均實現了全面提升。

與 Mem0(本次評測采用 Mem0 官方提供的 Pro 版本高性能接口)相比,MemOS 在各項核心指標上也取得了顯著進步。特別是在時序推理這一對記憶系統要求最高的任務上,MemOS 相較 Mem0 和 OpenAI 均實現了超過?20% 絕對值的性能提升,最高超過 159% 的相對值的提升,進一步驗證了其在復雜對話和長期推理場景中的優勢。

圖片

圖 9. MemOS 各項性能指標隨召回 TOP-K 數量的消融實驗

在記憶管理場景中,召回記憶的數量(TOP-K 值)以及對應的總 Context 長度,直接決定了框架的檢索效率和推理性能。通常而言,框架效率越高,就越能夠在相對較小的召回容量下取得最準確的回憶結果,從而顯著降低 Tokens 的編碼開銷。

如圖 9 所示,MemOS 在召回區間?TOP-20 左右時,僅需約?1000 個 Tokens?的上下文長度,即可在各項評估指標上取得優異表現。相比之下,對照組在達到相似準確度時,通常需要?2000–4000 Tokens?的召回區間,MemOS 在保證效果的同時大幅減少了檢索所需的輸入規模和推理負擔。

圖片

表 3. 檢索效率評估

此外,為了系統評估當前開源框架在檢索時效性方面的表現,MemOS 團隊針對原始 RAG 框架和現有多種記憶管理方案開展了全面的消融實驗。

從表 3 中的結果可以看出,MemOS-Preview 開源版本的檢索性能已接近多個主流商業化記憶管理框架的 API 接口,并在最終效果得分上實現了顯著提升。值得注意的是,在部分評測任務中,MemOS 的表現甚至優于 Full-Context 方案,展現出在高效記憶管理與資源利用之間的良好平衡能力。

圖片

表 4. 記憶調度場景 KV Cache 復用的加速性能實驗

同時,為了進一步評估?MemOS-Preview 版本在調度場景下的記憶緩存復用功能,作者圍繞不同模型規模和輸入長度,對緩存復用的性能進行了詳細的消融實驗。 ??

實驗設置包括:在不同輸入長度的緩存上下文條件下,測量推理過程的加速比;以及在不同參數規模的模型上,評估緩存復用對性能的提升效果。

從表中結果可以看出,隨著模型規模的增大和緩存上下文長度的增加,相比無緩存場景,推理加速比顯著提高。在長記憶場景下,TTFT(Time To First Token)加速比超過 70%,顯示出緩存復用在大規模推理任務中的明顯優勢。

這些實驗結果表明,對于需要長期和高頻訪問的記憶內容,構建高效的緩存復用模塊對于提升記憶解碼性能和整體響應速度具有重要價值。

MemOS 的未來發展計劃

圖片

圖 10. MemOS 歷史研發 Milestone

🌟 關鍵計劃一:成立 OpenMem 開源社區

MemOS 團隊計劃發起?OpenMem?開源社區,面向全球研究機構和產業伙伴,共同打造一個開放、協作、共創的大模型記憶技術生態。該社區將重點推動記憶管理、記憶增強、記憶共享等領域的研究與應用,探索讓 AI 記憶能力實現可管理、可遷移、可共享的發展路徑。OpenMem 歡迎所有對 AI 模型記憶感興趣的團隊加入,共建開放記憶底座,賦能智能系統普惠未來。聯系方式:contact@openmem.net

🌟 關鍵計劃二:應用發展與聯合開發計劃

未來,MemOS 將與智能體(Agent)研發團隊、行業業務團隊和技術合作伙伴共同發起聯合開發計劃,推進基于記憶操作系統的多樣化應用落地。相關計劃將聚焦對話機器人、智能搜索、個人助理、企業知識管理等典型場景,探索長期記憶、多主體協作、個性化演進的應用模式,助力智能系統在復雜動態環境中實現持續進化和價值創造。

🌟 關鍵計劃三:MemOS 的長期迭代與研發

在長期研發方面,MemOS 將持續推進技術演進和版本迭代,重點聚焦記憶表征與壓縮、分布式記憶調度、跨模型記憶轉移、可解釋性與安全性保障等關鍵方向。未來,MemOS 還將逐步完善標準化接口、性能優化、合規治理等體系,打造面向大規模生產環境的高可用、低成本、強安全的記憶操作系統。團隊計劃持續深化與學術界和產業界的合作,推動 AI 從靜態生成走向長期進化與持續學習的新階段。

記憶張量簡介:記憶張量(上海)科技有限公司是上海算法創新研究院孵化的新型大模型公司,由中科院院士擔任首席科學顧問。公司聚焦基本原理驅動的系統性創新,以 “低成本、低幻覺、高泛化” 為核心特色,致力于探索符合中國國情的大模型發展新路徑,推動 AI 應用更廣泛落地。公司持續圍繞大模型記憶增強與管理框架進行技術迭代,自主研發的基于記憶分層架構的 “憶 3” 大模型已實現商業化落地,業務穩步增長,獲得招商證券、中國銀行、中國電信等頭部國央企業認可。

#Stream-Omni

同時支持各種模態組合交互的文本-視覺-語音多模態大模型

GPT-4o式的多模態大模型(LMMs)展現出在文本、視覺和語音模態上的全能能力,其在線語音服務還能在語音交互過程中同步提供中間文本結果(即用戶輸入和模型響應的轉錄內容),為用戶提供“邊看邊聽”的靈活交互體驗。因此,如何構建支持文本、視覺和語音三種模態的多模態大模型成為近期研究熱點。現有的多模態大模型通常利用多個編碼器提取各個模態的表示,然后將各模態表示沿序列維度拼接并輸入至大語言模型基座中以生成回復。這些基于拼接的方法簡化了模態集成過程,但它們在很大程度上依賴大規模數據,以數據驅動的方式學習模態對齊。此外,這種基于拼接的維度對齊方式缺乏足夠的靈活性,無法像?GPT-4o?那樣在語音交互過程中同時生成中間文本結果。

圖片

為應對這一挑戰,中國科學院計算技術研究所自然語言處理團隊提出了文本-視覺-語音多模態大模型——Stream-Omni,其能同時支持各種模態組合下的交互。通過對各模態間的關系進行更有針對性的建模,Stream-Omni實現了更加高效和靈活的文本-視覺-語音模態對齊。僅依賴包含2.3萬小時語音的多模態數據,Stream-Omni即可具備文本交互、語音交互、基于視覺的語音交互等各種模態上的交互能力。與此同時,依賴于創新的語音建模方式,Stream-Omni能在語音交互過程中像GPT-4o一樣同步輸出中間文本轉錄結果,為用戶提供全方位的多模態交互體驗。

  • 論文題目:Stream-Omni: Simultaneous Multimodal Interactions with Large Language-Vision-Speech Model
  • 論文鏈接:https://arxiv.org/abs/2506.13642
  • 開源代碼:https://github.com/ictnlp/Stream-Omni
  • 模型下載:https://huggingface.co/ICTNLP/stream-omni-8b

Stream-Omni的模態對齊

圖片

現有多模態大模型中的模態對齊(如左圖所示):在序列維度上將三種模態的表示進行拼接,輸入至大語言模型基座

為了減輕對大規模三模態數據的依賴,Stream-Omni更有針對性地建模各模態之間的關系,即語音與文本應在語義上高度一致,而視覺則在語義上對文本形成互補關系。因此,Stream-Omni對不同模態采用不同對齊方式(如右圖所示):

  • 視覺-文本對齊:序列維度的視覺文本拼接
  • 語音-文本對齊:層級維度的語音文本映射

實現上,Stream-Omni?以大語言模型(LLM)為核心,并在其底部和頂部引入語音層,通過連接時序分類(Connectionist Temporal Classification,CTC)建模語音到文本的映射,此建模方式的優勢在于:

  • 支持通過語音模態進行外部交互,同時利用文本模態在內部控制生成的內容;
  • 基于CTC的語音-文本映射為語音文本在表示和結構的對齊上提供更加直接的監督,因此Stream-Omni 能夠在僅使用少量語音數據的情況下,將 LLM 主干的文本能力遷移至語音模態。
  • 層級維度映射使得Stream-Omni?在語音交互過程中還能同步輸出中間文本結果(即指令和回復的轉錄文本),為用戶提供更全面的多模態體驗。

Stream-Omni

圖片

Stream-Omni以大語言模型作為主干,逐步將視覺和語音與文本對齊,高效地構建了一個支持文本、視覺和語音的多模態大模型。在視覺-文本對齊方面,Stream-Omni采用視覺編碼器和投影模塊提取視覺表示,并將其與文本表示進行拼接。在語音-文本對齊方面,Stream-Omni在?LLM?主干的底部和頂部分別引入若干語音層,用于將語音映射到文本以及基于文本生成語音。

視覺模態

基于視覺模態與文本模態之間具有語義互補性,Stream-Omni?采用LLaVA架構中的序列維度拼接的方式進行視覺-文本對齊。

語音模態

(1)語音離散化:Stream-Omni采用CosyVoice Tokenizer對語音輸入進行離散化,編碼為若干離散的語音單元(<Audio_72>< Audio_965>…)。

(2)語音到文本映射:為了充分利用LLM的能力,Stream-Omni在LLM的底部引入語音層,用于學習語音與文本之間的映射關系,從而將?LLM?中的文本能力遷移到語音模態中。Stream-Omni利用在ASR任務上的CTC損失直接監督底部語音層語音表示,將其與文本模態對齊。

(3)文本生成:LLM基于輸入的視覺表示和語音表示,生成文本回復。

(4)文本到語音生成:Stream-Omni通過頂部語音層來完成文本到語音生成。為了在生成文本的同時生成語音單元,Stream-Omni在頂部語音層中引入了alignment-based fusion模塊。Alignment-based fusion沿用了StreamSpeech等實時生成研究中的同步生成策略,利用CTC對齊來指導同步生成過程。

任意模態組合下的多模態交互

Stream-Omni能夠通過靈活組合視覺編碼器、底部語音層、LLM、頂部語音層來實現任意模態組合下的交互。同時,由于層級維度語音文本映射,Stream-Omni能夠在語音到語音生成過程中提供中間的文本結果。

實驗結果

視覺理解能力

圖片

Stream-Omni和相同規模和數據量級的視覺大模型取得相當的表現。

語音交互能力

圖片

在事實性的語音交互上,Stream-Omni相比于現有方法具有優勢,源于層級維度的語音文本映射將LLM的文本能力遷移到語音模態上。

基于視覺的語音交互能力

圖片

在本實例中,在指令分別通過文本和語音輸入的情況下,VITA-1.5?給出了兩個相互矛盾的回答:“不允許前往二樓”和“直接通往二樓”。這一在面對不同模態指令時產生的矛盾回應,源于沿序列維度拼接視覺、語音和文本表示來實現多模態對齊的方法,并未對語音與文本模態之間的語義進行嚴格對齊建模。相比之下,Stream-Omni?引入語音到文本的映射機制,實現了語音與文本表示之間更精確的語義對齊。因此,Stream-Omni?在不同模態下表現更加一致,無論指令是通過文本還是語音輸入,都能生成相似的響應。另外,Stream-Omni還能生成高質量的語音回復,更多實例請在https://github.com/ictnlp/Stream-Omni體驗。

總結

  • Stream-Omni是一個GPT-4o式的文本-視覺-語音多模態大模型,能夠支持多種模態組合下的多模態交互。
  • Stream-Omni能夠在語音交互過程中輸出中間文本結果,為用戶提供更全面的多模態交互體驗。
  • Stream-Omni關注如何構建模態對齊,語音表現力等方面的增強不是本研究的重點,因此其在擬人化、音色多樣性等方面存在局限性。

#基于能量的 Transformer(Energy-Based Transformers, EBTs

新范式來了!新能量模型打破Transformer++擴展上限,訓練擴展率快35%

是否可以在不依賴額外監督的前提下,僅通過無監督學習讓模型學會思考? 答案有了。

在心理學領域,人類思維通常被劃分為兩種不同類型:系統 1(快速思維)和系統 2(慢速思維)。

當面對復雜問題如數學運算、多步驟推理等任務時,系統 2 思維(System 2 Thinking)顯得至關重要。然而,當前的大語言模型可能在適合系統 1 思維的任務上表現良好,但在需要系統 2 思維能力的任務方面仍存在明顯不足。

因此,很多研究者開始對系統 2 思維展開研究,這推動了 o1、R1、Grok3 和 Claude 3.7 Sonnet 等基礎模型的崛起。

但據公開訓練資料(特別是開源模型 R1)顯示,這些模型采用的強化學習訓練方法僅適用于答案可通過規則化獎勵驗證的領域(如數學和編程),這種局限性導致其適用范圍狹窄。

另一方面與人類系統 2 思維類似的推理時計算,近期成為提升模型性能的熱門方法。

然而,現有方法存在三大局限性:模態依賴性(如僅適用于文本)、問題依賴性(如局限于數學 / 編程等可驗證領域),或需要額外監督訓練(如驗證器或可驗證獎勵機制)。

因此,來自弗吉尼亞大學、亞馬遜 GenAI、斯坦福大學、哈佛大學的研究者探討了這樣一個問題:「能否泛化這類系統 2 思維方法,開發僅通過無監督學習就能自主思考的模型?」

答案是肯定的。

具體來說,該研究訓練了一類新的能量模型 ——?基于能量的 Transformer(Energy-Based Transformers, EBTs),它可以為每一對輸入和候選預測分配一個能量值(即非規范化的概率); 然后從一個隨機初始化的預測開始,通過梯度下降不斷優化,直到找到最低能量的預測; 這一優化過程就模擬了思考過程。與傳統 Transformer 僅單次前向推理不同,EBT 允許每個預測思考多步。?

這一建模方式使得系統二思維能夠在無監督學習中自然涌現,從而具備跨模態、跨任務的通用性。

在離散模態(如文本)和連續模態(如圖像)中,本文發現 EBT 在訓練過程中比主流的 Transformer++ 方法具備更快的擴展速度 —— 在數據量、批次大小、參數規模、FLOPs 和網絡深度等方面,EBT 的擴展速率最高可提升 35%。

在推理階段,通過引入系統二思維(即增加計算量),EBT 在語言任務中的性能提升比 Transformer++ 高出 29%。

在圖像去噪任務中,EBTs 也優于擴散 Transformer(Diffusion Transformers),且所需的前向傳播次數更少。

此外,本文還發現,當處理分布外數據時,引入系統二思維的 EBT 帶來的性能提升更為顯著;即便在預訓練效果相同或更差的情況下,EBT 在大多數下游任務上的表現仍優于現有模型,表明其具備更強的泛化能力。

因此,EBT 為擴展模型的學習能力與思維能力提供了一種極具前景的新范式。

論文地址:https://arxiv.org/pdf/2507.02092

論文主頁:https://energy-based-transformers.github.io/

論文標題:Energy-Based Transformers are Scalable Learners and Thinkers?

基于能量的 Transformers (EBT)?

能量模型(EBMs,Energy-Based Models)背后的核心思想是:能量越低的配置,其概率越高、彼此之間越兼容;而能量越高的配置,其出現的可能性越低、彼此之間越不協調。

更具體地說,EBM 的目標是學習一個能量函數(即將輸入映射為一個標量能量值;在本文中,能量函數就是整個神經網絡本身),這個函數會為正確或理想的配置(例如真實數據點)分配較低的能量,而為錯誤或不理想的配置(例如噪聲)分配較高的能量。?

例如,如果給定的上下文是一段狗奔跑著去接飛盤的視頻,那么高能量的延續可能是一段狗在啃玩具的視頻,而低能量的延續則可能是狗成功接住飛盤的片段。狗接住飛盤的場景與前面的上下文更為契合,因此對應的能量更低。?

image.png

在這些 EBM 中,思考過程可以通過從一個初始的(隨機的)預測開始,并通過梯度下降不斷最小化其能量來優化這個預測(如上圖所示)來實現。

為了實現高度可擴展性,本文設計了一種結合 Transformer 架構和可擴展訓練算法的特定類型的能量模型,稱為 EBT。EBT 具備高效的訓練性能、良好的穩定性以及并行處理能力。

image.png

可擴展的 EBM Thinking

本文發現有三種關鍵的能量曲面正則化技術在訓練過程中至關重要,它們能夠有效確保所學習到的能量曲面具有足夠的平滑性與凸性,從而使模型在訓練階段具備強大的思考能力。?

首先,本文發現重放緩沖區(replay buffer)有助于模擬更長的優化軌跡,使得能量 landscapes 在其最小值附近得到良好定義。

其次,一種 Langevin 動力學變體(隨機噪聲),被發現有助于鼓勵能量 landscapes 的探索。

第三,通過隨機化梯度下降步長 α 和優化步數,改變通向預測解決方案的路徑,顯著提高了泛化能力。

這些技術共同提高了模型的系統 2 思維能力,這一點通過表 2 中的消融實驗得到了證實。

EBT 架構

Transformer 在眾多領域中展現出卓越性能,其包括三大優勢:高度可并行化、訓練過程穩定性,以及良好的可擴展性。

而 EBM 在這三個方面一直面臨挑戰,因此,Transformer 架構為提升 EBM 的可擴展性提供了理想的基礎。

為推動 EBM 范式的發展,本文引入了 EBT,即專為能量模型設計的 Transformer 架構實現。本文設計了兩種變體:

  • 一種是僅使用解碼器的 EBT,受 GPT 架構啟發,適用于自回歸建模;
  • 另一種是雙向 EBT,在序列中使用雙向注意力機制,支持 infilling 和掩碼建模等任務。

實現細節可以參考 C.3 節。

實驗及結果

本文實驗關注兩類核心結果:

  • 首先是學習的可擴展性,即模型擬合預訓練數據的速度,這也是預訓練研究中的標準評估方式;
  • ?其次是思考的可擴展性,即隨著系統 2 思維能力的增強,模型性能的變化趨勢。

與模型學習速度相關的規模化趨勢,通常被稱為擴展律(Scaling Law),是比較難以測量的。

最近一項調查發現,觀察到的擴展率取決于多種實現細節和測量維度,往往導致多個不同的結論。

因此,為了盡可能全面地確定 EBT 與 Transformer++ 的擴展方式,該研究針對六個不同測量維度 —— 包括數據、批處理大小、深度、參數、FLOPs,以及嵌入維度。

image.png

圖 4:語言學習擴展性 —— 數據、批大小和深度。

該研究對比了 Transformer++ 方法與 EBT 模型在預訓練階段的可擴展性表現,考察維度包括訓練數據量、批大小及模型深度。

結果表明,在上述所有維度上,EBT 的擴展能力均顯著優于 Transformer++,顯示出更高的數據利用效率,并表明其在泛化能力方面具有潛在優勢。

此外,EBT 在模型深度上的擴展性能提升,亦為其在推理任務中的表現提供了可能性支持。

綜上結果表明,若這一擴展趨勢持續存在,則在基礎模型所需的數據規模下,EBT 有望全面超越 Transformer++ 模型。

image.png

圖 5:語言學習可擴展性 —— 參數、FLOPs 和寬度。

Transformer++ 方法與 EBT 在模型大小(參數)、計算(FLOPs)和寬度(嵌入維度)上的預訓練擴展性比較。EBT 在 FLOPs 和參數擴展性上略微優于 Transformer++,成為首個在不修改分詞器的情況下實現更高擴展率的方法。結果表明,隨著規模的增加,EBT 在參數和 FLOPs 效率方面作為預訓練范式具有很高的潛力。

在所有測量維度上,EBT 的擴展性能始終優于 Transformer++ 方法(即具有更高的擴展率),并成為首個在不更換分詞器的前提下實現這一突破的模型。

這些結果表明,與 Transformer++ 方法相比,EBT 在數據效率、批大小效率、參數效率、深度效率和計算效率方面都更高。

因此,在使用規模擴大 1,000 倍的數據和參數量擴大 1,000 倍的模型訓練現代基礎模型的情境下,預期 EBT 的預訓練性能將顯著優于 Transformer++ 方法。

在已有學習結果的基礎上,該研究進一步探討了 EBT 模型在推理階段的思考能力。研究發現,EBT 的思維能力在足夠大規模的數據訓練下開始顯現。鑒于資源限制,該研究主要在小規模模型(但訓練數據量充足)上開展相關思維能力實驗。

該研究從兩個維度評估模型的「思考能力」:一是延長思考時間,即增加優化步數;二是自我驗證,即生成多個候選預測,并從中選擇能量最小的預測結果。

在表 2 中,通過消融實驗驗證了該研究提出的能量 Landscape 正則化技術(Energy Landscape Regularization techniques)在 BigBench Dyck Languages 基準測試的分布外數據上提升系統 2 思維能力的有效性。

實驗結果表明,當結合延長思考和自我驗證機制時,應用全部正則化技術可以獲得最優的系統 2 思維表現。

此外,實驗還發現:步長隨機化是關鍵因素之一 —— 若移除該機制,模型的思維能力幾乎完全喪失;而關閉 Langevin 動力學則會削弱組合性能,但在無自我驗證條件下反而表現更佳,體現出性能與計算資源之間的權衡關系。

image.png

表 2:系統 2 思維消融實驗。

Thinking Longer 指更多優化步驟,Self-Verification 指優化多個預測并選擇最佳結果。加粗部分突出顯示默認系統 2 超參數,利用所有在 3.3 節中描述的能量 Landscape 正則化技術。

這種配置在 Thinking Longer 和 Self-Verification 時性能最佳。移除正則化,如 Langevin 動力學,會導致更少的能量 Landscape 探索,從而在犧牲 Self-Verification 性能的情況下提升單路徑性能(Thinking Longer)。

在驗證了上述能量 Landscape 正則化技術的重要性后,該研究進一步分析了 EBT 模型在思考能力方面的可擴展性。結果帶來了兩個主要發現:

首先,如圖 6 (a) 所示,EBT 模型通過增加前向傳播次數(即延長思考時間)可實現高達 29% 的性能提升,而 Transformer++ 在相同條件下的性能幾乎沒有任何提升。

這一現象驗證了傳統的前饋式 Transformer 無法根據每個預測任務動態分配額外的計算資源,因此也就無法通過「延長思考時間」來提升每個 token 的預測性能。

image.png

圖 6:EBT 思維分析。

其次,如圖 6 (b) 所示,EBT 的「思考能力」具有良好的可擴展性。具體而言,隨著訓練時間的增加,EBT 從自我驗證中獲得的性能提升也在持續增長:自我驗證帶來的增益從原先的 4%–8% 提升至 10%–14%。

這表明,若將 EBT 模型擴展到與當前主流基礎模型相同的訓練規模(例如 Llama3 所使用的 15 萬億 tokens,約為當前數據規模的 1000 倍),其自我驗證機制所帶來的性能提升將更為顯著。

最后,該研究可視化了 EBT 在預測 token 時對不確定性的表達能力。結果表明:對于預測難度較低的 token(如 the 或 but),EBT 能更快地優化至較低能量;而對于預測難度較高的 token(如 fox 或 problem),其對應的能量更高,且在多個步驟中未能收斂。

這說明在預訓練過程中,EBT 能夠學習并捕捉 token 預測難度的不確定性,從而實現對系統 2 中方面 2 的有效建模。

image.png

圖 8:文本中的不確定性學習結果。

EBT 模型在無任何顯式監督的情況下,能夠自動學習在不同文本 token 上的不確定性差異。例如,在圖 (a) 和 (b) 中可以觀察到,諸如 is、a、but 和 the 等簡單 token 在推理階段的優化過程中(即「思考」步驟)表現出較低的能量值,表明模型對此類 token 的不確定性較低。相比之下,諸如 quick、brown、research 和 problem 等難以預測的 token 在多個優化步驟中具有更高的能量,且能量難以收斂,說明模型對這些 token 的預測存在更高的不確定性。

鑒于人類的系統 2 思維與在新場景中的泛化能力密切相關,該研究設計了一組實驗,旨在直接評估 EBT 模型的系統 2 思維機制對泛化能力的影響。

如圖 7 所示,該研究可視化了 EBT 在多個數據集上的表現,這些數據集具有不同程度的分布外(OOD)偏移,該偏移通過下游任務困惑度與預訓練困惑度的比值進行量化。

實驗結果顯示出明顯的線性趨勢:隨著數據的分布偏移程度增加,思考機制帶來的性能提升也越顯著。因此,這一發現表明,EBT 的「思考」優勢并非在所有數據上均勻表現,而是隨著分布偏移程度的增強而增強,凸顯了「思考」機制在跨分布泛化任務中作為關鍵能力的作用。

這一發現亦與心理學中的觀察一致:人類在應對復雜的分布外任務時,通常依賴于更為深度和刻意的系統 2 思維過程。

image.png

圖 7:OOD 思考性能。隨著數據變得越來越 OOD,思考帶來的性能提升更加顯著,呈現大致線性的趨勢。

由于已在圖 4 和圖 5 中驗證了 EBT 模型相較于 Transformer++ 擁有更優的擴展性,因此有理由推測,EBT 在大規模訓練條件下也可能在下游任務中表現更佳。

為驗證這一假設,該研究對訓練設置完全相同的模型進行了比較,其中 EBT 模型在預訓練階段的困惑度略高于 Transformer++。然而,如表 3 所示,盡管 EBT 的預訓練困惑度稍差,但其在大多數下游任務上的困惑度更低(即性能更優),表明其具有更強的泛化能力,尤其是在應對分布外(OOD)數據方面表現更為突出。

結合此前關于學習可擴展性的優勢結果,以及已有研究表明,更好的預訓練表現通常會轉化為更優的下游任務性能,上述實驗證據共同表明,在大規模訓練情境下,EBT 會全面超越 Transformer++。

image.png

表 3:語言模型任務泛化比較。

盡管在預訓練階段困惑度略高,EBTs 在下游任務上的困惑度通常低于 Transformer++。這表明 EBT 比 Transformer++ 泛化能力更強。此外,由于 EBT 在預訓練階段比 Transformer++ 擴展性更好(圖 4),這些發現表明 EBT 在基礎模型規模上會優于 Transformer++。

圖 9 展示了嵌入維度(embedding dimension)和非嵌入參數量(non-embedding parameter count)兩個維度上的擴展性結果,這兩個維度表現出最為線性的擴展趨勢。實驗結果表明,盡管 EBT 模型在初始階段的損失值更高,但其擴展速度比 Transformer++ 快超過 33%。這一發現表明,在基礎模型規模下,EBT 會獲得顯著優于 Transformer++ 的性能表現。

image.png

圖 9:視頻學習可擴展性 —— 寬度與參數。在 Something Something V2(SSV2)數據集上達到的最小驗證損失。

雖然 EBT 在較小規模時驗證損失高于 Transformer++,但擴展率提高 33% ,表明在擁有數百億參數的基礎模型規模上,EBT 的表現將遠優于 Transformer++。值得注意的是,相對于參數數量,嵌入維度的擴展行為更接近線性,這可能是嵌入維度成為圖像表示的瓶頸所致。

為進一步驗證上述觀點,該研究在圖 11 中可視化了 EBT 模型在預測視頻幀時的能量變化結果。實驗結果表明,EBT 能夠有效學習并表征預測過程中的不確定性:在視頻的早期幀中,由于畫面中尚未出現主要物體,模型預測的能量較高(即不確定性較強);隨著場景中的主要物體逐漸顯現,EBT 對后續幀的預測能量顯著降低,表明模型不確定性隨之減少。

image.png

圖 11:視頻結果中的學習不確定性。與認知方面 2 一致,EBT 能夠在沒有監督的情況下,在連續視頻幀中表達不確定性。

在視頻開始時,不確定性較高(高能量),因為幀大部分是空的,場景高度不可預測。當一件藍色服裝被放置到幀中時,不確定性降低(低能量),反映了場景的可預測性增加。當藍色服裝從場景中移除時,不確定性再次增加,表明不可預測性恢復到較高水平。這種能力在沒有離散化方案的傳統前饋 Transformer 的連續空間中實現起來要困難得多。

表 4 展示了 EBT 與 DiT 模型在圖像去噪任務中的性能對比結果。觀察到,在分布內與分布外圖像去噪的多個評價指標上,EBT 均優于 DiT,峰值信噪比(PSNR)最高提升可達 3.5。

image.png

表 4:圖像去噪與分類對比。

在圖像去噪方面,EBTs 在分布內(in-distribution)和分布外(OOD)數據上的峰值信噪比(PSNR)以及均方誤差(MSE)上均顯著優于 DiT ,同時使用減少 99% 的正向傳遞次數。

這表明 EBT 比 DiT 泛化能力更強,同時計算量更少。在圖像分類方面,EBT 的表現也優于 DiT ,準確率提高了 10 倍 ,這表明 EBT 學習到的圖像表征更好,比 DiT 更理解圖像。

該研究還在圖 12 中繪制了不同前向傳播次數(即函數評估次數,Number of Function Evaluations, NFEs)下的模型性能曲線。結果表明,EBT 在使用比 DiT 少 99% 的去噪步驟的情況下,仍實現了更優的去噪效果,并且其系統 2 思維的擴展速率也明顯高于 DiT。

image.png

圖 12:圖像去噪任務中的思考可擴展性分析。

該研究比較了 EBT 與 DiT 在圖像去噪任務中,在不同前向傳播次數下的表現。結果顯示,EBT 僅需 DiT 所用前向傳播次數的 1%,即可達到相當甚至更優的峰值信噪比(PSNR)水平。

此外,隨著前向傳播次數增加,EBT 在 PSNR 上的性能提升速率遠高于 DiT。這一結果表明,在處理分布外(OOD)圖像去噪任務時,EBT 的思考能力明顯優于 DiT。

image.png

圖 10:定性 OOD 圖像去噪。

圖 10 展示了 EBT 與 DiT 基線模型在分布外圖像去噪任務中的視覺效果對比。結果進一步表明,EBT 所生成的去噪圖像在視覺質量上明顯優于 DiT,同時計算成本更低。

在推理階段,EBT 模型在每使用 1 次去噪步驟的情況下,便可達到與 DiT 需執行 100 次去噪步驟相當甚至更優的效果。整體而言,EBT 所生成的去噪圖像質量更高,圖像更清晰,模糊程度明顯低于 DiT 去噪結果。

#deepseek技術解讀(3)-MoE的演進之路

0. 引言

本篇講講deepseek在MoE(Mixture-of-Experts)上的演進過程。DeepSeek是MoE稀疏模型的忠實玩家。主版本模型從DeepSeekMoE(V1) 到 DeepSeek V3,一直堅持走MoE的技術路線,并且持續做出一些創新。本文參考paper并結合源碼閱讀,理解MoE的演進過程和具體實現。

1.簡述MoE的發展歷程

首先我們簡單回顧下MoE的發展歷史,早在1991年一篇名為《Adaptive Mixtures of Local Experts 》的工作,最早提出了Mixture of Experts的原型框架,如圖1,直至今日,MoE的框架依然保持這種形式。

圖1、Adaptive Mixtures of Local Experts 框圖

MoE(Mixture of Experts)是一種網絡層結構, 網絡層主要包括三部分:

  • 專家網絡(Expert Network):是一個前饋網絡,邏輯上一個專家網絡擅長處理一類專項的子任務,所有專家都接受相同的輸入,來做特定計算處理,產出不同的輸出
  • 門控網絡(Gating Network):跟專家網絡接收一樣的輸入,負責產出專家偏好的權重。來指示對于一個輸入,不同專家的重要程度。
  • 選擇器(selector):是一種根據專家權重來做專家選擇的策略。可以選擇權重最高的Top1專家或選擇TopK專家來融合得到最終的結果。

隨后一段時間,主要是Google在主導著MoE的發展。進入Transformer時代后,2020年Google發表了的《GShard》,也把模型訓到了600B的規模。GShard刻畫了在Transformer上做MoE的經典設計。主要包括Transformer MoE層設計和輔助負載均衡損失。

Transformer MoE層:MoE層替換Transformer的FFN層,計算邏輯:對于一個token 分別通過門控網絡和專家網絡計算門控值和專家輸出,然后用門控值加權多個專家輸出來產出最終結果。具體如下:

  • 門控計算:

圖片

  • 專家計算(專家就是FFN網絡)

圖片

多專家結果加權就和得到MoE的輸出

圖片

注:這里的專家是token級專家,而不是樣本粒度,每個token都會做專家路由。此外專家是稀疏激活的,是根據門控值取topK個專家來融合計算最終的結果。GShard最多激活權重最高的2個專家。

負載均衡-輔助損失:引入負載均衡損失,目的是解決多專家token分布不均的問題。因為如果完全按門控權重選取topk專家,容易導致訓練過程出現負載不均衡的問題。比如:大多數token被分配到少數幾個專家,導致只有少數專家數據通信繁忙造成擁堵,從而減緩訓練速度;也會導致其他專家得不到充分訓練。為了解決這個問題,定義了一個輔助損失(aux_loss)來降低負載不均衡問題。

那么怎么定義負載均衡的輔助損失?

圖片

圖片

圖片

其中為公式(1)針對token s 計算的專家e的門控權重。

那么這里我們再弄清楚兩個問題:

圖片

問題2:這樣近似計算有什么好處?
答:因為計算引入了門控項,計算如公式(1)所示,包括的可學習參數,保證了這個一個可微的計算,可以做梯度更新。

我們用把公式(4)改造下,將平方項的一個分量替換成,如公式(6):

圖片

公式(6)就是我們經常看到的負載均衡loss形式。這里也要注意,對于專家級的負載均衡的loss是加到每個MoE層的,每層都有一個輔助損失。

上面對MoE有了基本的認識,我們接下來看看DeepSeek在MoE方面的工作。

2.DeepSeek的工作2.1. DeepSeek-moe(V1)

24年1月DeepSeek發布V1版MoE模型,作者指出當前方法存在兩方面問題:

  • 知識混合性:現有的MoE模型通常使用數量有限的專家(如8個或16個),由于token的知識是豐富多樣的,將多樣的知識分配給有限的專家,會導致特定專家的token很可能會涵蓋多樣化的知識,而使得專家變成一個雜糅多知識的專家,這樣不能充分發揮專家的專業效果。
  • 知識冗余性:分配給不同專家的token可能存在共同知識。因此,多個專家可能會在其各自的參數中學習到共享知識,從而導致專家參數存在冗余。這種問題也阻礙了現有MoE實踐中專家的專業化,限制了MoE模型的理論上限性能。

針對上述問題,DeepSeek引入一種實現了專家專業化而設計的創新MoE架構。架構主要包含兩方面優化:

  • 細粒度專家分割(Fine-Grained Expert Segmentation):在保持參數數量不變的情況下,作者通過分割FFN中間隱藏維度來將專家分割成更細的粒度。相應地,在保持計算成本不變的情況下,可激活更多細粒度的專家,以實現激活專家組合的更高靈活性。細粒度專家分割使得多樣化的知識能夠被更細致地分解,并更精確地學習到不同的專家中,每個專家將保持更高的專業化水平。
  • 共享專家隔離(Shared Expert Isolation):將某些專家隔離出來,作為始終激活的共享專家,旨在捕獲不同上下文中的共同知識。通過將共同知識壓縮到這些共享專家中,可以減輕其他路由專家之間的冗余,這可以提高參數效率,確保每個路由專家專注于不同方面而保持專業化。

如下圖2所示。(b)是在(a)基礎上,通過將隱層切分更細粒度,而形成細粒度專家,(c)又在(b)基礎上隔離出來共享專家。DeepSeekMoE模型的演進過程,一直延續這兩個創新的設置。

圖2、DeepSeekMoE架構

DeepSeekMoE架構的公式形式:

圖3、DeepSeekMoE計算公式

圖片

除了在模型架構上的改進,隨著DeepSeek從V1 到 V3的演進,在負載均衡上,做了較多工作。首先看看 V1的負載均衡的優化,主要在計算負載均衡上做了優化,包括兩個負載均衡的設置:

1.專家級負載loss(Expert-Level Balance Loss)

loss計算如下所示

圖4、Expert-Level Balance Loss 計算

圖片

我們仔細看下如上公式,針對上述公式(13)的的計算,稍微有些不好理解。如果參照第一節公式(6),計算應該如下:

圖片

公式(13)相比公式(15),分子多乘了個路由專家數(),分母上多除了個激活路由專家數(K')。

我們看看為什么要乘以并除以個?

其實這里是為了保持計算損失的恒定,不隨專家數量的變化而變化。怎么理解呢?

圖片

圖片

圖片

解釋這么多,那么我們為什么要保持Loss的計算不隨專家的數量變化?這里我理解有兩個好處
第一:超參的調整簡單。超參是平衡主loss和輔助loss的超參,既不能太大,也不能太小。太大會干擾主loss的收斂效果,太小會達不到負載平衡的目標。所以如果輔助loss隨專家數變化,那么調整超參會較復雜
第二:做專家數對比消融實驗時,如果loss不受專家數設置影響,那么loss收斂的絕對值是有可比性的。尤其在做細粒度專家效果對比時,不同實驗的絕對loss值是有參考意義的,一組實驗的loss的絕對值低,能說明效果是更好的。

2.設備級負載loss(Device-Level Balance Loss)

將專家分成??組?,,每組專家放在一個設備上,為了保證設備間的計算負載均衡, 引入設備級負載loss。設備級負載loss 比專家級粒度更大,相當于在多組專家間做負載均衡,主要用來平衡不同設備的計算負載。如下圖公式所示

圖5、Device-Level Balance Loss 計算

V1版MoE的升級基本就描述完了。這里還有個問題:在公式中T表示要處理的總token量,在實際模型訓練中,模型是按Batch接受輸入的,那這個T總token量,到底是個什么口徑? 是實際樣本總token量,還是隨著Batch累加的量,亦或是每個Batch為一組的即時token量。

我們來看看V1的源碼,從源碼中看,是以每個Batch為一組token計算負載loss的,T就是一個Batch的總token量。核心代碼

class MoEGate(nn.Module):def forward(self, hidden_states):bsz, seq_len, h = hidden_states.shape        ############################# 這里的hidden_states就是公式里的T,是一個Batch數據的全部token做計算,每個Batch會重新計算############################hidden_states = hidden_states.view(-1, h)logits = F.linear(hidden_states, self.weight, None)scores_for_aux = logits.softmax(dim=-1)topk_weight, topk_idx = torch.topk(scores_for_aux, k=self.top_k, dim=-1, sorted=False)topk_idx_for_aux_loss = topk_idx.view(bsz, -1)mask_ce = F.one_hot(topk_idx_for_aux_loss.view(-1), num_classes=self.n_routed_experts)ce = mask_ce.float().mean(0)############################# 計算Pi,fi 和 aux_loss。這里的計算并沒有跨Batch累積,每個Batch單獨計算############################      Pi = scores_for_aux.mean(0)fi = ce * self.n_routed_expertsaux_loss = (Pi * fi).sum() * self.alpha

2.2. DeepSeek V2 MoE升級

DeepSeek V2 相對于V1版,對MoE模塊主要在負載均衡上做了三方面升級

1.設備受限的專家路由機制(Device-Limited Routing)

隨著LLM的size越來越大,對MoE模型的訓練,一般要采用專家并行(expert parallelism)來分布式加載模型,也就是對于網絡的一個MoE層的多個專家,分配到多個設備上,來并行訓練。由于DeepSeek的MoE是做了細粒度專家的設計,通常專家會很多(V2模型的路由專家數有160個,激活專家6個)。我們知道在MoE層多專家的輸入是一樣的,由當前層的Self-Attention輸出的隱層激活值作為MoE層的輸入。如果被激活的專家分布在多個機器上,那么要把輸入傳輸到多機器,勢必會帶來成倍的通訊成本。

為了解決這個問題,DeepSeekV2 引入了設備受限的專家路由機制。具體說就是保證每個token的激活專家,最多分布到M個設備上(M小于),這樣來控制通信成本。具體做法分2步:

  1. 對于每個token,首先選擇門控分數(圖3的公式11計算的)最高的專家所在的M個設備,
  2. 然后把M個設備上的所有專家作為備選集合,選擇個專家

DeepSeek實際驗證出,當M>=3的時候,這種受限的選的操作,與不受限的全局選的操作,模型效果上是大致相當的。所以在V2模型上,DeepSeek選擇的=6,M=3。

2. 增加通信負載均衡loss(Communication Balance Loss )

通過上面設備受限的路由機制可以減輕從輸入側將數據分發到多設備,減少多扇出的通訊量。但是在設備接收側可能還是會出現集中幾個設備的專家被激活的問題,導致通信擁堵的問題。所以V2版模型,相對于V1版增加了個通信負載均衡的loss

圖6 、通信復雜均衡loss 公式

圖片

設備受限的專家路由機制和通信負載均衡loss,都是為了解決通信負載平衡的方法。不同的是:設備受限的專家路由機制是在通信分發端確保分發的一個上限;而通信負載均衡loss是在通信接收端確保接收的平衡,鼓勵每個設備接收等量的token。所以通過這兩種方法,可以確保設備輸入、輸出的通信負載均衡。

3. 設備級Token丟棄策略(Token-Dropping Strategy)

雖然多個負載均衡的loss(包括專家,設備,通信)能引導模型做通信和計算的平衡,但并不能嚴格做到負載均衡。為了進一步做計算的負載均衡。引入了設備級的Token丟棄策略。具體做法:

  1. 首先對于一個Batch輸入token,算出每個設備的平均接收的token量,也就是設備的容量C
  2. 對于每個設備實際分配的token量,按照路由打分(圖3的公式11計算的)降序排列
  3. 如果則將超過容量C的尾部token丟棄掉,不進行專家網絡計算。

注:這里的丟棄Token,只是在單MoE層對token不做計算,但這個token會通過殘差繼續傳入上層Transformer網絡,參與計算。所以被丟棄的Token依然是有hidden_state表征的,只是這個表征不是專家輸出+殘差merge的結果,而是只有殘差部分的結果。而且多層Transformer MoE的專家是不耦合的,在某些層可能丟棄,在另外一些層參與專家計算。

作者為了保持推理和訓練的一致性,在訓練階段也保持有10%的樣本是不做Token丟棄的,來保證在推理階段不做token丟棄的效果。?

2.3. DeepSeek V3 MoE升級

首先在基本的MoE框架上,延續了細粒度專家(finer-grained experts)和 共享專家(Shared Expert Isolation)的設計。在門控網絡和負載均衡方面都做了些改進。具體如下:

1.MoE門控計算Softmax->Sigmoid

V3版MoE的計算框架如圖7所示,相對于前兩版的計算框架,主要是將門控網絡從Softmax 升級到了 Sigmoid

圖7. DeepSeek V3 MoE網絡層計算框架

從實現門控的效果上看,Softmax和Sigmoid都能做實現篩選TopK的功能,也能做概率分布的歸一化處理。

但V3版的MoE為什么要做從Softmax -> Sigmoid的升級?

要解釋這個問題,我們看看V3版相對于V2版的專家設置發生了哪些變化。

V2版:路由專家數: 160, 激活專家數: 6個, 模型總參數67B,激活參數21B
V3版:路由專家數: 256, 激活專家數: 8個, 模型總參數671B,激活參數37B

這里我個人理解:V3相對于V2的路由專家數增加了近100個,我們考慮在計算一個較大維度的softmax操作,softmax要在內部對所有維度的值做歸一化處理,維度越大,會趨向于計算出的每個維度的值會越小,因為所有維度加和要等于1,所以維度越大,每個維度值理論上分配的值就越小。這樣在選取個最大值時,對更小的小數位會敏感,會有數據區分度不高的問題,維度越大,問題越嚴重。而選擇Sigmoid函數,它是對每個專家分別計算一個[0,1]的打分,它并是不隨專家維度變化而變化,理論上計算的打分值域更寬,區分度更高。所以V3版在配置更多路由專家的情況下,采用了值域更寬的Sigmoid的函數計算專家激活權重。

2.無輔助損失負載均衡(Auxiliary-Loss-Free Load Balancing)

DeepSeek在V1,V2版MoE模型中,增加了專家級,設備級和設備通信級等平衡負載輔助loss。這些輔助loss只是為了做計算、通訊的負載均衡,對模型的效果調優并沒有幫助。甚至這些輔助loss增加過多,loss太大會對主模型造成影響,導致主模型的效果有損。為了減輕多輔助負載均衡的loss對主模型的影響,在V3版把多輔助loss都精簡掉了,通過引入一個可動態調節的bias來做到負載均衡。

圖片

這里論文中有些描述是比較含糊的,比如用什么方式檢測專家過載或負載不足的,是用專家的平均分配的token數作為參考嗎。我本來想通過看V3的源碼理解下細節(Model源碼),但沒有找到... ,只看到對于每個專家的設置成了一個可學習的參數。這個跟論文中描述的增加和減少固定的量也不一樣。可能是我沒找對位置,這塊后面會再搜集些信息,理解下具體實現。

3. sequence粒度的負均衡損失(Complementary Sequence-Wise Auxiliary Loss)

DeepSeek V3也增加了一個sequence粒度的負載均衡損失,來平衡單個sequence的token分配給每個專家。如下圖公式所示

圖8、Sequence-Wise Auxiliary Loss計算

相對于V1版的專家級輔助損失(Expert-Level Balance Loss)其實就是作用粒度不一樣,Sequence-Wise的粒度是單條樣本粒度的token做計算。Expert-Level Balance是一個Batch的多Sequence的token做計算。公式的計算形式并沒有什么差異。

最后DeepSeekV3也強調通過上面的負載均衡的策略,能達到一個非常好的平衡效果,所以在V3版并沒有Token被Drop掉。

3. 總結

我們再來回顧下DeepSeek在MoE方面創新和演進過程

  • V1版為了兼顧對通用知識和細粒度領域知識的建模,引入了共享專家(Shared Expert)和細粒度專家(Fine-Grained Expert)。同時為了平衡各個專家的計算負載,引入了專家級負載loss (Expert-Level Balance Loss)和 設備級負載loss(Device-Level Balance Loss)。
  • V2版主要在通信負載上做了些優化,通過引入設備受限的專家路由機制和通信負載均衡loss確保設備輸入、輸出的通信負載均衡。
  • V3版考慮負載loss對主模型的優化會有影響,將輔助負載loss做了精簡,通過在門控權重增加一個可調的bias來解決通信和計算的負載。也引入了一個更細粒度的sequence負載均衡loss。同時考慮隨著路由專家增到256個,在門控權重計算上選擇了值域更寬、打分差異更顯著的sigmoid函數替換了原來的softmax函數。

整體演進過程,如下圖所示:

DeepSeek MoE演進

#xxx

#xxx

#xxx

#xxx

#xxx

#xxx

#xxx

#xxx

#xxx

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/news/913334.shtml
繁體地址,請注明出處:http://hk.pswp.cn/news/913334.shtml
英文地址,請注明出處:http://en.pswp.cn/news/913334.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

每天一個前端小知識 Day 23 - PWA 漸進式 Web 應用開發

PWA 漸進式 Web 應用開發&#xff08;離線緩存、桌面安裝等&#xff09; &#x1f9e0; 一、什么是 PWA&#xff1f; PWA&#xff08;Progressive Web App&#xff09;是一種讓 Web 應用具有類似原生 App 用戶體驗的技術體系。 PWA 不是一個框架&#xff0c;而是由一組瀏覽器 A…

音視頻會議服務搭建(設計方案-兩種集成方案對比)-03

前言在開始計劃之前&#xff0c;查閱了不少資料。一種方案是 Go層做信令業務&#xff0c;nodejs層來管理和mediasoup的底層交互&#xff0c;通過客戶端去調用Go層&#xff1b;第二種方案是 客戶端直接調用nodejs層來跟mediasoup去交互&#xff1b; 最終&#xff0c;當然不出意料…

【小白】linux安裝ffmpeg | java轉碼 【超詳細】

前言 最近在開發過程中&#xff0c;發現當我們上傳除了mp4以外的其他少見的格式&#xff0c;如 .flv .rmvb 格式的視頻時&#xff0c;在前端在線播放的時候會播放不出來畫面&#xff0c;所以 接下來&#xff0c;將要進行一個非常完美的工程&#xff0c;將視頻格式轉為.mp4 1.安…

一個簡單的腳本,讓pdf開啟夜間模式

因為平常我比較喜歡晚上看面試題。 市面上很多的面試題pdf都是白色的晚上看的話非常的刺眼。 所以我本能的去互聯網搜索看看有沒有pdf轉換為夜間模式的。 搜索了一段時間后發現并沒有這種東西。于是我自己做了一個轉換的python腳本。 import os import fitz # PyMuPDF from P…

Flink OceanBase CDC 環境配置與驗證

一、OceanBase 數據庫核心配置 1. 環境準備與版本要求 版本要求&#xff1a;OceanBase CE 4.0 或 OceanBase EE 2.2組件依賴&#xff1a;需部署 LogProxy 服務&#xff08;社區版/企業版部署方式不同&#xff09;兼容模式&#xff1a;支持 MySQL 模式&#xff08;默認&#x…

c++對象池

【設計模式】其它經典模式-對象池模式&#xff08;Object Pool Pattern&#xff09;-CSDN博客 在C中&#xff0c;對象池&#xff08;Object Pool&#xff09;是一種管理對象生命周期的技術&#xff0c;旨在減少對象創建和銷毀的開銷&#xff0c;提高性能。對象池預先分配一定數…

JavaFX:Scene(場景)

簡介 Scene對象是JavaFX場景圖的根(root)。JavaFX 場景中包含所有可視的 JavaFX GUI 組件。JavaFX 場景由javafx.scene.Scene類表示。必須在 Stage(舞臺)上設置 Scene 對象才能使其可見。在本 JavaFX Scene 教程中,將向您展示如何創建 Scene 對象并向其添加 GUI 組件。 創…

vue3.4中的v-model的用法~

1.首先以前我們針對父子組件傳參是不是通過defineProps與defineEmits來實現的&#xff0c;但是這么比較繁瑣&#xff0c;因為他是單向傳參&#xff0c;而不是雙向的&#xff0c;這里我們要介紹的是vue3.4的v-model來實現雙向數據傳遞。 2、代碼示例&#xff1a; //父組件 <…

nvm常用指令匯總

nvm是用來管理nodejs的&#xff0c;可以方便安裝、切換、卸載當前環境的node版本。 以下是常用指令匯總&#xff1a;nvm list 查看本機已經安裝的node版本。*表示當前系統正在使用的node版本nvm install xx.xx.x 后邊加版本號&#xff0c;表示安裝指定的版本nvm use xx.xx.x當前…

洛谷P5021 [NOIP 2018 提高組] 賽道修建【題解】【二分答案+樹上貪心】

P5021 [NOIP 2018 提高組] 賽道修建 題意簡述 給定一棵含 n n n 個點的無向帶權樹&#xff0c;求將其分裂為 m m m 條鏈后&#xff0c;最短的一條鏈的最大長度是多少&#xff1f; 點可以重復使用&#xff0c;邊不可以重復使用。 思路 二分答案貪心判定貌似可以&#xff…

Portal認證過程雜談

Portal認證模型簡介 Portal認證模型通常由這四個設備組成 認證服務器即3A服務器&#xff0c;通常用radius服務器 接入設備通常就是NAC設備&#xff08;網絡接入控制&#xff09; Portal服務器就是Portal認證的認證網站&#xff08;通常叫門戶網站&#xff09; 認證過程簡述…

ZSGuardian ---AI賦能,新一代研發管理守護平臺 -即將上線

一場研發管理的革命 在數字化浪潮奔涌向前的今天&#xff0c;軟件開發與產品研發的節奏不斷加快&#xff0c;市場需求瞬息萬變&#xff0c;技術迭代日新月異。對于研發團隊而言&#xff0c;如何在復雜多變的環境中&#xff0c;高效地管理項目、保障產品質量、確保按時上線&…

小菜狗的云計算之旅,學習了解rsync+sersync實現數據實時同步(詳細操作步驟)

Rsyncsersync實現數據實時同步 目錄 Rsyncsersync實現數據實時同步 一、rsync概述 二、rsync運行原理 三、rsync部署 四、備份測試 五、使用非系統用戶備份數據 5.1 rsync的配置文件介紹 5.2 配置備份目錄 5.3 使用rsync用戶備份測試 5.4 pull拉取數據 六、rsyncse…

牛客周賽Round 99(Go語言)

A題 (A.go) 思路總結: 這道題要求判斷一個整數中是否包含連續的兩個9。 核心思路是將輸入的整數轉換為字符串&#xff0c;然后遍歷這個字符串&#xff0c;檢查是否存在相鄰的兩個字符都是9。如果找到了&#xff0c;就立即停止遍歷并輸出"YES"&#xff1b;如果遍歷完…

紅外圖像小目標檢測熱力圖可視化系統

原創代碼&#xff0c;可以工程修改含界面。

供應鏈管理:指標評估方式分類與詳解

一、指標評估方式分類與詳解 評估維度評估方式核心方法適用場景示例數據來源內部數據評估從企業ERP、MES、CRM等系統提取生產、財務、客戶等數據。成本、效率、質量等內部管理指標評估。生產成本數據&#xff08;MES系統&#xff09;、客戶滿意度&#xff08;CRM系統&#xff…

基于 Rust 的前端工具基本實現

1. Rust 環境安裝 1.1. 安裝 Rust Rust 提供了一個非常方便的安裝工具 rustup,可以通過以下命令安裝 Rust: curl --proto =https --tlsv1.2 -sSf https://sh.rustup.rs | sh 這個命令會安裝 Rust 編譯器 rustc、包管理工具 cargo 以及其他相關工具。 1.2. 配置環境變量 …

大模型關鍵字解釋

&#x1f4a1; 一、模型結構關鍵詞 1. Transformer Transformer 是一種專門用來“理解文字”的神經網絡結構。就像一個聰明的秘書&#xff0c;能同時看懂整段話的所有詞之間的關系&#xff0c;而不是像老式模型那樣一句一句讀。 &#x1f449; 舉例&#xff1a;以前的模型像…

空調和烘干機的使用

開關 制冷 選擇上下掃風 那個就下來了 烘干機 電源鍵 長按3s以上直到菜單顯示 選擇小件 不要快烘 至少1個半小時 才可以烘干

極簡的神經網絡反向傳播例子

我之前一直沒搞清楚&#xff0c;神經網絡為什么要求導&#xff1f;反向傳播又是什么&#xff1f;于是到現在深究回來…… 本質就是擬合一個未知函數。 高中的數理統計就學過最小二乘法這種回歸方法&#xff08;? 代表自己的預測y&#xff0c;這個表達要記住&#xff09;&…