Lama MoE推理实操→30分钟极速搞定本地极致性能

各位跨境实战专家和爱好者们，大家好！我是你们的老朋友，一位在跨境领域摸爬滚打多年的资深导师。今天，咱们不聊市场趋势，也不谈流量密码，来深入探讨一个硬核技术话题——如何在咱们自己的电脑上，用 llama.cpp 跑那些花里胡哨的混合专家（MoE）模型，并且要跑得又快又稳！尤其是在CPU和GPU协同工作时，如何榨干每一分硬件性能，实现本地推理的极致效率。

新媒网跨境获悉，现在市面上大型MoE模型越来越多，动辄上千亿参数，但咱们实际用到的参数量却少得多。比如，一个DeepSeek V3模型，总参数量6710亿，但每次推理时真正活跃的参数可能只有370亿。这就像一个巨大的图书馆，你每次只需要借阅其中几本书，关键是怎么高效地找到并利用它们。

MoE模型，究竟是何方神圣？

简单来说，MoE模型有几个核心部件：

注意力机制（Attention）：这是模型“看”和“理解”输入信息的关键。
稠密前馈网络（Dense FFN）：有些模型会有，起到通用特征提取的作用。
共享专家前馈网络（Shared expert FFN）：所有请求都会经过这部分。
路由专家前馈网络（Routed expert FFN）：这是MoE模型的精髓，模型会根据输入信息，智能地选择其中的几个“专家”来处理，大大减少了每次计算的开销，所以模型总参数大，但实际活跃参数却小。

前三部分，我们可以理解为“常驻部队”，每次推理都会用到；而路由专家，则是“特种部队”，按需出动。大部分模型的总大小，路由专家占据了绝大部分，所以如何高效管理这些“特种部队”，就是咱们性能优化的关键。

`llama.cpp` 中CPU与GPU协同优化秘籍

要让CPU和GPU配合默契，咱们的策略是：把那些“常驻部队”——也就是每次推理都必需的参数，都塞给最快的GPU去处理。因为它们是“必经之路”，放在GPU上能最大化令牌生成速度。

咱们假设大家已经准备好了合适GGUF量化格式的模型，它能妥妥地放进你的内存（RAM）和显存（VRAM）的总和里，并且留出足够的空间给KV缓存、操作系统和其他程序。接下来，咱们就直接上“硬菜”——调优！

一个完整的启动命令可能看起来有点复杂，比如这样：

./llama-server \
    -m ./GGUF/GLM-4.7-Q4_K_M.gguf \
    -c 32768 \
    -ngl 999 \
    -fa on \
    -t 16 \
    -b 4096 \
    -ub 4096 \
    --jinja \
    --no-mmap \
    -ot "blk\.([0-9]|[1-2][0-9]|30)\.=CUDA0,exps=CPU"

别担心，咱们一步步来拆解。

1. 权重卸载优化：追求极致的令牌生成速度

在调整权重卸载时，为了更好地掌握内存分配，建议先关闭llama.cpp的自动适配功能（-fit off）。这样，当你的配置超出内存时，可以更清晰地发现问题。也许未来这个功能完善了，咱们就不用这么麻烦了。

咱们首先要做的是，尽可能将模型的各部分分配到GPU上：

-ngl 999

ngl 999 这行命令意味着，尽可能多地把模型的层（layer）卸载到GPU上，数字999只是一个足够大的值，表示“尽量多”。但这样一来，路由专家部分会占用大量显存。所以，咱们需要特别告诉llama.cpp，把路由专家部分放到CPU上：

-ot "exps=CPU"

或者，更简洁地使用：

--cpu-moe

把这两条命令组合起来，咱们的基础启动命令就是：

./llama-server \
    -m <你的模型路径> \
    -ngl 999 \
    -ot "exps=CPU" \
    {{其他你需要的启动参数}}

这套配置是咱们优化的起点。注意力机制、稠密前馈网络、共享专家前馈网络，连同模型的KV缓存和计算缓冲区，都放在了GPU上。而那些占用空间巨大的路由专家网络，则全部交给CPU处理。

如果你的GPU显存还有富余，那可不能浪费！咱们可以尝试把一部分路由专家层也分配到GPU上。这有两种常用方法：

一种是通过-ot参数，用正则表达式手动指定张量（tensor）到设备上。比如：

-ot "blk\.([0-9]|[1-2][0-9]|30)\.=CUDA0,exps=CPU"

