Jellow 编辑发布，AI 辅助生成并完成技术核对。 计算示例和实测结果会在文中分别说明。

同一个模型服务，调大批处理预算后，监控上的 output tokens/s 更高了，聊天界面却开始一顿一顿地输出。两个现象可以同时成立：GPU 每秒产出了更多 token，但某个用户的相邻两次输出隔得更久。

要理解这个取舍，不能只看一场压测的总吞吐。需要把镜头拉近到每次调度：这一轮让谁运行、允许带进来多少新输入、已经开始输出的人要等多久。

本文用一个几十行的调度模型解释连续批处理和分块 Prefill，再讨论怎样把测试目标从“最大 tokens/s”改成“在延迟要求内完成多少请求”。所有耗时都是教学用假设，没有对应的 GPU 实测成绩。

连续批处理解决的是批次更新问题

传统的固定批次可以让一组请求一起进入，整组完成后再换下一组。长短输出混在一起时，短请求已经结束，空出来的位置却未必马上能接新请求。

连续批处理把决策点推进到生成迭代之间：一轮结束后，移除已完成的请求，有资源时加入其他请求，再运行下一轮。Orca 的 iteration-level scheduling 是理解这一思路的一手资料；它还提出了 selective batching，不能把整个系统简化成“多加一个循环”。Orca 论文与会议页面说明了两者的分工。

但能在轮次之间换人，不代表一个很长的 Prefill 不会阻塞正在 Decode 的请求。调度器可以在下一轮重新选择，却通常不能任意切开一个已经提交执行的大计算片段。

因此这里有两个不同的问题：

两者可以配合，但开启前者不会自动证明后者的预算适合当前负载。

把一次长 Prefill 放进时间轴

设想已有两条请求持续 Decode，观察期间它们都不会结束。现在来了一条含 4096 个输入 token 的新请求。

为了只看调度取舍，作如下假设：现有两条请求每轮的 Decode 总成本固定为 4 ms；新请求完整 Prefill 的成本为 64 ms，暂按输入 token 线性分摊；每轮另有 0.5 ms 固定开销。各项顺序执行、不重叠，已有请求的下一次输出统一在轮末交付。

如果一轮允许处理 c 个 Prefill token，则：

单轮耗时 = 4 + 64 × c / 4096 + 0.5   ms

最后一轮按实际剩余 token 数计算。在此模型里，已有请求的输出间隔就是这一轮耗时，新请求的 Prefill 完成时间则是这些轮次耗时之和。

把一整块拆成四块后，已有用户等待下一次输出的最长间隔大幅缩短；新请求的 Prefill 却从 68.5 ms 后完成变成 82 ms 后完成。拆到十六块，已有请求更平滑，新请求还要等更久。

差出来的时间并不全是浪费。现有两条请求在更多轮次里继续生成了 token，只是这些工作让新请求更晚完成 Prefill。固定的每轮开销也付了更多次。

这里特意写“Prefill 完成时间”，没有把它直接叫 TTFT。真实首 token 延迟还包含排队、输出头、采样与回传等阶段；这个模型也没有模拟混合 batch 的矩阵乘效率、KV 随生成增长的开销或 CPU/GPU 流水重叠。

运行一下，再改变假设

下面代码只用 Python 标准库。把 chunk_tokens 改成不能整除 4096 的数，也可以检查最后一轮是否按剩余输入计时。

from math import ceil

def simulate(chunk_tokens, prompt_tokens=4096, decode_ms=4.0,
             full_prefill_ms=64.0, overhead_ms=0.5):
    if chunk_tokens <= 0 or prompt_tokens <= 0:
        raise ValueError("token counts must be positive")
    remaining = prompt_tokens
    now = 0.0
    gaps = []
    while remaining:
        take = min(chunk_tokens, remaining)
        prefill_ms = full_prefill_ms * take / prompt_tokens
        step_ms = decode_ms + prefill_ms + overhead_ms
        now += step_ms
        gaps.append(step_ms)  # 已有 Decode 请求每轮末收到一个 token
        remaining -= take
    return len(gaps), max(gaps), now

