大幅提升 --n-cpu-moe 部分卸载模型的提示词处理速度
摘要
本文分享了一个 llama.cpp 的性能优化技巧,展示了增大微批大小(`-ub`)并结合部分 CPU 卸载(`--n-cpu-moe`)可以显著提升 gpt-oss-120b 等大型模型在消费级 GPU 上的提示词处理速度。
# 增大 ubatch 让我的 RTX 3090 在处理 gpt-oss-120b 提示词时快得多
我在 RTX 3090(24 GB 显存)上使用 llama.cpp 调优 `gpt-oss-120b-F16.gguf` 时发现,只要同时提高 `--n-cpu-moe` 以保持运行在显存范围内,增加物理微批大小(`-ub`)就能大幅提升提示词处理的吞吐量。llama.cpp 的默认设置是 `-b 2048` 和 `-ub 512`;我在图表中将该默认运行结果作为单独的一个数据点列出。以下是我绘制的非正式 `llama-bench` 结果:
|ubatch|n-cpu-moe|prefill|generation|
|:-|:-|:-|:-|
|256|25|240.03 tok/s|33.14 tok/s|
|512 (默认)|26|380.27 tok/s|32.29 tok/s|
|2048|25|1112.54 tok/s|32.96 tok/s|
|4096|26|1682.47 tok/s|32.38 tok/s|
|8192|28|2090.68 tok/s|30.05 tok/s|
与 llama.cpp 默认值 `-ub 512` 相比,提示词处理速度从约 380 tok/s 提升至约 2091 tok/s,大约提升了 5.5 倍。与较小的 `-ub 256` 运行相比,大约提升了 8.7 倍。Token 生成速度从默认设置下的约 32.3 tok/s 下降到 `-ub 8192` 时的 30.1 tok/s,降幅约为 7%。关键在于,更大的 ubatch 需要更多的 GPU 计算工作区。在我的机器上,`-ub 4096` 需要 `--n-cpu-moe 26`,而 `-ub 8192` 需要 `--n-cpu-moe 28`。因此这是一种吞吐量权衡:将更多的 MoE 层移到 CPU 上以为更大的批次腾出空间,这样提示词密集型工作负载会变得明显更快,而生成速度则会略微变慢。
https://preview.redd.it/s750judj7m0h1.png?width=2250&format=png&auto=webp&s=c696d26db310933120b9b99c310b2662e2d4f390
注意:前四个预填充数据点来自 `pp4096`;8192 ubatch 数据点来自 `pp8192` 运行,因此请将此视为非正式调优结果,而非严格控制的基准测试。
\-----
我购买 DGX Spark 的原因之一是为了获得更好的提示词处理速度。如果我知道这个技巧,我可能就不会这么做了,尽管它是一台非常棒的机器,并且在处理 gpt-oss-120b 时提示词处理性能略高,Token 生成速度几乎翻倍。提高 ubatch 可以*大幅*缩小这一差距。
相似文章
@leftcurvedev_: 任何拥有8GB或12GB显存配置的用户都需要明白,“-ncmoe”是在llama.cpp上提升性能的关键标志…
解释了llama.cpp中的-ncmoe标志如何通过将部分专家层卸载到CPU+内存,在有限显存(8-12GB)上提升MoE模型(如Qwen3.6 35B A3B)的性能,基准测试显示在RTX 3070Ti上可实现高达5倍的加速。
在仅有CPU的情况下本地运行GLM-5.2!(穷人的大型模型方案)
一位用户仅用CPU在本地运行GLM-5.2,演示如何在简陋的配置上运行大型模型。
双GPU llama.cpp加速
llama.cpp的一个分支修复了量化KV缓存中的--split-mode tensor问题,在双GPU配置上实现高达40%的速度提升,且无质量损失。
Windows 11与Linux下llama.cpp的速度差异:中型和大型MoE模型其实没有差别
用户评测表明,使用llama.cpp运行大型MoE模型时,Windows 11与Linux之间并无显著速度差异,打破了一个常见迷思。在多GPU配置下,使用Qwen 3.5 122B、397B和MiniMax 2.7等模型进行测试,提示处理和令牌生成速度几乎相同。
比较 llama.cpp 行/张量分割与 ik_llama 图分割的双GPU推理速度
一位用户使用llama.cpp(行/张量切分)和ik_llama(图切分)在两张RTX 3080 20GB上对双GPU推理速度进行了基准测试,使用Qwen3.6-27B GGUF模型,比较了token生成和提示处理速度。