ShardFlow把跨云推理跑到28 TPS

ShardFlow 最近公布了一组跨云、跨区域的大模型推理测试：两台位于不同 GCP 区域的 NVIDIA T4，通过公网 WAN 拆分运行 Qwen2.5-7B，在约 86ms 往返延迟下达到 28.10 TPS 峰值和 20.31 TPS 平均吞吐。

这里的 TPS（tokens per second）是每秒生成的 token 数，通常用于衡量大模型解码阶段的输出速度。这个数字单独看并不算惊人——单机高端 GPU 跑 7B 模型往往可以更快——但它的意义在于：ShardFlow 没有把模型完整放在一台机器或同一机房，而是把模型拆到两个相隔数百公里、通过公网连接的 GPU 节点上。

这类结果对大模型基础设施更有启发性。过去，跨节点张量并行通常默认节点之间有 InfiniBand、NVLink 或至少是同一云区域内的高速网络；一旦把通信链路拉到跨地域公网，网络往返延迟就可能把每一个生成 token 都变成一次等待。ShardFlow 的做法不是消灭 WAN 延迟，而是把延迟从“每个 token 一次”改造成“每轮生成一次”。

关键数据：28.10 TPS 峰值，平均值更值得看

ShardFlow 的核心测试使用了两台位于 GCP Iowa 和 Oregon 区域的 T4 GPU 节点，并通过 AWS EC2 Ohio 中继建立 TCP 连接。 测试在公网链路上完成，端到端 RTT 约为 86ms。根据项目作者在 Reddit 发布的测试结果，Qwen2.5-7B 的表现如下：

| 配置 | Qwen2.5-7B 结果 | 相对非推测基线 | 说明 | |---|---:|---:|---| | 非推测解码 | 4.92 TPS | 基线 | 每轮主要推进一个 token | | 神经推测解码，Eager 模式 | 14.3 TPS 峰值 | 约 2.9 倍 | 草稿模型先预测多个 token | | 神经推测解码 + CUDA Graphs | 28.10 TPS 峰值 | 约 5.7 倍 | 降低 GPU kernel 调度开销 | | 神经推测解码 + CUDA Graphs | 20.31 TPS 平均 | 约 4.1 倍 | 比峰值更接近稳定运行状态 |

20.31 TPS 的平均值比 28.10 TPS 峰值更能说明系统的实际价值。 峰值往往出现在特定 prompt、较短上下文或缓存状态理想的场景中，而平均吞吐会受到草稿 token 接受率、上下文长度、显存压力和通信抖动影响。以平均值计算，系统相较 4.92 TPS 的非推测基线提升约 4.13 倍；以峰值计算，提升约 5.71 倍。

作者还在同样的两节点配置上测试了 Qwen2.5-14B，并使用 NF4 四比特量化，平均达到 14.43 TPS。NF4（NormalFloat 4-bit）是一种面向神经网络权重分布设计的四比特量化格式，能够用更少显存承载更大的模型，但通常需要在精度、解码速度和算子支持之间做权衡。

| 模型 | 量化方式 | 节点配置 | 平均或峰值结果 | |---|---|---|---:| | Qwen2.5-7B | 未特别说明 | 两台 T4，跨 GCP 区域 | 28.10 TPS 峰值 / 20.31 TPS 平均 | | Qwen2.5-7B | 非推测基线 | 两台 T4，跨 GCP 区域 | 4.92 TPS | | Qwen2.5-14B | NF4，4-bit | 两台 T4，跨 GCP 区域 | 14.43 TPS 平均 |

它是怎么把 WAN 延迟摊薄的

神经推测解码是一种先由小模型批量猜测、再由目标模型并行验证的解码方法。 在传统自回归生成中，目标模型生成一个 token 后，才能把它放回上下文继续生成下一个 token。只要模型切分在两台机器上，每个 token 都可能触发一次跨节点通信，86ms RTT 很快就会成为吞吐上限。

推测解码把过程改成了两步。首先，草稿模型一次预测一串候选 token；随后，目标模型对这一串候选进行验证，并接受其中通过验证的部分。若一次往返能够确认多个 token，那么网络只需要为“一轮推测—验证”支付一次延迟，而不是为每个 token 单独支付一次延迟。

ShardFlow 测试中使用 K=8 的推测长度，每次往返平均提交约 4.07 个 token。 这里的 4.07 可以理解为每一轮实际被目标模型接受的 token 数，而不是草稿模型盲目生成的 8 个 token。由于部分候选会被拒绝，接受数必然小于 K；但只要平均接受数显著高于 1，WAN 延迟就不再线性叠加到每个 token 上。

用一个简化模型可以看出它的意义。假设每轮固定承担约 86ms 的网络往返时间：

• 每轮只确认 1 个 token，理论网络等待上限约为 11.6 token/s；
• 每轮确认 4.07 个 token，理论上可把网络等待摊到约 47.3 token/s；
• 实际速度还要扣除目标模型计算、草稿模型计算、拒绝重算和调度开销，因此最终平均为 20.31 TPS。

