采购美国GPU服务器前，单卡与多卡配置的带宽、IP和交付条款要核对什么？

采购美国 GPU 服务器时，单卡还是多卡，不能只看 GPU 数量。先判断模型或业务是否必须跨卡，再把 GPU 显存、卡间拓扑、网卡带宽、流量计费、IP 数量和交付验收标准写进同一份采购单。最容易出现的风险是：买到了多卡，却没有满足卡间通信条件；签了“高带宽”，却没有写清保障带宽、流量方向和计费方式；拿到服务器后发现 IP 数量、端口权限或交付时间与业务计划不一致。

直接判断可以遵循下面的边界：

• 单 GPU适合模型可以放入单卡显存、任务不需要跨卡并行，或更重视部署简单性、故障隔离和较少的合同变量。
• 多 GPU适合单卡显存无法容纳模型、框架明确支持数据并行或模型并行，或需要在同一台服务器上提高并发处理能力。
• 多张 GPU 的显存不能默认直接相加。只有应用和框架采用了相应的模型切分或并行机制，才可能利用多卡资源。
• 多 GPU 不等于需要更多公网 IP，也不等于必须获得更高公网带宽。同一台服务器内的卡间通信主要取决于 GPU 拓扑、互联方式、PCIe 通道和主机配置；只有跨服务器协同，才需要额外核对服务器之间的网络条件。
• 任何带宽或性能结论，都只对约定的测试节点、测试时间、系统环境、测试方法和样本有效，不能把一次测试结果直接理解为全天候或所有访问方的保证。

先把单卡与多卡需求写成可验收条件

1. 先确认业务是否真的需要多卡

采购前应先回答以下问题，而不是先根据卡数比较报价：

• 单个模型、推理任务或训练任务的显存峰值是多少？
• 业务是单任务低延迟，还是多个任务并发？
• 应用支持数据并行、模型并行，还是只能使用一张卡？
• 多卡之间是否需要频繁交换数据？
• 业务能否在单 GPU 不可用时降级到其他实例或旧服务器？
• 任务是长期运行，还是短时批处理？

可以使用下面的判断表作为初筛依据：

如果供应商只写“多卡配置”，没有写明 GPU 型号、显存、卡间拓扑和是否独占，应视为配置不完整，不能进入最终验收。

2. 把关键配置写成具体字段

采购单中不要只写“美国 GPU 服务器、多卡、高带宽”，建议至少拆成以下字段：

“独享”也要写清对象。它可能指独享物理服务器、独享 GPU、独享端口，三者并不等价。若业务对稳定性有要求，应分别询问，而不能仅凭“独享服务器”推断网卡和带宽没有共享因素。

合同中重点核对带宽、线路、流量和 IP

带宽要区分端口速率与可用带宽

合同中至少要确认以下内容：

1. 端口速率：网卡端口的连接速率是多少，是否存在协商降速。
2. 保障带宽：写的是端口上限、固定保障值，还是共享资源的理论峰值。
3. 方向：入口和出口是否分别计量，是否存在单向或双向限制。
4. 突发规则：短时间突发是否允许，持续时间和限制方式是什么。
5. 流量计费：按总流量、出口流量、峰值带宽还是其他口径计算。
6. 超额处理：超出额度后是额外计费、限速、暂停，还是需要人工确认。
7. 统计来源：以服务商监控、服务器网卡统计、应用统计还是账单数据为准。
8. 测试口径：测试节点、协议、并发数、测试时间和判定阈值是否写入验收条款。

“端口是某个速率”不能直接等同于“业务一定能获得该速率”。实际吞吐还会受到测试节点、对端能力、协议并发、系统配置和业务数据特征影响。因此，采购时应要求带宽验收方法，而不是只要求一个宣传参数。

如果业务需要从对象存储、数据仓库或其他业务系统拉取数据，还要分别核对入口流量；如果 GPU 服务器对外提供推理接口、文件服务或数据分发，则应重点核对出口流量。两种流量方向不能用一个笼统的“月流量”代替。

线路条款要绑定测试方法

线路质量不能只用“优质线路”或“低延迟”描述。合同或工单中应保留：

• 测试服务器的标识和所在网络环境；
• 业务实际访问节点或约定测试节点；
• 使用 IPv4 还是 IPv6；
• 使用 ping、吞吐测试还是实际应用请求；
• 测试的时间窗口和重复次数；
• 延迟、丢包、吞吐和抖动分别如何判定；
• 测试失败时由谁复测，复测期间是否保留原始日志。

