DeepSeek V4-Pro 推理数据流——三层注意力 + Hyper-Connections 详解

副标题： DeepSeek V4-Pro（1.6T / 49B 激活）是当前最复杂的开源 MoE 架构之一------三层混合注意力（SWA + CSA + HCA）、Hyper-Connections 替代残差连接、Lightning Indexer、FP4 专家......本文从 config.json 出发，逐层拆解 V4-Pro 的推理数据流。

一、V4-Pro 在模型格局中的位置

如果说 GLM-5.2 是"高效开源"路线的代表，DeepSeek V4-Pro 走的是极致工程优化路线------花最大的精力在架构层面压榨每一分计算和显存。

V4-Pro vs GLM-5.2 架构哲学对比

维度	DeepSeek V4-Pro	GLM-5.2
注意力	3 种混合：滑动窗口+CSA+HCA	2 种混合：MLA+DSA
残差连接	Hyper-Connections（4 流）	标准残差
KV Cache 优化	压缩+稀疏，双重减负	低秩 latent，单重减负
Expert 精度	FP4（专家权重用 4-bit）	FP8
推理 FLOPs（1M ctx）	V3.2 的 27%	---
KV Cache（1M ctx）	V3.2 的 10%	---

二、核心配置

复制代码

架构：       DeepseekV4ForCausalLM（MoE + CSA/HCA 混合注意力）
层数：       61 层（3 bootstrap + 58 交错的 CSA/HCA）
隐藏维度：   hidden_size = 7168
注意力头数： 128
KV 头数：   1（Multi-Query Attention，共享 K=V）
每头维度：   head_dim = 512
总参数量：   ~1.6T
激活参数量： ~49B / token
上下文：     1,048,576 tokens
开源协议：   MIT（HuggingFace: deepseek-ai/DeepSeek-V4-Pro-Base）

config.json 关键参数

参数	值	含义
`num_hidden_layers`	61	总层数
`num_attention_heads`	128	注意力头数
`num_key_value_heads`	1	单 KV 头（MQA）
`head_dim`	512	每头维度
`q_lora_rank`	1536	Q 低秩压缩
`o_groups`	16	输出投影分组
`o_lora_rank`	1024	输出投影低秩压缩
`n_routed_experts`	256（Pro 版用 384）	路由专家数
`n_shared_experts`	1	共享专家
`num_experts_per_tok`	6	每 token 激活专家数
`scoring_func`	`sqrtsoftplus`	路由打分函数
`sliding_window`	128	滑动窗口大小

压缩与稀疏参数

参数	值	含义
CSA 压缩率	4:1	每 4 个 token 压缩为 1 个
HCA 压缩率	128:1	每 128 个 token 压缩为 1 个
`index_n_heads`	64	Lightning Indexer 头数
`index_head_dim`	128	Indexer 每头维度
`index_topk`	1024	每 query 选 top-k 个压缩条目
`partial_rotary_factor`	64/512	RoPE 只作用于 64/512 维

Hyper-Connections

参数	值	含义
`hc_mult`	4	并行残差流数
`hc_sinkhorn_iters`	20	Sinkhorn 迭代次数
`hc_eps`	1e-6	数值稳定

三、三层注意力混合架构

这是 V4-Pro 最复杂的部分。61 层中每层被分配为三种注意力类型之一：

复制代码

层类型分布（model.layer_types）:
  第 0-2 层:  sliding_window     ← 全量滑动窗口（bootstrap）
  第 3-60 层:  CSA / HCA 交替    ← 稀疏 + 压缩注意力交错

分配模式（58 层 CSA/HCA）：

复制代码

L3:  CSA    L4:  HCA    L5:  CSA    L6:  HCA    L7:  CSA    L8:  HCA
...
每 2 层一个循环：CSA → HCA → CSA → HCA → ...

3.1 Sliding Window Attention（全量局部）

仅用于前 3 层 bootstrap。每个 token 只 attend 到自己和前方 128 个 token：

复制代码