这不是说推测解码凭空创造了算力，而是把原本串行的等待改成了更粗粒度的批处理。对于跨区域部署，真正关键的指标也不只是带宽，而是 RTT、草稿 token 接受率以及每轮计算能否被稳定执行。

CUDA Graphs解决的不是网络，而是“发令枪”

CUDA Graphs 是一种把一组 GPU 操作预先捕获并整体重放的执行机制，主要用于减少重复 kernel 启动和 CPU 调度开销。 它不会降低物理网络延迟，也不会改变模型参数量，但可以让推测解码器在每一轮中更少地等待 Python 和 CPU 发起 GPU 操作。

ShardFlow 作者在 v2.1 版本中发现，草稿生成阶段此前每轮会通过 Python 循环启动约 1500 个 CUDA kernel。单个 kernel 的执行时间只有约 2—5 微秒，真正的问题却是启动这些 kernel 的过程：每次调用都要经过 Python、框架运行时和 CUDA 调度路径。单次开销看似很小，累积到 1500 次后，就足以吞掉推测解码本应带来的收益。

这也是为什么 Eager 模式的峰值为 14.3 TPS，而加入 CUDA Graphs 后峰值提升到 28.10 TPS。两者使用的是同一套跨区域通信条件，性能差距主要来自草稿生成阶段的执行方式，而非网络突然变快。

ShardFlow 的案例说明，跨节点推理的瓶颈常常不是单一环节，而是网络、kernel 调度和 Python 控制流共同形成的“长尾”。 当 GPU 算力越来越便宜或被拆分到更多节点时，频繁的小算子启动会像快递分拣一样：每个动作只花几微秒，但大量动作之间的等待和协调最终主导总耗时。

与传统多机推理相比，ShardFlow的取舍是什么

传统张量并行更适合低延迟、高带宽的节点互联，而 ShardFlow 的路线更像是用算法换取跨区域资源弹性。 在 vLLM、SGLang、TensorRT-LLM 等主流推理栈中，多机部署通常围绕张量并行、流水线并行、数据并行和 KV Cache 管理展开，默认目标是把通信放在同一集群的高速网络内。

张量并行会把一个层内的矩阵计算拆到多个 GPU，再通过 All-Reduce 或 All-Gather 合并结果。它的优点是能让多张 GPU 共同承载一个模型，缺点是通信频率高；一旦链路从机房内网络变成公网 WAN，每次同步的固定延迟都会被放大。

流水线并行则把不同模型层放到不同节点上。它可以减少某些同步频率，但会引入阶段间的数据传递和气泡问题，尤其是在单请求、低并发场景中更明显。ShardFlow 的“把任意 Hugging Face Transformer 拆到 N 台 GPU 机器”思路，实质上是在模型切分和推测解码之间做协同：前者解决显存和算力分布，后者解决 WAN 上的串行等待。

| 方案 | 主要并行方式 | 对网络的要求 | 更适合的场景 | 主要代价 | |---|---|---|---|---| | ShardFlow | 模型跨节点切分 + 神经推测解码 | 可容忍较高 RTT，但依赖稳定链路 | 跨云、跨区域、低成本 GPU 拼接 | 接受率和调度逻辑较复杂 | | 张量并行 | 层内矩阵切分 | 高带宽、低延迟，最好使用专用互联 | 同机或同集群大模型推理 | 跨 WAN 时通信成本高 | | 流水线并行 | 按层切分模型 | 需要稳定的阶段间传输 | 超大模型、多请求流水线 | 存在 pipeline bubble | | 数据并行 | 每个节点运行完整副本 | 节点间主要同步请求和状态 | 高并发、服务副本扩展 | 单节点必须装下完整模型 |

ShardFlow 不是 vLLM 或 SGLang 的直接替代品，而是针对“手里有分散 GPU、但没有高速互联”的另一种解法。 如果企业已经拥有同一机房的 H100、NVLink 或 InfiniBand 集群，传统张量并行通常更简单、更稳定；如果资源分散在多个云区域，或者需要临时拼接低价 T4、L4 等 GPU，ShardFlow 的价值才会真正显现。

28 TPS并不等于线上体验已经解决

这组结果目前更像是一个有说服力的工程原型，而不是已经完成生产验证的推理平台。 参考资料来自项目作者在 Reddit 机器学习社区发布的自测结果，现阶段需要把它理解为单一环境下的 benchmark，而不是经过第三方复现的统一评测。

首先，测试模型规模为 7B 和 14B，不能直接推导到 70B、百亿级 MoE 或多模态模型。模型越大，跨节点切分后的中间激活、KV Cache 和同步数据越可能成为瓶颈；量化虽然能降低显存占用，但不同 GPU 架构对 NF4、融合算子和低精度计算的支持也会影响结果。

