香港显卡集群部署分布式内存后推理变慢，如何区分大陆运营商路径与集群内带宽瓶颈？

当香港显卡服务器集群的推理接口出现首 token 延迟升高、流式输出断续或吞吐下降时，我们不会先假定是显卡算力不足。要定位大陆运营商路径上的带宽瓶颈，正确顺序是：先把大陆电信、联通、移动等来源拆开，在相同香港入口上分别采集 ping、TCP 路径和应用请求数据；再将外部结果与集群内部节点、显卡通信和分布式内存读写指标对照。只有某一运营商路径异常时，才优先调整对应入口或线路；如果所有运营商都正常而推理变慢，问题通常已经进入集群内部。

下面以一组便于说明的典型场景展开。香港集群包含多个显卡工作节点，推理服务使用分布式内存保存或共享部分 KV Cache、上下文数据和中间状态，大陆用户通过统一 HTTPS 入口访问。前置条件包括：至少准备三个大陆探针，分别确认其接入运营商和出口地址；香港入口使用固定目标 IP，测试期间不要让 DNS 解析频繁切换；能查看网关、推理服务、分布式内存服务和显卡节点的指标；准备一个低流量测试请求，避免直接用大批量生产请求压测；iperf3、集合通信测试等主动测试应在维护窗口或独立测试节点执行；调整线路、路由或分布式内存参数前，保存当前配置，并准备恢复旧入口、旧参数和旧副本策略。

先把带宽问题拆成五段

分布式内存架构能够减少重复加载、提高显卡显存与主机内存的利用率，但它也会增加节点之间的数据交换。如果不区分流量方向，很容易把“大陆到香港的访问问题”和“香港集群内部的内存读写问题”混为一谈。

判断时要记住一条原则：ping 只能说明 ICMP 报文的往返情况，traceroute 只能帮助观察路径和中间跳点，二者都不能单独证明推理接口的真实性能。最终还要用与业务一致的 TCP 端口和低流量请求进行验证。

按运营商固定样本并验证业务路径

固定目标和运营商样本

我们先在三个大陆探针上记录接入运营商、探针所在省市或业务主要来源区域、探针公网地址及其归属、测试时间、香港入口目标 IP、测试协议和端口，以及当时的业务并发量。

如果同一个探针存在多条出口路径，应在记录中注明。不要只按探针机器所在机房判断运营商，还要核对实际公网出口的归属。对于使用多线接入的探针，至少连续采集两轮，避免一次测试恰好命中临时路径。

香港入口需要固定为同一个 IP。若入口前有多个地址，应先分别测试每个地址，不能把多个地址的结果混成一组。应用层测试则保留正确的域名和证书名称，例如：

TARGET_IP="<香港入口固定IP>"
TARGET_HOST="api.example.com"

这里的占位符需要替换成实际测试对象，不要直接把域名解析结果和业务请求结果混在一起。

用 ping 看延迟分布

在每个大陆运营商探针上执行相同数量的测试，例如：

ping -4 -c 30 -i 0.2 "$TARGET_IP"

我们重点看最小、平均和最大往返时间，中位数延迟，高分位延迟（例如 p95），以及最终目标的丢包比例。

例如，一组用于说明的模拟数据如下：

这组数据不能直接证明电信路径一定存在带宽不足，因为 ICMP 可能被限速，也可能与业务 TCP 走不同处理路径。但它提示我们优先检查电信来源的高峰时段和 TCP 应用请求。

判断规则可以这样使用：

• 三个运营商的 p95 同时升高，且最终目标也出现丢包：优先检查香港入口、上联容量或共同路径。
• 只有一个运营商的 p95 和丢包升高：优先排查该运营商到香港入口之间的互联或入口选择。
• 中间节点显示丢包，但最终目标没有丢包：不能直接判定中间链路拥塞，常见原因是中间设备限制 ICMP 响应。
• ping 正常但应用请求变慢：继续检查 TCP 建连、TLS、网关排队和分布式内存，不要停留在 ICMP 结果上。

对于持续性判断，30 个包只能作为快速筛查。正式验收应在相同业务时段连续采集多轮，并记录每轮的 p50、p95 和最终丢包。

用 traceroute 和 mtr 看路径变化

为了尽量贴近 HTTPS 业务，可以使用 TCP 443 进行路径探测：

sudo traceroute -4 -n -T -p 443 -w 2 -q 3 "$TARGET_IP"

如果系统没有 traceroute，在测试节点上安装对应发行版的软件包即可。安装动作应优先在测试节点进行，不要为了临时排查直接改动生产镜像。

traceroute 主要看三件事：大陆探针出口之后，路径是否在某个运营商段发生明显变化；不同运营商到香港入口的中间路径是否完全不同；高延迟是否从某一跳开始持续到最终目标。

但中间节点出现 * 不等于该跳就是瓶颈。很多设备只转发业务报文，不优先响应路径探测报文。如果后续节点和最终目标都正常，这一跳通常只能说明“没有返回探测响应”，不能说明“业务包在这里丢失”。