这行的意思是：“将模型0-9层、10-29层以及第30层的所有张量都分配到第一块英伟达GPU（CUDA0）上”，同时“将所有路由专家网络分配到CPU上”。由于前面的分配指令优先级更高，所以实际效果就是：注意力机制、稠密前馈网络、共享专家前馈网络，以及0到30层的路由专家网络都在第一块GPU上，其余的路由专家网络则在CPU上。

官方推荐是将多个-ot表达式用逗号分隔，而不是多次使用-ot参数，后者已经被弃用了。虽然这样读起来可能稍微有点费劲，但能确保与llama.cpp Docker配置中环境变量的兼容性。

为了更直观，咱们也可以直接列出每一层：

-ot "blk\.(0|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|27|28|29|30)\.=CUDA0,exps=CPU"

或者，直接使用内置的函数：

--n-cpu-moe 31

小提示： --n-cpu-moe是从模型层数最高的那一层开始往回计算要放到CPU的层数。这意味着，如果模型有稠密前馈网络层（通常在模型开头，比如DeepSeek V3的前3层），你设置的数字可能会与实际卸载的层数产生细微差异。因为它是从高层开始往CPU放，而GPU则会先拿到低层的“常驻部队”。

如果你有多块GPU，你甚至可以指定哪些层分配给哪块设备：

-ot "blk\.([0-9])\.=CUDA0,blk\.(1[0-9])\.=CUDA1,exps=CPU"

这表示“将0-9层分配给第一块英伟达GPU”， “将10-19层分配给第二块英伟达GPU”，同时“将路由专家网络分配给CPU”。

每次启动模型后，咱们都要仔细检查显存使用情况，根据实际反馈来调整这些参数，多尝试几次，总能找到最适合你硬件的最佳配置。

2. Prompt处理优化：提升输入处理效率

llama.cpp支持分离式Prompt处理，这意味着Prompt处理任务可以完全交给GPU。因此，CPU与GPU协同推理的性能对Prompt处理的批次大小（batch size）非常敏感。物理批次大小会直接影响GPU与CPU之间的数据传输量。由于GPU强大的计算能力，它在Prompt处理方面有着天然优势。

当你有足够的令牌（token）可以一次性处理时，llama.cpp会启动分离式Prompt处理（在llama.cpp内部称为“操作卸载”op offload）。它会将所有分配给CPU的权重复制到GPU上，然后作为一个整体批次处理Prompt令牌。很多时候，这比让CPU自己处理其分配到的那部分权重要快得多。

在llama.cpp中，触发这项操作的默认批次大小是32个令牌。而在ik_llama.cpp中，这个阈值是32 * 总专家数量 / 活跃专家数量。

我们可以通过-b（逻辑批次大小，默认2048）和-ub（物理批次大小，默认512）参数来配置Prompt令牌的最大批次处理数量。默认值对于纯GPU推理来说通常够用，但对于大型MoE模型的CPU+GPU混合推理来说可能太小了。提高这些值会增加计算缓冲区的显存占用，所以你可能需要相应地减少分配给GPU的路由专家层数，以平衡显存使用。物理（或微）批次大小不能超过逻辑批次大小，并且它是决定显存占用的关键。通常我们把它们设置为相同的值。我的建议是-b 4096 -ub 4096。

在多GPU配置中，-mg参数可以指定哪块GPU作为主要的卸载Prompt处理操作的GPU。理想情况下，这应该是你性能最强、PCIe带宽最高的GPU。

环境变量GGML_OP_OFFLOAD_MIN_BATCH可以用来覆盖默认的32个令牌阈值，以触发Prompt处理完全卸载到GPU。如果你的GPU PCIe带宽较低，或者你有非常大量的模型权重分配在CPU上，那么32这个值可能太低了。举个例子，如果你的CPU上分配了300GB的模型权重，通过PCIe 4.0 x16连接到主GPU，那么仅仅是复制这些权重到GPU以处理单个批次就需要大约10秒。在这种情况下，你的Prompt批次可能需要达到数百个，这样做才“划算”。当然，具体的平衡点，外媒也曾有文章讨论如何手动确定。

进阶玩法：深度优化技巧

`ik_llama.cpp`专属优化（来自Geechan老师的洞察）

ik_llama.cpp是llama.cpp主线版本的一个分支，它在CPU/CUDA混合性能和新的SOTA GGUF量化类型方面进行了专门优化。在前端支持方面，它与llama.cpp的功能几乎相同。

