從 DeepSeek-V3 到 Kimi K2:八種現代大語言模型架構設計

編譯:青稞社區+Kimi
原文:https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison
首發:https://mp.weixin.qq.com/s/lSM2jk1UxJVz1WllWYQ4aQ

自原始 GPT 架構開發以來已經過去了七年。乍一看,從 2019 年的 GPT-2 回溯,再到 2024-2025 年的 DeepSeek-V3 和 Llama 4,人們可能會驚訝地發現這些模型在結構上仍然如此相似。

當然,位置嵌入已經從絕對位置嵌入發展到旋轉位置嵌入(RoPE),多頭注意力(Multi-Head Attention)大多被分組查詢注意力(Grouped-Query Attention)所取代,更高效的 SwiGLU 也取代了像 GELU 這樣的激活函數。但在這些細微改進之下,我們是否真正看到了突破性的變化,還是我們只是在對相同的架構基礎進行打磨?

比較 LLM 以確定其表現良好(或不佳)的關鍵因素是出了名的具有挑戰性:數據集、訓練技術和超參數差異很大,且往往沒有得到很好的記錄。

然而,我認為,檢查架構本身的結構變化仍然具有很大的價值,以了解 2025 年 LLM 開發者們在做什么。(其中一部分如圖 1 所示。)

圖 1:本文涵蓋的部分架構。

因此,在這篇文章中,我將專注于定義當今旗艦開放模型的架構發展,而不是討論基準性能或訓練算法。

1. DeepSeek V3/R1

你可能已經不止一次聽說過,DeepSeek R1 在 2025 年 1 月發布時產生了巨大影響。DeepSeek R1 是基于 2024 年 12 月推出的 DeepSeek V3 架構構建的推理模型。

雖然我在這里關注的是 2025 年發布的架構,但我認為將 DeepSeek V3 包含進來是合理的,因為它在 2025 年 DeepSeek R1 發布后才獲得了廣泛關注和采用。

在這一部分中,我將重點介紹 DeepSeek V3 中引入的兩項關鍵架構技術,這些技術提高了其計算效率,并使其與其他許多 LLM 區別開來:

  • Multi-Head Latent Attention (MLA)
  • Mixture-of-Experts (MoE)

1.1 Multi-Head Latent Attention (MLA)

在討論多頭潛在注意力(MLA)之前,讓我們先簡要回顧一些背景,以說明為什么使用它。為此,我們先從分組查詢注意力(GQA)開始,近年來,GQA 已經成為多頭注意力(MHA)的更高效計算和參數替代方案。

所以,這里是一個簡短的 GQA 總結。與 MHA 不同,MHA 中的每個頭都有自己的鍵和值,為了減少內存使用,GQA 將多個頭分組以共享相同的鍵和值投影。

例如,如圖 2 所示,如果有 2 個鍵值組和 4 個注意力頭,那么頭 1 和頭 2 可能共享一組鍵和值,而頭 3 和頭 4 共享另一組。這減少了鍵和值計算的總數,從而降低了內存使用并提高了效率(根據消融研究,這并沒有明顯影響建模性能)。

圖 2:MHA 和 GQA 的比較。這里,組大小為 2,一個鍵值對在 2 個查詢之間共享。

因此,GQA 的核心思想是通過在多個查詢頭之間共享鍵和值頭來減少鍵和值頭的數量。這(1)降低了模型的參數數量,(2)減少了在推理期間鍵和值張量的內存帶寬使用,因為需要存儲和從 KV 緩存中檢索的鍵和值更少。

盡管 GQA 主要是 MHA 的計算效率解決方案,但消融研究(例如原始 GQA 論文和 Llama 2 論文中的研究)表明,它在 LLM 建模性能方面與標準 MHA 相當。

現在,多頭潛在注意力(MLA)提供了一種不同的節省內存的策略,這種策略也特別適合與 KV 緩存搭配使用。與 GQA 不同,MLA 在將鍵和值張量存儲到 KV 緩存之前,將其壓縮到低維空間。

在推理時,這些壓縮的張量會被投影回其原始大小,如圖 3 所示。這增加了一次額外的矩陣乘法,但減少了內存使用。

圖 3:與常規 MHA 相比,MLA(用于 DeepSeek V3 和 R1)的比較。

(順便說一下,查詢也在訓練期間被壓縮,但在推理期間不會。)

順便說一下,MLA 并不是 DeepSeek V3 的新發明,因為它的前身 DeepSeek-V2 也使用了(甚至引入了)它。此外,V2 論文還包含了一些有趣的消融研究,這些研究可能解釋了為什么 DeepSeek 團隊選擇了 MLA 而不是 GQA(見圖 4)。

圖 4:來自 DeepSeek-V2 論文的注釋表格,https://arxiv.org/abs/2405.04434

如圖 4 所示,GQA 的表現似乎不如 MHA,而 MLA 在建模性能方面優于 MHA,這可能是 DeepSeek 團隊選擇 MLA 而不是 GQA 的原因。(如果能看到 MLA 和 GQA 之間的“每個標記的 KV 緩存”節省比較,那將很有趣!)

