无 NVLink！公网狂飙 30 Tokens/s！仅用 6 张 RTX Pro 6000跑通 744B GLM-5.2

01、背景

在当前大语言模型（LLM）的算力基础设施部署过程中，千卡/万卡（H200、B200、B300）、NVLink、InfiniBand 或 RoCEv2等已经成为千亿参数级别以上的大模型挥之不去的搭配，面对着单台 8 卡 B300 服务器的市面造价已从早期的 400 万人民币推高至1000万元，一批人也在追求高性价比的组网方案上不断探索。

近期我在 GitHub 上无意间浏览到一个名为Shard的开源项目，其 README 中披露的实验数据引起了我的极大好奇：在物理上分散在美国六个不同的州（内华达、得克萨斯、华盛顿、明尼苏达、密苏里、犹他）的7张 NVIDIA RTX PRO 6000成功实现了GLM-5.2 （744B，MoE 架构）大模型的分布式推理，节点间互联未使用任何高速互联总线、未配置 SD-WAN 或专线的纯公网环境下（节点间延迟22 到75 毫秒）跑出了30.55 tokens/s推理速度，好奇其物理组网实现上如何做到的，我对其开源代码和运行回执进行了深度的拆解与学习。

02、基本实现原理与仿真

Shard 仓库中公开的 glm52-nvfp4-wan-20260618.json 运行回执中IP地址与硬件UUID，编制了如下的模拟仿真动态交互图：

图1：Shard引擎异地节点分布式拓扑及硬件配置全局图

如上图，整个架构由 7 块独立的 RTX Pro 6000 显卡分布在六大洲通过公网实现节点间互联，其中位于华盛顿州部署有1张节点协调卡，专门运行基于 CUDA Graph 捕获的轻量级 GLM-4-9B 作为投机解码的基准模型，负责 I/O 调度与网络分发；而另外的6张RTX Pro 6000 显卡作为推理节点用，分散于内华达、得克萨斯、华盛顿、明尼苏达、密苏里、犹他 6 大洲，节点间通过普通公网 IP 进行连接，广域网往返延迟实测在22ms 到 75ms之间，平均承载744B 参数的GLM-5.2 大模型（采用了 NVFP4 量化格式），数据传输未使用隧道技术（如 GRE 或 IPSec VPN），完全依赖公网路由。

03、四大核心特色

那么它又是如何让744B 参数的大模型在公开互联网上以每秒 30 个 token 的速度推理的呢？

1.放弃TP/DP并行，选择PP并行

在 744B 规模下，若采用张量并行（TP），单层前向计算均需产生大规模的 All-Reduce 聚合通信，公网带宽无法满足其吞吐需求。Shard 采用纯流水线并行（PP）策略，将 GLM-5.2 的 78 层 Transformer 切成六段，每段 13 层，分别装在六台位于不同州、通过公网 IP 互通的机器上。正如前文图1所示，协调节点（华盛顿州）只持有 embedding/lm_head 外加一个小型 GLM-4-9B draft 模型。6 个推理节点各自仅临时保留 13 层的模型参数，没有任何单一节点持有完整模型。输入 prompt 生成激活值后，数据像流水线一样在美国地图上跑了一圈：内华达 → 得克萨斯 → 华盛顿 → 明尼苏达 → 密苏里 → 犹他，尾节点算完后直接把结果发回协调节点。这种单向的、流水线式的数据流，从根本上降低了分布式系统对节点间极低延迟的刚性依赖。

2.异步流水线提升管线利用率

即便采用了流水线并行，若按照传统的流水线同步机制，跨越半个美国的数据流转仍会导致严重的资源闲置。为了对比二者的调度差异，图2直观展示了串行同步与异步流水线的执行流转过程。(注：为使动图能清晰展示数据块的流转状态，图中模拟延迟被特意放大设置为了 350ms)

图2_传统串行同步与Shard异步流水线吞吐量对比演示

