對于問題「北京是中國的首都」，需要推理嗎？
應該是不需要，地球人都知道

但現在，Transformer 只有一種處理方式：全靠算

DeepSeek 大半夜的，發(fā)布了一篇新論文
Conditional Memory via Scalable Lookup:A New Axis of Sparsity for Large Language Models

https://github.com/deepseek-ai/Engram

這篇論文中，做了一個新方法 Engram，并給到觀點：
該查表的查表，該算的算，兩件事分開處理

對此，他們 Engram 的模塊，專門負責「查」，和負責「算」的 MoE 配合使用

結果就是，Engram-27B 在等參數、等算力條件下，全面超越純 MoE baseline

代碼已開源：
https://github.com/deepseek-ai/Engram

一個具體的例子

論文里有個很直觀的案例

模型處理「Diana, Princess of Wales」這個實體時，內部發(fā)生了什么：

層數

模型此時「認為」這是什么

第 1-2 層

Wales，一個國家

第 3 層

Wales，歐洲的一個國家

第 4 層

Princess of Wales，一個頭銜

第 5 層

Princess of Wales，威爾士親王的妻子

第 6 層

Diana, Princess of Wales，戴安娜王妃

六層網絡，才把這個實體識別出來

但「戴安娜王妃」這個知識是固定的，不會因為上下文變化而變化。模型花六層來「算」出這個結果，本質上是在用計算重建一個靜態(tài)的查找表

這六層深度，本可以用來處理更復雜的推理任務

Engram 怎么做

技術方案不復雜：用連續(xù)幾個 token（N-gram）作為「查詢詞」，從一個大表里查出對應的向量，融合到模型的中間狀態(tài)里

幾個關鍵設計：

詞表壓縮

標準分詞器會給「Apple」和「apple」分配不同的 ID，但它們語義上是同一個東西。Engram 先做一層歸并，把這類 token 映射到同一個規(guī)范化 ID

實測 128k 詞表壓縮了 23%

多頭哈希

不可能真的存下所有 N-gram 組合，那是天文數字。用哈希函數把 N-gram 映射到有限大小的表里，犧牲一點精度換存儲空間

上下文門控

查出來的向量是「靜態(tài)先驗」，可能和當前上下文不匹配。比如「蘋果」在討論水果時和討論手機時含義不同

解決方案：用當前位置的隱藏狀態(tài)（已經通過 Attention 聚合了上下文信息）作為「裁判」，給查出來的向量打分。語義不匹配時，把這個向量的權重壓低

放在哪一層

Engram 不是每層都加。放太淺，隱藏狀態(tài)還沒積累足夠上下文，「裁判」不準；放太深，錯過了分擔早期層負擔的時機

實驗發(fā)現：放在第 2 層效果最好。如果要放兩個，第 2 層和第 15 層的組合最優(yōu)

參數怎么分配

這里有個核心問題：給定固定的參數預算，多少給 MoE，多少給 Engram？

論文定義了一個分配比例 ρ

• ? ρ = 100%：全給 MoE，沒有 Engram

• ? ρ = 0%：全給 Engram，沒有 MoE 的路由專家

實驗掃了一遍，結果是 U 型曲線：

這兩個極端，都不好

全給 MoE（ρ = 100%）：沒有專門的記憶模塊，模型被迫用計算來重建靜態(tài)知識

全給 Engram（ρ → 0%）：失去了動態(tài)計算能力，復雜推理做不了

最優(yōu)點在 75%-80%

也就是說，把 20-25% 的稀疏參數從 MoE 轉給 Engram，效果最好

這個比例在不同的計算預算下都穩(wěn)定，有一定的普適性

效果數據

四個模型對比：

• ? Dense-4B：稠密模型，基線

• ? MoE-27B：純 MoE 架構

• ? Engram-27B：把 MoE-27B 的 72 個路由專家減到 55 個，省出的參數給 5.7B 的 Engram

• ? Engram-40B：進一步擴大 Engram 到 18.5B

全部訓練 262B tokens，激活參數都是 3.8B（等算力）

挑幾個關鍵數據：

任務類型

具體任務

MoE-27B

Engram-27B

提升

知識

MMLU

57.4

60.4

+3.0

知識

CMMLU（中文）

57.9