输入 Q, K(滑动窗口内), V(滑动窗口内)
  → Attention(Q, K, V) → 输出
  计算量: O(seq_len × window_size) = O(128 × seq_len)
  特点: 全精度、无压缩、无稀疏

3.2 共享骨干（所有注意力层共用）

无论 CSA 还是 HCA，都共享以下组件：

Multi-Query Attention（MQA） ：num_key_value_heads = 1

复制代码

Q: (seq, 128 heads × 512 dim) = (seq, 65536)
K: (seq, 1 head × 512 dim)    = (seq, 512)   ← 只存一个头
V: (seq, 1 head × 512 dim)    = (seq, 512)   ← K 和 V 共享同一向量

节省: 标准 MHA 需要 128 个 KV 头，MQA 只需要 1 个 → KV Cache 减到 1/128

Partial RoPE ：仅作用于每头 512 维中的后 64 维：

复制代码

每头 512 维 = [nope(448), rope(64)]
Q_nope(448) + Q_rope(64) → 旋转 → Q_rope_rot
K_nope(448) + K_rope(64) → 旋转 → K_rope_rot

Grouped Low-Rank Output（o_groups=16）：

复制代码

16 组 × 每组的 lora_rank = 1024
Attention 输出(128×512=65536) → 16 组每组 4096 → 降维至 16×1024 → 合并 → 输出(7168)

Attention Sink：每头有可学习的 sink 参数，允许 attention score 之和小于 1。防止长序列下的注意力弥散。

3.3 Compressed Sparse Attention（CSA）

CSA 是 V4-Pro 的主力注意力类型，用于 50% 的层（CSA/HCA 交替的第一个）。

第一步：KV 压缩（4:1）

每 4 个相邻 token 用 softmax 加权求和压缩为 1 个压缩 token：

复制代码

原始 KV:   [k0, k1, k2, k3 | k4, k5, k6, k7 | ...]
              ↓  softmax 加权    ↓  softmax 加权
压缩 KV:   [c0               | c1               | ...]

压缩比: 4:1
窗口重叠: 使用两组交叠的池（C^a, C^b）避免边界信息丢失

1M 上下文 → 压缩后 ~262K 个压缩条目。

第二步：Lightning Indexer（稀疏索引）

Indexer 是一个轻量的低秩 multi-query attention，对所有压缩条目打分，选 top-k（k=512）：

复制代码

Lightning Indexer 打分:
  q_idx = Q_proj(q)                    # 轻量 Q 投影
  k_idx = K_proj(compressed_kv)         # 轻量 K 投影
  score = ReLU(q_idx @ k_idx^T)         # ReLU 门控打分（无 softmax）
  topk_indices = argsort(score)[:512]   # 选 top-512

关键: Indexer 以 FP4 运行，计算量极小

第三步：稀疏 Attention

只在选中的 top-512 个压缩位置上做 attention + 同时保留 128 个未压缩的滑动窗口 token：

复制代码

Attention 输入:
  - CSA 压缩条目（top-1024 个，来自 4:1 压缩 ≈ 覆盖 ~4096 原始位置）
  - 滑动窗口（128 个未压缩的原始 token）

总 attend 位置 ≈ 512 + 128 = 640 ← 而非 1M

3.4 Heavily Compressed Attention（HCA）

HCA 是 CSA 的"搭档"，用于另外 50% 的层。它做极端压缩：128:1，无 indexer，直接做 dense attention。

复制代码

每 128 个 token 压缩为 1 个（非交叠窗口）:
  原始 KV: [k0...k127 | k128...k255 | ...]
  压缩 KV: [c0        | c1          | ...]

1M 上下文 → 仅 ~7800 个压缩条目

Attention: dense attention，无需 indexer
  Q @ K_compressed^T 对所有 ~7800 个条目

HCA 相当于一个永久性的全局摘要通道------虽然分辨率低，但覆盖了全上下文。

3.5 三层注意力的完整工作流

复制代码

