大規模言語モデル（LLM）アーキテクチャ徹底比較
非常に優れた記事を見つけました――大規模LLMアーキテクチャの比較です。この記事では、Llama-3.2、Qwen3-4B、SmolLM3-3B、DeepSeek-V3、Qwen3-235B-A22B、Kimi-K2のアーキテクチャを挙げ、その違いと利点を詳細に論じています。大規模モデルを学習している方にはぜひ読んでほしいです！
英語記事：https://sebastianraschka.com/blog/2025/the-big-llm-architecture-comparison.html
最初のGPTアーキテクチャが登場してから7年以上が経過しました。一見すると、2019年のGPT-2から2024-2025年のDeepSeek-V3やLlama 4に至るまで、これらのモデルが構造的に高い類似性を保っていることに驚くかもしれません。
もちろん、位置埋め込み（positional embeddings）は絶対位置符号化（absolute positional encoding）から回転位置埋め込み（RoPE）へと進化し、マルチヘッドアテンション（Multi-Head Attention, MHA）も概ねグループ化クエリ・アテンション（Grouped-Query Attention, GQA）に取って代わられ、より効率的なSwiGLU活性化関数がGELUなどを置き換えるなど、変化はありました。しかし、これらの微細な改善の背後で、私たちは真の画期的な変革を見ているのでしょうか、それとも単に既存のアーキテクチャを磨き上げているだけなのでしょうか？
異なるLLMを比較し、その性能（良いか悪いかに関わらず）に影響を与える重要な要因を見つけることは極めて困難です。データセット、訓練技術、ハイパーパラメータは大きく異なり、詳細な記録が不足していることが多いからです。
しかし、私は2025年のLLM開発者の最新動向を理解するために、アーキテクチャ自体の構造変化を深く掘り下げることには依然として大きな価値があると考えています（一部のアーキテクチャは図1に示されています）。
図1：本記事で取り上げる一部のアーキテクチャ。
したがって、この記事では、ベンチマーク性能や訓練アルゴリズムについては議論せず、現在の主要なオープンソースモデルのアーキテクチャの発展に焦点を当てます。
目次
1. DeepSeek V3/R1
1.1 マルチヘッド潜在アテンション (MLA)
1.2 専門家混合 (MoE)
1.3 DeepSeek まとめ
2. OLMo 2
2.1 正規化層の配置
2.2 QK-ノルム (QK-Norm)
2.3 OLMo 2 まとめ
3. Gemma 3
3.1 スライディングウィンドウアテンション
3.2 Gemma 3における正規化層の配置
3.3 Gemma 3まとめ
3.4 Gemma 3n
4. Mistral Small 3.1
5. Llama 4
6. Qwen3
6.1 Qwen3 (密集モデル)
6.2 Qwen3 (MoE)
7.SmolLM3
7.1 位置埋め込みなし (NoPE)
8. Kimi 2
1. DeepSeek V3/R1
DeepSeek R1が2025年1月にリリースされた際、大きな反響を呼んだことはすでにご存知かもしれません。DeepSeek R1は、2024年12月に登場したDeepSeek V3アーキテクチャに基づいて構築された推論モデルです。
この記事の焦点は2025年にリリースされたアーキテクチャですが、DeepSeek V3を含めることは妥当だと筆者は考えます。なぜなら、2025年のDeepSeek R1のリリースに伴って広く注目され、応用されるようになったからです。
DeepSeek R1の具体的な訓練プロセスに興味がある場合は、私が今年初めに書いた推論LLMを深く理解するための記事が役立つかもしれません。
このセクションでは、DeepSeek V3に導入された2つの主要なアーキテクチャ技術に焦点を当てます。これらは計算効率を向上させ、他の多くのLLMとは異なる特徴を持っています。
マルチヘッド潜在アテンション（Multi-Head Latent Attention, MLA）
専門家混合（Mixture-of-Experts, MoE）
1.1 マルチヘッド潜在アテンション (MLA)
マルチヘッド潜在アテンション（MLA）について議論する前に、その応用動機を理解するために、関連する背景知識を簡単に振り返りましょう。そのため、まずグループ化クエリ・アテンション（GQA）から説明します。近年、GQAは計算効率とパラメータ効率に優れているため、マルチヘッドアテンション（MHA）の新しい標準的な代替手段となっています。
GQAの核となる考え方は、簡単に次のようにまとめられます。MHAでは各アテンションヘッドがそれぞれ独立したキー（key）とバリュー（value）を持つのですが、メモリ使用量を減らすために、GQAは複数のクエリヘッドをグループ化し、それらが同じキーとバリューの投影を共有するようにします。
例えば、図2に示すように、2つのキーバリューグループと4つのアテンションヘッドがある場合、アテンションヘッド1と2が1つのキーバリューセットを共有し、アテンションヘッド3と4が別のセットを共有する可能性があります。これにより、キーバリュー計算の総量が減少し、結果としてメモリ使用量が削減され、効率が向上します（アブレーション研究によると、モデル性能に顕著な影響はありません）。
図2：MHAとGQAの比較。ここではグループサイズが2で、これは1つのキーバリューペアが2つのクエリによって共有されることを意味します。
したがって、GQAの核となる考え方は、複数のクエリヘッドがキー（key）とバリュー（value）を共有することで、キーバリューヘッドの数を減らすことです。これにより、（1）モデルのパラメータ数が削減されるだけでなく、（2）推論時のキーバリューテンソル（tensor）のメモリ帯域使用量が減少します。これは、KVキャッシュに格納およびKVキャッシュから取得する必要があるキーバリューが少なくなるためです。
（GQAのコード実装に興味がある場合は、私のGPT-2からLlama 3への変換ガイドをご覧ください。そこにはKVキャッシュなしのバージョンが含まれています。KVキャッシュありのバージョンはこちらで確認できます。）
GQAは主にMHAの計算効率不足を補うための回避策ですが、アブレーション研究（例：GQAの原論文やLlama 2論文の研究）は、LLMモデリング性能の点で標準的なMHAと同等の性能を示すことを示しています。
さて、マルチヘッド潜在アテンション（MLA）は、特にKVキャッシュに適用できる異なるメモリ節約戦略を提案しています。GQAがキー（key）とバリュー（value）ヘッドを共有するのに対し、MLAはキーとバリューのテンソルをKVキャッシュに格納する前に、より低い次元の空間に圧縮します。
推論時、これらの圧縮されたテンソルは使用前に元のサイズに復元されます。これは図3に示されています。これにより、追加の行列乗算演算が増えますが、メモリ使用量が大幅に削減されます。
図3：MLA（DeepSeek V3およびR1で使用）と通常MHAの比較。
（ちなみに、クエリ（Queries）も圧縮されますが、訓練期間中のみで、推論期間中ではありません。）
さらに、MLAはDeepSeek V3の新しい内容ではなく、そのDeepSeek-V2の前身もこの技術を使用（あるいは初めて導入）していました。V2の論文には興味深いアブレーション研究も含まれており、これがDeepSeekチームがGQAではなくMLAを選択した理由を説明するかもしれません（図4を参照）。
図4：DeepSeek-V2論文からの注釈付き表、https://arxiv.org/abs/2405.04434
図4に示すように、GQAの性能はMHAに劣るようですが、MLAはモデル性能の点でMHAをわずかに上回っており、これがDeepSeekチームがGQAではなくMLAを選択した理由である可能性が高いです。（MLAとGQA間の「トークンごとのKVキャッシュ」の節約量の比較が見られれば、もっと面白いでしょう！）
次のアーキテクチャコンポーネントに進む前に、このセクションをまとめましょう。MLAは、KVキャッシュのメモリ使用量を削減し、モデル性能の点でMHAをわずかに上回る巧妙なテクニックです。
1.2 専門家混合 (MoE)
DeepSeekにおけるもう一つの注目すべき主要なアーキテクチャコンポーネントは、専門家混合（MoE）層の応用です。MoEはDeepSeek独自のものではありませんが、今年に入って再び普及しており、後で議論する多くのモデルでもこの手法が採用されています。
MoEについてはすでにご存知かもしれませんが、簡単に復習しておくと役立つかもしれません。MoEの核となる考え方は、Transformerブロック内の各フィードフォワードネットワーク（FeedForward）モジュールを複数の専門家層（各専門家層もフィードフォワードネットワークモジュール）に置き換えることです。これは、単一のフィードフォワード層を複数のフィードフォワード層に置き換えることを意味し、図5に示されています。
図5：DeepSeek V3/R1における専門家混合（MoE）モジュール（右）と標準的なフィードフォワードブロックを使用するLLM（左）の模式図。
Transformerブロック内部のフィードフォワードネットワーク（図中の濃い灰色のモジュール）は通常、モデルの総パラメータの大部分を占めます。（TransformerブロックとフィードフォワードネットワークはLLM内で何度も繰り返されることに注意してください。DeepSeek-V3では61回繰り返されます。）
したがって、単一のフィードフォワードブロックを複数のフィードフォワードブロック（MoE設定で行われるように）に置き換えることは、モデルの総パラメータ数を大幅に増加させます。しかし、ここでの重要なトリックは、各トークンに対してすべての専門家を使用（「活性化」）しないことです。代わりに、ルーティングメカニズムが各トークンに対して少数の専門家を選択します。（時間の節約のため、あるいは記事の長さのため、ルーティング戦略については後でより詳細に説明します。）
一度に少数の専門家しか活性化されないため、MoEモジュールは通常「スパース」モジュールと呼ばれ、常に全パラメータセットを使用する「密」モジュールとは対照的です。しかし、MoEは大量のパラメータによってLLMの容量を増加させます。これは、訓練期間中にり多くの知識を吸収できることを意味します。スパース性は推論効率を維持します。これは、すべてのパラメータを同時に使用しないためです。
例えば、DeepSeek-V3の各MoEモジュールには256人の専門家がおり、モデルの総パラメータ数は6,710億に達します。しかし、推論時には、毎回9人の専門家（1人の共有専門家とルーティングによって選択された8人の専門家）しか活性化されません。これは、各推論ステップで370億パラメータしか使用されないことを意味し、全6,710億ではありません。DeepSeek-V3のMoE設計における顕著な特徴は、「共有専門家」の使用です。これは、常に各トークンに対して活性化される専門家です。このアイデアは新しいものではなく、DeepSeek 2024 MoEと2022年のDeepSpeedMoE論文で既に導入されています。
図6：「DeepSeekMoE：専門家混合言語モデルにおける究極の専門家特化の達成」からの注釈付き図、https://arxiv.org/abs/2401.06066
DeepSpeedMoE論文では、共有専門家の利点が初めて指摘され、共有専門家がない場合と比較して、全体のモデル性能が向上することが発見されました。これは、一般的または反復的なパターンを複数の独立した専門家がそれぞれ学習する必要がなくなり、それらの専門家がより特殊化されたパターンを学習するための余地が増えるためであると考えられます。
1.3 DeepSeek まとめ
要するに、DeepSeek-V3は6,710億パラメータを持つ大規模モデルであり、リリース時には4,050億パラメータのLlama3を含む他のオープンソースモデルを上回る性能を示しました。体積は大きいものの、専門家混合（MoE）アーキテクチャのおかげで、推論時には効率が高く、各トークンで活性化されるパラメータはごく一部（わずか370億）に過ぎません。
もう一つの重要な特徴は、DeepSeek-V3がグループ化クエリ・アテンション（GQA）ではなく、マルチヘッド潜在アテンション（MLA）を採用していることです。MLAとGQAはどちらも標準のマルチヘッドアテンション（MHA）の推論効率の高い代替手段であり、特にKVキャッシュを使用する場合に有効です。MLAの実装はより複雑ですが、DeepSeek-V2の論文の研究によると、GQAよりも優れたモデル性能を持っています。
2. OLMo 2
アレン人工知能研究所（Allen Institute for AI）が開発した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-ノルムの追加であり、これらについては以下で議論します。
特筆すべきは、OLMo 2がMLAやGQAではなく、依然として従来のマルチヘッドアテンション（MHA）を使用している点です。
2.1 正規化層の配置
全体的に、OLMo 2は従来のGPTモデルのアーキテクチャを大きく踏襲しており、他の現代のLLMと同様です。しかし、いくつか注目すべき逸脱点があります。正規化層から見ていきましょう。
Llama、Gemma、そして他のほとんどの大規模言語モデルと同様に、OLMo 2もLayerNormからRMSNormに切り替わっています。
しかし、RMSNormはすでに「おなじみ」であるため（本質的にはLayerNormの簡略版で、訓練可能なパラメータが少ない）、筆者はRMSNormとLayerNormの議論は割愛します。（興味のある読者は、私のGPT-2からLlamaへの変換ガイドでRMSNormのコード実装を見つけることができます。）
ただし、RMSNorm層の配置場所については議論する価値があります。元のTransformerモデル（「Attention is all you need」論文から）は、Transformerブロックのアテンションモジュールとフィードフォワードモジュールの「後」にそれぞれ2つの正規化層を配置していました。
これは後正規化（Post-LN または Post-Norm）とも呼ばれます。
GPTモデルとその後の多くのLLMは、正規化層をアテンションモジュールとフィードフォワードモジュールの「前」に配置しました。これは前正規化（Pre-LN または Pre-Norm）と呼ばれます。後正規化と前正規化の比較を図に示します。
図8：後正規化、前正規化、およびOLMo 2の後正規化バリアントの比較。
2020年、Xiongらの研究は、前正規化（Pre-LN）が初期化時に望ましい勾配挙動を生み出すことを示しました。さらに、研究者らは、前正規化が学習率ウォームアップを慎重に調整しなくても良好な性能を示すのに対し、学習率ウォームアップは後正規化（Post-LN）にとって不可欠なツールであると指摘しました。
さて、私がこの点を持ち出したのは、OLMo 2が後正規化形式を採用しているからです（ただし、LayerNormではなくRMSNormを使用しているため、私はそれを「Post-Norm」と呼んでいます）。OLMo 2では、正規化層はアテンション層とフィードフォワード層の前に置かれるのではなく、その後に置かれます。これは上記の図に示されています。ただし、元のTransformerアーキテクチャとは異なり、これらの正規化層は依然として残差層（スキップ接続）の内部に位置していることに注意してください。
では、なぜ彼らは正規化層の位置を変更したのでしょうか？その理由は、訓練の安定性に貢献するからです。これは以下の図に示されています。
図9：前正規化（GPT-2、Llama 3など多くのモデルと同様）とOLMo 2の後正規化バリアントの訓練安定性を比較するグラフ。
残念ながら、この図はリオーダーとQK-ノルムの組み合わせの結果を示しており、QK-ノルムは独立したメカニズムです。したがって、正規化層のリオーダー自体がどれだけ貢献したかを判断するのは困難です。
2.2 QK-ノルム (QK-Norm)
前節でQK-ノルムに触れたので、そしてGemma 2やGemma 3など、後で議論する他のLLMもQK-ノルムを使用しているので、簡単にこれが何であるかについて議論しましょう。
QK-ノルムは本質的に別のRMSNorm層です。それはマルチヘッドアテンション（MHA）モジュール内部に配置され、回転位置埋め込み（RoPE）を適用する前に、クエリ（q）とキー（k）に適用されます。これを説明するために、私がQwen3をゼロから実装するために書いたグループ化クエリ・アテンション（GQA）層の抜粋を以下に示します（GQAにおけるQK-ノルムの適用は、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 = None def 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) # RoPEの適用 queries = 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-ノルムは後正規化と協調して機能し、訓練プロセスを共同で安定させます。QK-ノルムはOLMo 2が発明したものではなく、その概念は2023年の「拡張視覚Transformer」論文に遡ることに注意が必要です。
2.3 OLMo 2 まとめ
簡単に言えば、OLMo 2の注目すべきアーキテクチャ設計上の決定は、主にRMSNormの配置にあります。RMSNormをアテンションモジュールとフィードフォワードモジュールの「後」に配置する（後正規化の一種）こと、そしてアテンションメカニズム内部でクエリ（queries）とキー（keys）にRMSNorm（QK-ノルム）を追加することです。これら二つが連携して訓練損失の安定化に貢献しています。
以下はOLMo 2とLlama 3の並列比較図です。OLMo 2が依然として従来のMHAを使用し、GQAを使用していない点を除けば、両者のアーキテクチャは比較的類似していることがわかります。（ただし、OLMo 2チームは3ヶ月後にGQAを使用した320億パラメータのバリアントをリリースしました。）
図10：Llama 3とOLMo 2のアーキテクチャ比較。
3. Gemma 3
GoogleのGemmaモデルは常に優れた性能を発揮しており、私の意見では、Llamaシリーズなどの他の人気モデルほど注目されていないように感じます。
Gemmaのユニークな点は、その比較的大きな語彙量（多言語をより良くサポートするため）と、270億パラメータのモデルサイズに重点を置いていることです（80億や700億ではありません）。ただし、Gemma 2も10億、40億、120億といったより小さなサイズを提供していました。
270億パラメータというサイズは非常に良いバランスが取れています。80億パラメータのモデルよりもはるかに強力ですが、700億パラメータのモデルほどリソースを消費せず、私のMac Miniでもスムーズに動作します。では、Gemma 3には他にどのような注目すべき特徴があるのでしょうか？前述のDeepSeek-V3/R1などのモデルが、固定されたモデルサイズで推論に必要なメモリを削減するために専門家混合（MoE）アーキテクチャを採用しているように（MoE手法は後で議論する他の複数のモデルでも採用されています）。
Gemma 3は、計算コストを削減するために異なる「トリック」、すなわちスライディングウィンドウアテンション（sliding window attention）を採用しています。
3.1 スライディングウィンドウアテンション
スライディングウィンドウアテンション（元々は2020年のLongFormer論文によって導入され、Gemma 2でも採用されていました）を活用することで、Gemma 3チームはKVキャッシュのメモリ要件を大幅に削減しました。これは以下の図に示されています。
図11：Gemma 3論文（https://arxiv.org/abs/2503.19786）からの注釈付き図。スライディングウィンドウアテンションによるKVキャッシュメモリの節約を示しています。
では、スライディングウィンドウアテンションとは何でしょうか？通常の自己アテンションメカニズムが、各シーケンス要素が他のすべてのシーケンス要素にアクセスできる「グローバル」アテンションメカニズムであると考えるならば、スライディングウィンドウアテンションは、現在のクエリ位置周辺のコンテキストサイズを制限するため、「ローカル」アテンションメカニズムと見なすことができます。これは以下の図に示されています。
図12：通常のアテンション（左）とスライディングウィンドウアテンション（右）の比較。
スライディングウィンドウアテンションは、マルチヘッドアテンション（MHA）およびグループ化クエリ・アテンション（GQA）と組み合わせて使用できることに注意してください。Gemma 3はグループ化クエリ・アテンションを使用しています。
前述のように、スライディングウィンドウアテンションは「ローカル」アテンションとも呼ばれます。これは、ローカルウィンドウが現在のクエリ位置を中心に移動するためです。対照的に、通常の注意は「グローバル」であり、すべてのトークンが他のすべてのトークンにアクセスできます。
さて、前述の通り、Gemma 2の先行アーキテクチャもスライディングウィンドウアテンションを使用していました。Gemma 3との違いは、グローバル（通常）アテンションとローカル（スライディング）アテンションの比率を調整した点です。
例えば、Gemma 2は、スライディングウィンドウ（ローカル）アテンションとグローバルアテンションを1：1の比率で組み合わせた混合アテンションメカニズムを採用していました。各トークンは、その周辺の4kトークンのウィンドウに注目することができました。
Gemma 2では1層おきにスライディングウィンドウアテンションを使用していましたが、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 Gemma 3における正規化層の配置
小さな、しかし興味深い詳細として、Gemma 3はグループ化クエリ・アテンションモジュールの前後にRMSNormを使用しており、これは前正規化（Pre-Norm）と後正規化（Post-Norm）の両方の設定を同時に採用していることを意味します。
これはGemma 2と似ていますが、それでも強調する価値があります。なぜなら、これは（1）元のTransformer（「Attention is all you need」から）で使用された後正規化、（2）GPT-2によって普及し、その後他の多くのアーキテクチャで使用された前正規化、そして（3）以前に見たOLMo 2の後正規化バリアントとは異なるからです。
図14：OLMo2とGemma 3のアーキテクチャ比較。Gemma 3の追加の正規化層に注目してください。
この正規化層の配置方法は、前正規化と後正規化の両方の利点を兼ね備えているため、比較的直感的だと筆者は考えています。筆者から見れば、少し多めに正規化することは常に良いことです。最悪の場合、余分な正規化が冗長であれば、それは単に非効率につながるだけです。しかし、実際のアプリケーションでは、RMSNormの計算コストは比較的低いため、これは顕著な影響を与えないはずです。
3.3 Gemma 3 まとめ
要するに、Gemma 3は優れた性能を持つオープンソースLLMであり、筆者から見れば、オープンソースコミュニティでは多少過小評価されています。その最も興味深い点は、スライディングウィンドウアテンションを利用して効率を向上させていることです（将来的にMoEと組み合わせると興味深いでしょう）。
さらに、Gemma 3は、アテンションモジュールとフィードフォワードモジュールの両方の前後にRMSNorm層を配置するという、独自の正規化層の配置を行っています。
3.4 Gemma 3n
Gemma 3がリリースされて数ヶ月後、GoogleはGemma 3nを発表しました。これは小型デバイスの効率に最適化されたGemma 3モデルで、スマートフォンでの動作を目標としています。
Gemma 3nがより高い効率を達成するための変更点の一つに、「逐層埋め込みパラメータ層（Per-Layer Embedding, PLE）」と呼ばれるものがあります。その核となる考え方は、モデルパラメータのサブセットのみをGPUメモリに保持することです。テキスト、オーディオ、ビジュアルモーダリティなどのトークン層固有の埋め込みは、必要に応じてCPUまたはSSDからストリーミングされます。
以下の図は、標準的なGemma 3モデルの54.4億パラメータにおけるPLEのメモリ節約効果を示しています。これはおそらくGemma 3の40億パラメータバリアントを指していると思われます。
図15：Google Gemma 3nブログ（https://developers.googleblog.com/en/introducing-gemma-3n/）からの注釈付き図。PLEによるメモリ節約を説明しています。
54.4億パラメータと40億パラメータの違いは、GoogleがLLMのパラメータ数を報告する際に採用している興味深い方法に起因します。彼らは通常、モデルを小さく見せるために埋め込みパラメータを除外しますが、この場合はモデルを大きく見せるために含めるのが都合が良いというわけです。この慣行はGoogleに限ったことではなく、業界全体で一般的になっています。
もう一つの興味深いトリックは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の推論遅延が低い理由は、そのカスタマイズされたトークナイザ、および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（6,710億パラメータ）とLlama 4 Maverick（4,000億パラメータ）のアーキテクチャ比較。
Llama 4 Maverickの全体的なアーキテクチャはDeepSeek-V3と非常に似ていますが、いくつか強調すべき興味深い違いがあります。
まず、Llama 4は、その前身と同様にグループ化クエリ・アテンション（GQA）を使用していますが、DeepSeek-V3は本記事の冒頭で議論したマルチヘッド潜在アテンション（MLA）を採用しています。現在、DeepSeek-V3とLlama 4 Maverickはどちらも非常に大規模なアーキテクチャであり、DeepSeek-V3の総パラメータ数はLlama 4 Maverickよりも約68%大きいです。しかし、DeepSeek-V3は370億のアクティブパラメータを持っており、Llama 4 Maverick（170億）のアクティブパラメータの2倍以上です。
Llama 4 Maverickは、専門家数が少なく規模が大きい（2人のアクティブ専門家、各隠れ層サイズ8192）という、より古典的なMoE設定を採用しているのに対し、DeepSeek-V3は9人のアクティブ専門家、各隠れ層サイズ2048を持っています。さらに、DeepSeekは各Transformerブロック（最初の3つを除く）でMoE層を使用していますが、Llama 4は1つおきのTransformerブロックでMoEと密なモジュールを交互に使用しています。
アーキテクチャ間の数多くの微妙な違いを考慮すると、それらが最終的なモデル性能に与える影響を正確に判断するのは容易ではありません。しかし、主な結論は、専門家混合（MoE）アーキテクチャが2025年に著しく人気が高まっているということです。
6. Qwen3
通義千問（Qwen）チームは、高品質なオープンソースLLMの提供に尽力してきました。私がNeurIPS 2023でLLM効率チャレンジの共同指導を支援した際、最優秀受賞ソリューションはすべてQwen2をベースにしていたことを覚えています。
現在、Qwen3は別の人気モデルシリーズであり、それぞれの規模カテゴリでランキングのトップに位置しています。7つの密集モデル（0.6B、1.7B、4B、8B、14B、32B）に加え、2つのMoEモデル（30B-A3B、235B-A22B）があります。
（ちなみに、「Qwen3」にスペースがないのは誤植ではありません。筆者は通義千問の開発者が選択した元のスペルを維持するよう努めただけです。）
6.1 Qwen3 (密集モデル)
まず、密集モデルのアーキテクチャについて議論しましょう。本記事執筆時点で、0.6Bモデルは現在の世代で最小のオープンソースモデルである可能性が高いです。筆者の個人的な経験によると、この小さなサイズでも非常に優れたモデル性能を発揮します。ローカルで実行する予定の場合、毎秒トークンあたりのスループットが非常に高く、メモリ消費量も低いです。さらに重要なのは、そのコンパクトなサイズのため、ローカルでの訓練も容易であるということです（教育目的の場合）。
したがって、Qwen3 0.6Bは多くの場合、Llama 3 1Bに取って代わられています。これら2つのアーキテクチャの比較を以下の図に示します。
図18：Qwen3 0.6BとLlama 3 1Bのアーキテクチャ比較。Qwen3が層数が多くより深いアーキテクチャであるのに対し、Llama 3はアテンションヘッドが多くより幅広なアーキテクチャであることに注目してください。
外部のサードパーティ製LLMライブラリに依存しない、読みやすいQwen3の実装に興味がある場合は、私が最近ゼロから（純粋なPyTorchで）Qwen3を実装しました。
上図に示されている計算性能データは、A100 GPU上で実行した私のゼロからのPyTorch実装に基づいています。Qwen3は全体的なアーキテクチャが小さく、隠れ層とアテンションヘッドも少ないため、メモリ占有量が小さいことがわかります。しかし、Llama 3よりも多くのTransformerブロックを使用しているため、実行速度は遅くなります（毎秒のトークン生成速度が低い）。
6.2 Qwen3 (MoE)
前述のとおり、Qwen3も2種類のMoEバージョンを提供しています。30B-A3Bと235B-A22Bです。なぜQwen3のような一部のアーキテクチャは、通常の（密な）バージョンとMoE（疎な）バージョンの両方を提供するのでしょうか？
本記事の冒頭で述べたように、MoEバリアントは大規模な基盤モデルの推論コストを削減するのに役立ちます。密なバージョンとMoEバージョンの両方を提供することで、ユーザーの目的と制約に基づいて柔軟性を提供できます。
密なモデルは一般的に、さまざまなハードウェアでのファインチューニング、デプロイ、最適化が容易です。
一方、MoEモデルは大規模推論向けに最適化されています。例えば、固定された推論予算で、より高い全体のモデル容量（つまり、モデルが大きいため訓練中にり多くの知識を吸収できる）を実現でき、推論コストを比例的に増加させる必要がありません。
これら2つのタイプをリリースすることで、Qwen3シリーズはより幅広いユースケースをサポートできます。密なモデルは堅牢性、シンプルさ、ファインチューニングに適しており、MoEモデルは効率的な大規模サービスに適しています。
このセクションをまとめるために、DeepSeek-V3とQwen3 235B-A22B（A22Bは「220億アクティブパラメータ」を意味することに注意）を比較してみましょう。前者のアクティブパラメータは後者のほぼ2倍（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億パラメータのモデルサイズで非常に優れたモデル性能を提供する点で、含める価値のある興味深いモデルだと筆者は考えます。その規模は、17億パラメータと40億パラメータのQwen3モデルの間に位置します。これは以下の図に示されています。
さらに、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 位置埋め込みなし (NoPE)
LLMアプリケーションにおける位置埋め込みなし（NoPE）は、2023年の論文（「Transformerにおける長さ汎化能力に対する位置符号化の影響」）に遡る比較的新しい概念であり、明示的な位置情報注入（例えば、初期の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がより優れた長さ汎化能力を持つことを示しています。
上記の実験は、約1億パラメータの比較的小さなGPTスタイルのモデルと、比較的小さなコンテキストサイズを使用して行われたことに注意してください。これらの発見が、より大規模な現代のLLMにどれだけ一般化できるかは、現時点では不明です。
したがって、SmolLM3チームは、4層ごとにNoPEを「適用」（またはRoPEを省略）しただけなのかもしれません。
8. Kimi 2
Kimi 2は最近、その優れた性能を持つオープンソースモデルとしてAIコミュニティで大きな話題を呼んでいます。ベンチマークによると、GoogleのGemini、AnthropicのClaude、OpenAIのChatGPTといったトップクラスのクローズドソースモデルに匹敵します。
特筆すべきは、AdamWではなく、比較的新しいMuon最適化器のバリアントを使用している点です。筆者の知る限り、Muonがこれほどの規模のプロダクションモデルで使用されたのは初めてであり、これまでは160億パラメータまでしか拡張できることが証明されていませんでした。これにより、優れた訓練損失曲線が実現されており、これがこのモデルを前述のベンチマークのトップに押し上げる一因となった可能性があります。
損失が異常に滑らかである（スパイクがないため）とコメントする人もいますが、筆者はそれが異常に滑らかであるとは考えていません（例：以下の図のOLMo 2の損失曲線を参照。また、勾配のL2ノルムの方が訓練安定性をより良く測定できるかもしれません）。しかし、その損失曲線の減衰度合いは確かに注目に値します。
ただし、本記事の導入で述べたように、訓練方法論は別の話題であり、後で議論することにします。
このモデル自体は1兆パラメータを誇り、これは確かに印象的です。
本記事執筆時点で、これはおそらくこの世代で最大のLLMでしょう（Llama 4 Behemothがまだリリースされていないこと、クローズドソースLLMは含まれないこと、そしてGoogleの1.6兆パラメータのSwitch Transformerが別世代のエンコーダー-デコーダーアーキテクチャであることを考慮すると）。
Kimi 2もまた、本記事の冒頭で紹介したDeepSeek-V3アーキテクチャを踏襲しており、単にその規模を拡大しただけです。これは以下の図に示されています。
図25：DeepSeek V3とKimi K2のアーキテクチャ比較。
図に示すように、Kimi 2とDeepSeek V3は基本的に同じですが、Kimi 2は専門家混合（MoE）モジュールにより多くの専門家を使用し、マルチヘッド潜在アテンション（MLA）モジュールではより少ないヘッドを使用しています。
Kimi 2は突然登場したわけではありません。以前にKimik1.5：強化学習とLLMスケールの論文で議論されたKimi 1.5モデルも同様に印象的でした。しかし、残念ながら、DeepSeek R1モデル論文と同じ日（1月22日）にリリースされました。さらに、筆者の知る限り、Kimi 1.5の重みは公開されたことがありません。
したがって、Kimi K2チームはこれらの教訓を学び、DeepSeek R2がリリースされる前にKimi K2をオープンソースモデルとして共有した可能性が高いです。本記事執筆時点で、Kimi K2は最も印象的なオープンソースモデルです。
この記事が役立ったと思ったら、「いいね」や「お気に入り」を忘れずに。
>/ 著者：致Great
>/ 著者：転載歓迎、出典明記をお願いします