为了获得更稳定的统计，可以使用 TCP 方式的 mtr：

sudo mtr -4 -n -r -c 50 -T -P 443 "$TARGET_IP"

这里要分别看中间节点和最终目标：

• 某一中间节点丢包，但后续节点恢复正常：更接近响应限速；
• 从某一节点开始，后续所有节点和最终目标都出现相近丢包：才值得重点检查该段；
• 路径中间出现延迟升高，但最终目标延迟没有同步升高：不能把该节点延迟直接累加到业务 RTT；
• 同一探针多次运行得到不同路径：可能存在负载分担，必须增加样本，不能依据一次输出选择线路。

ping 给我们的是端到端统计，traceroute 给我们的是路径线索。两者必须与应用请求结果配合使用。

用应用请求验证推理性能

网络路径没有明显异常时，我们接着执行固定的小请求。先检查入口层的连接和响应时间：

curl --resolve "${TARGET_HOST}:443:${TARGET_IP}" \
  --connect-timeout 5 \
  --max-time 20 \
  -sS -o /dev/null \
  -w 'remote=%{remote_ip} connect=%{time_connect}s tls=%{time_appconnect}s start=%{time_starttransfer}s total=%{time_total}s code=%{http_code}\n' \
  "https://${TARGET_HOST}/healthz"

这个请求只能验证入口和应用健康检查，不代表完整推理时间。随后使用固定输入、固定输出长度和固定并发执行低速业务请求，至少记录 TCP 建连时间、TLS 完成时间、首 token 时间、完整响应时间、输入和输出 token 数、网关排队时间、分布式内存读取时间，以及推理节点实际执行时间。

如果只有 connect 或 tls 时间升高，问题靠近入口路径。如果连接时间正常、首 token 时间升高，则需要看网关排队、KV Cache 读取和显卡调度。如果首 token 正常但完整响应变慢，重点转向输出阶段的显卡利用率、显卡节点间通信和流式连接处理。

确认香港集群内部是否为东西向带宽

外部路径测完后，我们登录香港显卡节点，先执行只读检查：

ip -br addr
ip route
ip -s link show dev ens5
ss -s

网卡名称不一定是 ens5，应先通过 ip -br addr 确认实际接口。重点观察接口接收和发送字节是否接近链路上限，是否持续增加丢包、错误或重传计数，TCP 建立连接数是否突然升高，分布式内存服务是否出现大量短连接，以及推理请求是否在内存读取阶段排队。

如果系统支持 ethtool，可以进一步查看驱动统计：

sudo ethtool -S ens5 | egrep -i 'drop|error|miss|timeout|retrans'

不同网卡驱动的字段名称并不统一，命令没有输出某个字段不代表没有问题，应以实际接口统计为准。

用 iperf3 区分普通 TCP 带宽和业务逻辑

在两台内部测试节点之间执行短时 TCP 测试。服务端示例：

iperf3 -s -B 10.20.1.12

客户端示例：

iperf3 -c 10.20.1.12 -P 4 -t 30 -J

10.20.1.12 只是内网地址示例，需要替换成实际测试节点。测试会产生明显流量，必须避开生产高峰，并确认不会与分布式内存服务争抢同一接口。完成后按 Ctrl+C 停止服务端，不保留临时监听。

iperf3 结果较好，只能说明普通 TCP 在这两个节点之间具备一定吞吐能力，并不能证明分布式内存服务没有问题。还要继续看服务自身的序列化、分片、连接池和请求队列。

必要时检查显卡节点间集合通信

如果推理采用张量并行或其他节点间协同方式，并且环境中已经安装了对应的集合通信测试工具，可以在维护窗口执行小规模测试：

NCCL_SOCKET_IFNAME=ens5 \
NCCL_DEBUG=INFO \
./build/all_reduce_perf -b 8M -e 512M -f 2 -g 1

这条命令只适用于已有对应测试程序、接口名称正确且节点配置匹配的环境。它测量的是集合通信，不是分布式内存服务的读写性能。测试期间要记录参与节点数量、显卡数量、接口名称和数据范围，不能把不同节点规模的结果直接比较。

把分布式内存流量纳入带宽预算

分布式内存层最容易出现的问题，是显卡利用率看起来不高，但节点网卡和内存服务队列已经接近上限。我们可以先用一个简单估算确定量级：

所需带宽 ≈ 并发请求数 × 单请求平均读写速率 × 分片或副本放大系数 × 协议开销

例如一组说明用数据是：

• 并发请求：32；
• 每个请求平均读写：18 MB/s；
• 分片、副本和协议形成的综合放大系数：1.2。

计算过程为：

32 × 18 MB/s × 1.2 = 691.2 MB/s

按照十进制单位换算：

691.2 MB/s × 8 = 5529.6 Mbps

也就是约 5.53 Gbps。如果副本策略再使流量翻倍，所需带宽也会接近 11.06 Gbps。这个计算只用于建立预算，实际还要区分读流量、写流量、突发流量和不同分片的热点程度。

