exllamav3 在我的配置下轻松击败运行 CPU 卸载 Qwen-3.8-Flash-Next 的 llama.cpp！

我拥有 2 张 20GB RTX 3080 显卡、128GB DDR4 2666MHz 内存（仅使用了 6 通道中的 4 个）以及一颗 Xeon 6148 处理器。我一直都是 llama.cpp 的用户，并运行 Unsloth 的 Q4_K_XL 量化版 Qwen 3.8 Flash Next，预填充速度约 270 tps，解码速度约 13 tps（起初接近 20 tps，随着上下文增长下降到 13 tps，从未恢复）。最近我看到关于 exllamav3 的热议：其新的“CPU 卸载推理”支持，其量化格式在大小与性能方面比 GGUFs 更高效，还有人发布数据显示它运行模型比 llama.cpp 快很多。起初我持怀疑态度，因为在此之前，我的配置下从未有引擎在 CPU 卸载推理方面超越过 llama.cpp。然而，我好奇地尝试了一下，结果令我惊喜！我能够运行 Qwen 的 4.05 EXL3 量化版，解码速度平均约 25 tps（偶尔峰值达 32 tps），在 160k 上下文范围内（这是我目前测试的极限），预填充速度约 870 tps，快了 3.2 倍！因此，与 llama.cpp 相比：- 预填充快 3.2 倍 - 解码快 2 倍（无 MTP） - 输出质量更好，因为 4.05 EXL3 量化优于 UD-Q4_K_XL GGUF。这完全是一举三得！但：这种优势并非适用于所有模型（至少在我的配置下是如此）。我兴奋地下载了 GLM 5.3 Flash 的 3.05 EXL3，结果发现解码速度比其 llama.cpp 版本慢约 2 倍。因此，这种优势显然取决于模型和您的配置。就我而言，目前 CPU 的 AVX2 指令集似乎是 exllamav3 的瓶颈，但由于 Qwen 架构高效，它表现很好。我在这里没有看到任何关于 exllamav3 CPU 卸载性能的讨论，所以想以此为开端。在您选择此路线之前，有几个免责声明：- exllamav3 + TabbyAPI（llama-server 的等效工具）的配置不像 llama.cpp 那样简单直接。解码速度似乎需要一些时间来预热以校准热/冷专家。我的起初约 12 tps，最终在几千个 token 后达到约 25-30 tps。所以不要太快否定它。我仍在摸索这个引擎，如果有人有让卸载运行更快的提示，请分享！