十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Engram条件记忆:DeepSeek-V4.1-Flash中196B稀疏参数N-gram哈希查表的实现原理

Engram条件记忆:DeepSeek-V4.1-Flash中196B稀疏参数N-gram哈希查表的实现原理 Engram条件记忆DeepSeek-V4.1-Flash中196B稀疏参数N-gram哈希查表的实现原理【免费下载链接】DeepSeek-V4.1-FlashDeepSeek-V4.1-Flash 是一个多模态混合专家MoE模型拥有 5520 亿骨干参数并支持最多一百万 token 的上下文长度。该模型原生支持图像和文本输入并以自回归方式生成文本项目地址: https://ai.gitcode.com/hf_mirrors/deepseek-ai/DeepSeek-V4.1-FlashDeepSeek-V4.1-Flash 是一个拥有 5520 亿骨干参数的多模态混合专家MoE模型支持最长一百万 token 的上下文。它最独特的设计之一叫Engram 条件记忆用约196B 稀疏参数的 N-gram 哈希查找表把词组级记忆直接查出来注入模型。本文将用通俗的方式拆解这套哈希查表机制的实现原理帮你理解它为什么快、为什么省、为什么条件触发。为什么需要 Engram 条件记忆普通 Transformer 靠注意力机制重新计算上下文信息而人类的记忆更像字典听到华盛顿是美国直接翻出对应词条即可。Engram 就是给模型加的一本超级词典 它不参与注意力计算不走 KV Cache不增加上下文长度的存储压力只有当词组N-gram真的在文本中出现时才会触发对应的记忆行被查表读出——所以叫条件记忆196B 参数虽然庞大但每次只读其中极少数行属于稀疏激活。这套设计与 KV Cache 压缩是互补的一个管记住固定的词组知识一个管压缩动态上下文共同支撑起 1M 上下文窗口。整体架构第 1 层和第 14 层各挂一张哈希表打开 config.json 的text_config能看到 Engram 的全部关键配置配置项值含义engram_layer_ids[1, 14]只在 40 层中的第 1 层和第 14 层挂载 Engramengram_num_embeddings[384006168, 384016682]两张哈希表各约3.84 亿行engram_head_dim256每行记忆向量的维度engram_max_ngram_size4最大哈希 4-gram即 2、3、4 字词组engram_n_heads8每种 N-gram 拆 8 个头分散存储engram_compressed_vocab_size99092压缩后的词表大小两张表各约 3.84 亿行 × 256 维合计约1966 亿参数——这正是196B 稀疏参数的来源。第一步Token 压缩——让 The、the、THE 哈希相同在 inference/engram.py 中build_compressed_token_map会把每个 token 做 NFKC 归一化、去音标、转小写、合并空白然后映射到一个更小的压缩词表129280 → 99092。这一步的意义大小写、空格、音标差异导致的 token 变体会塌缩成同一个 ID词组命中率大幅提升。代码里还留了一个精巧的小细节——用私有区字符\ue000保护纯空格 token防止它被 Strip 清空后与其他无关 token 合并。⚠️ 压缩词表大小99092不是普通配置所有哈希乘数都由它派生不一致会导致整张表静默重哈希。第二步滚动 XOR 哈希——一个位置一次算出 2/3/4-gram这是 NgramHashState 类的核心。每个位置只与它前面最多 3 个 token 组合分别构成 2-gram、3-gram、4-gram。哈希方式很特别每个 token 乘以该层 × 回溯步专属的奇数乘数由10007 × 层号为种子的随机数生成且限制在 int64 不溢出范围内从近到远滚动异或XOR第 1 步得到 2-gram 哈希第 2 步 XOR 进上一个 token 就是 3-gram 哈希……以此类推每个 (N-gram 大小, 头) 组合各自对素数取模落在互不重叠的桶区间。为什么用素数不同头、不同 N-gram 大小的桶区间必须严格不相交素数按序抽取且绝不复用天然保证了这一点。每个桶的起点是engram_vocab_size1600 万向上找下一个未被占用的素数。为什么用滚动 XOR一个 token 位置最多只产生 3 个 N-gram 哈希滚动复用让计算量极小而且 prefill 和逐 token 解码阶段可以共享同一份位置缓存cache跨阶段无缝衔接。第三步查表——FP8 存储 张量并行分片哈希 ID 拿到后就要去哈希表里翻字典。inference/model.py 中的ParallelEngramEmbedding负责这件事有两个工程亮点FP8 存储3.84 亿行 × 256 维的表如果存 bf16 需要约 200GB改为 FP8E4M3后减半。表中存的是量化值 缩放因子查表时逐行反量化即可代价几乎为零按行分片表被均匀切到各张量并行 rank每个 rank 只查自己手里的行查不到的位置补 0最后all_reduce求和还原。每个位置、每层共触发24 次查表3 种 N-gram × 8 头读出的 24 行向量拼在一起进入最后一步。第四步门控注入——记忆按需进入残差流Engram 类 的 forward 是条件二字的落脚点24 行查表结果经线性投影wkv生成hc_mult份key键和 1 份value值门控分数 当前残差流与该 key 的归一化点积再取带符号平方根后过 sigmoid最终输出 残差流 门控 × value。直觉上当这个词组的含义与当前上下文对得上时门控开大记忆被注入对不上时门控趋近 0几乎不干扰。这就是条件——不是每次都强行回忆而是匹配度决定回忆强度 ️。多模态细节图像 token 被标记为 DEADDeepSeek-V4.1-Flash 原生支持图像输入。在 N-gram 哈希中图像跨度image span会被填成特殊值DEAD -1任何 N-gram绝不会跨越图像 token回溯到 DEAD 就停止图像位置的门控被直接置 0不获得任何 Engram 贡献原样通过。仓库中的多模态示例输入就是这样一张玉米图片它和文本 token 一起被编码但在 Engram 查表时完全隐身快速上手本地跑通 Engram 推理整个 Engram 机制在 inference/ 的最小推理实现里完整可读跟着做即可获取仓库git clone https://gitcode.com/hf_mirrors/deepseek-ai/DeepSeek-V4.1-Flash安装依赖python -m pip install -r requirements.txt转换权重以 8 卡张量并行为例python convert.py --model-parallel 8 ...运行示例INPUT_FILEexamples/example.txt ./run.sh完整步骤见 inference/README.md模型整体介绍见 README.md。常见疑问 FAQQ1196B 参数会不会拖慢推理不会。每次只查 24 行每层每位置FP8 行级反量化代价极低真正的成本是显存因此它按行分片到多卡。Q2哈希冲突怎么办冲突只是让两个词组共享同一段桶区间查表读出的是平均化的记忆再经过门控把关——不匹配时注入量趋近 0冲突被自然抑制。Q3为什么 N-gram 最大只到 4太短的 2-gram 歧义大太长的 5-gram 组合爆炸、命中率骤降2~4-gram 是通用性与区分度的平衡点再乘以 8 个头分散存储总容量依然充足。Q4Engram 和 KV Cache 是什么关系KV Cache 存的是这次对话的动态上下文随长度增长Engram 存的是训练中固化的静态词组知识容量固定、与上下文长度无关。两者分工不同这正是 V4.1-Flash 能把每 token KV 压到 890 字节的关键之一。小结用一句话概括 Engram 条件记忆归一化压缩 token → 滚动 XOR 哈希出 2/3/4-gram ID → 素数分桶查 FP8 哈希表 → 门控决定注入强度。它以近乎零算力的查表操作为 552B 多模态 MoE 模型外挂了一本 196B 的条件词典是长上下文大模型中记忆与计算分离的漂亮范例。想深入源码建议按顺序阅读inference/engram.py哈希与布局→ inference/model.py查表与门控→ config.json全部超参数。【免费下载链接】DeepSeek-V4.1-FlashDeepSeek-V4.1-Flash 是一个多模态混合专家MoE模型拥有 5520 亿骨干参数并支持最多一百万 token 的上下文长度。该模型原生支持图像和文本输入并以自回归方式生成文本项目地址: https://ai.gitcode.com/hf_mirrors/deepseek-ai/DeepSeek-V4.1-Flash创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表