DeepSeek-V4-Pro on NVIDIA H200：硬件工程师导读版·推理总线、带宽与延迟估算

正式报告前的入门导读

0. 先把问题翻译成硬件语言

一句话理解 DeepSeek‑V4‑Pro 推理

用户输入的一段文字会先被切成很多 token，每个 token 被变成一个长度为 7168 的向量。这个向量要顺序通过 61 个 Transformer 层。每一层大体做两件事： Attention 负责“从历史上下文里找相关信息”，MoE 专家网络负责“做非线性知识变换”。对硬件来说，这不是一个抽象的 AI 魔法，而是反复执行：读权重、读/写 KV cache、做矩阵乘、做 all-to-all 搬运、写回新 token 状态。

本报告后面的所有带宽和延迟推算，都是把这些动作映射到 HBM、片上 L2/SRAM/NoC、NVLink/NVSwitch 和跨节点网络上。

从硬件角度看，模型权重像“程序 ROM”。

DeepSeek‑V4‑Pro 有 1.6T 总参数，但每个 token 只激活约 49B 参数。大部分参数是 MoE 专家权重，不是每个 token 都用。

硬件含义：权重太大，必须跨多颗芯片切分；decode 时专家权重频繁从 HBM 流到计算阵列。

KV cache 像“运行时状态 RAM”。

上下文越长，历史 token 的 Key/Value 越多。1M context 不是一次性读 1M 原始 token，而是读压缩后的 KV/索引状态。

硬件含义：HBM 容量决定可服务 batch；HBM 带宽和 NoC 决定长上下文 decode 延迟。

MoE dispatch 像“按地址把包发到专家所在芯片”。

Router 会为每个 token 选 6 个 routed experts，再加 1 个 shared expert。专家可能分布在不同 GPU/NPU 上。

硬件含义：每层都有 dispatch/combine，两次跨芯片搬运；Scale‑up 的低延迟和 all-to-all 效率很关键。

在线服务的 Batch 是“把很多用户的 token 拼成一批”。

batch 变大能提高矩阵乘利用率，但也会触达更多专家、占用更多 KV cache，并增加队列等待。

硬件含义：吞吐、单 token 延迟、TTFT、显存容量之间必须折中。

阅读建议：先看下面三节导读，再看正式报告中的表格。正式报告里的 “B=32, S=1M” 表示 batch=32、每条序列上下文长度约 100 万 token；“Decode step” 表示每条序列各生成 1 个新 token 的一次循环。

DeepSeek‑V4‑Pro 架构白话说明

0.1 DeepSeek‑V4‑Pro 到底由哪些模块组成？

1

文本 → tokens

把中文、英文、代码等切成整数 ID。token 是模型处理的最小单位。

2

Embedding

把 token ID 查表变成 7168 维向量。可以理解为“把字变成电路能算的数”。

3

61 个 Transformer 层

每层都包含 Attention、MoE FFN、残差/归一化/mHC 等。核心搬数发生在这里。

4

LM Head

把最后的向量映射成词表上每个 token 的概率分数。

5

Sampling

按概率、温度、top-p 等规则选出下一个 token，然后循环继续 decode。

0.1.1 Attention：不是“理解文本”，而是在硬件上读历史 KV

Attention 可以理解成：当前 token 生成一个 Query，拿它去和历史 token 的 Key 比较，找到相关位置，再把对应的 Value 加权读出来。在普通 dense attention 中，上下文长度为 1M 时，每个新 token 都可能要扫 1M 份历史 KV，成本非常大。

DeepSeek‑V4‑Pro 使用 CSA + HCA 混合注意力来降低长上下文成本： CSA 先把每 4 个 token 的 KV 压缩成 1 个条目，再用 indexer 从压缩条目中选 top‑k； HCA 压缩更激进，把每 128 个 token 的 KV 合并成 1 个条目；此外还有一个小的 sliding window 保留最近 128 个 token 的细粒度局部信息。

CSA: 压缩率 m=4CSA top‑k=1024HCA: 压缩率 m′=128query heads=128head dim=512sliding window=128

硬件直觉：CSA/HCA 的作用像“给 1M 长文本建立多级索引”。它减少了需要读的 KV，但没有让 KV 消失；在长上下文和大 batch 下，Indexer 扫描、压缩 KV 读取和 SWA 局部窗口仍会占用 HBM 与 NoC。

0.1.2 MoE：总参数很大，但每个 token 只走少数专家

MoE 是 Mixture of Experts，混合专家。可以把它想成芯片里有 384 个“专用小函数单元”，每个 token 进来后，Router 先判断它应该交给哪 6 个专家处理。 DeepSeek‑V4‑Pro 每层有 1 个 shared expert + 384 个 routed experts，其中 shared expert 总是参与，routed experts 每个 token 选 6 个。