如果测试节点不是业务实际访问节点，测试结果只能说明该节点到服务器之间的表现，不能外推到其他访问方。一次短时测试也不能替代高峰期、低峰期和连续运行期间的观察。

IP 不能按 GPU 数量推导

一台单 GPU 服务器可能需要多个公网 IP，一台多 GPU 服务器也可能只需要一个公网 IP。IP 数量应根据业务入口、管理面、白名单、域名解析和服务隔离确定，而不是按照“几张卡配几个 IP”的方式采购。

至少核对以下事项：

• 分配的是固定公网 IP 还是临时地址；
• IPv4 和 IPv6 是否分别计费、分别开通；
• 地址数量是否包含网关地址、保留地址或不可分配地址；
• 是否提供子网掩码、网关和路由信息；
• 是否支持反向解析，申请和修改流程是什么；
• 入站端口是否默认开放，哪些端口需要单独申请；
• IP 更换是否收费，旧地址是否立即回收；
• 出现地址被封禁、误拦截或信誉异常时，处理和留证流程是什么；
• 服务器到期、迁移或取消后，IP 是否必须释放，业务如何切换。

如果多 GPU 服务器只是运行内部计算任务，通常不需要为每张 GPU 单独配置公网 IP。若多卡任务跨越多台服务器，则应把服务器间网络、内部地址规划和东西向流量单独列项，不能套用单台多卡服务器的公网 IP 条款。

到货后的连续验收步骤

验收前先固定条件和证据目录

正式测试前，应准备以下内容：

• 订单、配置单、带宽和 IP 条款的最终版本；
• 业务应用版本、模型版本、数据集版本和运行参数；
• 预期的单卡基线或现有服务器基线；
• 经过授权的带宽测试对端；
• 业务访问节点和测试时间窗口；
• 测试记录表、截图、命令输出和服务商工单编号。

如果需要修改 DNS、访问控制或生产路由，应先导出当前记录和配置，并保留原服务器或原服务入口。不要在未完成验收前直接切换全部生产流量。

第一步：核对服务器和 GPU 识别信息

在交付的 Linux 系统上，可以使用只读命令记录硬件状态。以下命令不会修改配置，但前提是系统已安装对应工具：

date -Is
cat /etc/os-release
nvidia-smi -L
nvidia-smi --query-gpu=index,name,memory.total,driver_version --format=csv
nvidia-smi topo -m
ip -br addr
ip route show

重点查看：

• GPU 数量是否与订单一致；
• 型号和显存是否一致；
• GPU 是否被其他任务占用；
• 多卡之间的拓扑是否与约定相符；
• 系统是否识别到正确的网卡和地址；
• 默认路由、网关和地址类型是否正确。

如果 nvidia-smi 或拓扑命令不可用，不要直接认定硬件异常。先记录系统版本、驱动状态和完整报错，再让交付方确认适配范围。不要为了“让命令有输出”擅自升级驱动，因为驱动变更可能影响既有应用，且会破坏原始验收环境。

查看网卡协商状态时，可先确认工具和接口：

command -v ethtool
NIC="$(ip -o route show default | awk 'NR==1 {print $5}')"
printf 'NIC=%s\n' "$NIC"
[ -n "$NIC" ] && ethtool "$NIC"

若链路速率低于合同约定，应先保留输出，不要立即重启网络或修改网卡参数。由交付方确认是网卡协商、交换端口、系统驱动还是合同配置问题。

第二步：核对 IP、路由和端口边界

IP 验收应包括地址、网关、路由和业务端口，而不是只看“能否访问网页”：

• 服务器上显示的公网地址与订单是否一致；
• 默认路由和网关是否匹配；
• 约定的 IPv4/IPv6 是否均可用；
• 业务需要的入站端口能否按合同策略访问；
• 不需要的端口是否保持关闭；
• 出站访问是否符合业务要求；
• IP 更换、回收和故障处理联系人是否已记录。

如果出站正常但入站失败，优先检查安全策略、端口开放范围、服务是否监听正确地址以及供应商侧的访问控制，不要立即判定线路故障。如果地址数量不符，应按合同申请补齐或更正，不要在服务器内自行添加未经分配的地址。

第三步：按合同约定测试带宽和线路

带宽测试必须使用已授权、能力足够且位置明确的对端。测试时间、服务器地址族、并发数和持续时长应与合同一致。Linux 环境中可先确认测试工具版本：

command -v iperf3
iperf3 --version