输入 x (seq, d)
    │
    ├── 确定本层类型（sliding_window / CSA / HCA）
    │
    ├── Q 投影: x → Q(seq, 64×512)
    │        └── Partial RoPE（64/512 维旋转）
    │
    ├── KV 投影: x → K(seq, 1×512) = V(seq, 1×512)  # MQA，共享 K=V
    │
    ├── 压缩（仅 CSA/HCA 层）:
    │   ┌─ CSA:  4:1 交叠压缩 → ~262K 个条目 → Indexer top-512
    │   └─ HCA: 128:1 非交叠压缩 → ~7.8K 个条目
    │
    ├── 滑动窗口（所有层）: 保留 128 个未压缩 token
    │
    ├── Attention:
    │   ┌─ sliding_window: Q @ K_window^T（128 个位置）
    │   ├─ CSA:           Q @ K_compressed_topk^T（512 个压缩条目）
    │   └─ HCA:           Q @ K_compressed_all^T（~7800 个压缩条目）
    │
    └── Grouped Low-Rank Output: 8 组 × 1024 → 合并 → 输出(4096)

四、Manifold-Constrained Hyper-Connections（mHC）

这是 V4-Pro 最"怪"但也最有趣的创新------用 4 条并行流替代标准残差连接。

标准残差 vs Hyper-Connections

复制代码

标准残差连接:
  x → sublayer(x) → + x → 输出
  一条路径，加性合并

Hyper-Connections（hc_mult=4）:
  输入: [s0, s1, s2, s3]  ← 4 条并行状态流
  
  Step 1 (pre-mix): 
    [s0, s1, s2, s3] → 混合矩阵 P(4×4) → [s0', s1', s2', s3']
    混合矩阵 P 是双随机的（doubly stochastic，Birkhoff 多面体约束）
  
  Step 2: 每条流独立通过 sublayer
    s0' → attention → t0
    s1' → attention → t1
    s2' → attention → t2
    s3' → attention → t3
  
  Step 3 (post-mix):
    [t0, t1, t2, t3] → 混合矩阵 Q(4×4) → [t0', t1', t2', t3']
  
  Step 4 (combine + split):
    新的 4 条流 = 组合权重

双随机混合矩阵

混合矩阵 P 满足：

所有元素 ≥ 0
每行之和 = 1
每列之和 = 1

通过 exp(params) + 20 次 Sinkhorn 迭代 实现。

为什么要这么做？

复制代码

标准残差的 F 范数:  > 1（深层中梯度可能爆炸）
Hyper-Connections:  ≤ 1（双随机矩阵的谱范数 = 1，非扩张的）
效果: 信号在 61 层中稳定传播，梯度不会爆炸或消失

工程代价：激活内存和通信量增加，但通过融合 kernel + 选择性重计算，仅增加 ~6.7% 的 1F1B wall-time。

推理时的实际影响

推理时 Hyper-Connections 的代价很小：

4 条流在内存中只是增加了一个维度
混合矩阵是 4×4 的------计算量可以忽略
主要在训练时有用，推理时只是多存 4× 的 hidden state

五、MoE FFN：256 专家 + sqrtsoftplus 路由

专家配置

复制代码

路由专家:  256（V4-Pro 使用 384 个）
共享专家:  1
每 token 激活: 6（top-6）
激活参数量: 6 个路由 + 1 共享 = 7 个专家 / token
打分函数: Sqrt(Softplus(x))  ← 替代 V3 的 Sigmoid

SqrtSoftplus vs Sigmoid

复制代码

V3（Sigmoid）:  gating = sigmoid(score)    # 输出范围 (0, 1)
V4（SqrtSoftplus）: gating = sqrt(softplus(score))  # 输出范围 (0, ∞)

效果: SqrtSoftplus 对高分专家给更大的权重，对低分专家抑制更强
       → 专家的分化更明显

MoE FFN 算子链（每个专家）

和 GLM-5.2 一样是 SwiGLU，但多了 clamp：

复制代码

输入(7168) → W_gate(4096→3072) → clamped to ±10.0 → SiLU → gate
输入(7168) → W_up(4096→3072)   → clamped to ±10.0 → up
hidden = gate × up  → (2048)
hidden → W_down(2048→4096) → 输出