在我們繼續下一個架構組件之前,總結一下這一部分,MLA 是一種巧妙的技巧,可以在降低 KV 緩存內存使用的同時,甚至在建模性能方面略微優于 MHA。

1.2 Mixture-of-Experts (MoE)

DeepSeek 值得強調的另一個主要架構組件是其使用了專家混合(MoE)層。雖然 DeepSeek 并沒有發明 MoE,但今年它又重新流行起來,我們稍后將討論的許多架構也采用了它。

你可能已經對 MoE 很熟悉了,但簡要回顧一下可能有幫助。

MoE 的核心思想是用多個專家層替換 Transformer 塊中的每個 FeedForward 模塊,其中每個專家層也是一個 FeedForward 模塊。這意味著我們將一個 FeedForward 塊替換為多個 FeedForward 塊,如圖 5 所示。

圖 5:DeepSeek V3/R1 中的專家混合(MoE)模塊(右)與具有標準 FeedForward 塊的 LLM(左)的比較。

Transformer 塊中的 FeedForward 塊(在上圖中顯示為深灰色塊)通常包含模型總參數的大部分。(請注意,Transformer 塊,因此 FeedForward 塊,在 LLM 中會重復多次;在 DeepSeek-V3 的情況下,重復了 61 次。)

因此,用多個 FeedForward 塊替換一個 FeedForward 塊(如 MoE 設置中所做的那樣)會顯著增加模型的總參數數量。然而,關鍵的技巧是我們并不使用(“激活”)每個標記的所有專家。相反,路由器只為每個標記選擇一小部分專家。(由于時間關系,或者更確切地說是為了節省文章篇幅,我將在以后詳細介紹路由器。)

因為每次只激活少數專家,所以 MoE 模塊通常被稱為_稀疏_模塊,與總是使用完整參數集的_密集_模塊相對。然而,通過 MoE 的大量總參數增加了 LLM 的容量,這意味著它可以在訓練期間吸收更多的知識。盡管如此,稀疏性保持了推理的高效性,因為我們并不是同時使用所有的參數。

例如,DeepSeek-V3 每個 MoE 模塊有 256 個專家,總共有 6710 億個參數。但在推理期間,每次只激活 9 個專家(1 個共享專家加上路由器選擇的 8 個)。這意味著每次推理步驟只使用 370 億個參數,而不是全部 6710 億個。

DeepSeek-V3 的 MoE 設計的一個顯著特點是使用了共享專家。這是一個始終為每個標記激活的專家。這個想法并不新鮮,早在 2024 年的DeepSeek MoE 和 2022 年的 DeepSpeedMoE 論文中就已經引入了。

圖 6:來自 “DeepSeekMoE:邁向專家混合語言模型的終極專家專業化” 的注釋圖,https://arxiv.org/abs/2401.06066

共享專家的好處最初在 DeepSpeedMoE 論文中被注意到,他們發現與沒有共享專家相比,它提高了整體建模性能。這可能是因為常見的或重復的模式不需要被多個單獨的專家學習,這為它們留下了更多空間來學習更專門的模式。

1.3 DeepSeek Summary

總之,DeepSeek-V3 是一個擁有 6710 億個參數的巨大模型,在發布時,它超過了其他開放權重模型,包括 405B Llama 3。盡管規模更大,但它在推理時間上效率更高,這得益于其專家混合(MoE)架構,該架構每次標記只激活一小部分(僅 37B)參數。

另一個關鍵區別是 DeepSeek-V3 使用了多頭潛在注意力(MLA)而不是分組查詢注意力(GQA)。MLA 和 GQA 都是標準多頭注意力(MHA)的推理高效替代方案,特別是在使用 KV 緩存時。雖然 MLA 實現起來更復雜,但 DeepSeek-V2 論文中的一項研究表明,它在建模性能方面優于 GQA。

2.OLMo 2

非營利機構艾倫人工智能研究所的OLMo系列模型值得關注,因為它在訓練數據和代碼方面非常透明,并且技術報告也相對詳細。

雖然你可能不會在任何基準測試或排行榜的頂部找到 OLMo 模型,但它們非常干凈,更重要的是,由于它們的透明度,它們是開發 LLM 的絕佳藍圖。

盡管 OLMo 模型因其透明度而受歡迎,但它們的表現也不差。事實上,在 1 月份發布時(在 Llama 4、Gemma 3 和 Qwen 3 之前),OLMo 2 模型位于計算與性能的帕累托前沿,如圖 7 所示。

圖 7:不同 LLM 的建模基準性能(越高越好)與預訓練成本(FLOPs;越低越好)的比較。這是來自 OLMo 2 論文的注釋圖,https://arxiv.org/abs/2501.00656

正如本文前面提到的,我的目標僅關注 LLM 架構細節(不包括訓練或數據),以保持篇幅可控。那么,OLMo2 中有哪些有趣的架構設計選擇呢?主要歸結為歸一化:RMSNorm 層的位置以及 QK-norm 的添加,我將在下面討論。

另一件值得一提的事情是,OLMo 2 仍然使用傳統的多頭注意力(MHA),而不是 MLA 或 GQA。

2.1 Normalization Layer Placement

