量子位 昨天
华为CloudMatrix重磅论文披露AI数据中心新范式,推理效率超NV H100
index.html
../../../zaker_core/zaker_tpl_static/wap/tpl_keji1.html

 

今年,AI 大厂采购 GPU 的投入又双叒疯狂加码——

马斯克 xAI 打算把自家的 10 万卡超算扩增 10 倍,Meta 也计划投资 100 亿建设一个 130 万卡规模的数据中心……

GPU 的数量,已经成为了互联网企业 AI 实力的直接代表。

的确,建设 AI 算力,这种堆卡模式是最简单粗暴的,但实际上,AI 集群却并非是卡越多就越好用。

GPU 虽然计算性能好,但是在集群化的模式下依然有很多挑战,即便强如英伟达,也面临通信瓶颈、内存碎片化、资源利用率波动等问题。

简单说就是,由于通信等原因的限制,GPU 的功力没办法完全发挥出来。

所以,建设 AI 时代的云数据中心,不是把卡堆到机柜里就能一劳永逸,现有数据中心的不足,需要用架构的创新才能解决。

最近,华为发布了一篇 60 页的重磅论文,提出了他们的下一代 AI 数据中心架构设计构想—— Huawei CloudMatrix,以及该构想的第一代产品化的实现 CloudMatrix384。相对于简单的 " 堆卡 ",华为 CloudMatrix 给出的架构设计原则是,高带宽全对等互连和细粒度资源解耦。

这篇论文干货满满,不仅展示了 CloudMatrix384 的详细硬件设计,并介绍了基于 CloudMatrix384 进行 DeepSeek 推理的最佳实践方案—— CloudMatrix-Infer。

那么,华为提出的 CloudMatrix384 到底有多强?简单地说,可以概括成三个方面——

够高效:预填充吞吐量达 6688 token/s/NPU,解码阶段 1943 token/s/NPU;计算效率方面,预填充达 4.45 token/s/TFLOPS,解码阶段 1.29 token/s/TFLOPS, 均超过业绩在 NVIDIA H100/H800 上实现的性能;

够准确:DeepSeek-R1 模型在昇腾 NPU 上 INT8 量化的基准测试精度与官方 API 一致;

够灵活:支持动态调整推理时延 SLO,在 15ms 严格延迟约束下仍维持 538 token/s 解码吞吐量。

AI 数据中心架构,华为云提前迈出了一步

在深入剖析这篇重磅论文之前,我们有必要先来了解一下"Why we need CloudMatrix384"。

若是一句话来概括,就是满足不了当下 AI 发展的算力需求。

因为传统的 AI 集群,它内部运行的过程更像是 " 分散的小作坊 ",每个服务器(节点)有种各玩各的感觉;算力、内存和网络资源等等,都是被固定分配的。

在这种传统模式下,AI 集群一旦遇到超大规模的模型,就会出现各种问题,例如算力不够、内存带宽卡脖子、节点间通信慢如蜗牛等等。

而华为在这篇论文中要做的事情,就是提出一种新的模式,把这种 " 小作坊 " 改成 " 超级算力工厂 "——

以 CloudMatrix(首个生产级实现 CloudMatrix384)为代表的华为云下一代 AI 数据中心架构。

它最鲜明的一大特点就是,所有的资源是可以统一调度的:CloudMatrix384 把 384 个 NPU、192 个 CPU 以及其它硬件都集成到了一个超级节点当中。

因此在这里,像刚才提到的算力、内存、网络资源等等,会像工厂里的流水线一样被统一管理起来,哪里需要就调哪里。

并且数据在 CloudMatrix384 里,就像是搭乘了工厂里的高速传送带,因为所有芯片的连接都是由超高带宽、低延迟的统一总线(UB)网络完成,数据在芯片之间是" 全对等 "直接传输,这就避免了传统网络 " 堵车 " 的问题。

也正因如此,无论 CloudMatrix384 是遇到多大参数规模的大模型,亦或是需要频繁访问缓存的推理任务,都能通过动态分配资源,高效完成计算。

