Complete architecture document set with multi-model review remediation: - Frozen interface contracts, runtime semantics, DB schemas - Event/tool/error/provider registries - Scheduler and main agent state machines - C4 module/code views, solution architecture, baseline V1 - Multi-model review reports and joint assessment - Phase-gate remediation complete (P0/P1/P2/UX resolved) - Implementation plan with T-000A through T-045 - Reference folders kept as placeholders only
42 KiB
DeepSeek 论文特性分析:基于模型架构的 Agent 优化指南
日期: 2026-05-28 目标: 针对 DeepCode CLI Agent 的模型特性优化 参考文献: DeepSeek arXiv 论文 + 官方技术报告 + GitHub 仓库
目录
- Multi-Head Latent Attention (MLA) — 2405.04434
- DeepSeekMoE — 2401.06066
- GRPO — 2402.03300 / 2501.12948
- DeepSeek-V3: Auxiliary-Loss-Free Load Balance + MTP — 2412.19437
- DSA / DeepSeek-V3.2 — 2512.02556
- Native Sparse Attention — 2502.11089
- CSA + HCA / DeepSeek-V4 — 完整技术报告分析
- Engram — 条件记忆
- DeepSeek-R1: 涌现推理行为 — 2501.12948 / Nature 645
- 综合 Agent 优化策略
1. Multi-Head Latent Attention (MLA) — 2405.04434
论文核心
DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model
- arXiv: 2405.04434, May 2024
- 236B total / 21B activated, 128K context
- KV cache 减少 93.3%, 吞吐量提升 5.76x
核心技术细节
MLA 低秩 KV 联合压缩
标准 MHA 需要为每个 token 缓存 2×n_h×d_h×l 元素。MLA 将所有 KV 压缩为潜在向量:
c_t^KV = W_DKV · h_t (压缩, d_c << n_h·d_h)
k_t^C = W_UK · c_t^KV (解压 Key)
v_t^C = W_UV · c_t^KV (解压 Value)
缓存: 只需存 c_t^KV → (d_c + d_h^R)×l 元素 ≈ 4.5×d_h×l
对比 MHA: 2×n_h×d_h×l (n_h 通常 32-128)
对于 DeepSeek-V2: d_c = 4×d_h, d_h^R = d_h/2 → 等价于 GQA with 2.25 groups, 但性能超过 MHA
解耦 RoPE 策略
RoPE 与低秩 KV 压缩不兼容(位置敏感性破坏矩阵吸收)。
解决方案: 额外多 Head 查询 q_t,i^R + 共享 Key k_t^R 承载 RoPE
q_t,i = [q_t,i^C; q_t,i^R] (内容部分 + RoPE 部分)
k_t,i = [k_t,i^C; k_t^R] (内容部分 + 共享 RoPE Key)
推理时: W_UK 可吸收到 W^Q, W_UV 可吸收到 W^O
解耦 Key (k_t^R) 需要额外缓存 d_h^R 元素
Query 低秩压缩
训练时也压缩 Query 以减少激活内存:
c_t^Q = W_DQ · h_t (压缩)
q_t^C = W_UQ · c_t^Q (解压)
Agent 优化含义
| 特性 | 对 Agent 的影响 | 优化策略 |
|---|---|---|
| KV cache 极低 (4.5×d_h) | 超长上下文可行 | Agent 可维护完整对话历史 + 项目上下文 |
| 解耦 RoPE 位置编码 | 位置信息独立于内容 | 上下文顺序敏感: 前置的关键信息在 RoPE 部分影响更大 |
| Query 低秩压缩 | 查询表征有信息瓶颈 | 提示词应聚焦: 避免冗余/模糊指令,让有限 query 维度承载高价值信息 |
| W_UK/W_UV 吸收到 W^Q/W^O | 推理时 KV 解压零开销 | Agent 框架调用时无需特殊处理 KV 缓存 |
具体优化建议
-
上下文分层策略 (基于 MLA 的 KV 效率):
利用 MLA 的 93.3% KV 减少 → Agent 可用 10x 以上上下文长度 V4-Pro: 1M tokens → 完整项目仓库上下文一次加载 -
位置敏感输入设计 (基于解耦 RoPE):
前 128 tokens (sliding window): 最关键的指令和约束 中间范围 (CSA 4x 压缩): 相关文件 / 代码段 远距离 (HCA 128x 压缩): 仓库全局信息 -
提示词聚焦原则 (基于 Query 压缩):
❌ 模糊: "帮我看看这个代码有什么问题" ✅ 精准: "分析 src/core/agent.rs:42-78 中的错误处理逻辑,特别是 Result<T,E> 的传播路径"
2. DeepSeekMoE — 2401.06066
论文核心
DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models
- arXiv: 2401.06066, Jan 2024
- 目标: 更精细的专家专业化
核心技术细节
细粒度专家分割 (Fine-Grained Expert Segmentation)
将标准 FFN 专家分割为 m 个更小的专家:
标准做法: 16 个专家, 选 top-2 → C(16,2) = 120 种组合
DeepSeekMoE: 64 个细粒度专家, 选 top-8 → C(64,8) = 4.4×10^9 种组合
组合爆炸 → 更灵活、更精准的知识获取。
共享专家隔离 (Shared Expert Isolation)
隔离 K_s 个始终激活的共享专家,捕获通用知识:
专家类型:
1. 共享专家 (Shared): 始终激活, 捕获通用知识 → 减少路由专家冗余
2. 路由专家 (Routed): 每 token 选 top-K → 高度专业化
V2 (236B): 2 共享 + 160 路由, 选 6 路由专家
V3 (671B): 1 共享 + 256 路由, 选 8 路由专家
V4-Pro (1.6T): 1 共享 + 384 路由, 选 6 路由专家
设备限制路由 (Device-Limited Routing)
每个 token 的目标专家限制在最多 M 个设备上 (M≥3 时性能接近无限制)。
三级负载均衡损失
| 损失类型 | 目标 | 公式 |
|---|---|---|
| Expert-Level (L_ExpBal) | 防止路由崩溃 | α₁∑f_i·P_i |
| Device-Level (L_DevBal) | 跨设备计算均衡 | α₂∑f'_i·P'_i |
| Comm-Bal (L_CommBal) | 通信开销均衡 | 控制跨设备通信 |
Agent 优化含义
| 特性 | 对 Agent 的影响 | 优化策略 |
|---|---|---|
| 细粒度专家 (384个) | 每 token 仅激活 6 个 | 任务类型决定激活路径 |
| 共享专家 (始终激活) | 通用知识无损失 | 系统提示词/Agent 规则等通用知识被共享专家处理 |
| 路由专家 (top-6) | 特定任务路由到特定专家 | 提示词应明确任务类型 以帮助路由 |
| 设备限制路由 | 同一设备上的专家协同 | 相似任务连续调用可能复用同一设备专家集合 |
具体优化建议
-
任务路由优化 (基于 MoE 路由机制):
不同任务类型触发不同专家组合: - 代码生成 → 路由到代码专家 - 架构分析 → 路由到推理/规划专家 - 错误诊断 → 路由到 debug/分析专家 隐含: prompt 开头的 token 影响路由决策最大 → 开头就明确任务类型: "Generate Python code..." / "Analyze the architecture..." -
共享专家利用:
共享专家处理通用知识 → 以下信息始终被共享专家覆盖: - Agent 身份规则 ("You are an expert software engineer") - 输出格式约束 - 通用编码规范 -
V4-Pro 的 384 专家架构优化:
V4-Pro: 1共享 + 384路由, 选6 激活率: 6/384 = 1.56% → 极端稀疏 → Agent 的每个请求只激活极少数专家 → 高度相似的任务反复调用 → 相同专家组合 → 一致的输出风格 → 多样性任务 → 不同专家组合 → 需要更多 "热身" token 稳定路由
3. GRPO — 2402.03300 / 2501.12948
论文核心
DeepSeekMath (2402.03300): GRPO 首次提出 DeepSeek-R1 (2501.12948 / Nature 645:633-638): GRPO 扩展到通用推理
与 PPO 的核心差异
PPO: Policy Model + Critic Model (Value Function) + Reward Model
GRPO: Policy Model + Group Samples + Reward Model (无 Critic)
GRPO 从一组响应中计算 advantage:
对 prompt q, 采样一组响应 {o₁, o₂, ..., o_G}
计算每个响应的奖励 {r₁, r₂, ..., r_G}
advantage_i = (r_i - mean(r)) / std(r) ← 以组均值为基线
优势:
- 不需要单独的 Critic/Value 模型 → 节省 ~50% 训练内存
- 训练更稳定 (组内归一化)
- 适用于只有最终答案可验证的场景 (数学、代码)
R1 训练流程
Stage 1: R1-Zero — 纯 RL, 无 SFT 数据
→ 涌现 CoT、自验证、反思行为
Stage 2: R1 — Cold-start SFT + RL
→ 收集少量 "冷启动" CoT 数据做 SFT
→ 然后 RL 训练
→ 解决 R1-Zero 的可读性和语言混杂问题
Stage 3: Distillation — 用小模型模仿 R1 推理模式
→ R1-Distill-Qwen-1.5B/7B/14B/32B
→ R1-Distill-Llama-8B/70B
涌现行为分析 (来自 Nature 论文)
纯 RL 训练 (R1-Zero) 产生以下涌现能力:
| 涌现行为 | 描述 | Agent 意义 |
|---|---|---|
| Chain-of-Thought | 自动分解复杂问题为步骤 | Agent 自然规划多步操作 |
| Self-Verification | 模型自动检查自己的输出 | Agent 可自我审查代码 |
| Reflection | 回顾和修正推理路径 | Agent 可回溯修复错误 |
| Dynamic Adaptation | 更难问题分配更多思考时间 | Agent 自动调节推理深度 |
| "Aha" Moment | 模型突然意识到错误并修正 | 零样本错误恢复能力 |
Agent 优化含义
-
R1 无需 explicit CoT 提示:
❌ "Let's think step by step" (对 R1 多余) ✅ 直接给任务描述 + 约束 + 输出格式 -
R1 对 prompt 精确度极度敏感:
模糊 prompt → 长且发散的 reasoning (浪费 token) 精确 prompt → 聚焦推理, 高效输出 -
Group-based 训练思想 可用于 Agent 调优:
对 Agent 的每个任务, 采样多个轨迹 用验证器 (test pass / build success) 打分 用 GRPO 方式优化 Agent policy
4. DeepSeek-V3: Auxiliary-Loss-Free Load Balance + MTP — 2412.19437
论文核心
DeepSeek-V3 Technical Report
- arXiv: 2412.19437, Dec 2024
- 671B total / 37B activated
- 训练仅 2.788M H800 GPU hours (~$5.5M)
- 无不可恢复 loss spike
关键技术
Auxiliary-Loss-Free Load Balancing
之前的 MoE 使用辅助损失 (expert balance loss) 来防止路由崩溃,但这会损害模型性能。V3 引入动态偏置:
对每个 expert i, 维护偏置 b_i
在训练中动态调整:
- 若 expert i 负载过高 → b_i -= γ (偏置降低, 减少该 expert 被选概率)
- 若 expert i 负载过低 → b_i += γ (偏置升高, 增加概率)
路由决策: gating_score + b_i
辅助损失: 不使用! (省去 α₁∑f_i·P_i 项)
Multi-Token Prediction (MTP)
传统: 预测下一个 token → V3: 同时预测 D 个后续 token
传统: P(t_{i+1} | t_1...t_i)
MTP: P(t_{i+1} | t_1...t_i) × P(t_{i+2} | t_1...t_i, t_{i+1}) × ...
好处:
- 更长的训练信号 → 更强的规划能力
- 对代码生成特别有益 (语句/函数级规划)
- 推理时可选择使用或忽略 MTP 头
Agent 优化含义
-
MTP 训练 → 规划能力:
V3 的 MTP 训练使模型内置规划能力 → Agent 架构中不需要显式 Planning Module → 只需给高层次的指令, 模型自动规划步骤 -
无辅助损失 → 更自然的路由:
路由纯粹基于 token-expert 亲和度 → 代码 token 自然路由到代码领域的 expert → 格式 token 路由到格式 expert ⇒ prompt 应使用领域相关术语来激活对应 expert -
训练稳定性 → 生产可靠性:
全程无 rollback → 模型行为高度可预测、稳定 → 适合构建 Agent 生产系统
5. DSA / DeepSeek-V3.2 — 2512.02556
论文核心
DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models
- arXiv: 2512.02556, Dec 2025
- 三大创新: DSA + Scalable RL + Agent Task Synthesis Pipeline
DSA 架构细节
Lightning Indexer
一个小型、多头的评分器,决定每个 query 关注哪些 token:
I_{t,s} = Σⱼ w_{t,j} · ReLU(q^I_{t,j} · k^I_s)
其中:
- H_I: 索引器 Head 数量 (很小, 如 4-8)
- q^I_{t,j}: query token 的索引查询
- k^I_s: 前驱 token 的索引键
- w_{t,j}: 可学习的 head 权重
- ReLU 激活: 确保正分数, 且利于 FP8 实现
索引器计算效率极高: 小 Head 数 + FP8 → 极低开销。
细粒度 Token 选择
每个 query 只选择 top-k 的 KV 条目做注意力:
u_t = Attn(h_t, {c_s | I_{t,s} ∈ Top-k(I_{t,:})})
其中 Top-k 选择分数最高的 k 个前驱 token
在 MLA 框架下的 DSA 实现
DSA 基于 MLA 的 MQA 模式实现:
透明图:
输入 h_t
→ 计算 c_t^KV (MLA 压缩) + q_t (query)
→ Lightning Indexer 评分 I_{t,s}
→ Top-k 选择前驱 KV
→ 稀疏注意力计算
→ 输出 u_t
训练过程: 两阶段
| 阶段 | 步骤 | 数据 | 操作 |
|---|---|---|---|
| 1. Dense Warm-up | 1000 步, 16 seq × 128K tokens | 2.1B tokens | 冻结所有参数, 仅训练 Lightning Indexer |
| 目标: 用 KL 散度对齐 Indexer 输出与 Full Attention 分布 | |||
| 2. Sparse Training | 全体参数优化 | 长上下文数据 | 引入 Top-k 选择, 对齐索引器 |
V3.2 的 Scalable RL 框架
- 后训练计算量大幅增加 (接近预训练规模的显著比例)
- V3.2-Speciale: 更高计算变体
- IMO 2025 金牌 + IOI 金牌
Agentic Task Synthesis Pipeline
自动化生成 Tool-use 场景的训练数据:
合成管道:
1. 定义工具集 (代码执行、搜索、文件操作)
2. 自动生成需要工具使用的任务
3. 用验证器 (test pass, search result) 作为奖励
4. RL 训练 Agent 行为
结果: 在复杂交互环境中的泛化能力和指令遵循显著提升
Agent 优化含义
| DSA 特性 | 对 Agent 影响 | 优化策略 |
|---|---|---|
| Lightning Indexer 选 top-k | 模型只关注 "最重要" 的前驱 tokens | 结构化上下文: 关键信息放在易于被索引器选中的位置 |
| Top-k 选择 | 短距离和长距离 token 竞争 | 减少上下文中的噪音, 让高价值 token 脱颖而出 |
| ReLU 索引器 | 负相关 → 完全忽略 | 避免与任务目标负相关的内容 |
| Dense Warm-up 对齐 | 索引器分布接近 full attention | 遵循常规 attention 的位置偏好 |
| Agent 合成管道 | V3.2 有原生 Agent 能力 | 直接使用 tool-use 格式, 模型已经过此类训练 |
具体优化建议
-
上下文质量 > 数量:
基于 DSA 的 Top-k 机制: 如果上下文包含大量无关信息, 索引器可能选到噪声 → Agent 应主动清理上下文, 只保留高价值信息 → 使用 RAG 或检索机制预先筛选相关文档 -
"关键信息" 定位:
索引器偏好: - Query token 和 key 有高语义匹配 → 用关键词匹配 - ReLU 只保留正分数 → 使用正面描述而非否定 示例: ❌ "Don't use any external library" ✅ "Use only Python standard library: os, sys, json" -
Short Context 优势:
短上下文中, 每个 token 被选中概率更高 → 对简单任务, 尽量缩小上下文 → 复杂的重构任务才需要完整项目上下文
6. Native Sparse Attention (NSA) — 2502.11089
论文核心
Native Sparse Attention: Hardware-Aligned and Natively Trainable Sparse Attention
- arXiv: 2502.11089, Feb 2025
- 作者: Jingyang Yuan, Huazuo Gao, Damai Dai 等 (DeepSeek)
核心技术
动态层次化稀疏策略
两层设计:
-
Coarse-grained Token Compression (粗粒度压缩):
- 将 token 块压缩为紧凑表示
- 捕获全局上下文
- 减少 attention 范围
-
Fine-grained Token Selection (细粒度选择):
- 从压缩结果中选择关键 token
- 保持局部精度
硬件对齐优化
- Arithmetic intensity balanced → 充分利用 GPU 计算能力
- 支持端到端训练 (非 post-hoc 稀疏化)
- 64K 序列长度下显著加速 Decoding/Forward/Backward
与 DSA 的关系
NSA 是 DSA 的前身/理论研究。DSA 是 NSA 的改进版,部署在 V3.2 中。
关键区别:
- NSA: 块级压缩 + 选择
- DSA: 以 Lightning Indexer 做细粒度 token 级别选择
7. CSA + HCA / DeepSeek-V4 — 完整技术报告分析
论文来源
DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence
- 完整 PDF: 43 页 (4.3MB), 来自 HuggingFace (deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf)
- 发布日期: 2026-04-23 (预览版本)
- arXiv: 待发布
模型系列
| 模型 | 总参数 | 激活参数 | 层数 | 隐藏维度 | 路由专家 | 激活专家 | 训练 tokens |
|---|---|---|---|---|---|---|---|
| V4-Pro | 1.6T | 49B | 61 | 7168 | 384 | 6 | 33T |
| V4-Flash | 284B | 13B | 43 | 4096 | 256 | 6 | 32T |
架构总览
V4 保留 Transformer + MTP (Multi-Token Prediction) 架构,在 V3 基础上有三大升级:
- mHC: Manifold-Constrained Hyper-Connections 替代标准残差连接
- CSA + HCA: 混合注意力架构实现极致长上下文效率
- Muon: 替代 AdamW 作为主要优化器
MoE 仍使用 DeepSeekMoE 框架,但有两个改动:
- activation function: Sigmoid(·) → Sqrt(Softplus(·))
- 前 3 个 MoE 层使用 Hash routing (基于 token ID 的确定性路由)
- 取消路由目标节点数约束
7.1 Compressed Sparse Attention (CSA)
核心思想
CSA 分两步: 先沿着序列维度压缩 KV, 再对压缩后的 KV 做稀疏注意力。
KV 压缩 (Token-Level Compressor)
每个 token 产生两组 KV 条目 (双流压缩, 重叠窗口):
C^a = H · W^a_KV, C^b = H · W^b_KV (KV 条目, shape: n × c)
Z^a = H · W^a_Z, Z^b = H · W^b_Z (压缩权重, shape: n × c)
对每 m 个 token 压缩为 1 个条目:
S = Softmaxrow([Z^a + B^a; Z^b + B^b]) (2m 元素 softmax)
C_i^Comp = Σ S^a_j ⊙ C^a_j + Σ S^b_j ⊙ C^b_j
V4-Pro 压缩率 m = 4, V4-Flash 压缩率 m = 4
关键: C^a 和 C^b 的索引窗口有重叠 (overlap), 因此实际压缩率为 1/m。
Lightning Indexer (稀疏选择)
一个小型多头评分器, 决定每个 query 关注哪些压缩 KV 块:
低秩 query 计算:
c^Q_t = h_t · W^DQ (压缩, R^d → R^dc)
q^I_t = [q^I_{t,1}; ...; q^I_{t,n^I_h}] = c^Q_t · W^IUQ (解压, R^dc → R^{c_I * n^I_h})
索引评分:
w^I_t = h_t · W^w (每 head 权重, R^d → R^{n^I_h})
I_{t,s} = Σ_h w^I_{t,h} · ReLU(q^I_{t,h} · K^IComp_s) (聚合分数, ReLU 确保正分)
Top-k 选择:
C_t^SprsComp = {C_s^Comp | I_{t,s} ∈ Top-k(I_{t,:})}
V4-Pro: n^I_h = 64, c_I = 128, top-k = 1024
V4-Flash: n^I_h = 64, c_I = 128, top-k = 512
共享 KV MQA (Multi-Query Attention)
压缩 KV 条目同时作为 Key 和 Value (MQA 模式):
query 也采用低秩压缩:
q_t = [q_{t,1}; ...; q_{t,n_h}] = c^Q_t · W^UQ (n_h query heads)
核心注意力:
o_{t,i} = CoreAttn(query=q_{t,i}, key=C_t^SprsComp, value=C_t^SprsComp)
V4-Pro: n_h = 128, c = 512, d_c = 1536
V4-Flash: n_h = 64, c = 512, d_c = 1024
Grouped Output Projection
n_h 个 head 的输出先分组再投影, 降低计算量:
n_h → g 组 (V4-Pro: g=16, V4-Flash: g=8)
每组: o^G_{t,i} ∈ R^{c * n_h/g} → 中间输出 o'^G_{t,i} ∈ R^{d_g} (d_g=1024)
最终: 拼接后投影到 d 维
滑动窗口补充分支 (Sliding Window Attention)
每个 query 额外关注最近的 n_win = 128 个未压缩 KV 条目, 保证局部精细度。
7.2 Heavily Compressed Attention (HCA)
核心思想
比 CSA 更激进的压缩 (m' ≫ m), 不做稀疏选择, 直接对压缩表示做 dense attention。
KV 压缩
C = H · W^KV, Z = H · W^Z (单流压缩, 无重叠)
每 m' 个 token 压缩为 1 个:
S = Softmaxrow(Z + B)
C_i^Comp = Σ S_j ⊙ C_j
V4: m' = 128
HCA 提供极紧凑的全局上下文表示。
7.3 混合注意力的协同工作
整体注意力流程 (每层):
1. SWA (128 tokens) — 精确局部上下文
2. CSA (4x 压缩, top-1024) — 选择性中程信息
3. HCA (128x 压缩) — 全局摘要感知
CSA 和 HCA 在层间交错使用:
- V4-Pro: 前 2 层用 HCA, 后续层 CSA/HCA 交错
- V4-Flash: 前 2 层用 SWA, 后续层 CSA/HCA 交错
效率对比 (1M 上下文)
| 指标 | V3.2 (GQA8) | V4-Pro | V4-Flash | 减少 |
|---|---|---|---|---|
| 单 token 推理 FLOPs | 100% | 27% | 10% | 73-90% |
| KV Cache | 100% | 10% | 7% | 90-93% |
| vs BF16 GQA8 baseline | 100% | ~2% | ~2% | 98% |
KV 混合精度存储
RoPE 维度: BF16 (64 维)
其他维度: FP8
→ KV cache 较纯 BF16 减少近一半
闪电索引器: 全部 FP4 精度
路由专家权重: FP4 (MXFP4)
7.4 Manifold-Constrained Hyper-Connections (mHC)
标准 Hyper-Connections (HC)
将残差流宽度扩展 n_hc 倍:
维度: R^d → R^{n_hc × d}
更新: X_{l+1} = B_l · X_l + C_l · F_l(A_l · X_l)
其中 A_l ∈ R^{1×n_hc}, B_l ∈ R^{n_hc×n_hc}, C_l ∈ R^{n_hc×1}
层输入: A_l · X_l ∈ R^d (实际隐藏维度不变)
mHC 的核心创新
将残差映射矩阵 B_l 约束到双随机矩阵流形 (Birkhoff polytope):
B_l ∈ M = {M ∈ R^{n×n} | M·1_n = 1_n, 1^T_n·M = 1^T_n, M ≥ 0}
约束效果:
- ∥B_l∥₂ ≤ 1 (谱范数有界) → 非扩张变换 → 数值稳定
- M 对乘法封闭 → 深层堆叠保持稳定性
- A_l, C_l 通过 Sigmoid 约束为非负有界
Sinkhorn-Knopp 投影
使用 Sinkhorn-Knopp 算法将 B̃_l 投影到双随机流形 (20 次迭代):
M^(0) = exp(B̃_l) (指数确保正性)
M^(t) = T_r(T_c(M^(t-1))) (交替行列归一化, 20 次)
动态参数化
参数由输入相关 (动态) 和输入无关 (静态) 两部分组成:
Ã_l = α^pre · (X̂_l · W^pre) + S^pre (X̂_l = RMSNorm(vec(X_l)))
B̃_l = α^res · Mat(X̂_l · W^res) + S^res
C̃_l = α^post · (X̂_l · W^post)^T + S^post
V4 配置: n_hc = 4, α 初始化为小值
工程优化
mHC 增加激活内存和通信量, 通过以下方式补偿:
- 融合 kernel (前向+反向)
- 选择性重计算 (checkpoint 中间 hidden states)
- 调整 DualPipe 1F1B 重叠方案
- 总开销: 仅占重叠 1F1B pipeline 阶段的 6.7%
7.5 Muon Optimizer
算法
对每个权重矩阵 W ∈ R^{n×m}:
1. G_t = ∇L_t(W_{t-1}) (梯度)
2. M_t = μ·M_{t-1} + G_t (动量, μ=0.95)
3. O'_t = HybridNewtonSchulz(μ·M_t + G_t) (Nesterov 技巧 + 正交化)
4. O_t = O'_t · max(n,m)^{1/2} · γ (RMS 重缩放, γ=0.18)
5. W_t = W_{t-1}·(1 - ηλ) - η·O_t (权重衰减 + 更新)
Hybrid Newton-Schulz 迭代
10 次迭代, 两阶段:
阶段 1 (前 8 步): (a,b,c) = (3.4445, -4.7750, 2.0315) → 快速收敛
阶段 2 (后 2 步): (a,b,c) = (2.0, -1.5, 0.5) → 精确稳定在奇异值=1
每次迭代: M_k = a·M_{k-1} + b·(M_{k-1}·M^T_{k-1})·M_{k-1} + c·(M_{k-1}·M^T_{k-1})^2·M_{k-1}
AdamW 保留部分
| 模块 | 优化器 |
|---|---|
| Embedding 层 | AdamW (β₁=0.9, β₂=0.95, ε=1e-20, wd=0.1) |
| Prediction head | AdamW |
| mHC 静态偏置 + 门控因子 | AdamW |
| 所有 RMSNorm 权重 | AdamW |
| 其余所有参数 | Muon |
工程实现
- Newton-Schulz 可在 BF16 下稳定计算 → 通信减半 (BF16 reduce-scatter)
- MoE 梯度: 在 data-parallel 间随机舍入到 BF16, 使用 all-to-all + FP32 本地求和
- 连续同形状参数自动合并 → 批量 NS 迭代提高硬件利用率
- 混合 ZeRO 策略: knapsack 算法分配 dense 参数, MoE 参数按 expert 独立优化
7.6 基础设施
MegaMoE (融合 EP Kernel)
单 fused kernel 实现 MoE 的四阶段流水线:
阶段: Dispatch (all-to-all) → Linear-1 (GEMM) → Act (SwiGLU+FP8) → Linear-2 (GEMM) → Combine (all-to-all)
Expert Wave 调度: 将专家分为 waves, 计算/通信/激活在 wave 间流水
→ 计算隐藏通信: 只要 C/B ≤ 6144 FLOPs/Byte, 通信完全被隐藏
→ V4-Pro: 每个 token-expert 对 6hd FLOPs, 仅 3h bytes 通信
→ 实测: 1.50-1.73× 推理加速, 最高 1.96× (RL rollout/agent serving)
开源: DeepGEMM + MegaMoE (github.com/deepseek-ai/DeepGEMM/pull/304)
TileLang DSL
- DSL 开发 fused kernels, 替代数百个 Torch ATen 算子
- Host Codegen: 将 Python 运行时校验移到生成的 C++ host 代码
- 每次调用开销: 几十到几百 μs → <1 μs
- Z3 SMT 求解器集成: 布局推导、内存冲突检测、边界分析的正式整数分析
- IEEE-754 合规 + bitwise reproducibility (与 CUDA NVCC 对齐)
Batch-Invariant & Deterministic Kernels
Batch Invariance: 任意 batch 位置输出 bitwise 一致
Attention: 双 kernel 策略
- Kernel 1: 单 SM 计算整个序列 (满 wave 高吞吐)
- Kernel 2: 多 SM 处理尾部 wave (减少 wave-quantization)
- 精心设计确保累加顺序一致
GEMM: DeepGEMM 替代 cuBLAS, 放弃 split-k, 用特殊优化补偿性能
Determinism: 确定性问题来自 backward 的 atomicAdd
Attention backward: 每 SM 独享累加 buffer → 全局确定性求和
MoE backward: token 顺序预处理 + 多 rank 间 buffer 隔离
mHC matmul: split-k 分别输出 → 确定性 reduce
Inference KV Cache
异构缓存结构:
State Cache (固定大小, 按请求分配):
- SWA segment: 最近 n_win tokens 的未压缩 KV
- CSA/HCA segment: 等待压缩的尾部 tokens
Classical Cache (多 block 按请求分配):
- 每个 block 覆盖 lcm(m, m') 个原始 token
- V4: lcm(4, 128) = 128 tokens/block
- k_1 = 128/4 = 32 CSA 压缩条目, k_2 = 128/128 = 1 HCA 压缩条目
On-Disk KV Cache (共享前缀复用):
CSA/HCA: 完整存储压缩 KV, 从磁盘读取
SWA: 三种策略:
1. Full Caching: 存全部 SWA KV → 计算零冗余但写密集
2. Periodic Checkpointing: 每 p tokens 存一次 checkpoint → 可调节存储/计算
3. Zero Caching: 不存 SWA → 重算最后 n_win·L 个 token
训练框架
Contextual Parallelism: 两阶段通信
Stage 1: rank i 发送末尾 m 个 token 给 rank i+1 (跨边界压缩)
Stage 2: all-gather 收集本地压缩 KV → fused select-and-pad 重组
Tensor-Level Activation Checkpointing:
- TorchFX tracing 构建计算图
- 对标注的 tensor 自动识别最小重计算子图
- 自动去重 (共享存储的 tensor 不重复重算)
7.7 预训练
数据
| 数据类别 | 说明 |
|---|---|
| Web 数据 | 过滤批量自动生成和模板化内容 |
| 数学/编程 | 核心组件, mid-training 加入 agentic 数据 |
| 多语言 | 更大语料覆盖长尾知识 |
| 长文档 | 优先科学论文和技术报告 |
| 总计 | V4-Flash: 32T, V4-Pro: 33T tokens |
Tokenizer: DeepSeek-V3 tokenizer (128K 词汇), 加入少量特殊 tokens 策略: token-splitting + FIM (Fill-in-Middle) + sample-level attention masking
训练超参数
| 参数 | V4-Flash | V4-Pro |
|---|---|---|
| 学习率 | 2.7×10^{-4} → 2.7×10^{-5} | 2.0×10^{-4} → 2.0×10^{-5} |
| 最大 batch size | 75.5M tokens | 94.4M tokens |
| LR warmup | 前 2000 步 | 前 2000 步 |
| 序列长度 | 4K → 16K → 64K → 1M | 4K → 16K → 64K → 1M |
| 稀疏注意力引入 | 1T tokens 后用 dense warmup | 更长的 dense warmup |
| MTP loss weight | 0.3 (decay 后 0.1) | 0.3 (decay 后 0.1) |
| 偏置更新速度 | 0.001 | 0.001 |
| 平衡 loss weight | 0.0001 | 0.0001 |
训练稳定性
Anticipatory Routing: 防 loss spike
核心: 步骤 t 用 θ_t 计算特征, 但用 θ_{t-Δt} 的路由索引
实现: 在步骤 t-Δt 提前获取数据, 预计算并缓存路由索引
额外开销: ~20% (仅 loss spike 时触发)
自动检测: loss spike → 短回滚 → 激活 AR → 稳定后恢复标准训练
SwiGLU Clamping: 消除异常值
SwiGLU 线性部分: 裁剪到 [-10, 10]
SwiGLU 门控部分: 上限 10
7.8 后训练
两阶段范式
Phase 1: 领域专家独立训练
每个 domain (数学/编码/Agent/指令遵循):
1. SFT (domain-specific 高质量数据)
2. RL (GRPO + 领域奖励模型)
Phase 2: On-Policy Distillation (OPD)
学生模型: 统一模型
教师模型: 10+ 领域专家
损失: L_OPD(θ) = Σ w_i · D_KL(π_θ ∥ π_{E_i}) (反向 KL)
全词汇 logit 蒸馏 (克服 token 级 KL 的高方差)
三种 Reasoning Effort 模式
| 模式 | 特性 | 典型用途 |
|---|---|---|
| Non-think | 快速直觉响应 | 日常任务, 低风险 |
| Think High | 有意识逻辑分析 | 复杂问题解决, 中等风险 |
| Think Max | 极限推理 (特殊系统提示) | 探索模型推理能力边界 |
Think Max 的系统提示注入:
Reasoning Effort: Absolute maximum with no shortcuts permitted.
You MUST be very thorough in your thinking and comprehensively decompose the
problem to resolve the root cause, rigorously stress-testing your logic against all
potential paths, edge cases, and adversarial scenarios.
Generative Reward Model (GRM)
替代传统标量奖励模型:
actor network 原生作为 GRM
joint optimization: 评估能力 + 生成能力
只用少量人类标注 → 模型利用内部逻辑泛化到复杂任务
Quick Instruction
特殊 token 实现辅助任务, 复用已有 KV cache:
<|action|> → 判断是否需要 web search
<|title|> → 生成对话标题
<|query|> → 生成搜索查询
<|authority|> → 分类权威性需求
<|domain|> → 识别对话领域
<|extracted_url|>/<|read_url|> → URL 提取和读取判断
优势: 无需单独的小模型, 零冗余 prefilling, 并行执行, TTFT 显著降低。
Interleaved Thinking
工具调用场景: 完整保留所有推理历史 (跨用户消息边界)
使模型在长周期 agent 任务中保持连贯累积思考
通用对话场景: 丢弃前轮推理内容, 保持简洁
FP4 Quantization-Aware Training
对以下组件进行 FP4 QAT:
1. MoE expert weights (FP32 master → FP4 量化 → FP8 计算)
FP4→FP8 去量化无损 (FP8 多 2 个 exponent bits)
Backward: STE (Straight-Through Estimator) 通过量化操作
2. Indexer QK path (query-key 激活)
全部 FP4: 缓存、加载、矩阵乘法
3. Index scores: FP32 → BF16 (2× 加速, 99.7% recall)
DSec Sandbox (Agentic AI 基础设施)
Rust 实现, 三个组件: Apiserver + Edge + Watcher, 基于 3FS 和自定义 RPC
四种执行基底 (统一 Python SDK libdsec):
- Function Call: 预热容器池, 零冷启动
- Container: Docker 兼容, EROFS 按需加载
- microVM: Firecracker, VM 级隔离
- fullVM: QEMU, 任意客户操作系统
关键设计:
- 分层存储: 3FS-backed EROFS layers + overlaybd
- 高密度并发: 页面缓存去重 + 内存回收 + spinlock 缓解
- 轨迹日志: 全局有序, 支持预emption 恢复和确定性回放
7.9 评测结果
Base Model 对比 (selected)
| Benchmark | V3.2-Base (37B) | V4-Flash-Base (13B) | V4-Pro-Base (49B) |
|---|---|---|---|
| MMLU-Pro (EM) | 65.5 | 68.3 | 73.5 |
| SimpleQA (EM) | 28.3 | 30.1 | 55.2 |
| HumanEval (Pass@1) | 62.8 | 69.5 | 76.8 |
| LongBench-V2 (EM) | 40.2 | 44.7 | 51.5 |
| MATH (EM) | 60.5 | 57.4 | 64.5 |
| BBH (EM) | 87.6 | 86.9 | 87.5 |
V4-Flash-Base 以 13B 激活超越 37B 激活的 V3.2-Base, 证明架构效率提升。
V4-Pro-Max 推理模式对比
| Benchmark | Opus-4.6-Max | GPT-5.4-xHigh | Gemini-3.1-Pro-High | V4-Pro-Max |
|---|---|---|---|---|
| SimpleQA | 46.2 | 45.3 | 75.6 | 57.9 |
| HLE | 40.0 | 39.8 | 44.4 | 37.7 |
| LiveCodeBench | 88.8 | — | 91.7 | 93.5 |
| Codeforces | — | 3168 | 3052 | 3206 |
| SWE-Verified | 80.8 | — | 80.6 | 80.6 |
| TerminalBench 2.0 | 65.4 | 75.1 | 68.5 | 67.9 |
| MRCR 1M | 92.9 | — | 76.3 | 83.5 |
| CorpusQA 1M | 71.7 | — | 53.8 | 62.0 |
Agent 优化含义
Agent 优化含义
| V4 特性 | 对 Agent 影响 | 优化策略 |
|---|---|---|
| 三层注意力 (128 + CSA + HCA) | 信息衰减: HCA 的 128x 压缩 → 只有最粗粒度的信息保留 | 关键信息必须放在 sliding window 或 CSA 范围 |
| Sliding window = 128 tokens | 精确注意力范围极有限 | 最关键的指令必须在 128 tokens 内 |
| CSA top-1024 (4x 压缩) | 项目级上下文可以保留但会压缩 | 文件级别信息放在此区 |
| HCA (128x 压缩) | 高压缩 → 只有主要概念/主题保留 | 只放仓库级元信息 (目录结构、全局约定) |
三层上下文预算优化
┌──────────────────────────────────────────────────────────┐
│ Sliding Window (128 tokens) — 精确注意力 │
│ 优先级 1: 当前任务指令 (task, file, line) │
│ 优先级 2: 输出格式约束 │
│ 优先级 3: 当前修改位置的代码片段 (3-5行) │
├──────────────────────────────────────────────────────────┤
│ CSA Range (4x 压缩, top-1024) — 选择性的精确信息 │
│ 当前文件上下文 (函数/类定义, 相关代码段) │
│ 相关文件的函数签名和类型定义 │
│ 最近工具调用历史 (最后 3-5 步) │
├──────────────────────────────────────────────────────────┤
│ HCA Range (128x 压缩) — 粗粒度摘要 │
│ 项目目录结构 │
│ 全局约定和配置 │
│ 整体任务目标 │
│ 完整 git 历史摘要 │
└──────────────────────────────────────────────────────────┘
关键优化: 将最重要的内容放在最前面
由于 sliding window 只有 128 tokens:
[SYSTEM PROMPT — 始终在窗口内]
You are an expert Rust engineer. Follow the project conventions.
[USER MESSAGE — 开始 128 tokens 控制的关键区域]
Task: Add error handling to src/db/query.rs:142
Current code (line 140-145):
let result = db.execute(sql).await;
Ok(result)
Requirement: Return proper error types, log context, and handle network failures.
→ 这些最关键的信息总是被精确关注
[稍后的内容 — CSA/HCA 处理]
...
8. Engram — 条件记忆
论文核心
Engram: Learning to Specialize with N-gram Lookup (DeepSeek repo)
核心技术
Engram 引入新的稀疏性维度: 条件记忆 (不同于 MoE 的条件计算)
MoE: 输入 → 路由 → 选择的专家 → 输出
Engram: 输入 → N-gram 查询 → O(1) 内存查找 → 输出
关键: 确定性寻址 (不是可学习的路由)
- 给定 N-gram, 总是访问相同的记忆槽位
- 可以 offload 到主机内存 (推理时极低开销)
U-shaped Scaling Law
MoE 和 Engram 之间存在 U 形分配曲线:
最优比例:
小模型: 更多 MoE, 少量 Engram
大模型: MoE 和 Engram 的平衡
超大模型: 更多 Engram, MoE 专注推理
Engram 擅长: 知识记忆、事实召回、词汇知识
MoE 擅长: 推理、规划、组合泛化
Agent 优化含义
-
知识 vs 推理分离:
Engram → 事实知识 (API 签名, 标准库函数, 已知 bug) MoE → 推理 (分析、规划、调试) → Agent 的 prompt 中, 事实性信息适合用结构化格式 → 推理任务需要更多推理 tokens -
O(1) 查找速度:
Engram 的记忆访问是常数时间 → 适合 Agent 需要快速查表的场景 → 如: 已知函数签名、类型定义、错误码
9. DeepSeek-R1: 涌现推理行为 — 2501.12948 / Nature 645
Nature 论文中的关键发现 (2025, vol 645, pp 633-638)
纯 RL 的 Reasoning 涌现
R1-Zero 的训练:
- 无 SFT 阶段
- 仅用 RL (GRPO)
- 奖励信号仅来自答案正确性
训练过程中, 模型自发发展出:
- Chain-of-Thought: 在
<think>块中逐步推理 - Self-Verification: 计算中间步骤后检查结果
- Reflection: 发现错误时回溯
- "Aha Moment": 训练到某点后, 模型突然学会修正自己之前的推理
蒸馏结果
| 模型 | MATH | 特点 |
|---|---|---|
| R1-Distill-Qwen-1.5B | 28.9% | 超小模型中即有推理 |
| R1-Distill-Qwen-7B | 55.9% | 超越许多大模型 |
| R1-Distill-Qwen-14B | 69.7% | 接近 GPT-4 |
| R1-Distill-Llama-70B | 80.7% | 最强蒸馏版 |
| DeepSeek-R1 (671B) | 90.8% | 完整版 |
Agent 优化含义
R1 的 Think Token 行为
对 Agent 的意义:
- R1 的 <think> 块包含原始推理过程
- 这些 tokens 对最终输出质量至关重要
- 但消耗推理成本 (需计费)
策略:
1. 简单任务: 用 V4-Flash (无 thinking) → 快速低成本
2. 复杂任务: 用 R1 先推理 → 提取计划 → V4-Pro 执行
3. 调试/错误分析: R1 的 self-verification 能力特别有用
蒸馏思想用于 Agent
知识蒸馏不仅适用于模型参数:
- 可以用 R1 为每个复杂任务生成推理轨迹
- 用这些轨迹训练 V4-Flash 的 agent 行为
- 结果: Flash 的价格 + R1 级别的推理质量
10. 综合 Agent 优化策略
10.1 模型选择矩阵 (基于架构特性)
| 任务类型 | 推荐模型 | 理由 (架构特性) |
|---|---|---|
| 简单代码生成 | V4-Flash | 13B 激活, CSA+HCA 高效, $0.14/M |
| 复杂系统重构 | V4-Pro-Max | 49B 激活 + Max reasoning, SWE-bench 80.6% |
| 调试/根因分析 | R1 → V4-Pro | R1 的 self-verification + V4-Pro 的代码能力 |
| 代码审查 | V4-Pro | 384 专家中代码相关专家高度专业化 |
| 架构设计 | V3.2-Speciale | IOI gold 级别的规划能力 |
| 多文件编辑 | V4-Pro (1M ctx) | 三层注意力支持全仓库上下文 |
| 文档生成 | V4-Flash | 共享专家覆盖通用知识 |
| 测试生成 | V4-Pro | MTP 训练的规划能力 |
| 形式验证 | Prover-V2 | Lean 4 专用 |
10.2 提示词结构优化 (基于所有论文分析)
┌─────────────────────────────────────────────┐
│ [Sliding Window — 128 tokens, 精确注意] │
│ 作用: V4 CSA+HCA 的 sliding window │
│ 内容: 系统指令 + 任务描述 + 约束条件 │
│ ─────────────────────────────────────────── │
│ [CSA Range — 4x 压缩, top-1024] │
│ 作用: DSA Lightning Indexer 选择关键 token │
│ 内容: 相关代码 + 错误信息 + 历史调用 │
│ ─────────────────────────────────────────── │
│ [HCA Range — 128x 压缩] │
│ 作用: 全局上下文 (压缩为摘要级信息) │
│ 内容: 项目结构 + 全局约定 + 背景知识 │
└─────────────────────────────────────────────┘
DSA 索引器策略:
1. 关键信息用 正面关键词 描述 (ReLU 只通过正分数)
2. 重复关键约束 (增加被索引器选中的概率)
3. 避免无关信息 (占用 top-k 位置)
MLA 优化:
4. 精准而非模糊的指令 (query 压缩限制信息容量)
5. 利用长上下文优势 (93% KV 减少)
6. 位置编码: 前置最重要内容
10.3 上下文管理策略
Agent 执行上下文 = 3 级缓存 (对应 V4 的三层注意力):
L1: Agent Scratchpad (~128 tokens)
- 当前步骤的指令
- 最近工具调用的结果
- 输出格式约束
L2: Working Context (~4K-32K tokens, CSA 优化)
- 当前文件关键部分
- 相关文件类型定义
- 最近 N 个交互
L3: Project Context (~128K+ tokens, HCA 压缩)
- 项目目录树
- 配置文件和约定
- 全局常量和类型
- Git 变更摘要
10.4 多模型协作架构
基于不同模型的架构特性:
┌─────────────┐
│ Planner │ ← R1 / V3.2-Speciale
│ (推理规划) │ IOI gold 级别规划能力
└──────┬──────┘
│ 计划
┌──────▼──────┐
│ Executor │ ← V4-Pro / V4-Flash
│ (代码生成) │ 49B/13B 激活
└──────┬──────┘ SWE-bench 80.6%
│ 代码
┌──────▼──────┐
│ Verifier │ ← V4-Pro / Prover-V2
│ (验证/测试) │ self-verification
└─────────────┘ Lean 4 formal proof
10.5 论文索引 (含关键公式/数据)
| 论文 | arXiv | 关键贡献 | 关键数据 |
|---|---|---|---|
| DeepSeekMoE | 2401.06066 | 细粒度专家 + 共享专家 | 2B 匹配 GShard 2.9B, 16B 匹配 LLaMA2 7B (40% 计算) |
| DeepSeekMath | 2402.03300 | GRPO 算法 | MATH 51.7% (无工具), GRPO 节省 ~50% 训练内存 |
| DeepSeek-V2 | 2405.04434 | MLA (低秩 KV 压缩) | KV cache -93.3%, 吞吐 +5.76x, d_c=4×d_h |
| DeepSeek-Coder-V2 | 2406.11931 | MoE 代码模型 | 236B MoE, 代码智能 |
| DeepSeek-V3 | 2412.19437 | Aux-loss-free load balance, MTP | 671B/37B, 2.788M H800 hours |
| DeepSeek-R1 | 2501.12948 | 纯 RL 推理, GRPO 扩展 | Nature 645:633-638, MATH 90.8% |
| NSA | 2502.11089 | 硬件对齐的稀疏注意力 | 块级压缩 + 选择, 端到端训练 |
| DeepSeek-V3.2 | 2512.02556 | DSA + Scalable RL + Agent Pipeline | IMO/IOI gold, SWE-bench 67.8 |
| DeepSeek-OCR-2 | 2601.20552 | Visual Causal Flow | 下一代 OCR |
| DeepSeek-V4 | DeepSeek_V4.pdf (HF) | CSA+HCA + mHC + Muon + V4-Flash (284B/13B) | 1.6T/49B, 27% FLOPs, 10% KV cache, 33T tokens |
| Engram | (repo) | N-gram 条件记忆 | O(1) 查找, U-shaped scaling |
10.6 关键数字速查
架构参数速查:
V2: 236B total, 21B active, 128K ctx, 2S+160R, top-6
V3: 671B total, 37B active, 128K ctx, 1S+256R, top-8
V3.2: 671B total, 37B active, 128K ctx, +DSA
V4-Flash:284B total, 13B active, 1M ctx, 1S+256R, top-6, 43 layers, d=4096, m=4, m'=128, n_h=64, d_c=1024, g=8
V4-Pro: 1.6T total, 49B active, 1M ctx, 1S+384R, top-6, 61 layers, d=7168, m=4, m'=128, n_h=128, d_c=1536, g=16
注意力机制速查:
MHA: 2×n_h×d_h×l (n_h=128 → 256×d_h×l)
GQA: 2×n_g×d_h×l (n_g=8 → 16×d_h×l)
MLA: (d_c+d_h^R)×l = 4.5×d_h×l (d_c=4×d_h, d_h^R=0.5×d_h)
V4 CSA: m=4 compression + top-k (1024/512) + SWA 128 + FP8/FP4 mixed
V4 HCA: m'=128 compression + SWA 128 + no sparse selection
训练效率:
V3: 2.788M H800 hours ≈ $5.5M
V4: 未公开 (估计 10x+ 于 V3)
价格速查 (per 1M tokens):
V4-Pro: $1.74 in / $3.48 out
V4-Flash: $0.14 in / $0.28 out
R1: $0.50 in / $2.18 out
GPT-5.5: ~$0.55 in / ~$2.00 out
Claude 4.6: ~$15 in / ~$75 out