服务问题

训练好的模型是一个文件；被服务的模型则是一套按秒和按钱计量的系统。服务首先把一次前向传播分成两个阶段：预填充（prefill）先读完整个提示词，主要受算力限制；解码（decode）一次只发出一个词元，通常受带宽限制。这种分裂把延迟、吞吐量与内存合成同一个调度问题。真正的目标是有效吞吐量（goodput），而非原始吞吐量或原始延迟；KV 缓存则决定这套服务系统能接纳多少并发请求。

本章从这个资源约束出发。缓存的形状由架构固定，成本落在加速器内存上，并被每个在飞请求继续拉长。一旦它成为约束，服务引擎的历史就容易读了：连续批处理不再浪费已完成请求的槽位，PagedAttention 不再预留用不上的缓存，前缀缓存不再重算共享提示词，分块预填充或预填充／解码分离则不再让一个阶段阻塞另一个阶段。

一个必须守时的文件

预训练只花一次算力，造出一个权重文件。服务却要持续消耗算力，每当一个用户发来请求就消耗一次，而且是在用户能感觉到的时钟下消耗。问题不再是最小化某个损失，而是把一组固定的权重跑在一条请求流上，让每个请求返回得足够快，集群又保持足够高的利用率。

有两种延迟定义了什么叫「足够快」，而它们不是同一个数。首词元时间（TTFT）是用户在答案的第一个片段出现之前要等多久。每输出词元时间（TPOT），有时也叫词元间延迟，是流开始之后每个后续词元要花多久。聊天界面需要短的 TTFT，好让回复显得及时；长生成需要短的 TPOT，好让文本连续输出。这两个时钟并非随意定下的产品目标，它们源于同一次前向传播分裂成两个硬件瓶颈不同的阶段。

预填充与解码的不同瓶颈

请求到来时，模型先读完整个提示词。这是**预填充**阶段：所有提示词词元在一次传播中被一起处理，每个位置都注意到每个更早的位置，这是一串大的矩阵-矩阵乘法。预填充是计算受限的，它会占满加速器的算术单元，成本随提示词长度增长。TTFT 本质上就是预填充所花的时间。

随后模型一次输出一个答案词元。这是**解码**阶段：每一步把最近的那一个词元送过网络，产出下一个，这是一串细长的矩阵-向量乘法。解码受限于内存带宽，而非算力。每步的算术量极小，但每步都得把完整的权重矩阵、以及不断增长的过去键值缓存从内存里流式读出，主导时间的是这次流式读取，而非算术。roofline 模型按算力或内存带宽中的一者来界定一个内核的性能上限，而这种 roofline 分裂正是推断性能的基本事实：预填充顶着算力上限，解码顶着带宽上限 (Yuan et al. 2024; Pope et al. 2022)。TPOT 本质上就是每步的解码延迟，而一个空转的解码步会让加速器的大部分算力闲置。

图 31.1 追踪一个请求穿过两个阶段，并列出每个阶段的算术形状、它主要占用的资源，以及它设定的延迟指标。

这个分裂之所以要紧，是因为两个阶段以不同方式压在同一份硬件上。预填充需要足够的工作量，让算术单元保持忙碌。解码需要把足够多请求放进同一个批，让一次昂贵的权重流式读取同时服务许多用户。批处理就是主要手段，它把带宽受限的解码转成更高效的计算：权重读一次，然后摊销到批中的每个请求上 (Pope et al. 2022)。于是吞吐量，即所有用户合计的每秒词元数，随批大小上升，而单个用户看到的延迟，会随批被填满而恶化。服务问题就是这种取舍的具体化：从批处理里赢得吞吐量，同时不耗尽用户的延迟预算。

单一指标为何误导

人们很想追逐某个单一指标，可两个显而易见的候选，吞吐量和延迟，单独拎出来看都具有误导性。吞吐量统计集群产出的每一个词元，延迟统计一个用户要等多久，二者都不是业务目标。一台服务器可以靠激进批处理报出巨大的吞吐量，激进到每个单独请求都错过自己的截止期；它也可以靠在空闲硬件上一次只跑一个请求，报出极小的延迟。能经受现实检验的目标是**有效吞吐量**：在各自延迟目标之内完成请求的速率。一个请求一旦超过自己的 TTFT 或 TPOT 预算，其后产出的词元就不算有用的工作。有效吞吐量，是只在满足服务等级目标（SLO）（服务等级目标，service-level objective）的请求上统计的吞吐量。

