Insights into DeepSeek-V3: Scaling Challenges and Reflections on Hardware for AI Architectures

Chenggang Zhao, Chengqi Deng, Chong Ruan, Damai Dai, Huazuo Gao, Jiashi Li, Liyue Zhang, Panpan Huang, Shangyan Zhou, Shirong Ma, Wenfeng Liang, Ying He, Yuqing Wang, Yuxuan Liu, Y.X. Wei DeepSeek-AI Beijing, China

主要贡献

本文探讨了大型语言模型（LLMs）在快速扩展过程中暴露出的当前硬件架构的关键限制，包括内存容量、计算效率和互连带宽的约束。DeepSeek-V3模型在2048个NVIDIA H800 GPU上训练，展示了硬件感知模型协同设计如何有效应对这些挑战，实现大规模的成本高效训练和推理。本文深入分析了DeepSeek-V3/R1模型架构及其AI基础设施，突出了关键创新，如多头潜在注意力（MLA）用于提升内存效率、专家混合（MoE）架构用于优化计算-通信权衡、FP8混合精度训练以释放硬件全部潜力，以及多平面网络拓扑以最小化集群级网络开销。基于DeepSeek-V3开发过程中遇到的硬件瓶颈，本文与学术界和工业界同行展开更广泛讨论，探讨未来硬件方向，包括精确低精度计算单元、向上扩展和向外扩展的融合，以及低延迟通信结构的创新。这些洞见强调了硬件和模型协同设计在满足AI工作负载不断升级需求中的关键作用，为下一代AI系统的创新提供了实用蓝图。

研究目标不在于重复DeepSeek-V3的详细架构和算法细节（这些已在技术报告[26]中详细记录），而是从硬件架构和模型设计双重视角探讨它们在实现成本高效大规模训练和推理中的复杂互动。通过考察这种协同作用，提供可操作的洞见，以高效扩展LLMs而不牺牲性能或可访问性。具体焦点包括：硬件驱动的模型设计，分析硬件特性（如FP8低精度计算和向上/向外扩展网络属性）如何影响DeepSeek-V3的架构选择；硬件和模型之间的相互依赖，调查硬件能力如何塑造模型创新，以及LLMs的演进需求如何驱动下一代硬件需求；未来硬件发展方向，从DeepSeek-V3中衍生可操作洞见，以指导未来硬件和模型架构的协同设计，为可扩展、成本高效的AI系统铺平道路。

背景知识/关键Observation/设计原则

DeepSeek-V3的设计原则体现了硬件感知方法，用于扩展LLMs，其中每个设计决策都仔细与硬件约束对齐，以优化性能和成本效率。 如图1所示，DeepSeek-V3采用已在DeepSeek-V2[25]中证明有效的DeepSeekMoE[27]和多头潜在注意力（MLA）[25]架构。DeepSeek MoE解锁了MoE架构的潜力，而MLA通过压缩键-值（KV）缓存显著降低内存消耗。此外，DeepSeek-V3整合了FP8混合精度训练，显著降低计算成本，并在不牺牲模型质量的情况下使大规模训练更实用。为了提升推理速度，DeepSeek-V3基于其多令牌预测模块整合了推测解码，这显著提高了生成速度。除了模型架构，我们还通过部署多平面两层胖树网络来取代传统三层胖树拓扑，探索成本高效的AI基础设施，从而降低集群网络成本。这些创新旨在解决扩展LLMs的三个核心挑战——内存效率、成本效益和推理速度，这些将在以下小节中详细探讨。

LLMs通常需要大量内存资源，内存需求每年增长超过1000%。 相比之下，高速内存（如HBM）容量的增长率要慢得多，通常每年不到50%[35]。虽然多节点并行是解决内存限制的可行方案，但从源头优化内存使用仍是关键且有效的策略。

2.1.1 低精度模型。 与使用BF16权重的模型相比，FP8将内存消耗减少一半，有效缓解AI内存墙挑战。低精度技术的详细讨论在第3节低精度驱动设计中提供。

2.1.2 使用MLA减少KV缓存。 对于LLM推理，用户请求通常涉及多轮对话。为了高效处理这些，之前请求的上下文被缓存在通常称为KV缓存中。KV缓存通过缓存先前处理令牌的键和值向量来解决这一挑战，从而无需为后续令牌重新计算它们。在每个推理步骤中，模型仅计算当前令牌的键和值向量，并通过将它们与历史KV对结合进行注意力计算。这种增量计算将生成每个令牌的复杂度降低到O(n)，在处理长序列或多轮输入时高效。然而，它引入了内存绑定瓶颈，因为计算从GEMM转向GEMV，后者的计算-内存比率低得多。随着现代硬件提供数百TFLOPS，GEMV很快受内存带宽限制，使内存访问成为主要瓶颈。为了解决这一瓶颈，我们采用多头潜在注意力（MLA）[25]，它使用投影矩阵将所有注意力头的KV表示压缩为更小的潜在向量，该矩阵与模型联合训练。在推理期间，仅需缓存潜在向量，与存储所有注意力头的KV缓存相比显著降低内存消耗。除了MLA，还提出了几种其他方法来减少KV缓存的大小。这些方法极具价值，并为内存高效注意力机制的进步提供了重要启发：共享KV（分组查询注意力，GQA；多查询注意力，MQA）：多个头共享一组KV对，而不是为每个注意力头维护单独的KV对，这显著压缩KV存储。代表性方法包括GQA【5，GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints+2023+arXiv+https://arxiv.org/abs/2305.13245】和MQA【70，Fast Transformer Decoding: One Write-Head is All You Need+2019+CoRR+http://arxiv.org/abs/1911.02150】。窗口KV：对于长序列，仅保留滑动窗口的KV对缓存，丢弃窗口外的结果。虽然这减少了存储，但会损害长上下文推理。代表性方法包括Longformer【11，Longformer: The Long-Document Transformer+2020+arXiv+https://arxiv.org/abs/2004.05150】和相关架构。量化压缩：使用低位表示存储KV对【40，KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization+2024+arXiv+https://arxiv.org/abs/2401.18079】【44，GEAR: An Efficient KV Cache Compression Recipe for Near-Lossless Generative Inference of LLM+2024+arXiv+https://arxiv.org/abs/2403.05527】【52，KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache+2024+arXiv+https://arxiv.org/abs/2402.02750】，进一步减少内存使用。量化在最小影响模型性能的情况下实现显著压缩。表1比较了DeepSeek-V3、Qwen-2.5 72B【75，Qwen2.5 Technical Report+2024+arXiv+https://arxiv.org/abs/2412.15115】和LLaMA-3.1 405B【4，Llama 3.1 Model Card+2024+GitHub+https://github.com/meta-llama/llama-models/blob/main/models/llama3_1/MODEL_CARD.md】的每个令牌KV缓存内存使用。通过采用MLA，DeepSeek-V3显著减少KV缓存大小，每个令牌仅需70 KB，远低于LLaMA-3.1 405B的516 KB和Qwen-2.5 72B的327 KB。这一减少突显了MLA在压缩KV表示方面的效率，与基于GQA的方法相比。该能力使DeepSeek-V3特别适合涉及长上下文处理和资源受限环境的场景，实现更可扩展和成本高效的推理。