这解释了为什么 DeepSeek‑V4‑Pro 是 1.6T total / 49B active：仓库里总共有 1.6T 参数，但一次 token 前向只用其中一小部分。对芯片来说，这种设计把问题从“所有权重都算一遍”变成了“每层快速找到专家、把 token 发过去、读被命中的专家权重、再把结果合回来”。

专家权重大小

一个 routed expert 可近似看作 3 个矩阵，参数量约 3×7168×3072≈66M。若按 FP4 存放，约 33MB。

硬件含义：一个专家约能放进 H100/H200 级别 50MB L2，但一层会触达上百个专家，整体工作集远超 L2。

Router/Dispatch

Router 产生 token→expert 的映射；dispatch 把 token 激活向量发到专家所在 GPU/NPU；combine 再把专家输出合回原 token。

硬件含义：需要 all-to-all、scatter/gather、低延迟 doorbell/队列和专家分组 DMA。

为什么 decode 小 batch 难？

每个专家拿到的 token 数少，GEMM 很瘦，算力利用率低；但专家权重仍要从 HBM 读，导致 bandwidth-bound。

硬件含义：峰值 TOPS 再高，若 HBM→L2→SM 的权重流供不上，延迟仍下不来。

0.1.3 FP4 / FP8 / BF16：它们首先影响“搬多少字节”

FP4、FP8、BF16 是不同的数据格式。位宽越低，同样参数需要的存储和带宽越小，但通常需要更复杂的缩放、反量化或混合精度计算。 DeepSeek‑V4‑Pro 的公开说明中，MoE expert 参数使用 FP4，多数其他参数使用 FP8；KV cache 中也存在 FP8 与 BF16 的混合。

对总线的核心影响：低精度不是只让算力变高，它更直接地降低 HBM、NoC、NVLink 搬运字节数。问题是 FP4 权重解包、scale 读取、tile 对齐和小矩阵效率会把一部分理论收益吃掉。

软件流程白话说明

0.2 在线推理从请求到输出，软件到底做了什么？

在线服务不是“一个用户来就单独跑一遍模型”。服务端会把许多用户请求放进队列，尽量拼 batch，复用 prefix cache，分配 KV cache 页，然后在 GPU/NPU 上交替执行 prefill 和 decode。对硬件工程师来说，重要的是看每一步把压力打到哪里：CPU/PCIe、HBM、片内 NoC、Scale‑up、SSD 还是跨节点网络。

0.2.1 请求级流程：从用户输入到第一个 token

阶段 1

Tokenizer / 请求入队

把文本转成 token ID，记录每条请求的上下文长度、最大输出长度、优先级。

硬件压力：主要在 CPU；会影响调度粒度，但不是 NPU 总线主瓶颈。

阶段 2

Prefix cache 查询

检查历史系统提示词、长文档前缀是否已经算过 KV。命中则复用 KV，未命中则要 prefill。

硬件压力：命中时减少 GPU 计算；但可能引入 SSD/Host→GPU 的 KV 恢复流量。

阶段 3

KV cache 分配

为每条序列分配 paged KV 空间，建立 token 位置到 HBM 页的映射。

硬件压力：HBM 容量、碎片、页表访问；长上下文下是 batch 上限的关键。

阶段 4

Chunked Prefill

把 prompt 按 4K/8K/16K chunk 送进模型，生成历史 KV。

硬件压力：大矩阵乘多，Tensor Core 利用率较高；长前缀会加大动态 attention/KV 读。

阶段 5

首 token 输出

prefill 完成后执行一次 decode，得到第一个输出 token。

硬件压力：TTFT = 排队 + prefill + 首次 decode；在线服务体验通常首先看它。

0.2.2 一次 Decode step：每条序列各生成 1 个 token

D1

Scheduler 组 batch

把不同用户当前要生成的 token 拼成 batch。B=32 表示一次并行处理 32 条序列的新 token。

硬件压力：batch 越大，计算效率更好，但 KV 容量和专家触达数也上升。

D2

进入第 l 层 Attention

读本层投影权重，生成 Q；读取历史 CSA/HCA/SWA KV 和 indexer key，计算相关性。

硬件压力：HBM 读 KV + 片内 NoC 搬运；1M context 下 CSA indexer 扫描很明显。

D3

写本层新 KV

当前 token 也会产生新的 K/V，被写入 KV cache，供后续 token 使用。

硬件压力：单 token 写入不大，但 batch×层数×长时间运行会造成 HBM 页管理和写带宽压力。

D4

Router 选专家

对每个 token 计算 384 个 routed expert 的分数，选 top‑6，加上 shared expert。

硬件压力：计算量不大，关键是生成后续 dispatch 的稀疏地址和元数据。

D5

Dispatch All‑to‑All

把 token 激活向量发到专家所在 GPU/NPU。一个 token 会被复制/发送到多个专家。

硬件压力：NVLink/NVSwitch 或 NPU scale‑up；需要低固定延迟和高小包效率。

D6

专家 FFN 计算

每个专家对收到的 token 做 Linear‑1、激活函数、Linear‑2 等矩阵乘。