有效吞吐量重新框定了之后的每一个决策。调度器的任务，是把尽可能多的请求安排到加速器上，同时不把其中任何一个推过它的 SLO。这是一个带硬约束的装箱问题，而约束由内存设定。要看清为何如此，得先问解码必须保留什么。

KV 缓存是主要约束

第 $t$ 步的注意力需要所有更早位置的键与值。与其每步重算，服务器不如把它们缓存下来。这就是 KV 缓存。它的大小由架构固定，而非由服务层固定：

$$\text{KV bytes} = 2 \cdot L \cdot n_{\text{kv}} \cdot d_{\text{head}} \cdot b_{\text{dtype}} \cdot T$$

其中 $L$ 是层数，$n_{\text{kv}}$ 是键值头数，$d_{\text{head}}$ 是头维度，$b_{\text{dtype}}$ 是每元素字节数，$T$ 是被缓存的词元数。因子二是为键与值，即每个被注意到的词元贡献的两个向量：用来与查询匹配的键，以及被加权汇入输出的值。缓存随序列长度线性增长，也随并发请求数线性增长，而且它住在与权重同一份稀缺加速器内存里。压力由此变得清楚：权重占去一块固定的内存切片，剩下的全部在当前在飞的各请求的 KV 缓存之间瓜分。能批进多少请求，从而吞吐量与有效吞吐量的上限，取决于剩下多少 KV 缓存内存、以及用得多有效。图 31.4 展示了这道划分，而 图 31.3 把这种线性增长及其后果具体化：每个请求的缓存随上下文长度沿一条直线上升，剩下的池则决定能同时容纳多少个这样的请求。

这就是为什么架构章的注意力变体对一个服务工程师如此要紧。多查询注意力（MQA）（多查询注意力，让多个查询头共享同一套键/值头）与分组查询注意力（GQA）（分组查询注意力，让一组查询头共享键/值头）缩小 $n_{\text{kv}}$，多头潜在注意力（MLA）压缩被缓存的状态，每一种都直接削减每词元的 KV 字节数。它们的设计，部分正是为了松开这道服务约束。至于 $T$ 增长到数十万时会发生什么，第 35 章 会再回来谈。

少浪费缓存的四步

一旦把缓存认定为主要约束，服务引擎的历史就可以概括为「少浪费一点缓存」。服务栈是靠一次去掉一处浪费，才得到如今形状的，而每一次去掉，在成为一个内核之前，都先是一个调度思想。

别再占着一个已完成请求的槽位。 最早的系统像 Web 服务器服务 HTTP 那样服务请求：攒一个批，跑到完成，返回这个批。这是请求级批处理，它把加速器浪费得很厉害，因为批中一个短生成早早完成，然后空转着等最长那个生成跑完，同时占着它的槽位。Orca 用迭代级调度取代了请求级批处理：调度器在单个解码步的粒度上决定跑什么，于是一个完成的请求立刻离开批，一个新到的请求无需等其余请求就能加入 (Yu et al. 2022)。这个思想，通常称为连续批处理（continuous batching），是每个现代引擎的地基。

别再预留用不上的缓存。 迭代级调度暴露了下一个瓶颈，那就是内存。连续批处理能在槽位一打开的瞬间就接纳一个请求，但前提是有 KV 缓存内存来容纳它，而早期引擎按最大可能长度，为每个请求分配一整块连续内存。多数请求远短于那个最大值，于是多数被预留的内存空着，把内存池碎片化，把批大小压在远低于硬件能跑的水平。PagedAttention 分页注意力（PagedAttention） 与 vLLM 引擎从操作系统那里借来了虚拟内存的分页：把 KV 缓存存进固定大小的块，这些块不必连续，随序列增长按需分配块，并让一张块表把逻辑位置映射到物理块 (Kwon et al. 2023)。碎片化显著减少，批增大，吞吐量在相同延迟下据报上升两到四倍 (Kwon et al. 2023)。那套分页的机制、以及它如何让跨请求的前缀共享成为可能，第 32 章 会专门展开；在这里，看见上文点名的内存压力怎样催生这个设计，就够了。