2.1.3 资源高效技术的未来方向和视角。 虽然减少KV缓存大小是提升内存效率的有前景方法，但Transformer-based自回归解码固有的二次复杂度仍是极长上下文的严峻挑战。最近的研究努力，如Mamba-2【21，Transformers are SSMs: generalized models and efficient algorithms through structured state space duality+2024+ICML+无URL】和Lightning Attention【63，Various lengths, constant speed: efficient language modeling with lightning attention+2024+ICML+无URL】，调查了线性时间替代方案，为平衡计算成本和模型性能提供了新可能性。此外，稀疏注意力【76，Native Sparse Attention: Hardware-Aligned and Natively Trainable Sparse Attention+2025+arXiv+https://arxiv.org/abs/2502.11089】等方法试图压缩并稀疏激活注意力键和值，代表了克服注意力计算挑战的另一种尝试。我们期待与更广泛社区合作，在这一领域实现突破。

对于稀疏计算，我们开发了DeepSeekMoE，这是一种先进的专家混合（MoE）架构，如图1右下部分所示。 MoE模型的优势体现在两个方面。

2.2.1 减少训练的计算需求。 MoE架构的主要优势在于显著降低训练成本的能力。通过仅选择性激活专家参数子集，MoE模型允许总参数计数急剧扩展，同时保持计算需求适中。例如，DeepSeek-V2具有236B参数，但每个令牌仅激活21B参数。同样，DeepSeek-V3扩展到671B参数——几乎是V2的三倍——而每个令牌激活仅保持在37B。与之相比，稠密模型如Qwen2.5-72B和LLaMa3.1-405B在训练期间需要所有参数活跃。如表2所示，DeepSeek-V3的总计算成本约为每个令牌250 GFLOPS，而72B稠密模型需要394 GFLOPS，405B稠密模型需要2448 GFLOPS。这表明MoE模型在消耗少一个数量级计算资源的情况下，实现与稠密模型相当或甚至优越的性能。

2.2.2 个人使用和本地部署的优势。 在个性化LLM代理【53，Large Language Model Agent: A Survey on Methodology, Applications and Challenges+2025+arXiv+https://arxiv.org/abs/2503.21460】变得普遍的未来，MoE模型在单请求场景中提供独特优势。因为每个请求仅激活参数子集，内存和计算需求大大减少。例如，DeepSeek-V2（236B参数）在推理期间仅激活21B参数。这使配备AI SoC芯片【6，AMD Ryzen AI Max+ PRO 395: Designed to power a new generation of compact Copilot+ PC workstations+2025+AMD网站+https://www.amd.com/en/products/processors/laptop/ryzen-pro/ai-max-pro300-series/amd-ryzen-ai-max-plus-pro-395.html】【10，Apple introduces M4 Pro and M4 Max+2024+Apple网站+https://www.apple.com/newsroom/2024/10/apple-introduces-m4-pro-and-m4-max/】【58，NVIDIA DGX Spark: A Grace Blackwell AI supercomputer on your desk+2025+NVIDIA网站+https://www.nvidia.com/en-us/products/workstations/dgx-spark/】的PC实现近20 tokens per second (TPS)，甚至两倍速度，这对个人使用绰绰有余。相比之下，类似能力的稠密模型（例如70B参数）在类似硬件上通常仅达到个位数TPS。值得注意的是，日益流行的KTransformers【39，A Flexible Framework for Experiencing Cutting-edge LLM Inference Optimizations+2025+GitHub+https://github.com/kvcache-ai/ktransformers】推理引擎允许完整DeepSeek-V3模型在配备消费级GPU的低成本服务器（成本约$10,000）上运行，同时仍实现近20 TPS。这种效率使MoE架构适合本地部署和单用户场景，其中硬件资源通常有限。通过最小化内存和计算开销，MoE模型可在无需昂贵基础设施的情况下提供高质量推理性能。

2.3.1 重叠计算和通信：最大化吞吐量。 推理速度包括系统级最大吞吐量和单请求延迟。为了最大化吞吐量，我们的模型从一开始就架构化以利用双微批次重叠【31，Profiling Data in DeepSeek Infra+2025+GitHub+https://github.com/deepseek-ai/profile-data?tab=readme-ov-file#inference】【78，DeepEP: an efficient expert-parallel communication library+2025+GitHub+https://github.com/deepseek-ai/DeepEP】，有意地将通信延迟与计算重叠。正如我们的在线推理系统所示，并由开源剖析数据【31】支持，我们将MLA和MoE的计算解耦为两个不同阶段。当一个微批次执行MLA或MoE计算的一部分时，另一个微批次同时执行相应的分发通信。相反，在第二个微批次的计算阶段，第一微批次经历组合通信步骤。这种流水线方法使all-to-all通信与正在进行的计算无缝重叠，确保GPU始终充分利用。此外，在生产中，我们采用预填充和解码分离架构【80，DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving+2024+OSDI+https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin】，将大批量预填充和延迟敏感解码请求分配到不同专家并行组大小。这种策略最终在真实世界服务条件下最大化系统吞吐量。

2.3.2 推理速度限制。 本节关注LLM服务的解码输出速度，通常以每个输出令牌时间（TPOT）衡量。TPOT是用户体验的关键指标，它也直接影响推理模型如OpenAI的o1/o3和DeepSeek-R1的响应性，这些模型依赖推理长度来提升智能。对于MoE模型，实现高推理速度依赖于高效地将专家参数部署到计算设备上。为了实现最快的推理速度，每个设备理想上应执行单个专家的计算（或多个设备协作计算单个专家，如果必要）。然而，专家并行（EP）需要将令牌路由到适当设备，这涉及跨网络的all-to-all通信。因此，MoE推理速度的上限由互连带宽决定。考虑一个系统，其中每个设备持有专家参数并一次处理约32个令牌。这个令牌计数在计算-内存比率和通信延迟之间取得平衡。这个令牌计数确保每个设备在专家并行期间处理相等的批量大小，允许轻松计算通信时间。对于使用CX7 400Gbps InfiniBand (IB) NIC互连的系统，EP中两次all-to-all通信所需时间计算如下：Comm. Time = (1Byte + 2Bytes) × 32 × 9 × 7K/50GB/s = 120.96μs。这里，分发使用FP8（1字节），而组合使用BF16（2字节），每个令牌的隐藏大小约为7K。因子9表示每个令牌传输到8个路由专家和1个共享专家。正如第2.3.1节所述，最大化吞吐量需要使用双微批次重叠。在这种策略中，我们的理论最佳案例分析假设计算开销最小化，因此性能上限由通信延迟决定。在实际推理工作负载中，请求上下文通常更长，MLA计算通常主导执行时间。因此，这一分析代表双微批次重叠下的理想化场景。在这一假设下，每层总时间可表述为：Total Time Per Layer = 2 × 120.96μs = 241.92μs。对于DeepSeek-V3的61层，总推理时间为：Total Inference Time = 61 × 241.92μs = 14.76ms。因此，该系统的理论上限约为14.76 ms TPOT，相当于67 tokens per second。然而，在实践中，通信开销、延迟、不完整带宽利用和计算低效会降低这一数字。相比之下，如果使用高带宽互连如GB200 NVL72（跨72个GPU的900GB/s单向带宽），每个EP步骤的通信时间降至：Comm. Time = (1Byte + 2Bytes) × 32 × 9 × 7K/900GB/s = 6.72μs。假设计算时间等于通信时间，这显著降低总推理时间，实现超过0.82 ms TPOT的理论上限，约1200 tokens per second。虽然这一数字纯属理论且未经验证，但它生动展示了高带宽向上扩展网络在加速大规模模型推理中的变革潜力。虽然MoE模型表现出良好可扩展性，仅通过增加硬件资源实现高推理速度成本高昂。因此，软件和算法也必须贡献于提升推理效率。

