index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html
![]()
华为联合硅基流动发布论文，详细介绍了昇腾超节点CloudMatrix 384的硬件架构和针对大模型推理的优化方案，被称为“菊花宝典”。该方案结合了CloudMatrix 384超节点的硬件优势和CloudMatrix-Infer推理优化方案，旨在提升大模型推理性能。通过UB总线、CANN软件栈以及多层级软件优化技术，华为在DeepSeek推理实战中取得了显著成果，展现了昇腾在超节点互联和架构级优化方面的实力，为大模型推理提供了新的思路。
🚀 CloudMatrix 384硬件架构：采用384颗昇腾910C NPU和192颗鲲鹏CPU，通过UB总线实现全互联，提供近芯片级带宽、微秒级延迟和统一寻址的算力池。该架构包含UB、RDMA和VPC三个平面，支持超节点Scale-up和Scale-out。
💡 昇腾910C芯片：每颗芯片包含双die，每die算力达到376TFLOPS@FP16或1054TFLOPS@INT8，板载128GB HBM3显存，带宽3.2TB/s。每die提供7 × 224 Gbps UB 通道 + 200 Gbps RDMA 通道，实现高效的数据传输。
⚙️ 软件优化方案：华为提供CANN软件栈，包括驱动、运行时和库，以及Matrix全家桶，用于大规模云环境部署。针对DeepSeek等大模型，提出CloudMartrix-Infer推理优化方案，包括PDC解耦、LEP大规模专家并行和硬件友好的优化包，提升推理性能。
📊 推理实战效果：在DeepSeek推理实战中，CloudMatrix 384在Prefill预填充和Decode解码阶段均展现出优异的性能，单卡吞吐量和算力利用率均达到领先水平，与N记H100/H800对比，展现了昇腾超节点的竞争力。
原创 小黑羊 2025-06-18 09:56 北京
《菊花宝典》来了
刚刚，华为联合硅基流动悄悄发了一篇论文，把自家的昇腾超节点CloudMatrix 384狠狠“安利”了一把。
这篇论文有两大看点：1、详细介绍了CloudMatrix384超节点的硬件架构：910C芯片、节点板卡、尤其是UB架构。2、针对像DeepSeek这样数千亿参数、MoE架构、超长上下文的推理需求，如何用软硬协同的“菊花宝典”来搞定。这份「菊花宝典」，包含CloudMatrix 384超节点硬件和CloudMatrix-Infer推理优化方案。 华为 CloudMatrix 384 将 384 颗 昇腾 910C NPU、192 颗鲲鹏 CPU 封装进单一“超节点”，通过 UB（Unified Bus）高带宽、低时延总线实现全互联，使计算、内存、网络资源可池化、等价访问并独立伸缩。具体的架构长这样↓包含三个平面：①UB平面完成超节点Scale-up；②RDMA平面，提供多个超节点Scale-out；③VPC平面，南北向通信，连接到数据中心网络。1、昇腾910C芯片参数910C为双die封装，每die算力达到376TFLOPS@FP16或1054TFLOPS@INT8。（比较遗憾的是，910系列不支持FP8，也不支持现在N卡和A卡都在狂带节奏的FP4/FP6，期待下一代可以）板载128GB HBM3显存，带宽3.2TB/s。每die提供7 × 224 Gbps UB 通道 + 200 Gbps RDMA 通道，既能 scale-up 又能 scale-out。2、昇腾910C子节点整个超节点由48个910C子节点组成。每个子节点板载8张昇腾910C芯片+4张鲲鹏CPU+7张UB交换芯片，并集成一张擎天DPU卡，负责节点级资源管理和南北向网络连接。
3、UB统一总线架构首次揭秘超级节点横跨了16个机架，其中12个计算机架（含48个昇腾910C节点）、4个通信机架，通信机架其实就是所谓的UB统一总线。这很像典型的Spine-Leaf两层脊叶架构，一层Leaf集成在每个910C节点机上，二层Spine搁在4个通信机架里面。每个L1端口对应16条上行链路（16×28GB/s），确保整个超级节点网络无阻塞。UB 架构的本质，是把传统“CPU-GPU-交换机多层异构系统”压缩进一个机柜内部的单级互连域，交付“近芯片级带宽 + 微秒级延迟 + 统一寻址”的算力池。大家可以看看菊厂给出的节点内和跨节点通信的带宽/时延对比：跨die带宽接近die内带宽，单跳时延接近1微秒。菊厂不愧是做通信出身的，这UB做得真NB，大模型推理的三个主要瓶颈（带宽、延迟、内存可用性），UB都提供了显著改进。正是因为UB的存在，CloudMartix才可以放弃传统Scale out的做法，用Scale up的理念攒一台大家伙，来搞定计算墙、显存墙、通信墙。当然，“一菊独放不是春，百菊齐放春满园”，就像下图一样，CloudMatrix的远景是先Scale-UP，再Scale-Out，组成一片超级“大菊园”。配套软件上，华为有自己的“菊版CUDA”，这就是CANN，包括驱动、运行时和库三层架构。同时，为了实现在更大规模的云环境中部署 CloudMatrix384，菊厂提供了一套“Matrix全家桶”，包括 MatrixResource、MatrixLink、MatrixCompute 和 MatrixContainer。下图给出了一个16.5万张卡组成的超大集群的示范，以及在这样的云平台上，全家桶各自的位置。为了更好的跑DeepSeek这样的大参数、MoE、长上下文模型，菊厂专门提出了CloudMartrix-Infer推理优化方案。本质上讲，这是一个多层级的软件优化技术，简要概括下。1、PDC 解耦（Prefill-Decode-Caching）：Prefill：16 × NPU 实例（EP32）专管长输入串、首 token 生成。Decode：160 × NPU 实例（EP320）追求极低 TPOT 的自回归生成。Caching：所有 NPU 通过 UB 总线直连一片分布式 DRAM 池，历史 KV + 模型权重都放这儿，谁需要谁 DMA 取。2、LEP 大规模专家并行让 DeepSeek-R1 的 320 个专家“一人一核”地摊到 320 个 NPU die 上，通信靠 UB，MoE 延迟不再是瓶颈。 3、硬件友好的优化包Ascend-native算子 + 微批管线并发，通信与计算重叠。INT8 五件套量化：混合精度、自适应尺度搜索、离群点抑制、高效INT8 GEMM、块级剪裁与误差补偿。（弥补昇腾芯片不支持FP8的短板，）所有这些优化手段，在论文中都有超长篇幅的图文介绍，详细到足以让你相信，这是菊厂真干成了。用这套软硬协同的“菊花宝典”，进行满血版DeepSeek推理实战，是一种怎样的体验？论文中给出了详细的数据，以及与N记H100/H800对比。（注意不是比H200更不是B200）1、Prefill预填充阶段：在同样16384×4096 的重载场景里，华为单卡吞吐达到6688tps，并拿到全场最佳算力利用率（4.45tok/s/TPFOPS）。2、Decode解码阶段：在TPOT=50ms的级别下，华为吞吐达到每卡1943tps。同样获得了最高的算力利用率（1.29tok/s/TFlops）。而且华为并没有使用更大的Batch Size堆吞吐，仍然拿到了高效输出。总体来讲，这波实战华为客观的展示了自身的能力，起到了双重袪魅效果：①昇腾的确很能打，在单卡通用硬件算力不如H100的前提下，凭超节点互联 + 架构级优化，实现整体性能反超。②昇腾没有坊间吃瓜群众吹得那么能打，一顿操作猛如虎，也只是能跟H100掰掰手腕。华为通过这波操作，验证了“超节点+软硬协同”在 LLM 时代的工程可行性与性能上限，为后续万亿参数、大稀疏推理平台提供了可实战的“菊花宝典”。总之，这篇论文来得非常及时，让我们可以既不盲目自信，也不妄自菲薄。最后，再次墙裂推荐大家阅读论文原文，获取方式，公众号后台回复：菊花宝典
阅读原文
跳转微信打开