前 3 层 Bootstrap：Hash MoE

前 3 层使用哈希路由 而非 learned routing：通过 tid2eid[input_ids] 静态查表决定 expert 分配。不需要路由器计算，也不需要 top-k 选择------启动阶段的 expert 分配是固定的。

六、推理数据流逐层拆解

单层 CSA 的完整算子链

复制代码

输入 x (1, 4096)
    │
    ├── Step 1: Hyper-Connections Pre-mix
    │   4 条流 × 4×4 混合矩阵 → P @ [s0,s1,s2,s3]（可忽略计算）
    │
    ├── Step 2: Q 投影（MQA）
    │   W_q(4096 → 64×512) → Q(64×512)
    │   计算量: 4096 × 32768 = 134M MACs
    │
    ├── Step 3: KV 投影（MQA，共享 K=V）
    │   W_k(4096 → 1×512) → K = V (512)
    │   计算量: 4096 × 512 = 2.1M MACs（很小）
    │
    ├── Step 4: Partial RoPE（64/512 维旋转）
    │
    ├── Step 5: KV 压缩（CSA 特有）
    │   每 4 个 token 加权求和 → 压缩条目
    │
    ├── Step 6: Lightning Indexer（CSA 特有，FP4）
    │   Q 轻量投影 → @ K_compressed → ReLU → top-512
    │
    ├── Step 7: Sparse Attention
    │   7a: 滑动窗口分支 --- Q @ K_window(128)^T
    │   7b: 压缩分支 --- Q @ K_compressed_topk(512)^T
    │   7c: softmax → 加权 V
    │   计算量: Q(64×512) @ K(640×512)^T ≈ 21M MACs
    │
    ├── Step 8: Grouped Low-Rank Output
    │   8 组 × lora 1024 → 展开 → 合并
    │   计算量: 可忽略（相比 Q 投影）
    │
    ├── Step 9: MoE FFN（7 个专家：6 路由 + 1 共享）
    │   每个专家 SwiGLU: 3 × 4096 × 2048 = 25.2M MACs
    │   7 个专家: 25.2M × 7 = 176.4M MACs
    │
    └── Step 10: Hyper-Connections Post-mix
        Q @ [t0,t1,t2,t3] → 新的 4 条流

HCA 层 vs CSA 层的差异

阶段	CSA 层	HCA 层
KV 压缩	4:1 交叠池化	128:1 非交叠池化
压缩条目数（1M ctx）	~262K	~7.8K
Indexer	✅ 有（FP4，top-512）	❌ 无（dense 扫描全部）
压缩注意力	k=512 稀疏	dense 到 ~7800 条目
滑动窗口	✅ 始终保留 128 个	✅ 始终保留 128 个
总 attend 位置	~640	~7900

单 token decode 计算量分布（hidden=7168, heads=128）

阶段	MACs / 层	占比
Q 投影（7168 × 65536）	470M	~40%
KV 投影（MQA, 7168 × 512）	4M	~0.3%
稀疏 Attention（CSA: ~640 pos / HCA: ~7900 pos）	~84M / ~1034M	~7% / ~49%
Grouped LoRA Output（16组 × 8.4M）	134M	~12%
MoE FFN（7 experts × 3 × 7168 × 3072）	462M	~40%
Lightning Indexer + 其他	~10M	~1%
CSA 层总计	~1164M
HCA 层总计	~2114M

关键差异： HCA 层的 attention 占据大量计算（~1034M MACs, ~49%），因为它要对全部 ~7900 个压缩条目做 dense attention。CSA 层则把 attention 压缩到 ~640 个位置，计算量仅为 HCA 层的一半。

七、算力与带宽评估

Prefill 阶段

组件	MACs / token
3 × Bootstrap 层（window attention + Dense FFN）	~3.8B
29 × CSA 层	29 × 1164M ≈ 33.8B
29 × HCA 层	29 × 2114M ≈ 61.3B
LM Head（7168 × 129280）	927M
总计	~100B MACs

