最近DeepSeek R1模型凭借其稀疏专家混合（MoE）架构和千亿级参数的潜力，被不少技术社区称为“国货之光”。我更想从硬件适配的角度聊聊：作为国产芯片的代表，为什么华为昇腾910超节点可能是当前最适合运行DeepSeek系列模型的国产平台？ 尤其是对比Nvidia的相关集群，昇腾在通信架构和集群规模上的设计，或许正在改写MoE模型的训练和推理规则。
一、MoE模型的“命门”：All2All通信与集群拓扑
DeepSeek R1的核心是MoE架构，其61层模型中有58层涉及多次All2All通信，通讯要占到时延的40%以上。这种通信模式的特点是什么？——高频次、小数据包、低时延敏感。举个例子：当输入序列进入某一层时，路由网络会将不同Token分配给不同的专家（Expert），每个专家可能分布在不同的计算卡上，此时需要将Token分发到对应专家的卡上（All2All），计算完成后再收集结果。一次前向传播可能触发200次以上集合通信，通信延迟每增加5μs，整体通信延迟将同步增加10%，直接拖累吞吐量。
传统解决方案依赖IB（InfiniBand）网络，但有两个致命问题：
通信延迟难以压到μs级：IB协议栈本身有软硬件开销，小包时延通常在10μs量级；
跨卡内存访问效率低：需要通过显存→主机内存→网络→目标主机内存→显存的路径，带宽受限。
而昇腾超节点有机会通过全互联架构下的高速跨卡LOAD/STORE直通解决这个核心问题，这是什么概念？
时延逼近硬件极限：直接内存访问绕过了协议栈，时延可压至纳秒级；
拓扑灵活性：支持超节点内数百卡全互联，无需分层交换。
这对DeepSeek R1的通信模式简直是“精准打击”——All2All的小包能在芯片级互联中“裸奔”，无需经过网络协议栈的层层盘剥。
二、算力分析：“普通批量服务”与“VIP服务保障”得到双重突破
昇腾910单卡算力是H20的数倍，在真实场景中，用户请求的序列长度（Token数）差异极大，短至几十Token的实时对话，长至数万Token的文档分析。当系统负载达到峰值时，普通用户请求可能因资源竞争而无限延迟，但是VIP服务却需保障高TPS（每秒事务处理量）。
昇腾集群的大算力特点允许用户通过动态资源调度与硬件级QoS（服务质量）实现这一目标，在提升普通任务处理效率同时能够释放更多算力给VIP任务：例如，某金融客户将70%算力分配给高频交易模型（VIP），剩余30%用于批量数据处理（普通用户），确保VIP任务的响应时间稳定在固定时间以内。
但如果类似任务在H20集群上运行则会面临挑战，假设某云服务商需同时处理以下两类请求：
VIP任务：企业级客户的大模型服务（序列长度10k Token，并发数100）
普通任务：C端用户的实时对话（序列长度200 Token，并发数10k）
H20集群会由于算力限制，系统需频繁进行切换，VIP任务的TPS可能会从峰值100降至40，响应延迟从200ms飙升至800ms。
三、实测数据：吞吐量与集群规模的“非线性增益”
因为国产HBM2e的助力，昇腾910的memory带宽将得到有效改善，在4K序列长度下，单卡吞吐率有望超过1500 tokens/s，采用更短的序列长度能够获得数倍的收益，例如：当序列为256 token，吞吐率可达约5000 tokens/s。这个数字是什么水平？
对比Nvidia H800集群：在类似规模的IB组网下，H800单卡吞吐通常不足500token/s（长序列），Nvidia集群规模远小于昇腾数百卡集群(实现全互联)，导致MoE模型的专家无法充分并行
关键在于，MoE模型的性能与集群规模存在非线性关系。假设专家数量为N，当N小于集群卡数时，部分卡会空闲；当N远大于卡数时，单卡需托管多个专家，增加通信开销。昇腾超节点集群超节点，配合全互联架构，使得专家可以“一专家一卡”甚至“一专家多卡冗余”，最大化硬件利用率。
举个具体场景：DeepSeek R1在解码（Decode）阶段需要数百张卡部署专家，共享专家和热点专家需冗余部署。如果集群规模不足，要么专家分布密集导致通信拥塞，要么需要引入复杂的负载均衡策略。而昇腾超节点的大规模组网能力，让专家分布更接近“理想拓扑”。
四、结语：MoE时代，国产Infra的“新锚点”
DeepSeek R1的成功证明了国产大模型在算法层面的突破，而昇腾910超节点未来表现，或许正在为国产AI芯片锚定一个新高地：在特定模型架构（如MoE）和场景（超大集群）下，利用硬件-软件协同设计，实现局部优势的关键突破。昇腾910集群有望证明：在All2All通信密集型的赛道上，国产芯片可以比Nvidia跑得更快。
最近DeepSeek R1模型凭借其稀疏专家混合（MoE）架构和千亿级参数的潜力，被不少技术社区称为“国货之光”。我更想从硬件适配的角度聊聊：作为国产芯片的代表，为什么华为昇腾910超节点可能是当前最适合运行DeepSeek系列模型的国产平台？ 尤其是对比Nvidia的相关集群，昇腾在通信架构和集群规模上的设计，或许正在改写MoE模型的训练和推理规则。
一、MoE模型的“命门”：All2All通信与集群拓扑
DeepSeek R1的核心是MoE架构，其61层模型中有58层涉及多次All2All通信，通讯要占到时延的40%以上。这种通信模式的特点是什么？——高频次、小数据包、低时延敏感。举个例子：当输入序列进入某一层时，路由网络会将不同Token分配给不同的专家（Expert），每个专家可能分布在不同的计算卡上，此时需要将Token分发到对应专家的卡上（All2All），计算完成后再收集结果。一次前向传播可能触发200次以上集合通信，通信延迟每增加5μs，整体通信延迟将同步增加10%，直接拖累吞吐量。
传统解决方案依赖IB（InfiniBand）网络，但有两个致命问题：
通信延迟难以压到μs级：IB协议栈本身有软硬件开销，小包时延通常在10μs量级；
跨卡内存访问效率低：需要通过显存→主机内存→网络→目标主机内存→显存的路径，带宽受限。
而昇腾超节点有机会通过全互联架构下的高速跨卡LOAD/STORE直通解决这个核心问题，这是什么概念？
时延逼近硬件极限：直接内存访问绕过了协议栈，时延可压至纳秒级；
拓扑灵活性：支持超节点内数百卡全互联，无需分层交换。
这对DeepSeek R1的通信模式简直是“精准打击”——All2All的小包能在芯片级互联中“裸奔”，无需经过网络协议栈的层层盘剥。
二、算力分析：“普通批量服务”与“VIP服务保障”得到双重突破
昇腾910单卡算力是H20的数倍，在真实场景中，用户请求的序列长度（Token数）差异极大，短至几十Token的实时对话，长至数万Token的文档分析。当系统负载达到峰值时，普通用户请求可能因资源竞争而无限延迟，但是VIP服务却需保障高TPS（每秒事务处理量）。
昇腾集群的大算力特点允许用户通过动态资源调度与硬件级QoS（服务质量）实现这一目标，在提升普通任务处理效率同时能够释放更多算力给VIP任务：例如，某金融客户将70%算力分配给高频交易模型（VIP），剩余30%用于批量数据处理（普通用户），确保VIP任务的响应时间稳定在固定时间以内。
但如果类似任务在H20集群上运行则会面临挑战，假设某云服务商需同时处理以下两类请求：
VIP任务：企业级客户的大模型服务（序列长度10k Token，并发数100）
普通任务：C端用户的实时对话（序列长度200 Token，并发数10k）
H20集群会由于算力限制，系统需频繁进行切换，VIP任务的TPS可能会从峰值100降至40，响应延迟从200ms飙升至800ms。
三、实测数据：吞吐量与集群规模的“非线性增益”
因为国产HBM2e的助力，昇腾910的memory带宽将得到有效改善，在4K序列长度下，单卡吞吐率有望超过1500 tokens/s，采用更短的序列长度能够获得数倍的收益，例如：当序列为256 token，吞吐率可达约5000 tokens/s。这个数字是什么水平？
对比Nvidia H800集群：在类似规模的IB组网下，H800单卡吞吐通常不足500token/s（长序列），Nvidia集群规模远小于昇腾数百卡集群(实现全互联)，导致MoE模型的专家无法充分并行
关键在于，MoE模型的性能与集群规模存在非线性关系。假设专家数量为N，当N小于集群卡数时，部分卡会空闲；当N远大于卡数时，单卡需托管多个专家，增加通信开销。昇腾超节点集群超节点，配合全互联架构，使得专家可以“一专家一卡”甚至“一专家多卡冗余”，最大化硬件利用率。
举个具体场景：DeepSeek R1在解码（Decode）阶段需要数百张卡部署专家，共享专家和热点专家需冗余部署。如果集群规模不足，要么专家分布密集导致通信拥塞，要么需要引入复杂的负载均衡策略。而昇腾超节点的大规模组网能力，让专家分布更接近“理想拓扑”。
四、结语：MoE时代，国产Infra的“新锚点”
DeepSeek R1的成功证明了国产大模型在算法层面的突破，而昇腾910超节点未来表现，或许正在为国产AI芯片锚定一个新高地：在特定模型架构（如MoE）和场景（超大集群）下，利用硬件-软件协同设计，实现局部优势的关键突破。昇腾910集群有望证明：在All2All通信密集型的赛道上，国产芯片可以比Nvidia跑得更快。
