llama.cpp 移动端移植详解：从 GGUF 格式看如何通过多线程优化实现 10 tokens/s

前言

随着大语言模型（LLM）的普及，将模型部署在手机端（端侧推理）成为了趋势。llama.cpp 作为一个高性能的 C++ 推理库，通过极致的指令集优化和轻量级的 GGUF 格式，让在手机上流畅运行 Llama-3 成为可能。本文将重点介绍如何通过 GGUF 量化与多线程优化，在 Android 设备上实现 10 tokens/s 的推理速度。

1. 核心基石：GGUF 格式与量化

要在移动端跑得动，模型必须足够小。GGUF 是 llama.cpp 的专用格式，它将模型权重、张量信息和元数据打包在一起。对于手机而言，推荐使用 Q4_K_M（4-bit 量化），它在精度损失极小的前提下，将内存占用降低了约 70%。

模型转换与量化命令示例：

# 将 HuggingFace 模型转换为 GGUF (需要 python 环境)
python3 convert.py models/Llama-3-8B/

# 对模型进行 Q4_K_M 量化
./quantize ./models/Llama-3-8B/ggml-model-f16.gguf ./models/Llama-3-8B/llama-3-q4_k_m.gguf Q4_K_M

2. 交叉编译：针对 Android 架构优化

我们需要利用 Android NDK 将 llama.cpp 编译成 ARM64 架构的可执行文件。建议开启 OpenMP 支持以增强多线程能力。

# 设置 NDK 路径
export NDK=<your_ndk_path>

# 创建构建目录
mkdir build-android && cd build-android

# 使用 CMake 进行交叉编译
cmake -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake \
      -DANDROID_ABI=arm64-v8a \
      -DANDROID_PLATFORM=android-28 \
      -DGGML_OPENMP=ON ..

make -j8

3. 多线程优化策略：冲击 10 tokens/s

推理速度主要取决于 CPU 的计算效率。在移动端，盲目增加线程数反而会导致发热降频，关键在于“对齐核心”。

线程数选择 (-t 参数)

通常手机拥有 8 核 CPU（如 1+3+4 架构）。推理时，应将线程数设置为大核（Performance Cores）的数量。对于骁龙 8 Gen 2/3，设置为 -t 4 或 -t 5 往往比 -t 8 更快，因为小核的木桶效应会拖慢整体进度。

内存锁定 (-mlock)

移动端内存回收机制激进。使用 –mlock 参数可以防止模型权重被操作系统置换到虚拟内存中，从而减少延迟波动。

4. 实战运行命令

通过 adb 将编译产物和模型推送到手机 /data/local/tmp 目录后运行：

./main -m llama-3-q4_k_m.gguf \
       -p "Building a mobile AI application is" \
       -n 128 \
       -t 4 \
       --mlock \
       --color

5. 性能调优 Tips

1. 温控管理：如果发现运行一段时间后 tokens/s 骤降，说明触发了过热降频，建议调减线程数或使用散热背夹。
2. 指令集验证：确保 CPU 支持 DotProd 指令集，这在现代 ARM 架构上能极大地加速矩阵乘法（llama.cpp 会自动检测并开启）。
3. Batch Size：推理单个 Prompt 时，将 -b (batch size) 设置为 512，-ub (ubatch size) 设置为 256 左右，能平衡首词延迟和持续推理速度。

通过以上优化，在主流安卓旗舰机上，Llama-3 8B 模型的推理速度通常能稳定在 8-12 tokens/s，基本满足实时对话的需求。