华为 CloudMatrix 架构愿景

在了解完下一代 AI 数据中心的设计愿景之后,我们继续深扒一下细节创新技术和独特优势。

全对等互联:华为提前迈出的重要的一步

全对等互联(Peer-to-Peer),可以说是 CloudMatrix384 在硬件架构设计上的一大创新之处。

因为传统的 AI 集群中,CPU 相当于扮演一个 " 领导 " 的角色,NPU 等其它硬件更像是 " 下属 ",数据传输的过程中就需要 CPU" 审批签字 ",效率自然就会大打折扣。

尤其是在处理大规模模型的时候,通信开销甚至可以占整体任务时长的 40%!

但在 CloudMatrix384 中,情况就截然不同了。

CPU 和 NPU 等硬件更像是一个 " 扁平化管理的团队 ",它们之间的地位比较平等,直接通过 UB 网络通信,省去了 " 领导传话 " 的时间。

CloudMatrix384 全对等互联硬件架构设计

而实现如此 " 扁平化管理团队 " 的关键,就是我们刚才提到的UB 网络,是一种无阻塞全连接拓扑。

它采用 Clos 架构设计,16 个机架中的 L1/L2 交换机形成多层级无阻塞网络,可以确保任意两个 NPU/CPU 间通信带宽恒定。

而在传统集群中,节点间是通过 RoCE 网络来通信,带宽通常仅为 200Gbps(约 25GB/s),并且还存在 " 南北向带宽瓶颈 "(如数据中心核心交换机负载过高)。

但在 UB 网络的加持下,每个 NPU 可以提供392GB/s的单向带宽,相当于每秒能传 48 部 1080P 电影,数据传输又快又稳。

除此之外,传统 NPU 之间通信还依赖 SDMA 引擎(类似 " 快递中转站 "),它的缺点就是启动延迟比较高(约 10 微秒)。

为此,全对等互联引入了 AIV 直连(AIV-Direct)的机制,它可以直接通过 UB 网络写入远程 NPU 内存,跳过 SDMA 的中转,传输启动延迟从 10 微秒降至 1 微秒以内。

这个机制就非常适合 MoE 中 token 分发等高频通信的场景,把单次通信耗时缩短 70% 以上。

但除了硬件上的设计之外,软件层面的加持对于 CloudMatrix384 的高效率也是起到了功不可没的作用。

例如 UB 网络通过结合内存池化技术,实现了 CloudMatrix384 的 " 全局内存视图 ",即所有 NPU/CPU 可直接访问跨节点内存,无需关心数据物理位置。

解码阶段的 NPU 可直接读取预填充阶段 NPU 生成的 KV 缓存,不用再通过 CPU 中转或磁盘存储,数据访问延迟从毫秒级降至微秒级,缓存命中率提升至 56% 以上。

再以 671B 的 DeepSeek-R1 为例,通过 FusedDispatch 融合算子与 AIV 直连,token 分发延迟从 800 微秒降至 300 微秒。预填充计算效率提升 4.45 token/ 秒 /TFLOPS,超越了英伟达 H100 的 3.75 token/ 秒 /TFLOPS。

并且在 TPOT<50ms 的约束下,解码吞吐量达到了 1943 token/ 秒 / 每 NPU,即使收紧至 TPOT<15ms,仍能维持 538 token/ 秒,这就验证了全对等互联在严苛延迟场景下的稳定性。

因为云原生:不用关心硬件细节,华为云上开箱即用

除了 " 全对等互联 " 之外,这篇重磅论文的第二个技术关键词,非" 云 "莫属了。

简单来说,这是一套面向云的基础设施软件栈,它就像一个 " 智能管家团队 ",可以把复杂的硬件设备变成人人能用的 " 云端算力超市 "。

值得一提的是,早在 CloudMatrix384 问世之前,华为云团队早早地就敲定下一代 AI 数据中心要以 " 面向云 " 为基础,这就体现了华为在技术战略布局上的前瞻性。