在确认对端已授权并处于接收状态后，再执行正向和反向测试。以下仅为记录格式示例，TEST_ENDPOINT 必须替换为双方约定的测试地址：

EVIDENCE_DIR="acceptance-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$EVIDENCE_DIR"

TEST_ENDPOINT="TEST_ENDPOINT"

date -Is | tee "$EVIDENCE_DIR/time.txt"
ping -c 20 "$TEST_ENDPOINT" | tee "$EVIDENCE_DIR/ping.txt"
iperf3 -c "$TEST_ENDPOINT" -t 30 -P 4 --json | tee "$EVIDENCE_DIR/iperf3-forward.json"
iperf3 -c "$TEST_ENDPOINT" -t 30 -P 4 -R --json | tee "$EVIDENCE_DIR/iperf3-reverse.json"

测试记录至少包含：

• 测试开始和结束时间；
• 美国 GPU 服务器的地址和网卡；
• 对端测试节点标识；
• IPv4 或 IPv6；
• 并发数、持续时长和测试方向；
• 原始输出和服务商监控数据；
• 当时的 GPU 任务、CPU 负载和其他流量情况。

ping 失败不一定代表 TCP 业务不可用，因为对端可能限制 ICMP；iperf3 结果偏低，也不一定能直接证明服务商带宽不足，还要排除对端容量、并发参数、系统负载和业务高峰的影响。验收结论应以合同约定的测试方法为准。

第四步：先做单卡基线，再做多卡实际任务

多 GPU 验收不能只运行 nvidia-smi。应使用真实业务或等价测试任务，并固定以下条件：

• 相同的模型和数据集；
• 相同的精度、批大小或并发策略；
• 相同的预热方式；
• 相同的运行时长；
• 相同的结果校验方法；
• 明确是数据并行还是模型并行。

先使用一张 GPU 运行基线，记录完成时间、吞吐、显存峰值、错误日志和温度等指标；再使用合同约定的 GPU 数量运行多卡任务。若多卡任务吞吐没有按预期提升，应进一步查看卡间拓扑、PCIe 布局、CPU 内存访问和通信等待，而不是仅凭公网带宽或 IP 数量下结论。

多卡扩展效率可以按下面的方式记录：

多卡扩展效率 = 多卡任务吞吐 ÷（单卡基线吞吐 × 使用的 GPU 数量）

这个比例只是分析工具，不是通用合格阈值。合格标准必须结合业务目标写进验收单，例如单位时间处理量、最大延迟、显存余量和连续运行稳定性。没有事先约定目标时，只能说明测试差异，不能事后随意判定供应商违约。

测试结果异常时如何判断

异常留证与回滚

验收失败时，先冻结现场，再处理配置。建议保留：

• 订单和最终配置单；
• GPU、网卡、IP、路由和拓扑输出；
• 测试脚本、原始日志和时间戳；
• 业务任务参数、模型校验值和结果文件；
• 服务商工单、回复内容和复测安排；
• 异常发生前后的监控截图。

如果是硬件、IP 或带宽与合同不符，不要先重装系统、升级驱动、修改网络参数或切换生产流量。先要求交付方给出修复方案，并约定修复后的复测条件。

如果已经涉及业务切换，应采用可回退方式：

1. 保留旧服务器或原服务入口，确认其仍能承载回退流量。
2. 修改 DNS、访问控制或路由前，备份当前记录和配置。
3. 先让少量业务进入新服务器，观察错误率、延迟、吞吐和 GPU 使用情况。
4. 新服务器未通过全部验收时，将流量恢复到原入口。
5. 记录回退时间、原因、影响范围和恢复结果。
6. 只有硬件、网络、IP、应用任务和合同条款全部复核通过后，才完成正式交付。

签字前保留的复核项

• 单 GPU 或多 GPU 的选择是否有明确业务依据；
• 多卡是否验证了显存使用方式和实际并行任务；
• GPU 型号、数量、显存和拓扑是否与订单一致；
• 网卡端口速率、保障带宽、流量方向和超额规则是否写清；
• 线路测试是否记录了节点、时间、协议、方向和原始结果；
• IP 数量、地址类型、路由、端口策略和更换流程是否明确；
• 计费起点、交付起点、验收期和异常处理是否一致；
• 生产切换前是否完成备份、分阶段验证和回滚准备；
• 所有未解决的问题是否进入工单，并标明责任方和复测时间。

这样核对后，单 GPU 与多 GPU 的差异才会真正落到可交付、可测试、可回退的条款上，而不是停留在卡数、带宽标签或 IP 数量的表面比较。