Lucebox 在 GitHub 开源了 lucebox-hub，给出的成绩很抓眼球：单张 RTX 3090 跑 Qwen3.5-27B，demo 峰值 207.6 tok/s，HumanEval 10 个提示词均值 129.5 tok/s。对比同卡自回归基线约 37.8 到 38 tok/s，提升约 3.43×；对比同硬件下的 SGLang AWQ，也给出约 2.8× 的优势。

我更在意的不是这个峰值本身，而是它指向的东西：如果一张 3090 还能被这样挖出性能，问题就不只是“卡老不老”，而是“栈懒不懒”。古人说“工欲善其事，必先利其器”。今天看，本地 AI 里真正钝掉的，未必是器，可能是那层谁都想兼容、谁都不想重写的软件。

它到底做到了什么，边界又在哪里

先看事实锚点。

  • 模型.Qwen3.5-27B
  • 硬件.单张 RTX 3090，24GB 显存
  • 配置.Q4_K_M target + BF16 draft
  • 成绩.demo 最高 207.6 tok/s；HumanEval 均值 129.5 tok/s
  • 对比.相对 AR 约 3.43×；比链式 speculative decoding 快约 15%；比同硬件下 SGLang AWQ 快约 2.8×

但这组数字不能看得太飘。

207.6 tok/s 是 demo 峰值，不是稳定常态。更该参考的是不同任务下的均值：HumanEval 129.5 tok/s、Math500 110.5 tok/s、GSM8K 96.2 tok/s。场景一变，速度就会掉，这很正常。

还有一个边界必须钉死：DFlash 和 DDTree 不是 Lucebox 发明的。原始算法分别来自 z-lab 和 Ringel 等人。Lucebox 新做的，是把这套方案搬到 GGUF/ggml 路线上，再用 C++/CUDA 解码引擎和定制 kernel 去做工程化落地。

所以这不是“新算法横空出世”，而是“旧算法终于被人往消费级硬件上认真搬了一遍”。差别很大。前者是论文叙事，后者是工程叙事。

对本地部署玩家来说，这里的现实含义很直接：如果你手里正好是 3090，关心的是单卡跑大模型的吞吐，这个仓库值得看。要是你用的是别的 GPU、别的模型、别的量化格式，先别急着把这组数字当成你的答案。它明确绑在 3090、CUDA 12+、sm_86、指定量化和 fork 版 llama.cpp/ggml 上，迁移性目前还看不清。

为什么能快，关键不在算法名词，在 24GB 显存

这次最有信息量的地方，其实是约束条件：24GB 显存太紧了。

Lucebox 的公开说明很明确。Qwen3.5-27B 的 AWQ INT4 加 BF16 draft，在 3090 上放不下 DDTree 的 verify state。所以它没继续沿着 AWQ 这条常见路线走，而是转向 GGUF。用 Q4_K_M 目标权重，大约 16GB；再加 3.46GB 的 draft 权重，以及 budget=22 的 tree state 和 KV cache，才把 128K context 挤进 24GB。

这就是工程现实。很多路线不是因为“理论最优”才成立，而是因为“显存刚好塞得下”。纸上爱谈算法优雅，落到 3090 这种消费级卡上，最后拼的是内存账本、kernel 调度和实现细节。

Lucebox 真正下手的地方，也都很具体：没有现成的 DFlash runtime 支持 GGUF target，就自己在 ggml 上做；tree-aware 的 SSM state rollback 没现成支持，就补 CUDA kernel。这些工作不性感，但决定了最后能不能把吞吐做上去。

这也是我觉得这件事有价值的原因。它至少说明，通用框架留下的性能空洞不是玄学，更像是工程债。天下熙熙，皆为利来。通用栈长期占上风，不一定因为它最好，很多时候只是因为它最省人力、最省维护、最容易覆盖更多卡和更多模型。

这条路值不值得跟，谁该马上动作

对两类人，这事最有参考价值。

第一类，是拿 3090、4090、A6000 这类卡跑本地模型的开发者和硬件玩家。你现在面对的不是“要不要立刻切过去”，而是“要不要继续默认通用栈已经差不多了”。如果你的核心目标就是单卡吞吐，而且愿意折腾 fork、CUDA 环境和特定模型配置，那这类项目值得试，至少能帮你重新校准预期。

第二类，是仍依赖通用推理框架的开源栈开发者。这个信号更刺耳。过去很多人把性能损失当成兼容性的必要代价，现在这套实现给了一个不太体面的参照：代价也许比大家嘴上承认的更大。

但我也不会把它吹成通用答案。按芯片、按模型、按量化路线逐个手工重写，速度会很好看，维护账也会很难看。今天是 3090 + Qwen3.5-27B + GGUF；明天换 GPU 架构、换模型结构、换量化格式，很多优化都可能要重做。历史上这种“专机专用”的胜利并不少见，最后常常输给维护成本。其兴也勃焉，其亡也忽焉，说的就是这种工程奇观。

所以接下来最该观察的，不是峰值还能不能再冲高，而是三件更实际的事。

  • 它能不能稳定复制到第二种 GPU 或第二个主流模型
  • 通用框架会不会吸收这些做法，把性能差距缩回去
  • 部署门槛会不会下降，不再只适合重度折腾用户

如果这三件事都没有发生，那它更像一场漂亮的局部胜利。要是其中前两件发生了，本地 AI 的性能基线就会被重写。

对普通想部署本地模型的人，动作反而应该保守一点：先观望，不必因为一个峰值就换路线。对追求极限吞吐的玩家和开发者，动作可以更积极：先测你自己的任务，再看这类“特调栈”到底比现有方案多拿回多少性能。买不买账，最后看的是复现，不是口号。