總的來說,OLMo 2 在很大程度上遵循了原始 GPT 模型的架構,與其他當代 LLM 相似。然而,也有一些值得注意的偏差。讓我們從歸一化層開始。

與 Llama、Gemma 和大多數其他 LLM 類似,OLMo 2 從 LayerNorm 切換到 RMSNorm。

但既然 RMSNorm 已經司空見慣(它基本上是 LayerNorm 的簡化版本,可訓練參數更少),我將跳過 RMSNorm 與 LayerNorm 的討論。

然而,討論 RMSNorm 層的位置是值得的。原始 Transformer(來自“Attention is all you need”論文)將兩個歸一化層放置在 Transformer 塊中注意力模塊和 FeedForward 模塊之后。

這也被稱為 Post-LN 或 Post-Norm。

GPT 和之后的大多數其他 LLM 將歸一化層放置在注意力和 FeedForward 模塊之前,這被稱為 Pre-LN 或 Pre-Norm。Post- 和 Pre-Norm 的比較如下圖所示。

圖 8:Post-Norm、Pre-Norm 和 OLMo 2 的 Post-Norm 風格的比較。

2020 年,Xiong 等人表明,Pre-LN 在初始化時產生更良好行為的梯度。此外,研究人員提到,Pre-LN 甚至在沒有仔細的學習率預熱的情況下也能很好地工作,而這對 Post-LN 來說是一個至關重要的工具。

現在,我提到這一點的原因是,OLMo 2 采用了 Post-LN 的一種形式(但使用 RMSNorm 而不是 LayerNorm,所以我稱之為_Post-Norm_)。

在 OLMo 2 中,他們沒有將歸一化層放置在注意力和 FeedForward 層之前,而是將其放置在之后,如上圖所示。然而,請注意,與原始 Transformer 架構相比,歸一化層仍然在殘差層(跳躍連接)內部。

那么,他們為什么移動了歸一化層的位置呢?原因是這有助于訓練穩定性,如下圖所示。

圖 9:顯示 Pre-Norm(如 GPT-2、Llama 3 和許多其他模型中)與 OLMo 2 的 Post-Norm 風格的訓練穩定性圖。

不幸的是,這張圖顯示了與 QK-Norm 重新排序的結果,這是一個單獨的概念。因此,很難判斷歸一化層重新排序本身貢獻了多少。

2.2 QK-Norm

由于上一節已經提到了 QK-norm,并且我們稍后討論的其他 LLM(如 Gemma 2 和 Gemma 3)也使用了 QK-norm,讓我們簡要討論一下這是什么。

QK-Norm 本質上是另一個 RMSNorm 層。它位于多頭注意力(MHA)模塊內部,并在應用 RoPE 之前應用于查詢(q)和鍵(k)。為了說明這一點,以下是我為 Qwen3 從零開始實現所寫的 Grouped-Query Attention(GQA)層的一個片段(GQA 中 QK-norm 的應用與 OLMo 中的 MHA 類似):

class GroupedQueryAttention(nn.Module):def __init__(self, d_in, num_heads, num_kv_groups,head_dim=None, qk_norm=False, dtype=None):# ...if qk_norm:self.q_norm = RMSNorm(head_dim, eps=1e-6)self.k_norm = RMSNorm(head_dim, eps=1e-6)else:self.q_norm = self.k_norm = Nonedef forward(self, x, mask, cos, sin):b, num_tokens, _ = x.shape# 應用投影queries = self.W_query(x)keys = self.W_key(x)values = self.W_value(x)# ...# 可選歸一化if self.q_norm:queries = self.q_norm(queries)if self.k_norm:keys = self.k_norm(keys)# 應用 RoPEqueries = apply_rope(queries, cos, sin)keys = apply_rope(keys, cos, sin)# 擴展 K 和 V 以匹配頭的數量keys = keys.repeat_interleave(self.group_size, dim=1)values = values.repeat_interleave(self.group_size, dim=1)# 注意力attn_scores = queries @ keys.transpose(2, 3)# ...

如前所述,QK-Norm 與 Post-Norm 一起穩定了訓練。請注意,QK-Norm 并非由 OLMo 2 發明,而是可以追溯到 2023 年的 Scaling Vision Transformers 論文。

2.3 OLMo 2 Summary

簡而言之,值得注意的 OLMo 2 架構設計決策主要是 RMSNorm 的位置:在注意力和 FeedForward 模塊之后而不是之前(Post-Norm 的一種風格),以及在注意力機制中為查詢和鍵添加 RMSNorm(QK-Norm),這兩者共同幫助穩定了訓練損失。

下圖進一步比較了 OLMo 2 與 Llama 3;可以看出,除了 OLMo 2 仍然使用傳統的 MHA 而不是 GQA 之外,架構在其他方面相對相似。(然而,OLMo 2 團隊在 3 個月后發布了一個使用 GQA 的 32B 變體。)

圖 10:Llama 3 和 OLMo 2 的架構比較。

3. Gemma 3

谷歌的 Gemma 模型一直都很出色,我認為與其他流行模型(如 Llama 系列)相比,它們總是被低估了。

