550个词元如何决定一座数据中心的网络拓扑

真正昂贵的，往往不是一次推理，而是我们用错误的方式定义了“快”。

如果一个请求平均包含550个输入词元，生成150个输出词元，那么它究竟应该由什么样的芯片、网络和集群来处理？这个问题看似属于性能测试，实际上却会一路追问到系统架构：我们如何切分Prefill与Decode，如何配置显存与算力，甚至如何设计节点之间的网络拓扑。

更关键的是，所谓“典型请求”从来不是一个中立的统计数字。它会把某种软件硬件结构塑造成合理，把另一种结构判定为低效。性能指标不是系统的镜子，而是系统设计的一部分。

一个请求，实际上是两种完全不同的工作

语言模型推理通常被描述成一个连续过程：输入一段文本，然后输出另一段文本。但从计算特征看，它更像一间工厂里先后发生的两道工序。

第一道工序是Prefill。模型一次性阅读550个输入词元，完成大规模矩阵计算，并为后续生成建立KV Cache。这个阶段的核心问题是：如何尽可能快地消化一整段上下文。它更偏向计算密集型任务，适合高算力加速卡，也更容易通过并行计算提高吞吐。

第二道工序是Decode。模型每次只生成一个或少数几个词元，却必须反复读取此前积累的KV Cache。150个输出词元意味着模型要经历大约150轮连续决策。这个阶段不只是“计算少一点”，而是工作性质发生了变化：它更受显存容量、显存带宽和单步延迟影响。

可以把它类比成餐厅厨房。Prefill像是一次性处理一整筐食材，厨师需要大灶、刀具和批量加工能力。Decode像是顾客每隔几秒提出一个小要求，厨房每次只做一道极小的动作，却必须保持前面所有订单状态。前者适合批处理，后者更怕等待和频繁搬运。

因此，使用同一种硬件、同一种网络、同一种资源调度策略同时服务两类工作，并不天然意味着简单高效。它可能只是把两种不同的经济活动强行塞进同一条生产线。

推理系统的真正单位，不是“一个请求”，而是请求在时间轴上经过的不同计算阶段。

这也是Prefill与Decode分离具有吸引力的原因。Prefill子集群可以配置高算力卡，Decode子集群则更重视高显存和高带宽。两者不必完全复制同一套资源，而是按照各自的瓶颈进行专门化。

但专门化并不免费。Prefill完成后，KV Cache需要从一个子集群传给另一个子集群。这就把原本隐藏在单机内部的数据移动，暴露成了网络问题。于是，系统性能不再只由芯片峰值算力决定，而取决于一个更完整的链条：计算、显存、队列、网络，以及请求本身的长度分布。

“典型请求”如何决定一张网络的形状

假设输入长度平均为550个词元，标准差为150个词元，输出长度平均为150个词元，标准差为20个词元。这个统计描述已经透露出一个重要事实：输入上下文的波动明显大于输出长度的波动。

换句话说，系统更难预测的是Prefill负载。一次550词元的请求，可能变成700词元，也可能只有400词元。Prefill的计算量随输入长度增长，KV Cache的规模也随上下文增长。如果调度系统只盯着平均值，就可能在高峰期同时遭遇算力排队和网络拥塞。

而输出长度相对稳定，意味着Decode阶段的工作轮数更容易估计。对在线服务而言，这会形成一种有趣的不对称：输入端的负载更像波浪，输出端的负载更像节拍器。一个好的架构不应只追求平均吞吐，而要问：哪一个阶段的尾部延迟最容易失控？

这里还隐藏着一个常被忽略的问题：词元不是天然单位。不同分词器对同一段文本的切分方式不同。假设同样一句话，在一种分词器中平均每个词需要1.5个词元，在另一种分词器中只需要1.33个词元，那么相同的用户文本会产生不同的计算量、缓存规模和服务成本。

这不是一个无关紧要的测量细节。若系统用某种分词器统计550个输入词元，却用另一种分词器实际运行，那么基准就会出现系统性偏差。一个模型可能因为更高效地编码文本而看起来“处理得更多”，也可能因为词元数量更少而被错误地认为拥有更高吞吐。

因此，性能比较至少要区分三种单位：用户看到的字符或词，模型实际处理的词元，以及硬件真正搬运的字节。只报告每秒生成多少词元，就像只报告工厂每秒生产多少零件，却不说明零件大小、原料重量和运输距离。

**词元数量决定计算工作量，词元分布决定负载波动，字节数量决定网络压力。**这三者不能被一个简单的平均值替代。

从平均吞吐转向“阶段化性能预算”

一个更有用的分析方法，是把一次推理拆成四个连续预算。

第一是阅读预算，也就是Prefill时间。它回答：系统需要多久才能读完输入并建立上下文？这一阶段主要受计算能力、并行策略和输入长度影响。

第二是交接预算，也就是KV Cache从Prefill节点传向Decode节点的时间。若缓存规模为若干GB，网络带宽为100Gbps，理论上每秒可以传输12.5GB数据，但实际还要扣除协议开销、拥塞、内存拷贝和并发竞争。理论带宽不是可用带宽，更不是稳定的端到端延迟。

第三是逐词生成预算，也就是Decode阶段每个词元的生成时间。用户感知的“响应流畅度”往往由这里决定。即使Prefill很快，如果Decode每一步都因为显存读取或排队而延迟，整体体验仍然会很差。

第四是排队预算。在线服务最容易犯的错误，是只测量设备真正计算的时间，却忽略请求在队列中等待的时间。Prefill和Decode共享资源时，长上下文请求可能占住高算力设备，使短请求也被拖慢。分离式架构的价值之一，正是允许两类队列独立扩缩容。

