1. 从一颗芯片到一张网AMD Helios 与 TH6 到底在做什么AMD 这几年在数据中心的存在感越来越强从 EPYC 处理器到 Instinct 加速卡再到最近放出的 Helios 机架级方案路线图越来越清晰。这次公开的 TH6 scale up 交换机设计是 Helios 体系里非常关键的一块拼图。简单说它解决的是一堆加速卡怎么高效连成一台逻辑上的大机器这个问题。如果你平时关注的是单卡算力、显存带宽、模型参数量那 scale up 这个词可能有点抽象但如果你搭过多卡训练集群就会知道真正卡脖子的往往不是单卡而是卡与卡之间的互联。TH6 这个命名延续了 AMD 在互联层面的代际节奏T 通常指代互联Topology/Transport 一类含义H 系列则和 Helios 机架方案绑定。scale up 交换机的核心任务是把同一机架内、甚至跨机架的加速卡用高带宽、低延迟的链路连起来让它们像访问本地显存一样访问邻居的显存。这跟传统数据中心里 scale out 用的以太网交换机完全是两个思路scale out 追求的是通用、可扩展、成本可控scale up 追求的是极致带宽、极低延迟、内存语义一致。我先把结论摆在这TH6 公开的意义不在于AMD 又出了一款交换机而在于它把 scale up 互联从加速卡厂商的私有黑盒往可被机架级方案统一调度的方向推了一步。对做集群规划、机房布线、散热供电的人来说这意味着选型和容量测算的模型要跟着变。下面我会从设计思路、核心细节、实操落地和排障几个角度把这件事拆开讲清楚尽量让没接触过 scale up 互联的读者也能看懂。2. 内容整体设计与思路拆解2.1 为什么 scale up 需要专用交换机而不是普通以太网要理解 TH6 的设计先得理解 scale up 和 scale out 的本质区别。scale out 是把任务拆到很多台独立服务器上每台服务器有自己的内存空间节点之间通过标准以太网或 InfiniBand 通信走的是消息传递语义。你发一个 all-reduce数据要经过打包、传输、解包延迟在微秒级带宽受限于网卡和交换机端口速率。scale up 不一样它追求的是内存语义——加速卡可以直接读写另一张卡的显存不需要对方 CPU 参与也不需要走完整的网络协议栈。这种模式下延迟要压到百纳秒级带宽要跟显存带宽一个量级。普通以太网交换机的转发芯片是为包转发设计的缓冲区、调度、协议处理都是围绕包来的做内存语义互联会非常别扭。所以 scale up 需要专门的交换芯片和协议TH6 就是干这个的。提示判断一个互联方案是不是 scale up最简单的标准是看它支不支持内存语义的直接访问。如果还要走 socket、走 MPI那本质还是 scale out。2.2 Helios 机架方案里 TH6 的位置Helios 是 AMD 面向大规模 AI 训练的机架级参考设计里面包含计算节点、加速卡、供电、液冷、互联几个部分。TH6 交换机在其中的角色类似于一个卡间中枢它把机架内所有加速卡的 scale up 端口汇聚起来做成一个无阻塞的交换平面。这样做的直接好处是机架内任意两张卡之间的通信跳数固定不会因为拓扑变化导致某些卡对之间的延迟忽高忽低。从公开的设计思路看TH6 走的是多层交换的路线支持把多个交换芯片级联成更大的平面。这一点很关键因为单机架能塞的加速卡数量有限要支撑更大的模型并行度就必须跨机架扩展。TH6 的设计目标应该是让跨机架的 scale up 域也能保持一致的延迟特性而不是像传统方案那样跨机架就退化成 scale out。2.3 方案选型背后的取舍做 scale up 交换机绕不开几个取舍端口速率、端口密度、交换延迟、功耗、成本。TH6 公开的信息里端口速率和密度是重点这符合当前加速卡互联带宽快速上涨的趋势。我个人的判断是AMD 选择在这个时间点公开 TH6一方面是为了给 Helios 方案背书让客户知道互联不是瓶颈另一方面也是在向生态释放信号鼓励更多厂商围绕这个互联标准做适配。这里有个容易被忽略的点scale up 交换机的价值不只在硬件本身还在配套的软件栈。拓扑发现、路由计算、故障隔离、拥塞控制这些都需要软件配合。TH6 如果只公开硬件设计而不谈软件接口那对实际部署的帮助是有限的。所以看这类方案一定要把硬件和软件放在一起评估。3. 核心细节解析与实操要点3.1 端口与带宽的匹配逻辑scale up 交换机的端口速率必须和加速卡的互联端口匹配否则要么浪费卡的带宽要么交换机成为瓶颈。假设一张加速卡的 scale up 端口是 400Gbps一个机架有 8 张卡那交换机至少需要 8 个 400G 下行端口。如果还要做跨机架上行上行端口数取决于你想要的收敛比。收敛比的计算很简单下行总带宽除以向上总带宽。比如 8 个 400G 下行2 个 400G 上行收敛比就是 4:1。scale up 场景下收敛比通常要做到 1:1 无阻塞因为 all-reduce 这类操作是全局同步的任何一条链路拥塞都会拖慢整个集合通信。TH6 的设计如果支持无阻塞交换那它的交换容量至少要等于所有下行端口带宽之和。参数典型取值说明单端口速率400Gbps / 800Gbps跟随加速卡互联代际下行端口数8 / 16 / 32取决于机架内卡数上行端口数与下行对称或减半无阻塞建议对称交换延迟百纳秒级内存语义的关键指标收敛比1:1 优先集合通信敏感3.2 拓扑结构与跳数控制scale up 域内常见的拓扑有全互联、胖树、蜻蜓等。全互联在卡数少的时候延迟最低但端口数随卡数平方增长不现实。胖树和蜻蜓是可扩展的方案代价是跳数增加。TH6 作为交换芯片需要支持这些拓扑的路由计算。跳数控制的核心是让任意两张卡之间的路径长度尽量一致。如果某些卡对是 1 跳某些是 3 跳那集合通信的完成时间取决于最慢的那对整体效率就被拉低了。所以设计时要尽量做对称拓扑或者在路由算法上做流量均衡。注意拓扑不对称是 scale up 集群性能波动的常见原因。上线前一定要用带宽测试工具跑一遍全卡对的点对点带宽把最慢的路径找出来。3.3 与加速卡端口的对接细节交换机端口和加速卡端口对接涉及物理层、链路层、协议层三个层面。物理层看的是 SerDes 速率、通道数、连接器类型链路层看的是链路训练、误码率、重传机制协议层看的是内存语义的地址映射和一致性协议。实操中最容易出问题的是链路训练。不同厂商的 SerDes 参数、均衡设置不一样混插时可能出现链路起不来或者误码率高的情况。我的经验是新集群上线前先做单链路压力测试跑满带宽持续一段时间观察误码计数。如果误码率超过阈值先调均衡参数再考虑换线缆或光模块。3.4 供电与散热的实际约束scale up 交换机通常放在机架顶部或专门的互联机架里功耗密度不低。一个满配的 TH6 级别交换机功耗可能到几百瓦甚至更高。供电要走冗余散热要保证风道畅通。如果是液冷机架交换机的散热方案也要和整体液冷系统匹配。我踩过的坑是交换机放在机架顶部热风被上层设备吸走导致进风温度偏高夏天容易触发降频。后来改成下进风、上出风并在机架内加导流板温度才降下来。这类问题在规划阶段就要考虑不要等上线了再补救。4. 实操过程与核心环节实现4.1 集群规划阶段的容量测算假设你要搭一个 64 卡的 scale up 域每张卡互联端口 400Gbps。如果用一个机架放 8 张卡需要 8 个机架。每个机架内用一台 TH6 级别交换机做机架内互联机架之间再用上层交换机互联。容量测算步骤计算机架内下行总带宽8 × 400Gbps 3200Gbps。确定机架内交换机交换容量至少 3200Gbps建议留 20% 余量。确定上行端口数如果要做无阻塞跨机架上行也要 3200Gbps即 8 个 400G 上行。计算上层交换机端口数8 个机架 × 8 上行 64 个 400G 端口。上层交换机交换容量64 × 400Gbps 25600Gbps。这个测算过程看起来简单但实际做的时候要反复迭代因为机架数、卡数、端口速率都可能调整。我一般会做一个表格把不同配置下的端口数和交换容量列出来方便对比。4.2 布线方案与线缆选型scale up 互联的线缆选型主要看距离和速率。机架内短距离可以用铜缆成本低、延迟小跨机架用光缆距离远、抗干扰。400G 及以上速率铜缆的有效距离很短通常只有几米所以跨机架基本都要走光。光模块选型要注意兼容性。不同厂商的交换机对光模块的兼容列表不一样混用可能不识别。我的做法是关键链路用交换机厂商认证的模块非关键链路可以试第三方但一定要先小批量验证。场景线缆类型典型距离注意事项机架内卡到交换机铜缆/DAC 3m注意弯曲半径机架内交换机到交换机铜缆/DAC 5m注意散热跨机架光缆AOC5m-100m注意模块兼容跨机房光缆 100m注意光衰预算4.3 交换机配置与调优交换机上线后配置工作包括端口使能、速率协商、链路聚合、路由策略、QoS 等。scale up 场景下QoS 的重点是保证集合通信流量优先避免被管理流量或其他流量挤占。配置示例以常见命令行风格示意# 使能端口 interface ethernet 1/1-1/8 no shutdown speed 400g fec rs # 配置链路聚合 interface port-channel 1 member ethernet 1/1-1/4 # 配置 QoS 优先级 qos policy scale-up class collective-traffic priority 7 class management-traffic priority 1调优的重点是 FEC 模式和缓冲区分配。400G 及以上速率通常需要 RS-FEC但 FEC 会引入额外延迟。如果链路质量好可以尝试关闭 FEC 降低延迟但要先确认误码率在可接受范围。4.4 上线验证与性能基线交换机配置完成后不要直接跑训练任务先做性能基线测试。测试内容包括单链路带宽测试确认每条链路能跑满标称速率。全卡对带宽测试确认任意两张卡之间的带宽一致。延迟测试测量点对点延迟确认在预期范围内。集合通信测试跑 all-reduce、all-gather 等操作观察带宽利用率。我一般会用 nccl-tests 这类工具做集合通信测试用 ib_write_bw 或类似工具做点对点测试。测试结果要存档作为后续故障排查的基线。如果某次训练性能下降先对比基线看是链路问题还是任务本身的问题。5. 常见问题与排查技巧实录5.1 链路起不来或频繁闪断这是最常见的问题原因可能出在光模块、线缆、端口配置、对端设备任何一个环节。排查顺序建议从物理层往上走检查光模块是否插紧金手指是否干净。检查线缆是否有折弯、挤压。查看端口日志看是否有链路训练失败、误码率过高的记录。换端口、换线缆、换模块逐步定位。我遇到过一种情况光模块和交换机兼容但和加速卡不兼容链路能起来但跑一会儿就闪断。后来换了加速卡厂商认证的模块才稳定。所以兼容性不能只看交换机一侧要两端都确认。5.2 带宽跑不满标称值带宽跑不满可能是链路问题也可能是配置问题。先确认单链路能不能跑满如果单链路正常那问题在多链路聚合或路由。检查链路聚合的哈希算法确保流量均匀分布到各成员链路。如果哈希算法是源目的 IP 哈希而流量模式比较单一可能导致某些链路空闲。另一个常见原因是 PCIe 带宽瓶颈。加速卡的互联端口速率很高但如果数据要先经过 PCIe 再到互联端口PCIe 可能成为瓶颈。这种情况要看加速卡的架构设计有些卡支持互联端口直接访问显存不经过 PCIe。5.3 集合通信性能波动集合通信性能波动通常和拓扑不对称、拥塞、温度降频有关。排查步骤跑全卡对带宽测试找出慢链路。检查交换机端口计数器看是否有丢包、拥塞。检查机房温度和设备温度看是否有降频。检查是否有其他任务在抢占带宽。我遇到过一次性能波动最后发现是机房空调故障导致温度升高交换机降频。这种问题从软件层面很难看出来一定要结合环境监控数据。5.4 故障排查速查表现象可能原因排查方法链路起不来模块/线缆/配置换件法、查日志链路闪断兼容性/误码查误码计数、换模块带宽不足聚合/PCIe/拥塞单链路测试、查计数器延迟偏高FEC/跳数/拥塞查 FEC 配置、拓扑性能波动温度/抢占/拓扑环境监控、任务隔离集合通信慢慢链路/路由全卡对测试、路由检查提示排查 scale up 互联问题最重要的是有基线数据。没有基线你连正常是什么样都不知道更别说找异常了。6. 从 TH6 看 scale up 互联的演进方向TH6 公开的设计反映出一个趋势scale up 互联正在从加速卡附带的私有互联变成机架级的基础设施。这个变化的影响是深远的。以前做集群规划互联部分基本是黑盒厂商给什么用什么现在互联交换机独立出来意味着你可以像规划网络一样规划 scale up 域做容量测算、做冗余设计、做故障隔离。对从业者来说这意味着技能栈要扩展。以前搞 AI 集群可能只需要懂 GPU、懂 MPI、懂存储现在还要懂交换芯片、懂拓扑、懂链路预算。这不是坏事懂底层的人永远稀缺。我个人的建议是如果你在做 AI 基础设施花点时间把 scale up 互联的原理和实操搞明白这会是未来几年的核心竞争力。另一个值得关注的点是标准化。scale up 互联目前还是各家有各家的方案互通性差。如果 TH6 这类设计能推动接口标准化那对整个生态都是好事。标准化意味着更多厂商可以参与成本下降创新加速。当然标准化也可能牺牲一些极致性能这个平衡怎么把握是 AMD 和生态伙伴要一起解决的问题。最后分享一个我在实际部署中的体会scale up 集群的性能往往不是被最慢的卡决定的而是被最慢的链路决定的。所以规划阶段宁可多花时间做对称设计也不要为了省端口省线缆搞出不对称拓扑。后期排查不对称拓扑的性能问题花的时间远超前期省下的成本。这个坑我踩过希望你别再踩。