硬件压力：读 FP4 专家权重；decode 小 batch 时多为 HBM bandwidth-bound。

D7

Combine All‑to‑All

专家输出按 router 权重加权合并，发回原 token 所在位置。

硬件压力：第二次跨芯片通信；需要与专家计算重叠，否则尾延迟增加。

D8

LM Head + Sampling

61 层结束后读词表头，生成 logits，采样出下一个 token，更新序列状态。

硬件压力：通常不是主瓶颈，但会引入同步、采样和队列调度开销。

0.2.3 为什么 Batch 化会改变瓶颈？

Batch 小

每个专家只拿到很少 token，GEMM 很瘦；专家权重读一遍，但计算量不足以摊薄搬运成本。

表现：单 token 延迟低一些，但芯片利用率低，HBM/NoC 是主要瓶颈。

Batch 中等

tokens/expert 增加，Tensor Core 利用率变好；但被触达的专家数量也快速增加。

表现：吞吐提升明显，是在线服务常用的折中区间。

Batch 很大

几乎所有专家每层都被触达，MoE 权重读接近饱和；同时 KV cache 容量线性增加。

表现：吞吐继续涨，但每步延迟、显存占用和队列等待都会变大。

读正式报告时的主线：每一层的 Attention 主要消耗 KV/Indexer 读带宽；每一层的 MoE 主要消耗专家权重 HBM streaming 与 dispatch/combine；在线 batch 决定专家复用和 KV 容量是否可接受。

名词解释：按硬件工程师视角

0.3 术语速查表

下面每个名词都尽量用“它是什么 + 为什么影响硬件总线”的方式解释。正式报告中出现这些词时，可以回到这里查。

Token

模型处理文本的最小单位，可以是一个汉字、词的一部分、标点或代码片段。

硬件影响：decode 每一步通常是每条序列生成 1 个 token。

Context / 上下文

模型当前能看到的历史 token 数。1M context 表示最多约 100 万 token。

硬件影响：上下文越长，KV cache 越大，长序列 attention 读带宽越高。

Prefill

处理用户 prompt、把历史 token 全部过一遍模型并生成 KV cache 的阶段。

硬件影响：大块矩阵乘多，计算利用率高；长前缀会造成大量 KV 读写。

Decode

模型逐 token 生成回答的循环。每循环一次，每条活跃序列输出一个新 token。

硬件影响：小矩阵、多同步、频繁读专家权重和历史 KV，常是在线延迟瓶颈。

Batch B

一次并行处理多少条序列的新 token 或多少 prompt token。

硬件影响：batch 提高计算利用率，但增加 KV 容量、触达专家数量和队列等待。

Hidden size h

每个 token 在模型内部的向量宽度。V4‑Pro 中 h=7168。

硬件影响：激活搬运、MoE dispatch payload、矩阵维度都与 h 直接相关。

Transformer Layer

大模型的重复计算单元。V4‑Pro 有 61 层，每层大致由 Attention + MoE FFN 构成。

硬件影响：每层都重复读权重、读写 KV、做 all‑to‑all；单层开销会乘以 61。

Attention

让当前 token 从历史上下文中取信息的机制，本质是 Q 与 K 匹配，再聚合 V。

硬件影响：长上下文下主要是 KV/indexer 读取、top‑k 和稀疏 gather。

Q / K / V

Query、Key、Value。Q 是当前查询，K 是历史位置的索引，V 是历史位置携带的信息。

硬件影响：K/V 会缓存到 HBM；Q/K/V 投影权重需要每层读取。

KV cache

保存历史 token 的 K/V，避免每次生成新 token 都重算历史。

硬件影响：在线服务的显存大户；1M context 下 batch 上限首先受它限制。

CSA

Compressed Sparse Attention。先压缩 KV，再用 indexer 选少量相关 KV 做 attention。

硬件影响：减少 dense attention 读量，但引入 indexer 扫描和 top‑k 稀疏访问。

HCA

Heavily Compressed Attention。比 CSA 更强地压缩历史 KV，V4‑Pro 压缩率 m′=128。

硬件影响：显著降低长上下文 KV 读，但信息更粗，需要与 CSA/SWA 混合使用。

SWA / Sliding Window

只保留最近一小段窗口的细粒度 attention，V4‑Pro 窗口为 128。

硬件影响：保证局部上下文精度；KV 读小但每层都会发生。

MoE

Mixture of Experts。把 FFN 拆成很多专家，每个 token 只激活少数专家。

硬件影响：降低激活计算量，但引入专家权重大容量、路由和 all‑to‑all。

Expert / 专家

一个小型 FFN 子网络。V4‑Pro 每层有 384 个 routed experts 和 1 个 shared expert。

硬件影响：一个 FP4 routed expert 约 33MB；多专家同时触达导致 L2 放不下。

Router / Gate

为每个 token 选择要走哪些专家的打分模块。V4‑Pro 每 token 选 6 个 routed experts。