其次，峰值 TPS 与首 token 延迟（TTFT）不是同一个指标。TTFT 是从请求发出到第一个 token 返回的时间，受到模型加载、prefill、上下文长度和网络连接建立影响；TPS 通常主要反映 decode 阶段的持续生成速度。一个系统可以在长文本生成中达到较高 TPS，却在短问答中因为跨区域握手和 prefill 成本显得迟缓。

再次，推测解码的收益高度依赖草稿模型与目标模型的匹配程度。若草稿模型预测质量高，单轮接受 token 数就高；若用户输入分布变化大、代码补全或结构化输出约束较强，接受率可能下降。K=8 不是越大越好：K 太小，无法充分摊薄 RTT；K 太大，则会增加草稿计算、验证成本和被拒绝 token 的浪费。

最后，公网 WAN 的抖动、丢包、带宽波动和中继节点故障都可能改变结果。测试中使用 AWS EC2 Ohio 作为 TCP relay，说明作者需要通过第三方中继改善或稳定两地节点之间的连接，但生产环境还要考虑中继带宽费用、故障转移、加密、数据驻留和跨境合规问题。对于真实业务，平均 TPS、P95/P99 延迟、断链恢复时间和单位 token 成本，往往比一次峰值跑分更重要。

它对多云推理有什么现实价值

ShardFlow 最值得关注的地方，是它把“跨云 GPU 拼接”从成本优化问题推进成了调度和解码协同问题。 多云部署的吸引力并不只是规避单一云厂商故障，还包括在不同区域寻找更便宜或更容易获得的 GPU 资源，以及根据流量和合规要求动态调整推理位置。

传统做法往往是每个区域部署完整模型副本，再通过路由层将请求分发到最近的节点。这种架构对在线服务更稳妥，但模型副本会带来显存和存储成本，冷启动也更重。模型切分则允许多个区域共同承载一个模型，但通信复杂度和故障域随之上升。ShardFlow 试图通过推测解码，降低这种切分对交互速度的影响。

对于以下场景，它可能比“每个区域一份完整副本”更有吸引力：

1. GPU 资源碎片化。 不同云厂商或区域只有零散的 T4、L4 等卡，单点资源无法完整承载目标模型。
2. 低并发或实验性服务。 流量不足以支撑每个区域独立部署完整副本，但又希望利用闲置 GPU。
3. 模型规模略超单节点显存。 通过跨节点切分和 4-bit 量化，把 14B 或更大模型放入现有资源池。
4. 多云成本调度。 根据 GPU 价格、可用库存和区域网络质量选择计算节点。
5. 容灾与弹性。 在某个区域资源不足时，将模型的部分计算迁移到其他区域，但需要额外设计故障切换策略。

不过，跨区域推理并不能绕开数据合规要求。 用户 prompt、上下文和生成结果可能经过多个国家或地区的计算节点与中继。阿里云百炼 2026 年 6 月更新的地域与服务部署文档也将接入地域、推理执行范围和数据驻留边界明确区分，说明多地域推理首先是合规和架构问题，其次才是性能问题。涉及医疗、金融、企业源代码或个人信息时，不能因为 GPU 价格更低就默认把请求发送到全球资源池。

OpenAI Hub判断：方向成立，但离通用基础设施还有距离

我们的判断是，ShardFlow 的技术方向成立，最有价值的创新不是“28 TPS”这个数字，而是证明高 RTT 网络下仍可以通过推测解码和 GPU 执行优化保住可用吞吐。 它击中了当前大模型基础设施中的一个真实矛盾：高端 GPU 集群越来越集中，但中小团队和实验项目手里的算力却越来越碎片化。

从工程角度看，v2.1 对约 1500 个 kernel 启动的优化尤其值得重视。很多推理系统的性能问题并不发生在模型结构本身，而发生在框架调度、动态 shape、Python 循环和小算子碎片上。CUDA Graphs 在这里不是锦上添花，而是让推测解码从“理论上能摊平网络延迟”变成“实际能把计算跑起来”的关键一环。

但我们不会把它解读成“公网也能替代高速互联”。对于高并发、多租户、严格 P99 延迟的生产服务，单请求跨区域拆分仍然会带来复杂的故障处理、流量调度和成本核算；对于 70B 以上模型，推测器训练、激活传输、KV Cache 一致性和动态批处理也需要更多公开数据支撑。

下一步真正值得观察的不是更高的峰值，而是 ShardFlow 能否公开代码、复现脚本和完整指标，并在不同 RTT、上下文长度、并发数与模型规模下稳定工作。 如果它能在 50—150ms RTT、长上下文和多请求场景中保持可预测的 P95 延迟，同时把节点故障恢复和安全传输纳入框架，才有机会从个人工程实验成长为多云推理基础设施。

截至 2026 年 8 月 23 日，这项测试最准确的结论是：跨云区域分布式推理并非只能依赖专用高速网络，算法级的 token 批处理和系统级的 GPU 调度优化，也能把公网 WAN 的延迟成本压到可接受范围；但 28.10 TPS 仍应视为基准测试中的峰值，而不是对所有模型和线上业务的承诺。