DeepSeek‑V4 推理场景下：大规模 NPU 集群片内 NoC 与片外 Scale‑up 总线瓶颈分析

重排版 HTML 报告。以 DeepSeek‑V4‑Pro 为主参考、V4‑Flash 为低成本对照，按在线服务的完整推理数据流拆解 attention、MoE 路由、专家并行 All‑to‑All、KV cache、DDR/HBM/SSD 分层缓存，以及 NoC 与 Scale‑up/Scale‑out 互联的协同瓶颈。

版本：2026‑06‑05 范围：推理芯片 / NPU 集群 / 在线 Batch 服务 主线：总线瓶颈、提升点、落地难点

1. 结论摘要

总线核心矛盾

V4 把长上下文 attention 的 KV cache 压下去，但 MoE 每层仍需要高频 Dispatch / Combine，瓶颈从“纯 KV 容量”转向“稀疏、短包、低时延、可重叠的 All‑to‑All”。

片内 NoC

NoC 不是只搬矩阵 tile。它要同时承受 HBM/DDR 权重流、KV 随机 gather、网络 RDMA 注入、专家输出 reduce 和 host 调度，且这些流在 fused kernel 下并发出现。

片外 Scale‑up

对于 V4‑Pro，每个 token‑expert 对约需 3h bytes 通信、6h·dff FLOPs；官方给出的可隐藏条件等价为 6,144 FLOPs/Byte。超过平衡点后，继续堆带宽收益递减，低时延与原语更重要。

最重要判断：在线推理的 P99 不会由单一“峰值 TOPS”决定，而由 每个 decode step 的有效 batch、每专家 tokens 数、专家 All‑to‑All 消息粒度、KV cache 层次命中率、以及 NoC/HBM/Scale‑up 并发时是否降频共同决定。
瓶颈优先级位置为什么重要典型症状
P0MoE EP Dispatch / CombineV4‑Pro 61 层、每层 6 个 routed experts；小 batch decode 时消息短、专家负载不均，带宽与微秒级延迟都敏感。TPOT 抖动、GPU/NPU 利用率被网络尾部拖低、hot expert 拥塞。
P0HBM/DDR 权重与 KV 访问单专家 FP4 权重仍是几十 MB 级；低 batch 下每专家 GEMM 算术强度不足，容易从算力瓶颈退化成内存带宽瓶颈。算力峰值很高但 decode TPS 不随 TOPS 线性增长。
P1Heterogeneous KV cache 管理CSA/HCA/SWA 的 KV entry 尺寸和更新策略不同，PagedAttention 类统一分页假设被打破。cache 碎片、随机读、cache-line 对齐损失、长上下文抖动。
P1Scale‑up / Scale‑out 边界跨节点专家路由需要在 NVLink/自研 Scale‑up 与 IB/RoCE/以太之间转发，软件同步、RDMA completion、out-of-order 处理会放大延迟。同机房平均带宽够，但 P95/P99 不稳。
P2Host / Runtime 调度continuous batching、prefix cache、prefill/decode disaggregation 与 MoE 路由需要毫秒级甚至更细粒度决策。吞吐和时延目标互相牵制，服务商很难同时满载与低延迟。

2. DeepSeek‑V4 参考参数与推理芯片假设

公开资料没有披露 DeepSeek‑V4 的真实生产集群切分方式、每颗芯片片上 SRAM/NoC 规格、Ascend 950PR 的完整互联参数。因此本报告把“官方模型参数 + 公开论文中的通信公式 + V3 硬件经验”作为估算基准，所有数值均用于架构研判，不视为 DeepSeek 线上部署配置。

