概览

目前来说, OrangePI AI Pro 上的 LLM 推理部署主要基于 MindIE 和 ascend-llm, 前者通常需要量化(且量化得在端侧或者有 NPU 的设备上进行[1], 后者则需要将 LLM 权重通过 atc 工具转换为 .om 静态图模型(转换为 fp16 时需要在端侧或者有 NPU 的设备上进行[2], 且二者均需要 Python 依赖, 量化与转换也比较耗时.

Llama.cpp 是一个基于 C/C++ 的 LLM 推理引擎. 其模型生态比较好, 大部分 LLM 模型均是支持的, 且支持得比较迅速. 所以如果能够在 Ascend310B 上支持 Llama.cpp, 那么就可以利用 Llama.cpp 较好的模型生态来在 OrangePI AI Pro 去做大多数 LLM 模型的推理加速, 且可以利用广泛的量化后的模型, 从而可以不必在端侧上去做模型转换与量化.

但现有 CANN 后端在 Ascend310B 上并不直接可用. 虽然 Llama.cpp 是有 ggml-cann 后端的, 但其具体实现均采用的是 NN 算子与融合算子, 而这二者在 Ascend310B 上刚好不支持(文档里写的是部分支持, 其实是绝大部份都不支持), 所以无法采用算子库的方式来去对 Ascend310B 进行支持.

基于上述限制,我们尝试构建了一个名为 ascend-blas 的库, 直接对接 Ascend310B 的矩阵运算(Cube 核)能力，以此为 Llama.cpp 提供 NPU 加速.

环境配置

使用的环境版本如下:

注: 虽然项目仅在 CANN 8.5.0 和 CANN 8.5.0.alpha002 的 OrangePI AI Pro 20T(Ascend310B1)上测试过, 但理论上对于 Ascend310B1~Ascend310B4 以及 Atlas 200I/500 A2 推理产品应该均是适用的.

首先构建 AscendBLAS 库:

git clone --recursive https://github.com/xvyv99/ascend-blas
cd ascend-blas
mkdir build
cd build
cmake ..
sudo make -j install

注: 使用 --recursive 是因为 catlass 是作为 ascend-blas 的 Git submodule(在 deps 文件夹下). 该参数可以在 clone ascend-blas时自动拉取catlass, 并将其 checkout 到指定的 commit.

然后构建定制版的 Llama.cpp:

git clone https://github.com/xvyv99/llama.cpp
cd llama.cpp
mkdir build
cd build
cmake .. 
sudo make -j llama-cli

最后运行(以 Qwen3 0.6B 为例, 精度为 fp16):

./bin/llama-cli -m ~/Downloads/qwen3-0.6b-fp16.gguf --prompt "Hello"

效果如下图显示:

性能评估

我们使用 llama-bench 来评估 Llama.cpp 在 Orange PI AI Pro 上的推理性能.

对于 Qwen3 0.6B, 精度为 fp16 时:

看起来与 ascend-llm 的性能差不多(由于不太想搭建 ascend-llm 的环境, 于是参考了 qwen-ascend-llm 里的测试结果, Decode 应该都是 5 t/s 左右, Prefill 的速度并没写所以不知道).

对于 Qwen3 0.6B, 精度为 int8 时:

上述结果看起来比较反常, Prefill 速度下降了很多. 这是大概是因为目前 ascend-blas 并不原生支持 int8 的 GEMM.

具体而言, 在精度为 int8 时, 目前的实现是会反量化到 fp16 上去做计算(也就是 w8a16), 且这个转换在 ggml-cpu 上进行.

• 而对于 Prefill 阶段, 其是 Compute-bound 的, 在 int8 时开销在于反量化(int8->fp16), 所以 Prefill 的速度下降了很多;
• 对于 Decode 阶段, 其是 Memory-bound 的, 精度为 int8 降低了内存带宽压力, 掩盖了转换带来的开销, 所以 Decode 速度会有一定的提升.

具体原理

可以参考我写的这几篇 Blog:

• llama.cpp 在 OrangePi AIPro 上的支持探索 0: 使能 CANN 后端
• llama.cpp 在 OrangePi AIPro 上的支持探索 1: 魔改 ggml-blas 后端

TLDR: 将 CATLASS 中的示例 00_basic_matmul 封装成类 CBLAS 接口, 然后去替换 ggml-blas 的 GGML_OP_MUL_MAT 中调用的 cblas_sgemm 实现, 以此来进行加速, 其他的计算则 fallback 到 CPU 上进行(这个 fallback 是无开销的, 因为其是统一内存).

下一步

接下来打算:

• 添加 int8 原生支持;
• 添加反量化的 NPU 算子实现.

至于 GEMM 和其他算子则没有进一步优化的打算, 因为 GEMM(也就是 GGML_OP_MUL_MAT)是绝对瓶颈, 目前没有太多优化的余地, 而其他算子优化得到的收益很小.

1. DeepSeek-R1-Distill-Llama-8B-OrangePi 中提到: 使用此方法需要另外准备一台Atlas 800I A2或Atlas 300I DUO，转换成功后需把权重转移至香橙派上
2. 基于香橙派AI pro的Qwen3-0.6B的om模型推理部署 中提到: win （仅支持--dtype=float32 ）