2.3.3 多令牌预测。 受Gloeckle et al.【36，Better & Faster Large Language Models via Multi-token Prediction+2024+ICML+https://openreview.net/forum?id=PEpbUobfJv】启发，DeepSeek-V3引入多令牌预测（MTP）框架，同时提升模型性能和推理速度。在推理期间，传统自回归模型在解码步骤生成一个令牌，导致顺序瓶颈。MTP通过以较低成本生成额外候选令牌并并行验证它们来缓解这一问题，类似于先前的自我起草基于推测解码方法【14，Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads+2024+ICML+https://openreview.net/forum?id=PEpbUobfJv】【48，EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty+2024+ICML+https://openreview.net/forum?id=1NdN7eXyb4】。这一框架在不牺牲准确性的情况下显著加速推理。如图1顶部所示，每个MTP模块使用单层，比完整模型轻量得多，以预测额外令牌，实现多个候选令牌的并行验证。虽然略微损害吞吐量，这种方法显著改善端到端生成延迟。真实世界实践数据表明，MTP模块在预测第二个后续令牌时实现80%到90%的接受率，与无MTP模块场景相比，将生成TPS提高1.8倍。而且，通过每步预测多个令牌，MTP增加推理批量大小，这对提升EP计算强度和硬件利用至关重要。此类算法创新对DeepSeek-V3的快速和成本高效推理至关重要。

2.3.4 推理模型的高推理速度和测试时扩展。 LLMs中的测试时扩展，以OpenAI的o1/o3系列【60，Introducing OpenAI o1+2024+OpenAI网站+https://openai.com/o1/】【61，Introducing OpenAI o3 and o4-mini+2025+OpenAI网站+https://openai.com/index/introducing-o3-and-o4-mini/】为例，通过在推理期间动态调整计算资源，在数学推理、编程和一般推理中实现了显著进步。随后模型——包括DeepSeek-R1【28，DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning+2025+arXiv+https://arxiv.org/abs/2501.12948】、Claude-3.7 Sonnet【9，Claude 3.7 Sonnet and Claude Code+2025+Anthropic网站+https://www.anthropic.com/news/claude-3-7-sonnet】、Gemini 2.5 Pro【38，Gemini 2.5: Our most intelligent AI model+2025+Google博客+https://blog.google/technology/google-deepmind/gemini-model-thinking-updates-march-2025/】、Seed1.5-Thinking【68，Seed1.5-Thinking: Advancing Superb Reasoning Models with Reinforcement Learning+2025+arXiv+https://arxiv.org/abs/2504.13914】和Qwen3【71，Qwen3: Think Deeper, Act Faster+2025+GitHub+https://github.com/QwenLM/Qwen3】——采用了类似策略，并在这些任务中实现了显著改进。对于这些推理模型，高令牌输出速度至关重要。在强化学习（RL）工作流中——如PPO【67，Proximal Policy Optimization Algorithms+2017+arXiv+https://arxiv.org/abs/1707.06347】、DPO【64，Direct Preference Optimization: Your Language Model is Secretly a Reward Model+2024+arXiv+https://arxiv.org/abs/2305.18290】和GRPO【69，DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models+2024+arXiv+https://arxiv.org/abs/2402.03300】——快速生成大量样本的必要性使推理吞吐量成为关键瓶颈。同样，延长推理序列会增加用户等待时间，降低此类模型的实际可用性。因此，通过协同硬件和软件创新优化推理速度对推进推理模型效率不可或缺。然而，加速推理和加快RL训练的有效策略仍是活跃研究领域，如第2.1.3节所述。我们鼓励更广泛社区合作探索和开发这些持续挑战的新解决方案。

每个加速技术都经过严格经验验证，以评估其准确性影响，包括MLA、FP8混合精度计算和网络协同设计的MoE门路由。 鉴于在全规模模型上进行详尽消融的成本高昂，我们采用分层且资源高效的验证管道。每个技术首先在小规模模型上广泛验证，其次是最小大规模调优，最后集成到单个全面训练运行中。例如，我们首先在16B和230B DeepSeek-V2模型上进行细粒度FP8训练消融研究，然后进行最终集成。在这些受控设置下，与BF16相比的相对准确性损失保持在0.25%以下，这归因于我们使用高精度累积和细粒度量化策略。

方法细节

量化技术如GPTQ[32]和AWQ[51]已被广泛用于将位宽减少到8位、4位甚至更低，显著降低内存需求。 然而，这些技术主要在推理期间应用以节省内存，而不是在训练阶段。NVIDIA的Transformer Engine已支持FP8混合精度训练一段时间，但DeepSeek-V3之前，没有开源大型模型利用FP8进行训练。通过基础设施和算法团队的深度合作，以及广泛实验和创新，我们开发了MoE模型的FP8兼容训练框架。图1显示了训练管道中利用FP8精度前向和后向过程的计算组件。应用细粒度量化，即激活的tile-wise 1x128量化和模型权重的block-wise 128x128量化。我们FP8框架的进一步技术细节记录在DeepSeek-V3技术报告[26]中，我们的细粒度FP8 GEMM实现已在DeepGEMM[77]中开源。

3.1.1 限制： 虽然FP8在加速训练方面有巨大潜力，但几个硬件限制需要解决以充分利用其能力：FP8累积精度：FP8在Tensor Cores中使用受限累积精度，影响大型模型训练的稳定性，特别是在NVIDIA Hopper GPU上。在根据最大指数右移对齐32个尾数乘积后，Tensor Core仅维护其最高13个分数位进行加法，并截断超出此范围的位。加法结果累积到FP22寄存器（1符号位、8指数位和13尾数位）。细粒度量化挑战：细粒度量化如tile-wise和block-wise量化引入了从Tensor Cores传输部分结果到CUDA Cores进行缩放因子乘法的巨大去量化开销。这导致频繁数据移动，降低计算效率并复杂化硬件利用。

3.1.2 建议： 为了解决现有硬件的限制，我们对未来设计有以下建议：增加累积精度：硬件应将累积寄存器精度提高到适当值（例如FP32），或支持可配置累积精度，实现不同模型训练和推理需求之间性能和准确性的权衡。本地支持细粒度量化：硬件应本地支持细粒度量化，使Tensor Cores接收缩放因子并实现组缩放的矩阵乘法。这样，整个部分和累积及去量化可直接在Tensor Cores内完成，直到产生最终结果，避免频繁数据移动以减少去量化开销。一个值得注意的工业实现是NVIDIA Blackwell对微缩放数据格式的支持【66，Microscaling Data Formats for Deep Learning+2023+arXiv+https://arxiv.org/abs/2310.10537】，这体现了大规模本地量化的实际益处。

在当前DeepSeek-V3架构中，我们为网络通信采用低精度压缩。 在EP并行期间，使用细粒度FP8量化分发令牌，与BF16相比将通信量减少50%。这显著降低通信时间。虽然组合阶段由于准确性要求仍使用更高精度（例如BF16），但我们正在积极测试FP8、自定义精度格式（例如E5M6）和混合FP8-BF16以进一步减少。除了这些传统浮点格式，我们还尝试了一种新数据类型，名为对数浮点格式（LogFMT-nBit），其中n是位数，领先1位作为符号位s。通过将激活从原始线性空间映射到对数空间，激活分布更均匀。具体而言，给定元素tile，[x1, · · · , xn]，在我们的实现中为1x128，我们取绝对值并计算所有元素的对数，并找到最小xmin = min(log(|xi|))和最大xmax = max(log(|xi|))。最小编码为s.00 · · · 01，最大编码为s.11 · · · 11，间隔表示interval = (xmax - xmin)/(2^{n-2}-1)。零值由s.00 · · · 00特别表示。左侧值四舍五入到最近整数k倍的interval。解码过程简单，通过组合符号位和exp(xmin + interval × (k -1))。通过本地计算xmin和xmax，这种数据类型为不同块支持动态表示范围，与静态浮点格式相比覆盖更大范围或提供更多精度。此外，我们发现在线性空间而不是对数空间中四舍五入对无偏激活量化很重要。我们还将xmin约束为大于xmin - log(2^{32})，这意味着最大表示范围类似于E5，具有5个指数的浮点。我们在约70亿参数的稠密语言模型上验证LogFMT-nBit，通过量化残差分支输出以模拟MoE模型中的组合阶段。当设置n=8，与FP8共享相同位时，LogFMT-8Bit显示出优于E4M3或E5M2的训练准确性。在将n增加到10位后，我们发现它类似于BF16组合阶段。