硬件影响：生成稀疏 dispatch 地址；路由不均会造成某些芯片尾延迟。

Shared Expert

每个 token 都会走的公共专家，用来保留通用能力。

硬件影响：比 routed experts 更稳定可复用，但仍要读权重、做矩阵乘。

Routed Expert

由 Router 按 token 内容动态选择的专家，不同 token 走不同专家。

硬件影响：造成稀疏、动态、难预测的数据流，是 MoE 总线复杂度来源。

FFN / MLP

Transformer 层里的前馈网络，通常是几次矩阵乘和激活函数。

硬件影响：在 MoE 中变成很多专家 GEMM；decode 时常因小 batch 变成搬权重受限。

Residual / mHC

把层输入和层输出相加或以更复杂方式连接，帮助信号在深层网络中稳定传播。

硬件影响：计算量相对小，但涉及激活读写和片上 buffer 组织。

Top‑k

从很多候选中选出分数最高的 k 个。CSA 选 KV 条目，MoE 选专家都会用到。

硬件影响：带来排序/选择、元数据和稀疏 gather/scatter。

EP / Expert Parallel

把不同专家放到不同 GPU/NPU 上，token 按专家路由跨芯片流动。

硬件影响：每层 MoE 都可能需要 all‑to‑all，是 scale‑up 设计重点。

TP / Tensor Parallel

把一个大矩阵切到多颗芯片上共同计算。

硬件影响：需要 all‑reduce / reduce‑scatter 等通信；通信形态比 EP 更规则。

PP / Pipeline Parallel

把不同层放在不同芯片或节点上，像流水线一样传激活。

硬件影响：跨层激活传输较规则，但 decode batch 小时 pipeline bubble 明显。

HBM

GPU/NPU 封装内的高带宽显存。

硬件影响：V4‑Pro decode 主瓶颈之一是 HBM 反复流专家权重和 KV。

L2 / SRAM

片上缓存，比 HBM 小得多但延迟低、带宽高。

硬件影响：若专家权重/KV tile 能复用，L2 可省 HBM；但 V4‑Pro 每层触达专家太多。

NoC

片内 Network‑on‑Chip，把 HBM 控制器、L2 slice、计算阵列、DMA 等连接起来。

硬件影响：NoC 承担 HBM→L2→SM/NPU core 的权重和 KV 搬运。

NVLink / NVSwitch

NVIDIA 的 GPU 间高速互联和交换芯片，用于单机或 supernode 内 scale‑up。

硬件影响：EP dispatch/combine 依赖它；带宽、固定延迟、小包效率都重要。

Scale‑up

把一个推理副本扩到多颗芯片上，芯片之间像一个大加速器一样协同。

硬件影响：需要低延迟高带宽互联，适合放 TP/EP 等细粒度并行。

Scale‑out

跨服务器/机架扩展，通常用 InfiniBand/RDMA/以太网。

硬件影响：适合复制服务副本或粗粒度并行，不适合每层细粒度 MoE all‑to‑all。

All‑to‑All

每个芯片都可能给其他芯片发送一部分数据，并接收其他芯片的数据。

硬件影响：MoE dispatch/combine 的典型通信模式；容易受固定延迟和流量不均影响。

Paged KV

像操作系统分页一样管理 KV cache，避免连续大块显存分配困难。

硬件影响：降低碎片，但增加页表/地址计算和 gather 复杂度。

Prefix cache

复用相同前缀的 KV，避免重复 prefill。例如系统提示词或共享长文档。

硬件影响：减少 GPU 计算，但把压力转到 KV 存储、恢复和一致性管理。

FP4 / FP8 / BF16

不同浮点格式，分别约 4/8/16 bit。低位宽减少存储和带宽，但实现更复杂。

硬件影响：影响权重、KV、激活的字节数，以及解包/缩放/对齐成本。

GEMM / Tensor Core

GEMM 是矩阵乘；Tensor Core 是专门加速矩阵乘的硬件单元。

硬件影响：prefill 大 GEMM 利用率高；decode 小 GEMM 可能喂不满 Tensor Core。

Roofline

用峰值算力和峰值带宽估算某任务理论下界的方法。

硬件影响：它给出“再优化也很难低于”的延迟，但真实实现通常更慢。

FLOPs/Byte

每搬 1 字节数据能做多少浮点运算，用来判断是算力受限还是带宽受限。

硬件影响：值低通常是带宽受限；MoE EP 是否能隐藏通信也可用它判断。

TTFT / TPOT

TTFT 是首 token 延迟；TPOT 是每个输出 token 的平均耗时。

硬件影响：TTFT 受 prefill、排队、prefix cache 影响；TPOT 主要受 decode 循环影响。

1. 正式报告：结论先行

模型权重容量

单 H200 不可承载

HF 仓库约 865GB；8×H200 共 1128GB，均匀切权重后约 108GB/GPU。

1M上下文KV容量

≈5.69GB/序列

8路KV切分后≈0.71GB/序列/GPU；B=128@1M 在 8×H200 上容量不成立。