Gemma 的一個顯著特點是其相當大的詞匯量(為了更好地支持多種語言),以及對 27B 尺寸的更強關注(而不是 8B 或 70B)。但請注意,Gemma 2 也有更小的尺寸:1B、4B 和 12B。

27B 的尺寸確實是一個非常好的平衡點:它比 8B 模型強大得多,但不像 70B 模型那樣資源密集,而且在我的 Mac Mini 上運行得很好。

那么,Gemma 3 還有什么有趣的地方呢?如前所述,像 Deepseek-V3/R1 這樣的其他模型使用專家混合(MoE)架構來減少推理時的內存需求,給定固定的模型大小。(MoE 方法也用于我們稍后討論的其他幾個模型。)

Gemma 3 使用了一種不同的“技巧”來降低計算成本,即滑動窗口注意力。

3.1 Sliding Window Attention

通過滑動窗口注意力(最初在 2020 年的 LongFormer 論文中引入,并且也被 Gemma 2 使用),Gemma 3 團隊能夠大幅減少 KV 緩存中的內存需求,如下圖所示。

圖 11:來自 Gemma 3 論文(https://arxiv.org/abs/2503.19786)的注釋圖,顯示了通過滑動窗口注意力實現的 KV 緩存內存節省。

那么,什么是滑動窗口注意力呢?如果我們把常規自注意力看作是一種_全局_注意力機制,因為每個序列元素都可以訪問其他所有序列元素,那么我們可以把滑動窗口注意力看作是一種_局部_注意力,因為這里我們限制了當前查詢位置周圍的上下文大小。如下圖所示。

圖 12:常規注意力(左)和滑動窗口注意力(右)的比較。

請注意,滑動窗口注意力可以與多頭注意力和分組查詢注意力一起使用;Gemma 3 使用分組查詢注意力。

如上所述,滑動窗口注意力也被稱為_局部_注意力,因為局部窗口圍繞并隨當前查詢位置移動。相比之下,常規注意力是_全局_的,因為每個標記都可以訪問所有其他標記。

現在,如前所述,Gemma 2 的前身架構也使用了滑動窗口注意力。Gemma 3 的不同之處在于它們調整了全局(常規)和局部(滑動)注意力之間的比例。

例如,Gemma 2 使用混合注意力機制,以 1:1 的比例結合了滑動窗口(局部)和全局注意力。每個標記可以參與附近上下文的 4k 標記窗口。

Gemma 2 在其他層中使用滑動窗口注意力,而 Gemma 3 現在有 5:1 的比例,這意味著每 5 個滑動窗口(局部)注意力層中只有 1 個完整注意力層;此外,滑動窗口大小從 4096(Gemma 2)減少到僅 1024(Gemma 3)。這將模型的重點轉移到更高效的局部計算上。

根據他們的消融研究,滑動窗口注意力的使用對建模性能的影響很小,如下圖所示。

圖 13:來自 Gemma 3 論文(https://arxiv.org/abs/2503.19786)的注釋圖,顯示滑動窗口注意力對 LLM 生成的輸出困惑度的影響很小或沒有影響。

雖然滑動窗口注意力是 Gemma 3 最值得注意的架構方面,但我也想簡要回顧一下歸一化層的位置,作為前一節 OLMo 2 的后續。

3.2 Normalization Layer Placement in Gemma 3

一個雖小但有趣的細節是,Gemma 3 在 Pre-Norm 和 Post-Norm 設置中都使用了 RMSNorm,圍繞其分組查詢注意力模塊。

這與 Gemma 2 類似,但仍然值得強調,因為它不同于(1)原始 Transformer(“Attention is all you need”)中使用的 Post-Norm,(2)由 GPT-2 推廣的 Pre-Norm,之后在許多其他架構中使用,以及(3)我們之前看到的 OLMo 2 的 Post-Norm 風格。

圖 14:OLMo2 和 Gemma 3 的架構比較;請注意 Gemma 3 中的額外歸一化層。

我認為這種歸一化層的位置是一種相對直觀的方法,因為它結合了 Pre-Norm 和 Post-Norm 的優點。在我看來,多做一些歸一化并沒有壞處。在最壞的情況下,如果額外的歸一化是多余的,這會帶來一點冗余的低效。實際上,由于 RMSNorm 在整體方案中相對便宜,這不應該有任何明顯的影響。

3.3 Gemma 3 Summary

Gemma 3 是一個表現良好的開放權重 LLM,在我看來,它在開源圈子中有點被低估了。最有趣的部分是使用滑動窗口注意力來提高效率(未來將其與 MoE 結合將很有趣)。

此外,Gemma 3 還具有獨特的歸一化層位置,在注意力和 FeedForward 模塊之前和之后都放置了 RMSNorm 層。

3.4 Bonus: Gemma 3n

在 Gemma 3 發布幾個月后,谷歌分享了 Gemma 3n,這是一個針對小型設備效率優化的 Gemma 3 模型,目標是在手機上運行。

Gemma 3n 為實現更好的效率所做的更改之一是所謂的每層嵌入(PLE)參數層。關鍵思想是只將模型參數的一個子集保留在 GPU 內存中。然后,根據需要從 CPU 或 SSD 流式傳輸特定于標記層的嵌入,例如文本、音頻和視覺模態的嵌入。

下圖說明了 PLE 的內存節省,列出了標準 Gemma 3 模型的 54.4 億個參數。這可能指的是 Gemma 3 的 40 億變體。

圖 15:來自 Google 的 Gemma 3n 博客(https://developers.googleblog.com/en/introducing-gemma-3n/)的注釋圖,說明了 PLE 的內存節省。

54.4 億與 40 億參數的差異是因為谷歌有一種有趣的報告 LLM 參數數量的方法。他們通常排除嵌入參數以使模型看起來更小,除非在這種情況下,包含它們以使模型看起來更大很方便。這并不是谷歌獨有的,因為這種方法在該領域已經很普遍。

另一個有趣的技巧是 MatFormer 概念(Matryoshka Transformer 的縮寫)。例如,Gemma 3n 使用一個共享的 LLM(Transformer)架構,可以將其切片為更小、獨立可用的模型。每個切片都經過訓練,可以獨立運行,因此在推理時,我們可以只運行你需要的部分(而不是大型模型)。

4. Mistral Small 3.1

Mistral Small 3.1 24B 于 3 月在 Gemma 3 之后不久發布,值得注意,它在幾個基準測試中優于 Gemma 3 27B(除了數學),同時速度更快。

Mistral Small 3.1 比 Gemma 3 更低的推理延遲的原因可能是他們的自定義分詞器,以及縮小 KV 緩存和層數。否則,它是一個標準架構,如下圖所示。

圖 16:Gemma 3 27B 和 Mistral 3.1 Small 24B 的架構比較。

有趣的是,早期的 Mistral 模型使用了滑動窗口注意力,但他們在 Mistral Small 3.1 中似乎放棄了它。因此,由于 Mistral 使用常規分組查詢注意力,而不是像 Gemma 3 中那樣使用滑動窗口的分組查詢注意力,也許由于能夠使用更優化的代碼(即 FlashAttention),還有額外的推理計算節省。例如,我推測雖然滑動窗口注意力減少了內存使用,但它不一定減少推理延遲,而 Mistral Small 3.1 正專注于這一點。

5. Llama 4

本文前面關于專家混合(MoE)的廣泛討論再次得到了回報。Llama 4 也采用了 MoE 方法,并且總體上遵循了一個相對標準的架構,與 DeepSeek-V3 非常相似,如下圖所示。(Llama 4 包括原生多模態支持,類似于 Gemma 和 Mistral 等模型。然而,由于本文專注于語言建模,我們只專注于文本模型。)

圖 17:DeepSeek V3(6710 億參數)和 Llama 4 Maverick(4000 億參數)的架構比較。

雖然 Llama 4 Maverick 架構總體上看起來與 DeepSeek-V3 非常相似,但有一些有趣的差異值得強調。

首先,Llama 4 使用了與其前身類似的分組查詢注意力,而 DeepSeek-V3 使用了多頭潛在注意力,我們在本文開頭討論過。現在,DeepSeek-V3 和 Llama 4 Maverick 都是非常大的架構,DeepSeek-V3 的總參數數量大約大 68%。然而,DeepSeek-V3 擁有 370 億個活躍參數,比 Llama 4 Maverick(170 億)多出一倍多。

Llama 4 Maverick 使用了更經典的 MoE 設置,專家更少但更大(2 個活躍專家,每個隱藏大小為 8192),相比之下,DeepSeek-V3(9 個活躍專家,每個隱藏大小為 2048)。此外,DeepSeek 在每個 Transformer 塊(除了前 3 個)中使用 MoE 層,而 Llama 4 在每個其他 Transformer 塊中交替使用 MoE 和密集模塊。

鑒于架構之間的許多小差異,很難確定它們對最終模型性能的確切影響。然而,主要的收獲是,MoE 架構在 2025 年得到了顯著普及。

6. Qwen3

Qwen 團隊持續提供高質量的開放權重 LLM。當我共同建議 2023 年 NeurIPS 的 LLM 效率挑戰時,我記得所有獲勝解決方案都是基于 Qwen2 的。

現在,Qwen3 是另一個在其尺寸類別中排名靠前的模型系列。有 7 個密集模型:0.6B、1.7B、4B、8B、14B 和 32B。還有兩個 MoE 模型:30B-A3B 和 235B-A22B。

讓我們先討論密集模型架構。在撰寫本文時,0.6B 模型可能是目前可用的最小當前一代開放權重模型。根據我的個人經驗,鑒于其小巧的尺寸,它的表現確實非常好。如果你打算本地運行,它具有出色的每秒標記吞吐量和低內存占用。更重要的是,由于其小巧的尺寸,它也很容易在本地進行訓練(用于教育目的)。

因此,Qwen3 0.6B 在大多數情況下已經取代了 Llama 3 1B。下圖顯示了這兩個架構的比較。

圖 18:Qwen3 0.6B 和 Llama 3 1B 的架構比較;請注意,Qwen3 是一個更深的架構,具有更多層,而 Llama 3 是一個更寬的架構,具有更多注意力頭。

如果你對一個沒有外部第三方 LLM 庫依賴的可讀 Qwen3 實現感興趣,我最近從零開始實現了 Qwen3(使用純 PyTorch)。

上圖中的計算性能數據基于我在 A100 GPU 上從零開始的 PyTorch 實現。可以看出,Qwen3 的內存占用更小,因為它總體上是一個更小的架構,但也使用了更小的隱藏層和更少的注意力頭。然而,它使用了比 Llama 3 更多的 Transformer 塊,這導致運行時間更慢(每秒標記生成速度更低)。

6.2 Qwen3 (MoE)

如前所述,Qwen3 也有兩種 MoE 風格:30B-A3B 和 235B-A22B。為什么像 Qwen3 這樣的架構既有常規(密集)又有 MoE(稀疏)變體?

正如本文開頭提到的,MoE 變體有助于降低大型基礎模型的推理成本。提供密集和 MoE 版本讓用戶可以根據他們的目標和約束靈活選擇。

密集模型通常更容易在各種硬件上進行微調、部署和優化。

另一方面,MoE 模型針對擴展推理進行了優化。例如,在固定的推理預算下,它們可以實現更高的整體模型容量(即,由于在訓練中更大,因此知識吸收量更大),而不會成比例地增加推理成本。

通過發布這兩種類型,Qwen3 系列可以支持更廣泛的使用案例:密集模型用于穩健性、簡單性和微調,MoE 模型用于大規模高效服務。

為了總結這一部分,讓我們看看 Qwen3 235B-A22B(請注意,A22B 代表“220 億活躍參數”)與 DeepSeek-V3 的比較,后者擁有近兩倍多的活躍參數(370 億)。

圖 19:DeepSeek-V3 和 Qwen3 235B-A22B 的架構比較。

如上圖所示,DeepSeek-V3 和 Qwen3 235B-A22B 的架構非常相似。然而,值得注意的是,Qwen3 模型不再使用共享專家(早期的 Qwen 模型,如 Qwen2.5-MoE 使用了共享專家)。

不幸的是,Qwen3 團隊沒有透露他們放棄共享專家的原因。如果我不得不猜測,也許是因為在他們的設置中,當他們將專家從 2(在 Qwen2.5-MoE 中)增加到 8(在 Qwen3 中)時,共享專家對訓練穩定性不再必要。然后,他們能夠通過僅使用 8 個而不是 8+1 個專家來節省額外的計算/內存成本。(然而,這并不能解釋為什么 DeepSeek-V3 仍然保留其共享專家。)

7. SmolLM3

SmolLM3 可能不像本文涵蓋的其他 LLM 那樣受歡迎,但我認為它仍然是一個有趣的模型,因為它在相對較小且方便的 30 億參數模型大小上提供了非常好的建模性能,位于 Qwen3 的 1.7B 和 4B 模型之間,如下圖所示。

此外,它還分享了很多訓練細節,類似于 OLMo,這很少見,而且總是受歡迎的!

圖 20:來自 SmolLM3 公告帖子的注釋圖,https://huggingface.co/blog/smollm3,比較 SmolLM3 的勝率與 Qwen3 1.7B 和 4B 以及 Llama 3 3B 和 Gemma 3 4B

如下圖所示的架構比較圖所示,SmolLM3 架構看起來相當標準。也許最有趣的方面是它對 NoPE(無位置嵌入)的使用。

圖 21:Qwen3 4B 和 SmolLM3 3B 的并排架構比較。

7.1 No Positional Embeddings (NoPE)

NoPE 在 LLM 語境中是一個舊想法,可以追溯到 2023 年的一篇論文(The Impact of Positional Encoding on Length Generalization in Transformers),以移除顯式的位置信息注入(如早期 GPT 架構中的經典絕對位置嵌入層或如今的 RoPE)。

在基于 Transformer 的 LLM 中,通常需要位置編碼,因為自注意力獨立于順序對待標記。絕對位置嵌入通過添加一個額外的嵌入層來解決這個問題,該層向標記嵌入添加信息。

圖 22:來自我的《從零構建大型語言模型》一書(https://www.amazon.com/Build-Large-Language-Model-Scratch/dp/1633437167)的修改圖,說明了絕對位置嵌入。

另一方面,RoPE 通過相對于其標記位置旋轉查詢和鍵向量來解決這個問題。

然而,在 NoPE 層中,根本沒有添加這樣的位置信號:不是固定的,不是學習的,不是相對的。什么都沒有。

盡管沒有位置嵌入,但由于因果注意力掩碼,模型仍然知道哪些標記在前面。該掩碼防止每個標記關注未來的標記。因此,位于位置 t 的標記只能看到位于位置 ≤ t 的標記,這保留了自回歸排序。

因此,雖然沒有顯式添加位置信息,但模型結構中仍然隱含了一種方向感,并且 LLM 在常規的基于梯度的訓練中,如果發現它有利于優化目標,就可以學會利用它。(查看 NoPE 論文的定理以獲取更多信息。)

因此,總的來說,NoPE 論文不僅發現沒有必要注入位置信息,而且還發現 NoPE 具有更好的長度泛化性,這意味著隨著序列長度的增加,LLM 的回答性能下降較少,如下圖所示。

圖 23:來自 NoPE 論文(https://arxiv.org/abs/2305.19466)的注釋圖,顯示 NoPE 具有更好的長度泛化性。

請注意,上面顯示的實驗是使用一個相對較小的 GPT 風格模型進行的,大約有 1 億個參數,并且相對較小的上下文大小。目前尚不清楚這些發現如何推廣到更大的當代 LLM。

出于這個原因,SmolLM3 團隊可能只在每 4 層中“應用”了 NoPE(或者更準確地說,省略了 RoPE)。

8. Kimi 2

Kimi 2 最近在 AI 社區引起了巨大轟動,因為它是一個具有令人難以置信的性能的開放權重模型。根據基準測試,它與谷歌的 Gemini、Anthropic 的 Claude 和 OpenAI 的 ChatGPT 模型等最佳專有模型不相上下。

一個顯著的方面是它使用了相對較新的 Muon 優化器而不是 AdamW。據我所知,這是 Muon 首次用于這種規模的生產模型(以前,它只被證明可以擴展到 16B)。這導致了非常漂亮的訓練損失曲線,這可能有助于將這個模型推到上述基準測試的頂端。

雖然人們評論說損失異常平滑(由于缺乏尖峰),但我認為它并沒有異常平滑(例如,見下圖中的 OLMo 2 損失曲線;此外,梯度的 L2 范數可能是跟蹤訓練穩定性的更好指標)。然而,令人驚訝的是損失曲線的衰減效果如此之好。

然而,正如本文引言中提到的,訓練方法是另一個主題。

模型本身有 1 萬億個參數,這確實令人印象深刻。

它可能是這一代最大的 LLM(鑒于 Llama 4 Behemoth 尚未發布,專有 LLM 不算在內,谷歌的 1.6 萬億 Switch Transformer 是來自不同代的編碼器-解碼器架構)。

它也圓滿了,因為 Kimi 2 使用了我們在本文開頭介紹的 DeepSeek-V3 架構,只是他們將其做得更大,如下圖所示。

圖 25:DeepSeek V3 和 Kimi K2 的架構比較。

如上圖所示,Kimi 2.5 基本上與 DeepSeek V3 相同,只是它在 MoE 模塊中使用了更多專家,在多頭潛在注意力(MLA)模塊中使用了更少頭。

Kimi 2 并非憑空而來。早期的 Kimi 1.5 模型在 Kimi k1.5: Scaling Reinforcement Learning with LLMs paper中也有討論,同樣令人印象深刻。然而,它很不幸,DeepSeek R1 模型論文恰好于 1 月 22 日同一天發表。此外,據我所知,Kimi 1.5 權重從未公開分享。

因此,Kimi K2 團隊很可能吸取了這些教訓,并在 DeepSeek R2 發布之前將 Kimi K2 作為開放權重模型分享。在撰寫本文時,Kimi K2 是最令人印象深刻的開放權重模型。

這些年過去了,LLM 的發布仍然令人興奮,我很好奇接下來會發生什么!

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

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

相關文章

linux驅動開發筆記--GPIO驅動開發

目錄 前言 一、設備樹配置 二、驅動編寫 三、用戶空間測試 總結 前言 開發平臺:全志A133,開發環境:linux4.9andrio10,開發板:HelperBoard A133_V2.5。 一、設備樹配置 打開板級設備樹配置文件,路徑&a…

騰訊iOA:企業軟件合規與安全的免費守護者

人們眼中的天才之所以卓越非凡,并非天資超人一等而是付出了持續不斷的努力。1萬小時的錘煉是任何人從平凡變成超凡的必要條件。———— 馬爾科姆格拉德威爾 目錄 一、為什么要使用騰訊iOA? 二、中小企業軟件合規痛點 三、騰訊iOA解決方案 3.1 核心技…

C#定時任務實戰指南:從基礎Timer到Hangfire高級應用

高效管理后臺作業,讓定時任務成為應用的可靠引擎 在C#應用開發中,定時任務是實現數據同步、報表生成、系統維護等后臺作業的核心技術。本文將深入探討C#生態中主流的定時任務解決方案,從基礎的內置Timer到強大的Quartz.NET和Hangfire框架&…

軟件開發、項目開發基本步驟

? 立項階段:項目定義、需求收集與分析、可行性分析、風險評估與規劃、項目團隊組建、制定項目計劃、獲取批準與支持。? 需求評審與分析:? 項目團隊(包括產品經理、開發人員、測試人員等)共同參與,明確項目的目標、功…

慢 SQL接口性能優化實戰

在對某電商項目進行接口性能壓測時,發現 /product/search 接口響應緩慢,存在明顯性能瓶頸。通過慢查詢日志排查和 SQL 優化,最終實現了接口響應速度的顯著提升。本文完整還原此次優化過程,特別強調操作步驟和問題分析過程&#xf…

【C#】在WinForms中實現控件跨TabPage共享的優雅方案

文章目錄一、問題背景二、基本實現方案1. 通過修改Parent屬性實現控件移動三、進階優化方案1. 創建控件共享管理類2. 使用用戶控件封裝共享內容四、方案對比與選擇建議五、最佳實踐建議六、完整示例代碼一、問題背景 在Windows窗體應用程序開發中,我們經常遇到需要…

Android Camera openCamera

由頭 今日調休,終于終于閑下來了,可以寫一下博客了,剛好打開自己電腦,就有四年前下的谷歌Android 12源碼,不是很舊,剛好夠用,不用再另外下載新源碼了,不得不感慨這時間過得真快啊~廢…

神經網絡——池化層

目錄 池化層 最大池化層 MaxPool2d 最大池化操作圖示 最大池化操作代碼演示 綜合代碼案例 池化層 池化層(Pooling Layer) 核心作用:通過降采樣減少特征圖尺寸,降低計算量,增強特征魯棒性。 1. 常見類型 …

Android 默認圖庫播放視頻沒有自動循環功能,如何添加2

Android 默認圖庫播放視頻沒有自動循環功能, 如何添加 按如下方式修改可以添加 開發云 - 一站式云服務平臺 --- a/packages/apps/Gallery2/src/com/android/gallery3d/app/MovieActivity.java +++ b/packages/apps/Gallery2/src/com/android/gallery3d/app/MovieActivity.java…

數字孿生賦能智慧能源電力傳輸管理新模式

在“雙碳”戰略和能源數字化轉型的雙重驅動下,智慧能源系統亟需更高效、精細和智能的管理手段。數字孿生技術作為融合物理世界與數字空間的橋梁,為電力傳輸系統的全生命周期管理提供了強有力的技術支撐。本文聚焦數字孿生在智慧能源電力傳輸中的應用&…

Jmeter的元件使用介紹:(二)線程組詳解

Jmeter線程組默認包含三種:線程組、setUp線程組、tearDown線程組。線程組之間的執行順序為:setUp線程組->線程組->tearDown線程組。多數情況都是選用線程組,setUp線程組用于做一些腳本的前置準備,比如:跨線程組設…

AI替代人工:浪潮中的沉浮與覺醒

當AlphaGo以4:1的比分戰勝圍棋大師李世石之時,人機博弈的疆界被重新劃定;當工廠車間里機械臂以驚人精度與不知疲倦的姿態取代了工人重復的手勢;當客服電話那頭響起的不再是溫存人聲,而成了準確但缺乏溫度的AI語音;當算…

數學建模--matplot.pyplot(結尾附線條樣式表格)

matplotlib.pyplot繪圖接口 1. 用法 導入模塊 import matplotlib.pyplot as plt import numpy as np # 用于生成示例數據繪制簡單圖表 # 生成數據 x np.linspace(0, 10, 100) y np.sin(x)# 創建圖形和坐標軸 plt.figure(figsize(8, 4)) # 設置圖表大小 plt.plot(x, y, …

NumPy 實現三維旋轉變換

在三維空間中,物體的旋轉變換是計算機圖形學、機器人學以及三維建模等領域中一個至關重要的操作。這種變換可以通過構造特定的旋轉矩陣并將其應用于三維點或向量來實現。本文將深入探討如何利用 NumPy 這一強大的 Python 科學計算庫來實現三維旋轉變換,從基本的數學原理到具體…

基于Springboot的中藥商城管理系統/基于javaweb的中藥材銷售系統

管理員:登錄,個人中心,用戶管理,藥材分類管理,藥材信息管理,藥材入庫管理, 藥材出庫管理,訂單管理,云端藥館,系統設置用戶:注冊,登錄&…

試用SAP BTP 02A:試用SAP HANA Cloud

進入SAP BTP主控室 -> 子賬 -> 服務市場,選擇【數據和分析】-> 點擊SAP HANA Cloud點擊創建選擇服務、計劃、運行時環境、空間,輸入實例名稱,點擊下一步在JSON文件中配置HANA管理員密碼,點擊下一步審核hana 實例信息&…

純CPU場景下C++的分布式模型訓練框架設計思路

0. 參數分配 稠密參數 → MPI 集合通信(All-Reduce / Broadcast / Reduce-Scatter)。稀疏參數 → brpc Parameter Server 異步推拉。 完全去掉 NCCL/GPU 相關部分。1. 整體拓撲 ┌----------------┐ ┌----------------┐ │ Worker-0 │…

訓練日志7.21

conda環境,服務器原因無法使用,需重新搭建 學習一下預訓練和微調相關內容,對于預訓練整體的流程,還不太清楚,自己估計是訓練不動,只能微調

Java 高頻算法

Java高頻算法面試題 以下是Java面試中常見的高頻算法題目&#xff0c;涵蓋了數據結構、算法思想和實際應用場景。 一、數組與字符串 1. 兩數之和 public int[] twoSum(int[] nums, int target) {Map<Integer, Integer> map new HashMap<>();for (int i 0; i <…

汽車控制系統——CAPL腳本

CAPL (Communication Access Programming Language) 是一種專門用于嵌入式系統和汽車電子測試領域的編程語言&#xff0c;特別是在 CAN (Controller Area Network) 總線和汽車網絡通信系統中被廣泛使用。它由 Vector 公司開發&#xff0c;主要用于編寫與汽車控制單元 (ECU) 進行…