llama.cpp zDNN 后端如何在 IBM z17 上编译 zDNN 库并构建启用 GGML_ZDNN 的二进制【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp这篇文章对应一个具体任务在 IBM z17LinuxONE 5主frame 上从源码编译安装 IBM zDNN 加速库再用 CMake 构建出启用GGML_ZDNN后端的 llama.cpp 二进制。完成后的结果是zDNN 库安装在指定前缀目录下文为/opt/zdnn-libsllama.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 -marchz17见 docs/build-s390x.md 的 FAQ 与 Appendix A。概念区分zDNNIBM 面向 IBM Z 与 LinuxONE 主frame 的 DNN 加速库与 ZenDNNAMD 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.cppgit clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -S . -G Ninja -B build \ -DCMAKE_BUILD_TYPERelease \ -DGGML_ZDNNON \ -DZDNN_ROOT/opt/zdnn-libs cmake --build build --config Release -j$(nproc)两个关键选项的含义见 docs/backend/zDNN.md 的 CMake Options 一节CMake 选项默认值说明GGML_ZDNNOFF是否编译带 zDNN 支持的 llama.cppGGML_ZDNN选项定义在 ggml/CMakeLists.txtZDNN_ROOT覆盖 zDNN 库的查找路径ZDNN_ROOT必须指向第一步的--prefix路径本文示例为/opt/zdnn-libs。如果你把 zDNN 装到了/usr或/usr/local这类默认查找位置则可以省略该参数构建命令退化为 docs/build-s390x.md IBM zDNN Accelerator 一节给出的形式仅-DGGML_ZDNNON。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 MatrixzDNN 列中 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/10 13:11:19 · 阅读 1.2k llama.cpp zDNN 后端如何在 IBM z17 上编译 zDNN 库并构建启用 GGML_ZDNN 的二进制
llama.cpp zDNN 后端如何在 IBM z17 上编译 zDNN 库并构建启用 GGML_ZDNN 的二进制【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp这篇文章对应一个具体任务在 IBM z17LinuxONE 5主frame 上从源码编译安装 IBM zDNN 加速库再用 CMake 构建出启用GGML_ZDNN后端的 llama.cpp 二进制。完成后的结果是zDNN 库安装在指定前缀目录下文为/opt/zdnn-libsllama.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 -marchz17见 docs/build-s390x.md 的 FAQ 与 Appendix A。概念区分zDNNIBM 面向 IBM Z 与 LinuxONE 主frame 的 DNN 加速库与 ZenDNNAMD 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.cppgit clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -S . -G Ninja -B build \ -DCMAKE_BUILD_TYPERelease \ -DGGML_ZDNNON \ -DZDNN_ROOT/opt/zdnn-libs cmake --build build --config Release -j$(nproc)两个关键选项的含义见 docs/backend/zDNN.md 的 CMake Options 一节CMake 选项默认值说明GGML_ZDNNOFF是否编译带 zDNN 支持的 llama.cppGGML_ZDNN选项定义在 ggml/CMakeLists.txtZDNN_ROOT覆盖 zDNN 库的查找路径ZDNN_ROOT必须指向第一步的--prefix路径本文示例为/opt/zdnn-libs。如果你把 zDNN 装到了/usr或/usr/local这类默认查找位置则可以省略该参数构建命令退化为 docs/build-s390x.md IBM zDNN Accelerator 一节给出的形式仅-DGGML_ZDNNON。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 MatrixzDNN 列中 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考