print("chunk rounds max_gap_ms prefill_done_ms")
for chunk in (4096, 1024, 256):
    rounds, gap, done = simulate(chunk)
    print(f"{chunk:5d} {rounds:6d} {gap:10.1f} {done:15.1f}")

rounds, gap, done = simulate(1000)
assert rounds == ceil(4096 / 1000)
assert done == 64 + rounds * (4 + 0.5)
print("chunk_1000:", rounds, gap, done)

最后一行得到 5、20.125、86.5。五轮总 Prefill 工作仍为 64 ms，外加五次 Decode 和固定开销。读者可以把 decode_ms 或 overhead_ms 调高，观察继续缩小块长为什么会越来越昂贵。

真实服务里，Prefill 时间并非严格随 chunk token 数线性增长。后面的 chunk 要关注更长的历史，不同形状也会触发不同执行效率。所以这段代码适合解释因果关系，不适合据此宣布某个具体 token 预算最优。

在 vLLM 中，token 预算不是请求数

vLLM 的调优文档描述了分块 Prefill 下优先安排 Decode，再用剩余 token 预算安排 Prefill 的策略；放不下的长输入可以拆分处理。文档也指出，较小预算通常更有利于输出间隔，较大预算有利于推进 Prefill。vLLM 调优说明可以用来核对所用版本的实际行为。

这给出了调参方向，但没有给所有模型一个通用答案。尤其要区分 max_num_batched_tokens 和 max_num_seqs：前者约束一轮可调度的 token 数，后者限制一轮可处理的序列数，具体定义见引擎参数文档。一个长 Prefill 请求就可能消耗很多 token 预算；普通自回归 Decode 则通常每条序列每轮推进一个 token。

因此，本文模拟里的“每轮 Prefill 上限 1024”，不等于把实际引擎的总 token 预算直接设成 1024。后者还要容纳 Decode token，并受序列数、KV 空间和调度细节共同约束；推测解码、多模态输入等也会改变预算的解释。

比较时应记录实际引擎版本和完整启动参数。先固定序列数上限，只改变 token 预算，观察 Prefill/Decode 混合负载；不要同时改量化、并行度和请求长度，否则很难知道收益来自哪里。

两种压测，回答的是不同问题

固定并发压测常见的做法是：始终维持 N 个在途请求，完成一个再补一个。忽略思考时间，处于稳定状态时，到达率近似满足：

到达率 ≈ N / 平均完整请求耗时

假设 N 为 32，平均请求耗时是 2 秒，对应约 16 请求/秒。若服务变慢到 4 秒，压测工具实际补充请求的速率也降到约 8 请求/秒。这个闭环模型适合测固定在途负载，但客户端会随着服务变慢自动减速，不能单凭它证明服务能承受固定的外部到达率。

如果用户请求本来按独立节奏到来，服务变慢时，新请求不会自动减半。此时应补一场固定到达负载的测试，保留到达时刻、实际发出时刻和完成时刻，确认压测机或客户端并发上限没有悄悄改变计划。

两场测试都要保持输入与输出长度分布、采样参数和缓存冷热条件可比。某组输出更短，可能看起来请求完成更快；某组长请求超时后被丢出统计，尾延迟也可能虚假地变好。错误和超时必须单独记录，并保留在请求总数的分母里。

平均输出间隔，会藏起哪种停顿

假设一条回答有 100 个相邻 token 间隔，其中 99 个间隔是 10 ms，另一个是 500 ms。平均值为 14.9 ms，看上去并不惊人，但用户会清楚感受到中间停了半秒。

若采用最近秩定义，这 100 个间隔的 p99 还是 10 ms：排序后的第 99 个值仍在那 99 个短间隔里。采用插值的分位数实现可能得到别的数，因此连“p99”也必须带上统计口径。

更需要注意的是采样单位。一条请求的平均每 token 时间、所有流式响应间隔的分布、每条请求最大停顿的分布，是三组不同的数据。很多协议一次会回传多个 token，网络缓冲又会改变客户端观察到的间隔，不能把流式 chunk 不加区分地当成一个 token。

