当网络成为计算：大模型推理的真正瓶颈正在从 GPU 转向请求路径

真正决定大模型推理效率的，可能不是 GPU 的峰值算力，而是一个更容易被忽略的问题：当一次请求被拆成多个阶段、分布到不同机器上之后，网络究竟还是基础设施，还是已经变成了计算本身的一部分？

在传统服务器里，网络通常是连接计算资源的管道。计算完成后，数据经过网络送到下一个节点，网络越快越好，但它很少决定程序的基本结构。然而在大模型系统中，这种关系正在倒转。Prefill 与 Decoder 被拆开，Cache 在节点之间流动，数千张 GPU 通过高速互联共同完成一次请求。此时，网络不再只是传输数据，它开始参与决定哪些计算能够发生、何时发生，以及系统能否兑现延迟承诺。

这带来一个重要判断：智算中心的核心竞争力，不是单独堆叠更强的 GPU 或更快的网络，而是把计算分工、内存带宽、通信路径和服务目标统一成一个调度系统。

当模型推理从一条流水线变成一座城市

理解这一变化，可以先看一次典型的生成请求。用户输入一段很长的文本，系统首先需要读取全部上下文并计算出中间状态，这一阶段是 Prefill。随后，模型逐个生成新 Token，这一阶段是 Decoder。

两者看起来都在执行神经网络计算，但它们的资源需求并不相同。Prefill 通常具有更强的并行性，适合配置计算能力更强的 GPU。Decoder 则更像一辆不断启停的配送车，每生成一个 Token，都要反复读取模型参数和 KV Cache，因此往往更加受制于显存带宽，而不是乘法计算能力。

如果用餐厅来比喻，Prefill 像一次性准备一桌大型宴席，需要很多厨师同时处理食材。Decoder 则像根据客人的每一次追加要求逐道上菜，关键不是厨房能在一秒钟切多少菜，而是食材能否持续、快速地从仓库送到灶台。让同一类 GPU 同时承担这两种工作，往往意味着资源错配：计算型 GPU 在 Decoder 阶段可能等待内存，带宽型 GPU 在 Prefill 阶段又无法充分发挥。

因此，分离式架构的价值并不只是把系统拆成两部分，而是承认一个事实：不同计算阶段有不同的瓶颈，统一配置反而会制造浪费。

但拆分也会引入新问题。Prefill 产生的中间状态需要送往 Decoder，Cache 需要被复用，任务需要在不同 GPU 池之间迁移。原本隐藏在单机内部的数据访问，变成了跨服务器、跨交换机，甚至跨网络层级的数据流动。架构获得了资源匹配能力，却支付了通信成本。

这就是分离式架构的第一重悖论：它通过拆分减少计算浪费，却可能通过通信增加系统延迟。

五微秒为什么可能比一张更强的 GPU 更重要

在多机多卡环境中，通信延迟不是一个孤立的网络指标，而是模型执行路径上的固定成本。传统 TCP/IP 网络的数据需要经过操作系统内核协议栈，应用程序发起一次通信后，数据往往要经历内核处理、内存拷贝和协议调度等步骤。RDMA 的关键价值，是让一台主机能够绕过内核协议栈，直接访问另一台主机的内存。

实验中的典型数字非常有启发性：同一集群内部一跳可达时，传统 TCP/IP 的应用层端到端延迟可能约为 50 微秒，RoCE 可以降到约 5 微秒，InfiniBand 则可降到约 2 微秒。单看一次通信，这些数字似乎都很小。但大模型推理并不是只通信一次。

假设一次请求需要进行数百次跨节点交互。即便每次只增加 20 微秒，累计起来也可能达到数毫秒。对于追求首 Token 延迟的在线服务，这已经足以改变用户感知。更重要的是，通信延迟还会造成排队效应：一个阶段等待数据，后续阶段无法启动，其他请求则继续占用队列和缓存。于是，局部的几十微秒，可能被系统放大成整体吞吐和尾延迟的显著恶化。

可以把这种现象称为通信复利：

在分布式推理中，网络延迟的代价不等于单次延迟乘以通信次数，还要加上等待、排队、缓存失效和资源空转所产生的间接成本。