建议至少监控以下分布式内存指标：

根据运营商结果选择入口或调整架构

当三个运营商的测试结果已经分开后，我们按以下方式处理。

只有一个运营商路径明显异常。 如果电信探针的 p95 和最终丢包显著高于联通、移动，而香港集群内部读写正常，优先与线路提供方核对该运营商到香港入口的路径、互联位置和端口容量。若已有多个香港入口，可以让该运营商来源的请求进入测试结果更稳定的入口，再通过相同探针复测。

此时不要先增加显卡，也不要降低分布式内存副本数，因为这些动作无法修复大陆到香港之间的路径问题。入口选择应依据一段时间内的 p95、最终丢包、TCP 建连和应用首 token，而不是依据一次 ping 的最低延迟。

三个运营商都异常，但内部网络正常。 这种结果更接近香港入口共同上联、入口节点容量或共同路径问题。我们会核对入口网卡带宽、连接队列、TLS 处理能力和业务高峰时段的出方向流量。如果存在不同接入方案，应使用三个运营商探针做同口径对比。

成本评估也要放在同一张表中，至少包含端口保底带宽、峰值带宽或突发计费方式、是否需要运营商分别接入、入口数量和健康检查成本、跨运营商路径的探针覆盖，以及发生切换时的连接迁移方式。没有连续样本时，不应仅因为某条线路宣传的峰值带宽更高就直接切换。

外部访问正常，分布式内存读写异常。 这时处理重点转为香港集群内部：

1. 让请求尽量固定在持有热点 KV 或上下文的工作节点，减少重复远程读取。
2. 检查分片是否过度集中，必要时重新分散热点分片。
3. 对连接池、单请求并发和在途字节数设置上限，避免少数大请求占满链路。
4. 只有在确认可靠性允许的前提下，评估副本和同步策略；不要为了降低带宽而直接取消必要副本。
5. 将控制信息和大块数据读取分开监控，避免控制面小流量正常掩盖数据面拥塞。
6. 逐项调整，每次只改变一个主要参数，并保留旧值。

配置参数可以按下面的思路建立基线，而不是一开始追求最大并发：

如果外部和内部都正常，但推理仍慢，则应查看模型执行时间、显卡利用率、显存压力和请求排队。此时继续更换大陆运营商路径，通常不会得到有效改善。

验收、失败处理与回滚

处理完成后，我们用相同的三个运营商探针重复 ping、TCP mtr 和应用请求，并在香港集群内部重复 iperf3 或对应的业务级测试。验收至少包含四组对比：

• 运营商维度：p50、p95、最终丢包和 TCP 建连时间；
• 服务维度：首 token、完整响应、超时率和排队时间；
• 内存维度：命中率、远程读取 p95、读写放大和队列长度；
• 集群维度：网卡利用率、重传、GPU 空闲等待和显卡间通信带宽。

例如，前面的模拟场景可以把目标设为：电信探针的 p95 从约 86 ms 降到接近其他运营商水平；分布式内存远程读取 p95 不再随着并发持续上升；入口网卡不再长时间处于高占用；应用首 token 和完整响应时间同步改善。具体阈值应以现有业务基线和服务等级要求为准，不能把某个示例数值当成所有集群的统一标准。

调整过程中如果结果变差，我们按低风险方式恢复：

1. 入口切换后某个运营商更差：立即恢复原入口或原线路，把新入口保留为非主用测试对象，避免同时改动应用和集群内部配置。
2. 增加并发后内存服务排队：恢复上一版连接池、批量大小和在途字节上限，先排空正在处理的请求，再滚动重启受影响节点。
3. 降低副本或改变分片后出现数据不可用：恢复原副本和分片配置，不执行清理缓存或删除数据操作；确认数据一致性后再做小范围测试。
4. 主动带宽测试影响生产：立即停止 iperf3 或集合通信测试，检查测试进程是否退出，并确认网卡流量回到业务基线。
5. 路径探测出现大量星号：不要立即回滚线路，先用最终目标的 TCP 请求和应用指标确认是否真的影响业务。
6. 所有调整都没有改善：恢复原配置，保留前后对比数据，再重新判断瓶颈是在入口、内存层、显卡通信还是模型执行阶段。

配置恢复应采用部署系统中的版本回退或配置副本恢复，变更范围控制在一个入口、一个参数或一组测试节点内。不要在没有备份和维护窗口的情况下直接覆盖生产配置。

回到最初的香港显卡集群场景，我们最终要形成的不是“哪条路径最快”这一句结论，而是一张可复用的判断链：哪个大陆运营商的最终目标指标异常，traceroute 是否提供了可重复的路径线索，应用请求是否同步变慢，香港集群内部网卡和分布式内存是否达到瓶颈，以及调整后其他运营商和内部节点是否保持稳定。只有这些证据指向同一段链路时，才适合切换对应入口；如果证据指向分布式内存东西向流量，就应优先改善数据本地性、分片和并发控制，而不是继续增加外部带宽。