llama.cpp 的 Metal/CPU 混合推理调度：Apple Silicon 上的线程绑定与内存带宽优化

一、M2 Ultra 上的 llama.cpp 推理，token/s 波动高达 40%

在 Apple M2 Ultra（24 核 CPU + 76 核 GPU）上运行 llama.cpp 推理时。遇到一个令人困惑的性能波动。同样的模型和 Prompt。token/s 在 35 到 58 之间剧烈波动。排查发现波动与 GPU 的参与度直接相关。

Apple Silicon 的统一内存架构（UMA）在理论上消除了 CPU 与 GPU 之间的数据拷贝。但在实践中，CPU 核心和 GPU 核心共享同一块 LPDDR5 内存。带宽约为 800GB/s（M2 Ultra）。当 CPU 线程和 GPU 同时执行内存密集型操作时。带宽竞争导致双方性能都恶化。

更深层的问题在于默认调度策略。llama.cpp 默认将一定比例的层 offload 到 GPU（Metal）。剩余的层在 CPU 上计算。CPU 线程数和 GPU offload 层数之间没有协调机制。在默认配置下，CPU 的线程竞争和 GPU 的内存带宽竞争叠加。性能反而不及纯 CPU 推理。

二、Apple Silicon 的内存架构与混合调度模型

Apple Silicon 的 UMA 架构消除了 PCIe 这个传统 GPU 推理的瓶颈。但引入了新的调度挑战。

graph TD A["模型加载"] --> B["GGUF 权重文件"] B --> C["统一内存 UMA 800GB/s"] C --> D["CPU 集群 P-Core（16核）"] C --> E["CPU 集群 E-Core（8核）"] C --> F["GPU 核心（76核）"] C --> G["ANE 神经网络引擎"] subgraph 调度策略 H["层分配决策"] --> H1["靠前层 → GPU（计算密集）"] H --> H2["中间层 → CPU P-Core"] H --> H3["靠后层 → CPU E-Core"] I["线程绑定"] --> I1["P-Core 绑定到性能核心"] I --> I2["E-Core 绑定到能效核心"] I --> I3["GPU 线程绑定到 GPU queue"] J["内存带宽分配"] --> J1["CPU 线程数 × 带宽权重"] J --> J2["GPU 缓存策略"] end D --> H E --> H F --> H

混合调度的核心决策变量有三个：GPU offload 层数（-ngl）、CPU 线程数（-t）和批处理大小（-b）。这三个参数之间存在复杂的相互作用关系。

当-ngl增大时，更多层在 GPU 执行。GPU 占用的内存带宽增加。此时如果-t也很大，CPU 线程会争夺剩余带宽。CPU 推理的 token/s 不但不会随线程数线性增长。反而可能因为带宽不足而下降。

最优配置是通过系统化扫描找到的。在 M2 Ultra 上对 7B 模型 Q4_K_M 量化的测试发现。-ngl 24（将 32 层中的 24 层放 GPU）配合-t 8（仅使用 8 个 P-Core）时。CPU 和 GPU 的带宽使用达到最佳平衡。token/s 稳定在 55 左右。

三、性能优化配置与线程绑定实践