对比 GLM-5.2（~29.3B MACs/token），V4-Pro 的 prefill 计算量反而大 3 倍多。原因在于 V4-Pro 的 head_dim=512（GLM 256 的两倍），且 num_heads=128（GLM 64 的两倍），Q 投影 + 注意力计算大幅增加。

Decode 阶段（带宽密集）

每 token 需要加载的激活权重（FP8，专家为 FP4）：

组件	参数量	精度	加载量
Q 投影（7168 × 128×512）	470M	FP8	470 MB
KV 投影（MQA, 7168 × 512）	3.7M	FP8	4 MB
Grouped LoRA Output（16组）	134M	FP8	134 MB
MoE FFN（7 experts × 3 × 7168 × 3072）	462M	FP4	231 MB
Indexer + 其他（FP4）	~15M	FP4	~8 MB
每层活跃权重	~1084M		~847 MB
61 层总计	~66B		~51.7 GB
LM Head（7168 × 129280）	927M	FP8	927 MB
全模型总计	~67B ≈ ~49B 激活参数		~53 GB

不同 GPU 的解码延迟估算：

GPU	带宽	53GB 加载时间	理论 tok/s
A100 80GB	2.0 TB/s	~26.5 ms	~38 tok/s
H100 80GB	3.35 TB/s	~15.8 ms	~63 tok/s
H200 141GB	4.8 TB/s	~11.0 ms	~91 tok/s
B200 192GB	8.0 TB/s	~6.6 ms	~152 tok/s

V4-Pro 的 decode 速度比 GLM-5.2（~84 tok/s on H100）慢约 25%------主要是因为 hidden_size=7168 比 GLM 的 6144 大，Q 投影和 Expert FFN 的权重加载量更高。但 V4-Pro 用 FP4 专家 和 MQA 在一定程度上控制住了差距------如果没有这两项优化，加载量会接近 100GB/token。

注意： V4-Pro 的确切 hidden_size 取决于具体发布版本。这里以 config 基准（4096）做估算框架，实际部署以 HuggingFace config.json 为准。

KV Cache 占用

V4-Pro 的 KV Cache 极为复杂------分层、分精度缓存：

复制代码

每层 KV Cache（3 种）:
  1. 滑动窗口 KV:  2 × 1 × 512 × 128 = 128K 值/层 → ~0.13 MB（FP8）
  2. CSA/HCA 压缩 KV（MQA, 1 head）:
     CSA: 2 × 1 × 512 × (seq/4) = 256 × seq  值
     HCA: 2 × 1 × 512 × (seq/128) = 8 × seq  值
  3. Indexer KV（仅 CSA 层，FP4）:
     64 × 128 × (seq/4) = 2048 × seq  值 → ~1 KB/seq（FP4）

对于 1M 上下文：

组件	大小
滑动窗口 KV（61 层）	128K × 61 ≈ 8 MB
CSA 压缩 KV（29 层 × 256 × 1M × FP8）	~7.4 GB
HCA 压缩 KV（29 层 × 8 × 1M × FP8）	~0.2 GB
Indexer KV（29 层 × 2048 × 1M × 0.5B FP4）	~30 GB
总计	~38 GB

KV Cache 总量约 38 GB（1M 上下文），对比标准 MHA 的 5 TB 以上，压缩比在 100 倍以上。这个数字和 V4-Pro 官方宣称的"KV Cache 仅为 V3.2 的 10%"一致。

八、部署需要多少卡？当前主流 AI 加速卡适配分析

V4-Pro 的完整推理（FP8/FP4 混合精度，1M 上下文）需要满足以下条件：

资源需求	数值
权重存储（FP8 + FP4 混合）	~1120 GB（800GB FP4 专家 + 320GB FP8 其他）
KV Cache（1M 上下文）	~38 GB
激活值 + 框架开销	~50 GB（估算）
总计最低显存需求	~1200 GB
Decode 权重加载 / token	~53 GB → 决定单卡 tok/s