可以把总延迟写成一个简单的概念模型：

总响应时间 = Prefill时间 + KV Cache交接时间 + Decode时间 + 排队时间。

这个公式并不复杂，但它改变了优化顺序。若KV Cache交接只占总耗时的百分之几，增加昂贵的RDMA网络可能没有意义。若交接时间在高并发下迅速成为主要部分，那么再快的GPU也只是把更多数据更快地送到拥堵的桥头。

由此可以得到一个重要判断：网络拓扑应当由工作负载的流向决定，而不是由训练集群的惯性决定。

训练通常需要大量节点之间近似全互联，因为参数、梯度和激活值会在广泛的节点组合之间交换。Prefill与Decode分离后的推理则可能呈现完全不同的流量结构：Prefill节点只需要向部分Decode节点发送KV Cache，通信主要发生在两个子网之间，而不是每个节点和所有节点之间。

这就产生了类似二分网络的结构。Prefill子网内部可以使用相对适中的互联，Decode子网内部也未必需要训练级别的全互联，真正需要高带宽和低延迟的，是两个子网之间的连接。N对M的偏序互联，可能比每个节点都互相直连更节省交换机和布线成本。

然而，拓扑节省的前提是流量确实具有这种偏序性。如果调度器不断把任意Prefill实例的缓存发送给任意Decode实例，所谓的二分结构仍然可能在边界处形成拥塞。架构设计因此不能先画网络图，再要求业务适应它，而应先观察请求如何流动，再决定哪些连接值得昂贵。

真正的优化对象，是“信息移动”

在大模型系统中，人们常常从峰值算力开始讨论硬件。某张卡有多少浮点计算能力，另一张卡有多少显存，某种互联协议理论上有多高带宽。这些数字有用，但它们没有回答最核心的问题：一次请求的信息，究竟被移动了多少次，移动到哪里，为什么必须移动？

Prefill与Decode分离让这个问题变得无法回避。KV Cache本质上是已经处理过的上下文状态。如果它留在原节点，Decode就必须在原节点继续进行。如果把Decode迁移到另一组节点，就必须把状态一起搬过去。迁移的收益是资源可以专门化，代价是状态需要跨网络旅行。

这像是医院把诊断科和治疗科分设在不同院区。专业化可以提高设备利用率，但如果每位病人都要携带完整病历在两院之间往返，交通成本就会吞噬专业化收益。最好的方案不是盲目合并或盲目拆分，而是比较两种成本：让不匹配的设备长期闲置，和让状态跨网络移动。

可以进一步提出一个“专门化收益阈值”：

只有当分离后节省的计算与显存成本，大于KV Cache交接和额外排队带来的成本，分离式推理才真正成立。

这个阈值会随请求长度、并发度和模型结构变化。短输入、短输出的请求可能根本不值得跨节点迁移。长上下文、多轮对话或高并发服务，则更可能从专门化中获益。也就是说，Prefill与Decode分离不是一种普遍真理，而是一种依赖工作负载的经济决策。

这也解释了为什么固定的“典型请求”可能具有误导性。平均输入550词元、平均输出150词元，适合建立一个可复现的基线，却不足以决定所有生产系统的架构。代码补全、客服问答、长文档分析和智能体调用，会产生完全不同的输入输出分布。

更可靠的做法，是把基准从一个点扩展成一组工作负载画像。例如：短输入短输出、长输入短输出、短输入长输出、长输入长输出，再分别观察吞吐、首词延迟、每词延迟、尾部延迟和网络流量。这样测出的不是一个漂亮的平均数字，而是一张架构决策地图。

关键行动清单

1. 同时记录三种长度：用户文本长度、模型词元长度、KV Cache字节大小。不要用其中任何一个替代另外两个。

2. 把Prefill和Decode分别压测：分别测量首词延迟、每词延迟、吞吐、显存占用和队列等待时间，避免一个阶段的平均值掩盖另一个阶段的瓶颈。

3. 用分布而非单一平均值做容量规划：至少加入输入长度和输出长度的标准差，并单独观察高分位请求，例如第九十五和第九十九百分位。

4. 先测量KV Cache交接，再决定网络规格：计算理论带宽只是起点，还要验证并发传输、协议开销、内存拷贝和拥塞条件下的有效带宽。

5. 让路由策略配合拓扑：如果采用Prefill与Decode分离，应尽量让缓存流量具有稳定的N对M映射，避免把一个节省交换机的偏序网络使用成隐形的全互联网络。

结语：基准测试其实是在选择未来

大模型推理的竞争，表面上是芯片速度的竞争，深层却是对工作负载的解释权之争。你把请求定义成多少词元，把输入和输出看成怎样的分布，把首词延迟和总吞吐放在什么位置，都会进一步影响硬件采购、网络拓扑和软件调度。

因此，“哪个系统更快”并不是一个脱离语境的问题。更准确的问题是：在什么请求分布、什么服务目标、什么信息移动成本下，它更快？

一旦接受这个视角，性能工程就不再只是寻找更大的芯片或更快的网络，而是重新安排信息的旅程。最好的系统，不一定拥有最强的单个组件，而是让每一段上下文只在必要的时候移动，让每种硬件处理最适合自己的阶段，让指标忠实反映真实用户体验。

最终，真正值得优化的不是每秒钟生成多少词元，而是每个词元为了出现，究竟被迫穿越了多少不必要的计算、缓存和网络。