例如 GenAI-Perf 的指标定义会把相邻响应时间除以后一个响应中的生成 token 数，用于计算 ITL；它并不等于逐个 token 在 GPU 上完成的精确时间。其官方指标表可用来理解口径。此处引用定义，不要求读者选用某个压测工具。

对交互服务，除了 TTFT 和常规 ITL，可以额外记录每条请求最大的客户端停顿、超过某个停顿阈值的请求比例，并把网络传输层和引擎内部耗时放在一起排查。

用达标请求数决定配置

先把服务要求写清楚。比如人为设定：首 token 在 1 秒内到达、整条回答里最长输出停顿不超过 100 ms，且请求成功完成。阈值只是例子，应由实际产品体验决定。

将一个完整测试批次从开始发送到全部结束或超时的时间定义为 T，则这场测试的达标请求吞吐可以定义为：

goodput = 同时满足全部条件的请求数 / T

比较不同配置时，用同一套计时边界、超时规则和请求序列；如果采用稳态窗口，还要说明跨窗口请求如何归属。不要把达标比例、请求吞吐和输出 token 吞吐混成一个数。

例如同样 100 秒的两个假设测试，A 完成 1000 个请求，只有 600 个达标；B 完成 900 个请求，有 810 个达标。A 的完成吞吐更高，goodput 却是 6 请求/秒，低于 B 的 8.1 请求/秒。此时继续追求 A 的最大吞吐，很可能背离用户需要。

实际调参可以从一组保守配置开始，在相同到达负载下逐档增加 token 预算。每档同时记录 TTFT、停顿分布、goodput、失败率和 KV 压力。已有用户停顿超标时，检查是否被长 Prefill 拉长了轮次；首 token 太慢而 Decode 很平稳时，再看是否预算过小或等待过久。

如果两类延迟都随负载恶化，缩放 chunk 未必能解决总容量不足。它决定有限资源如何分配，不能凭空增加资源。此时需要判断是否该降低接入负载、增加副本，或重新安排不同服务等级的请求。

一个值得保留的配置，应当能解释它让谁更快、让谁多等，以及在什么负载下开始越过延迟要求。这样得到的吞吐数字，才与聊天窗口里的体验连得上。

技术资料核对日期：2026-09-05。示例为 CPU 上运行的调度模型与手算数据，不是 vLLM 内部调度器的复刻，也不是 GPU 基准测试。

模型推理加速专题 · 先分清 Prefill、Decode 和指标 · 内容生成、审核与纠错说明

Jellow 编辑发布，AI 辅助生成并完成技术核对。 计算示例和实测结果会在文中分别说明。

假设一项问答服务打开了前缀缓存，监控上显示 90% 的请求命中，用户却仍要等很久才看到回答。缓存是不是没起作用？

还不能这么判断。“有多少请求碰到了缓存”没有回答两个更关键的问题：省掉了多少工作，以及这份工作原本占等待时间的多少。

本文沿着这两个问题展开。讨论范围是完整因果注意力模型、可复用的前缀 KV，以及普通自回归生成。滑动窗口、混合注意力和跨节点缓存传输都有额外条件，不能直接照搬这里的块数和成本估计。

命中的是 token 前缀，不是相似的问题

前缀缓存保存已经计算过的 KV。新请求如果使用相同前缀，可以跳过相应的 Prefill。它不会因为两句话意思接近，就把一句话的 KV 交给另一句话使用。vLLM 的 APC 功能说明明确把收益定位在共享前缀的计算复用，而非后续生成过程的直接提速。

判断是否相同，应看 chat template、tokenizer 等处理之后真正送进模型的输入。肉眼看起来一样的正文，如果模板、分隔符或前面的内容不同，最终前缀可能不同。

在 vLLM 的哈希块设计中，一个块的身份还依赖前面的块，并包含必要的额外标识，例如 LoRA、多模态输入或缓存隔离信息；该设计只缓存完整块。官方设计文档给出了这些条件。