3.2.1 限制： 使用LogFMT的初始目的是将其应用于传输期间或激活函数附近的激活，因为它以相同位宽提供高于FP8的精度。然而，后续计算需要重新转换为BF16或FP8以适应Hopper GPU张量核的数据类型。由于GPU带宽不足以进行log/exp操作以及编码/解码期间的过度寄存器压力，如果编码/解码操作与all-to-all通信融合，开销可能很大（50%∼100%）。因此，虽然实验结果验证了该格式的有效性，但我们最终未采用它。

3.2.2 建议： 为FP8或自定义精度格式提供本地支持的压缩和解压缩单元代表未来硬件的可行方法。这有助于最小化带宽需求并简化通信管道。减少的通信开销在带宽密集任务如MoE训练中特别有用。

我们当前使用的NVIDIA H800 GPU SXM架构，如图2所示，建立在Hopper架构上，类似于H100 GPU。 然而，由于监管合规，它具有降低的FP64计算性能和NVLink带宽。具体而言，H800 SXM节点的NVLink带宽从900 GB/s降低到400 GB/s。这种节点内向上扩展带宽的显著减少对高性能工作负载构成挑战。为了补偿，每个节点配备八个400G Infiniband (IB) CX7 NIC，提升向外扩展能力以缓解带宽不足。为了应对这些硬件约束，DeepSeek-V3模型整合了几个与硬件优势和限制对齐的设计考虑。

为了与H800架构的约束对齐，以下并行策略被考虑以优化DeepSeek-V3的性能： 避免张量并行（TP）：由于有限NVLink带宽，在训练期间避免张量并行。然而，在推理期间，TP仍可选择性使用以减少延迟并改善TPOT性能。增强管道并行（PP）：采用DualPipe【29，DualPipe: A bidirectional pipeline parallelism algorithm for computation-communication overlap in V3/R1 training+2025+GitHub+https://github.com/deepseek-ai/dualpipe】以重叠注意力、MoE计算与MoE通信。这也减少管道气泡并平衡跨GPU的内存使用，提升整体吞吐量。额外细节可在技术报告[26]中获得。加速专家并行（EP）：使用八个400Gbps Infiniband (IB) NIC，系统实现超过40GB/s的all-to-all通信。值得注意的是，我们的all-to-all EP实现DeepEP【78，DeepEP: an efficient expert-parallel communication library+2025+GitHub+https://github.com/deepseek-ai/DeepEP】已开源，使高效专家并行如以下小节所述。

H800架构中向上扩展（节点内）和向外扩展（节点间）通信的带宽差异约为4:1。 具体而言，NVLink提供200GB/s带宽（实际可达约160GB/s），而每个400Gbps IB NIC提供仅50GB/s带宽（考虑小消息大小和延迟影响，使用40GB/s作为有效带宽）。为了平衡并充分利用更高的节点内带宽，模型架构与硬件协同设计，特别是在TopK专家选择策略中。考虑一个具有8个节点（总计64个GPU）和256个路由专家（每个GPU 4个专家）的设置。对于DeepSeek-V3，每个令牌路由到一个共享专家和8个路由专家。如果其8个目标专家分布在所有8个节点上，通过IB的通信时间为8t，其中t表示通过IB发送一个令牌的时间。然而，通过利用更高的NVLink带宽，路由到同一节点的令牌可通过IB发送一次，然后通过NVLink转发到其他节点内GPU。NVLink转发启用IB流量的去重。当给定令牌的目标专家分布在k个节点上时，去重IB通信成本将减少到kt (k < 8)。由于IB流量仅依赖于k，DeepSeek-V3为TopK专家选择策略引入节点限制路由。具体而言，我们将256个路由专家分组为8组，每组32个专家，并将每个组部署到一个节点上。在此部署基础上，我们算法上确保每个令牌将路由到最多4个节点。这种方法缓解IB通信瓶颈，并在训练期间提升有效通信带宽。

4.4.1 当前实现的限制。 虽然节点限制路由策略减少了通信带宽需求，但由于节点内（NVLink）和节点间（IB）互连的带宽差异，它复杂化了通信管道内核实现。在实践中，GPU流多处理器（SM）线程用于网络消息处理（例如填充QP和WQE）和通过NVLink的数据转发，消耗计算资源。例如，在训练期间，H800 GPU上的多达20个SM分配用于通信相关操作，留下更少资源用于实际计算。为了在在线推理中最大化吞吐量，我们完全通过NIC RDMA执行EP all-to-all通信，避免SM资源争用并改善计算效率。这突显了RDMA异步通信模型在重叠计算和通信方面的优势。以下是EP通信期间当前由SM执行的关键任务，特别是组合阶段的规约操作和数据类型转换。将这些任务卸载到专用通信硬件可释放SM用于计算内核，显著改善整体效率：转发数据：在IB和NVLink域之间聚合针对同一节点多个GPU的IB流量。数据传输：在RDMA缓冲区（注册GPU内存区域）和输入/输出缓冲区之间移动数据。规约操作：执行EP all-to-all组合通信所需的规约操作。管理内存布局：处理跨IB和NVLink域的分块数据传输的细粒度内存布局。数据类型转换：在all-to-all通信前后转换数据类型。

4.4.2 建议： 为了解决这些低效，我们强烈推荐未来硬件将节点内（向上扩展）和节点间（向外扩展）通信集成到统一框架中。通过整合专用协处理器用于网络流量管理和NVLink与IB域之间的无缝转发，此类设计可减少软件复杂性和最大化带宽利用。例如，DeepSeek-V3中采用的节点限制路由策略可通过硬件支持动态流量去重进一步优化。我们还认识到新兴互连协议如Ultra Ethernet Consortium (UEC)【17，Overview of and Motivation for the Forthcoming Ultra Ethernet Consortium Specification+2023+UEC网站+https://ultraethernet.org/wp-content/uploads/sites/20/2023/10/23.07.12-UEC-1.0-Overview-FINAL-WITH-LOGO.pdf】【18，UEC Progresses Towards v1.0 Set of Specifications+2024+UEC网站+https://ultraethernet.org/uec-progresses-towards-v1-0-set-of-specifications/】、Ultra Accelerator Link (UALink)【16，Introducing UALink 200G 1.0 Specification+2025+UALink网站+https://ualinkconsortium.org/wp-content/uploads/2025/04/UALink-1.0-White_Paper_FINAL.pdf】，两者都准备驱动向上扩展和向外扩展通信的进步。更近，Unified Bus (UB)【49，UB-Mesh: a Hierarchically Localized nD-FullMesh Datacenter Network Architecture+2025+arXiv+https://arxiv.org/abs/2503.20377】引入了一种向上扩展和向外扩展融合的新方法。第6节进一步探讨了UEC和UALink提出的几个技术创新。然而，在本节中，我们的主要焦点是编程框架级别的向上扩展和向外扩展融合：(1) 统一网络适配器：设计连接到统一向上扩展和向外扩展网络的NIC（网络接口卡）或I/O Die。这些适配器还应支持基本交换功能，如将来自向外扩展网络的数据包转发到向上扩展网络内的特定GPU。这可使用单一LID（本地标识符）或IP地址结合基于策略的路由实现。(2) 专用通信协处理器：引入专用协处理器或可编程组件——如I/O die——用于处理网络流量。该组件将从GPU SM卸载数据包处理，防止性能下降。此外，它应包括高效缓冲区管理的硬件加速内存复制能力。(3) 灵活转发、广播和规约机制：硬件应支持跨向上扩展和向外扩展网络的灵活转发、广播操作（用于EP分发）和规约操作（用于EP组合）——镜像我们当前的基于GPU SM实现。这不仅改善有效带宽，还减少网络特定操作的计算复杂性。(4) 硬件同步原语：提供细粒度硬件同步指令，以在硬件级别处理内存一致性问题或乱序数据包到达。这将消除基于软件的同步机制如RDMA完成事件的需求，后者引入额外延迟并增加编程复杂性。具有获取/释放机制的内存语义通信是一种有前景的实现。通过实现这些推荐，未来硬件设计可显著提升大规模分布式AI系统的效率，同时简化软件开发。

