DeepSeek-V4-Pro on NVIDIA H200：推理总线、带宽与延迟估算

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说明。
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等片上结构参考。

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