由此可以推导一个很实用的排查顺序：先确认输入序列和运行上下文真的可复用，再讨论缓存是否足够大。如果一个会变化的时间戳被拼在提示词最前面，后面几千 token 的稳定说明也不能作为相同前缀直接命中。

对于适合调整的业务模板，可以把稳定说明、固定文档放在前面，把本次问题放在后面。但不要只为命中率重排会改变含义的指令，也不要把不同权限或不同租户的数据混在一个共享范围里。模板改动之后仍要检查回答质量。

完整块还有一个取整问题。假设块长为 16 token，两次请求共享的前缀长 1000 token，那么完整共享块覆盖的是：

floor(1000 / 16) × 16 = 992 token

这里的 16 是示例参数，不是对所有后端默认值的声明。实际可复用量还受块是否仍驻留、运行配置是否兼容等条件影响。另外，vLLM 的 KV 管理代码说明，为获得最后位置的 logits，完整命中时仍需重算；块对齐还可能扩大重算范围。因此不能据此断言 Prefill 耗时必为零。

90% 命中，可能只省了 1.54% 的输入 token

为避免与某个框架的监控命名混淆，先自行定义两个统计口径。第 i 个请求的输入长度为 nᵢ，实际复用长度为 hᵢ：

请求命中率 = hᵢ > 0 的请求数 / 总请求数
token 复用率 = Σhᵢ / Σnᵢ

有些监控指标按块查询次数计数，既不是第一个，也不是第二个。看到 hit_rate 时，先查分子、分母和统计窗口。

构造 100 个请求：

请求命中率的确为 90%。但总输入有 93,440 token，实际只复用了 1,440 token，token 复用率约为 1.54%。

这并不矛盾。大量短请求各碰到一个小前缀，就足以让“命中的请求数”很好看；真正占输入大头的长请求可能一次都没复用。

如果那 10% 未命中的长请求又恰好最慢，整体 p95 仍可能落在它们当中。缓存帮助了多数请求，也不保证最慢一段用户的体验同步改善。这里应按长度和是否命中分组看延迟分布，不能对几组 p95 做加权平均来拼出整体 p95。

token 复用率也不等于计算节省比例

即使知道复用了多少 token，仍然少了一步：原来每个 token 要做的工作并不完全相同。

对长度为 n 的完整因果注意力，注意力中有效的 query-key 位置对数量是 n(n+1)/2。为了区分随 token 数增长的工作和随位置对增长的工作，构造一个成本模型：

C(n) = a × n + b × n(n+1)/2

a 汇总模型各层中按 token 线性增长的工作，b 表示每个有效注意力位置对的相对成本。它们是简化系数，不是通用硬件常数；矩阵形状、算子分块和 GPU 利用率都会让真实时间偏离这条曲线。

若前 h 个 token 已经缓存，后面还剩 m 个，其中 m=n-h。新 token 仍然需要关注前面的 h 个位置，所以剩余成本应为：

Cremaining = a × m + b × [m × h + m(m+1)/2]
           = C(n) - C(h)

不能写成 C(n-h)。那会漏掉后缀对已有前缀的注意力。缓存省掉的是前缀自身的计算，不是从注意力视野中删除这段上下文。

因此，假如缓存了 8192 token 输入的一半，在这个模型里线性部分省掉一半，而注意力位置对只省掉约四分之一。最终时间能省多少，还取决于两部分的比例和执行效率。这也解释了为什么“命中了 50% token”不应直接写成“Prefill 快了一倍”。

下面把前面的 100 请求例子完整算一遍。

requests = [(128, 16)] * 90 + [(8192, 0)] * 10

def cost(n, a=1.0, b=1.0 / 1024):
    # 人为选择的成本单位，不是微秒或 GPU FLOPs。
    return a * n + b * n * (n + 1) / 2

