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 服务实测。

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

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

把 BF16 模型换成 4bit，显存占用明显降了，生成速度却只涨了一点。该怀疑量化方案，还是推理框架？

先别急着换框架。模型文件的大小、一次前向需要搬运的数据量、GPU 完成这些工作的时间，是三件不同的事。量化直接改变其中一部分，剩下的部分可能很快成为主要开销。

这篇文章只讨论稠密自回归模型的权重量化，重点是 W4A16 的 Decode 阶段。这里 W 表示权重精度，A 表示激活精度；不把原生低精度计算、KV Cache 量化、MoE 或跨卡通信混到同一个加速数字里。Prefill 与 Decode 的基本区别，可以先看系列第一篇。

4bit 描述的是哪一段数据

W4A16 的含义不是“整个模型用 4bit 计算”。以 TensorRT-LLM 文档中的 weight-only 路径为例，权重以低位宽存储，线性层使用时进行反量化，激活仍为 FP16 或 BF16。官方精度说明把 W4A16 与其他精度方案分开列出。

只算权重存储，也未必能从 16bit 精确降到四分之一。假设原权重占 W 字节，其中比例 f 被量化；每 G 个被量化的权重共用一个 16bit scale，暂不考虑 zero-point、对齐和其他元数据，那么：

量化后权重 / 原权重 ≈ (1 - f) + f / 4 + f / G

最后一项来自 scale：原来每个权重是 2 字节，一组 G 个权重额外保存 2 字节，所以相对于原权重的比例是 f / G。

取 f = 0.9，G = 128，结果约为 0.332。这个假想格式的压缩比约 3.01 倍，尚未计入工作区、激活、KV Cache 和分配器预留。它说明为什么“4bit 模型”不足以推算进程总显存；实际数字要看格式和加载结果。

Decode 每一步，还要读什么

考虑一个简化场景：单卡、稠密模型、完整因果注意力，一个 Decode 批次包含 B 条序列，每条生成一个 token。忽略片上缓存复用差异，假设批内共享一次权重读取，历史 KV 各读一次。

这一步的主要读取量可以粗估为：

读取量 ≈ W + B × K

W 是整次前向需要读取的权重字节数；K 是一条序列当前历史 KV 的总字节数。式子省略了激活读写、新 KV 写入、scale 读取以及其他算子流量，因此只是定位瓶颈的模型，不能直接当作 profiler 结果。

对使用常规 K、V 布局的完整注意力，单条序列每个历史 token 的 KV 大小为：

c = 2 × L × Hkv × D × bytes_per_element
K = S × c

其中 2 对应 K 和 V，L 为层数，Hkv 为 KV 头数，D 为头维度，S 为上下文长度。假设 L=32、Hkv=8、D=128，KV 使用 2 字节精度，则 c=128 KiB/token。当 S=8192 时，每条序列的历史 KV 就有 1 GiB。

这一步没有改变 KV 精度。权重量化之后，这 1 GiB 仍然在。

下面另设一组便于心算的权重数字：BF16 路径每步读取 14 GiB，量化路径连同相关元数据读取 4 GiB。这两个数是独立的假设输入，不是上面 f、G 示例的测量结果。 假设两条路径的有效带宽均为 1 TiB/s，暂时忽略计算和额外开销：

所有数字都是计算示例。两条路径各有相同的 B，不是在拿单请求和高并发互相比。

加速比来自：

Sread = (W16 + B × K) / (W4 + B × K)

当 B × K 越来越大，分子和分母里相同的部分占比升高，加速比便趋近 1。反过来，如果上下文很短、批次很小，权重流量占主导，权重量化就更值得优先验证。

还有一个容易误读的地方：B 增加时，表中的一步耗时也增加，但一步产出了 B 个 token。系统吞吐应按 B / step_time 算，不能只看一步越来越慢就认定总吞吐下降；同样，总吞吐增加也不意味着每个用户的输出间隔更短。

把反量化和计算放回去

TensorRT 的 weight-only 实现会读取 4bit 权重，再反量化并做高精度点积。低位宽存储因此不自动等于同倍数的算术加速。TensorRT 11.2.1 的实现说明直接描述了这条执行路径。

用一个粗略的 roofline 视角，可以把单步时间写成：

Tstep ≳ max(实际搬运字节 / 有效带宽, 实际运算量 / 有效算力)

