推理中的计算与数据搬运：MoE 如何改变服务结构
Computation and Data Movement for Inference
MoE 已在前沿模型中广泛使用，它改变的不只是参数量，而是每个 token 激活哪些张量、哪些数据必须就近放置、哪些传输需要高本地带宽。文章把推理拆成 Prefill、Midfill、Decode attention、Decode experts 四个阶段，指出四者对计算、内存与网络的需求各不相同，统一当作同一负载会丢掉 MoE 的结构性优势。
译文尚不完整，完整内容请切换到原文。
混合专家（Mixture of Experts）如今已广泛用于前沿模型，它改变了服务的结构，也改变了有用推理的经济性。它不只是增加了参数数量。它改变了每个 token 激活哪些张量、哪些必须保持紧密相邻、哪些传输需要强本地带宽、哪些可以容忍较弱的网络链路，以及内存移动、存储和调度如何贡献于有效吞吐量。
最好的起点是把服务作为一个整体来看。推理运行在一个由编排层协调的集群内，例如 NVIDIA Dynamo、Mooncake 或自定义调度器。这些编排层与 vLLM 或 SQlang 等推理服务器紧密协作，而这些推理服务器也有自己的编排功能。本文不会深入探讨如何使用编排软件或你应该选择哪一个。本文旨在概述这一过程，以及你可能用到的各种功能背后的原因。
用户（或其代理）以请求（查询）开始一段对话，对话在得到回答后可能继续提出更多请求。请求-回答构成一个“轮次”。在现代 AI 系统中，用户通常运行在客户端应用（无论是 GUI 还是命令行导向）中，而 AI 返回的某些回答会被该应用截获，作为要执行的指令，比如编辑你的代码或就 HR 问题搜索你公司的准则。
AI 系统也可以从自己的数据中心自行完成其中一些事情，例如它可能搜索网络。这些截获的工具操作的结果也会作为请求返回给 AI，从而产生更多轮次。服务器会保留一个上下文（通常称为 KV 缓存或简称缓存），它是会话的提炼，使来自用户或工具的每个新请求都能被正确解释，以推动整体进展。当用户启动一个代理执行长时间运行的任务时，每小时可能有数千个轮次。对话也可以暂停，并在数小时甚至数天后恢复。
当请求到达推理服务器时，编排会将其放入队列，随后连同系统提示和对话中先前轮次的任何上下文一起送入输入填充（input-fill）工作器。查询随后被转换为追加到对话中的新上下文。该新上下文状态随后被移动到解码（decode）工作器。解码会反复读取累积状态，生成回答 token，这些回答 token 也会追加到对话状态中。该过程可能在工具、代理、用户和进一步的输入填充工作之间循环。在 GPU 上运行的模型工作器只是这个 token 工厂的一部分；存储、网络和编排连接着它的各个阶段。
在工作器内部，有四种运行模式值得从一开始就加以区分：
预填充（Prefill），即初始的新 token 块被一起处理。
中填充（Midfill），即续接请求被追加到已有的缓存上下文。
解码注意力（Decode attention），即利用上下文生成新生成 token 的基础部分。
解码专家（Decode experts），即每个基础新 token 由从大量可能专家中选出的一组专家来精炼。
这些模式对计算、内存和网络提出了不同的要求。Prefill 和 Midfill 密切相关，Prefill 就是上下文为零的 Midfill。不过，Prefill 是一种常见的特殊情况，对应于一次性查询，比如经典的“聊天机器人”用法，并且可以比 Midfill 进行略微不同的优化。Prefill 达到高算术强度（计算与数据移动的比率），并且不需要等待上下文被定位和读取。Midfill 从已有状态的现有 KV 缓存开始，并追加新的请求输入序列。这通常比 prefill 具有更适中的算术强度，因为新 token 更少，而每个 token 需要移动的现有数据更多。
解码注意力和解码专家工作通常算术强度较低，因为与先前的上下文或专家权重相比，新 token 很少，而在解码状态下，这些权重是需要移动的数据。同时，在所有这些过程中，注意力和专家的张量无论 token 值如何都是相同的，因此，将一次张量读取与尽可能多的可排队使用它的 token 共享是有益的，甚至包括来自其他用户无关请求、只是恰好同时运行且网络连接足够近可以共享的 token。将全部四种模式视为相同的工作负载，会丧失 MoE 模型在不同强度和不同共享模式方面提供的许多结构性优势。
在本文档中，我们将分别处理这 4 个阶段，并有时假设它们是解耦的。聚合式（模型留在同一台服务器上，随着请求在各阶段推进而重新配置）与解耦式（编排器可以在另一台已适当配置的机器上找到空闲槽位）之间存在权衡。一般来说，我们将以解耦方式讨论这些阶段，而聚合是前一阶段完成时始终使当前节点可用的特殊情况。在更完整地介绍待完成的工作之后，末尾将有一节讨论这些权衡。
Transformer 模型是重复层组的深层堆叠。一个组可以包含一种层，也可以包含一个全注意力层以及若干线性、局部、选择性或其他优化注意力层（这是混合层组）。在每一层内，注意力、共享变换、路由、选定的专家以及重组按顺序发生。这些步骤是预先已知的并持续重复，允许相同的硬件资源在不同时刻服务于流程的不同部分。
这些机器也可以被描述为同样简单的重复单元。一个节点是一组加速器，通常是机架中的一个托盘，每个加速器将计算与本地快速内存配对。一个节点由一个 CPU 协调，并通过 NIC（网络接口控制器）连接到其他节点。节点堆叠成机架。当非常大的张量时，一个机架可以充当一个纵向扩展域、几个较小的纵向扩展孤岛，或一组流水线阶段。数据中心网络则将受限的工作节点连接到存储和编排，而不是参与每个内部张量操作。
本文沿着这一脉络展开。它从全局服务和运行机制入手，然后将模型拆分为宽泛的层组切片，并将其映射到加速器节点和机架上。由此进一步展开流水线并行、张量并行和专家并行；KV 缓存内存所施加的限制；批处理在预填充、中填充和解码中的不同价值；以及调度在多机架 token 工厂中的作用。
1. 编排层通过队列将请求送入工作进程池
推理服务是一个集群，空闲时存储先前的请求和不可变状态，当新请求拉入上下文或先前请求重新唤醒以继续时，这些状态会被排队交付给专门的工作进程。传入队列还不是一个批次。每个请求携带提示 token、可复用上下文的引用、服务目标，并且通常还带有现有的对话或智能体状态。编排器可以将其放入预填充、中填充或解码批次，请求可以在完成时独立地加入或离开该批次，从而将这部分容量释放给新工作。当调度器知道哪些工作进程有空槽且与请求的上下文长度和服务目标匹配时，连续批处理的效果最佳。
预填充工作进程从大量新 token 中创建上下文。其输出是每个模型层的新 KV 状态，独立于创建它的工作进程进行存储。KV 状态沿模型层移动，某一轮中第 K 层的输出成为下一轮中第 K 层的输入。在流水线服务器中，这自然形成了来自不同网卡的输出和输入的“洪流式”传输。
中填充工作进程扩展先前已处理的上下文。缓存的前缀可能包含系统和用户提示、记忆、较早的对话轮次、智能体步骤或检索到的文档。大型根可能已被缓存，而增量输入可能比同等的未缓存请求小得多：五十万上下文可能只接收几百或几千个新 token。
解码工作进程消费已处理、累积的上下文，并在每次传递中生成一个或几个 token（多 token 预测正变得相当普遍）。每个生成的 token 都会增加少量新状态。当用户、工具或智能体贡献另一块输入时，同一上下文稍后可以返回中填充工作进程。使用工具的智能体工作会创建上下文扩展和生成的重复序列，而不仅仅是一次预填充后接一次解码。
一个工作进程可以占用一个节点、一个托盘或一个机架。该服务通过运行许多有界工作进程并在它们之间移动请求和状态而变得庞大。根据精度和工作状态需求，即使是数万亿参数的模型也可以容纳在现代机架级系统的聚合内存中。数据中心网络仍然至关重要，因为工厂必须将许多此类工作进程连接到共享存储，并持续将工作进程配置与需求相匹配。KV 传输的大小可能达到数 GB，但它们可以跨多个链路和目的地进行条带化或洪流式传输；其移动时间可以远低于长时间解码作业的生存期。
这种分离对性能和运维都很有用。一旦缓存前缀大小、新 token 数量和 worker 配置已知，prefill 和 midfill 就是可预测的。Decode 完成时间则是随机的，因为最终输出 token 的到达无法提前预测。两个池之间共享内存和存储，让每个阶段都能按自己的节奏运行。本文后面的章节将讨论队列、就绪缓冲区和 worker 重新配置。现在，重点在于该服务是由可移动状态连接起来的一系列阶段循环。
AgentX 示例
这是用 SemiAnalysis Conversation Explorer 查看的。它显示对话过程中的上下文增长可能相当迅速，但也会因压缩以及其他模型行为而经历大幅波动，这些行为在公开讨论中可能并未得到解释。推理上下文的编排是 AI 公司的一项竞争优势。
我们可以取同一数据集，提取每一轮中看到的缓存、新输入和结果长度值。这张图展示了 Token Factory 需要服务多少种不同的工作负载。原则上，可能同时有与这些轨迹中每个点类似的请求（以及来自其他工作负载数据集的更多点）在运行，并被分配给 AI 集群中的某个 worker。
本文旨在概述推理中使其成为可能的一些主要功能，
2. KV 状态以不可变 blob 的形式移动
在数据中心规模上，可复用上下文变成了一个由不可变 blob 组成的共享对象存储，而不是附着在一台机器上的文件。系统提示、项目上下文、先前的用户轮次、工具输出和生成的 token 可以分别位于不同的 blob 中。新操作读取它需要的 blob，并追加新的 blob；现有 blob 通常保持不变。这种仅向前结构遵循因果 transformer 本身。变更可以通过回溯并创建新分支来处理，而不是重写公共路径。
这些 blob 的持久来源是一个快速、并行、横向扩展的内存和存储池。它需要足够的聚合带宽和网络覆盖范围，以便 prefill、midfill 和 decode worker 可以根据适用性和可用性来选择，而不是因为某台机器拥有上下文的唯一副本。新近空闲的 blob 可以先移动到共享的网络附加 DRAM 中，包括节点 CPU 内存和专用内存设备。随着该层级被填满，分类器可以丢弃不太可能被复用的 blob，或将生命周期更长的状态提升到 SSD。底层文本和引用通常比展开后的 KV 表示小几个数量级，因此如果分诊决定复用空间并丢弃了展开的嵌入状态，就有可能从更小的文本重建 KV blob。AI 计算可能会有细微差异，因此虽然重建后的状态可以预期是有效上下文，但服务可能会对丢弃和重建的随意程度，以及试图保留多少重要的不可变状态，采取不同的做法。
如需深入了解这些 blob 是如何管理的，推荐阅读 Unified Radix Cache: One Tree for Hybrid Model Prefix Caching - LMSYS Org。它并非最终定论，但写得很清楚，如果你想寻找更多资料，它会为你指向其他来源。
对于长时间运行的智能体，状态压缩也频繁发生，这些智能体会不断累积直至达到最大上下文，因此通常在一次压缩之后，会有许多先前的 blob 因被新上下文取代而遭废弃。压缩前上下文所占用的空间很可能被回收用于新工作。
你可以看到，在这些对话的右半部分，随着上下文接近每个模型的实用上下文上限（Opus 4.8 为 250k token，Fable 为 1MT），压缩开始出现。两条线中还出现了“钟乳石”状现象，它们似乎是暂时性的，反映了 Anthropic 模型中的某种专有行为。
加速器 HBM 是“热”工作层。它过于昂贵且供应受限，不适合作为被动上下文存储的默认选择。活动前缀和后缀应在使用前不久进入 HBM，并在工作单元用完后迅速离开。CPU DRAM 是有用的暂存与组装层，尤其对于传出状态：已完成的工作单元可以将新生成的 blob 移入 CPU 内存，同时存储系统选择放置位置和冗余方式，之后由 NIC 将它们送入共享池。
对于传入数据，支持 RDMA 的系统可能允许网络将数据直接放入加速器内存，避免经由 CPU DRAM 的完整拷贝。CPU 内存对于元数据、协调、部分组装、回退路径、副本以及传出暂存仍然有用。当工作单元使用多个 GPU 时，传入上下文可以并行地直接条带化到它们各自的目标内存中。
机架级热 blob 缓存也可能有用，无论是以内存/存储设备的形式实现，还是利用分配给分布式存储池的 CPU 内存。系统提示等非常常见的对象是天然的候选者。这些缓存应保持为共享的横向扩展资源，而不是将请求绑定到某一台解码机器的私有状态。HBM 比 DDR 贵数倍，且供应更受限。HBM 的最佳用途是存放当前正在产生收入的活动批次中的数据。
数据输入通常大于输出。Midfill 通常读取一个大的前缀，并追加一个有意义但较小的后缀。Decode 读取累积的上下文，只追加一个或几个生成 token 的状态。读取会重复进行，写入通常只发生一次。系统设计应通过每条数据路径的宽度直接体现这些差异。
3. Prefill、midfill 和 decode 形成不同的运行模式
全局服务包含若干计算模式。它们的差异比计算受限和内存受限这类通用标签更有用，因为每种模式都有不同的复用机会，以及不同的硬件自然映射方式。
3.1 Prefill
经典 prefill 开始时几乎没有或完全没有可复用的 KV 状态，并处理一大块新 token。这些 token 共享权重加载，高效使用矩阵运算，并产生足够多的路由激活，以形成有用的共享专家批次。注意力和稠密变换可以达到很高的算术强度，因此 prefill 通常主要受计算约束。较长的初始输入上下文可能增加内存流量，但其长度很少达到 100,000 token，而 midfill 通常超过这一长度。
3.2 Midfill
Midfill 将新 token 追加到长得多的缓存前缀之后。新块仍可为共享权重和专家复用提供数百或数千个激活，将算术强度提升到每字节数据数千次运算。注意力还必须读取一个庞大的现有 KV 状态，其大小可达数十 GB。因此它处于一种混合状态：算术复用比解码更多，但缓存状态流量远高于相同新 token 数量的初始预填充。
3.3 解码注意力
解码在每次查询输入一个或几个 token 时推进。每个查询都带来自己的 KV 状态，其长度与 midfill 处理的相近。预填充与 midfill 的区别在于缓存长度，而解码与 midfill 的区别在于输入序列长度。这些一到几个输入 token 使算术强度保持低位，这项工作显然由 KV 缓存周围的内存移动主导。
对于长上下文，注意力读取可能超过与模型权重相关的张量运算的大小。因此，尽管大多数模型参数位于专家中，注意力仍是现代解码中最大的操作之一。Delta、top-k 或线性注意力算法层可以减轻负担，但周期性使用全注意力层仍然是主要的内存负载。每个查询都带来自己的上下文，因此批处理查询不会改变注意力的算术强度。
3.4 解码专家
专家并非解码阶段特有。模型运行到哪里，专家就运行到哪里，它们除了一个 token 的嵌入之外不需要任何上下文。查询的历史已经被压缩到呈现给专家的激活中。这使得各种设计可以将专家共享到所有可用的 GPU 上，减少每个 GPU 的内存大小并提高内存带宽/内存大小之比，即内存强度比。你可以将 GPU 读取其所有专家所需的时间间隔视为最佳情况下的交互性（每个用户看到的 token 速率），因此如果内存带宽保持不变但 GPU 负责的专家更少，交互性就可以更高。问题在于网络需求也会上升，而路由到专家所需的 all-to-all 模式是一项艰巨的任务。
在注意力结束时（在预填充、midfill 或解码中），路由器计算（一个对未精炼 token 操作的小张量）为每个新 token 选择几个专家。选择同一专家的 token 可以共享一次张量权重加载，即使它们来自不同的请求，只要它们能及时聚集在一起以利用同一次权重加载。实际上，所有层中可能有 15,000 个专家，因此利用这种巧合需要有意的同步，比如等待一个批次中的所有查询完成注意力后再将它们发送去进行专家工作，而这又可能通过让附近不同机器上的多个实例也同步到该调度来改善。如果你曾想知道为什么 Nvidia 如此努力地将 72 个 GPU 紧密连接在一起，这就是很大一部分原因。在一个大型 token 工厂中，让这 72 台机器全部同步运行是可行的，从而允许将一层的专家最多分成 72 份。如果模型的一层有 256 个专家，那么每个 GPU 在每层只处理 3 或 4 个，从而允许非常快速地完整循环所有专家。以及大量的 all-to-all 流量。
如果你的专家都能保存在 SRAM 中，就会发生一些有趣的事情。你需要大量的加速器和一张庞大的网络，才能把它们全部收集并全对全地送回 GPU，但现在几乎没有理由等待形成一个批次。每个专家只要有输入就可以运行。每加载一个字节的能耗比从 HBM 加载要好上多达 100 倍，因此运行单个 token 的效率可能相当于以前排队 100 个 token 的效率。作为这种 DAF（解耦注意力-FFN，其中专家就是 FFN）的回报，你可以让这些实例不再需要同步。这一优势在 prefill 或 midfill 中帮助不大，因为它们本来就有一批 token，可以在单层上排序到共享队列中，但它仍可能从那些 GPU 上卸载所有专家权重，让它们能够优化本地内存用于其他用途，比如更长的上下文。网络仍然是个棘手之处：基于 SRAM 的加速器可以在不到一微秒内完成一次专家计算，但现在你可能要用数百万 token 的全对全流量去淹没一台连接着数百个节点的交换机。网络吸收的金钱和功耗可能比它们所连接的专家还要多。
推理 worker 可以通过在同一模型层上协调多个注意力实例来改善共享。它们路由后的激活随后从该层的专家库中提取，从而减少每个目的地必须加载的不同专家数量。在流水线服务器中，这也意味着用于专家并行的网络连接可以局限于机器的该阶段，永远不会出现需要来自另一层的专家的路由。即便如此，每个 decode 请求每次通常只贡献一个新 token，并带有 8 到 16 个路由专家，而一层可能包含数百个专家。在小批量下，共享仍然有限，内存带宽继续主导 KV 扫描和活跃专家加载，每加载一字节权重所对应的计算量非常少。无论使用何种内存，专家内存的每比特能耗都需要非常低。
这些模式解释了为什么 prefill、midfill 和 decode 可能偏好不同的 worker 配置；为什么 decode 注意力和 decode 专家可能偏好节点内的不同放置位置；以及为什么批处理对每个阶段的帮助程度不同。随着现代 agent 工作中的 prefill 迅速扩展到 50 万 token 范围，存在大量内存移动，尤其是在 token decode 阶段——即模型生成有用的中间和最终结果的阶段。快速且大容量的 3D RAM 将在效率方面起决定性作用。快速内存对 midfill 也很有用。然而，对于我们如今视为常态的大上下文，容量需要达到最低水平。如果内存容量太小，那么与未来那些在不放弃吞吐量的前提下利用 3D 容量扩展的内存类型相比，网络损耗和过度庞大的芯片集群可能会浪费功耗。
虽然 Vera Rubin 72 在算术密集的 mid-fill 层表现出色，但在转向内存密集型的 decode 时效果就不那么理想，Rubin 无法充分发挥其计算能力。在大上下文场景下，将 decode 工作和 midfill 保留在同一节点内、避免将上下文通过网络发送到不同节点，具有很高的价值。这可能有利于一种全能型芯片，既具备超高的内存吞吐量，又拥有真正高效的计算能力。
4. MoE prefill 层的流程
经典的 prefill 从注意力开始。一组新的查询 token 会关注可复用的前缀（如系统提示）以及新块中较早的位置。注意力操作会为每个新 token 生成一个激活值，共享变换则将这些激活值准备好，送入路由专家阶段。
路由器为每个 token 分配若干专家。如果模型选择 8 个路由专家，那么每个传入 token 会在一个可能包含 256 个或更多专家的池中产生大约 8 条路由。按 token 顺序来看，这些记录是稀疏且交错的：相邻的 token 可能具有完全不同的目的地。然而，在整个输入块上，每个专家都可以累积出一个较短的被分配 token 列表。
工作节点按专家标识符对路由记录进行排序或排队。分配给专家 037 的所有激活值成为一个消息流；分配给 142 的则成为另一个。这样，一次专家权重加载就可以服务该桶中的所有激活值。多个请求可以贡献到相同的桶中，而运行同一层的不同注意力实例可以在专家目的地合并它们的路由工作。将 token 顺序转换为专家顺序是 MoE prefill 的核心效率来源之一。像 NVLink 这样的 scale-up 网络可以组织为内存映射连接，因此将请求发送到特定专家可以映射为将消息推送到一个特定的内存映射位置，该位置被配置为硬件队列。启动和停止时间非常短。专家可以用相当于 RDMA CIQ 的方式监听，同样利用硬件加速来传递消息流，无需复杂的协议启动和停止。消息内联的简单头部标识发送方和接收方。可以为从专家返回 decode 工作节点的回程流建立类似的连接。
专家输出被恢复为 token 顺序，加权、合并，然后传递到下一层。与此同时，注意力为追加的 token 创建新的 K 和 V 状态。在整个模型中，这些值形成一个不可变的 KV 后缀，用于解码下一个 token，并最终作为上下文中的下一个 blob 存储起来，供对话的下一轮使用。
因此，prefill 结合了两种形式的权重复用。注意力和稠密变换在多个 token 之间复用权重，而路由专家则在收集到其桶中的 token 之间复用每个被选中的专家。随着激活流量、KV 流量和输出处理的增长相比张量计算占用更多时间，收益最终会趋于平缓。批处理可能会延迟首 token 时间，但一个包含数千个新 token 的单个请求已经提供了可观的算术强度；prefill 并不总是需要在每个批次中有大量请求才能高效运行。现代单插槽 GPU 甚至可能在大约一秒内为小批量的大模型完成 prefill。
5. MoE 解码层的流程
解码在每次前向传播开始时的新工作量要小得多。当前 token，或 MTP（多 token 预测）中推测出的少量 token，就是查询。注意力机制读取先前的 KV 状态以及新 token 的 KV 条目。新条目追加到结果中，并被追加到 KV 状态中以供下一次传播使用。
在智能体场景中，先前的 KV 状态通常比该单个 token 所使用的注意力和专家权重带来更重的读取负担。新的查询及其局部投影权重相对紧凑。注意力可以跨 KV 头、上下文范围、内存通道或加速器单元进行分区，之后将部分结果归约为一个 token 激活。该激活足够小，可以低成本地移动，尽管它将在下一阶段触发大得多的局部张量运算。
该激活经过共享变换和路由。路由器从可用专家库中选择少数专家，只有这些专家张量会为当前 token 激活。它们的输出被加权、组合、投影，并传递下去。
在每一层，注意力都会为新 token 创建并保留该层的 K/V 条目。然后激活推进到下一层的注意力，在那里重复相同的序列。当最后一层产生下一个 token 时，每一层都已追加了其小的 K/V 更新。这些更新可以在 token 流式传输到客户端或智能体的同时，组装成一个新的不可变 KV 后缀。
因此，该流程同时包含一个宽泛操作和一个稀疏操作。注意力在私有查询状态上广泛读取。专家激活总模型容量的一小部分。硬件映射应同时支持两者，而不应强制整个层使用一种并行策略。
6. Midfill 是一种独特的运行模式
Midfill 将长缓存前缀与一块新 token 相结合，为对话或智能体工作中的下一轮做准备。追踪数据显示，缓存输入比增量查询大许多倍，尽管增量查询通常从 50 到 5,000 个新输入 token 不等。缓存系统提示、对话根、记忆、先前的智能体步骤和检索文档的存在，可以迅速将对话和智能体上下文推高到百万上限。AgentX 数据集显示，前沿专家反复压缩上下文，以保持在百万 token 限制之下。
这使得 midfill 既不是小型预填充，也不是大型解码。与解码一样，它必须读取大量私有 KV 缓存。与预填充一样，它处理足够多的新 token，以复用权重并将路由激活分拣为有用的专家批次。其算术强度可以比单 token 解码高出数百倍，但其缓存状态流量可以比同等规模的初始预填充大数十倍。
现代加速器通常可以利用数百个 token 的块中可用的算术复用，因此困难的平衡往往在于大量 KV 读取与路由专家流量突发之间。这种突发与解码流水线的平滑节奏不匹配：midfill 可能占用某个阶段的时间远长于相邻阶段中的解码批次，从而使那些阶段得不到充分利用。
理想的并行方式也可能不同。本文后面的示例会发现，midfill 配置使用的流水线、张量和专家并行设置与 decode 不同。在实时 decode 流水线中途重新配置 GPU 可能代价高昂或不切实际。因此，服务可能受益于一个专用的 midfill 优化节点池。硬件可以与 decode 池完全相同，但加载的模型阶段、并行度和批处理策略不同。
7. 模型是重复层组构成的高堆叠
模型的参数量量化了总的学习状态，但服务取决于该状态如何组织和使用。模型是层的堆叠，而将这些层分组为重复的架构单元越来越有用。
在某些 MoE 模型中，一个层组等同于一层。在其他模型中，一个组包含一个完整注意力层以及若干线性、delta、top-k 或其他优化注意力层。通常最初的 1 到 3 层可能是稠密层，或以其他方式设计以获得干净的开端。模型的其余部分通常会重复一种循环的组模式。
一张宽而薄的 crêpe 是层组的有用表示。宽阔的表面为注意力、共享变换、路由、专家容量和残差流提供了空间。其浅薄的厚度标志着该组是一个高得多的重复模型中的一片。它也呼应了加速器的物理形态：一个非常薄的活动层铺展在宽阔的封装上。crêpe 是将宽算法流映射到宽硬件表面的有用直觉。
重复结构简化了功能规划。为一个组创建的映射可以复用于下一个组。相应的内存区域可以容纳下一组的权重。相同的计算和通信计划可以重复执行。一致性不仅对运行时效率重要，对编译器、内核和运维工具也很重要。
在 decode 期间，对于给定 token，一次只有一层处于活动状态。在该层内，若干操作按顺序发生。相邻层可能被预取，不同的流水线阶段可能同时处理不同的查询，但一个 token 的逻辑路径仍然按顺序爬升穿过堆叠。
8. 并行应划分模型的窄数据流
并行不是一个单一决策。流水线、张量和专家并行划分模型的不同维度，应根据不同的通信模式来评判。
流水线并行遵循层堆叠
层立即暗示了流水线化。层之间传递的激活是紧凑的——通常是一个嵌入 token、一个小型多 token 预测块，或先前混合组结果的简短摘要——而层内使用的权重和 KV 状态要大得多。因此，一个流水线阶段可以拥有一个或多个完整层组，并将相对较小的激活传递给下一阶段，而无需过强的网络。
流水线并行将模型权重干净地划分开，并让层内热点通信保持在本地。其主要缺点是多样本占用：一条完全活跃的流水线在每个阶段都有不同的查询或批次。因此每个阶段都为所有活跃流保存其那份 KV 状态，随着上下文增长，内存收益最终不再改善。
张量并行适用于单个操作本质上就很宽的场景
注意力可能需要将权重和 KV 状态划分到多个加速器上。KV 头、上下文范围或其他线性维度可以被分区，使每个加速器先处理自己的份额，再对 token 结果做一次紧凑的归约。张量并行也可用于异常大的稠密变换。
TP 不应自动扩散到该层的每一个张量。对宽注意力操作合理的集合通信，其开销可能超过一个小专家张量的算术量。
专家并行遵循独立的专家张量
大部分 MoE 参数内存可能驻留在专家中。专家自身不保留查询历史；上下文随激活到达。因此专家库可以广泛分布在一个对等集合上，并由多个工作实例共享。
宽专家并行之所以有用，是因为专家相互独立且数量众多。路由器将紧凑的激活发送到选定的目的地，这些目的地返回变换后的激活。即使流水线阶段变小，专家并行的宽度仍可保持很大，从而允许独立选择交换基数与本地内存放置。
一般规则很直接：对垂直的层序列使用流水线并行，对大型不可分割操作使用张量并行，对无上下文的被路由专家库使用专家并行。当一个阶段可用的快速内存安全地超过其本地权重、活跃批次状态和工作缓冲区时，它就能舒适地容纳在一个 scale-up 域内：
M_{free,node}>\frac{W}{P}+M_{batch}+M_{working}
现代 GPU 节点往往以数倍于该阈值的规模超出。当它们做到这一点时，苛刻的带宽、功耗和延迟要求可以留在一个节点内，而更细的流水线激活和 KV 移动则使用 scale-out 链路。其余的快速内存很可能没有产生任何收益。闲置在内存中的数据是开销，移动起来被处理的数据才是收益。
9. 逻辑加速器节点
将逻辑节点理解为一个排成环的对等集合，比理解为字面意义上的电路板布局更容易。该环包含大约十六个加速器。每个加速器将一个计算区域与本地快速内存配对。这些单元通过强大的 scale-up 互连结构连接。一个 CPU 协调工作负载和内存管理，而一个 NIC 将节点连接到机架和数据中心资源。
这个环只是一种可视化方式，用来展示加速器作为对等体、地位平等。我并不是在暗示节点内部网络应该是环形的。它可以是星形、轨道形、全连接、环面、超立方体……随你喜欢，只要它能以低延迟和低能耗每比特处理机架内最高的数据流即可。为简单起见，我就把它画成环。
这种表示方式避免过早确定封装布局、板级布线或交换实现。实际机器可能使用一个中央交换机、多个交换机、直接链路或分层结构。逻辑要求是一个有界的对等集合，具备可预测的快速本地通信。
加速器设计可能有所不同。一种版本可能使用以 SRAM 为主的内存内计算单元。另一种可能使用混合键合 DRAM，或在 BEOL 工艺期间置于顶部的 IGZO 存储单元。还有一种可能使用混合键合的高带宽真 3D 内存。内存容量和带宽可以变化，而这种逻辑模型仍然有用。
节点是保留高频重复工作的自然位置。注意力分区交换紧凑的部分结果。路由的专家激活值传输到本地目的地。专家输出返回以进行重组。共享状态和调度元数据保留在 CPU 附近。NIC 承载流水线激活值、KV 数据块以及节点之外的工作分配。
一个节点可能小于机架，就像我们在配备 8 个 GPU 的 SGX 节点中看到的那样；或者一个纵向扩展系统可能横跨整个机架，就像我们在 NVL72 中看到的那样。逻辑符号在两种情况下都仍然有效。如果纵向扩展已经覆盖整个机架，那么单独的机架骨干层级就消失了，下一个边界直接就是横向扩展网络。
10. 节点堆叠成机架
当倾斜为宽而浅的硬件可丽饼时，环变得更具表现力。多个单元可以在机架中垂直堆叠，就像模型深度中堆叠的模型层组一样。
这种重复形式使模型与硬件之间的关系更容易看出。一个层组可丽饼可以放置在一个硬件可丽饼上。如果内存允许，多个层组可以占用一个节点。如果注意力或专家容量需要，一个层组可以跨越多个紧密连接的节点。这种映射可以扩展或收缩，而无需改变基本的视觉词汇。
机架可以按多种方式组织：
一个机架范围的纵向扩展域；
由机架骨干连接的若干节点规模孤岛；
分布在这些孤岛之间的流水线阶段；
每个阶段内广泛的专家放置；
或阶段本地纵向扩展与共享横向扩展链路的混合。
因此，机架骨干是一个可选的中间层级。一些系统将纵向扩展结构扩展到整个机架，无需单独的节点连接器。另一些系统使用强大的本地节点结构以及独立的架顶或共享轨道网络。在机架之上，横向扩展网络连接存储、预填充池、解码池和其他机架。
重复的机架单元也有助于区分两种规模。模型可以适配在一个有界的机架工作器内，而工厂通过添加许多工作器来扩展。第一个问题是功能放置。第二个是工作器编排。
11. 一个层组随时间复用节点
一个层组并不要求算法中的每个操作同时以峰值强度运行。其操作形成一个重复序列，在解码周期中为不同工作复用同一硬件。
注意力可能分布在环的大部分区域，使用许多内存通道和若干计算单元。查询和输出变换使用模型权重，以更紧凑的操作进行。共享前馈工作可能使用密集区域。然后，选定的专家激活环周围的本地内存和计算区域。重组返回一个紧凑的结果。
相同的物理加速器可以在每个步骤中发挥不同的作用。计算注意力的执行单元之后可能执行一个或多个专家。用于流式传输 KV 状态的内存通道之后可以馈送专家权重。缓冲区和本地链路随着 token 的推进而被复用。
这种分时复用是高效设计的核心。静态图可能让机器看起来未被充分利用，因为并非每个模块都同时处于活动状态。实际上，硬件正在服务一系列不同的操作，目标是让这个序列以极少的设置或同步开销持续运行。
宽泛的层组 crêpe 与加速器对等集是互补的。crêpe 展示算法流程；环展示其下方可复用的物理资源。映射就是将流程的每个阶段与环的合适子集对齐的行为。
12. 将吞吐边界放在流量最小处
一旦模型和机器被绘制为相互连接的流，放置规则就变得清晰：频繁、对延迟敏感的通信应保持在最强的本地结构内，而较弱的链路应承载紧凑或可摊销的传输。
注意力分区可能每一层都交换部分结果。专家路由将激活发送到选定的专家并返回其输出。这种流量按字节数计算并不总是最大的，但它频繁、突发且对同步敏感。只要可行，它就应属于所选的纵向扩展域内。
在层或层组之间传递的激活要小得多。因此，流水线边界可以跨越较弱的链路，而无需移动该层的全部内部工作集。KV 块更大，但它们在 worker 边界移动，并在许多生成的 token 上摊销。它们的路径可以使用条带化或洪流式的横向扩展网络和共享存储，而不是消耗最内层的张量结构。
路由器到专家的边界通常是承载紧凑激活的中等吞吐全对全通信。其困难通常来自端点数量、同步和路由效率，而非原始字节量。将其保持在节点或机架的纵向扩展域内，可以限制延迟和运维复杂性。
这种层次结构比每条链路都同样强大的机器更容易、更便宜地构建。纵向扩展路径围绕每一层内交换嵌入和部分结果的操作。横向扩展链路承载流水线激活、KV 移动、调度流量以及有界 worker 之间的流量。
这些层级也有不同的延迟要求。如果吞吐量足够，层组之间的流水线传输可能几乎注意不到几微秒。相比之下，当专家加载和乘法仅需几微秒时，每个路由跳额外增加 100 ns 就很重要。因此，最近的链路应与加速器结构紧密集成，而不太频繁的传输可以容忍横向扩展网络。
13. 在可行的情况下按层组进行流水线划分
层组是流水线放置的自然首选候选。在经典 MoE 模型中，该组重复一种层。在较新的结构中，它可能包含一个全注意力层，后跟若干个优化或局部化注意力层。
将一组保持在一起可以保留内部依赖关系，并允许一个放置和编译方案在各阶段重复使用。统一的方案可降低工具成本并简化部署。当每个阶段运行相同的重复结构时，内核、内存布局、通信调度、监控和故障恢复都会变得更加容易。
仍然可以在一个组的中间切分流水线，尽管由此产生的放置更为复杂。如果各层没有特殊的跨层依赖，紧凑的激活边界仍然是一个适合网络传输的低流量链路。一个阶段可以包含若干个完整的组、一个组，或一个大组的一部分，具体取决于内存和吞吐量需求。
指导原则并不是绝对禁止拆分分组，而是倾向于规则的边界，并理解何时非均匀拆分是值得的。工具和运维的简洁性可能与微小的理论放置收益同样重要。
14. 流水线深度止于 KV 缓存交叉点
流水线并行可以干净地划分模型权重。如果模型具有权重占用（W）并使用（P）个阶段，则每个阶段的理想化权重占用趋近于（W/P）。
KV 缓存需求的表现则不同。完整的流水线通过在每个阶段运行不同的查询或批次而保持占用。在一个八阶段流水线中，每个阶段拥有八个活跃流中每个流的八分之一的逐层 KV 值。每个阶段层数的减少被同时活跃的流数量所抵消，因此该阶段在活跃 KV 需求上并不会像权重那样获得相同的（1/P）缩减。
一个有用的阶段内存估算为：
M_{stage}\approx \frac{W}{P}+M_{KV,stage}+M_{working}+M_{slack}
一旦每个阶段的权重降至与 KV 和工作状态内存同一数量级，更深的流水线化几乎不会带来额外的容量收益，反而会增加协调开销和延迟。
交叉点在很大程度上取决于模型设计。经典的全注意力方法在所有层上可能需要每 token 数百 KB 的 KV 状态。类 MLA 设计通常在数十 KB 量级，而近期以线性、循环或局部注意力为主的混合层组可以更低。对于某些新的混合模型，每 token 约 25 kB 的工作平均值可能是合理的；对于一种经过验证的压缩注意力设计，每 token 约 70 kB 是一个保守的参考点。
作为一个粗略的设计目标，取每 token 70 kB 和分配给一个阶段的两百万 token 聚合活跃上下文。这大约是 140 GB 的 KV 状态。双缓冲允许一个工作集在移动的同时另一个继续运行，将 KV 配额提高到约 280 GB。再加上模型权重、激活、瞬态缓冲区、路由表、碎片和运行余量，约 400–500 GB 本地快速内存的阶段目标就成为一个有用的 2027 年基准。
其他设计可以通过流式传输、压缩、部分驻留或额外层级来降低需求。该估算并非普遍要求；它是一个实际的前沿系统应当能够在无需英雄式假设的情况下满足的标准。
如果多个加速器插槽共享一个纵向扩展互连结构，该阶段可以将此内存分布到这些插槽上。大型 MoE 中超过 95% 的权重内存位于路由专家中，这些专家自然地在插槽之间划分。KV 状态可以按头、上下文或注意力实例进行分区，并将由此产生的集合通信匹配到同一本地互连结构。
15. Prefill 和 midfill 将稀疏路由转化为密集专家批次
Prefill 和 midfill 具有强大的批处理机会，因为许多输入序列 token 在专家执行开始之前就完成了注意力计算。路由器可以对所有 token 进行评分，为每个 token 发出多个目的地，然后按专家对路由记录进行排序。
一个实际的输入块可以包含足够多的分配，使得基本上每个专家都能获得工作。如果 128 个新 token 各选择 8 个专家，路由器会在一个包含 256 个专家的库中发出 1,024 个分配。对于每个 token 而言，路由仍然是稀疏的；排序改变了执行顺序，使得专家 e000 处理其所有分配的 token，然后是 e001，依此类推。每个专家只加载一次，并为其紧凑的 token 列表重复使用，而不是按 token 顺序反复加载。
对于一个具有 (W) 权重、权重流量 (B_W)、每个路由 token 的激活流量 (B_A)、输出流量 (B_O) 和 (n) 个分配 token 的专家，一个粗略的算术强度表达式为：
AI_{expert}\approx \frac{2nW}{B_{W}+nB_{A}+B_{O}}
当权重流量占主导时，增加 (n) 会迅速提高复用率。最终，激活、输出和路由流量变得重要，增益趋于平缓。
排序并非没有代价。必须构建路由记录、计数、置换、发送到专家目的地，并恢复到 token 顺序。专家容量限制可能导致溢出或重新路由。即便如此，prefill 和 midfill 开始时就有足够多的 token，因此这种优化通常是有意义的。
这是与 decode 的关键区别。专家是相同的；变化的是工作器执行它们时可用的路由激活数量。
16. Decode 从批处理中获益较少
Decode 注意力几乎没有直接的跨查询复用。每个额外的查询都会贡献另一个 KV 缓存和另一次上下文扫描。共享的查询投影权重可以复用，软件开销可以摊销，但占主导地位的长上下文读取仍然是查询私有的。
Decode 专家提供了潜在的共享，因为专家权重是与上下文无关的。实际限制在于共享概率。一个模型可能在每一层包含数百个路由专家，在整个模型中包含数千个层专家。每个查询在每次传递中贡献一个新 token，并且只选择少数几个目的地。在较小的批大小下，只有少数路由 token 可用，大多数活跃专家仅从一个 token 获得工作。会发生一些共享，但它随着传递中 token 数量的增加而逐渐增长。
共享变换提供了更传统的权重复用，但它们在 MoE 模型中所占比例较小。因此，与延迟和 KV 内存压力的增加相比，扩大 decode 批大小带来的整体吞吐量增益可能不大。
当上下文长度为 100,000 个 token 或更多时，批大小为 1 并非微不足道的工作负载。注意力扫描已经占用了大量的内存带宽。最佳批大小不一定是 1——软件启动、分配、路由和硬件利用率仍然重要——但它可能更接近 1 或 5，而不是与面向吞吐量的服务相关的大批量。
这在经济上很重要。交互式 token 可能比批量延迟 token 更有价值。为了获得微小的吞吐量提升而增加延迟可能是一笔糟糕的交易。硬件和软件应当消除对有用的小批量运行的阻碍，而不是让大批量成为效率的前提条件。
17. 调度使解聚变得有用
解聚作为统计系统在云规模下最为有效。一个大型资源池可以包含配置用于长预填充、短预填充、长上下文解码、短上下文解码或其他有用类别的 worker。编排器将每个作业分配给合适的可用 worker，并通过共享存储移动所需的 KV blob。
一旦前缀大小、新 token 数量和 worker 配置已知，预填充和中间填充工作就是可预测的。解码是随机的，因为输出长度不确定。池之间的存储将可预测的生产与不规则的消费解耦。已完成预填充和中间填充工作的就绪缓冲区可以让解码 worker 保持供给，即使各个查询在不同时间完成。
调度器应当观察客户工作负载和时段模式，预测已知的峰值，并随着组合变化重新配置 worker。重新配置可能意味着加载不同的模型阶段、更改流水线基数、重新分配专家容量，或在预填充、中间填充和解码之间移动机架。
规模很重要。在一个小型固定基准测试中，一个输入填充阶段可能直接连接到一个解码阶段。一个缓慢的阶段可能会使另一阶段中的容量闲置。在一个大型资源池中，worker 独立完成和启动，因此没有 worker 需要被闲置。
因此，高交互性和高利用率并非本质上对立。调度器可以在保持机器繁忙的同时保持小批量，只要它有足够的 worker、足够的存储带宽、对工作的足够可见性，以及足够快的响应时间来适应当下。
图 1 中的服务概览提供了相应的系统图景：四个资源池，编排器横跨其下。
18. 反馈可能将小的不平衡变成振荡
一个紧密耦合的系统可以放大普通的波动。假设输入填充的准入直接由解码查询的完成来控制。一个长时间运行解码查询会延迟完成。输入填充准入下降。解码随后耗尽它的就绪队列并变得供给不足。然后准入激进地打开，产生一阵输入填充作业和新的拥塞浪潮。
这是一个延迟反馈回路。控制信号在系统状态已经改变之后才到达。大批量恢复可能通过增加 KV 内存压力和响应延迟使回路变得更糟。工厂在满和空之间交替，而不是在稳定点附近运行。
没有单一的调度器策略能解决这个问题。几种熟悉的控制技术有帮助：
在阶段之间使用就绪工作缓冲区；
根据平滑后的积压和预测的服务速率来调节准入，而不是根据单个完成事件；
将快速本地控制与较慢的容量控制分开；
对 worker 重新配置应用迟滞；
为短交互式工作保留容量；
并且避免在系统能够观察到其效果之前就改变批量大小。
同样的原则适用于不同的时间尺度。微秒级的工作线程调度、毫秒级的 token 流动、秒级的缓冲区、分钟级的工作线程重配置以及小时级的需求规划，不应全都对同一个噪声信号作出响应。
19. 聚合与解聚的比较
既然我们已经详尽地描述了分离式推理，那么是否有理由支持聚合呢？在某种程度上，是的。显然，由于对话可以暂停数分钟乃至数小时，将整个对话绑定在一个系统上是不合理的。在回合结束后的几秒内，那块 HBM 就可以得到更好的利用，而现代横向扩展网络可以在不到一秒的时间内将数 GB 的 KV 缓存移动到并行存储系统中更便宜的位置，该系统可以分层使用 DRAM 和 SSD。
然而，在一个回合期间，我们是否需要调度多个位置来完成工作？拥有太多不同设计的服务器成本高昂，会增加运营成本以及设计工作。如果只有一种设计，并且以 midfill 场景为中心呢？请求可以被调度到那个空闲的工作线程，并在那里停留，完成 prefill、midfill 和 decode。它需要有足够的算力用于 prefill 和 midfill，以及足够的内存带宽用于 decode。总会存在一些算力或内存传输方面的搁浅容量，具体取决于模型运行在哪个阶段，但我们已经容忍了 GPU 上较低的 MFU。我们试图用巧妙的 kernel 来克服这一点，但在实践中，集群一直带着搁浅的功能运行。
复杂的编排会导致一些搁浅。如果在一个回合运行在单个聚合工作线程上，其中一些就可以避免。pre/midfill 移交给 decode 时没有调度间隙。宽并行专家集的一份副本可以自然共享。没有将上下文从 fill 移动到 decode 的网络开销。编排器仍然会查看请求的形态——缓存大小、输入序列长度、模型类型、客户交互级别——并做出一个决定：哪个可用工作线程应处理该回合的所有阶段。然后它就不再干预，直到停止 token 出现，该回合被交付给用户并缓存到快速并行文件系统。这一个工作线程在处理该回合所有阶段时，使用适应给定请求形态的 kernel 和数据流。
聚合工作线程有其吸引力和拥护者。
在现实世界的使用中，所有系统总会搁浅加速器的某些能力。在分离式系统中，可以有两种（或更多）类型的机器，其投资集中在实际使用的算力、内存和网络上，可以说是对这些投资的最佳利用。Prefill 机器可能投资于算力，而 decode 机器可能投资于内存。如果工作线程是聚合的，那么一台机器将在所有阶段使用，因此它需要投资于最强的算力和最强的内存吞吐量。也许还需要强大的网络。如果它不是全面出众的，那么它就会被其较弱的部分拖累，整体表现“平平”。因此，聚合有优势，但在提供最佳全面性能方面也无处可藏。如果你能打造出那个神奇的全能明星，那么将整个回合聚合在一个工作线程中可能是最好的。
20. 内存带宽和内存容量是不同的目标
内存通常被当作两个独立标量来最大化。在实践中，容量和带宽相互权衡，它们的经济价值必须一起考虑。
数据在流动时产生收入；闲置时则产生成本。具有极高内存吞吐量的加速器能以低带宽内存无法匹敌的速率生成 token，即使低带宽配置拥有更大的容量。容量在活跃权重、KV 状态、激活值和运行余量都能干净地容纳之前是有价值的。超过这一点后，额外的本地容量可能增加成本而不带来收入。
容量曲线不是垂直的悬崖。在有用极限之下，增加加速器同时提供更多内存和更多带宽。当其他限制出现时，这些优势就结束了：最大纵向扩展宽度、糟糕的模型切分、延迟的主导地位、额外的同步或网络争用。
安全容量设计点必须位于这些限制之上。它包括针对现实上下文分布、双缓冲、碎片化、故障和瞬态峰值的余量。收入-容量曲线在该点之前急剧上升，平滑地圆润过渡，然后达到一个主要由带宽和计算决定的更平坦的上限。如果过剩容量变成沉没成本，运营方试图用大批量、慢速、高吞吐但价值较低的方式来证明其合理性，收入甚至可能下降。
加速器 HBM 太昂贵，无法在不立即使用的情况下闲置数据。已完成的 KV blob 应移入 CPU DRAM 进行出站暂存，然后进入横向扩展存储。频繁复用的公共 blob 可以保留在共享 CPU 内存或附近的缓存设备中复制。只有活跃工作集才能为最昂贵的内存买单。
高容量内存的高堆叠可能在功耗、信号质量、封装和频率方面带来成本。容量刚好够用且带宽卓越的设计，可能比每加速器容量最大化但存在闲置过剩的设计，以更高的利润率服务交互式推理。
21. 一种实用的映射方法
前面的章节可以浓缩为一种可重复的方法，用于将模型映射到机器上。
区分运行模式。 独立测量预填充、中填充、解码注意力和解码专家。每个还可以按上下文长度或工作负载类别进一步拆分——例如智能体、编码、媒体或内容创作。这些成为编排器可以在生产中混合使用的预备配置。
描述重复层组。 识别完整注意力和优化注意力、共享变换、路由专家以及任何跨层依赖。
测量活跃状态，而不仅仅是总参数。 区分阶段权重、活跃专家、实时激活值、KV 状态和瞬态缓冲区。
Choose the natural parallel dimension for each operation. Pipeline the layer stack, tensor-parallelize broad indivisible work, and distribute independent experts widely.
Map the broadest operation first. Long-context attention often determines memory striping and the minimum useful scale-up participation.
Place expert weights in regular local destinations. Let routing select among known peer locations rather than creating a global event for every token. A large model may contain on the order of 15,000 layer-experts, and each can be placed with regard to the other experts in its layer and the expected routing distribution. The goal is even use of memory capacity and bandwidth.
Keep repeated high-throughput cooperation inside the strongest fabric. Let thinner activations and amortized KV movement cross weaker boundaries. Respect latency and power cliffs as well as throughput cliffs.
Stop increasing pipeline depth at the KV-memory crossover. Once the model and target context fit with safe margin, additional stages bring little memory benefit and add stage-transition latency.
Use input fill and decode differently. Sort prefill and midfill routes into expert batches; preserve small-batch decode interactivity.
Design storage and scheduling with the worker. KV movement, admission control, ready buffers, and worker reconfiguration determine whether the physical mapping produces steady throughput. Short batches and continuous batch updates let the orchestrator replace individual requests without waiting for the whole batch to retire.
The method does not select one universal topology. It makes the trade-offs visible. A peer set may be one package, one board, or a rack-wide scale-up domain. A layer-group crêpe may map to one node or several. The important point is that the communication hierarchy follows the model’s actual flow.
22. The next view is time
The diagrams so far describe structure and flow. The next step is to place time over them.
Interactive decode has a tight end-to-end budget. Execution of one layer commonly needs to fit within roughly 50 microseconds to 1 millisecond, which across a typical 60-layer model corresponds to roughly 15 to 300 generated tokens per second. Each layer contains several sequential phases, so individual arithmetic operations and handoffs live in tens of microseconds, microseconds, and sometimes fractions of a microsecond.
At that scale, tensor arithmetic is only part of the result. Kernel launch, queueing, synchronization, memory setup, routing, reduction, and link latency must all remain small compared with the operation they support. An expert multiply that takes a fraction of a microsecond is of diluted value if dispatch and data movement take several microseconds each.
The timing view also sharpens the network hierarchy. A high-bandwidth path may still be unsuitable if its setup latency is too large. A small local buffer can be more valuable than a large distant memory tier for a sub-microsecond handoff. A scheduler that creates millisecond variation can overwhelm careful microsecond engineering inside the worker.
The factory spans several control timescales:
local arithmetic and link handoffs in fractions of a microsecond to microseconds;
layer execution in roughly 50 microseconds to 1 millisecond;
token generation in milliseconds;
ready buffers and admission control in roughly 0.1 to 10 seconds;
worker reconfiguration by the orchestrator over seconds to minutes;
KV-blob retention and lifecycle in the fast parallel file system over minutes to days;
and customer demand planning over hours and days.
These loops should be designed separately and joined carefully. Fast controls should not chase slow demand noise, and slow controls should not react to every transient queue fluctuation.
23. Worked example: projected Kimi K3 performance on Blackwell systems
The preceding sections describe a method for reasoning about model placement. A useful check is to apply it to a specific frontier model and explore the resulting trade-offs together. The following charts show modeled Kimi K3 performance on B200, B300, and GB200 systems using configurations from 16 to 64 GPUs in a rack. These are workload-and-hardware projections, not measured benchmark results. Connected lines identify projected Pareto frontiers: configurations for which interactivity cannot improve without giving up throughput or another selected objective.
22.1 Interactivity and throughput
The first chart compares time per output token for decode, or time to first token for prefill and midfill, against tokens per second per GPU. Normalizing throughput per GPU makes configurations of different sizes directly comparable.
The lower-left group contains decode frontiers for 8k and 32k input contexts. Feasible configurations appear for all three GPU types. GB200 is strong across much of the frontier, while B200 and B300 also offer competitive points. The lowest-latency decode configurations generally combine pipeline and tensor parallelism. At the throughput-oriented end, the highest tokens per second per GPU tend to come from one attention instance per GPU, without tensor or pipeline parallelism, while expert parallelism remains as wide as the system permits.
The upper-middle group is midfill: 127k cached input tokens followed by a 1k-token append before decode. GB200 leads the low-TTFT portion without pipeline parallelism, using TP=4 or TP=2. B300 catches up toward the throughput-oriented end. B200 and B300 generally use PP=4, with expert parallelism bounded within each stage so the expert all-to-all remains inside the node.
The two groups at upper right are 8k- and 32k-token prefills. All three GPU types converge on similar configurations: PP=4, with TP=4 or TP=2 favoring lower TTFT at some cost in throughput. Their close projected performance reflects the shared Blackwell compute architecture and the compute-limited nature of these prefill workloads.
22.2 Energy per query
The second chart uses the same simulated configurations but changes the vertical axis to energy per completed query. Decode is the largest energy workload because the modeled output length is 1,000 tokens, requiring roughly 1,000 passes through the model for every query. Midfill uses the least energy: it appends a relatively short sequence after one pass through an existing long context. Full 8k and 32k prefills require successively more energy.
The model includes Kimi K3’s localized-attention layers, so both retained state and computation reflect the expected savings from the attention structure rather than treating every layer as full attention.
22.3 Fast-memory requirements
The third chart shows peak HBM residency per GPU. It excludes the extra buffers used while KV state enters or leaves the worker, which may add several gigabytes per GPU. Between conversational or agentic turns, inactive KV blobs can be transferred in parallel to network-attached DDR, including the DRAM attached to node CPUs. That memory is cheaper, more available, and less constrained by the HBM supply chain.
The projected frontiers cluster near the lower end of the feasible memory range. For prefill and midfill, the downward steps come from adding pipeline parallelism and increasing tensor or data parallelism, including data-parallel ring-batched instances. Decode reduces per-GPU residency first through tensor or data parallelism, using pipeline parallelism later.
Most frontier configurations remain below approximately 80 GB per GPU even after allowing for practical KV-transfer buffers. This supports the earlier conclusion that bandwidth can be more valuable than maximizing HBM capacity on every accelerator, provided the broader storage and orchestration system moves idle state promptly.
22.4 Network peaks and the scale-up boundary
The fourth chart shows projected peak network traffic per GPU. Prefill and midfill make intensive use of the network for expert parallelism because many routed activations are in flight at once. Pipeline parallelism is therefore particularly useful on B200 and B300 systems: placing one stage inside a node keeps its expert all-to-all traffic on the local NVLink fabric.
GB200 NVL72 extends scale-up bandwidth across the rack. More GPUs can therefore participate in one layer in parallel, with all instances advancing through that layer in synchrony, to improve latency and throughput without crossing a weaker network boundary.
Decode shows lower interval-averaged peaks because a small batch consults relatively few experts at once. Individual transfers still burst at the physical NVLink rate; the lower plotted value reflects a measurement interval longer than the transfers themselves. This distinction between instantaneous link rate and sustained traffic matters when sizing the fabric and interpreting utilization.
The four views tell a consistent story. The best configuration changes with the operating regime and the selected point on the latency-throughput frontier. Prefill and midfill reward organized parallelism and stage-local expert traffic. Decode benefits from parallelism at the low-latency end, but the highest throughput per GPU comes from simpler attention instances combined with wide expert placement. Across the projected frontiers, fast-memory capacity appears less restrictive than network placement, memory bandwidth, and orchestration.
Closing perspective
The useful unit of analysis for inference is not total parameter count alone. It is the active flow of the model joined to the memory, communication, and timing hierarchy of the machine.
MoE provides structure. Layer groups repeat. Experts are numerous but individually manageable. Attention is broad and increasingly shaped by KV state. Operations occur in sequence and can reuse hardware. Pipeline, tensor, and expert parallelism can each follow the dimension where it is most natural. Prefill and midfill can sort routes into efficient expert batches, while decode can preserve short batches and high interactivity.
The hardware can reflect that structure. A logical accelerator peer set provides a bounded scale-up domain. Nodes stack into racks. A rack may be one scale-up worker or several pipeline stages. Shared storage makes KV blobs movable. Datacenter networking connects bounded workers rather than carrying every inner tensor operation. Scheduling keeps predictable and stochastic stages in steady flow.
Holding the problem this way does not remove its scale. It makes that scale easier to divide. The model, worker, rack, storage system, and scheduler become parts of one coherent design that can be measured, illustrated, and improved.
来源：SemiAnalysis · newsletter.semianalysis.com