项目DeepSeek‑V4‑ProDeepSeek‑V4‑Flash对总线的含义
总参数 / 激活参数1.6T / 49B active284B / 13B activePro 权重容量必须跨芯片分片；Flash 更容易单节点或小 EP group 部署。
层数 / hidden size61 / 716843 / 4096hidden size 直接决定 MoE dispatch/combine payload 与 NoC 激活搬运。
MoE experts1 shared + 384 routed/layer1 shared + 256 routed/layer专家数越多，batch 被分散后每专家 tokens 越少，低 batch decode 越容易 memory/network bound。
每 token 激活 routed experts66每层至少 6 路专家数据流，产生高频 All‑to‑All。
专家中间维度 dff30722048决定每 token‑expert 计算量和权重 tile 规模。
AttentionCSA m=4, top‑k=1024; HCA m′=128; SWA window=128CSA m=4, top‑k=512; HCA m′=128; SWA window=128KV cache 不再是规则、同尺寸、纯连续 append/read，NoC/DDR 需要支持压缩块、稀疏索引和局部窗口并存。
上下文 / 最大输出1M / 384K1M / 384K1M 上下文让 KV 容量、prefix cache、SSD/host DDR 分层成为服务商必需能力。
官方 API 并发上限5002500可以作为线上资源紧张程度与服务分层的外部信号；Pro 更受高端算力约束。

权重容量的数量级

模型全 FP4全 FP8全 BF16
V4‑Pro 1.6T≈ 0.8 TB≈ 1.6 TB≈ 3.2 TB
V4‑Flash 284B≈ 142 GB≈ 284 GB≈ 568 GB

V4 技术报告提到 routed expert parameters 使用 FP4；其他模块精度、布局和 checkpoint shard 方式会改变真实容量。

KV cache 的数量级

V4 报告称：在 1M context 下，V4‑Pro 单 token inference FLOPs 约为 V3.2 的 27%，KV cache 约为 V3.2 的 10%；V4‑Flash 分别约为 10% 和 7%。如果以 V3 公开的 70.272 KB/token KV cache 量级作参照，则 1M token 请求的 V4‑Pro KV 约为数 GB 级，而不是数十 GB 级。

这并不代表 HBM 压力消失：并发 100 个长上下文请求依然会让 KV 占用进入数百 GB 级，并触发 host DDR / CXL / SSD 分层。

3. 推理软件周期：逐 token、逐专家的数据流

下面按一次在线推理请求的真实数据搬运顺序拆解。关键点是：prefill 与 decode 只是外层阶段；内部每层都包含 attention cache 访问、MoE route、All‑to‑All、专家 GEMM、combine、残差与下一层激活转发。

① 入队与 Batch请求排队、prefix match、continuous batching
② Embeddingtoken → hidden；少量表查与激活写入
③ CSA/HCA/SWA压缩 KV 写入；decode 稀疏/压缩 KV 读取
④ Routergate logits → top‑6 experts
⑤ Dispatchhidden 按专家发往本地/远端 NPU
⑥ Expert GEMMgate/up/down + activation；权重从 HBM/DDR 流入
⑦ Combine & Head专家输出回传、加权求和、MTP/LM head
软件子阶段主要数据片内 NoC 要求HBM/DDR/SSD 要求片外 Scale‑up/Scale‑out 要求
入队、prefix cache 查询request metadata、prefix hash、cache block index低命中后需要从 disk/host/HBM 恢复 KV；cache miss 则进入完整 prefill。多副本 cache 一致性、cache-aware routing；否则同一 prefix 被重复 prefill。
Prefill attention长 prompt 的 Q/KV、CSA/HCA 压缩块、SWA 状态需要大吞吐 DMA、cache-line 对齐写入、压缩块生成流水顺序写 KV，对 HBM 容量与写带宽敏感；长 prefix 可落盘。若 attention tensor parallel，需 all‑reduce/reduce‑scatter；prefill 可用大 batch 掩盖网络。
Decode attention当前 token Q、历史压缩 KV、CSA indexer top‑k、HCA dense compressed KV、SWA window随机 gather、小块读取、bank conflict 与 TLB 压力上升从连续带宽型访问变成稀疏/压缩/窗口混合访问；cache miss 会放大时延。attention 分片时存在跨芯片 KV/partial logits 汇聚；长上下文下更依赖局部性。
Router / expert selectionhidden → gate scores → top‑6 expert ids少量计算，但输出会驱动后续数据重排gate 权重很小；主要是元数据和排序/分桶 buffer。需要快速把 tokens 按 expert、rank、node 分桶；小 batch 下元数据开销不能忽略。
MoE Dispatch每 token hidden 向 top‑6 experts 发送；Pro hidden=7168网络 DMA 注入 HBM 时与 GEMM 读写抢 NoC；需要 QoS 和多 DMA engine。RDMA buffer、专家输入 staging；最好避免 CPU copy。核心瓶颈。短包多、incast/outcast、hot expert、跨节点转发都会影响 P99。
Expert GEMM + activation专家权重、token batch、SwiGLU/低成本 activation、partial output权重 multicast、tile reuse、片上 SRAM 双缓冲、NoC 到 compute array 的供数稳定性单专家权重 Pro FP4 约 33 MB；每专家 tokens 少时 HBM/DDR 带宽主导。如 expert tensor parallel，还需要局部 reduce；专家跨多芯片会增加同步。
MoE Combine专家输出 BF16 回传并按 router weight 加权合并reduce / scatter / writeback 并发；需避免与下一层 prefetch 冲突。输出 staging、residual buffer、下一层输入。与 Dispatch 同等关键；Combine payload 通常比 Dispatch 更大，因为 BF16。
MTP / LM head / sampling隐藏态、候选 token、vocab logits、采样状态vocab head 可能大矩阵；MTP 模块增加小额计算换取少 decode step。LM head 权重和 logits buffer；可用 TP/分片 vocab。logits all‑gather/top‑k reduce；MTP acceptance 影响后续 batch 粒度。

