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/HyperQwenHyperQwen是一个用 vLLM 在你现有的消费级 GPU如单张 RTX 309024 GB上高速服务大型 Qwen 模型的开源项目。它的核心技巧之一叫lookup 草稿lookup-augmented drafting当模型正在复读提示词里的内容——引用文档、重贴命令、改写代码——它不再靠小模型瞎猜而是直接从请求自己的上下文里把答案抄出来让大模型一次性验证 16 个 token。结果是把一份 25k token 文档逐字复述解码速度从 159 tok/s 推到381 tok/s139%且输出分布完全不变、质量无损。先看效果381 tok/s 是怎么来的所有数据来自 RTX 3090限 250 W、greedy 解码、25k token 上下文的实测。测试矩阵就在 bench/labd_bench.py原理与逐项收益的完整推导见 docs/optimizations.md任务25k 文档greedy无 lookup默认DFLASH_TOKENS7DFLASH_TOKENS15逐字复述前 60 行4.72 tok/步 · 159 tok/s7.83 · 26014.97 · 381缩短文档但保留命令2.70 · 903.19 · 1073.50 · 113引用并解释3.01 · 1013.21 · 1073.35 · 110自由总结 / 问答2.15 · 722.08 · 692.13 · 718 条短聊天3.22 · 1263.33 · 1313.42 · 133规律很清晰复读越多提速越大普通写作用几乎免费地拿到 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_TOKENS15草稿模型只出它训练的 7 个剩下的位置由上下文免费填补。融合规则区分了两种位置草稿头前 7 位草稿模型已经提过名。只有 lookup 匹配 ≥8 个 token 才直接替换较短的匹配≥6还要草稿模型独立猜中前 2 个 token 才采纳——两个独立信源一个看隐状态、一个看文本都同意是廉价的置信信号防止巧合的短匹配在普通文本上拖垮接受率。草稿尾后 8 位没人提过名lookup 提供的都是白捡的阈值放宽到 ≥4 即可。第 3 步长块只在复制进行中才调度每个额外验证位置在 25k 上下文下要付出约 1 ms 的注意力开销所以长块不是常驻的进入条件lookup 有足够长的匹配可以填满尾部且上一步几乎满块输出——连续两步才算数。一步饱和在普通行文里随时会发生一个引用短语、一个重复的列表标记连续两步才是真的在复制。粘性退出VLLM_DFLASH2_LOOKUP_STICKY3匹配标志会因为各种原因临时掉线一行匹配不上的文本、异步标志还没落地立刻收回长块要花两步才能重新挣回来。所以标志掉线后继续保留长块 3 步。实测让同一 prompt 连续 6 次跑分稳定在15.21 tok/步 · 379 tok/s关粘性则是 13.92 · 362且波动明显。整个模式仍是无损的greedy 验证根本不读草稿分布采样请求中lookup 填补的每个位置都被改写成对提案 token 的 point mass这是 vLLM 拒绝采样器合法的提案分布输出分布与不开投机解码完全一致。怎么开启两个环境变量搞定不需要写代码。在.env里加两行重启即可详见 single-user/README.mdprintf SPECdflash2\nPREFIX_CACHE1\n .env # 如果你的回答经常引用/复述提示词再加这行 echo DFLASH_TOKENS15 .env docker compose --profile single up -d各开关对应的文件位置模式总览与全部环境变量single-user/README.mdlookup 补丁与逐条收益推导docs/optimizations.md复读任务实测脚本bench/labd_bench.py混合批下逐字复述一致性 soak 测试bench/labd_soak.py配合用的前缀缓存多轮聊同一份 24k 文档后续轮 23 s → 1 s见 single-user/README.md代价与适用场景别为聊天白开 15DFLASH_TOKENS15复现模式是为特定负载准备的代价是真实的默认DFLASH_TOKENS7复现模式15请求槽位84可用上下文64k56k逐字复述 25k 文档260 tok/s381 tok/s短聊天131 tok/s133 tok/s原因16 个 token 的验证块让每个驻留请求占用的循环状态页翻倍。实测聊天负载下草稿块第 7-14 位只贡献了 0.65% 的接受 token——聊天场景开 15 只值 1%却花掉一半槽位。判断标准一句话你的回答在复述输入吗✅ 开 15RAG 前端引用原文、代码编辑应用 diff、重贴这些命令、翻译/改写保留代码✅ 保持默认 7普通聊天、agent 客户端两者都可以叠加PREFIX_CACHE1它对两类负载都只赚不亏小结lookup 草稿证明了上下文本身是最好的草稿来源草稿模型只看得到 2048 窗口但提示词全文都在——答案就在手里何必猜免费获得的草稿让验证块从 8 拉到 16一步落地 15 个 token自适应调度保证长块只在复制进行中运行普通文本零损失融合 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考