并且团队通过两年多时间的打磨,已经让部署 CloudMatrix384 这事变成 " 零门槛 ",用户无需关心硬件细节直接可以部署。

部署 CloudMatrix384 的华为云基础设施软件栈

整体来看,这套面向云的基础设施软件栈主要包含以下几大模块:MatrixResource、MatrixLink、MatrixCompute、MatrixContainer,以及顶层的 ModelArts 平台,它们之间可以说是分工明确且相互协作。

首先我们来看下MatrixResource

它在软件栈中起到的是 " 资源分配管家 " 的作用,主要负责超级节点内物理资源的供应,包括基于拓扑感知的计算实例分配。

通过运行在每个计算节点擎天卡上的 MatrixResource 代理,动态管理 NPU、CPU 等硬件资源的分配,确保资源按拓扑结构高效调度,避免跨节点通信瓶颈。

MatrixLink则是一位 " 网络通信管家 "。

它为 UB 和 RDMA 网络提供服务化功能,支持 QoS 保障、动态路由及网络感知的工作负载放置。可以优化超节点内 384 个 NPU 及跨节点间的通信效率,例如在推理场景中通过并行传输和多路径负载均衡技术,辅助提升推理效率 20%。

MatrixCompute的角色像是 " 逻辑超节点管家 "。

它的任务是管理超节点的 " 生老病死 ",从开机启动到故障修复全负责,包括裸金属供应、自动扩缩容、故障恢复等。

具体实现的方式是跨物理节点编排资源,将分散的硬件组件构建为紧密耦合的逻辑超级节点实例,实现资源的弹性扩展和高可用性。

MatrixContainer是 " 容器部署管家 "。

它的作用是让用户的 AI 应用能像 " 快递包裹 " 一样轻松部署到超节点上:基于 Kubernetes 容器技术,把复杂的 AI 程序打包成标准化容器,用户只需 " 点击部署 ",它就会自动安排到合适的硬件上运行。

最后,就是ModelArts这位 "AI 全流程管家 " 了。

它位于整个软件栈的顶层,提供从模型开发、训练到部署的全流程服务,包括 ModelArts Lite(裸金属 / 容器化硬件访问)、ModelArts Standard(完整 MLOps 流水线)、ModelArts Studio(模型即服务,MaaS)。

新手可以用 ModelArts Lite 直接调用硬件算力;进阶用户可以用 ModelArts Standard 管理训练、优化、部署全流程;企业用户则可以用 ModelArts Studio 把模型变成 API 服务(如聊天机器人),一键发布。

由此可见,在 CloudMatrix384 本身高效的基础上,面向云的基础设施软件栈起到了 " 如虎添翼 " 的作用,使得部署这件事变得更加便捷。

软硬一体:高效、便捷的同时,也够灵活

除了 " 全对等互联 " 和 " 云原生 " 这两个关键词,论文中也还涉及到了二者 " 软硬一体 " 结合下,在灵活性上体现出来的优势。

例如刚才我们提到的 " 用户无需关注底层硬件细节,只需调用 API" 这方面,具体而言,是华为云 EMS(弹性内存服务)通过内存池化技术,将 CPU 连接的 DRAM 聚合为共享内存池,NPU 可直接访问远程内存,实现 KV 缓存复用,使首 Token 时延降低 80%,同时减少 NPU 购买量约 50%。

以及 MatrixCompute 支持超节点实例的自动扩缩容,例如根据工作负载动态调整预填充 / 解码集群的 NPU 数量,在严苛的 15ms TPOT 约束下仍能维持 538 token/ 秒的解码吞吐量。

通过确定性运维服务和昇腾云脑技术,还可以实现万卡集群故障 10 分钟内恢复,HBM 和网络链路故障场景下恢复时间挑战 30 秒,例如光模块故障影响降低 96%,保障训练 / 推理任务的连续性。

软件栈还支持超节点资源的多租户切分,不同用户可共享硬件资源但逻辑隔离,例如通过命名空间隔离不同模型的缓存数据,确保数据安全与资源公平分配。