4. 关键带宽与算力估算

4.1 MoE Dispatch / Combine：V4‑Pro 的核心公式

每 token‑expert pair 通信量 ≈ hidden × (FP8 dispatch + BF16 combine) = h × (1 + 2) = 3h bytes 每 token‑expert pair 计算量 ≈ 6 × h × d_ff FLOPs （SwiGLU 的 gate/up/down 投影） 通信可完全隐藏条件：C/B ≤ V_comp/V_comm = (6h·d_ff)/(3h) = 2d_ff V4‑Pro: d_ff=3072 → 6144 FLOPs/Byte V4‑Flash: d_ff=2048 → 4096 FLOPs/Byte
估算项V4‑ProV4‑Flash解释
每 token‑expert 通信3×7168 = 21.5 KB3×4096 = 12.3 KBDispatch FP8 + Combine BF16，不含元数据、padding、重传。
每 token‑layer 的 routed 通信≈ 129 KB≈ 73.7 KBtop‑6 routed experts；shared expert 若远端也会增加。
每输出 token 跨全部层 routed 通信≈ 7.9 MB≈ 3.2 MB这是 aggregate payload；实际分布在 EP group 内。
每 token‑expert 计算≈ 132 MFLOPs≈ 50 MFLOPs只估专家 FFN 三个投影。
每输出 token 全层 routed expert 计算≈ 48 GFLOPs≈ 13 GFLOPsattention、shared expert、norm、head、MTP 另计；49B/13B active params 给出更高总量级。

4.2 在线 batch 对“每专家 tokens 数”的决定性影响

MoE 推理最怕“小 batch 被大量 experts 稀释”。假设路由均匀，单层平均每个 routed expert 获得的 token 数为：

tokens_per_expert ≈ batch_tokens × top_k / routed_experts
decode 活跃序列数 / batch tokensV4‑Pro：384 experts, top‑6V4‑Flash：256 experts, top‑6判断
1282.0 tokens/expert3.0 tokens/expert极差 GEMM 太小，网络短包与 HBM 权重流主导。
5128.012.0偏差 可跑但难吃满算力。
204832.048.0可用 需要 MTP/continuous batching 保持稳定。
409664.096.0较好 专家 GEMM 算术强度改善，但排队延迟上升。
在线服务商的核心 trade‑off：batch 做大可提高每专家 tokens 数、减少权重流与短包开销；但 batch 做大会增加排队延迟，并且不同用户输出长度不等会产生长尾。V4 的 1M 上下文与 reasoning/agent 长输出会进一步放大这个矛盾。

