<![CDATA[单卡 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，这可能是一条更有意思的路。

]]>https://lcz.me/topic/1849RSS for NodeFri, 25 Sep 2026 21:27:25 GMTSun, 20 Sep 2026 23:50:11 GMT60<![CDATA[Reply to 单卡 RTX 3090 跑 Qwen3.8-27B 381 tok/s？HyperQwen 的思路其实比数字更有意思 on Mon, 21 Sep 2026 13:35:05 GMT]]>@johnnybegood 长链任务看的是否有radix缓存树这种增量prefill，比如halogen，比如ninfer都有这样的能力，其它的优化只是锦上添花。

]]>https://lcz.me/post/19796https://lcz.me/post/19796Mon, 21 Sep 2026 13:35:05 GMT<![CDATA[Reply to 单卡 RTX 3090 跑 Qwen3.8-27B 381 tok/s？HyperQwen 的思路其实比数字更有意思 on Mon, 21 Sep 2026 04:24:43 GMT]]>@williamlouis prefill 能稳定在 1200 就是这个项目的意义

]]>https://lcz.me/post/19664https://lcz.me/post/19664Mon, 21 Sep 2026 04:24:43 GMT<![CDATA[Reply to 单卡 RTX 3090 跑 Qwen3.8-27B 381 tok/s？HyperQwen 的思路其实比数字更有意思 on Mon, 21 Sep 2026 04:06:20 GMT]]>都搞这种数值竞赛有什么意义？
能长链工作才是重点。
chat 再快会很嗨嘛？

]]>https://lcz.me/post/19657https://lcz.me/post/19657Mon, 21 Sep 2026 04:06:20 GMT<![CDATA[Reply to 单卡 RTX 3090 跑 Qwen3.8-27B 381 tok/s？HyperQwen 的思路其实比数字更有意思 on Mon, 21 Sep 2026 03:41:40 GMT]]>我也看到了这个项目，但是现在还没有时间测试。

主要是Ninfer-3090还没玩明白，等这个玩明白后再试吧😄

]]>https://lcz.me/post/19650https://lcz.me/post/19650Mon, 21 Sep 2026 03:41:40 GMT<![CDATA[Reply to 单卡 RTX 3090 跑 Qwen3.8-27B 381 tok/s？HyperQwen 的思路其实比数字更有意思 on Mon, 21 Sep 2026 01:01:48 GMT]]>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 混在一起看不出收益来自哪里。

建议先把"命中率 + 平均接受长度"两个指标接上，再谈移植。

]]>https://lcz.me/post/19633https://lcz.me/post/19633Mon, 21 Sep 2026 01:01:48 GMT<![CDATA[Reply to 单卡 RTX 3090 跑 Qwen3.8-27B 381 tok/s？HyperQwen 的思路其实比数字更有意思 on Mon, 21 Sep 2026 00:28:00 GMT]]>

@znx said:

Context Lookup Speculation

從預測下面幾個 tokens, 變成下一段tokens (?)

]]>https://lcz.me/post/19629https://lcz.me/post/19629Mon, 21 Sep 2026 00:28:00 GMT<![CDATA[Reply to 单卡 RTX 3090 跑 Qwen3.8-27B 381 tok/s？HyperQwen 的思路其实比数字更有意思 on Sun, 20 Sep 2026 23:52:35 GMT]]>项目地址： https://github.com/syv-ai/HyperQwen

]]>https://lcz.me/post/19625https://lcz.me/post/19625Sun, 20 Sep 2026 23:52:35 GMT