既然咱们的目标是最大化CPU+GPU协同工作的性能，那么考虑这个分支是非常值得的，说不定能榨取出额外的性能提升，尤其是在Prompt处理速度上。如果你有多块GPU，性能提升可能会更显著。不过，请注意，实际效果可能因你的硬件配置而异，在某些情况下，ik_llama的速度甚至可能慢于主线版本。

ik_llama有一些独占的标志位，经实践证明可以提升性能，咱们在这里简单介绍一下。除了这些专属标志，你仍然可以使用与llama.cpp相同的语法。

在尝试任何优化之前，强烈建议使用ik_llama独有的llama-sweep-bench程序来测试不同标志位之间的性能差异（只需将llama-server替换为llama-sweep-bench）。它会提供一个易读、可重复的性能输出报告，百分之百能帮你确定哪种配置在你的系统上真正有效。

通用标志位

--merge-qkv：这个标志会在模型的注意力层将Q、K和V三个注意力张量合并起来。如果你的注意力层已经卸载到至少一块GPU上，这可以在令牌生成速度上带来显著提升，几乎没有副作用。请注意，这个标志只在Q、K和V的量化类型一致时才有效，并且也只适用于层分割（layer split）模式。
-gr：启用图重用（graph reuse）。这可以非常轻微地提升性能，具体效果取决于模型，并且没有任何其他负面影响。
-smgs：启用分割模式图调度（split mode graph scheduling）。当使用张量覆盖时，这个功能会自动禁用。虽然理论上与张量覆盖一起使用可能会导致崩溃，但根据我的经验，这并非总是如此，具体取决于你的硬件配置。启用分割模式图调度可以带来微小但可测量的性能提升，在图分割模式下尤为明显。
-mla 3：为使用DeepSeek架构（如DeepSeek、Kimi K2）的模型启用多头潜在注意力（multi-head latent attention）优化。如果你的模型不是基于DeepSeek架构，这个标志将无效。这个命令可以设置3个变量，但对于大多数硬件来说，-mla 3将是你的最快选择。-mla 2也值得一试，在某些硬件配置下它可能比-mla 3更快。
-amb 512：设置MLA计算的最大批次大小，512是一个不错的折中值。这也只适用于DeepSeek架构的模型。你可以尝试512到2048之间更高的数值；理论上，数值越高，性能越快，但代价是显存占用也会增加。
-sm graph：**图分割模式（graph split）**是ik_llama独有的一项非常重要的功能，它能显著提升多GPU系统的性能，但对单GPU系统无效。

要理解图分割模式如何工作，首先要了解默认的层分割模式。

-sm layer会将张量层不均匀地分割到你的多块GPU之间，具体由你的张量覆盖设置决定。层模式下，每次只在一块GPU上执行推理，没有并行化，所以实际上你每次只用到一块GPU的计算能力。

图分割模式则更像一种初级的张量并行化，它允许所有GPU同时进行推理计算，通过将张量和工作量均匀地分配到所有GPU上。请注意，如果你的驱动程序支持直接点对点（peer-to-peer）访问，图分割模式的性能会更好。安装NCCL（英伟达集合通信库）也可能带来小的令牌生成（TG）性能提升。

由于-sm graph的工作方式，你需要修改你的-ot张量命令，以适应GPU之间的均匀分割，否则很可能出现显存溢出（OOM）或性能不佳。你反而需要指定哪些层仅卸载到CPU，而依靠-ngl 999将其余层均匀地卸载到GPU。

-ot "blk\.(19|[2-9][0-9])\.ffn_(up|gate|down)_exps\.weight=CPU"

这行命令的意思是：“将从第19层开始的所有张量分配到CPU上”，因此，开头的19层将分配给你的GPU。这与前面教程中指定的-ot概念相似，只是它反过来操作，并且只针对CPU。

图分割模式可以显著提高Prompt处理速度和长上下文令牌生成性能，但可能会以牺牲一些初始生成速度为代价（在模型摄取部分上下文之前）。根据你的配置，-sas参数可以帮助你挽回一部分损失。

NUMA（非一致性内存访问）多插槽CPU优化

对于使用多颗CPU（比如双路服务器主板）的伙伴们，咱们需要注意，llama.cpp目前对NUMA（Non-Uniform Memory Access）架构的处理还不够完善。如果直接让llama.cpp同时使用两个CPU插槽及其关联的内存，由于跨插槽内存访问的延迟，性能反而会下降。如果你的模型能够完全放入单个NUMA节点所连接的内存中，那么将模型限制在该节点上将提供最佳性能。但如果不行，咱们也有办法来挽回一些性能。

