同一份长材料被反复提问，每次都重新计算全部输入，可能浪费不少预填充工作。前缀缓存复用已经算过的共同开头，但它匹配的是实际输入前缀，而不是“意思差不多”的文本。

复用的是计算状态

vLLM的自动前缀缓存复用共享前缀的KV状态，让后续请求跳过已缓存部分的预填充。它不是缓存整段答案：同一材料后面接不同问题，仍然需要处理新增输入并生成新的回答。

例如两个请求的token序列是[10,11,12,13,14]与[10,11,12,15]。共同前缀长度为3。这些整数只是教学ID，没有对应真实tokenizer。

先算一个理想上界

不复用时，两次输入共有5+4=9个单位；理想复用完整共同前缀时，第二次只增加1个单位，总共5+1=6个单位。减少3个输入单位不等于延迟下降三分之一：实际成本不是简单按token数线性相加，而且还包含排队、调度和生成。

def common_prefix(a, b):
    n = 0
    for x, y in zip(a, b):
        if x != y: break
        n += 1
    return n

first = [10, 11, 12, 13, 14]
second = [10, 11, 12, 15]
assert common_prefix(first, second) == 3
assert common_prefix(first, [99] + second) == 0
assert common_prefix([], second) == 0
assert common_prefix(first, first) == 5
raw_units = len(first) + len(second)
ideal_units = len(first) + len(second) - common_prefix(first, second)
assert (raw_units, ideal_units) == (9, 6)
print('shared prefix:', 3)
print('input units without / with ideal reuse:', raw_units, ideal_units)

代码已经执行，验证共同前缀、首位不同、空输入与相同输入的情况。它只算序列匹配和输入单位，没有运行vLLM。若共同文本被移到不同位置，就不能用这个共同开头模型直接声称命中。

哪些调整值得测试

把稳定的系统说明和重复材料放在前面，把变化的问题放在后面，有机会增加相同前缀。但不要为缓存而改变任务含义；模板、空白、消息组织与tokenization的变化也可能改变实际序列。

vLLM文档明确指出，前缀缓存主要减少预填充工作，并不直接减少生成新token的解码工作。长输出、几乎没有共享前缀或缓存已被淘汰时，收益可能有限。

测试时分别比较冷缓存与热缓存，固定输入和输出长度，并观察首token时间、总延迟和缓存命中。不要把热缓存的结果当成所有请求都能获得的收益。已有KV cache显存估算还提醒我们，缓存本身也需要资源预算。

English version

参考资料

Official documentation

补发说明：实际补发日期为北京时间2026年10月10日，文章日期保留原计划2026年10月10日09:00。代码为原创教学验证，没有运行真实模型性能测试。