Scale‑up带宽判断

NVLink 不是第一瓶颈

H200 dense FP8/NVLink≈2199 FLOPs/Byte，低于 V4-Pro 隐藏阈值 6144 FLOPs/Byte。

Decode主瓶颈

HBM专家权重流

在线decode小batch下，每层会触达大量不同专家，L2放不下，HBM反复流专家权重。

场景	显存/GPU GB	step延迟 ms	吞吐 tok/s/8GPU	主瓶颈
Decode：B=32，S=1M（8×H200可容纳但较紧）	130.87	14.36	2,229	MoE专家权重HBM流 + 1M动态attention
Decode：B=128，S=128K（在线服务较现实）	119.56	27.78	4,607	MoE专家权重HBM流
Decode：B=128，S=1M（仅作roofline，不满足8×H200容量）	199.12	32.58	3,929	容量不可行；计算上MoE+attention

最关键修正：不能只讨论“算力够不够”或“NVLink够不够”。DeepSeek‑V4‑Pro decode 的主矛盾是 MoE 专家权重的 HBM streaming + 每专家 token 数过小；1M context 下，CSA indexer 扫描和 HCA 压缩 KV 读成为第二个明显瓶颈。 Scale‑up 网络在 8卡 NVLink 域内主要是延迟、同步、功耗和routing skew问题；一旦把 EP all-to-all 放到跨节点 RDMA/IB 上，带宽比例会迅速失衡。

2. 参数基线：DeepSeek‑V4‑Pro × NVIDIA H200 SXM

2.1 DeepSeek‑V4‑Pro 结构参数

本报告只使用 Pro：1.6T total 49B activated 1M context 61 layers hidden 7168 MoE: 1 shared + 384 routed/layer 6 routed active/token expert FFN 3072 CSA m=4, top‑k=1024 HCA m′=128 head=128, head_dim=512

CSA/HCA层数按“前2层HCA，之后交替”估算为 HCA 31层、CSA 30层。若官方实现的具体层序有细微差异，不改变瓶颈结论。

2.2 H200 SXM 推理副本

假设一个推理副本使用 8×NVIDIA H200 SXM，EP/TP 都限制在单机 NVLink/NVSwitch scale‑up 域内。 H200 SXM：141GB HBM3e、4.8TB/s HBM、NVLink 900GB/s、FP8 Tensor Core 官方列 3958 TFLOPS（带稀疏）；本报告按 dense FP8 峰值≈1979 TFLOPS/GPU 估算。

Hopper片上参考：H100 SXM5为132 SM、50MB L2；每SM 256KB combined L1/shared。H200沿用Hopper架构与更大更快HBM，片上缓存量级可作为NoC/缓存压力参考。

效率假设：HBM有效70%，NVLink有效70%，Attention projection有效40%，动态attention有效35%，decode MoE有效30%，prefill MoE有效55%。这些不是官方实测值，而是为了把“峰值硬件”转成较保守的roofline下界。报告内也保留 HBM/Compute 分项，便于替换假设。

3. 核心公式：每次数据搬运如何计入总线

3.1 KV cache 容量与读写

KV主条目大小 = (512-64)×FP8 + 64×BF16 = 448B + 128B = 576B
CSA indexer K条目 = cI×FP8 = 128B（若FP4存储则约64B，本报告用128B偏保守）
KV_per_sequence(S) = 30×ceil(S/4)×(576+128) + 31×ceil(S/128)×576 + 61×min(S,128)×576

其中最后一项是SWA/state cache的驻留；每新生成一个token的KV写入摊销只有约40.6KB/token，decode中不是主瓶颈，主瓶颈是历史KV读取与专家权重读取。

3.2 MoE专家计算、权重与EP通信

单专家参数 = 3×h×d_ff = 3×7168×3072 = 66.06M params ≈ 33.03MB(FP4)
每 token-expert pair FLOPs = 6×h×d_ff = 132.12 MFLOPs
每 token 每层激活 = 6 routed + 1 shared → 924.84 MFLOPs/layer
全61层MoE计算 = 56.42 GFLOPs/token
EP通信/token-expert pair = 3×h bytes = 21,504B（FP8 dispatch + BF16 combine）
U(B)=384×(1-(1-1/384)^(6B)) ≈ 每层被触达的不同routed experts数

例如 B=32 时，平均每层触达约151个routed专家；B=128时约332个；B≥512时几乎384个专家全被触达。decode 的专家权重读随 U(B) 快速上升，而不是只随 token 数线性上升。

3.3 Attention动态部分

CSA indexer FLOPs/token/layer = 2×64×128×ceil(S/4)
CSA core FLOPs/token/layer = 4×128×512×(topk + nwin)，topk=1024，nwin=128
HCA core FLOPs/token/layer = 4×128×512×(ceil(S/128)+nwin)
Attention projection参数约 = 19.13B params → 38.26 GFLOPs/token，不含动态KV扫描