#!/bin/bash # Apple Silicon 上 llama.cpp 的调优脚本 # 目标：找到 CPU/GPU 混合推理的最优参数组合 MODEL="llama-3-8b-instruct-q4_k_m.gguf" PROMPT="用一句话解释什么是内存带宽。" # ========================================== # 阶段一：纯 CPU 推理基线 # ========================================== echo "=== 纯 CPU 基线测试 ===" for threads in 1 2 4 8 16 24; do echo -n "线程数=$threads: " ./llama-cli \ -m "$MODEL" \ -p "$PROMPT" \ -n 128 \ -t "$threads" \ -ngl 0 \ --no-mmap \ 2>&1 | grep "eval time" | awk '{print $5 " token/s"}' done # 观察结果：8 线程后 token/s 不再线性增长 # 这反映了内存带宽的瓶颈（而非 CPU 算力） # ========================================== # 阶段二：GPU offload 扫描 # ========================================== echo -e "\n=== GPU Offload 扫描 ===" for ngl in 0 4 8 12 16 20 24 28 32; do echo -n "GPU层=$ngl: " ./llama-cli \ -m "$MODEL" \ -p "$PROMPT" \ -n 128 \ -t 8 \ -ngl "$ngl" \ --no-mmap \ 2>&1 | grep "eval time" | awk '{print $5 " token/s"}' done # 典型结果：在 ngl=24 时达到峰值 # ngl=32 时性能反而下降——因为 GPU 内部也面临带宽竞争 # ========================================== # 阶段三：最优配置验证 # ========================================== echo -e "\n=== 最优配置 ===" ./llama-cli \ -m "$MODEL" \ -p "$PROMPT" \ -n 256 \ -t 8 \ -ngl 24 \ -b 512 \ -c 4096 \ --mlock \ --no-mmap \ 2>&1 | grep -E "(eval time|total time)" # 实用建议： # -t 8: 仅使用 P-Core（M2 Ultra 有 16 P-Core + 8 E-Core） # 超过 8 线程后，额外的线程争夺带宽而非增加算力 # -ngl 24: 将 75% 的层放在 GPU，剩余 25% 最重的 attention 层用 CPU # 这是经验性最佳比例，精确值需要针对具体模型调优 # -b 512: 批处理大小，平衡吞吐和延迟 # --mlock: 防止模型权重被 swap 到 SSD，避免延迟尖峰 # --no-mmap: 强制加载到物理内存而非 mmap，减少缺页中断

线程绑定的效果可以通过 macOS 的taskpolicy工具进一步优化。

# 将 llama.cpp 进程绑定到 P-Core（性能核心） # -p 表示使用 QoS 高性能等级 taskpolicy -c background ./llama-cli -m model.gguf -p "test" -n 128 -ngl 24 -t 8 # 另一个实用工具：使用 caffeinate 防止系统休眠 caffeinate -i ./llama-cli -m model.gguf -p "test" -n 128

在实际测试中，绑定到 P-Core 可以让 token/s 提升 5%～10%。原因在于 macOS 调度器可能在 E-Core 之间迁移推理线程。每次迁移都会带来 L1/L2 缓存失效的代价。线程绑定消除了这种迁移。

四、Apple Silicon 混合推理的现实局限

Apple Silicon 做推理具有独特的优势和限制。

首先是量化精度的差异。Metal 后端对某些 GGUF 量化格式（如 Q5_1、Q8_0）的支持不完整。如果使用这些量化格式。GPU offload 的层会回退到 FP32 计算。性能反而降低。建议只使用 Q4_0、Q4_K_M 这类 Metal 原生支持的格式。

其次是 batch 推理的困境。GPU 的优势在大 batch 场景才能充分发挥。但 Apple Silicon 的 GPU 仅有 76 核。相比 NVIDIA A100（6912 CUDA Cores）算力差距悬殊。batch 增大到 4 以上时性能上升曲线趋于平坦。这限制了高吞吐场景的适用性。

第三是功耗和散热。M2 Ultra 同时跑满 CPU 和 GPU 时。功耗峰值可达 120W+。在 Mac Studio 等被动散热不充分的机型上。持续高负载会触发降频。推理速度在 5 分钟后下降 15%～20%。监测温度值是生产部署的必要环节。

最后是 Metal 驱动的成熟度。相比 CUDA 十余年的生态积累。Metal 在 AI 推理场景中仍有许多性能优化空间。例如 Metal Performance Shaders（MPS）对某些操作的实现不如 cuBLAS 高效。在计算密集的 GEMM 上差距约 10%～20%。

五、总结

1. Apple Silicon 的统一内存架构消除了 PCIe 拷贝开销。但 CPU 与 GPU 共享带宽时会产生带宽竞争。影响推理性能。
2. 最优 GPU offload 比例通常为 60%～75%。全部 offload 反而可能导致 GPU 内部带宽竞争而性能下降。
3. CPU 线程数不宜超过物理 P-Core 数量。多余的线程争夺内存带宽而非增加算力。
4. 线程绑定到 P-Core 可以防止跨核迁移带来的缓存失效。提升 5%～10% 的稳定性能。
5. 仅使用 Metal 原生支持的量化格式。Q5_1/Q8_0 等格式在 GPU 路径上的性能折损可能抵消 offload 收益。