4.3 单专家权重流：为什么 DDR/HBM 带宽仍是硬瓶颈

项目V4‑Pro 单 routed expertV4‑Flash 单 routed expert总线含义
专家参数量估算3×7168×3072 ≈ 66M params3×4096×2048 ≈ 25M paramsgate/up/down 三矩阵。
FP4 权重容量≈ 33 MB≈ 12.6 MB单专家就超出很多片上 SRAM tile 容量，只能分块流入。
FP8 权重容量≈ 66 MB≈ 25 MB低 batch 下反复读权重，HBM/DDR 成瓶颈。
单 token FP4 算术强度≈ 4 FLOPs/Byte≈ 4 FLOPs/Byte需要足够多 token 复用同一专家权重，算术强度才能线性上升。

5. 片内 NoC 与片外 Scale‑up 的瓶颈地图

5.1 片内 NoC：不是“带宽越大越好”，而是并发流的仲裁与局部性

NoC 需要承载的并发流

  • HBM/DDR → compute array 的专家权重 tile 流。
  • HBM/DDR → attention kernel 的 CSA/HCA/SWA KV gather。
  • Scale‑up NIC / die‑to‑die fabric 注入的 Dispatch activations。
  • Expert GEMM 输出 → Combine reduce/writeback。
  • 下一层预取、当前层写回、runtime metadata 更新。

片上缓存策略

  • 完整专家权重通常不应假设能驻留片上；片上 SRAM 更适合做 tile buffer、activation staging、KV block cache。
  • 对 V4‑Pro，单 expert FP4 权重约 33 MB；若芯片片上 SRAM 为几十 MB，缓存一个专家都很紧张，更无法缓存多专家。
  • Decode 阶段每专家 tokens 数少，权重 tile 复用不足；NoC 应支持权重 multicast、双缓冲和跨 core 分块。
  • CSA top‑k 与 HCA dense compressed KV 混合读取需要 gather/scatter 友好的 bank layout 与预取。
NoC 子问题V4 为什么加重设计建议
Bank conflict / 随机 gatherCSA 先压缩再稀疏选择 top‑k，HCA 又以 m′=128 做重压缩；KV block 尺寸与层策略不同。KV cache layout 与 sparse attention kernel 联合设计，cache-line padding，面向 block gather 的 DMA。
RDMA 注入与 GEMM 争 NoCMoE fused kernel 试图把通信、内存、计算全部重叠，NoC 与 HBM 控制器同时满载。为网络 DMA、HBM load、compute writeback 设置 QoS/virtual channel；提供网络流量独立 copy engine。
片上 SRAM 容量错配专家权重太大，KV cache 太长，片上只能缓存局部 hot blocks。软件暴露 expert hotness 与 KV hot prefix；硬件提供可编程 cache partition 与 pinned region。
低精度格式转换routed expert FP4、Dispatch FP8、Combine BF16、attention 路径混合精度。NoC 端或 DMA 端支持轻量 dequant/pack/unpack，减少 compute core 侧格式搬运。
功耗墙融合 kernel 使 compute/memory/network 同时高负载，容易触发功耗限频。按通信-计算重叠场景配置功耗余量，而不是只按孤立 GEMM 峰值做 TDP。

5.2 片外 Scale‑up：MoE 的 All‑to‑All 是推理互联的第一类公民

Dense LLM 主要要求 tensor parallel 的 all‑reduce / all‑gather；MoE LLM 还要在每层做 expert dispatch/combine。V4‑Pro 的 top‑6 routed experts 让每层都产生多目的地重排。互联瓶颈不只是吞吐，还包括消息启动延迟、排序、拥塞隔离、跨节点转发和 RDMA buffer 管理。

