企业官网建设流程全解析

llama.cpp zDNN 后端如何在 IBM z17 上编译 zDNN 库并构建启用 GGML_ZDNN 的二进制

【免费下载链接】llama.cppLLM inference in C/C++项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp

这篇文章对应一个具体任务：在 IBM z17（LinuxONE 5）主frame 上，从源码编译安装 IBM zDNN 加速库，再用 CMake 构建出启用GGML_ZDNN后端的 llama.cpp 二进制。完成后的结果是：zDNN 库安装在指定前缀目录（下文为/opt/zdnn-libs），llama.cpp 的 ggml 构建出ggml-zdnn后端库，可以利用 Telum I / Telum II 处理器内的 NNPA 硬件加速器。

先明确几个前提，避免走错方向：

• 硬件范围：zDNN 后端仅在 IBM z17 / LinuxONE 5 及更新系统上受支持；IBM z16 / LinuxONE 4 明确标记为 Not Supported（见 docs/backend/zDNN.md）。文档中验证过的环境是 RHEL 9.6、IBM z17、40 IFLs。
• 编译器版本：在 z17 上编译时，需要至少 GCC 15.1.0 的 GCC 编译器，并将binutils更新到最新版本；否则会报invalid switch -march=z17（见 docs/build-s390x.md 的 FAQ 与 Appendix A）。
• 概念区分：zDNN（IBM 面向 IBM Z 与 LinuxONE 主frame 的 DNN 加速库）与 ZenDNN（AMD EPYC 的深度学习库）是两个完全不同的东西，不要混用文档。
• 包管理器版本不可靠：通过apt或yum提供的 zDNN 库可能无法正常工作（上游 issue #15772），官方建议从源码编译，这也是本文的主路径。
• 数据范围：zDNN 后端当前支持的数据类型为 F32、F16、BF16。

1. 从源码编译并安装 zDNN 库

以下命令来自 docs/backend/zDNN.md 的 "Install zDNN Library" 章节：

git clone --recurse-submodules https://github.com/IBM/zDNN cd zDNN autoreconf . ./configure --prefix=/opt/zdnn-libs make build sudo make install

几点执行说明：

• --recurse-submodules会一并拉取 zDNN 仓库依赖的子模块，不要省略，否则后续configure/make可能因缺少子模块内容而失败。
• ./configure --prefix=/opt/zdnn-libs决定安装前缀。这个前缀不是随便取的——它会被第二步的ZDNN_ROOT参数原样引用，改前缀时两处必须保持一致。
• sudo make install会向/opt/zdnn-libs写入头文件和库文件，需要 root 权限；副作用仅限于该前缀目录，不会动系统全局路径。安装完成后，该目录下应包含include/zdnn.h与lib/lib64下的libzdnn，这两者正是 CMake 查找的目标（见下文验证部分）。

2. 构建启用 GGML_ZDNN 的 llama.cpp

git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -S . -G Ninja -B build \ -DCMAKE_BUILD_TYPE=Release \ -DGGML_ZDNN=ON \ -DZDNN_ROOT=/opt/zdnn-libs cmake --build build --config Release -j$(nproc)

两个关键选项的含义（见 docs/backend/zDNN.md 的 CMake Options 一节）：

ZDNN_ROOT必须指向第一步的--prefix路径（本文示例为/opt/zdnn-libs）。如果你把 zDNN 装到了/usr或/usr/local这类默认查找位置，则可以省略该参数，构建命令退化为 docs/build-s390x.md "IBM zDNN Accelerator" 一节给出的形式（仅-DGGML_ZDNN=ON）。

3. 核对构建结果：CMake 的查找输出

配置阶段（cmake -S . -B build ...这一步）的输出是判断 zDNN 是否被正确找到的直接依据。ggml/src/ggml-zdnn/CMakeLists.txt 中定义了查找逻辑与输出信息：

• 指定了ZDNN_ROOT时，会先打印zdnn: using ZDNN_ROOT override: <路径>；
• 头文件查找成功时打印zdnn: found include: <路径>（查找zdnn.h，查找位置为ZDNN_ROOT、/usr、/usr/local的include子目录）；
• 库查找成功时打印zdnn: found library: <路径>（查找zdnn库，查找位置为ZDNN_ROOT、/usr、/usr/local的lib/lib64子目录）。

如果三步中任何一步失败，配置会直接以FATAL_ERROR终止，报错形如：

zdnn: include directory not found, please set ZDNN_ROOT to the proper path if necessary zdnn: library not found, please set ZDNN_ROOT to the proper path if necessary

遇到这类报错的处理路径很明确：检查第一步的安装前缀是否正确、ZDNN_ROOT是否与该前缀一致（包括是否漏了--prefix导致的实际落点不同）。配置通过且cmake --build成功后，build目录中即得到启用 zDNN 后端的 llama.cpp 构建产物。

4. 已知限制与运行前注意

• 旧硬件回退：在 IBM z15 等更老系统上，zDNN 硬件加速不可用，相关 API 会回退到 CPU 例程；这不是报错路径，但意味着加速不生效。
• 量化类型覆盖：按 docs/build-s390x.md 的 SIMD Support Matrix，zDNN 列中 FP32/FP16/BF16 标记为加速可用，各量化类型（Q4_0、Q8_0、Q*_K 等）目前标记为 unknown，文档建议使用者自行测试后反馈。
• 模型字节序：构建完成后运行推理时，模型必须转换为 Big-Endian GGUF。docs/build-s390x.md 的 "Getting GGUF Models" 一节给出了三种途径（使用已转换的现成模型、用convert_hf_to_gguf.py --bigendian从 safetensors 转换、用gguf-py/gguf/scripts/gguf_convert_endian.py转换已有 GGUF）；加载小端模型时会报this GGUF file version ... is there a mismatch between the host and model endianness?，按该文档 FAQ 处理即可。本文不展开这一步，因为它属于独立的模型准备任务。

【免费下载链接】llama.cppLLM inference in C/C++项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp