企业官网建设流程全解析

HyperQwen 上下文复述加速：lookup 草稿如何把 25k 文档复读推到 381 tok/s

【免费下载链接】HyperQwenServe large Qwen models fast on the GPUs you actually own. Qwen3.8-27B on a single 24 GB card with vLLM: 127 tok/s single-user (381 when the answer quotes the prompt), ~1,035 tok/s at 64 concurrent, 150k-262k context. vLLM patches, requant pipeline, benchmarks.项目地址: https://gitcode.com/gh_mirrors/qw/HyperQwen

HyperQwen是一个用 vLLM 在你现有的消费级 GPU（如单张 RTX 3090，24 GB）上高速服务大型 Qwen 模型的开源项目。它的核心技巧之一叫lookup 草稿（lookup-augmented drafting）：当模型正在"复读"提示词里的内容——引用文档、重贴命令、改写代码——它不再靠小模型瞎猜，而是直接从请求自己的上下文里把答案抄出来，让大模型一次性验证 16 个 token。结果是：把一份 25k token 文档逐字复述，解码速度从 159 tok/s 推到381 tok/s（+139%），且输出分布完全不变、质量无损。

先看效果：381 tok/s 是怎么来的

所有数据来自 RTX 3090（限 250 W）、greedy 解码、25k token 上下文的实测。测试矩阵就在 bench/labd_bench.py，原理与逐项收益的完整推导见 docs/optimizations.md：

规律很清晰：复读越多，提速越大；普通写作用几乎免费地拿到 2-3% 的小增益。质量方面 GSM8K 保持在 96.5%，9 条长 greedy 提示词里有 7 条与关闭 lookup 的输出逐 token 一致。

瓶颈在哪：2048 窗口的草稿模型

HyperQwen 默认用DFlash2块草稿器做投机解码：一个 5 层小模型一次并行提出 7 个候选 token，再由大模型并行验证，一步就能落地近 8 个 token。

但它只有2048 token 的注意力窗口。当你的任务是"复述这份 25k 文档"时，接下来该说什么，答案一字不差地就在提示词里，而草稿模型根本看不见——它只能在 2048 窗口之外硬猜。

更坑的是，vLLM 原本把验证块长度绑定为草稿块长度（8），所以即使猜对了，一步最多也验证 8 个 token。实测中，逐字复读时 8 个草稿能中 7.83 个——卡在块上限上跑，而不是跑在上下文允许的速率上。

lookup 草稿的原理：三步走

整个机制由一个补丁实现：patches/dflash2-lookup-drafting.patch。

第 1 步：在后文里找"刚才说过什么"

每步解码前，一个 Triton 核程序（每个请求一个，与批大小无关）扫描该请求自己的 token 历史：找"刚生成的最长后缀（4-12 个 token）"最近一次出现的位置，把接在它后面的 token拿来当草稿提案。

关键细节：允许匹配与后缀重叠。这样"- 列表项"、缩进、代码围栏这类周期性模式也能被自己的周期命中，而不是漏掉。而且大部分候选在 4 个 token 的"拒绝测试"阶段就淘汰了，扩展搜索几乎不用付出代价。

第 2 步：与草稿模型的提案做"融合"，不是覆盖

lookup 命中的 token不花草稿模型任何算力（不需要额外的 mask token，不需要多跑一次候选头），所以它可以把验证块拉长到 16 个（DFLASH_TOKENS=15），草稿模型只出它训练的 7 个，剩下的位置由上下文免费填补。

融合规则区分了两种位置：

• 草稿头（前 7 位）：草稿模型已经提过名。只有 lookup 匹配 ≥8 个 token 才直接替换；较短的匹配（≥6）还要草稿模型独立猜中前 2 个 token 才采纳——两个独立信源（一个看隐状态、一个看文本）都同意，是廉价的置信信号，防止巧合的短匹配在普通文本上拖垮接受率。
• 草稿尾（后 8 位）：没人提过名，lookup 提供的都是白捡的，阈值放宽到 ≥4 即可。

第 3 步：长块只在"复制进行中"才调度

每个额外验证位置在 25k 上下文下要付出约 1 ms 的注意力开销，所以长块不是常驻的：

• 进入条件：lookup 有足够长的匹配可以填满尾部，且上一步几乎满块输出——连续两步才算数。一步饱和在普通行文里随时会发生（一个引用短语、一个重复的列表标记），连续两步才是"真的在复制"。
• 粘性退出（VLLM_DFLASH2_LOOKUP_STICKY=3）：匹配标志会因为各种原因临时掉线（一行匹配不上的文本、异步标志还没落地），立刻收回长块要花两步才能重新挣回来。所以标志掉线后继续保留长块 3 步。实测让同一 prompt 连续 6 次跑分稳定在15.21 tok/步 · 379 tok/s，关粘性则是 13.92 · 362，且波动明显。

整个模式仍是无损的：greedy 验证根本不读草稿分布；采样请求中，lookup 填补的每个位置都被改写成"对提案 token 的 point mass"，这是 vLLM 拒绝采样器合法的提案分布，输出分布与不开投机解码完全一致。

怎么开启：两个环境变量搞定

不需要写代码。在.env里加两行，重启即可（详见 single-user/README.md）：

printf 'SPEC=dflash2\nPREFIX_CACHE=1\n' >> .env # 如果你的回答经常引用/复述提示词，再加这行： echo 'DFLASH_TOKENS=15' >> .env docker compose --profile single up -d

各开关对应的文件位置：

• 模式总览与全部环境变量：single-user/README.md
• lookup 补丁与逐条收益推导：docs/optimizations.md
• 复读任务实测脚本：bench/labd_bench.py
• 混合批下逐字复述一致性 soak 测试：bench/labd_soak.py
• 配合用的前缀缓存（多轮聊同一份 24k 文档，后续轮 23 s → 1 s）：见 single-user/README.md

代价与适用场景：别为聊天白开 15

DFLASH_TOKENS=15（复现模式）是为特定负载准备的，代价是真实的：

原因：16 个 token 的验证块让每个驻留请求占用的循环状态页翻倍。实测聊天负载下，草稿块第 7-14 位只贡献了 0.65% 的接受 token——聊天场景开 15 只值 1%，却花掉一半槽位。

判断标准一句话：你的回答在复述输入吗？

• ✅ 开 15：RAG 前端引用原文、代码编辑应用 diff、"重贴这些命令"、翻译/改写保留代码
• ✅ 保持默认 7：普通聊天、agent 客户端
• 两者都可以叠加PREFIX_CACHE=1，它对两类负载都只赚不亏

小结

lookup 草稿证明了"上下文本身是最好的草稿来源"：

1. 草稿模型只看得到 2048 窗口，但提示词全文都在——答案就在手里，何必猜；
2. 免费获得的草稿让验证块从 8 拉到 16，一步落地 15 个 token；
3. 自适应调度保证长块只在复制进行中运行，普通文本零损失；
4. 融合 + point mass 改写保证逐 token 无损。

结果就是本文标题里的那行数字：25k 文档复读，159 → 381 tok/s，而且普通工作负载还顺带涨了 2-3%。更多优化细节与硬件复现报告，可以从 docs/optimizations.md 和 docs/reproductions/README.md 继续读起。

【免费下载链接】HyperQwenServe large Qwen models fast on the GPUs you actually own. Qwen3.8-27B on a single 24 GB card with vLLM: 127 tok/s single-user (381 when the answer quotes the prompt), ~1,035 tok/s at 64 concurrent, 150k-262k context. vLLM patches, requant pipeline, benchmarks.项目地址: https://gitcode.com/gh_mirrors/qw/HyperQwen