结合 arm 的 CHI 架构协议自主修改成较新版本的 nvswitch 协议可以而且这事在架构上是有抓手的——不是改几个字段那种小改而是以 CHI 为骨架、裁剪一致性、新增交换内计算的一次协议再设计。我先把可行性拆成三个层面讲清楚你自己判断要不要往下走。一、CHI 里可以直接继承的部分这部分是真能省的分层模型CHI 的 protocol / link / physical 分层、flit 格式、channel 划分TXREQ/RSP/DAT/SNP可以直接映射成 GPU fabric 的传输骨架。CHI 是公开规范分层思路本身不受限制。credit 流控 link 层重传L-Credit/RetryNVLink 同样是 credit-based flow control link-level retry概念几乎一一对应CHI 这部分是现成的教科书实现。Atomic 事务族这是 CHI 离 NVSwitch最近的一块。CHI Issue B 起就支持 AtomicLoad / AtomicStore / AtomicSwap / AtomicCompare对应 ARMv8.1 LSE 原子指令而 NVSwitch 的 in-network reduction 本质就是远端原子 交换芯片内算。你可以把 CHI 的 Atomic 事务语义直接扩展成发往 switch 归约引擎的 reduction op。地址映射System Address MapCHI 按地址区间路由到不同 HN/SN 的机制可改造成多 GPU 统一地址空间的路由表——GPU 显存映射成 fabric 地址区间switch 按地址/按目标 ID 转发。二、必须砍掉和新增的部分这才是工作量所在砍掉整套一致性状态机——MOESI、目录、snoop 事务SnpShared/SnpUnique 等、HN-F 的 snoop filter。GPU 间互联走的是无一致性内存语义NVLink 本身不维护跨 GPU 缓存一致性这部分在 CHI 里占了一半以上的复杂度砍掉后协议反而更接近 NVSwitch 的轻。新增NVSwitch 真正独有、CHI 完全没有的端口级硬件组播multicastNVSwitch 的 broadcast 是在交换芯片内做硬件复制——一个入口 flit 按组播掩码复制到多个出端口源 GPU 只发一次。CHI 事务模型是严格点对点请求-响应没有任何 switch-resident 的复制语义这个要在 datapath 层面新写。交换内归约引擎SHARP 类功能较新的 NVSwitchNVSwitch 3 起NVLink Switch / NVSwitch 4 更强能在芯片内对多路输入流做 FP16/FP32/FP8 加法归约再广播结果。这相当于在交换芯片里塞了一个 vector ALU 阵列——协议上要新增 reduction 事务类型、在途缓冲和反压机制这是和 CHI 差距最大的地方。物理层重映射CHI 的 flit 宽度是为片上/封装内互联设计的没有对接到 100G/lane 级 SerDes 的规定。你要在 CHI link 层之下重新设计 flit 到高速串行链路的映射这块反而可以复用你在 CMAC/GTY 上的积累或者用 UALink 的 PHY 思路。三、一个现实判断做成CHI-flavored 的 GPU 交换协议可行。裁剪一致性后的 CHI 组播 归约引擎架构上自洽业界也有先例思路UALink 本质上也是借用成熟协议栈 GPU 语义的组合。做成和较新版 NVSwitch 对标性能难在物理实现而非协议。NVSwitch 4 那一代的差距主要不在协议格式而在全交换无阻塞 Clos 拓扑的实现、switch 内归约的算力密度、以及 SHARP 与 NCCL 的软件协同。协议你能写出来但要复现它的带宽-延迟曲线工程量在 RTL 和软件栈。法律层面注意一点CHI 规范虽公开下载但商业实现涉及 ARM 的 AMBA 许可条款如果是自用研究/FPGA 原型没问题产品化前要过一眼许可。如果你后面想开工我建议的切入顺序是先写裁剪版去掉一致性只留内存读写原子→ 加组播 → 最后加归约引擎每一步都能在 KU5P 上做链路级验证。你想先从哪一步深入聊