结合图2中可以看出来，Shard 引入了异步流水线机制，协调节点无需等待前一个数据块返回，即可持续生成并向网络中注入后续的数据块。这种策略实现了网络传输管道的时空复用，使得散布在 6 个州的 GPU 能够在同一微观时间片内，并发处理不同批次的数据。通过这种方式，让系统的性能瓶颈从“网络物理延迟”成功转移至“节点显存带宽吞吐”，使得广域网等待时间在主循环中的占比降至 5% 以下。

3.投机解码与无损状态回滚

为了让异步流水线发挥最大效能，必须结合投机解码技术来增加单次网络通信的信息负载。具体而言，华盛顿州的协调节点利用GLM-4-9B快速生成 K 个预测 Token，将其打包投入异步管线；随后，6 张承载 744B 切片的推理节点卡对这 K 个 Token 进行等价验证。值得注意的是在高并发状态下，当预测发生偏差时，系统如何处理庞大且分散的集群状态一致性问题？

图3：投机解码验证对齐与KVCache指针重置动态演示

(注：此演示的模拟延迟设置为350ms)

如图3演示所示，当GLM-5.2的验证概率分布与预测序列发生偏离（预测断裂）时，算法会接受断裂前的有效前缀，并利用大模型的计算结果强制纠正错误位，从而确保最终输出的数学一致性。 对于最棘手的问题——如何清理沿途节点因预测失败而写入的无效键值缓存（KV Cache），Shard 在底层设计了基于静态地址的“位置张量”。一旦触发图3所示的回滚信号，推理节点无需执行高开销的显存数据擦除，仅需重置读写指针，后续的合法生成数据便会直接覆盖无效缓存。

4.环形直接回传与底层传输协议定制

为进一步压缩回程延迟，系统设计了环形直接返回机制。位于犹他州的尾部节点完成最后一层计算后，无需沿流水线逆向原路返回，而是将结果通过公网1跳直接发送至华盛顿州的协调节点，避免了沿原流水线逐跳逆向传递带来的延迟开销。

出于对公网传输安全性的考量，Shard 重构了底层 wire.py 传输协议——所有跨网激活张量均采用了 ChaCha20-Poly1305 算法及预共享密钥（SHARD_PSK）进行认证加密。更重要的一点是，由于 Python 的 Pickle 反序列化在不受信任的网络中极易引发 RCE（远程代码执行）漏洞，开发了定制化的安全无 Pickle 帧结构。

04、思考与展望

关于7卡RTX Pro 6000（6推理+1协调）项目未来发展的一些个人看法：随着分布式推理架构的成熟，未来的算力网络可深度借鉴 PCDN的逻辑，将散落于微型 IDC 机房、企业边缘节点甚至家庭高配工作站（如 RTX 4090/5090 等消费级显卡）的零散 GPU 资源进行统一编排。通过 P2P 模式整合长尾算力池，有望大幅提高 GPU 利用效率，从而降低大型语言模型的推理边际成本，实现显著的降本增效。例如区块链与 AI 领域的知名项目 Virtuals Protocol已宣布集成 Leyten 的 Shard 引擎，用于支撑其松耦合去中心化 AI Agent 的底层推理需求。当然也可以直接复用于公有云环境，借助云企业网、MPLS VPN、云网POP等来盘活边缘、零散的VPC GPU实例资源，进而优化AI推理成本。

另外，基于公网的分布式推理在工程落地层面仍面临不少的挑战：尽管传输链路具备加密保障，但在计算接力过程中，中间节点仍需解密张量数据进行计算。这意味着部分中间激活状态及用户 Prompt 存在被恶意节点窥探的理论风险。未来需结合可信执行环境技术或边界层路由可信绑定以强化数据安全。由于互联网环境缺乏 SLA 保障，任何单一节点的网络抖动或离线，均会导致整个流水线的断裂。虽说路线图上规划了基于 libp2p 的 NAT 动态打洞机制和节点中继，但在高吞吐要求下，毫秒级状态同步与模型切片的动态重分配仍面临巨大挑战。不过项目也让我们看到过深度的异步调度算法与大模型投机预测机制的结合，证明了在松散的广域网环境中实现模型Scale Out的技术可行性。