互联问题典型瓶颈对 V4 推理的影响硬件方向
短包启动延迟decode batch 小、每专家 tokens 少，payload 不足以摊薄微秒级延迟。P99 TPOT 抖动；Flash/Pro 低价服务更依赖高并发平滑。低延迟 signaling、doorbell batching、push/pull 两种模式都要高效。
Incast / Outcast多个 token 同时命中 hot expert，Combine 又形成 many‑to‑one reduce。局部拥塞影响其他 DP/TP 流。VOQ、per‑QP 队列隔离、自适应路由、拥塞控制。
Scale‑up/Scale‑out 断层NVLink/自研 fabric 与 IB/RoCE 之间需要软件转发或额外同步。节点内带宽很高但跨节点专家一多，实际延迟被边界损耗吞掉。统一网络适配器、I/O die 转发、memory-semantic acquire/release。
通信占用 compute core用 SM/NPU core 做打包、搬运、同步会抢 GEMM 资源。算力看似空闲但 kernel 不能同时满载。网络协处理器、硬件 copy、广播/规约原语。
跨机房/大集群规模两层/三层 Fat‑Tree 成本与延迟权衡，RoCE 成本低但拥塞复杂。大规模多租户服务时网络成本和稳定性同等重要。Multi‑Plane network、低延迟以太、可编程 CC。

6. 在线服务 Batch 化：从服务调度到每专家数据流

6.1 Prefill 与 decode disaggregation 仍然必要，但还不够

DeepSeek V3 硬件反思中提到，生产中采用 prefill 与 decode 分离，并为大 batch prefill 与低延迟 decode 分配不同 expert parallelism group size。到 V4，由于 1M context、CSA/HCA heterogeneous cache、agent 长输出和 top‑6 MoE 并存，服务商还需要更细的调度维度：

Prefill 池

  • 目标：吞吐优先，尽量把 prompt tokens 聚成大 batch。
  • 瓶颈：长上下文 attention 与 KV 写入、prefix cache 构建、HBM 容量。
  • 互联：可用较大 EP group；All‑to‑All payload 大，带宽利用率较好。
  • 优化：prefix 去重、on‑disk KV cache、长文档按块编排、prefill 队列按长度分桶。

Decode / reasoning 池

  • 目标：P99 TPOT 优先，不能无限等 batch。
  • 瓶颈：每步 1 token/sequence，MoE dispatch 短包、专家 tokens 少。
  • 互联：需要更强低时延 Scale‑up；跨节点 experts 应尽量减少。
  • 优化：continuous batching、MTP/speculative decoding、hot expert placement、KV locality-aware scheduling。

6.2 每个 MoE 专家的数据流向

  1. Router 产生 top‑6 expert ids：对 batch 中每个 token 计算 gating logits；调度器把 token 按 expert id、所在芯片、所在节点分桶。
  2. Dispatch：每个 token hidden 被复制到 6 个 experts。若 expert 本地，流量走片内 NoC/本节点 fabric；若远端，走 Scale‑up 或 Scale‑out RDMA。
  3. Expert input staging：接收端按 expert 聚合 token，形成 GEMM 的 M 维。M 太小时 GEMM 退化为小矩阵，权重读占比高。
  4. Expert GEMM：读取 expert gate/up/down 权重 tile；执行 SwiGLU 或低成本替代激活；输出回写 staging buffer。
  5. Combine：专家输出乘以 router weight 后回到原 token owner，进行加权求和。Combine 常用 BF16，因此 payload 大于 FP8 dispatch。
  6. 进入下一层：token hidden 再次进入 attention，再 route 到另一组 experts；hot expert 在层间并不固定，导致 cache 和网络局部性难预测。
可落地策略：让 batch 调度器不仅看“请求数”，还看 预计 expert histogram、KV cache locality、输出长度预测、SLA 等级。这样可以把 Pro 服务、Flash 服务、cache-hit 服务、agent 长任务拆成不同池，避免彼此拖慢。

7. 芯片适配与生态信号

