Engram 与 DSpark：查表记忆和草稿头
V4.1 新加的两个组件：196B 参数的 Engram 按 n-gram 哈希查表，把“记住”从“计算”里拆出来；DSpark 取代 MTP 做投机解码，一次草拟 5 个 token，并按置信度决定验证多长。
V4.1 报告把这两样归为“高效的架构扩展”[1]。它们都来自 DeepSeek 之前单独发表的论文，这次第一次装进主力模型。
Engram：给模型一张可以查的表
想解决什么
Engram 论文的出发点是：MoE 用“条件计算”扩大容量，但 Transformer 缺少一个原生的“查表”操作，只能用计算去模拟检索，效率不高 [2]。它提出条件记忆（conditional memory）作为和 MoE 互补的另一条稀疏轴：把经典的 N-gram 嵌入现代化，做成 的查表。
论文报告的几条结果（作者报告，待独立验证）[2]：
- MoE（神经计算）与 Engram（静态记忆）之间的分配存在一条 U 形的规模律；按它把 Engram 扩到 27B 参数，在参数量与计算量都相同的条件下超过纯 MoE 基线。
- 增益不只在知识类任务（MMLU +3.4、CMMLU +4.0），推理（BBH +5.0）、代码与数学（HumanEval +3.0、MATH +2.4）上更大；长上下文检索也大幅提升（Multi-Query NIAH 从 84.2 到 97.0）。
- 机理分析的解释是：查表替浅层卸掉了“重建静态知识”的负担，相当于把网络加深；把局部依赖交给查表，也给注意力腾出了处理全局上下文的容量。
装进 V4.1 的样子
| 项目 | 数值 |
|---|---|
| 参数 | 196B，平均分给两个模块 |
| 位置 | 第 1 层与第 14 层（从 0 数），为了在训练流水线各阶段间平衡显存 |
| 查询方式 | 用 2、3、4 元组（n-gram）的哈希取表项，8 个哈希头，每个元数的嵌入总维度 2048 |
| 表的规模 | 每个哈希头对应一张约 1,600 万行的表，表长取互不相同的质数 |
| 精度 | 嵌入表与 K / V 投影都是 FP8 |
| 与原设计的差别 | 去掉了短因果卷积（收益抵不上推理栈里的复杂度）；嵌入改用动量更新加 Sinkhorn 均衡来优化 |
以上见报告第 2.4.2 节 [1]。config.json 里两个模块的表项数分别约为 3.84 亿行，每行 256 维，合计约 196.6B，与报告的 196B 吻合 [3]。
为什么它可以不占显存
Engram 最有工程意义的一点是确定性寻址：查哪几行只取决于输入的 token 序列，不依赖任何中间计算 [1][2]。于是：
- 推理时，嵌入可以放在主机内存里，通过后台 RDMA 传输提前取到 GPU；第一个模块的预取与第一个 Transformer 块的计算重叠进行 [1]。
- 训练时，表按行切分到专门的进程组里，每步开始前就为整个本地批次发起预取；优化器状态也按副本切分 [1]。
- 强化学习采样时，反而让表常驻 GPU，以减轻主机内存压力、避免碎片导致的内存溢出 [1]。
这对自己部署的人很重要：约 197 GB 的 FP8 表，原理上不必和专家权重一起挤在 HBM 里（部署那一章会看到社区已经这么做了）。
查不到的一块：V4.1 报告没有给出 Engram 在这个模型里贡献了多少的消融。基座模型的 SimpleQA-Verified 从 V4-Flash 的 30.1 升到 42.3 [1]，但同时变的还有参数规模、数据与多模态训练，不能把这 12 分记在 Engram 头上。Engram 论文里的增益数字来自论文自己的实验设置，不能直接外推到 V4.1。
DSpark：取代 MTP 的草稿头
投机解码一句话
大模型逐 token 生成，每一步都要走一遍完整网络。投机解码的做法是：先用一个便宜的“草稿”机制一次猜出几个 token，再让主模型一次性验证，猜对的直接收下，于是一次前向能产出不止一个 token。
从 MTP 到 DSpark
V3 和 V4 都有多 token 预测（MTP）模块：训练时和主干一起预训练，额外预测下一个之后的 token，推理时可以拿来当草稿；V4 论文写明原样沿用 V3 的 MTP 设置，深度为 1 [1][8]。V4.1 在预训练主干时省略了 MTP 模块，改用 DSpark 做投机解码 [1]。
DSpark 在 V4 时代就已经上线：6 月 27 日，Hugging Face 上出现了 V4-Flash-DSpark，模型卡写明“不是新模型，是同一个检查点外挂了一个投机解码模块”[5]；7 月 31 日的 V4-Flash-0731 也是这个结构 [6]。DSpark 论文报告，在 DeepSeek-V4 的线上服务里，以 MTP-1 为基线，DSpark 在相同吞吐下把单用户生成速度提高了 60% 到 85%（作者报告）[4]。
在 V4.1 里长什么样
报告第 2.4.3 节的描述 [1]：
- 草稿器由 3 个 Transformer 块组成，滑动窗口 128 个 token；
- 一次前向并行算出 5 个草稿位置的基础 logits，再用一个轻量的 Markov 头建模草稿 token 之间的依赖（纯并行草拟的通病是越往后越猜不准，这一步就是补这个）；
- 一个置信度头预测每个位置被接受的条件概率，据此估计“前缀能活到第几个”；调度器结合预先测好的引擎吞吐曲线，为每个请求动态决定验证多长，目标是在当前负载下让整个系统的期望吞吐最大。
config.json 把主干第 37–39 层列为 DSpark 的目标层（dspark_target_layer_ids），草稿块各带 128 个路由专家、每 token 激活 3 个 [3]；据 vLLM 配方页估算，草稿器的专家约占 14B 参数 [7]。
单独训练
和 V3 的 MTP 全程随主干一起预训练不同，DSpark 在预训练结束后单独一个阶段训练，主干冻结；后训练期间它继续跟着训练，但 DSpark 的目标不向主干回传梯度 [1]。这样它能一直对齐不断变化的策略模型，既加速线上服务，也加速强化学习与在线策略蒸馏时的采样 [1]。
两个组件的共同点
Engram 和 DSpark 解决的问题不同，但都体现了这一代的同一种取舍：把一部分能力从“主干必须算的东西”里拆出来，交给更便宜、能单独调度的部件——事实记忆交给可以放在主机内存里的查表，草拟交给可以按负载调节验证长度的小网络。主干本身，则专心做推理和组合。
第二部分结束。下一部分讲 V4.1 在“能看什么”和“想多少”上的两处变化。👉 原生多模态：从零训练的 DeepSeek-ViT
参考文献
- [1] DeepSeek-AI. “DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression.” 2026-09. arXiv:2609.19969 —— 第 2.1 节（省略 MTP、改用 DSpark）、第 2.4.2 节（Engram 配置）、第 2.4.3 节（DSpark 结构与训练）、第 3.1.3 节（Engram 的训练与推理实现）、表 1（SimpleQA-Verified）。
- [2] Cheng et al. “Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models.” 2026-01. arXiv:2601.07372 —— Engram 的原始论文：条件记忆、U 形规模律、27B 实验与各项增益、确定性寻址与主机内存预取。
- [3] Hugging Face：deepseek-ai/DeepSeek-V4.1-Flash 的 config.json ——
engram_*与dspark_*各字段。 - [4] Cheng et al. “DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation.” 2026-07. arXiv:2607.05147 —— DSpark 的原始论文与线上加速数字。
- [5] Hugging Face 模型卡：deepseek-ai/DeepSeek-V4-Flash-DSpark —— “同一检查点外挂投机解码模块”。
- [6] Hugging Face 模型卡：deepseek-ai/DeepSeek-V4-Flash-0731 —— 0731 与 V4-Flash-DSpark 结构相同。
- [7] vLLM Recipes. “deepseek-ai/DeepSeek-V4.1-Flash.” 2026-09-19 查阅. recipes.vllm.ai/deepseek-ai/DeepSeek-V4.1-Flash —— 第三方推理引擎文档：草稿器专家约 14B 参数的估算。
- [8] DeepSeek-AI. “DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence.” 2026-04. arXiv:2606.19348 —— V4 沿用 V3 的 MTP 设置、深度为 1。