单卡 RTX 3090 跑 Qwen3.8-27B 381 tok/s？HyperQwen 的思路其实比数字更有意思
-
最近看到一个挺有意思的开源项目 HyperQwen，专门针对 Qwen3.8-27B + vLLM 做优化。作者在单张 RTX 3090 24GB 上，普通单流大约能做到 120+ tok/s，而在代码修改、长文档引用这类“输出大量复用上下文”的场景，最高跑到了 381 tok/s。
这里最值得关注的其实不是 381 这个数字，而是它的 Context Lookup Speculation。
传统 DFlash/MTP 是让草稿模型“猜”后面的 token；HyperQwen 发现代码、日志、配置文件、RAG 文档等场景中，大量答案其实已经存在于上下文，于是直接从 Context 中查找连续 token，一次提出最长十几个 token，再交给目标模型批量验证。命中高的时候，相当于从“逐字生成”变成了“找到原文 → 批量复制 → 验证”。
除此之外，它还做了 DFlash2 W4A16 量化、Embedding/LM Head INT8、前缀缓存和针对 Qwen3.8 的 Kernel 优化，在 24GB 显存上尽量挤出更多 KV Cache 空间。
我觉得这个项目对本地 Agent 特别有意思：代码修改、日志分析、JSON/YAML、工具调用和长文档问答，本来就是高 Context Reuse 场景。
下一步准备研究一下，能不能把其中的 Context Lookup + DFlash 思路移植到双 7900 XTX + SGLang 上。相比单纯继续卷 Kernel，这可能是一条更有意思的路。
-
-
最近看到一个挺有意思的开源项目 HyperQwen，专门针对 Qwen3.8-27B + vLLM 做优化。作者在单张 RTX 3090 24GB 上，普通单流大约能做到 120+ tok/s，而在代码修改、长文档引用这类“输出大量复用上下文”的场景，最高跑到了 381 tok/s。
这里最值得关注的其实不是 381 这个数字，而是它的 Context Lookup Speculation。
传统 DFlash/MTP 是让草稿模型“猜”后面的 token；HyperQwen 发现代码、日志、配置文件、RAG 文档等场景中，大量答案其实已经存在于上下文，于是直接从 Context 中查找连续 token，一次提出最长十几个 token，再交给目标模型批量验证。命中高的时候，相当于从“逐字生成”变成了“找到原文 → 批量复制 → 验证”。
除此之外，它还做了 DFlash2 W4A16 量化、Embedding/LM Head INT8、前缀缓存和针对 Qwen3.8 的 Kernel 优化，在 24GB 显存上尽量挤出更多 KV Cache 空间。
我觉得这个项目对本地 Agent 特别有意思：代码修改、日志分析、JSON/YAML、工具调用和长文档问答，本来就是高 Context Reuse 场景。
下一步准备研究一下，能不能把其中的 Context Lookup + DFlash 思路移植到双 7900 XTX + SGLang 上。相比单纯继续卷 Kernel，这可能是一条更有意思的路。
-
381 这个数别当基准看，它由命中率决定。Context Lookup Speculation 本质是 prompt-lookup / n-gram 投机：把当前后缀在上下文里做最长匹配（后缀自动机或 Aho-Corasick 增量索引），一次提出一整段（十几个 token），再交给目标模型一次 forward 批量验证。命中多就接近"拷贝"，命中少就退回普通 decode——所以 120+ 是常态，381 是代码/RAG 这类高复用场景的上限。
回 kos or 的问题：它和 DFlash/MTP 的区别在"草稿从哪来"。MTP/DFlash 是训练出来的 draft head 去猜，Context Lookup 不训练，草稿直接取自上下文里的原文；DFlash2 W4A16、Embedding/LM Head INT8 属另外的量化/显存优化，和投机是两件事，别混在一起归因。
移植到双 7900 XTX + SGLang 值得试，性价比比继续卷 kernel 高：lookup 这层模型无关，只吃 token 流，不依赖 CUDA；要动的是把它挂进 SGLang 的 spec decode 当 proposer（SGLang 已有 ngram/EAGLE 路径），AMD 侧 W4A16 走 ROCm 的 int4 kernel 即可，不需要 NV 特性。三个坑：① lookup 索引必须增量维护，长上下文每次全量扫描会反噬；② 只在输出与上下文逐字重合时收益大，改写/推理类接受率会掉；③ 要按 pp/tg 分开测并把接受长度分布打出来，否则 381 和 120 混在一起看不出收益来自哪里。
建议先把"命中率 + 平均接受长度"两个指标接上，再谈移植。
-
-
都搞这种数值竞赛有什么意义？
能长链工作才是重点。
chat 再快会很嗨嘛？ -
@williamlouis prefill 能稳定在 1200 就是这个项目的意义