公开芯片厂商资料能验证“V4 正在被国内硬件生态优先适配”，但很少披露 NPU NoC、Scale‑up 拓扑、单卡 HBM/DDR、真实 TPOT/TPS 等底层指标。因此这里把厂商相关信息作为约束信号，而不是性能结论。

来源/厂商信号公开内容对总线研判的含义
DeepSeek 官方 V4 发布V4‑Pro/Flash 均 1M context，Pro 1.6T/49B active，Flash 284B/13B active；引入 CSA/HCA、mHC、Muon，并发布技术报告与权重。推理芯片必须同时面向超长上下文 KV 与 MoE expert parallelism，而不是只优化 dense GEMM。
DeepSeek 官方 APIV4‑Pro 与 V4‑Flash 均支持 thinking/non‑thinking、1M context、384K max output；Pro 官方并发上限低于 Flash。在线服务会自然分层：Pro 资源更稀缺，Flash 承担更大吞吐；硬件池可能需要异构部署。
Huawei Ascend 950 SuperNodeReuters 报道称华为 Ascend 950‑based supernode 全面支持 V4；V4 发布后大厂采购 Ascend 950PR 需求上升。国内高端 NPU 的竞争焦点已进入“能否低成本服务 MoE + 1M context”的系统级阶段；产能与软件生态仍是约束。
Cambricon / domestic chip cooperationReuters 早期报道称 DeepSeek 与 Huawei、Cambricon 合作改写 V4 底层代码以适配国产芯片。跨厂商可移植性会是巨大工程：kernel DSL、通信库、FP4/FP8 格式、RDMA 原语都需要重做。
V3/V3.2 经验DeepSeek V3 硬件反思强调 MLA 降 KV、MoE 通信-计算重叠、Multi‑Plane network、Scale‑up/Scale‑out convergence。V4 的方向不是推翻 V3，而是在更长上下文和更低精度下把这些系统要求放大。

8. 总线提升点、困难与挑战

8.1 硬件侧提升点

1. 以 MoE 平衡点设计带宽

V4‑Pro 官方公式给出 6144 FLOPs/Byte 的通信隐藏阈值。硬件不应盲目堆互联带宽，而应匹配 compute/HBM/network 三者，使 fused EP kernel 不降频。

2. 统一 Scale‑up/Scale‑out

用统一 NIC/I/O die 和转发原语消除节点内外边界，支持 EP dispatch 的 broadcast、combine 的 reduce、动态 dedup 和细粒度同步。

3. NoC 支持稀疏 KV

为 CSA/HCA/SWA 混合 cache 提供 block gather、cache-line padding、跨 bank 预取、TLB 友好的 KV layout。

4. 网络协处理器

把 packet processing、RDMA buffer copy、专家分桶、metadata packing 从 compute core 中剥离，避免通信抢占 GEMM 单元。

5. FP4/FP8 原生数据路

routed experts 使用 FP4 后，芯片需要 FP4 GEMM、scale metadata、pack/unpack、FP8 dispatch 与 BF16 combine 的低开销转换。

6. HBM‑DDR‑SSD 分层

1M context 与 prefix cache 要求 HBM 做 hot cache、DDR/CXL 做 warm cache、NVMe/分布式文件系统做 cold prefix；总线要支持异步搬运与 QoS。

8.2 软件/系统侧提升点

  • Fine‑grained EP wave scheduling：把专家切成 wave，通信完成一波就启动一波计算。
  • Fused MoE mega‑kernel：Dispatch、GEMM、activation、Combine 尽可能融合，减少 host launch 与中间写回。
  • Continuous batching + MTP：增加有效 batch 与每专家 tokens 数，降低短包和小 GEMM 占比。
  • Prefill/decode disaggregation：不同池配置不同 EP group size、KV cache 策略和 SLA。
  • Expert placement：按 router 统计、tenant、语言/任务热度做 hot expert 放置，减少跨节点专家命中。
  • KV locality-aware routing：cache-hit 请求尽量调度到已有 prefix/KV 的节点，减少重复 prefill 与远端 cache 拉取。
  • Batch-invariant deterministic kernels：在动态 batch 下保持结果稳定，降低线上调试和回归成本。
  • 跨厂商 kernel DSL：TileLang/CANN/MLU/DTK 等适配需要统一抽象，否则每个芯片都要手写稀疏 attention 与 EP kernel。