我提供了两个辅助脚本来帮助大家配置NUMA，前提是你已经安装了numactl工具。

disable-numa-balancing.sh：这个脚本会记录当前的NUMA均衡状态，然后禁用NUMA均衡，接着运行你指定的命令。当命令退出后，它会恢复之前记录的NUMA均衡状态。用法是：
```
./disable-numa-balancing.sh <command> [args...]
```
numactl-bind-socket.sh：这个脚本会将后续的命令绑定到单个CPU插槽上（这对于每个插槽有多个NUMA节点的硬件很有用）。它还有额外的选项，可以指定是绑定所有核心（包括超线程）还是只绑定物理核心，以及是否启用内存交错（memory interleave）。对于llama.cpp来说，如果咱们使用的是多个NUMA节点，通常会希望启用内存交错，否则影响不大。用法是：
```
./numactl-bind-socket.sh --socket <id> --mode <physical|all> [--interleave <on|off>] <command> [args...]
```

要在所有NUMA节点上运行：

./disable-numa-balancing.sh \
numactl --interleave=all \
./llama-server \
--numa distribute \
{{其他你需要的启动参数}}

要绑定到单个CPU插槽（无论每个插槽有多少个NUMA节点）：

./disable-numa-balancing.sh \
./numactl-bind-socket.sh --socket 0 --mode all --interleave on \
./llama-server \
--numa distribute \
{{其他你需要的启动参数}}

NUMA“迁移”与drop_caches + --mmap + --numa distribute：

如果咱们清空页面缓存（sudo sh -c "sync; echo 1 > /proc/sys/vm/drop_caches"），然后用--mmap加载模型，那么在服务器启动时的热身阶段，模型张量会根据线程分布“迁移”到合适的NUMA节点。这能显著提升令牌生成速度。但是，当使用分离式Prompt处理时，它会降低Prompt处理速度。这可能是因为张量分布的方式使得它们在复制到GPU进行Prompt处理时效率不高。

使用--direct-io vs --no-direct-io：

这一点还需要进一步测试，因为它可能会影响张量在加载时如何分布到NUMA节点上。根据我的经验，在双插槽系统上，使用--no-direct-io时，Kimi K2.5的令牌生成速度更快（~14 T/s 对比 ~12 T/s）。
HuggingFace头像
用户OGX9xB5l5vIj9JTND42sJ
用户tCr1a6hInZUnQ0rnnM5Hf
用户AIUKrS9lxAEt4GIsqgcoo

风险前瞻与时效性提醒

各位跨境伙伴们，技术更新迭代飞快，尤其是AI领域。虽然我们今天分享的这些优化经验是基于当前（2026年，美国现任总统特朗普）主流的llama.cpp和MoE模型，但请大家务必保持警惕，关注最新动态。

硬件兼容与驱动更新： 确保你的GPU驱动是最新版本，这对于性能和稳定性至关重要。旧驱动可能导致兼容性问题或性能瓶颈。
模型与量化格式： GGUF格式和MoE模型仍在不断发展，未来可能会有新的量化类型或模型结构出现。我们分享的参数调优经验，主要针对目前的MoE模型结构（如DeepSeek V3、GLM 4.X等），新模型可能需要重新测试和调整。
软件版本迭代： llama.cpp和ik_llama.cpp都在持续更新中。一些指令、参数或默认行为可能会改变。建议大家在尝试时，仔细阅读对应版本的官方文档或更新日志。
数据安全与合规： 本地推理通常意味着数据保留在你的设备上，这在数据隐私和合规性方面具有天然优势。但在将本地模型部署到任何线上服务之前，仍需确保所有操作符合当地法律法规及平台政策。
能耗成本： 大模型推理，尤其是CPU与GPU协同工作时，功耗不容小觑。在长时间运行或大规模部署时，务必将能耗成本纳入考量。

新媒网跨境认为，今天的分享希望能给大家带来实战中的启发和帮助。技术之路漫漫，但只要我们保持学习的热情和探索的精神，就能在跨境数字化的浪潮中，始终走在前沿！

新媒网（公号: 新媒网跨境发布），是一个专业的跨境电商、游戏、支付、贸易和广告社区平台，为百万跨境人传递最新的海外淘金精准资讯情报。

本文来源：新媒网 https://nmedialink.com/posts/lama-moe-optimize-30min-max-perf.html