3. 服务器平台
3.1 三种主流GPU服务器形态的工程定位
在数据中心GPU集群的硬件选型中，服务器平台决定了GPU的供电、散热、互联拓扑以及可维护性。当前主流形态分为PCIe GPU服务器、HGX（High-Performance GPU eXpress）基板服务器和MGX（Modular GPU eXpress）模块化服务器。三者并非简单的性能递进关系，而是面向不同部署密度、网络拓扑和运维策略的工程选择。
| 对比维度 | PCIe GPU服务器 | HGX基板服务器 | MGX模块化服务器 |
|---|---|---|---|
| GPU互联方式 | 通过PCIe Switch或CPU Root Complex | NVLink全互联（如NVSwitch） | NVLink域内互联，支持混合拓扑 |
| 典型GPU数量 | 4~8张（风冷为主） | 4~8张（HGX A100/H100/L40S） | 2~4张（模块化单元，可组合） |
| CPU耦合度 | 高，依赖CPU PCIe Lane | 中，通过PCIe Switch连接CPU | 低，模块独立供电/散热 |
| 适用场景 | 推理、中小规模训练、异构混布 | 大规模训练、多租户HPC | 边缘计算、灵活扩容、OEM定制 |
工程选型时，不能仅看GPU型号，还需确认服务器背板PCIe Lane分配、GPU供电接口（如PCIe 8pin/12VHPWR）、散热风道方向以及NVLink Bridge或NVSwitch的物理占用。例如，一台标称支持8张H100的PCIe服务器，若CPU仅提供64条PCIe 5.0 Lane，则每张GPU只能分配到x8带宽，实际训练吞吐可能下降15%~20%。
3.2 CPU与芯片组兼容性核心原理
GPU服务器对CPU的依赖主要体现在PCIe Lane数量、PCIe版本、IO虚拟化（SR-IOV）以及NUMA拓扑亲和性。Intel和AMD平台在PCIe Root Complex的分配方式上存在显著差异，直接影响GPU的物理拓扑。
- Intel Xeon Scalable（Ice Lake/Sapphire Rapids）：每颗CPU提供最多80条PCIe 5.0 Lane，支持x16拆分。Sapphire Rapids引入PCIe 5.0和CXL 1.1，但需注意部分型号的PCIe Lane被UPI或加速器占用。
- AMD EPYC（Genoa/Bergamo）：每颗CPU提供最多128条PCIe 5.0 Lane，且支持PCIe Lane动态拆分（如x16拆分为x8+x8）。Genoa的GMI3链路可提供更高的跨Socket带宽，适合双路CPU直连GPU。
- 芯片组（PCH）：GPU数据面不经过PCH，但PCH负责管理NVMe、网卡、BMC等控制面设备。若PCH的DMI带宽不足，可能在高IO压力下形成瓶颈。
兼容性验证的关键在于PCIe Lane分配表。例如，双路EPYC 9654平台，若每颗CPU提供128条Lane，其中8条用于连接PCH，8条用于OCP网卡，剩余112条可分配给GPU。此时8张GPU每张可获x16，但需确认主板布线是否支持全部x16插槽同时工作。
# 查看Linux下GPU所在NUMA节点及PCIe带宽
lspci -vvv -s 01:00.0 | grep -E "LnkCap|LnkSta|NUMA"
# 输出示例
# LnkCap: Port #0, Speed 32GT/s, Width x16
# LnkSta: Speed 32GT/s, Width x16
# NUMA node: 03.3 方法流程：GPU服务器兼容性验证清单
在采购或上架前，建议按以下流程进行硬件兼容性验证，避免“能点亮但性能不达标”的隐性故障。
- 确认CPU Lane预算：计算所有PCIe设备（GPU、网卡、NVMe、IB卡）所需Lane总数，对比CPU可用Lane。注意预留至少8条Lane给控制面设备。
- 核对GPU供电与散热：HGX基板通常需要8pin EPS或专用供电模块，PCIe GPU则依赖主板PCIe插槽供电（最高75W）+辅助供电。确认电源功率余量不低于30%。
- 验证NVLink拓扑：HGX平台需确认NVSwitch固件版本与GPU驱动匹配。使用
nvidia-smi topo -m检查GPU间互联是否形成全连接矩阵。 - 测试CPU-GPU带宽：使用
nvbandwidth或cudaMemcpy测试H2D/D2H带宽，若低于理论值80%，检查PCIe Lane是否降速或NUMA跨节点访问。 - 固件与BMC兼容：确认BIOS版本支持当前GPU的OptionROM，BMC的IPMI传感器能正确读取GPU温度与功耗。
3.4 案例：某训练集群HGX平台CPU选型失误复盘
某互联网公司部署8台HGX H100服务器，每台配置2颗Intel Xeon Platinum 8468（Sapphire Rapids，80 Lane/CPU）。规划时认为160条Lane足够8张H100（每张x16）使用，但实际测试发现GPU间P2P带宽仅达到理论值的60%。
排查过程：
- 使用
nvidia-smi topo -m发现GPU0~GPU3挂在CPU0下，GPU4~GPU7挂在CPU1下，跨CPU的P2P需经过UPI链路，带宽受限。 - 进一步检查BIOS设置，发现PCIe ACS（Access Control Services）开启，导致P2P DMA被强制走内存转发。
- 查阅Intel文档确认：8468的80条Lane中，有16条被UPI和DMI占用，实际可用仅64条，无法满足8张GPU全x16。
最终解决方案：更换为AMD EPYC 9654（128 Lane/CPU），并关闭ACS，P2P带宽恢复至理论值95%。该案例说明，CPU Lane数量不能只看规格表，必须扣除平台固定开销，且需验证BIOS默认的PCIe虚拟化策略。
3.5 常见误区与规避建议
此外，需注意PCIe Retimer或Redriver的引入。在长走线或高密度背板中，Retimer会增加约2~3微秒延迟，但对带宽无影响。若服务器使用PCIe Switch（如Broadcom PEX89000），需确认Switch的端口拆分模式与GPU数量匹配，否则可能出现端口闲置或带宽不均。
最后，建议在服务器验收时执行完整的GPU压力测试矩阵：包括单卡Furmark、多卡NVLink AllReduce、CPU-GPU混合负载（如HPL）以及故障注入测试（模拟单卡掉线）。只有通过全链路验证，才能确保服务器平台真正满足GPU集群的长期稳定性要求。