4.5.1 限制： 此外，当前硬件缺乏在NVLink和PCIe上不同类型流量之间动态分配带宽的灵活性。例如，在推理期间，从CPU内存到GPU传输KV缓存数据可消耗数十GB/s，饱和PCIe带宽。如果GPU同时使用IB进行EP通信，KV缓存传输和EP通信之间的争用可降低整体性能并导致延迟峰值。

4.5.2 建议： 动态NVLink/PCIe流量优先级：硬件应基于流量类型支持动态优先级。例如，与EP、TP和KV缓存传输相关的流量应分配不同优先级以最大化互连效率。对于PCIe，向用户级编程暴露流量类（TC）就足够了。I/O Die Chiplet集成：将NIC直接集成到I/O die并连接到同一封装中的计算die，而不是通过常规PCIe，将显著减少通信延迟并缓解PCIe带宽争用。向上扩展域内的CPU–GPU互连：为了进一步优化节点内通信，CPU和GPU应使用NVLink或类似专用高带宽结构互连，而不是仅依赖PCIe。与将NIC集成到I/O die的益处类似，这种方法可显著改善训练和推理期间GPU和CPU内存之间参数或KV缓存卸载的场景。

在DeepSeek-V3训练期间，我们部署了多平面胖树（MPFT）向外扩展网络，如图3所示。 每个节点配备八个GPU和八个IB NIC，每个GPU–NIC对分配到一个不同的网络平面。此外，每个节点有一个400 Gbps Ethernet RoCE NIC连接到单独存储网络平面，用于访问3FS【30，Fire-Flyer File System+2025+GitHub+https://github.com/deepseek-ai/3FS】分布式文件系统。在向外扩展网络中，我们使用64端口400G IB交换机，使拓扑理论上支持多达16,384个GPU，同时保留两层网络的成本和延迟优势。然而，由于政策和监管约束，最终仅部署了略超过两千个GPU。

此外，由于当前IB ConnectX-7的限制，我们部署的MPFT网络未完全实现预想的架构。 理想情况下，如图4所示，每个NIC将具有多个物理端口，每个连接到一个单独网络平面，但通过端口绑定集体暴露为单个逻辑接口给用户。从用户视角，单个队列对（QP）可无缝跨所有可用端口发送和接收消息，类似于数据包喷洒。因此，来自同一QP的数据包可能遍历不同网络路径并乱序到达接收器，从而需要NIC内的本地支持乱序放置以保证消息一致性和保留正确顺序语义。例如，InfiniBand ConnectX-8本地支持四个平面。未来NIC完全支持高级多平面能力将有益于两层胖树网络有效扩展到更大AI集群。总体而言，多平面架构在故障隔离、鲁棒性、负载均衡和大规模系统可扩展性方面提供显著优势。

5.1.1 多平面胖树网络的优势。 多平面胖树拓扑的子集：MPFT拓扑构成更广泛MRFT架构的特定子集。因此，NVIDIA和NCCL为多轨网络开发的现有优化可在多平面网络部署中无缝利用。此外，NCCL对PXN【54，Doubling all2all Performance with NVIDIA Collective Communication Library 2.12+2022+NVIDIA博客+https://developer.nvidia.com/blog/doubling-all2all-performance-with-nvidia-collective-communication-library-2-12/】技术的支持解决了平面间隔离的固有挑战，即使在平面之间缺乏直接互连时也启用高效通信。成本效率：如表3所示，多平面网络使用两层胖树（FT2）拓扑启用超过10k端点，显著降低与三层胖树（FT3）相比的网络成本。每个端点的成本甚至略优于成本高效的Slim Fly (SF)拓扑【12，A high-performance design, implementation, deployment, and evaluation of the slim fly network+2025+NSDI+无URL】。流量隔离：每个平面独立运行，确保一个平面的拥塞不影响其他。这改善整体网络稳定性和防止级联性能下降。延迟减少：两层拓扑实现低于三层胖树的延迟，如我们的实验所示。这使它特别适合延迟敏感应用如基于MoE的训练和推理。鲁棒性：如图4所示，多端口NIC提供多个上行链路，因此单端口故障不中断连接，并可能实现快速、透明故障恢复。重要的是，由于当前400G NDR InfiniBand限制，跨平面通信需要节点内转发，这在推理期间引入额外延迟。如果未来硬件能实现如前所述的向上扩展和向外扩展网络融合，这种延迟可显著减少，进一步提升多平面网络的可行性。

5.1.2 性能分析。 为了验证多平面网络设计的有效性，我们在集群上进行真实世界实验，修改集群网络拓扑以比较多平面两层胖树（MPFT）和单平面多轨胖树（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的高带宽，提供满足训练需求的可靠性能。

1. DeepSeek-V3模型的训练吞吐量：我们还在表4中比较了MPFT和MRFT之间DeepSeek-V3模型的训练指标。MFU（模型FLOPS利用率）基于BF16峰值性能计算。因果MFU仅考虑注意力矩阵下三角的FLOPS（符合FlashAttention【19，FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning+2023+无会议+无URL】【20，FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness+2022+NeurIPS+无URL】），而非因果MFU包括整个注意力矩阵的FLOPS（符合Megatron【47，Reducing activation recomputation in large transformer models+2023+MLSys+无URL】）。1F、1B和1W分别表示前向时间、输入后向时间和权重后向时间。在2048个GPU上训练V3模型时，MPFT的性能几乎与MRFT相同，观察到的差异在正常波动和测量误差范围内。

   

在我们的模型推理中，大规模EP高度依赖all-to-all通信，这对带宽和延迟都高度敏感。 考虑第2.3.2节讨论的典型场景，使用50GB/s网络带宽，数据传输理想上应需约120 μs。因此，微秒级的固有网络延迟可关键影响系统性能，使其影响不可忽略。

5.2.1 IB或RoCE。 如表5所示，IB始终实现更低延迟，使其成为延迟敏感工作负载如分布式训练和推理的首选。虽然IB与RDMA over Converged Ethernet (RoCE)相比具有优越的延迟性能，但它伴随某些限制：成本：IB硬件显著比RoCE解决方案昂贵，这限制了其广泛采用。可扩展性：IB交换机通常每个交换机仅支持64端口，与RoCE交换机常见的128端口相比。这限制了基于IB的集群的可扩展性，特别是大规模部署。