这解释了为什么网络架构会直接影响模型服务的经济性。更强的 GPU 只有在数据及时到达时才能持续计算。如果 GPU 因为等待 Cache 或参数而空闲，那么账面上的算力就没有转化成有效吞吐。对于高成本的加速卡来说，一张 GPU 的等待，本质上就是一笔昂贵的闲置费用。

从这个角度看，2 微秒与 50 微秒的区别，并非只是网络工程师的性能对比，而是系统是否能够把昂贵的计算资源保持在工作状态。

网络选择不是设备采购，而是调度哲学

在高性能集群中，InfiniBand 与 RoCEv2 代表了两种不同的系统取向。

InfiniBand 更像一个从一开始就为高性能计算设计的封闭交通系统。它不依赖传统路由协议，网络转发表由集中式的 Subnet Manager 计算并下发，连同分区和 QoS 一起进行管理。其 Adaptive Routing 还能够根据网络状况进行逐包动态路由，在大规模 GPU 集群中尽量避免局部拥塞。

这种设计的优点，是系统目标明确，路径控制集中，性能更容易被塑造成一种可预测的能力。代价则是专用设备、专用线缆、专用管理体系，以及较强的供应商集中度。对于需要建设万卡级集群的组织，这种专用化可能是获得稳定性能的合理成本。

RoCEv2 则更像是在现有城市道路上改造出高速货运通道。它能够运行在以太网络之上，通用性更强，价格也可能更低，设备供应商选择更广。但要让它稳定承载 RDMA 流量，需要精细配置 Headroom、PFC 和 ECN 等参数。一个看似普通的交换机配置错误，就可能在高负载时引发拥塞扩散、队头阻塞或丢包重传，最终让低延迟承诺变成偶发性的运气。

这两种方案的差异，表面上是技术路线之争，深层则是可预测性与通用性的权衡。如果系统的调度器把 Prefill 产生的 Cache 大规模发送给 Decoder，网络性能的平均值并不够。调度器真正需要的是尾部延迟、拥塞概率、路径稳定性，以及在高峰期间仍能否完成服务等级目标。

换言之，网络架构应当根据调度问题选择，而不是根据峰值带宽选择。一个标称 400Gbps 的网络，如果在大量 Cache 迁移同时发生时出现严重抖动，可能不如一个峰值略低但行为稳定的网络。对于 SLO 约束下的在线推理，最重要的指标通常不是“最快时刻有多快”，而是“最差的一批请求是否仍然可控”。

Cache 不是数据，而是未来的计算机会

分离式推理中最值得重新理解的对象，是 KV Cache。它看起来只是中间数据，实际上更接近一种可交易的计算期权。

Prefill 阶段如果能够复用已有 Cache，就不必重复处理相同的上下文，首 Token 延迟和计算成本都会下降。Decoder 阶段如果能够快速获得所需 Cache，就能持续生成 Token，避免 GPU 因等待数据而停顿。因此，Cache 的价值不仅由大小决定，还由位置、有效期、访问概率和传输成本共同决定。

一个简单的 Cache 决策可以写成四个问题：

1. 这个 Cache 未来被再次访问的概率有多高。
2. 如果留在本地，需要占用多少宝贵的 HBM 空间。
3. 如果迁移到远端，网络传输会占用多少时间和带宽。
4. 请求的 SLO 是否允许这次迁移发生。

这意味着调度器不能只看 GPU 利用率。两个 GPU 池即使利用率都为 70%，系统状态也可能完全不同。一个池的 Cache 命中率高、网络距离近、请求尾延迟稳定，另一个池则不断在跨交换机迁移大块状态。前者可能是真正高效的系统，后者只是把瓶颈从计算利用率隐藏到了网络和队列中。

因此，可以引入一个更有用的指标：有效算力密度。它不是设备提供的理论 FLOPS，而是单位时间内，在满足 SLO 的前提下完成的有效 Token 数。有效算力密度同时受到四类因素影响：计算能力、内存带宽、通信延迟和调度命中率。

这也解释了为什么在 Decoder 阶段使用算力相对较弱但显存带宽更大的 GPU，可能比简单增加高算力 GPU 更合理。因为系统优化的对象已经从“单次矩阵计算速度”转变为“整个生成链路中每个 Token 的稳定产出速度”。

真正的架构单位，是一条带有预算的请求路径