total_tokens = sum(n for n, h in requests)
reused_tokens = sum(h for n, h in requests)
request_hits = sum(h > 0 for n, h in requests)
uncached_work = sum(cost(n) for n, h in requests)
saved_work = sum(cost(h) for n, h in requests)

print(f"request_hit_pct={100 * request_hits / len(requests):.2f}")
print(f"token_reuse_pct={100 * reused_tokens / total_tokens:.2f}")
print(f"model_work_saved_pct={100 * saved_work / uncached_work:.3f}")

n, h = 8192, 4096
m = n - h
remaining = m + (m * h + m * (m + 1) / 2) / 1024
print("remaining_work:", remaining)
print("incorrect_suffix_only:", cost(m))
assert remaining == cost(n) - cost(h)
assert remaining > cost(m)

运行后，三个比例依次为 90.00%、1.54%、0.344%；后两行工作量为 28674.0 和 12290.0。示例中长输入占据大量注意力工作，却完全未命中，按这个成本模型算出的收益便比 token 复用率还小。

这些数字只验证推导。改变 a、b 或请求长度分布，结论的具体幅度会变；是否值得部署，仍要测真实 Prefill 时间。

首 token 的账里，还有排队

用户感知的 TTFT，是发出请求到收到第一个有效输出之间的时间。为了诊断，可以把关键路径概念性地拆成：

TTFT ≈ 输入处理与网络 + 排队 + 缓存查找/必要传输
       + 剩余 Prefill + 输出头与采样 + 首次回传

真实系统中一些阶段可以重叠，trace 里的字段也可能包含彼此；相加之前要先对齐口径。对 Prefill、Decode 与客户端指标不熟悉，可以结合第一篇的指标说明阅读。

假设一次请求排队 800 ms，Prefill 为 200 ms，其他开销暂记为零。缓存把 Prefill 降到 20 ms，而排队没有变化，那么 TTFT 从 1000 ms 变成 820 ms，只提升约 1.22 倍。

这不意味着缓存最多只有这点作用。如果缓存减少了全站计算压力，排队也可能随之下降。上面的例子特意固定排队，只是为了证明：单请求省下的计算时间，与整个服务最终少等的时间，需要分别测量。

多副本部署还会带来另一个取舍。假设副本 A 有缓存，但预计要排队 600 ms、剩余 Prefill 40 ms；副本 B 没有缓存，只排队 20 ms、完整 Prefill 200 ms。忽略其他开销，A 是 640 ms，B 是 220 ms。此时只按“去有缓存的副本”路由，会选错。

这也是一个假设案例，不是在推荐具体路由算法。它给出的决策条件是：缓存省掉的计算与传输，是否大于额外排队和路由成本。热点前缀的局部命中率再漂亮，也需要放回这个比较中。

怎样做一次不会高估收益的实验

先准备一份固定请求序列，保留真实的输入长度、共享前缀长度和到达顺序。只反复发送同一个长提示词，测到的是近乎理想的复用条件；它可以验证功能，却不能代表生产收益。

用同样的到达负载做三个对照：缓存关闭、缓存开启但从空状态开始、缓存开启且经过符合真实流量的预热。记录预热请求，但与正式窗口分开计时。不要用提前知道未来全部请求的方式构造“完美缓存”，再把结果当成正常服务表现。

每次请求至少关联这些数据：

缓存分组可用内部标识关联，通常不必把完整用户提示词写进性能日志。

当结果不理想时，顺序也很重要。复用 token 本来就少，先检查模板和流量结构；复用多但 Prefill 没降，检查实际是否重算以及成本模型是否适合该架构；Prefill 已明显下降而 TTFT 不动，再看队列、路由、传输和客户端缓冲。

缓存优化最终应该交付一件具体的东西：在相同请求到达条件下，哪些请求的等待下降了多少，哪些仍然没有受益。命中率是解释这个结果的线索，不是结果本身。

技术资料核对日期：2026-09-05。代码在 CPU 上验证统计口径和成本恒等式；文中耗时均为假设示例，未进行 GPU 服务实测。

模型推理加速专题 · 内容生成、审核与纠错说明