5.2.2 RoCE改进推荐。 虽然RoCE有潜力成为IB的成本高效替代，但其当前在延迟和可扩展性方面的限制阻止它完全满足大规模AI系统的需求。下面，我们概述改进RoCE的具体推荐：(1) 专用低延迟RoCE交换机：我们推荐以太网供应商开发专门为RDMA工作负载优化的RoCE交换机，通过移除不必要的以太网特性。Slingshot架构【22，An In-Depth Analysis of the Slingshot Interconnect+2020+SC+https://doi.org/10.1109/SC41405.2020.00039】示范了基于以太网的设计如何实现与IB相当的延迟性能。同样，Broadcom【13，Scale Up Ethernet Framework+2025+Broadcom文档+https://docs.broadcom.com/doc/scale-up-ethernet-framework】的最近创新，包括AI转发头（AIFH）和即将推出的低延迟以太网交换机，展示了为AI量身定制的高性能以太网结构的 feasibility。我们期待这一方向的持续创新。(2) 优化路由策略：如图8所示，RoCE中的默认等成本多路径（ECMP）路由策略难以有效分布互连上的流量，导致NCCL集体通信测试中的严重拥塞性能下降。LLM训练流量，如数据并行（DP），往往缺乏随机性，导致多个流汇聚到同一互连链路。相比之下，自适应路由（AR）【34，Adaptive Routing Strategies for Modern High Performance Networks+2008+IEEE Symposium on High Performance Interconnects+https://doi.org/10.1109/HOTI.2008.21】可通过动态喷洒数据包跨多路径显著提升网络性能。虽然基于手动配置路由表的静态路由可避免特定目的地的链路冲突，但缺乏灵活性。对于大规模all-to-all通信，自适应路由提供优越性能和可扩展性。(3) 改进流量隔离或拥塞控制机制：当前RoCE交换机仅支持有限数量的优先级队列，这对涉及并发通信模式如EP的all-to-all和DP的all-reduce的复杂AI工作负载不足。在此类混合工作负载中，all-to-all流量由于突发多对一传输可导致incast拥塞，可能降低整体网络性能。为了解决incast对其他流量的影响，一种方法是采用虚拟输出排队（VOQ），为每个QP分配专用虚拟队列以隔离流量流。或者，可采用更有效的拥塞控制（CC）机制如基于RTT的CC (RTTCC) 或用户可编程CC (PCC)，启用NIC–交换机协同优化，以在动态流量条件下保持低延迟和高吞吐量。

5.2.3 InfiniBand GPUDirect Async (IBGDA)。 我们利用IBGDA【2，GPUDirect Async: Exploring GPU synchronous communication techniques for InfiniBand clusters+2018+J. Parallel and Distrib. Comput.+https://doi.org/10.1016/j.jpdc.2017.12.007】【57，Improving Network Performance of HPC Systems Using NVIDIA Magnum IO NVSHMEM and GPUDirect Async+2022+NVIDIA博客+https://developer.nvidia.com/blog/improving-network-performance-of-hpc-systems-using-nvidia-magnum-io-nvshmem-and-gpudirect-async/】来减少网络通信中的延迟。传统上，网络通信涉及创建CPU代理线程：一旦GPU准备好数据，它必须通知CPU代理，后者然后填充工作请求（WR）的控制信息并通过门铃机制向NIC发出信号以启动数据传输。这一过程引入额外通信开销。IBGDA通过允许GPU直接填充WR内容并写入RDMA门铃MMIO地址来解决这一问题。通过在GPU内管理整个控制平面，IBGDA消除与GPU-CPU通信相关的显著延迟开销。而且，当发送大量小数据包时，控制平面处理器容易成为瓶颈。由于GPU具有多个并行线程，发送方可利用这些线程分布工作负载，从而避免此类瓶颈。一系列工作——包括我们的DeepEP【78】——利用了IBGDA并报告了实质性能提升【1，Offloading Communication Control Logic in GPU Accelerated Applications+2017+CCGRID+https://doi.org/10.1109/CCGRID.2017.29】【15，Efficient Heterogeneous Large Language Model Decoding with Model-Attention Disaggregation+2025+arXiv+https://arxiv.org/abs/2405.01814】【79，TileLink: Generating Efficient Compute-Communication Overlapping Kernels using Tile-Centric Primitives+2025+arXiv+https://arxiv.org/abs/2503.20313】。因此，我们主张此类能力在加速器设备中广泛支持。

基于前几节，我们总结关键架构洞见并概述针对大规模AI工作负载的未来硬件设计方向。 第2.3.2节突显了大规模向上扩展网络对加速模型推理的重要性。第3节讨论了高效支持低精度计算和通信的必要性。第4节探讨了向上扩展和向外扩展架构的融合，以及几个拟议增强。第5节聚焦多平面网络拓扑并识别了基于以太网互连所需的关键改进。这些节共同识别了具体应用上下文中的硬件限制并提供相应建议。在此基础上，本节扩展讨论到更广泛考虑并提出未来硬件架构设计的展望方向。

6.1.1 限制： 互连故障：高性能互连（例如IB和NVLink）容易间歇断开，这可中断节点到节点通信。这在通信密集工作负载如EP中特别有害，即使短暂中断也可能导致显著性能下降或作业失败。单个硬件故障：节点崩溃、GPU故障或ECC（纠错码）内存错误可损害长时间运行的训练作业，通常需要昂贵重启。此类故障的影响在大规模部署中升级，其中单点故障概率与系统大小成比例增加。静默数据损坏：未被ECC机制检测的错误，如多位内存翻转或计算不准确，对模型质量构成显著风险。这些错误在长时间任务中特别阴险，因为它们可未检测传播并损坏下游计算。当前缓解策略依赖应用级启发式，这对确保系统级鲁棒性不足。

6.1.2 高级错误检测和纠错建议。 为了缓解与静默损坏相关的风险，硬件必须整合超出传统ECC的高级错误检测机制。技术如基于校验和的验证或硬件加速冗余检查可为大规模部署提供更高可靠性。此外，硬件供应商应向终端用户提供全面诊断工具包，赋能他们严格验证系统完整性并主动识别任何潜在静默数据损坏。此类工具包作为标准硬件包的一部分嵌入，促进透明度并启用运营生命周期中的连续验证，从而增强整体系统可信度。

虽然加速器设计往往占据中心舞台，但CPU仍对协调计算、管理I/O和维持系统吞吐量至关重要。 然而，当前架构面临几个关键瓶颈：首先，如第4.5节所述，CPU和GPU之间的PCIe接口往往成为带宽瓶颈，特别是在大规模参数、梯度或KV缓存传输期间。为了缓解，未来系统应采用直接CPU–GPU互连——如NVLink或Infinity Fabric——或将CPU和GPU集成到向上扩展域，从而消除节点内瓶颈。除了PCIe限制，维持此类高数据传输速率还需要异常高的内存带宽。例如，饱和160条PCIe 5.0通道需要每个节点超过640 GB/s，转化为约1 TB/s每个节点的内存带宽需求——这对常规DRAM架构构成显著挑战。最后，延迟敏感任务如内核启动和网络处理需求高单核CPU性能，通常需要超过4 GHz的基本频率。而且，现代AI工作负载需要每个GPU足够的CPU核以防止控制侧瓶颈。对于基于chiplet的架构，需要额外核以支持缓存感知工作负载分区和隔离。