1M上下文下，CSA indexer 扫描是动态attention计算与HBM读取的核心；HCA因m′=128，读KV量比dense attention低很多，但仍随S增长。

4. 容量先卡死：8×H200能跑什么Batch？

HF仓库显示 DeepSeek‑V4‑Pro 文件总量约865GB。8×H200总HBM 1128GB，均匀切权重后每GPU约108.1GB，留给KV、workspace、通信buffer和碎片的硬上限约32.9GB/GPU。下表假设KV也能8路切分；如果KV复制，容量会更差。

上下文	KV/序列（全局）GB	KV/序列/GPU（8路切分）GB	理论最大Batch（仅扣权重）	建议上限Batch（再留8GB/GPU）
8K	0.05	0.01	5,378	4,070
32K	0.18	0.02	1,444	1,092
128K	0.71	0.09	367	278
1M	5.69	0.71	46	34

B=128、S=1M 不满足8×H200容量：仅KV就需要约 128×0.711≈91GB/GPU，加上权重约108GB/GPU，总计约199GB/GPU，超过141GB。要跑这种并发，需要更多GPU做context/KV切分、KV offload/分层缓存、降低实际上下文或降低batch。

5. Decode：逐步延迟与带宽估算

Decode一步表示每个在线序列生成1个新token。下面给两个代表场景：B=32、S=1M 是8×H200容量上较紧但可讨论的长上下文场景；B=128、S=128K 更像在线服务商为了吞吐而做batch的场景。

5.1 场景A：B=32，S=1M，8×H200

总step延迟估算：14.36 ms，吞吐约 2,229 tok/s/8GPU。这个场景容量约 130.9 GB/GPU，已经接近实用上限。

阶段	主要数据搬运	计算量	HBM下界 ms	Compute下界 ms	采用 ms	瓶颈
Attention投影 + 输出投影	读投影权重 19.1 GB；写/读激活约 O(B·L·h)	1.22 TFLOPs	0.711636	0.193318	0.71	小/中batch时权重读；大batch时计算
CSA/HCA 动态注意力	读KV/Indexer 37.6 GB	6.58 TFLOPs	1.39893	1.186867	1.40	1M时CSA indexer扫描+HCA长序列KV
MoE Router + Dispatch + Linear1/2 + Combine	读专家权重 306.7 GB；NVLink per GPU/layer 0.45 MB	1.81 TFLOPs	11.411729	0.380094	11.41	decode小专家batch导致HBM专家权重流
LM Head / logits	读vocab head约 0.93 GB	0.06 TFLOPs	0.034475	0.009365	0.03	通常不是主瓶颈
调度/同步/内核launch余量	top-k、scatter/gather元数据、流同步、采样等	—	—	—	0.80	实现相关；roofline未包含的延迟

层内细分：B=32，S=1M

层内步骤	每层数据搬运	每层计算	单层下界	说明
CSA层 Attention	投影权重 324 MB；KV/Indexer读 1.09 GB	167.8 GF	0.053 ms	30层；1M下Indexer扫描是CSA主要流量
HCA层 Attention	投影权重 304 MB；KV读 153.4 MB	89.2 GF	0.024 ms	31层；压缩率128，所以KV读显著低于dense attention
MoE专家	触达专家≈151+shared；专家权重 5.03 GB	29.6 GF	0.187 ms	61层；decode主瓶颈
EP All-to-All	per GPU payload 0.45 MB	—	0.72 µs	payload可隐藏；真实延迟取决于collective和同步

5.2 场景B：B=128，S=128K，8×H200

总step延迟估算：27.78 ms，吞吐约 4,607 tok/s/8GPU。这个场景容量约 119.6 GB/GPU，比1M上下文可行得多。

阶段	主要数据搬运	计算量	HBM下界 ms	Compute下界 ms	采用 ms	瓶颈
Attention投影 + 输出投影	读投影权重 19.1 GB；写/读激活约 O(B·L·h)	4.90 TFLOPs	0.711636	0.77327	0.77	小/中batch时权重读；大batch时计算
CSA/HCA 动态注意力	读KV/Indexer 21.3 GB	4.42 TFLOPs	0.791932	0.797575	0.80	1M时CSA indexer扫描+HCA长序列KV
MoE Router + Dispatch + Linear1/2 + Combine	读专家权重 671.3 GB；NVLink per GPU/layer 1.81 MB	7.22 TFLOPs	24.973106	1.520377	24.97	decode小专家batch导致HBM专家权重流
LM Head / logits	读vocab head约 0.93 GB	0.24 TFLOPs	0.034475	0.03746	0.04	通常不是主瓶颈
调度/同步/内核launch余量	top-k、scatter/gather元数据、流同步、采样等	—	—	—	1.20	实现相关；roofline未包含的延迟

层内细分：B=128，S=128K