61.9

+4.0

推理

BBH

50.9

55.9

+5.0

推理

ARC-Challenge

70.1

73.8

+3.7

代碼

HumanEval

37.8

40.8

+3.0

數學

MATH

28.3

30.7

+2.4

知識類任務提升在預期內，畢竟加了個「記憶」模塊

但推理類任務提升更大，這就有意思了

一個「記憶」模塊，怎么讓「推理」能力變強？

為什么推理也變強了

這是論文最有價值的部分

他們用了兩個分析工具

LogitLens：看每一層輸出的預測置信度

結果：Engram 模型在早期層就達到了高置信度，預測收斂速度明顯更快

CKA：看不同層之間的表示相似度

結果：Engram 模型第 5 層的表示，和 MoE 模型第 12 層的表示最相似

這說明什么？

Engram 等效于增加了網絡的有效深度

邏輯是這樣的：有了 Engram 分擔靜態(tài)知識的檢索，早期層不用再花深度做這件事。省出來的深度，可以用于更復雜的推理

Attention 的容量也被釋放了。本來要處理局部依賴（比如識別「張仲景」是一個人名）的注意力頭，現在可以專注于全局上下文

長上下文任務上這個效果更明顯：

任務

MoE-27B

Engram-27B

Multi-Query NIAH

84.2

97.0

Variable Tracking

77.0

89.0

Engram 到底存了什么

做了個消融實驗：把 Engram 的輸出完全屏蔽，看各類任務的性能保留多少

• ? 事實問答（TriviaQA）：只剩 29%

• ? 閱讀理解（C3）：保留 93%

• ? 推理任務：居中

結論很清晰：

事實知識主要存在 Engram 里，屏蔽后崩得厲害

閱讀理解依賴上下文，答案就在文章里，Engram 幫不上忙

推理任務的提升是間接的，來自 Engram 釋放的網絡深度，而不是 Engram 直接提供推理能力

門控可視化

紅色表示門控激活（采納了查表結果），顏色越深激活越強

規(guī)律很明顯：

• ? 多 token 實體觸發(fā)高激活：「Alexander the Great」「Milky Way」「Princess of Wales」

• ? 固定搭配觸發(fā)高激活：「By the way」

• ? 中文也能識別：「四大發(fā)明」「張仲景」「醫(yī)圣」「傷寒雜病論」

需要結合上下文理解的 token，門控會壓低

工程：offload 效率

這部分對開發(fā)者有參考價值

Engram 的查表索引是確定的。知道輸入是什么 token，就知道要查哪些行，不依賴中間計算結果

MoE 不一樣，路由決策要等隱藏狀態(tài)算出來才能做

這個區(qū)別讓 Engram 可以做預?。耗Ｐ驮谟嬎闱皫讓拥臅r候，同時從主機內存異步加載 Engram 需要的數據，兩邊并行

實測結果：

配置

吞吐量

Dense-4B

9,031 tok/s

Dense-4B + 100B

Engram（CPU offload）

8,858 tok/s

Dense-8B

6,315 tok/s

Dense-8B + 100B

Engram（CPU offload）

6,140 tok/s

100B 參數的 Engram 表完全放主機內存，吞吐量下降不到 3%

N-gram 的訪問還符合 Zipf 分布，少數高頻模式占了絕大多數訪問量?？梢宰龆嗉壘彺妫簾衢T的放 GPU 顯存，長尾的放主機內存甚至 SSD

組件消融

哪些設計貢獻最大：

• ? 多分支集成：重要

• ? 上下文門控：重要

• ? Tokenizer 壓縮：重要

• ? 輕量卷積：影響不大

• ? 4-gram：在當前參數預算下不如 2-gram + 3-gram 組合

Engram 放在第 2 層效果最好，越往深層放效果越差

跑起來

                                                           pip install torch numpy transformers sympy
python engram_demo_v1.py

GitHub 上的 demo 是演示版，mock 了 Attention/MoE 等標準組件，用于展示 Engram 的數據流

總結一下：
MoE 管算，Engram 管查，兩種機制處理兩類任務

代碼：
https://github.com/deepseek-ai/Engram

論文：
https://raw.githubusercontent.com/deepseek-ai/Engram/refs/heads/main/Engram_paper.pdf