别再让一次预填充阻塞解码。 最近的一个转折正面处理预填充与解码之间的紧张关系。接纳一个新请求会跑一次昂贵的预填充，与已在飞的解码请求争抢资源：偏向预填充则 TTFT 改善，而正在输出的请求变得不平稳；偏向解码则 TTFT 上升，而进行中的流保持顺滑。因为一次预填充是一阵大的计算爆发，一个解码步是小的，把它们混在一个批里，会让一次预填充阻塞排在后面等待的解码请求，使它们的 TPOT 出现尖峰。出现了两类方案。Sarathi-Serve 把两个阶段留在同一份硬件上，但把每次预填充切成块、与进行中的解码交错，于是没有解码被一个长提示词阻塞 (Agrawal et al. 2024)。DistServe 走了另一条路，把两个阶段拆分到分开的加速器池上，于是预填充干扰根本碰不到解码延迟，代价是要在池之间运送 KV 缓存 (Zhong et al. 2024)。二者都明确地在优化有效吞吐量，而非原始吞吐量，这正是为什么分块预填充与拆分，是让人不必在 TTFT 与 TPOT 之间二选一的两种有原则的办法。

余下取舍在哪里发生

上面那两个预填充与解码的答案，解决了服务的一道取舍。还剩三道，每一道都在延迟、吞吐量或内存之间，用一个去换另一个，而 KV 池是它们共同面对的约束。

• 批大小：吞吐量与延迟。 更大的解码批把权重流式读取的成本摊销到更多请求上，提高吞吐量，但它消耗更多 KV 缓存内存、拉长每一步，提高 TPOT。正确的批是仍能满足 TPOT SLO 的那个最大批，而它随请求长度变化而移动。图 31.5 以批大小为横轴画出两条曲线：吞吐量带着递减的回报接近一个带宽受限的上限，TPOT 则上升，被选中的批就坐在 TPOT 达到其预算的那一点。

• KV 缓存内存与被接纳的请求。 花在权重上的内存装不了 KV 缓存，花在缓存一个长上下文请求上的内存接纳不了一个新请求。当池满时，引擎必须要么拒绝或排队新请求，要么逐出并稍后重算一个被暂停请求的缓存，用内存压力换重算成本。

• 延迟下限与利用率。 留着加速器空闲作储备，能保护 TTFT 抵御突发，但浪费了服务之所以存在、本要变现的那份算力。有效吞吐量正是为这笔取舍定价的那个函数，因为它只在利用率产出满足 SLO 的完成时才统计它。

那个循环，以及它报告什么

一个服务引擎，其核心是一个循环：每次迭代选出一组要跑的请求，对它们跑一个模型步，并释放任何已完成请求的资源。下面这个形状，就是 Orca 引入、而每个现代引擎都在精炼的连续批处理循环 (Yu et al. 2022)。

# 连续批处理调度器的一次迭代（示意）。
while running or waiting:
    # 在 KV 缓存块空闲且 SLO 允许时，接纳新请求。
    while waiting and kv_pool.can_allocate(waiting.peek()):
        running.add(waiting.pop())          # 它的预填充加入这一步
    batch = scheduler.select(running)       # 可切块预填充，受内存约束
    outputs = model.step(batch)             # 一次预填充／解码传播
    for req in batch:
        req.append(outputs[req])
        if req.is_finished():
            kv_pool.free(req.blocks)        # 把块还回池
            running.remove(req)

关键决策不在模型步里，而在接纳请求与选择批的那两行里。kv_pool.can_allocate 是内存约束变成一个调度决策的地方，而 scheduler.select 是延迟-吞吐量权衡被敲定的地方：靠限制满足 TPOT 的批大小，靠把预填充切块使其不阻塞解码，靠针对 SLO 排序。一个真实引擎里对应的逻辑住在引擎步里，例如 vLLM V1 引擎的 EngineCore.step, vllm/v1/engine/core.py，它取代了旧的 LLMEngine 循环；批由 vllm/v1/core/sched/scheduler.py 里的调度器组成，块记账则在其 KV 缓存管理器里。

要紧的运维指标直接从问题里来。TTFT 与 TPOT 按请求度量，并作为百分位、而非均值来跟踪，因为一次尾部错过就是一次 SLO 错过。有效吞吐量是头条数字，按每秒满足 SLO 的完成数计算。KV 缓存利用率与抢占率，即引擎因内存耗尽而不得不暂停、稍后再恢复一个请求的频率，便表明当前是内存约束还是计算约束在起作用。当抢占上升，缓存就是瓶颈，解决方向是架构性的、在 第 32 章 里；当加速器满载而延迟尚可，吞吐量就是边界，解决方向在 第 33 章 与 第 34 章 里。

服务把模型能力换成有价格的行为：一个模型只有能在延迟预算之内被服务时，才交付出一种行为。效率是核心问题，因为每加速器的有效吞吐量正是让一种能力负担得起的条件。信任则以 SLO 本身的形式进入，即一个请求会准时返回的承诺，调度器必须在给定负载下守住它。

延伸阅读