摘要
大语言模型（LLM）的迅速扩展揭示了当前硬件架构在内存容量、计算效率和互联带宽方面的关键限制。DeepSeek-V3 在 2,048 张 NVIDIA H800 GPU 上训练，展示了“硬件感知的模型协同设计”如何有效应对这些挑战，实现大规模训练与推理的成本效率。
本文深入分析了 DeepSeek-V3/R1 模型架构及其 AI 基础设施，重点介绍以下创新：
• 多头潜在注意力机制（MLA）：提升内存效率；
• 专家混合架构（MoE）：优化计算与通信权衡；
• FP8 混合精度训练：充分释放硬件潜力；
• 多平面网络拓扑：最小化集群级网络开销。
通过 DeepSeek-V3 发展中遇到的硬件瓶颈，本文还就未来硬件发展方向展开更广泛的讨论，包括低精度计算单元、规模提升与分布式扩展的融合、新一代低延迟通信结构等。
第1章：引言（Introduction）
1.1 背景
近年来，大语言模型（LLMs）经历了快速演进，这一进展得益于模型设计、计算能力以及数据可用性的迭代提升。2024 年，诸如 GPT-4o [59]、LLaMa-3 [3]、Claude 3.5 Sonnet [8]、Grok-2 [73]、Qwen2.5 [75]、Gemini-2 [37] 以及我们提出的 DeepSeek-V3 [26] 等开创性模型取得了显著进展，进一步缩小了通往通用人工智能（AGI）的差距。如 Scaling Laws [45] 所示，扩大模型规模、训练数据和计算资源将显著提升模型性能，突显出“扩展”在推动 AI 能力提升方面的关键作用。
这些发展共同标志着一个新时代的到来：扩大模型规模与计算能力被视为释放更高智能水平的关键。
近期的发展中，诸如 OpenAI 的 o1/o3 系列模型 [60, 61]、DeepSeek-R1 [28]、Claude 3.7 Sonnet [9]、Gemini 2.5 Pro [38]、Seed1.5-Thinking [68] 和 Qwen3 [71] 等“推理模型（reasoning models）”，不仅展示了大规模架构所带来的性能提升，同时也彰显出提升推理效率的迫切性，特别是在处理更长上下文以及实现更深层次推理方面。这些进展进一步突显出对更快、更高效推理能力的需求，从而对计算资源提出了日益增长的挑战。
为应对这些挑战，业界领先者如阿里巴巴、字节跳动、谷歌、xAI 和 Meta 部署了庞大的训练集群 [33, 42, 43, 56, 62, 74]，配备了数万甚至数十万张 GPU 或 TPU。尽管这种大规模基础设施使得最先进模型得以开发，但其高昂成本也为小型研究团队和组织带来了显著门槛。
尽管存在这些障碍，一些开源初创团队（如 DeepSeek [23–26, 28] 和 Mistral [41, 55]）仍在积极研发最前沿模型。其中，DeepSeek 尤其展现了“软硬件协同设计（software-hardware co-design）”的高效性，证明即使是小型团队，也能通过协同设计实现低成本的大模型训练。
延续这一传统，DeepSeek-V3 [26] 成为低成本训练领域的又一重要里程碑。仅使用 2,048 张 NVIDIA H800 GPU，DeepSeek-V3 便实现了当前最优性能。这一成果也延续了此前 Fire-Flyer AI-HPC [7] 架构在成本效率上的承诺与实践。通过 DeepSeek-V3 所总结的实践经验与见解，我们展示了如何将现有硬件资源发挥至最大潜力，并为更广泛的 AI 与高性能计算（HPC）社区提供了宝贵参考。。
1.2 研究目标
本论文并不旨在重复详尽介绍 DeepSeek-V3 的架构与算法细节，这些内容已在其技术报告 [26] 中有充分阐述。相反，我们采用一种“双重视角”——横跨硬件架构与模型设计——以探索两者之间在实现大规模、低成本训练与推理过程中的复杂交互。
通过研究这种协同关系，我们希望为如何在不牺牲性能与可访问性的前提下高效扩展 LLM，提供可操作的洞察。
具体来说，本文聚焦于：
• 硬件驱动的模型设计：分析硬件特性（如 FP8 低精度计算、scale-up / scale-out 网络属性）如何影响 DeepSeek-V3 的架构设计；
• 模型与硬件之间的相互依赖性：探讨硬件能力如何塑造模型创新，以及 LLM 不断增长的需求又如何推动下一代硬件的发展；
• 未来硬件演进方向建议：从 DeepSeek-V3 中提炼出关键经验，为未来 AI 系统的软硬件协同架构提供可行路径。
三大研究重点：
1. 硬件驱动的模型设计：探讨 FP8 低精度计算和网络结构如何影响模型架构；
2. 模型与硬件的双向耦合：硬件能力如何推动模型创新，反之亦然；
3. 未来硬件方向：基于 DeepSeek-V3 的实践，提出硬件/模型协同设计的建议。
1.3 论文结构
本论文其余部分结构如下：
• 第 2 章 探讨了 DeepSeek-V3 架构背后的设计原则，强调了 Multi-head Latent Attention、Mixture-of-Experts 优化以及 Multi-Token Prediction 模块等关键创新；
• 第 3 章 阐述我们如何围绕低精度计算与通信优化模型架构；
• 第 4 章 讨论 scale-up 互连的优化方式、scale-up / scale-out 的融合策略，以及硬件特性如何影响并行策略与专家选择；
• 第 5 章 聚焦 scale-out 网络优化，包括多平面网络协同设计与低延迟互连结构；
• 在总结第 3 至第 5 章的当前限制与未来建议基础上，第 6 章 更深入探讨了从 DeepSeek-V3 中获得的重要见解，明确指出未来软硬件协同设计的关键方向。
第2章：DeepSeek 模型的设计原则
DeepSeek-V3 的开发体现了一种硬件感知的 LLM 扩展方法，其中每一项设计决策都与硬件约束紧密对齐，以优化性能和成本效率。
如图 1 所示，DeepSeek-V3 采用了在 DeepSeek-V2 中已被验证有效的 DeepSeek-MoE [27] 和多头潜在注意力（Multi-head Latent Attention, MLA）[25] 架构。DeepSeek-MoE 释放了 MoE 架构的潜力，而 MLA 通过压缩键值（KV）缓存显著减少了内存占用。此外，DeepSeek-V3 融合了 FP8 混合精度训练，在不牺牲模型质量的前提下降低了计算成本，使大规模训练更为实际可行。为提升推理速度，DeepSeek-V3 集成了基于其多 Token 预测模块（Multi-Token Prediction Module）的预测性解码技术，显著提升了生成速度。
在模型架构之外，我们还探索了成本高效的 AI 基础设施，通过部署两层多平面 Fat-Tree 网络（Multi-Plane Two-Layer Fat-Tree），替代传统三层结构，从而降低集群网络成本。
这些创新旨在解决 LLM 扩展中的三大核心挑战：内存效率、成本效率与推理速度，以下小节将对此展开详细探讨
2.1 内存效率
LLM 通常需要大量内存资源，且每年的内存需求增长超过 1000%，而高带宽内存（HBM）容量的增长速度通常不足 50% [35]。虽然多节点并行是一种可行的解决方案，但从源头优化内存使用仍是一种重要且高效的策略。
2.1.1 低精度模型
与使用 BF16 权重的模型相比，FP8 显著减少了一半的内存占用，有效缓解了 AI 的“内存墙”问题。第 3 节将详细讨论低精度技术。
2.1.2 通过 MLA 减少 KV 缓存
在 LLM 推理中，用户请求通常包含多轮对话。为高效处理这些请求，需缓存上下文信息，即所谓的 KV 缓存。KV 缓存保存了之前处理过的 token 的 Key 和 Value 向量，从而在后续 token 推理时无需重复计算。
在每一次推理步骤中，模型仅需计算当前 token 的 Key 和 Value 向量，并将其与历史缓存进行 attention 运算。这种增量计算将生成每个 token 的复杂度降低为 O(N)，在处理长序列或多轮输入时非常高效。然而，这也引入了一个以内存为瓶颈的问题：计算从 GEMM 转向 GEMV，而后者的计算-内存比远低于前者。尽管现代硬件具备每秒数百 TFLOPS 的计算能力，GEMV 很快就会因内存带宽限制而成为瓶颈。
为应对这一挑战，我们采用了 多头潜在注意力（MLA） [25] 技术，该方法将所有注意力头的 KV 表示压缩为一个较小的 latent 向量，使用一个投影矩阵实现，该矩阵与模型一同训练。在推理过程中，仅需缓存 latent 向量即可，与缓存所有 attention head 的 KV 值相比，显著降低了内存使用。
除了 MLA，还有多种方法用于减小 KV 缓存大小，这些方法为内存高效的注意力机制提供了重要的灵感：
• 共享 KV（Grouped-Query Attention, GQA；Multi-Query Attention, MQA）：多个注意力头共享一组 KV 向量，从而显著压缩 KV 存储。如 GQA [5] 与 MQA [70]。
• 窗口 KV（Windowed KV）：对于长序列，仅保留滑动窗口内的 KV 向量，丢弃窗口外的历史。虽然节省了存储，但会削弱长上下文的推理能力，如 Longformer [11]。
• 量化压缩（Quantized Compression）：使用低比特数表示 KV 向量 [40, 44, 52]，以进一步减少内存使用，在保证性能的前提下实现显著压缩。
表 1 比较了 DeepSeek-V3、Qwen-2.5 72B [75] 和 LLaMA-3.1 405B [4] 在 BF16 精度下每个 token 的 KV 缓存开销。得益于 MLA，DeepSeek-V3 每个 token 的缓存仅需 70 KB，远低于 Qwen-2.5 的 327 KB 与 LLaMA-3.1 的 516 KB。这一显著优势使 DeepSeek-V3 在处理长上下文与资源受限环境中表现更具可扩展性与成本效率。
2.1.3 面向未来的资源高效技术展望
尽管减小 KV 缓存是一种提升内存效率的有效方式，但 Transformer 自回归解码的二次复杂度仍是超长上下文中的一大挑战。近期研究如 Mamba-2 [21] 与 Lightning Attention [63] 正在探索线性复杂度替代方案，为计算成本与模型性能之间的平衡提供新思路。
此外，稀疏注意力（sparse attention）[76] 也是另一类尝试，通过压缩并稀疏激活注意力的 key 和 value 向量，以克服注意力机制中的计算瓶颈。我们期待与学术与工业界共同努力，在该领域实现更大突破。
2.2 MoE 模型的成本效率
2.2.1 降低训练计算需求
MoE 架构的首要优势是显著降低训练成本。通过仅激活部分专家参数，MoE 模型可在总参数数量大幅增加的同时，保持相对较低的计算需求。例如，DeepSeek-V2 拥有 236B 参数，但每 token 仅激活 21B；而 DeepSeek-V3 扩展至 671B，仅激活 37B。相比之下，Qwen2.5-72B 与 LLaMA3.1-405B 等密集模型在训练中需激活全部参数。
如表 2 所示，DeepSeek-V3 每 token 的训练计算开销为 250 GFLOPS，远低于 Qwen-72B 的 394 GFLOPS 和 LLaMA-405B 的 2448 GFLOPS。MoE 模型在以更少计算资源实现相当或更高性能方面表现出巨大潜力。
2.2.2 适合本地化与个人部署
随着个性化 LLM 代理的普及 [53]，MoE 模型在单请求场景中展现出独特优势。由于每次推理仅激活部分参数，内存与计算压力大幅降低。例如，DeepSeek-V2 推理时仅激活 21B 参数，使搭载 AI SoC 芯片的个人电脑实现每秒近 20 token 的生成速度，甚至更高；而同等能力的 dense 模型通常仅能达到个位数 TPS。
值得注意的是，借助日益流行的 KTransformers 推理引擎，整个 DeepSeek-V3 模型可在约 $10,000 成本的消费级 GPU 服务器上运行，并实现近 20 TPS 的推理性能。
这种效率优势使得 MoE 架构特别适合资源有限的本地化部署与单用户场景，在保证推理质量的同时显著降低资源需求。
2.3 提升推理速度
2.3.1 重叠计算与通信：最大化吞吐
推理速度涵盖系统最大吞吐量与单请求延迟。为最大化吞吐，我们从设计之初就引入了“双 micro-batch 重叠”策略 [31, 78]，在通信延迟与计算中实现重叠。
通过将 MLA 与 MoE 的计算解耦，我们实现了一个 micro-batch 执行 MLA/MoE 计算时，另一个 micro-batch 同时进行调度通信（dispatch）；而在后者执行计算时，前者则执行合并通信（combine）。这种流水线化方法确保 GPU 始终处于高利用状态。此外，我们在生产环境中采用 prefill-decode 解耦架构，将大批次预填充请求与低延迟解码请求分配至不同的专家并行组，从而在真实服务场景中最大化系统吞吐。
2.3.2 推理速度上限（Inference Speed Limits）
本节关注于 LLM 服务的“每输出 Token 时间”（Time Per Output Token, TPOT）这一核心指标，它不仅直接影响用户体验，也关系到如 OpenAI o1/o3 与 DeepSeek-R1 等推理模型在长推理链中提升智能能力的效果。
对于 MoE 模型，要实现高推理速度，关键在于高效部署专家参数到各计算设备上。理想情况下，每个设备应仅负责计算一个专家（或多个设备共同计算一个专家），但专家并行（Expert Parallelism, EP）需要在各设备间调度 token，这依赖网络的 all-to-all 通信。因此，MoE 的推理速度上限受限于互联带宽。
考虑一个系统，其中每个设备持有一个专家的参数，并同时处理约 32 个 token。这一 token 数既能平衡计算-内存比，也能确保在 EP 中每个设备负载均衡，通信时延容易测算。
在使用 CX7 400Gbps InfiniBand（IB）网卡互联的系统中，EP 所需两次 all-to-all 通信的总时间可计算如下：
通信时间 = (1字节 + 2字节) × 32 × 9 × 7K / 50GB/s = 120.96 微秒
其中，dispatch 使用 FP8（1字节），combine 使用 BF16（2字节），每个 token 的 hidden size 约为 7K；因每 token 会发送至 8 个路由专家与 1 个共享专家，共计 9 次。
如 2.3.1 节所述，在“双 micro-batch 重叠”策略中，若假设计算开销可忽略，则性能上限由通信时延决定。在理想推理负载中，MLA 计算通常主导执行时间，但以下是理论上限估算：
每层总耗时 = 2 × 120.96 μs = 241.92 μs
DeepSeek-V3 共 61 层，总推理时间为：
总推理时间 = 61 × 241.92 μs = 14.76 ms
换算为 TPOT 即约 14.76ms，即 67 token/s。
但实际中受通信开销、带宽利用不完全与计算非理想等因素影响，该值会进一步下降。
相比之下，若使用如 GB200 NVL72（72 GPU 组成的900GB/s 单向带宽）这种高带宽互联，则每次 EP 通信时间降为：
通信时间 = (1字节 + 2字节) × 32 × 9 × 7K / 900GB/s = 6.72 μs
假设计算时间等于通信时间，则每层时间为：
2 × 6.72 μs = 13.44 μs；总 TPOT = 61 × 13.44 μs = 0.82 ms
即理论上可实现 1200 token/s，尽管该数据尚未通过实测验证，但足以展示高带宽互联对加速大模型推理的巨大潜力。
尽管 MoE 模型具备良好的扩展性，单靠增加硬件资源提升推理速度成本极高，因此还需通过软件与算法共同优化推理效率。
2.3.3 多 Token 预测（Multi-Token Prediction）
受到 Gloeckle 等人 [36] 启发，DeepSeek-V3 引入了多 Token 预测（MTP）框架，在提升模型性能的同时加快推理速度。传统自回归模型每步仅生成一个 token，造成推理瓶颈。而 MTP 可同时预测多个候选 token 并并行验证，有效加快生成过程，类似于自草稿（self-drafting）式的 speculative decoding 方法 [14, 48]。
如图 1 所示，每个 MTP 模块使用一层轻量结构来预测额外 token，相比完整模型显著更轻量，可并行验证多个候选 token。尽管稍微影响吞吐，该方法显著缩短了端到端生成延迟。实际数据表明，MTP 模块对第二个 token 的预测接受率达到 80%~90%，相比未使用 MTP 时 TPS 提升约 1.8 倍。
此外，每步预测多个 token 还可提高推理时的 batch size，有助于提升专家并行中的计算密度与硬件利用率。这类算法创新对 DeepSeek-V3 快速且成本有效的推理尤为重要。
2.3.4 面向推理模型的高推理速度与测试时扩展（Test-Time Scaling）
在 OpenAI 的 o1/o3 系列 [60, 61] 中，测试时扩展（Test-time Scaling）策略显著提升了数学推理、编程与通用推理能力。这些方法通过在推理时动态调整计算资源以提升效果。后续模型如 DeepSeek-R1、Claude-3.7、Gemini 2.5 Pro、Seed1.5-Thinking 与 Qwen3 也采用类似策略并在相关任务上表现优异。
对这些推理模型而言，高 Token 输出速度至关重要。在强化学习训练（如 PPO [67]、DPO [64] 和 GRPO [69]）中，需快速生成大量样本，高推理吞吐成为瓶颈。同样，推理序列越长，用户等待时间越长，降低了实际可用性。因此，通过软硬件协同优化推理速度是提高模型效率的关键。
不过，如何有效提升推理速度并加速 RL 训练仍是研究热点，如 2.1.3 节所述。我们鼓励学术界与工业界持续合作，探索新解法以应对这些挑战。
2.4 技术验证方法（Technique Validation Methodology）
每项加速技术（如 MLA、FP8 训练、网络协同 MoE 路由）在引入前均经过严格实证验证，以评估其对精度的影响。考虑到在全尺寸模型上执行详尽消融实验代价高昂，我们采用了分层、资源友好的验证流程：
1. 首先在小规模模型上进行广泛验证；
2. 然后在大模型上做最小限度调优；
3. 最终将多项技术集成至一次完整训练中。
例如，在集成 FP8 前，我们在 16B 与 230B 的 DeepSeek-V2 模型上做了精细化的消融实验。在这些受控设置下，相较 BF16，FP8 的相对精度损失低于 0.25%，得益于高精度累加策略与细粒度量化策略。
第三章 低精度驱动设计（Low-Precision Driven Design）
3.1 FP8 混合精度训练（FP8 Mixed-Precision Training）
量化技术（如 GPTQ [32] 和 AWQ [51]）已被广泛应用于将模型位宽缩减至 8 位、4 位甚至更低，从而显著降低内存需求。然而，这些技术主要在推理阶段使用，用于节省显存，而非训练阶段。
虽然 NVIDIA 的 Transformer Engine 已支持 FP8 混合精度训练一段时间，但在 DeepSeek-V3 之前，尚无开源的大模型在训练阶段采用 FP8。通过我们基础设施与算法团队的深入协作，并经过大量实验与技术创新，我们开发出了适用于 MoE 模型的 FP8 训练框架。如图 1 所示，我们在训练管道中的多个计算组件中使用了 FP8 精度前向与反向计算。采用了细粒度量化策略，即：对激活值使用 tile-wise 1×128 量化，对模型权重使用 block-wise 128×128 量化。
我们在 DeepSeek-V3 技术报告 [26] 中详细记录了 FP8 框架的更多技术细节，并将我们细粒度 FP8 GEMM 实现以 DeepGEMM [77] 的形式开源。
3.1.1 限制（Limitations）
虽然 FP8 在加速训练方面具有巨大潜力，但要充分发挥其能力，仍需解决若干硬件层面的限制：
• FP8 累加精度问题：FP8 在 Tensor Cores 中的累加精度受限，这会影响大模型训练时的稳定性，特别是在 NVIDIA Hopper 架构中。其具体表现为：在将 32 个尾数乘积右移对齐（基于最大指数）后，Tensor Core 仅保留最高的 13 位尾数用于加法运算，其结果被累加到 FP22 寄存器中（即 1 位符号位，8 位指数位，13 位尾数位）。
• 细粒度量化的开销：tile-wise 与 block-wise 等细粒度量化方式在将部分结果从 Tensor Core 传输到 CUDA Core 后还需进行缩放因子的乘法计算，造成较大的反量化（dequantization）开销。频繁的数据移动降低了计算效率，也增加了硬件利用的复杂性。
3.1.2 建议（Suggestions）
为解决现有硬件的局限性，我们对未来设计提出以下建议：
• 提高累加精度：建议硬件将累加寄存器的精度提升到如 FP32，或支持可配置的累加精度，以在训练与推理场景下根据精度与性能需求做平衡选择。
• 原生支持细粒度量化：建议硬件原生支持细粒度量化，使 Tensor Core 可接收缩放因子并完成带缩放的矩阵乘法计算。这意味着 Tensor Core 能够在内部完成所有部分和的累加与反量化，直到最终结果输出，避免频繁的数据移动，降低反量化开销。NVIDIA Blackwell 提出的微缩放数据格式（microscaling data format）[66] 就是一种可行的工业级实践，体现了原生量化在规模上的优势。
3.2 LogFMT：通信压缩（LogFMT: Communication Compression）
在 DeepSeek-V3 架构中，我们对网络通信采用了低精度压缩。在专家并行（EP）中，token 调度阶段采用了细粒度 FP8 量化，相比 BF16 降低了 50% 的通信量，从而显著缩短通信时间。尽管由于精度需求，合并阶段（combine）仍使用 BF16，但我们也在积极测试 FP8、自定义精度格式（如 E5M6）以及 FP8-BF16 混合使用，以进一步减少通信数据量。
除了传统的浮点格式外，我们还尝试了一种新数据类型，称为对数量化浮点格式（Logarithmic Floating-Point Formats, LogFMT-nBit），其中 n 为总比特数，最前的一位为符号位 S。通过将激活值从线性空间映射到对数空间，LogFMT 能使激活分布更加均匀。
具体实现如下：
• 给定一个 1×128 的数据块 [x₁, …, xₘ]，先取其绝对值并计算 log( |xᵢ| )，然后找到最小值 min 与最大值 max。
• 将最小值编码为 S.00…01，最大值编码为 S.11…11，步长为 step = (max - min) / (2ⁿ⁻¹ - 2)。
• 零值被特殊编码为 S.00…00。
• 其余值在原始线性空间中进行四舍五入，取最接近 step 的整数倍。
• 解码过程通过 min + step × (K - 1) + sign 还原。
通过局部计算 min 和 step，该数据类型在不同 block 上实现动态表示范围，相较静态浮点格式，能覆盖更广范围或获得更高精度。此外，我们发现，在原始线性空间中进行四舍五入操作更能保持激活量化的无偏性。
我们还对 min 设置了一个下限：不得小于 max - log(2³²)，使其最大表示范围与 E5（5 位指数的浮点数）相当。
我们在一个约 7B 参数的 dense 模型上测试了 LogFMT-nBit，通过量化 residual 分支的输出以模拟 MoE 模型中的 combine 阶段。在使用 n=8（与 FP8 相同位数）时，LogFMT-8Bit 在训练精度上优于 E4M3 与 E5M2；当增加到 n=10 位后，其效果接近 BF16 combine 阶段的表现。
3.2.1 限制（Limitations）
设计 LogFMT 的初衷是应用于激活值的通信传输或激活函数前后阶段，以在相同位宽下提供比 FP8 更高的精度。但随后所有计算仍需转换回 BF16 或 FP8，以兼容 Hopper GPU 的 Tensor Core 数据类型。
由于 GPU 带宽无法高效支持 log/exp 操作，且 encode/decode 阶段存在大量寄存器占用，如果将 encode/decode 与 all-to-all 通信融合执行，则开销可能高达 50%～100%。因此，尽管实验结果验证了该格式的有效性，我们最终未在主流程中使用该格式。
3.2.2 建议（Suggestions）
建议未来硬件为 FP8 或自定义精度格式提供原生的压缩与解压缩单元，以降低通信带宽需求并简化通信管道。这类通信开销的减少，特别适用于 MoE 训练等带宽密集型任务。
第四章 基于互联的设计（Interconnection Driven Design）
4.1 当前硬件架构（Current Hardware Architecture）
我们当前使用的 NVIDIA H800 GPU SXM 架构，如图 2 所示，基于 Hopper 架构构建，与 H100 GPU 类似。然而，为了满足监管合规性，H800 SXM 在 FP64 计算性能和 NVLink 带宽方面被做了削减。具体而言，H800 SXM 节点的 NVLink 带宽由 900 GB/s 减至 400 GB/s。如此显著的带宽削减对高性能工作负载构成了挑战。
为进行补偿，每个节点配备了 8 张 400G 的 InfiniBand (IB) CX7 网卡，从而增强了横向扩展能力（scale-out），用于弥补带宽上的不足。
针对上述硬件限制，DeepSeek-V3 的模型架构纳入了多项设计考量，以适应其优势与局限性。
4.2 面向硬件的并行策略（Hardware-Aware Parallelism）
为契合 H800 架构的特性，我们在 DeepSeek-V3 中采用了如下并行策略，以优化模型性能：
• 避免 Tensor 并行（TP）：由于 NVLink 带宽有限，训练过程中我们避免使用 TP。然而，在推理阶段，TP 仍可按需启用，以减少延迟并提升 TPOT 性能。
• 增强的流水线并行（Pipeline Parallelism, PP）：我们采用 DualPipe [29] 方案，使注意力机制与 MoE 的计算与通信可并行重叠执行，从而减少流水线气泡（pipeline bubble），并在 GPU 之间实现内存负载均衡，从而提升吞吐。更多细节可参考技术报告 [26]。
• 加速专家并行（Expert Parallelism, EP）：得益于每个节点配备的八张 400Gbps IB 网卡，系统能够实现超过 40 GB/s 的 all-to-all 通信速度。我们自研的 all-to-all EP 实现方案 DeepEP [78] 已开源，在后续小节中将进一步介绍。
4.3 模型协同设计：节点限制型路由（Model Co-Design: Node-Limited Routing）
在 H800 架构中，节点内（scale-up）通信与节点间（scale-out）通信之间的带宽差距约为 4:1。具体而言，NVLink 提供 200 GB/s 实际带宽（理论为 400 GB/s，实际约 160~200 GB/s），而每张 400Gbps IB 网卡提供 50 GB/s（考虑小消息和延迟，约为 40 GB/s 有效带宽）。
为了平衡该差异并充分利用节点内的更高带宽，模型架构被协同设计以适应硬件，尤其在专家选择策略（TopK Expert Selection Strategy）中尤为明显。
以 8 个节点（共 64 块 GPU）和 256 个路由专家为例（每块 GPU 存放 4 个专家），DeepSeek-V3 中每个 token 被路由至 1 个共享专家和 8 个路由专家。如果这 8 个路由专家分布在全部 8 个节点上，则需要将 token 分别通过 IB 向所有 8 个节点传输，通信时间为 8t（t 为单次 IB 传输时间）。
然而，若多个专家位于同一节点，我们只需一次 IB 传输将 token 发至目标节点，再借助 NVLink 完成节点内的二次转发。这种“NVLink 转发”机制可对 IB 流量去重（deduplication）。当目标专家仅分布在 M 个节点时，IB 通信成本即可缩减至 Mt（M < 8）。
基于这一特性，DeepSeek-V3 引入了“节点限制型路由”策略用于 TopK 专家选择：将 256 个专家分为 8 组，每组 32 个专家部署在一个节点中，并通过算法策略确保每个 token 最多只被路由至 4 个节点。该策略有效缓解了 IB 通信瓶颈，并提升训练时的通信带宽利用率。
4.4 Scale-Up 与 Scale-Out 的融合（Scale-Up and Scale-Out Convergence）
4.4.1 当前实现的限制（Limitations of Current Implementations）
尽管“节点限制型路由”策略降低了通信带宽需求，但也带来了通信管道 kernel 实现的复杂性。这是因为节点内 NVLink 和节点间 IB 带宽存在显著差异。
实践中，GPU 的 Streaming Multiprocessors（SM）线程需同时处理如下任务：
• 网络报文管理（如填充 QP 和 WQE）；
• NVLink 传输数据；
• 数据聚合（例如 EP combine 的 reduce 操作）；
• 数据类型转换。
例如，在训练阶段，H800 GPU 上最多有 20 个 SM 被分配用于处理上述通信任务，导致可用于计算 kernel 的资源减少。
为最大化在线推理的吞吐，我们在推理时完全通过 NIC RDMA 执行 EP all-to-all 通信，从而避免了 SM 资源争用，提升计算效率。这也凸显了 RDMA 异步通信模型在通信与计算重叠方面的优势。
当前通信中 SM 负责的关键任务包括：
• 数据转发：跨 IB 与 NVLink 域之间聚合与分发报文；
• 数据搬运：从 RDMA buffer 到 input/output buffer；
• Reduce 操作：执行 EP combine 所需的聚合；
• 内存布局管理：在跨 IB 与 NVLink 域传输时处理分块数据；
• 数据类型转换：在 all-to-all 通信前后做数据类型 cast。
4.4.2 建议（Suggestions）
为应对上述低效问题，我们强烈建议未来硬件将 scale-up 与 scale-out 通信能力融合成统一架构。通过集成专用网络流量管理协处理器，实现 NVLink 与 IB 域的无缝转发，可显著减少软件复杂度并最大化带宽利用率。
例如，在 DeepSeek-V3 中采用的节点限制型路由策略若配合动态去重的硬件支持，可进一步优化通信性能。我们也关注了如 Ultra Ethernet Consortium（UEC）[17, 18]、Ultra Accelerator Link（UALink）[16] 以及 Unified Bus（UB）[49] 等新兴协议，它们有望推动 scale-up/scale-out 通信的融合发展。
在编程框架层面，我们提出以下设计建议：
1. 统一网络适配器（Unified Network Adapter）：设计支持 scale-up 与 scale-out 网络统一接入的 NIC 或 I/O Die，并具备基础交换功能，实现将 scale-out 网络的流量转发至 scale-up 网络中指定 GPU。通过统一的 LID 或 IP 地址配合策略路由即可实现。
2. 专用通信协处理器（Dedicated Communication Co-Processor）：集成可编程协处理器（如 I/O Die）用于处理网络流量，卸载 GPU SM 的控制面任务。建议还内置硬件加速的数据拷贝能力以实现高效的 buffer 管理。
3. 灵活转发、广播与聚合机制：建议硬件原生支持 scale-up 与 scale-out 网络之间的灵活转发、广播（用于 EP dispatch）和 reduce（用于 EP combine）操作，以提升带宽效率并降低通信计算开销。
4. 硬件级同步原语（Hardware Synchronization Primitives）：提供更细粒度的硬件同步指令，用于处理内存一致性或报文乱序问题，替代当前基于软件的 RDMA 完成事件等机制。具备 acquire/release 语义的 memory-semantic 通信机制是一个有前景的实现方式。
通过上述建议，未来硬件架构将能有效提升大规模分布式 AI 系统的效率，并简化软件开发过程。
4.5 带宽争用与延迟（Bandwidth Contention and Latency）
4.5.1 分层带宽争用（Hierarchical Bandwidth Contention）
如第 2 节所述，训练阶段的专家并行（EP）通信依赖两个 all-to-all 操作：dispatch（分发）和 combine（合并）。在 MoE 训练中，多个 token 会同时发送到同一个专家进行并行计算。这种设计提高了 GPU 利用率，但也可能造成不同 token 的通信请求在到达共享链路（如 scale-up 或 scale-out 层）前出现拥塞。
这一问题可以建模为一个 三层的双向调度问题，涉及：
1. token 到专家的映射（mapping from tokens to experts）；
2. 专家在节点内的调度（mapping of experts within the node）；
3. 专家在节点间的调度（mapping of experts across nodes）。
例如，在最坏情况下，如果多个 token 的专家目标均位于同一节点，则所有通信请求将争用该节点的网络资源。当前 DeepSeek-V3 使用的基线方法是：对专家分配使用固定权重的贪婪哈希策略，尽可能平均地将专家负载分布在不同节点上，以减少热点（hotspot）问题。
我们相信更先进的调度方法可以显著缓解该问题。正在探索的方法包括：
• 增量式调度算法：以流水线方式逐步调度 token，避免集中通信；
• 拓扑感知调度器（topology-aware schedulers）：根据实际网络拓扑（如 Fat-Tree）动态调整 token 调度路径；
• 负载均衡路由（load-balanced routing）：基于当前节点负载动态重分配请求。
4.5.2 多租户中的延迟感知调度（Latency-Aware Scheduling in Multi-Tenant Scenarios）
在典型的大模型训练系统中，多任务训练（multi-task training）广泛应用，特别是在指令微调（instruction tuning）或 RLHF 场景中。此类场景中，一个训练任务会混合多个不同来源的数据集，如代码、数学、语言、图像等，每种数据集的输入 token 长度可能相差极大。
在调度这些长度差异明显的输入时，会造成通信行为的不确定性与资源利用不均衡，最终导致训练吞吐下降。这一现象在 FlashAttention [13] 等流水线优化算法中尤为显著。
为解决此问题，我们引入了一种 延迟感知的训练任务调度器，其核心目标是通过智能排序与分组提升系统资源利用效率。
基本做法如下：
• 对每个训练样本预估其序列长度；
• 将输入样本分组，使同一 group 内的输入长度尽可能接近；
• 优先调度短序列 group，以减少 pipeline bubble；
• 同时确保长序列 group 的整体 batch size 保持合理，避免 GPU 空转。
实验表明，该调度器能在不影响模型收敛性的前提下将训练吞吐提升 12%~19%。未来我们还计划将该调度器与调度系统如 Ray 或 Kubernetes 集成，扩展其适应范围。
小结（Summary）
在本章中，我们分析了当前主流硬件架构（以 NVIDIA H800 为代表）在 scale-up（节点内扩展）与 scale-out（节点间扩展）方面的关键特征，并阐述了 DeepSeek-V3 如何通过软件与模型设计充分利用其带宽资源、应对通信瓶颈。
我们还提出了如下几个关键建议：
1. 融合 scale-up 与 scale-out 的通信架构，通过统一的 I/O 管理器与通信协处理器，简化数据流路径；
2. 支持灵活转发与原生聚合操作，以降低通信层开销；
3. 改进调度器以减少带宽争用与不均衡负载，特别是在多租户环境中。
这些建议意在引导下一代 AI 基础设施在软硬件协同方面做出优化，从而更好地支撑超大规模 LLM 的训练与推理任务。
第五章 现实中的多平面网络拓扑（Multi-plane Network Topology in the Real World）
在训练 DeepSeek-V3 的过程中，我们部署了一个多平面 Fat-Tree（MPFT）横向扩展网络，如图 3 所示。每个节点配备了 8 张 GPU 和 8 张 IB 网卡，每对 GPU–NIC 被分配到一个独立的网络平面。此外，每个节点还有一张 400Gbps 的以太网 RoCE 网卡，连接到一个独立的存储网络平面，用于访问 3FS【30】分布式文件系统。在扩展网络中，我们使用了 64 端口的 400G IB 交换机，使得该拓扑理论上可支持多达 16,384 张 GPU，同时保留了两层网络在成本和延迟方面的优势。然而，受政策与监管限制，最终仅部署了 2,000 多张 GPU。
此外，由于当前 IB ConnectX-7 的限制，我们部署的 MPFT 网络未能完全实现预期架构。理想情况下，如图 4 所示，每张 NIC 应配有多个物理端口，每个端口连接至一个独立网络平面，同时通过端口绑定被用户视为一个逻辑接口。从用户角度看，单个队列对（QP）应能无缝地通过所有可用端口发送与接收消息，类似于数据包喷洒。因此，源自同一 QP 的数据包可能走不同路径到达接收端，因而 NIC 需原生支持乱序投递以保障消息一致性与顺序语义。例如，InfiniBand ConnectX-8 原生支持四个平面。未来的 NIC 若能完全支持高级多平面能力，将有助于使两层 Fat-Tree 网络有效扩展至更大规模 AI 集群。总体而言，多平面架构在故障隔离、鲁棒性、负载均衡与大规模系统扩展性方面具备显著优势。
5.1 多平面 Fat-Tree 网络优势（Advantages of Multi-Plane Fat-Tree Network）
多轨 Fat-Tree（MRFT）的子集：MPFT 拓扑是更广义 MRFT 架构的一个特定子集。因此，NVIDIA 与 NCCL 为多轨网络开发的现有优化可以无缝应用于多平面网络部署中。此外，NCCL 对 PXN【54】技术的支持解决了平面间隔离的固有挑战，即使平面间无直接互连也能实现高效通信。
成本效益：如表 3 所示，MPFT 网络在两层 Fat-Tree（FT2）拓扑下可支持超过 10k 个终端点，相较三层 Fat-Tree（FT3）大幅降低网络成本。其每终端点成本甚至略优于成本优化的 Slim Fly（SF）拓扑【12】。
流量隔离：每个平面独立运行，确保一个平面中的拥塞不会影响其他平面。这种隔离性提升了整体网络的稳定性，防止性能崩溃的级联效应。
延迟降低：实验表明，两层拓扑比三层 Fat-Tree 拓扑具备更低的延迟，特别适合 MoE 训练与推理等延迟敏感型应用。
鲁棒性：如图 4 所示，多端口 NIC 提供多个上行链路，单端口故障不会中断连接，可实现快速、透明的故障恢复。
需要注意的是，由于当前 400G NDR InfiniBand 的限制，跨平面通信仍需通过节点内转发，从而在推理中引入额外延迟。若未来硬件实现了如前所述的 scale-up 与 scale-out 网络融合，该延迟可显著降低，进一步增强多平面网络的实用性。
5.1.2 性能分析（Performance Analysis）
为了验证多平面网络设计的有效性，我们在真实集群中修改网络拓扑，比较了多平面两层 Fat-Tree（MPFT）与单平面多轨 Fat-Tree（MRFT）的性能。以下是实验中得到的关键结论：
1. All-to-All 通信与 EP 场景：如图 5 所示，多平面网络的 all-to-all 性能与单平面多轨网络非常接近。这种性能一致性可归因于 NCCL 的 PXN 机制【54】，该机制优化了多轨拓扑下的 NVLink 流量转发，多平面拓扑同样受益于此。如图 6 所示，使用 16 张 GPU 进行的 all-to-all 通信测试结果表明，MPFT 与 MRFT 拓扑在延迟上的差异可忽略。
为了评估 MPFT 在实际训练中的 all-to-all 性能，我们还测试了训练期间常用的 EP 通信模式。如图 7 所示，每张 GPU 在多平面网络中可实现超过 40GB/s 的带宽，性能稳定可靠，满足训练需求。
- DeepSeek-V3 模型训练吞吐：我们还比较了 MPFT 与 MRFT 网络下 DeepSeek-V3 模型的训练指标，见表 4。MFU（Model Flops Utilization）基于 BF16 峰值性能计算。Causal MFU 仅计算注意力矩阵的下三角浮点运算（参考 FlashAttention【19, 20】），而 non-causal MFU 包括整个注意力矩阵的计算（参考 Megatron【47】）。1F、1B 和 1W 分别表示前向时间、输入反向时间和权重反向时间。在 2,048 张 GPU 上训练 V3 模型时，MPFT 与 MRFT 的性能几乎一致，观测到的差异均在正常波动与测量误差范围内。
5.2 低延迟网络（Low Latency Networks）
在我们的模型推理过程中，大规模的 EP 强烈依赖 all-to-all 通信，其对带宽与延迟高度敏感。参考第 2.3.2 节中提到的典型场景，在 50GB/s 的网络带宽下，数据传输时间理论应约为 120 微秒。因此，微秒级的网络固有延迟可能对系统性能产生关键性影响，其影响不可忽视。
5.2.1 IB 还是 RoCE（IB or RoCE）
如表 5 所示，InfiniBand（IB）始终实现更低的延迟，因此是分布式训练与推理等延迟敏感型工作负载的首选。尽管 IB 在延迟方面优于基于以太网的 RoCE（RDMA over Converged Ethernet），但其也存在一些限制：
• 成本：IB 硬件价格远高于 RoCE 解决方案，限制了其广泛采用；
• 可扩展性：IB 交换机通常仅支持 64 个端口，而 RoCE 交换机普遍支持 128 个端口。这限制了基于 IB 的集群在大规模部署下的扩展性。
5.2.2 对 RoCE 的改进建议（Recommendations for RoCE Improvements）
尽管 RoCE 具有成为 IB 替代方案的成本优势，但其当前在延迟与可扩展性方面的局限性使其尚不能完全满足大规模 AI 系统的需求。以下是我们提出的 RoCE 改进建议：
1. 专用低延迟 RoCE 交换机：我们建议以太网设备厂商开发专门为 RDMA 工作负载优化的 RoCE 交换机，移除不必要的以太网功能。Slingshot 架构【22】就是以太网设计实现与 IB 相当延迟性能的典范。Broadcom 最近的创新也展现了 AI 定制以太网结构的可行性，例如 AI 转发头（AIFH）与即将推出的低延迟以太网交换机。我们期待在这一方向上持续的产业创新。
2. 优化路由策略：如图 8 所示，RoCE 默认的等价多路径（ECMP）路由策略难以在互连链路之间高效分发流量，导致 NCCL 集体通信测试中性能下降严重。数据并行（DP）等 LLM 训练流量缺乏随机性，易造成多个流汇聚至同一链路。相比之下，自适应路由（Adaptive Routing, AR）【34】可通过实时喷洒分发数据包，在多个路径之间动态调度，大幅提升网络性能。静态路由虽能避免目标固定场景下的冲突，但缺乏灵活性。对于大规模 all-to-all 通信，自适应路由在性能与可扩展性上具有更强优势。
- 改进流量隔离或拥塞控制机制：当前 RoCE 交换机仅支持有限数量的优先级队列（priority queues），这对于 EP all-to-all 与 DP all-reduce 等并发通信模式的复杂 AI 工作负载而言远远不够。在此类混合负载下，all-to-all 流量容易因突发 many-to-one 传输导致 incast 拥塞，严重影响网络整体性能。
为缓解 incast 对其他流量的影响，可采用以下方案：
• 虚拟输出排队（VOQ）：为每个 QP（队列对）分配专属虚拟队列，实现流量隔离；
• 更有效的拥塞控制机制：如基于 RTT 的拥塞控制（RTTCC）或用户可编程的拥塞控制（PCC），这些机制允许在 NIC 与交换机之间协同优化，在动态流量条件下保持低延迟与高吞吐。
5.2.3 InfiniBand GPUDirect Async（IBGDA）
我们使用 InfiniBand GPUDirect Async（IBGDA）【2, 57】来降低网络通信中的延迟。传统网络通信通常涉及创建一个 CPU 代理线程：GPU 准备好数据后需通知 CPU，由 CPU 填充控制信息（Work Request, WR），然后通过 doorbell 机制通知 NIC 启动数据传输。这一流程引入了显著的通信开销。
IBGDA 通过允许 GPU 直接填写 WR 内容并写入 RDMA doorbell 的 MMIO 地址来解决这一问题。IBGDA 使 GPU 可管理整个控制面，从而消除了 GPU–CPU 之间通信带来的显著延迟。此外，在发送大量小数据包时，控制面处理器容易成为瓶颈。得益于 GPU 拥有多个并行线程，发送方可利用这些线程分担控制负载，从而避免瓶颈。
包括我们自研的 DeepEP【78】在内的多项工作均已使用 IBGDA 并报告了显著的性能提升【1, 15, 79】。因此我们强烈建议所有加速设备广泛支持此类功能。
第六章 面向未来硬件架构设计的讨论与见解
在前述章节的基础上，我们总结了关键的架构性见解，并概述了为大规模 AI 工作负载量身定制的未来硬件设计方向。
第 2.3.2 节强调了大规模 scale-up 网络对于加速模型推理的重要性。第 3 章探讨了高效支持低精度计算与通信的必要性。第 4 章则分析了 scale-up 与 scale-out 架构的融合及若干增强建议。第 5 章聚焦于多平面网络拓扑，并识别了以太网互联中需要改进的关键点。
上述各章共同揭示了在实际应用背景下的硬件局限，并提供了相应的建议。在此基础上，本章节将讨论范围扩展至更广泛的考量，并提出面向未来硬件架构设计的前瞻性方向。
6.1 鲁棒性挑战（Robustness Challenges）
6.1.1 局限性（Limitations）
• 互联故障（Interconnect Failures）：高性能互联（如 IB 和 NVLink）容易出现间歇性断连，这会干扰节点间通信。尤其是在通信密集型负载如 EP 中，即使是短暂的中断也可能导致显著的性能下降或任务失败。
• 单点硬件故障（Single Hardware Failures）：节点崩溃、GPU 故障或 ECC（纠错码）内存错误可能危及长时间运行的训练任务，通常需要代价高昂的重启。在大规模部署中，此类故障影响被进一步放大，因为随着系统规模的增加，单点故障的概率也线性上升。
• 静默数据损坏（Silent Data Corruption）：某些 ECC 无法检测的错误（如多比特内存翻转或计算误差）对模型质量构成重大风险。这些错误在长时间任务中尤其隐蔽，可能未被发现地传播并污染下游计算。当前的缓解策略依赖于应用级启发式方法，难以保障系统层面的鲁棒性。
6.1.2 高级错误检测与修复建议（Suggestions for Advanced Error Detection and Correction）
为减轻静默损坏带来的风险，硬件必须引入超越传统 ECC 的高级错误检测机制。例如，基于校验和（checksum）的校验或硬件加速的冗余检查技术，可为大规模部署提供更高的可靠性。
此外，硬件厂商应向终端用户提供全面的诊断工具包，使其能严格验证系统完整性，并主动识别任何潜在的静默数据损坏。这类工具若能作为标准硬件包的一部分嵌入，可增强系统透明度，并在整个运行周期中持续验证，从而提升整体系统可信度。
6.2 CPU 瓶颈与互联问题（CPU Bottlenecks and Interconnects）
虽然加速器设计常被置于核心地位，但 CPU 在协调计算、管理 I/O 和维持系统吞吐方面仍然不可或缺。然而，当前架构在以下几个方面面临关键瓶颈：
首先，如第 4.5 节所述，CPU 与 GPU 之间的 PCIe 接口经常成为带宽瓶颈，尤其是在大规模参数、梯度或 KV 缓存传输过程中。为缓解此问题，未来系统应采用 CPU–GPU 直接互联（如 NVLink 或 Infinity Fabric），或将 CPU 与 GPU 一起整合进 scale-up 域，从而消除节点内部瓶颈。
除了 PCIe 限制外，要维持如此高的数据传输速率还需要极高的内存带宽。例如，若要饱和 160 条 PCIe 5.0 通道，单节点就需超过 640GB/s 的内存带宽，约等于每节点 1TB/s，这对传统 DRAM 架构构成重大挑战。
最后，内核启动和网络处理等延迟敏感任务需具备高单核 CPU 性能，通常要求基础频率超过 4GHz。此外，现代 AI 负载要求每个 GPU 配备足够的 CPU 核心以避免控制侧瓶颈。对于基于小芯片的架构，还需额外核心来支持面向缓存的工作负载划分与隔离。
6.3 迈向面向 AI 的智能网络（Toward Intelligent Networks for AI）
为了满足延迟敏感型工作负载的需求，未来的互连架构必须同时优先考虑低延迟和智能网络能力：
• 共封装光学（Co-Packaged Optics）：集成硅光子技术可实现更高的可扩展带宽和更优的能效，这两者对于大规模分布式系统来说都是至关重要的。
• 无损网络（Lossless Network）：基于信用的流控制（Credit-Based Flow Control，CBFC）机制可确保数据传输无损，但若天真地触发流控，可能会引发严重的首部阻塞（Head-of-Line Blocking）。因此，迫切需要部署高级的、由端侧驱动的拥塞控制（Congestion Control，CC）算法，以主动调节注入速率并避免病态拥塞场景。
• 自适应路由（Adaptive Routing）：正如第 5.2.2 节所强调的，未来网络应标准化采用动态路由方案，例如数据包喷洒（packet spraying）和拥塞感知路径选择，这些方案能够持续监控实时网络状态并智能地重新分配流量。这些自适应策略在缓解热点和减轻集体通信工作负载（如 all-to-all 和 reduce-scatter 操作）中的瓶颈方面尤为有效。
• 高效容错协议（Efficient Fault-Tolerant Protocols）：通过部署自愈协议、冗余端口和快速故障转移技术，可以显著增强系统对故障的鲁棒性。例如，链路层重试机制和选择性重传协议在扩展大型网络的可靠性方面至关重要，有助于最小化停机时间并确保在间歇性故障下无缝运行。
• 动态资源管理（Dynamic Resource Management）：为了有效处理混合型工作负载，未来硬件应支持动态带宽分配和流量优先级调度。例如，在统一集群中应将推理任务与训练流量隔离，以保障延迟敏感型应用的响应能力。
6.4 关于内存语义通信与顺序问题的讨论
（Discussion on Memory-Semantic Communication and Ordering Issue）
使用 load/store 内存语义进行跨节点通信是一种高效且对程序员友好的方式，但当前实现仍受到内存顺序约束问题的限制。例如，在写入数据后，发送端必须显式发出内存屏障（fence），然后再更新一个标志位以通知接收端，以确保数据一致性。这种严格的顺序要求引入了额外的 RTT（往返时间）延迟，并可能阻塞发出线程，抑制正在进行的 store 操作，从而降低吞吐量。
类似的乱序同步问题也出现在消息语义的 RDMA 中；例如，在 InfiniBand 或 NVIDIA BlueField-3 上，在常规 RDMA 写入之后使用分组喷洒（packet spraying）方式执行 RDMA 原子加法操作时，也会引入额外的 RTT 延迟。
为解决这些问题，我们主张在硬件层面支持对内存语义通信内建的顺序保障。此类一致性应同时由编程模型（例如通过 acquire/release 语义）和接收端硬件来施加，从而在不引入额外开销的前提下实现有序传输。
我们认为有多种方式可以实现这一点。例如，接收端可以缓冲原子消息，并使用分组序号进行有序处理。然而，一种基于 acquire/release 机制的方法在优雅性与效率之间达成更好平衡。
我们建议一种简单的概念性机制，称为 区域获取/释放机制（Region Acquire/Release，RAR），其中接收端硬件维护一个 bitmap 用于追踪某个 RNR（Receiver Not Ready）内存区域的状态，而 acquire/release 操作的作用范围限定于该 RAR 地址范围。
借助极小的 bitmap 开销，这一机制能实现高效的、由硬件强制执行的顺序性，不再需要发送端显式设置屏障，从而将顺序保障交由硬件完成 —— 最好是在 NIC 或 I/O 芯片上执行。
值得一提的是，RAR 机制不仅有助于内存语义操作，也可推广至消息语义的 RDMA 原语，从而拓展其实用性和适用范围。
6.5 网络内计算与压缩
（In-Network Computation and Compression）
EP（专家并行）包含两个关键的 all-to-all 阶段 —— dispatch（分发）和 combine（合并）—— 它们为网络内优化提供了重要机会。
dispatch 阶段类似于小规模的多播操作，其中单个消息需要被转发至多个目标设备。如果硬件层能够实现自动的数据包复制与多目标转发协议，将能极大减少通信开销并提高效率。
combine 阶段则类似小规模的归约操作，其可以通过网络内聚合技术获得加速。然而，由于 EP combine 阶段的归约范围较小，且负载不均衡，实现灵活的网络内聚合较具挑战性。
此外，正如第 3.2 节所强调的，LogFMT 实现了低精度 token 传输，同时对模型性能影响甚微。若能将 LogFMT 原生集成至网络硬件中，通信效率将进一步优化 —— 既提升信息熵密度，又降低带宽消耗。硬件加速的压缩与解压能力将使 LogFMT 可无缝嵌入分布式系统中，从而提升整体吞吐。
6.6 面向内存的创新
（Memory-Centric Innovations）
6.6.1 内存带宽的局限性（Limitations of Memory Bandwidth）
随着模型规模呈指数增长，高带宽内存（HBM）技术的发展速度却远远落后于模型需求。这种差距造成了明显的内存瓶颈，尤其是在以 Transformer 为代表的注意力密集型架构中尤为突出。
6.6.2 建议（Suggestions）
• 堆叠式 DRAM 加速器（DRAM-Stacked Accelerators）：通过先进的 3D 堆叠技术，可将 DRAM 芯粒垂直集成在逻辑芯片之上，从而实现极高的内存带宽、极低的延迟以及适度但实际可用的内存容量（虽然受到堆叠层数限制）。这种架构范式特别适合专家模型（MoE）推理任务，其在内存吞吐方面存在严重瓶颈。类似 SeDRAM【72】的架构已展示了该方法在内存受限任务中的巨大潜力。
• 晶圆级集成（System-on-Wafer，SoW）：采用晶圆级集成技术【50】可以最大化计算密度与内存带宽，从而满足超大规模模型的运行需求。
第七章 结论（Conclusion）
DeepSeek-V3 充分体现了软硬件协同设计（hardware-software co-design）在推动大规模 AI 系统的可扩展性、效率与鲁棒性方面的变革性潜力。通过识别当前硬件架构的种种限制，并提出可操作的改进建议，本文为新一代 AI 优化硬件提供了一条明确的路线图。
随着 AI 工作负载在复杂性和规模上的持续增长，这些创新将成为关键驱动力，推动智能系统的未来发展。
