Betelgeuse：在 RTX 3060 12GB + 16GB DDR4 内存上以 22 tok/s 持续运行 Qwen 3.8 Flash Next（峰值 48 tok/s），100% 位精确！

大约两个月前，我在这里发帖讨论尝试预测下一个 token 会使用哪些 MoE 专家，以加速 Qwen 3.6 35B 在 CPU/GPU 卸载上的速度。先说句实话：我最终把那个原型扔掉了。为了得到当时看到的高数字，我基本上是在用门控剪枝作弊（当路由权重较低时丢弃冷门专家）。这让 tok/s 计数器狂飙，但在已经低比特量化的模型上，它悄悄降低了输出质量和推理能力。我不想发布一个为了让截图好看而把模型变成脑残的东西，所以我废弃了它。当 Qwen 3.8 Flash Next 发布时，我想看看我们是否真的能在一台普通预算游戏 PC 上以真正可用的速度运行 68GB 的 GSQ-RCO-IQ2_XS 构建——而且不丢弃任何一个专家。作为背景，这是我测试所用的确切配置（我特意拔掉了额外的内存条，以测试普通 16GB PC 的表现）：GPU：RTX 3060 12GB 内存：16GB DDR4 单通道（约 19 GB/s） 操作系统：CachyOS / Arch Linux（在严格的 MemoryMax=12G cgroup 内测试） 存储：消费级 PCIe NVMe SSD（约 2.1 GB/s） 如果你尝试在原生 llama.cpp 中用 12GB 显存 + 16GB 内存加载 68GB 的 MoE，你已经知道会发生什么：mmap 把操作系统页面缓存折腾到死，每个 token 约 1,500 次主缺页，生成速度爬行在 1.47 tok/s。然后我测试了 Strata。Strata 非常酷，如果你有 48GB–64GB 内存来 mlock 24GB+ 的专家到系统内存中，它能达到 40+ tok/s。但在 16GB 内存的配置上，除非强制 --low-ram mmap，否则它拒绝加载，而那样会降到 8.11 tok/s，因为受限于冷 SSD 读取。所以在过去一周里我构建了 Betelgeuse（bel-cli / bel-server，llama.cpp 的一个分支，我也在向 llama.cpp 提交一个干净的上游 PR，即使它可能不会被合并哈哈）。它底层实际做的事情：零门控剪枝 / 100% 位精确：全部 48 层中每层 10 个路由专家中的每一个都参与计算