低配机器上的 MoE 推理对决：用 llama-bench 对比 ik_llama.cpp 与 llama.cpp 运行 Qwen3-30B-A3B

低配机器上的 MoE 推理对决用 llama-bench 对比 ik_llama.cpp 与 llama.cpp 运行 Qwen3-30B-A3B【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp导读本文基于 ik_llama.cpp 仓库社区讨论帖中一份真实的低配机器实测数据完整还原了在同一台机器上Ryzen 5 3500 六核 CPU GTX 1650 Super 4GB VRAM用llama-bench对 Qwen3-30B-A3B30.53B 参数 MoE 模型IQ4_XS 量化分别在 ik_llama.cpp 与主线 llama.cpp 下的表现对比并逐项解读帖子中使用的-fa、-amb、-fmoe、-ot expsCPU、-ngl 99等关键参数。读者读完本文后将掌握如何在显存不足的机器上通过专家层部分/全部留在 CPU的混合卸载策略运行大 MoE 模型并能看懂并复现这套 llama-bench 对比流程。一、背景为什么在低配机器上跑 30B 模型Qwen3-30B-A3B 是一个典型的高效 MoEMixture of Experts模型虽然总参数量达到 30.53B但实际激活参数只有约 3BA3B 即 Active 3 Billion。这类大底座、小激活的模型天然适合资源受限环境——只要把全部权重放到内存里每次前向传播只需要加载一小部分专家权重参与计算。帖子作者 fizzAI 的shitbox配置是CPUAMD Ryzen 5 35006 核约 3.6 GHz内存16 GB DDR4最高 2667 MHzGPUNVIDIA GTX 1650 Super仅 4 GB GDDR6 显存模型文件Qwen3-30B-A3B IQ4_XS 量化版15.32 GiB关键矛盾在于模型文件 15.32 GiB而显存只有 4 GB。这意味着无论如何都无法全量装入 GPU必须走混合卸载路线——模型主体留在 CPU 内存16 GB 恰好放得下仅将部分层/部分张量放到 GPU或者反过来。这正是 ik_llama.cpp 对 MoE 混合推理做了大量优化的场景。二、测试方法与完整命令对比双方都使用官方自带的llama-bench基准工具源码位于 examples/llama-bench/llama-bench.cpp该工具默认输出 Markdown 表格支持-o csv|json|md|sql切换输出格式。测试项pp512表示 512 token 的 prompt 处理prompt processing测吞吐tg128表示生成 128 个 tokentoken generation测单 token 延迟。ik_llama.cpp 侧完整命令build 4084ca73ik_llama.cpp/build/bin/llama-bench -fa 0,1 -amb 128,512 -fmoe 1 -ot expsCPU -ngl 99 \ -m ~/ggufs/REPACK-Qwen_Qwen3-30B-A3B-IQ4_XS.gguf主线 llama.cpp 侧命令build 15e03282llama.cpp/build/bin/llama-bench -fa 0,1 -ot expsCPU -ngl 99 \ -m ~/ggufs/Qwen_Qwen3-30B-A3B-IQ4_XS.gguf两侧使用了同一份基准-ngl 99把除留在 CPU 的张量外的一切尽量卸载到 GPUGTX 1650 Super 识别为 compute capability 7.5VMM 开启-ot expsCPU将专家权重强制留在 CPU。帖子还另测了一组-ot ffnCPU的对照见下文第三节讨论。值得注意的是 llama-bench 的通用能力几乎所有参数都支持逗号分隔多值如-fa 0,1、-amb 128,512工具会自动组合这些值生成多个测试实例并逐个跑见 examples/llama-bench/llama-bench.cpp 中多参数笛卡尔积展开逻辑一次命令即可完成多组配置对比实测日志也印证了这一点——-fa 0,1 -amb 128,512一次跑出 8 组组合结果。三、实测结果双方各自最佳表现帖子选取双方各自最优配置的对比-ot expsCPU| 框架 | 模型 | 大小 | 参数 | 后端 | ngl | fa | amb | fmoe | 测试 | t/s | | --- | --- | ---: | ---: | --- | --: | -: | --: | ---: | --- | ---: | | ik_llama.cpp | qwen3moe IQ4_XS_R8 4.25 bpw | 15.32 GiB | 30.53 B | CUDA | 99 | 0 | 512 | 1 | pp512 |15.82 ± 1.91| | ik_llama.cpp | qwen3moe IQ4_XS_R8 4.25 bpw | 15.32 GiB | 30.53 B | CUDA | 99 | 0 | 512 | 1 | tg128 |3.05 ± 0.30| | llama.cpp | qwen3moe 30B.A3B IQ4_XS 4.25 bpw | 15.32 GiB | 30.53 B | CUDA,BLAS | 99 | 0 | N/A | N/A | pp512 | 14.29 ± 0.05 | | llama.cpp | qwen3moe 30B.A3B IQ4_XS 4.25 bpw | 15.32 GiB | 30.53 B | CUDA,BLAS | 99 | 0 | N/A | N/A | tg128 | 2.75 ± 0.27 |结论直观在同样专家留 CPU、其余 99 层上 GPU的配置下ik_llama.cpp 的 prompt 处理吞吐15.82 vs 14.29 t/s约 10.7%和生成速度3.05 vs 2.75 t/s约 10.9%均领先。由于 Qwen3-30B-A3B 的专家权重占绝对大头MoE 模型的绝大多数参数量在 FFN 专家中混合卸载下每次推理都要在 CPU 与 GPU 之间搬运专家数据矩阵乘法的单核/多核实现质量直接决定上限——这正是 ik_llama.cpp 的优化重心所在。完整日志中还给出了 ik_llama.cpp 在-ot expsCPU下 8 组配置的全部数据原讨论| fa | amb | pp512 (t/s) | tg128 (t/s) | | -: | -: | -: | -: | | 0 | 128 | 15.72 ± 0.19 | 2.86 ± 0.34 | | 0 | 512 |15.82 ± 1.91|3.05 ± 0.30| | 1 | 128 | 16.38 ± 1.32 | 2.78 ± 0.18 | | 1 | 512 | 15.78 ± 1.96 | 2.89 ± 0.24 |而主线 llama.cpp 在-fa 1时 pp512 反而掉到 11.80 t/s——帖主直言LCPP 的 CPU FA 慢得离谱。四、关键参数逐个拆解这组命令到底做了什么4.1-ot/--override-tensor把哪些张量放哪里-ot--override-tensor是 ik_llama.cpp 提供的张量级放置控制格式为模式缓冲类型支持逗号分隔多个规则。在 examples/llama-bench/llama-bench.cpp 中parse_buft_overrides()会把tensor_patternbackend_buft_name解析为llama_model_tensor_buft_override列表加载模型时对匹配该正则模式的张量使用指定缓冲类型GPU 或 CPU。-ot expsCPU将所有名字匹配exps的张量即各层ffn_up_exps/ffn_gate_exps/ffn_down_exps专家权重放到 CPU 内存。Qwen3 MoE 每层的专家权重正是以blk.N.ffn_(up|gate|down)_exps.weight命名见 src/graphs/ 下各 MoE 架构构建代码中对ffn_up_exps等张量的引用。-ot ffnCPU匹配整个ffn前缀等于把专家权重连同 FFN 相关的 norm、gate 等张量一起留在 CPU。帖主在两条路线间做了实测对比-ot expsCPUvs-ot ffnCPU均-fmoe 1 -ngl 99令人意外的是ffnCPU虽然卸载得更彻底pp512 最高 16.07 t/s、tg128 最高 2.86 t/s反而整体略逊于expsCPUpp512 15.82 t/s、tg128 3.05 t/s 的综合表现。帖主推测这与 norm 等小张量留在 CPU 后反而增加跨设备调度开销有关——这正是张量放置策略中卸载越多不一定越快的典型反例。4.2-fmoe/--fused-moe融合专家计算-fmoe默认 1控制 MoE 专家的融合计算。从 examples/llama-bench/llama-bench.cpp 可见该参数最终写入cparams.fused_moe_up_gate对应上下文参数中的融合 up/gate 专家投影选项。开启后MoE 层的 up 与 gate 两个专家投影可以合并为一次更大的矩阵乘法执行减少内核启动与显存搬运开销。对于专家在 CPU 侧执行的场景融合带来的批量计算收益同样明显因此帖主全程保持-fmoe 1。4.3-amb/--attention-max-batch注意力最大批大小-amb--attention-max-batch默认 0设置注意力计算允许的最大批大小。源码中它被直接映射到上下文参数cparams.attn_max_batchexamples/llama-bench/llama-bench.cppllama-bench 支持传多个值做扫描如-amb 128,512。从实测数据看一个有趣现象不开 FA 时amb高一点512更快开 FA 时反而amb低128更快。原因可以从工作机制推断amb限制了注意力计算每次处理的最大 token 数较高的amb允许更大的计算批次、摊薄内核开销但也意味着更长序列上一次性分配更多中间显存开启 FA 后注意力本身已按块化方式处理额外放大批次的收益被抵消反而受限于 4 GB 显存。帖主在 4GB 小显存、且内存未成为瓶颈的前提下观察到的规律与amb 与 fa 存在交互一致。4.4-fa/--flash-attn与-ngl/--n-gpu-layers-fa 0,1依次测试关闭/开启 Flash Attention。帖主结论本场景专家在 CPU、显存充足无压力下 FA 没有带来实质收益tg128 反而略降但真正糟糕的是主线 llama.cpp 的 CPU 侧 FA 实现把 pp512 从 14.29 拖到 11.80 t/s。-ngl 99表示卸载 99 层到 GPU默认即为 999见 examples/llama-bench/llama-bench.cpp实际效果是除了被-ot规则留在 CPU 的张量其余全部上 GPU。4.5 其他相关参数源码可查--n-cpu-moe N便捷地把前 N 层的专家权重放到 CPU等价于自动生成blk\.N\.(ffn_(up|down|gate)_exps\.weight)覆盖规则examples/llama-bench/llama-bench.cpp是-ot的面向 MoE 的专用封装。-mqkv/-muge分别合并 QKV、合并 up/gate 专家张量以提速后者与-fmoe配合。-ger/--grouped-expert-routing分组专家路由减少实际参与计算的专家组数量。--fit/--max-gpu按可用显存自动决定哪些张量留在 GPUauto-fit见 README 中 PR 1501/1504 的记录适合显存吃紧时的自动调优。五、讨论区的两个关键答疑BLAS 与矩阵乘实现帖子作者对是否该单独编译 BLAS 后端存疑他在 ik_llama.cpp 侧选择不链接外部 BLAS而给主线 llama.cpp 编译了 BLIS。评论区两位参与者给出了项目级权威回答默认后端是什么有人猜测不指定 BLAS 时默认使用 llamafile 后端。项目作者 ikawrakow 明确纠正No, it does not. This isik_llama.cppnotllama.cpp.——本项目几乎所有量化类型的矩阵乘法实现均由作者本人编写其内置 CPU 矩阵乘实现比 llamafile 更快因此无需也不建议外挂 BLAS 后端。这与项目 README 中相比主线提供额外 SOTA 量化类型并在多数场景更快的定位一致。CPU 矩阵乘是关键路径当专家权重全部放在 CPU如-ot expsCPU时MoE 的专家计算完全落在 CPU 侧CPU 矩阵乘实现质量直接决定 tg 与 pp 速度。ik_llama.cpp 的内置实现含 AVX2 等 SIMD 路径与多种量化内核正是对比中胜出的核心原因。另一个实际教训来自 README 的明确警告README.md混合 CPU/GPU 推理 MoE 且专家留在 CPU 时不要使用-rtr运行时重打包。-rtr会把留在内存的张量重打包为行交错格式而不少量化类型如 K 系列 k-quants没有 CUDA 行交错实现导致这些张量的矩阵乘永远在 CPU 上执行即使本可卸载到 GPU 计算最终反而显著拉低 prompt 处理速度。低显存混合推理用户应牢记这一条。六、从实测到实战低配机器跑 MoE 的建议综合帖子数据、评论区答疑与仓库文档在显存远小于模型体积的机器上运行 Qwen3-30B-A3B 这类 MoE 模型可遵循以下实践优先保证模型能整体装入内存15.32 GiB 模型需要 16 GB 内存刚刚好内存是硬底线作者确认本测试中内存并非瓶颈。用-ot expsCPU而非-ot ffnCPU起步本实测表明把 norm 等小张量留在 CPU 反而更慢pp512 差约 1.5%tg128 差约 6%精准卸载专家、其余尽量上 GPU是更优解。不要盲目开 FA4 GB 显存 专家在 CPU 的场景下 FA 收益趋近于零甚至拖慢生成务必用-fa 0,1实测对比后再决定。amb与fa存在交互不开 FA 时调大amb如 512有利开 FA 时保持较小amb如 128更佳建议按-amb 128,512扫描。保持-fmoe 1融合 up/gate 专家计算在混合卸载下收益明确。不折腾外部 BLASik_llama.cpp 内置矩阵乘实现即是针对本项目量化的最快路径混合推理时避免-rtr重打包。本案例的完整原始日志与讨论过程可查阅仓库中的 讨论 #399 原文llama-bench 的完整参数说明见 examples/llama-bench/README.md参数解析与默认值实现见 examples/llama-bench/llama-bench.cpp。在动手压测前也建议通读项目 README.md 中的混合推理注意事项特别是-rtr与--cpu-moe/--n-cpu-moe/张量覆盖在 graph 并行模式下的已知问题。【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考