8.1 NVIDIA 全线产品

|:----|:---😐:----😐::---------😐:-------😐:-------😐:-------😐:--------|

| A100 80GB | 80GB HBM2e | 2.0 TB/s | ~38 | TP=32 | 32 卡 | 2560 GB | 显存太小，权重要靠大量 TP 分片，通信开销大 |

| H100 80GB | 80GB HBM3 | 3.35 TB/s | ~63 | TP=16 | 16 卡 | 1280 GB | 勉强装下权重，但显存吃紧 |

| H200 141GB | 141GB HBM3e | 4.8 TB/s | ~91 | TP=12 | 12 卡 | 1692 GB | 充裕，可额外支撑多路并发 |

| H200 141GB | 同上 | 4.8 TB/s | ~91 | TP=8 | 8 卡 | 1128 GB | ❌ 不够（1128<1200），需 CPU offload |

| B200 192GB | 192GB HBM3e | 8.0 TB/s | ~152 | TP=8 | 8 卡 | 1536 GB | ✅ 性价比最优：8 卡刚好装下，还有余量 |

| B200 192GB | 同上 | 8.0 TB/s | ~152 | TP=4 | 4 卡 | 768 GB | ❌ 不够 |

TP 规模与通信开销： TP=16 意味着每层被切成 16 份，每次 attention 计算都需要 all-reduce。H100 NVLink 带宽为 900 GB/s，TP=16 时 all-reduce 开销约占总解码时间的 10-15%。TP=8 是最优平衡点------B200 正好可以用 TP=8。

推荐方案：

最优：8 × B200 → TP=8，原生 FP4 支持，单卡 ~152 tok/s，8 卡并行后约 1200+ tok/s（批量推理时可达更高）
最实用：12 × H200 → 宽裕的显存，不必担心 OOM
经济型：16 × H100 → 也够用，但需注意显存限制

8.2 华为昇腾系列

华为昇腾是国产唯一能支撑 V4-Pro 级别推理的芯片系列。

型号	显存	带宽	算力	最少卡数	分析
Ascend 910C（2025）	128GB HBM3	3.2 TB/s	800 TFLOPS FP16	12 卡（1536 GB）	带宽接近 H100（3.35 vs 3.2），卡数需求 12 卡合理
Ascend 950PR（2026）	128GB 自研 HBM	1.6 TB/s	1 PFLOPS FP8	---	Prefill 优化：低带宽但对 prefill 影响小，1M context prefill 快；decode 受限
Ascend 950DT（2026）	144GB 自研 HBM	4 TB/s	1 PFLOPS FP8	10 卡（1440 GB）	Decode 优化：4 TB/s 带宽接近 H200，144GB 显存适合大模型部署
Ascend 960（2027 Q4）	288GB	9.6 TB/s	2 PFLOPS FP8	5-6 卡	显存带宽全面超越 B200，但尚未上市

昇腾 vs NVIDIA 推理吞吐对比（估算）：

复制代码

V4-Pro decode 单卡 tok/s 估算（受带宽限制）:
  H100 (3.35 TB/s):   ~63 tok/s
  B200 (8 TB/s):      ~152 tok/s
  Ascend 950DT (4 TB/s):  ~76 tok/s    ← 约等于 H200
  Ascend 910C (3.2 TB/s): ~60 tok/s    ← 约等于 H100

结论： 如果只用单卡，950DT 的 4 TB/s 带宽被 B200 的 8 TB/s 大幅超越。但昇腾的优势不在单卡性能，而在多卡互联效率 ------华为 CloudMatrix 集群的 2 TB/s 自研互联远高于以太网方案，大规模部署时多卡效率损失更小。对于国产化部署场景，8-10 卡 950DT 是 V4-Pro 实际可用的最小配置。

8.3 其他国产 AI 卡