通过智能化调度实现 " 朝推夜训 ",白天运行推理任务,夜间利用闲置算力进行模型训练,节点在训练 / 推理间切换 <5 分钟,提升算力利用率。

据了解,CloudMatrix384 已经在华为云乌兰察布、和林格尔、贵安、芜湖四大节点上线,用户可按需开通算力,无需自行搭建硬件环境,10 毫秒时延圈覆盖全国 19 个城市群,支持低延迟访问。

并且 CloudMatrix384 还提供全栈智能运维的能力,例如昇腾云脑的故障知识库已经覆盖了 95% 的常见场景,一键诊断的准确率达到了 80%、网络故障诊断<10 分钟,可以说是把运维的门槛也打了下去。

打破 " 不可能三角 "

看到这里,我们可以做个简单总结了。

华为的 CloudMatrix384 通过 " 全对等架构 + 软硬协同 " 的模式,打破了传统上算力、延迟和成本之间的 " 不可能三角 "。

硬件层面,它的全对等 UB 总线实现 392GB/s 卡间带宽,让 384 张 NPU 能够高效协同工作,在 EP320 专家并行模式下,token 分发延迟控制在 100 微秒以内。

软件层面的 CloudMatrix-Infer 采用全对等推理架构、大 EP 并行、昇腾定制融合算子、UB 驱动的分离式内存池等,最大化发挥硬件效率。

这种设计让高算力、低延迟、可控成本同时成为可能,总之有了 CloudMatrix384,云端的大模型部署方案变得更香了。

云端可以在数据中心级别进行统一规划,构建专门的高速网络拓扑,突破单一企业的物理限制。

更关键的是,云端支持弹性扩缩容,企业可以根据业务需求动态调整资源规模,从几十张卡扩展到数百张卡,而无需对物理设施进行改动。

而且,选择云也意味着不需要用户自己找专业团队去处理模型优化、分布式训练、故障处理等复杂问题。

CloudMatrix384 的运维自动化设计更是将故障影响降低 96%,万卡集群故障恢复时间控制在 5 分钟以内,这种专业化运维能力是大部分企业无法自建的。

更重要的,CloudMatrix384 代表的云端 AI 服务模式为中国企业提供了一个更现实的 AI 落地路径。

比如 DeepSeek-R1 从模型迁移到上线仅用 72 小时,相比传统方案的 2 周时间,效率提升显著。

这种成本和效率优势让更多企业能够尝试 AI 应用,而不需要承担巨额的基础设施投入风险。

CloudMatrix384 证明了国产云端方案不只是 " 能用 ",更是在性能和成本效益上都具备竞争优势。

AI 基础设施正在重新被定义

CloudMatrix384 代表的不只是一台更强的 AI 超算,还是对 " 什么是 AI 基础设施 " 的重新定义。

技术上,它通过 UB 颠覆了过往以 CPU 为中心的层级式设计,将整个超级节点变成了一个统一的计算实体。

面向未来,华为论文中也给出了两条发展路径——一方面继续扩大节点规模,另一方面进行更强力的解耦。

扩大规模容易理解,未来 LLM 参数规模更大,需要更紧密耦合的计算资源。

而解耦,可以分别从资源和应用两个维度来看。

资源上,CPU 和 NPU 资源物理将分离为专用资源池,从逻辑解耦将走向物理解耦,实现更好的资源利用率。

应用中,大模型的推理过程中内存密集型注意力计算将从解码路径解耦,注意力和专家组件也会分离为独立执行服务。

总之,作者描绘了一个完全解耦、自适应、异构的 AI 数据中心架构,这种架构将进一步提升可扩展性、灵活性、效率和性能。

未来,计算资源将不再是固定的物理设备,而是可以动态编排的抽象能力。

通过 CloudMatrix384 和其未来畅想,我们正在见证又一次新的技术迭代,也在见证整个 AI 数据中心范式的深刻变革。

一键三连「点赞」「转发」「小心心」

欢迎在评论区留下你的想法!

—    —

点亮星标

科技前沿进展每日见

评论
大家都在看