如果把上述因素合在一起，可以建立一个简单的分析框架：每个请求都有一条从输入到输出的路径，而这条路径拥有四种预算。

第一是计算预算。 Prefill 和 Decoder 分别需要多少计算资源，是否应该使用不同 GPU 池。

第二是内存预算。 模型参数、KV Cache 和中间结果如何分布，哪些数据必须驻留 HBM，哪些可以放到远端或更低层级存储。

第三是通信预算。 一次请求允许发生多少次跨节点传输，每次传输经过几跳，是否会与其他大流量任务竞争链路。

第四是服务预算。 首 Token 延迟、每 Token 延迟、吞吐量和尾延迟之间如何排序，哪些请求可以延后，哪些请求必须抢占资源。

过去的基础设施设计，常常分别优化这四种预算。网络团队关注吞吐和丢包，GPU 团队关注利用率，推理团队关注 Token 速度，平台团队关注成本。但分离式架构要求它们共同面对同一个问题：一条请求路径的瓶颈在哪里，瓶颈移动后谁来负责重新调度？

例如，在低负载时，跨节点发送 Cache 可能完全没有问题。高峰到来后，网络拥塞使传输时间增加，Decoder 队列开始堆积。此时继续按照原来的策略分发任务，表面上仍然拥有足够 GPU，实际上已经进入了通信受限状态。更成熟的系统应该识别这种状态，并采取动作：提高 Cache 复用权重，减少远端迁移，调整请求优先级，限制高成本长上下文请求，或者把部分任务转移到带宽更合适的 GPU 池。

这正是 SLO 视角的意义。SLO 不是监控面板上的一个数字，而是调度器用来分配稀缺资源的约束条件。

最好的调度不是让每个阶段都尽可能忙，而是让整条请求路径在最重要的时间边界内完成。

Key Takeaways

1. 先按瓶颈划分计算阶段，再决定 GPU 配置。 Prefill 更偏计算和并行，Decoder 更容易受显存带宽和 Cache 访问影响。不要用单一的 GPU 型号覆盖所有阶段。

2. 把网络延迟纳入模型服务的核心性能模型。 统计跨节点通信次数、平均跳数、P95 和 P99 延迟，而不只看峰值带宽。每一次 Cache 迁移都应当被视为请求路径上的真实成本。

3. 以 SLO 驱动网络选型。 如果业务要求大规模集群下的稳定尾延迟，InfiniBand 的专用化和可预测性可能更有价值。如果需要兼容既有以太网并控制成本，RoCEv2 可以成为选择，但必须把拥塞控制和参数治理当成系统工程，而不是设备开箱即用的功能。

4. 建立 Cache 的位置感知调度。 Cache 命中概率、GPU 的 HBM 压力、网络距离和请求优先级应该共同决定数据放在哪里，而不是简单地追求本地化或平均分布。

5. 用有效算力密度替代理论算力衡量系统。 真正应该关注的是在满足 SLO 的条件下，每秒完成多少有效 Token，以及有多少 GPU 时间被通信等待、队列阻塞和 Cache 失效吞噬。

结语：未来的 GPU 集群更像一台分布式计算机

分离式推理并没有让计算和网络各自变得独立，恰恰相反，它让两者更加紧密地耦合在一起。Prefill 与 Decoder 的拆分，把不同类型的计算暴露出来；RDMA 和高速互联，则把原本隐藏的通信成本暴露出来。Cache 的流动进一步证明，数据位置本身已经成为性能决策。

因此，下一代智算中心不应被理解为一排排 GPU 加上一张高速交换网络。它更像一台被拆散到机架、交换机和调度器中的巨型分布式计算机。GPU 是执行单元，HBM 是近端记忆，RDMA 网络是跨节点总线，调度器则决定这台机器每一时刻究竟在执行什么。

当我们不再问“哪种 GPU 最快”或“哪种网络带宽最高”，而开始问“哪条请求路径在 SLO 内最稳定，哪种数据移动最值得发生”，基础设施设计就进入了新的阶段。

真正高效的系统，不是让每一块芯片都达到峰值，而是让计算、内存和网络之间几乎没有无意义的等待。未来的大模型竞争，最终可能不是算力规模的竞争，而是谁能把等待本身压缩成一种可调度、可预测、可定价的资源。