型号	显存	带宽	定位	能否跑 V4-Pro？
摩尔线程 MTT S5000	80GB HBM2e	1.6 TB/s	训推一体	⚠️ 勉强：32 卡（2560 GB）才够存权重，但单卡 80GB 显存碎片效应严重
寒武纪思元 690	80GB HBM2e	1.2 TB/s	旗舰推理	⚠️ 32 卡起步，带宽仅为 H100 的 36%，不推荐
海光 DCU Z100	64GB HBM2e	933 GB/s	通用计算	❌ 显存太小，需 40+ 卡，性价比极低

这些卡目前的单卡规格（显存 ≤ 80GB、带宽 ≤ 1.6 TB/s）和 V4-Pro 的需求（~1200GB 总显存、带宽敏感）有较大差距。它们更适合 7B-70B 级别模型的推理，对于 1.6T 级别的 V4-Pro 需要 32 卡以上集群，互联效率会成为瓶颈。

如果你需要国产化部署 V4-Pro，短期看 Ascend 950DT（10-12 卡）是唯一可行的方案，长期等 2027 年的 Ascend 960 单卡 288GB。

8.4 实践建议速查

场景	推荐方案	估算吞吐（多卡并行）
快速上线、性能优先	8 × B200（TP=8）	单用户 ~1200 tok/s，批量更高
性价比、现有存量卡	12-16 × H200	~1100-1500 tok/s
降级方案（80GB 卡）	16 × H100 + CPU offload	~800 tok/s（受 offload 影响）
国产化、信创合规	10-12 × Ascend 950DT	~700-900 tok/s
个人开发者跑模型	❌ V4-Pro 不适合	至少 8 卡 B200/12 卡 H200

九、总结：V4-Pro 的工程智慧

创新点速览

创新	解决的问题	效果
CSA 4:1 + Indexer top-512	长上下文 attention O(n²)	从 1M 降到 640 个 attend 位置
HCA 128:1 + dense	全局信息通路	仅 ~7800 条目覆盖全上下文
MQA（KV heads=1）	KV Cache 随层数线性增长	KV Cache 减到 1/128
FP4 专家	MoE 权重复载	专家权重减半
Hyper-Connections 4 流	深层梯度不稳定	谱范数 ≤ 1，稳定传播
SqrtSoftplus 路由	专家分化不够	高低分差距更明显
Grouped LoRA Output	输出投影参数量大	从 32768×4096 降到 8×1024
Partial RoPE 64/512	RoPE 破坏低秩压缩	448 维可压缩，64 维感知位置
Attention Sink	长序列注意力弥散	score 之和可小于 1

V4-Pro vs GLM-5.2：架构路线对比

复制代码

特性            DeepSeek V4-Pro              GLM-5.2
───            ───────────────              ──────
hidden_size    7168                         6144
头数            128                          64
每头维度        512                          256
KV 头数         1（MQA）                     64（全量）
注意力层数      3 种（窗口+CSA+HCA）          1 种（MLA+DSA）
位置编码        Partial RoPE（64/512）        Partial RoPE（64/256）
输出投影        16 组×1024 LoRA              全量 16384×6144
残差连接        Hyper-Connections 4 流        标准残差
路由打分        SqrtSoftplus                 Top-8（分类器）
专家精度        FP4                          FP8
Indexer 精度    FP4                          全精度
MoE FFN 中间    3072                         2048
MoE 规模        ~49B 激活 / 1.6T 总参         ~40B 激活 / 744B 总参

一句话总结

DeepSeek V4-Pro 是对"极致工程"的诠释------每一层的计算都被用到了极限，没有冗余的注意力覆盖，没有浪费的浮点精度。三层注意力（窗口+CSA+HCA）就像三副各有分工的望远镜：滑动窗口看近处细节，CSA 看远处重点，HCA 看全貌。这种设计让 V4-Pro 在 1M 上下文下仅用 V3.2 的 27% FLOPs 和 10% KV Cache，是对"大模型推理太贵"这个问题的工程回答。

数据来源：DeepSeek V4-Pro HuggingFace config.json、nano-deepseek-v4 参考实现、Vultr 部署文档、知乎 DeepSeek-V4 深度解读