层内步骤	每层数据搬运	每层计算	单层下界	说明
CSA层 Attention	投影权重 324 MB；KV/Indexer读 0.62 GB	190.3 GF	0.036 ms	30层；1M下Indexer扫描是CSA主要流量
HCA层 Attention	投影权重 304 MB；KV读 84.9 MB	116.4 GF	0.019 ms	31层；压缩率128，所以KV读显著低于dense attention
MoE专家	触达专家≈332+shared；专家权重 11.00 GB	118.4 GF	0.409 ms	61层；decode主瓶颈
EP All-to-All	per GPU payload 1.81 MB	—	2.87 µs	payload可隐藏；真实延迟取决于collective和同步

Scale‑up结论：以B=128为例，每层EP all-to-all平均每GPUpayload约1.81MB，纯payload下界约2.87µs/层，61层约0.17ms；即使加上collective固定延迟，也通常可以被MoE计算/权重读隐藏。真正难的是细粒度dispatch/combine的同步、routing skew、功耗并发和跨节点时延，而不是单纯NVLink带宽数值。

6. Batch扫描：在线服务Batch化后的容量、延迟与吞吐

表中“容量判断”按权重865GB/8 + KV切分 + 8GB/GPU保留空间粗略判断。B越大，tokens/expert变多，Tensor Core利用率变好；但U(B)接近384后，MoE每步权重读基本饱和在约776GB/step，继续加B主要增加attention和计算。

上下文	Batch	预计触达专家/层	显存/GPU GB	容量判断	MoE权重读/步 GB	Attention KV读/步 GB	EP通信payload ms	估算step延迟 ms	吞吐 tok/s/8GPU
128K	16	85.04	109.55	可行	173.35	2.66	0.02	8.09	1,977
128K	32	151.24	110.98	可行	306.75	5.32	0.04	13.16	2,432
128K	64	242.92	113.84	可行	491.46	10.64	0.09	20.63	3,103
128K	128	332.17	119.56	可行	671.28	21.29	0.17	27.78	4,607
128K	256	377.00	131.00	可行	761.62	42.57	0.35	33.15	7,722
128K	512	383.87	153.87	不可行	775.46	85.15	0.70	36.88	13,882
1M	16	85.04	119.50	可行	173.35	18.80	0.02	8.69	1,840
1M	32	151.24	130.87	可行	306.75	37.60	0.04	14.36	2,229
1M	64	242.92	153.62	不可行	491.46	75.21	0.09	23.03	2,779
1M	128	332.17	199.12	不可行	671.28	150.41	0.17	32.58	3,929
1M	256	377.00	290.12	不可行	761.62	300.83	0.35	42.75	5,989
1M	512	383.87	472.11	不可行	775.46	601.65	0.70	56.07	9,131

服务调度含义：短上下文可以通过更大batch提高吞吐；超长上下文主要被KV容量限制，batch不能无限增加。对在线服务商，最优点通常不是“最大batch”，而是在TTFT、每token延迟、KV驻留、prefix cache命中率和队列等待之间折中。

7. Prefill：8K chunk 的计算/带宽估算

Prefill与decode不同：它一次处理大量prompt tokens，专家batch大、计算利用率高，MoE更偏计算受限；但如果已有很长前缀，动态attention会读取大量历史KV，1M场景下会变成attention/KV读受限。下面以8K token chunk估算。

Prefill chunk场景	chunk tokens	Attention投影 ms	动态Attention ms	MoE ms	KV写 ms	总延迟 ms	prefill吞吐 tok/s	动态KV读 GB
无前缀	8,192	49.49	16.06	53.07	0.01	121.64	67,348	218.69
已有128K前缀	8,192	49.49	52.17	53.07	0.01	157.75	51,930	1399.27
已有1M前缀	8,192	49.49	359.50	53.07	0.01	465.08	17,614	9663.32

Prefix cache的价值：DeepSeek报告提到为共享前缀使用on-disk KV cache，压缩KV可直接复用；但SWA未压缩，体积约为压缩CSA/HCA的8倍，因此Full/Periodic/Zero SWA缓存是在SSD写放大和重算之间折中。对服务系统，这会把瓶颈从GPU HBM部分转移到SSD吞吐、PCIe/CPU路径和KV恢复调度。

8. 总线瓶颈：片内NoC与片外Scale‑up分别卡在哪里？

8.1 片内 NoC / HBM / L2：核心不是“峰值算力”，而是数据复用太差

H200/Hopper的50MB级L2可以容纳一个FP4专家约33MB，但decode一个MoE层在B=32时平均触达约151个专家，在B=128时约332个专家。这意味着每层专家权重读是5GB到11GB量级，远超过L2可保持的工作集。NoC需要持续把专家权重从HBM搬到L2/SM，再由Tensor Core消费；小专家batch使GEMM形状偏瘦，计算单元利用率下降，HBM流量成为主瓶颈。

CSA indexer在1M上下文下也给NoC施压：每个CSA层每token要扫描约S/4=262K个indexer keys，虽然每个key只有约128B，但30层×batch累积后会产生几十GB到百GB级KV读。这个流量具有较强顺序扫描特征，适合预取和专用稀疏attention kernel，但会与MoE权重流争抢HBM与NoC。

