企业官网建设流程全解析

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 的设计如果支持无阻塞交换，那它的交换容量至少要等于所有下行端口带宽之和。

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 级别交换机做机架内互联，机架之间再用上层交换机互联。

容量测算步骤：

1. 计算机架内下行总带宽：8 × 400Gbps = 3200Gbps。
2. 确定机架内交换机交换容量：至少 3200Gbps，建议留 20% 余量。
3. 确定上行端口数：如果要做无阻塞跨机架，上行也要 3200Gbps，即 8 个 400G 上行。
4. 计算上层交换机端口数：8 个机架 × 8 上行 = 64 个 400G 端口。
5. 上层交换机交换容量：64 × 400Gbps = 25600Gbps。

这个测算过程看起来简单，但实际做的时候要反复迭代，因为机架数、卡数、端口速率都可能调整。我一般会做一个表格，把不同配置下的端口数和交换容量列出来，方便对比。

4.2 布线方案与线缆选型

scale up 互联的线缆选型，主要看距离和速率。机架内短距离可以用铜缆，成本低、延迟小；跨机架用光缆，距离远、抗干扰。400G 及以上速率，铜缆的有效距离很短，通常只有几米，所以跨机架基本都要走光。

光模块选型要注意兼容性。不同厂商的交换机对光模块的兼容列表不一样，混用可能不识别。我的做法是，关键链路用交换机厂商认证的模块，非关键链路可以试第三方，但一定要先小批量验证。

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 上线验证与性能基线

交换机配置完成后，不要直接跑训练任务，先做性能基线测试。测试内容包括：

1. 单链路带宽测试：确认每条链路能跑满标称速率。
2. 全卡对带宽测试：确认任意两张卡之间的带宽一致。
3. 延迟测试：测量点对点延迟，确认在预期范围内。
4. 集合通信测试：跑 all-reduce、all-gather 等操作，观察带宽利用率。

我一般会用 nccl-tests 这类工具做集合通信测试，用 ib_write_bw 或类似工具做点对点测试。测试结果要存档，作为后续故障排查的基线。如果某次训练性能下降，先对比基线，看是链路问题还是任务本身的问题。

5. 常见问题与排查技巧实录

5.1 链路起不来或频繁闪断

这是最常见的问题，原因可能出在光模块、线缆、端口配置、对端设备任何一个环节。排查顺序建议从物理层往上走：

1. 检查光模块是否插紧，金手指是否干净。
2. 检查线缆是否有折弯、挤压。
3. 查看端口日志，看是否有链路训练失败、误码率过高的记录。
4. 换端口、换线缆、换模块，逐步定位。

我遇到过一种情况：光模块和交换机兼容，但和加速卡不兼容，链路能起来但跑一会儿就闪断。后来换了加速卡厂商认证的模块才稳定。所以兼容性不能只看交换机一侧，要两端都确认。

5.2 带宽跑不满标称值

带宽跑不满，可能是链路问题，也可能是配置问题。先确认单链路能不能跑满，如果单链路正常，那问题在多链路聚合或路由。检查链路聚合的哈希算法，确保流量均匀分布到各成员链路。如果哈希算法是源目的 IP 哈希，而流量模式比较单一，可能导致某些链路空闲。

另一个常见原因是 PCIe 带宽瓶颈。加速卡的互联端口速率很高，但如果数据要先经过 PCIe 再到互联端口，PCIe 可能成为瓶颈。这种情况要看加速卡的架构设计，有些卡支持互联端口直接访问显存，不经过 PCIe。

5.3 集合通信性能波动

集合通信性能波动，通常和拓扑不对称、拥塞、温度降频有关。排查步骤：

1. 跑全卡对带宽测试，找出慢链路。
2. 检查交换机端口计数器，看是否有丢包、拥塞。
3. 检查机房温度和设备温度，看是否有降频。
4. 检查是否有其他任务在抢占带宽。

我遇到过一次性能波动，最后发现是机房空调故障导致温度升高，交换机降频。这种问题从软件层面很难看出来，一定要结合环境监控数据。

5.4 故障排查速查表

提示：排查 scale up 互联问题，最重要的是有基线数据。没有基线，你连"正常"是什么样都不知道，更别说找异常了。

6. 从 TH6 看 scale up 互联的演进方向

TH6 公开的设计，反映出一个趋势：scale up 互联正在从"加速卡附带的私有互联"变成"机架级的基础设施"。这个变化的影响是深远的。以前做集群规划，互联部分基本是黑盒，厂商给什么用什么；现在互联交换机独立出来，意味着你可以像规划网络一样规划 scale up 域，做容量测算、做冗余设计、做故障隔离。

对从业者来说，这意味着技能栈要扩展。以前搞 AI 集群可能只需要懂 GPU、懂 MPI、懂存储；现在还要懂交换芯片、懂拓扑、懂链路预算。这不是坏事，懂底层的人永远稀缺。我个人的建议是，如果你在做 AI 基础设施，花点时间把 scale up 互联的原理和实操搞明白，这会是未来几年的核心竞争力。

另一个值得关注的点是标准化。scale up 互联目前还是各家有各家的方案，互通性差。如果 TH6 这类设计能推动接口标准化，那对整个生态都是好事。标准化意味着更多厂商可以参与，成本下降，创新加速。当然，标准化也可能牺牲一些极致性能，这个平衡怎么把握，是 AMD 和生态伙伴要一起解决的问题。

最后分享一个我在实际部署中的体会：scale up 集群的性能，往往不是被最慢的卡决定的，而是被最慢的链路决定的。所以规划阶段宁可多花时间做对称设计，也不要为了省端口省线缆搞出不对称拓扑。后期排查不对称拓扑的性能问题，花的时间远超前期省下的成本。这个坑我踩过，希望你别再踩。