你让 AI 客服同时接待很多人，本想靠两项“省时技巧”加速，结果它可能把本该分开的答题草稿弄混。最近一名 Reddit 用户报告称，Qwen3.6 27B 或 35B 在 vLLM 中同时开启前缀缓存和推测式解码后，出现了输出损坏和质量下降。它值得关注，不是因为模型慢了，而是提速配置可能动摇答案本身。不过，目前全部信息来自同一篇用户帖，没有官方说明、独立复现或可核查的错误样例，“串数据”仍是尚未证实的具体解释。
两项提速功能，为什么会互相添乱？
vLLM 是一个大模型服务引擎，负责批量处理请求、利用显存，并支撑多人同时使用模型。这里，它是 Qwen 在线运行的底座。
前缀缓存会保存多个请求共有开头的计算结果。比如所有客服对话都使用同一段系统提示词，服务便不必每次重算。推测式解码则先快速提出多个候选 token——也就是模型生成文字时的基本单位——再交给主模型批量核验，减少逐字等待。
两者单看都在节省重复劳动，但组合使用要求缓存、文字位置和请求状态严格对应。尤其在高并发下，服务同时处理多条请求，更容易暴露状态隔离问题。供稿者将自己遇到的“corruption problems”归因于这一组合，并指向 vLLM PR #48375，称其中补丁解决了其质量下降问题。
这仍只能算个案线索。帖子没有展示损坏后的输出，也没有说明究竟是请求间状态混入、文本错乱，还是其他质量异常。因此，现有材料不足以确认真的发生了“串数据”。同样无法确认该补丁是否已经合并、发布，或能否解决其他部署中的问题。
“下降近 20 个百分点”说明了什么？
供稿者称，Qwen/Qwen3.6-27B-FP8 在 vLLM 下，相比 llama.cpp variants 出现显著的性能或质量下降，高负载、高并发时尤其明显；其质量基准下降接近 20 个百分点。
这个数字听起来严重，却不能外推成“Qwen 普遍下降 20%”。帖子没有披露基准名称、样本量、并发参数、软件版本和原始结果，而且混用了 performance、quality 与 absolute terms。对比的权重和量化方案也可能不同：帖子同时提到 FP8 safetensors、Unsloth UD-Q4_K_XL 等配置，无法把差异直接归因于缓存与推测式解码。
帖子还称，若未设置 PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True，模型会臆造工具名称。这个因果关系反常，材料也没有提供验证，应只视为供稿者的经验性注释。
真正的提醒是：速度不能替代正确性
我们在 7 月 12 日的 HY3 报道中介绍过 KV cache——模型保存中间计算结果的“草稿纸”——与推测式解码，也提醒过不同运行路径的性能不能直接比较。这次的线索把问题推进了一步：生产部署不能只看吞吐量和延迟，还要检查功能组合是否改变输出。
对部署者而言，这则帖子尚不是已确认的通报，更像一枚需要认真验证的警报。若线上系统同时使用前缀缓存和推测式解码，关键问题不是“能快多少”，而是高并发下，同一批输入能否稳定得到正确且彼此隔离的输出。
局限与未知
- 全部结论来自同一篇 Reddit 用户帖，缺少官方事故说明和独立复现。
- 帖子没有给出可复现配置、错误输出或完整测试数据，准确型号与权重描述也不一致。
- PR #48375 的正文未在材料中提供，无法确认补丁状态、作用范围及普适性。