Lucebox 团队给出了一个让很多人没想到的数字：207.6 token/s。用的还是 Qwen3.5-27B 官方模型，不是蒸馏，不是 INT8 量化残血版——就是 Q4_K_M 量化版本，目标加草稿模型全部加载在一张 24 GB VRAM 的 RTX 3090 上。

这个成绩靠的不是等英伟达下一代消费级显卡，而是对解码算法本身动刀子。

为什么自回归解码是瓶颈

大多数人聊 LLM 推理优化，会先想到量化、KV cache 压缩、batch 并行。但对单卡消费级 GPU 来说，这些都已经做到头了——Q4_K_M 量化能压缩到约 16 GB，再压下去效果肉眼可见地降。

问题出在自回归解码本身。每生成一个 token，GPU 要完整跑一遍 27B 参数的前向传播。27B 参数在 Q4_K_M 下大约 16 GB，VRAM 带宽是 936 GB/s——每次解码都要把这 16 GB 从显存读一遍，理论带宽利用率撑死不到 20%。这是机械式的物理限制，不是软件优化能绕过去的。

speculative decoding（投机解码）解决的就是这个问题：用一个小草稿模型一次生成多个候选 token，再用大模型一次验证整串。如果草稿猜得准，大模型只跑一次就能吐出五六个 token，GPU 计算资源用得更充分。

DFlash：块扩散草稿，比 Chain EAGLE 更容易命中

主流投机解码方案是 EAGLE（及其 chain 版），草稿模型做自回归预测，每步大约能接受 3 个 token。DFlash（2026） 换了个思路：用块扩散（block diffusion） 做草稿——一个 5 层非因果的去噪网络，同时预测多个位置，而不是逐个生成。

效果如何？看数字：

AR 基线是 Qwen3.5-27B Q4_K_M 在 RTX 3090 上的原生速度，也是 llama.cpp、SGLang AWQ 等框架在同一硬件上的天花板。DFlash 把这个天花板一口气推到 3 倍以上——而且平均每次验证接受 8 个 token，比 EAGLE 的 ~3 高了将近两倍。

但这里有个工程问题：官方 DFlash 实现跑在 BF16 下，需要 60+ GB VRAM 的 B200 专业卡才能装下目标+草稿+验证树。消费级 GPU 想用，得从头移植。

GGUF 移植：Q4_K_M 是 24 GB 的最优解

Lucebox 的贡献就是这个移植。他们选了 Q4_K_M 量化目标（~16 GB）+ BF16 草稿（~3.46 GB）+ DDTree 验证树（budget=22），刚好能在 24 GB VRAM 里塞下整个推理链路。

GGUF 是 llama.cpp 的量化格式，在消费级 GPU 上生态最成熟。选择 ggml 作为运行时而非 libllama，是因为 ggml 有原生 Gated DeltaNet CUDA kernel，不需要额外改硬件抽象。

整个移植约 2000 行 C++/CUDA 代码，fork 了 llama.cpp 增加了三个 tree-mode 操作：

ggml_ssm_conv_tree      // SSM 卷积树结构
ggml_gated_delta_net_tree        // Gated DeltaNet 树验证
ggml_gated_delta_net_tree_persist // 持久化状态

硬编码了 Qwen3.5-27B + Qwen3.5-27B-DFlash 这一个模型组合，没有通用性——但消费级单卡跑 27B 规模，这个组合恰好是最有价值的一个。

128K context 怎么塞进去

原生 DFlash 在 128K 上下文时会爆显存，因为 KV cache 太大。Lucebox 的解法是Q4_0 KV cache + 滑动 target_feat ring（4096 槽位）：

• Q4_0 比 BF16 省 8 倍显存
• Sliding window 限制历史 KV 长度
• target_feat 做 ring buffer，超长 prompt 自动驱逐旧状态

代价是 Acceptance Length 约下降 3%，但换来了128K context 稳定在 24 GB 内，128K 模式下仍能跑出 ~135 tok/s。这对需要超长上下文的应用（代码库分析、长文档对话）是实打实的突破。

关键洞察：消费级 GPU 的 LLM 推理还没到头

看完 Lucebox 的实现，有几个工程结论值得关注：

1. 量化不是终点，算法才是

Q4_K_M 已经把 27B 压到 16 GB，这个路径的边际收益越来越小。但在 Q4_K_M 基础上加 DFlash，能在不降低模型质量的前提下再快 3 倍——这说明解码算法的优化空间远没有到头。下一个突破点很可能是草稿模型和目标模型的协同训练，而不是继续压缩精度。

2. GGUF 生态正在变厚

Llama.cpp 的 GGUF 量化格式原本是"省显存"的妥协方案，但随着 ggml 支持更多的 CUDA kernel（SSM、Gated DeltaNet），它在某些场景下已经不只是"能用"，而是"最优解"。这对想在消费级硬件上做推理优化的开发者是好消息——不需要自己写 CUDA kernel，现成的生态已经能跑起来。

3. 单卡 27B 的实用边界在拓宽

207 tok/s 意味着什么？实际体验大概是：每秒能吐出大约 150-200 个中文词，或者 300-400 个英文词。这个速度已经能支持实时交互式 AI 助手——不是等几秒才回一个字，而是几乎感知不到延迟的流式响应。加上 128K 上下文，单卡 27B 能做的事比去年这个时候多了很多。

快速上手

项目在 GitHub，clone 下来大概需要知道这几步：

# 1. 克隆（含 submodule）
git clone --recurse-submodules https://github.com/Luce-Org/lucebox-hub
cd lucebox-hub/dflash

# 2. 编译（CUDA 12+, RTX 3090/sm_86）
cmake -B build -S . -DCMAKE_CUDA_ARCHITECTURES=86 -DCMAKE_BUILD_TYPE=Release
cmake --build build --target test_dflash -j

# 3. 下载模型（约 20 GB）
huggingface-cli download unsloth/Qwen3.5-27B-GGUF Qwen3.5-27B-Q4_K_M.gguf --local-dir models/
huggingface-cli download z-lab/Qwen3.5-27B-DFlash model.safetensors --local-dir models/draft/

# 4. 运行
python3 scripts/run.py --prompt "def fibonacci(n):"

完整的 benchmark 结果在 RESULTS.md，包括不同模型、不同 context 长度下的吞吐和内存数据。

信源

• Lucebox DFlash 实现：https://github.com/Luce-Org/lucebox-hub
• DFlash 论文：https://arxiv.org/abs/2602.06036
• DDTree 论文：https://arxiv.org/abs/2604.12989
• Lucebox 官方博客：https://lucebox.com/blog/dflash27b
• Qwen3.5-27B GGUF 量化模型：https://huggingface.co/unsloth/Qwen3.5-27B-GGUF
• Qwen3.5-27B-DFlash 草稿模型：https://huggingface.co/z-lab/Qwen3.5-27B-DFlash