📑 目录
- 一、前言/AI场景背景
- 二、核心原理与协议深度
- 三、硬件架构深度剖析
- 四、AI通信的硬件加速实现
- 五、实战部署与深度配置
- 六、性能深度分析与基准测试
- 七、典型故障深度排查
- 八、总结与设计trade-off
- 参考资料
摘要：本文从芯片RTL与集群架构视角，深度解构AI训练中PFC风暴与RDMA死锁的根因。涵盖RoCEv2协议状态机、RNIC寄存器定义、拥塞控制硬件流水线及GPUDirect数据通路，提供从故障排查到NCCL调优的全栈实战指南。
一、前言/AI场景背景
随着大语言模型（LLM）参数规模突破万亿级别，以及混合专家模型（MoE）架构的普及，GPU集群的通信延迟与吞吐量已成为制约训练效率的核心瓶颈。在800G乃至1.6T的AI数据中心网络中，RDMA（Remote Direct Memory Access） 凭借零拷贝、内核旁路和CPU卸载特性，成为连接数千张GPU的绝对基石。然而，AI工作负载的流量特征与传统云原生业务截然不同：稠密梯度同步（AllReduce）呈现极端的多对一（Incast） 突发特征；MoE的All-to-All路由导致全网流量矩阵瞬间重构；而长文本推理的KV Cache迁移则对尾延迟（Tail Latency）提出了苛刻要求。
为了在共享以太网（RoCEv2）中维持这些高并发、高突发流量的无损传输，业界普遍依赖PFC（Priority-based Flow Control） 与DCQCN（Data Center Quantized Congestion Notification） 的组合。然而，在万卡级超大规模集群中，这种传统架构暴露出致命缺陷：PFC水线配置不当极易引发PFC风暴（PFC Storm） ，导致全网吞吐断崖式下跌；复杂的环形拓扑或路由不对称则会触发RDMA死锁（Deadlock），造成训练任务永久挂起。
本文面向具备3年以上RDMA/网络芯片经验的工程师，拒绝停留在概念科普，直接切入芯片微架构、RTL数据流、寄存器配置和故障根因。我们将深度剖析PFC死锁的硅片级形成机理，解构RNIC（RDMA Network Interface Card）内部的拥塞控制引擎（CC Engine）流水线，并结合NCCL/GPUDirect实战，提供从芯片设计验证到集群调优的全栈指南。
| 定位维度 | 传统网络运维视角 | 本文芯片与架构视角 |
|---|---|---|
| 关注层级 | 交换机端口、OS网络栈、NCCL参数 | RNIC RTL流水线、PCIe TLP、IB Spec协议字段 |
| 故障归因 | 拥塞、配置错误、线缆故障 | Buffer Cell耗尽、状态机死锁、DMA描述符泄漏 |
| 解决思路 | 调整PFC阈值、开启ECN、重启服务 | 修改CC算法状态机、优化Token Bucket、重构QP映射 |
二、核心原理与协议深度
1. RoCEv2协议栈与PFC死锁机理
RoCEv2（RDMA over Converged Ethernet v2）将InfiniBandverbs语义封装在UDP/IP之上。在数据链路层，PFC（IEEE 802.1Qbb） 是实现无损网络的最后底线。PFC将物理链路划分为8个优先级（Priority 0~7），每个优先级拥有独立的硬件Buffer队列。当某队列深度超过Watermark（水线）时，交换机MAC层生成XOFF（Pause） 帧，强制上游停止发送该优先级的报文。
PFC死锁（Deadlock）的硅片级根因 ：
在环形拓扑（如Fat-Tree的某些冗余路径）或存在多路径非对称路由时，死锁源于循环资源等待。假设节点A向B发送数据，B向C发送，C向A发送。若三者的PFC Buffer均被占满，且都在等待下游释放Credit，则形成死锁。在芯片内部，这表现为RX Buffer的SRAM Cell被永久锁定，TX Arbiter因收不到XON帧而停止调度，最终导致整个Fabric瘫痪。
2. DCQCN协议状态机与IB Spec解析
DCQCN是端到端的拥塞控制机制，依赖交换机CP（Congestion Point）的ECN标记和接收端NP（Notification Point）生成的CNP（Congestion Notification Packet）。发送端RP（Reaction Point）根据CNP调整速率。
DCQCN硬件状态机（基于IB Spec Vol 1, Section 11.6.2）：
text
+-----------------------+
| Slow Start | <--- (初始状态/超时恢复)
| (Rate = Rate * 2) |
+-----------+-----------+
| 收到CNP或达到阈值
v
+-----------------------+
| Fast Recovery | <--- (Rate = Rate * (1 - 0.5))
| (Rate = Rate * (1-α)) |
+-----------+-----------+
| 连续收到CNP
v
+-----------------------+
| Active/Recovery | <--- (Rate = Rate * (1 - α/2))
| (AIMD 乘性减速) |
+-----------------------+触发条件 ：状态转移由ecn_ce_valid信号和CNP接收定时器严格控制。在AI Incast场景下，由于RTT极短（2-5μs），DCQCN的RTT级反馈（50μs）往往滞后于Buffer溢出，导致PFC被频繁触发。
3. AI通信模式的数据流路径
- AllReduce (Ring/Tree)：典型的周期性Incast。8卡节点中，7张卡同时向1张卡发送Chunk。若CC反应慢于1个RTT，交换机Buffer瞬间溢出，触发PFC风暴。
- All-to-All (MoE) ：流量矩阵动态变化，静态的ECN阈值（ K m i n K_{min} Kmin）无法适应，必须依赖Swift等自适应算法或主机端可插拔CC架构。
三、硬件架构深度剖析
1. RNIC芯片整体架构
以下是面向AI集群的自研RNIC芯片微架构ASCII图，展示了从PCIe到MAC的核心数据通路：
text
[Host/GPU] <==PCIe Gen5 x16==> [PCIe EP Controller]
|
v
+-------------------------------------------------------------+
| [DMA Engine] <--> [TX/RX SRAM Buffer (Cell-based)] <--> [CC Engine] |
| | | | |
| v v v |
| [WQE/CQE Fetch] [QP Context RAM] [Rate Limiter] |
| | |
+-------------------------------------------------------------+
|
v
[RoCEv2 Packetizer]
|
v
[MAC/PHY 800G]2. RNIC芯片寄存器定义表
以下是与拥塞控制（CC）和QP管理相关的核心寄存器映射（基于PCIe BAR0 UAR空间，假设主频500MHz，2ns/cycle）：
| 寄存器名称 | 偏移地址 | 位域 | 复位值 | 属性 | 说明 |
|---|---|---|---|---|---|
CC_GLOBAL_CTRL |
0x1000 | 31:0 | 0x0000_0001 | RW | 1:0:算法选择(00:DCQCN, 01:TIMELY); 2:CC使能 |
QP_RATE_LIMIT |
0x1004 | 19:0 | 0x000F_FFFF | RW | 当前QP允许发送速率(Mbps)，TX Arbiter据此进行Token Bucket整形 |
ECN_KMIN_THRESH |
0x1008 | 15:0 | 0x0000_0100 | RW | ECN标记最小队列深度阈值(单位:Cell, 1Cell=256B) |
ECN_KMAX_THRESH |
0x100C | 15:0 | 0x0000_0800 | RW | ECN标记最大队列深度阈值，超过此值100%标记 |
RTT_BASELINE |
0x1010 | 31:0 | 0x0000_03E8 | RW | 基准无载RTT(ns)，用于TIMELY/Swift的梯度计算 |
CC_ALPHA_REG |
0x1014 | 7:0 | 0x0000_0010 | RW | DCQCN的Alpha权重因子，控制速率恢复的激进程度 |
PFC_PAUSE_CFG |
0x1018 | 15:0 | 0x0000_0040 | RW | PFC XOFF生成水线阈值(Cell) |
QP_CTX_PTR |
0x101C | 23:0 | 0x0000_0000 | RW | 当前正在处理的QP Context在SRAM中的基址指针 |
CQ_ARM_DB |
0x1020 | 31:0 | 0x0000_0000 | WO | CQ Arm Doorbell，写入后触发中断或轮询状态更新 |
TX_ERR_STATUS |
0x1024 | 31:0 | 0x0000_0000 | RC | TX错误状态，包含PFC超时、DMA错误等，写1清零 |
3. RTL级数据通路分解
在RNIC的TX数据通路中，拥塞控制引擎（cc_engine）位于MAC层与TX Arbiter之间。核心RTL模块及握手协议如下：
rx_parser：解析接收到的ACK/CNP/INT报文。提取ECN标记或INT队列深度。输出信号：ecn_ce_valid(1-bit),int_qdepth(16-bit),rtt_sample(32-bit)。cc_engine：核心状态机。采用AXI4-Stream的valid/ready机制。当ecn_ce_valid拉高且ready为1时，cc_engine在3个时钟周期（6ns）内完成速率计算。tx_arbiter：根据cc_engine输出的rate_update信号，动态调整Token Bucket的注入速率。
4. PCIe BAR空间划分与WQE/CQE时序
BAR空间划分：
| BAR | 地址范围 | 映射内容 | 访问方式 |
|---|---|---|---|
| BAR0 (UAR) | 4KB | User Access Region，Doorbell机制 | MMIO Write (32/64-bit) |
| BAR1 (BlueFlame) | 16MB | 直接推送小报文数据，绕过DMA | MMIO Write (连续) |
| BAR2 (Config) | 4KB | 健康状态、中断配置、寄存器映射 | MMIO Read/Write |
WQE/CQE 硬件时序分解（PCIe Gen5 x16, 32GT/s）：
text
[Host] --Doorbell(20ns)--> [NIC] --WQE Fetch(40ns)--> [DMA Read(150ns)]
--> [Packetize(30ns)] --> [MAC TX(10ns)] --> [Wire]
--> [Remote RX] --> [CQE Gen(50ns)] --> [Host CQ]总延迟 ：从Doorbell到MAC TX约 250ns 。CQE写回异步进行，延迟约 50ns。
5. DMA引擎架构
DMA引擎负责Scatter/Gather描述符链的解析。地址翻译流程：IOVA -> IOMMU (若开启) -> PA -> PCIe TLP。在GPUDirect场景下，通过PCIe P2P TLP直接路由到GPU BAR，绕过Host Memory。Bounce Buffer策略仅在内存未对齐或跨4K边界时触发，带来额外~100ns延迟。
四、AI通信的硬件加速实现
1. NCCL集合通信的硬件加速流水线
NCCL的Ring AllReduce将数据分为多个Chunk和Slice。在硬件层面，RNIC的DMA引擎需支持流水线分片传输 。硬件状态机（nccl_dma_fsm）设计：
IDLE：等待WQE。FETCH_META：读取WQE中的NCCL元数据（Rank, World Size）。DMA_CHUNK：按Chunk大小（如4MB）发起DMA。采用Double Buffering（Ping-Pong Buffer）掩盖PCIe延迟。WAIT_ACK：等待对端ACK。
2. GPUDirect RDMA (GDR) 数据通路
GPUDirect RDMA的核心是PCIe P2P（Peer-to-Peer）。GPU显存（VRAM）与NIC的BAR空间在同一PCIe Switch下。
- TLP路由 ：NIC发起DMA Read Request，目标地址为GPU的VRAM物理地址（如
0xFC000000）。PCIe Switch根据Bus/Device/Function号，直接将TLP路由到GPU。 - 延迟对比 ：Host Memory中转延迟约 400ns（含CPU缓存一致性刷新）；GPUDirect P2P延迟仅 120ns，带宽利用率提升30%以上。
3. 拥塞控制硬件实现与伪代码
以HPCC 为例，其核心速率调整公式在RTL中的实现：
R n e w = R o l d × ( 1 − α × Q l e n K m a x ) R_{new} = R_{old} \times (1 - \alpha \times \frac{Q_{len}}{K_{max}}) Rnew=Rold×(1−α×KmaxQlen)
RTL伪代码 (Verilog-like)：
verilog
always @(posedge clk) begin
if (rst_n) begin
rate_reg <= MAX_RATE;
end else if (int_qdepth_valid) begin
// 计算比例因子: alpha * Q_len / K_max
ratio = (ALPHA_REG * int_qdepth) >> 16;
// 乘性减速
rate_new = rate_reg - ((rate_reg * ratio) >> 10);
// 更新Token Bucket
rate_reg <= rate_new;
end else begin
// 加性递增
rate_reg <= rate_reg + AI_STEP;
end
end4. 多路径/自适应路由的硬件实现
在RoCEv2中，ECMP（Equal-Cost Multi-Path）哈希通常基于5-tuple。但在AI场景下，由于Flow Entropy极低，极易发生Hash冲突。硬件实现上，RNIC支持动态权重更新机制 ，通过读取交换机下发的INT遥测数据，在本地维护一张路径权重表（Path Weight Table），在TX Arbiter层实现Per-Packet的Spraying（如SRD协议），从而彻底规避Incast。
五、实战部署与深度配置
1. 交换机与NIC配置差异
- 交换机侧（如CE6800/Spectrum） ：必须开启PFC，配置基于Cell的水线。对于AI网络，建议将PFC水线设置为Buffer的30%-50%，避免过高导致死锁，过低导致吞吐下降。开启ECN，配置 K m i n K_{min} Kmin和 K m a x K_{max} Kmax。
- NIC侧（ConnectX-7 vs BlueField-3）：CX-7侧重极致低延迟，BF-3侧重DPU卸载。在AI训练中，通常关闭BF-3的Arm核卸载，直接走CX-7的纯硬件路径。
2. Linux侧完整配置命令序列
bash
# 1. 检查驱动与固件版本
ofed_info -s
mlxfwmanager --query
# 2. 查看RDMA设备与网络接口映射
ibdev2netdev
# 3. 配置NIC拥塞控制参数 (以mlx5为例)
mlxcfg -d /dev/mst/mt41692_pciconf0 set CABLE_MAX_RATE=400000
mlxconfig -d /dev/mst/mt41692_pciconf0 set ROCE_NEXT_PROTOCOL=1
# 4. 开启GPUDirect RDMA并检查IOMMU
nvidia-smi -q | grep -i gpudirect
cat /sys/kernel/iommu_groups/*/devices/*
# 5. 调整PCIe Max Read Request Size (MRRS)
setpci -s 0000:3b:00.0 CAP_EXP+08.w=5000 # 设置为512B
# 6. 配置NCCL环境变量
export NCCL_IB_HCA=mlx5
export NCCL_IB_GID_INDEX=3
export NCCL_ALGO=Ring
export NCCL_PROTO=Simple
export NCCL_CROSS_NIC=0
export NCCL_P2P_LEVEL=PXB
# 7. 检查QP与CQ资源限制
sysctl -w net.core.rmem_max=2147483647
sysctl -w net.core.wmem_max=2147483647
# 8. 开启硬件时间戳 (用于pRTT)
ethtool -T eth0 | grep hardware3. AI集群特有调优与检查清单
| 检查项 | 期望值 | 实际值 | 不匹配时的影响 |
|---|---|---|---|
| PFC水线 | 30%-50% Buffer | 80% | 极易触发PFC风暴与死锁 |
| ECN K m i n K_{min} Kmin | 略大于PFC水线 | 小于PFC水线 | DCQCN无法生效，直接打爆PFC |
| PCIe MRRS | 512B | 128B | DMA效率下降，带宽损失20% |
| NCCL_ALGO | Ring/Tree | NVLS(若不支持) | 通信失败或回退到低效路径 |
| GID Index | 3 (RoCEv2) | 0 (RoCEv1) | 路由错误，报文无法出子网 |
| IOMMU | 关闭或配置PASID | 开启且未直通 | GPUDirect P2P失败，走Host中转 |
| CQ深度 | > 1024 | 256 | CQE溢出，QP进入Error状态 |
| MTU | 4096 | 1024 | 包头开销增加，有效吞吐下降 |
| PFC COS映射 | Priority 3-4 | Priority 0 | 与管控流量冲突，导致丢包 |
| 固件版本 | 最新稳定版 | 旧版 | 存在已知的CC状态机Bug |
六、性能深度分析与基准测试
1. 测试方法论
- perftest ：用于底层RDMA语义测试（
ib_write_bw,ib_send_lat），验证单QP/多QP的极限带宽与尾延迟。 - nccl-tests ：用于集合通信测试（
all_reduce_perf,alltoall_perf），验证AI训练实际吞吐。 - 自定义benchmark：基于MoE流量矩阵生成器，模拟动态All-to-All，测试CC算法的收敛速度。
2. 性能数据表（基于800G RoCEv2集群）
| 规模配置 | 消息大小 | 延迟 P50/P99/P999 (μs) | 带宽 (Gbps) | 消息速率 (Mpps) |
|---|---|---|---|---|
| 单QP (Write) | 4MB | 2.1 / 2.3 / 3.5 | 780 | 0.24 |
| 多QP (64 QPs) | 64KB | 1.8 / 2.5 / 8.2 | 795 | 1.55 |
| 多机 (8 nodes) | AllReduce 1GB | 45.0 / 52.0 / 85.0 | 620 (Agg) | N/A |
| AI集群 (MoE) | All-to-All 512MB | 120.0 / 180.0 / 450.0 | 580 (Agg) | N/A |
| 注：P999延迟在MoE场景下飙升，主要由于PFC Pause导致的尾延迟放大。 |
3. 瓶颈分解与竞品对比
瓶颈分解：在800G网络中，端到端延迟中，PCIe DMA延迟占比约15%，协议处理（Header/Packetize）占比10%，网络传输（SerDes+Switch）占比60%，拥塞控制排队（PFC/CC）占比15%。
竞品方案对比：
| 特性 | NVIDIA ConnectX-7 | NVIDIA BlueField-3 | Broadcom Thor-2 | AMD Pensando DPU |
|---|---|---|---|---|
| 核心架构 | 纯NIC，极致低延迟 | DPU，Arm核卸载 | 交换芯片集成NIC | DPU，可编程P4 |
| CC算法 | DCQCN, 硬件HPCC | DCQCN, 软件自定义 | 硬件DCQCN | 软件可插拔CC |
| GPUDirect | 原生P2P, NVLink | 原生P2P | 支持PCIe P2P | 支持PCIe P2P |
| AI训练适用性 | 极高（主流选择） | 高（安全/存储卸载） | 中（依赖交换机生态） | 中（灵活性高但延迟略大） |
对训练step_time的影响：在LLaMA-70B训练中，CX-7相比Thor-2，由于更低的PCIe延迟和更优的NCCL硬件映射，step_time可缩短约8%-12%。
七、典型故障深度排查
1. AI训练典型故障诊断表
| 故障现象 | 根因分析 | 诊断命令 | 修复方案 | 预防措施 |
|---|---|---|---|---|
| PFC风暴 | Buffer耗尽，XOFF泛洪 | show pfc counters, show queue counters |
降低PFC水线，优化ECN K m i n K_{min} Kmin | 部署Swift/HPCC，关闭不必要的PFC优先级 |
| RDMA死锁 | 环形拓扑循环等待 | mlxlink -m, show deadlock counters |
开启Adaptive Routing，配置VLT | 确保网络拓扑无环，或配置基于QP的死锁恢复 |
| GPUDirect IOMMU错误 | IOMMU未直通或地址越界 | `dmesg | grep -i iommu, nvidia-smi` |
关闭IOMMU或配置PASID/IOMMU组直通 |
| QP泄漏/挂起 | 应用层未释放QP或CQE溢出 | ibv_devinfo, dump_qp_context |
重启应用，清理残留QP | 增加CQ深度，应用层增加QP超时重试机制 |
| PCIe AER错误 | 信号完整性或P2P路由错误 | `dmesg | grep AER, lspci -vvv` |
降速PCIe Gen5->Gen4，更换线缆 |
| 固件异常/Reset | CC状态机死锁或看门狗超时 | mlxfwmanager, mlxlink -m |
热重启，抓取Crash Dump | 升级固件，关闭非必要的硬件Offload |
2. 高级Debug手段
- 硬件Trace寄存器Dump：通过PCIe BAR2读取内部FIFO状态和状态机当前节点，定位CC Engine卡死位置。
- PCIe TLP抓包：使用PCIe Analyzer或NIC内部的Loopback模式，抓取DMA Read/Write TLP，分析地址翻译错误。
- NIC内部计数器分析 ：读取
tx_pause_frames,rx_ecn_marked,cqe_overflow等硬件计数器，量化拥塞与丢包。
3. 监控命令速查表
perfquery -x：查询端口硬件错误计数器。systool -c ib_port：查看IB/RDMA端口状态。mlxlink -m -d /dev/mst/mt41692_pciconf0：查看NIC链路物理状态与FEC。ethtool -S eth0 | grep -i pfc：查看网卡侧PFC Pause帧统计。cat /sys/class/infiniband/mlx5_*/ports/1/hw_counters/*：读取RDMA硬件计数器。dmesg -T | grep mlx5_core：查看NIC驱动日志与固件事件。nccl-tests/all_reduce_perf -b 1G -e 1G -g 8：快速验证8卡AllReduce带宽。watch -n 1 nvidia-smi dmon -s u：监控GPU PCIe收发带宽与利用率。
八、总结与设计trade-off
1. 核心技术要点总结表
| 概念 | 实现要点 | 常见误区 | 最佳实践 |
|---|---|---|---|
| PFC水线 | 基于Cell配置，需与ECN联动 | 设得越高越安全 | 设为Buffer的30%-50%，必须配合ECN |
| DCQCN | 硬件状态机，依赖CNP反馈 | 认为DCQCN能解决所有拥塞 | 仅作为第一道防线，Incast需依赖PFC兜底 |
| GPUDirect | PCIe P2P TLP直连 | 开启IOMMU导致性能下降 | 生产环境关闭IOMMU或配置严格直通 |
| NCCL调优 | 算法与协议选择 | 盲目开启所有Offload | 根据拓扑选择Ring/Tree，关闭不必要的代理 |
2. 设计权衡分析表 (Trade-off)
| 设计决策 | 性能/收益 | 面积/成本/功耗 | 灵活性 | 结论 |
|---|---|---|---|---|
| 硬件CC vs 软件CC | 硬件CC延迟极低(ns级) | 占用大量SRAM和逻辑面积 | 极低，依赖固件升级 | AI训练首选硬件CC，推理/通用云可选软件CC |
| 大Buffer vs 小Buffer | 大Buffer吸收Incast突发 | 芯片面积大，功耗高，延迟增加 | 无 | AI网络需大Buffer，但必须配合严格的PFC水线 |
| 流水线深度 | 提高主频，增加吞吐 | 增加延迟，设计复杂度高 | 无 | RX解析流水线需平衡，TX Pktize可深流水 |
| Per-QP vs Per-Pipe CC | Per-QP精度高 | 状态机数量多，SRAM爆炸 | 低 | 大模型场景推荐Per-Pipe聚合，降低硬件开销 |
3. AI RDMA最佳实践（按优先级排序）
- 关闭不必要的PFC优先级：仅保留数据平面的优先级（如Priority 3/4），避免管控流量干扰。
- 精准配置ECN与PFC水线 ： K m i n K_{min} Kmin 必须略大于PFC水线，确保DCQCN先于PFC触发。
- 开启Adaptive Routing：在交换机侧开启Per-Packet或Per-Flow的自适应路由，缓解Hash冲突。
- 统一固件与驱动版本：集群内所有NIC和交换机固件必须严格一致，避免状态机行为差异。
- GPUDirect P2P直通：确保GPU与NIC在同一PCIe Switch下，并关闭IOMMU干扰。
- NCCL参数固化 ：根据集群拓扑（Fat-Tree/Dragonfly）固化
NCCL_ALGO和NCCL_PROTO。 - 监控PFC与ECN计数器：部署Prometheus+Grafana，实时监控PFC Pause帧和ECN标记率，设置阈值告警。
- 定期执行Deadlock Recovery：在交换机侧配置死锁检测与自动恢复机制（如基于Credit的回退）。
- 评估主机端可插拔CC：对于MoE等极端动态流量，评估基于pRTT的主机端软件CC方案。
- 建立硬件级Trace能力：在测试环境保留PCIe TLP抓包和NIC内部寄存器Dump能力，用于疑难故障定位。
在AI大模型的算力狂飙中，网络不再是透明的管道，而是决定训练效率的核心引擎。理解PFC风暴与RDMA死锁的硅片级根因，掌握从寄存器配置到NCCL调优的全栈技能，是每一位AI基础设施工程师的必修课。
参考资料
- IEEE 802.1Qbb Standard for Priority-based Flow Control
- InfiniBand Architecture Specification Volume 1 (IB Spec)
- RFC 8238: Data Center Benchmarking Terminology
- IETF Draft: Benchmarking Terminology for AI Network Fabrics
- SIGCOMM 2024: Meta's LLM Training Cluster Network Architecture
- NSDI 2023: HPCC: High Precision Congestion Control
- Breaking Hardware Barriers: Host-Pluggable Congestion Control for RDMA
- RDMA Protocol and Communication Ecosystem: From IB/RoCEv2 to MoE
📝 作者简介： 资深RDMA智能网卡、存储技术专家，拥有十余年DPU/RDMA/NVMe SSD芯片测试与工程经验，致力于推动高性能网络技术的开源与普及。
👍 如果本文对你有帮助，欢迎点赞、收藏、关注！
💬 有问题欢迎评论区讨论，看到都会回复。