8.2 Scale‑up：NVLink域内带宽够，跨节点EP不够

DeepSeek给出的EP隐藏条件是 C/B ≤ 2d_ff = 6144 FLOPs/Byte。H200 dense FP8约1.979PFLOP/s，NVLink 900GB/s，因此C/B≈2199 FLOPs/Byte，理论上满足隐藏条件。但如果把EP dispatch/combine放到400Gb/s级别的跨节点网络，C/B会升到约39,580 FLOPs/Byte，明显超过阈值；此时通信不能被MoE计算隐藏，decode会被网络拖住。

因此，大规模NPU推理集群的Scale‑up设计要把“专家并行域”尽量限制在低延迟高带宽的单机/单supernode内；Scale‑out更适合复制replica、做pipeline/context并行或prefill分摊，而不是把每层MoE all-to-all放到远端网络。

8.3 软件周期瓶颈：每个token经历的总线事件

1) Scheduler聚合在线请求 → 形成decode batch，读每序列KV指针/页表
2) 每层Attention：读projection权重 → 生成Q/压缩KV/SWA → CSA indexer扫描历史Indexer K → top‑k → 读选中CSA KV/HCA KV/SWA → 输出投影
3) 每层MoE：router算top‑6 → 按expert owner做dispatch all‑to‑all → 各GPU按专家分组读FP4专家权重 → Linear‑1/activation/Linear‑2 → combine all‑to‑all → residual/mHC
4) 最后一层：LM head读vocab权重 → logits/sampling → 写新token与KV cache
5) 若prefix cache命中：从SSD/host恢复压缩KV与SWA state，减少prefill但引入PCIe/SSD/CPU调度瓶颈

9. 对推理NPU总线/架构的提升点与困难

9.1 最值得投硅面积的方向

第一，扩大有效片上缓存或做专家权重近存缓存。 不是简单堆L2，而是让同一层的热点专家、相邻token的专家权重、以及FP4解包后的tile能在NoC上复用。目标是减少“每层数GB专家权重从HBM流一次”的开销。

第二，NoC要支持MoE pull/push与scatter-gather原语。 DeepSeek报告提到当前dispatch采用pull以避免细粒度push通知延迟，未来硬件若提供低延迟跨芯片信号，可以让push式通信更自然。对NPU而言，这意味着Scale‑up不只是大带宽SerDes，还要有低延迟doorbell、远端读写、credit/QoS和按expert分组的DMA。

第三，CSA indexer需要专门的流式稀疏attention通道。 1M上下文下，indexer key扫描呈长顺序读；适合硬件预取、压缩格式、FP4点积、top‑k近数据归约，避免把所有indexer scan都压到通用NoC/HBM路径上。

第四，EP域的边界要架构化。 Scale‑up域内保证C/B≤6144；跨域只传更粗粒度的数据。集群调度要让高概率共现的专家放在同一supernode，减少跨节点MoE all‑to‑all。

9.2 难点与挑战

功耗并发：DeepSeek的fused MoE让compute、HBM和network同时高负载，容易触发功耗墙。NPU不能只按单模块峰值设计，要按“Tensor + HBM + SerDes 同时满载”的电源/热设计。

routing skew：公式用均匀路由估算，但真实请求、语言、domain和hash routing会造成专家热度不均。某些GPU的专家被过多命中时，平均带宽足够也会尾延迟变差。

容量与碎片：1M上下文的KV即便压缩到约5.69GB/序列，batch 仍迅速吃满HBM。实际服务还需要paged KV、workspace、双buffer、通信buffer和prefix cache元数据，表里的“理论最大Batch”不能直接当生产上限。

软件复杂度：要把通信隐藏在MoE compute下，必须有expert分组、wave scheduling、fused GEMM、异步DMA、top‑k稀疏attention、KV layout协同。硬件带宽提升若没有软件栈配合，收益会被kernel launch、同步和小矩阵效率吃掉。

10. 参考来源与可复核口径

DeepSeek‑V4 technical report：V4-Pro 1.6T/49B、1M context、CSA/HCA、MoE、EP overlap、KV cache/on-disk cache、模型设置等。
DeepSeek‑V4‑Pro HuggingFace model card：模型下载、精度说明、仓库大小、local deployment说明。
DeepSeek API Docs · V4 Preview Release：API侧模型发布、上下文和服务约束说明。
NVIDIA H200官方页面：H200 SXM显存、HBM带宽、FP8/BF16 Tensor Core、NVLink/PCIe规格。
NVIDIA Hopper Architecture In‑Depth：Hopper L2、SM、L1/shared、TMA、NVLink/NVSwitch、FP8等片上结构参考。

本报告没有把知乎回答作为事实依据；社区讨论可辅助形成问题意识，但带宽/延迟数值以公开技术报告和芯片官方规格为准。