8.3 最难的挑战

挑战为什么难可能的缓解方式
低延迟与高吞吐同时满足大 batch 提吞吐，小 batch 保延迟；MoE 每专家 tokens 数与用户排队延迟天然冲突。SLA 分池、MTP、动态 batch window、Flash/Pro 分层服务。
专家负载不可预测真实请求的语言、领域、prompt 模板会造成 expert hotness，均匀假设不成立。在线 router histogram 监控、热专家复制、node‑limited routing、负载感知调度。
Heterogeneous KV 与 PagedAttention 不兼容CSA/HCA/SWA 的 entry size、压缩周期、eviction policy 不同。定制 KV block allocator、state cache、cache‑kernel co‑design。
功耗与散热EP 融合后 compute、memory、network 同时满载，峰值功耗不再由单独 GEMM 代表。为并发工作负载留 power headroom；调度器做功耗感知。
国产生态适配不只是 PyTorch 算子能跑，还要 FP4、稀疏 attention、RDMA、fused EP、调度器、监控全部成熟。开放 kernel、标准化通信原语、模型-芯片共同设计和长期 profiling。
研判：下一代推理 NPU 的胜负手不在单卡 dense TOPS，而在 MoE all‑to‑all 原语 + HBM/DDR/KV 分层 + 稀疏 attention NoC 访问 + runtime batch 调度的端到端系统能力。DeepSeek‑V4 的 1M context 与 FP4 routed expert 会把这些系统能力差距进一步放大。

9. 参考来源与可信度说明

本 HTML 采用官方资料和 Reuters/论文作为主依据；知乎等社区讨论在本版中未直接引用，因为可检索到的结果不足以稳定核验。若后续需要，我可以把知乎专业回答作为“非正式观点”单独附录。

  1. DeepSeek API Docs, “DeepSeek V4 Preview Release”, 2026‑04‑24. https://api-docs.deepseek.com/news/news260424
  2. DeepSeek‑AI, “DeepSeek‑V4: Towards Highly Efficient Million‑Token Context Intelligence”, technical report PDF, 2026. https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf
  3. DeepSeek API Docs, “Models & Pricing”. https://api-docs.deepseek.com/quick_start/pricing
  4. DeepSeek API Docs, “Context Caching”. https://api-docs.deepseek.com/guides/kv_cache
  5. DeepSeek‑AI, “DeepSeek‑V3 Technical Report”, arXiv:2412.19437. https://arxiv.org/abs/2412.19437
  6. Zhao et al., “Insights into DeepSeek‑V3: Scaling Challenges and Reflections on Hardware for AI Architectures”, ISCA 2025 / arXiv:2505.09343. https://arxiv.org/abs/2505.09343
  7. Reuters, “DeepSeek‑V4, the Chinese AI model adapted for Huawei chips”, 2026‑04‑24. https://www.reuters.com/world/china/deepseek-v4-chinese-ai-model-adapted-huawei-chips-2026-04-24/
  8. Reuters, “Big Chinese tech firms scramble to secure Huawei AI chips after DeepSeek V4 launch”, 2026‑04‑29. https://www.reuters.com/world/china/big-chinese-tech-firms-scramble-secure-huawei-ai-chips-after-deepseek-v4-launch-2026-04-29/
  9. Reuters, “DeepSeek's V4 model will run on Huawei chips, The Information reports”, 2026‑04‑03. https://www.reuters.com/world/china/deepseeks-v4-model-will-run-huawei-chips-information-reports-2026-04-03/

注：本报告中“GB/MB”按十进制近似，“KiB/MiB”未严格区分；具体工程设计应按芯片实际精度、padding、routing locality、EP/TP/PP/DP 切分、cache 命中率和压测数据重算。