这不是把整个模型当成一个能完美重叠的大算子。真实前向由许多有依赖的算子组成，还要考虑调度、同步和启动开销。它的用处是提醒我们：降低字节数，只压低了其中一个约束。

反量化也不能机械地当成一段独立时间加上去。有的实现把它融合到矩阵乘里，与访存或计算部分重叠；有的形状却会因解包、寄存器压力或低效内核丢掉收益。应该看实际执行的 kernel 和时间分布。

为了估算余量，可以暂时再作一个更强的假设：两条路径都只受带宽限制，而且量化路径多出一段无法重叠的额外耗时 Δ。那么量化更快的条件是：

Δ < (W16 - W4) / BW

在上表的假设下，右边约为 9.77 ms。超过它，少搬权重省出的时间就被抵消。这个阈值与 B 无关，是因为模型假设两条路径的 KV 流量、带宽完全相同；实际内核一变，这个简化条件也要重算。

一个可以自己改参数的计算器

下面的 Python 只依赖标准库，保存后直接运行。它不调用 GPU，也不预测某张显卡的性能。compute_floor_ms 和 extra_ms 是留给读者探索边界的假设参数，不能不经测量就填成“真实开销”。

GiB = 2**30
TiB = 2**40

def step_ms(weight_gib, batch, kv_gib=1.0, bandwidth=TiB,
            compute_floor_ms=0.0, extra_ms=0.0):
    read_ms = (weight_gib + batch * kv_gib) * GiB / bandwidth * 1000
    return max(read_ms, compute_floor_ms) + extra_ms

print("B  bf16_ms  w4_ms  speedup")
for batch in (1, 8, 32):
    bf16 = step_ms(14, batch)
    w4 = step_ms(4, batch)
    print(f"{batch:2d} {bf16:8.2f} {w4:6.2f} {bf16 / w4:7.2f}")

# 人为加入 12 ms 无法重叠的额外开销，构造更慢的反例。
print("extra_12ms_speedup:", round(step_ms(14, 1) /
      step_ms(4, 1, extra_ms=12), 3))

# 同样的 50 ms 计算约束主导两条路径：搬运减少也不改变结果。
print("compute_bound_speedup:", step_ms(14, 1, compute_floor_ms=50) /
      step_ms(4, 1, compute_floor_ms=50))

最后两行分别得到约 0.868 和 1.0。前者是额外开销吃掉收益的反例，后者是计算约束盖住访存收益的反例。这两种情况都不需要“量化失败”才能发生。

长输入 Prefill 应单独测量。一次处理更多 token 会改变矩阵形状和权重复用程度；Decode 上得到的比例，没有理由原样搬到 Prefill。

实际选型时，把两场实验分开做

第一场实验固定工作负载，回答“相同工作是不是更快”。使用同一模型来源、tokenizer、输入 token、输出长度设置和 KV 精度，在同一 GPU 上比较 BF16 与 W4A16。保持推理框架、注意力实现等尽可能一致，记录无法一致的部分；固定一个可容纳的批次后，再分别测短、长上下文。单独记录 Prefill、Decode、端到端延迟，以及真正执行的 kernel。

第二场实验允许利用量化省下的显存，回答“同一硬件能服务多少人”。逐步增加负载，比较满足首 token 延迟和输出间隔要求的吞吐。此时更高吞吐可能来自容纳了更多 KV，而不是每个请求本身更快。报告里应把这个原因写出来。

两场实验都需要先过质量门槛。位宽和误差之间没有一个适用于所有模型、所有任务的固定换算。AWQ 论文利用激活统计识别重要通道并调整缩放，说明权重如何量化同样关键；论文中的效果不能替代你自己的任务检查。

做代码生成，就检查可执行正确率；做结构化提取，就检查字段准确率和格式通过率。测试数据与量化校准数据分开，尤其保留真实业务中较长、较难的输入。若质量不达标，先比较更合适的校准方式或更高精度方案，再讨论吞吐。

当结果不符合预期，可以按观察到的现象缩小范围：

量化值得做的理由可以是省显存、降低单请求延迟，也可以是在同样延迟要求下多接请求。先把希望得到的收益说清楚，后面的测试才不会被一个漂亮的“4bit”标签带偏。

技术资料核对日期：2026-09-05。本文代码用于验证计算关系，未进行 GPU 性能实测；运行时请以所用版本的文档和 profiler 结果为准。

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