为了满足延迟敏感工作负载的需求，未来互连必须优先考虑低延迟和智能网络： 共封装光学：整合硅光子学启用可扩展更高带宽可扩展性和增强能效，两者对大规模分布式系统至关重要。无损网络：基于信用的流控制（CBFC）机制确保无损数据传输，但天真触发流控制可诱发严重头对尾阻塞。因此，部署高级、端点驱动拥塞控制（CC）算法至关重要，这些算法主动调节注入速率并避免病态拥塞场景。自适应路由：如第5.2.2节强调，未来网络应标准化采用动态路由方案——如数据包喷洒和拥塞感知路径选择——这些方案持续监控实时网络条件并智能重新分布流量。这些自适应策略在缓解热点和减轻集体通信工作负载中的瓶颈特别有效，包括all-to-all和reduce-scatter操作。高效容错协议：通过部署自愈协议、冗余端口和快速故障转移技术，可显著增强对故障的鲁棒性。例如，链路层重试机制和选择性重传协议在大网络中扩展可靠性不可或缺，最小化停机时间并确保尽管间歇故障的无缝操作。动态资源管理：为了有效处理混合工作负载，未来硬件应启用动态带宽分配和流量优先级。例如，在统一集群中，推理任务应与训练流量隔离，确保延迟敏感应用的响应性。

使用加载/存储内存语义的节点间通信高效且程序员友好，但当前实现受内存顺序挑战阻碍。 例如，在写入数据后，发送方必须发出显式内存屏障（fence）然后更新标志以通知接收方，确保数据一致性。这种严格顺序引入额外往返时间（RTT）延迟并可阻塞发出线程，阻碍飞行存储并减少吞吐量。类似乱序同步问题出现在消息语义RDMA中；例如，在InfiniBand或NVIDIA BlueField-3上执行RDMA原子加操作后进行常规RDMA写入的数据包喷洒可产生额外RTT延迟。为了解决这些，我们主张硬件支持为内存语义通信提供内置顺序保证。此类一致性应在编程级别（例如通过获取/释放语义）和硬件在接收方强制执行，实现无额外开销的有序交付。几种方法可能。例如，接收方可缓冲原子消息并使用数据包序列号进行有序处理。然而，获取/释放机制既优雅又高效。我们建议一个简单概念机制，区域获取/释放（RAR）机制，其中接收器硬件维护位图以跟踪RNR内存区域的状态，且获取/释放操作范围于RAR地址范围。以最小位图开销，这启用高效、硬件强制顺序，消除显式发送方fence并将顺序委托给硬件——理想上在NIC或I/O die上。重要的是，RAR机制不仅受益于内存语义操作，还受益于消息语义RDMA原语，从而拓宽其实际适用性。

EP涉及两个关键all-to-all阶段——分发和组合——这些阶段为网络内优化提供显著机会。 分发阶段类似于小规模多播操作，其中单个消息必须转发到多个目标设备。硬件级协议启用自动数据包复制和转发到多个目的地可急剧减少通信开销并改善效率。组合阶段，作为小规模规约操作，可受益于网络内聚合技术。然而，由于EP组合中的小规约范围和不平衡工作负载，以灵活方式实现网络内聚合具有挑战性。而且，如第3.2节突出，LogFMT启用低精度令牌传输，对模型性能影响最小。在网络硬件中本地整合LogFMT可通过增加熵密度和减少带宽使用进一步优化通信。硬件加速压缩和解压缩将允许LogFMT无缝集成到分布式系统中，提升整体吞吐量。

6.6.1 内存带宽限制。 模型大小的指数增长已超过高带宽内存（HBM）技术的进步。这种差异创建内存瓶颈，特别是在注意力密集架构如Transformer中。

6.6.2 建议： DRAM堆叠加速器：利用先进3D堆叠技术，DRAM die可垂直集成在逻辑die之上，从而启用异常高内存带宽、超低延迟和实际内存容量（虽受堆叠限制）。这一架构范式对MoE模型中的超快推理特别有利，其中内存吞吐量是关键瓶颈。架构如SeDRAM【72，A 135 GBps/Gbit 0.66 pJ/bit Stacked Embedded DRAM with Multilayer Arrays by Fine Pitch Hybrid Bonding and Mini-TSV+2023+IEEE Symposium on VLSI Technology and Circuits+https://doi.org/10.23919/VLSITechnologyandCir57934.2023.10185427】示范了这种方法的潜力，为内存绑定工作负载提供前所未有的性能。晶圆级系统（SoW）：晶圆级集成【50，Cerebras Architecture Deep Dive: First Look Inside the HW/SW Co-Design for Deep Learning : Cerebras Systems+2022+IEEE Hot Chips+https://doi.org/10.1109/HCS55958.2022.9895479】可最大化计算密度和内存带宽，满足超大规模模型的需求。

实验环境

数据集：未明确指定具体数据集名称和规模，但模型训练基于大规模数据，参考Scaling Laws【45，Scaling Laws for Neural Language Models+2020+CoRR+https://arxiv.org/abs/2001.08361】，强调增加模型大小、训练数据和计算资源导致性能改进。用途为训练大型语言模型以实现高级智能。

模型架构关键参数：DeepSeek-V3采用DeepSeekMoE架构，671B总参数，每个令牌激活37B参数；61层；隐藏大小约7K；使用MLA压缩KV缓存，每个令牌KV缓存70 KB（BF16）；整合MTP模块为单层轻量设计；FP8混合精度训练，细粒度量化（激活1x128 tile-wise，权重128x128 block-wise）。

硬件配置：2048个NVIDIA H800 SXM GPU（基于Hopper架构，NVLink带宽400 GB/s，FP64性能降低）；每个节点8个GPU和8个400G IB CX7 NIC；多平面两层胖树网络，支持多达16,384 GPU；每个节点1个400 Gbps Ethernet RoCE NIC连接存储网络；集群规模略超2000 GPU。

软件配置：基于DeepSeek自定义框架，包括DeepEP【78】为专家并行通信库；DeepGEMM【77】为FP8 GEMM实现；DualPipe【29】为管道并行；3FS【30】为分布式文件系统；使用NCCL支持PXN；开源组件如KTransformers【39】用于推理；语言为Python/CUDA；依赖NVIDIA Transformer Engine和自定义量化。

实验结果

KV缓存大小比较实验（表1，出自Section 2.1.2）：实验内容为比较DeepSeek-V3（MLA）、Qwen-2.5 72B和LLaMA-3.1 405B的每个令牌KV缓存内存使用（BF16精度）。结果显示DeepSeek-V3为70 KB，Qwen-2.5 72B为327 KB，LLaMA-3.1 405B为516 KB。分析结论：MLA显著减少KV缓存大小，使DeepSeek-V3适合长上下文和资源受限环境。

训练计算成本比较实验（表2，出自Section 2.2.1）：实验内容为比较MoE模型（DeepSeek-V3、DeepSeek-V2）和稠密模型（72B、405B）的每个令牌计算成本（假设序列长度4096）。结果显示DeepSeek-V3为250 GFLOPS，DeepSeek-V2为220 GFLOPS，72B稠密为394 GFLOPS，405B稠密为2448 GFLOPS。分析结论：MoE模型以少一个数量级资源实现相当或优越性能。

网络拓扑成本比较实验（表3，出自Section 5.1.1）：实验内容为比较FT2（多平面两层胖树）、FT3、SF和DF拓扑的端点数、端口利用、延迟和成本（基于Slim Fly论文方法）。结果显示FT2支持10k+端点，成本最低。分析结论：多平面FT2显著降低成本并提升可扩展性。

训练指标比较实验（表4，出自Section 5.1.2）：实验内容为在2048 GPU上比较MPFT和MRFT的DeepSeek-V3训练性能，包括MFU、时间（1F/1B/1W）。结果显示MPFT MFU（因果）为71.2%，MRFT为71.5%；时间相似。分析结论：MPFT性能几乎与MRFT相同，差异在正常波动内。

通信延迟比较实验（表5，出自Section 5.2.1）：实验内容为比较IB、RoCE和NVLink的CPU端到端延迟（64B数据）。结果显示IB最低（~1μs），RoCE更高，NVLink最低。分析结论：IB适合延迟敏感任务，但成本和可扩展性受限。

All-to-All性能实验（图5，出自Section 5.1.2）：实验内容为32-128 GPU的NCCL all-to-all性能比较（MPFT vs MRFT）。结果显示性能相似。分析结论：PXN机制使MPFT与MRFT相当。

All-to-All延迟实验（图6，出自Section 5.1.2）：实验内容为不同消息大小下16 GPU的延迟比较。结果显示差异可忽略。分析结论：多平面网络在实际场景中可靠。

DeepEP性能实验（图7，出自Section 5.1.2）：实验内容为16-128 GPU的EP分发/组合吞吐（4096令牌）。结果显示每个GPU >40GB/s。分析结论：接近饱和400Gps NIC带宽，满足训练需求。

RoCE带宽实验（图8，出自Section 5.2.2）：实验内容为不同路由（ECMP、AR、静态）和TP维度的AllGather/ReduceScatter带宽。结果显示AR最佳。分析结论：自适应路由缓解拥塞，提升性能。

FP8训练消融实验（出自Section 2.4）：实验内容为在16B/230B DeepSeek-V2上的FP8 vs BF16准确性。结果显示相对损失<0.25%。分析结论：高精度累积和细粒度量化确保稳定性。

MTP接受率实验（出自Section 2.3.3）：实验内容为MTP模块的第二个令牌接受率。结果为80-90%，TPS提高1.8x。分析结论：显著改善生成延迟。

LogFMT验证实验（出自Section 3.2）：实验内容为7B稠密模型上的LogFMT-nBit vs FP8/BF16准确性（n=8/10）。结果显示LogFMT-8优于E4M3/E5M2，LogFMT-10类似于BF16。分析结论：提供更高精度，但开销导致未采用。

引用汇总

方法细节中引用的参考文献包括：

• [5]：在2.1.2段落中描述为共享KV方法的代表，原文："Representative methods include GQA [5] and MQA [70]."

• [11]：在2.1.2段落中描述为窗口KV方法的代表，原文："Representative methods include Longformer [11] and related architectures."

• [14]：在2.3.3段落中描述为自我起草推测解码方法，原文："similar to previous self-drafting-based speculative decoding approaches [14, 48]."

• [16]：在4.4.2段落中描述为新兴互连协议，原文："emerging interconnect protocols such as the Ultra Ethernet Consortium (UEC) [17, 18], Ultra Accelerator Link (UALink) [16]"

• [17]：同上。

• [18]：同上。

• [19]：在5.1.2段落中描述为FlashAttention，原文："in line with FlashAttention[19, 20]"

• [20]：同上。

• [21]：在2.1.3段落中描述为线性时间替代方案，原文："Recent research efforts, such as Mamba-2 [21] and Lightning Attention[63]"

• [22]：在5.2.2段落中描述为Slingshot架构，原文："The Slingshot architecture [22] exemplifies"

• [25]：多次，在2段落中描述为DeepSeek-V2和MLA，原文："DeepSeek-V2 [25]"

• [26]：多次，在多处描述为技术报告，原文："technical report [26]"

• [27]：在2段落中描述为DeepSeekMoE，原文："DeepSeekMoE [27]"

• [28]：在2.3.4段落中描述为DeepSeek-R1，原文："DeepSeek-R1 [28]"

• [29]：在4.2段落中描述为DualPipe，原文："DualPipe [29]"

• [30]：在5.1段落中描述为3FS，原文："3FS [30]"

• [31]：在2.3.1段落中描述为剖析数据，原文："open-source profiling data [31]"

• [32]：在3.1段落中描述为GPTQ，原文："Quantization techniques such as GPTQ [32] and AWQ [51]"

• [34]：在5.2.2段落中描述为自适应路由，原文："Adaptive Routing (AR) [34]"

• [35]：在2.1段落中描述为内存增长率，原文："typically less than 50% per year [35]"

• [36]：在2.3.3段落中描述为MTP启发，原文："Inspired by Gloeckle et al. [36]"

• [38]：在2.3.4段落中描述为Gemini 2.5 Pro，原文："Gemini 2.5 Pro [38]"

• [39]：在2.2.2段落中描述为KTransformers，原文："KTransformers [39]"

• [40]：在2.1.2段落中描述为量化压缩，原文："Quantized Compression: KV pairs are stored using low-bit representations [40, 44, 52]"

• [44]：同上。

• [45]：在1.1段落，但方法中未直接；为背景。

• [47]：在5.1.2段落中描述为Megatron，原文："in line with Megatron [47]"

• [48]：在2.3.3段落中描述为推测解码，原文："[14, 48]"

• [49]：在4.4.2段落中描述为Unified Bus，原文："Unified Bus (UB) [49]"

• [50]：在6.6.2段落中描述为SoW，原文："Wafer-scale integration [50]"

• [51]：在3.1段落中描述为AWQ，原文："[32] and AWQ [51]"

• [52]：在2.1.2段落中描述为KIVI，原文："[40, 44, 52]"

• [53]：在2.2.2段落中描述为个性化代理，原文："personalized LLM agents [53]"

• [54]：在5.1.1和5.1.2段落中描述为PXN，原文："NCCL’s support for PXN [54]"

• [57]：在5.2.3段落中描述为IBGDA，原文："IBGDA [2, 57]"

• [60]：在2.3.4段落中描述为o1，原文："OpenAI’s o1/o3 series [60, 61]"

• [61]：同上。

• [63]：在2.1.3段落中描述为Lightning Attention，原文："[21] and Lightning Attention[63]"

• [64]：在2.3.4段落中描述为DPO，原文："DPO [64]"

• [66]：在3.1.2段落中描述为微缩放，原文："NVIDIA Blackwell’s support for microscaling data format [66]"

• [67]：在2.3.4段落中描述为PPO，原文："PPO [67]"

• [68]：在2.3.4段落中描述为Seed1.5-Thinking，原文："Seed1.5-Thinking [68]"

• [69]：在2.3.4段落中描述为GRPO，原文："GRPO [69]"

• [70]：在2.1.2段落中描述为MQA，原文："[5] and MQA [70]"

• [71]：在2.3.4段落中描述为Qwen3，原文："Qwen3 [71]"

• [72]：在6.6.2段落中描述为SeDRAM，原文："Architectures such as SeDRAM[72]"

• [75]：在2.1.2段落中描述为Qwen-2.5，原文："Qwen-2.5 72B [75]"

• [76]：在2.1.3段落中描述为稀疏注意力，原文："sparse attention [76]"

• [77]：在3.1段落中描述为DeepGEMM，原文："DeepGEMM [77]"

• [78]：在2.3.1、4.2、5.2.3段落中描述为DeepEP，原文："DeepEP [78]"

• [80]：在2.3.1段落中描述为预填充解码分离，原文："prefill and decode disaggregation architecture [80]"

这些引用严格从论文中提取，并在相应段落中按原文描述使用。