llama.cpp 在 IBM Zs390x主帧上构建与部署实战VXE/VXE2 向量化、zDNN 加速器与 GGUF 大端模型【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp本篇技术指南基于 llama.cpp 仓库中面向 IBM Z LinuxONE 主帧s390x 架构的专用构建文档完整讲解如何在这类大端Big-EndianRISC 处理器上完成 llama.cpp 的编译、加速与模型准备。读完本文后你将掌握使用 OpenBLAS VXE/VXE2 SIMD 指令的原生 CPU 构建、可选的 IBM zDNN 协同处理器后端、safetensors/GGUF 小端模型向 GGUF 大端格式的三条转换路径以及 IFL 核心数、SMT、虚拟化方式等关键性能调优要点。适用范围与项目结构该构建流程仅适用于 IBM Z LinuxONE 主帧s390x 架构其他架构x86_64、aarch64 等请参考仓库通用构建文档。llama.cpp 的核心产物是llama库其 C 风格接口定义在 include/llama.h项目同时提供大量基于该库的示例程序与工具从最简单的代码片段到 OpenAI 兼容的 HTTP servertools/server一应俱全。这些工具在 s390x 上同样适用只是构建方式需要做主帧适配。获取代码git clone https://github.com/ggml-org/llama.cpp cd llama.cpp说明仓库当前检出环境如需离线获取可使用项目对应的镜像地址本文后续不再重复说明。CPU 构建OpenBLAS VXE/VXE2 向量加速文档明确建议在 s390x 上构建 llama.cpp 时开启 BLAS 支持实测有可观的性能提升。前提是环境中已安装 OpenBLAS通常通过发行版包管理器安装。标准 Release 构建cmake -S . -B build \ -DCMAKE_BUILD_TYPERelease \ -DGGML_BLASON \ -DGGML_BLAS_VENDOROpenBLAS cmake --build build --config Release -j $(nproc)VXE/VXE2 默认开启何时需要关闭VXE/VXE2 向量扩展默认启用仅在极少数场景下如针对 z14 或更早机型交叉编译才需要显式关闭文档标注“不建议关闭”cmake -S . -B build \ -DCMAKE_BUILD_TYPERelease \ -DGGML_BLASON \ -DGGML_BLAS_VENDOROpenBLAS \ -DGGML_VXEOFF cmake --build build --config Release -j $(nproc)Debug 构建与静态库构建调试构建只需切换构建类型cmake -S . -B build \ -DCMAKE_BUILD_TYPEDebug \ -DGGML_BLASON \ -DGGML_BLAS_VENDOROpenBLAS cmake --build build --config Debug -j $(nproc)若需要静态链接产物追加-DBUILD_SHARED_LIBSOFFcmake -S . -B build \ -DCMAKE_BUILD_TYPERelease \ -DGGML_BLASON \ -DGGML_BLAS_VENDOROpenBLAS \ -DBUILD_SHARED_LIBSOFF cmake --build build --config Release -j $(nproc)另外文档建议在频繁重复编译的环境安装 ccache 以加速重编译。源码剖析CMake 如何识别 z15/z16/z17上述参数背后的机型探测逻辑位于 ggml/src/ggml-cpu/CMakeLists.txt。当 CMake 检测到GGML_SYSTEM_ARCH为s390x时在原生编译GGML_NATIVE场景下读取/proc/cpuinfo中的machine字段按机型号精确映射目标架构8561/8562→ z15生成-marchz153931→ z16生成-marchz169175/9176→ z17生成-marcharch15注释说明-marchz17只有 GCC ≥ 15.1.0 且 binutils 更新到最新版才可用否则回退-marcharch15无法识别时发出警告“若你在 z14 或更早机型上编译可能需要追加-DGGML_VXEOFF”并退化为-marchnative -mtunenative。在交叉编译GGML_CPU_ALL_VARIANTS场景下可循环 z15–z17 生成多架构目标。当GGML_VXE或内部 VXE2 特性开启时追加-mvx -mzvector编译标志并定义宏GGML_USE_VXE2同时把 s390 专用量化实现 ggml-cpu/arch/s390/quants.c 加入编译源文件列表。GGML_VXE选项本身声明于 ggml/CMakeLists.txt默认跟随GGML_NATIVEoption(GGML_VXE ggml: enable vxe ${GGML_NATIVE})向量量化内核位于 ggml/src/ggml-cpu/arch/s390/quants.c约 1400 行在__VXE__/__VXE2__宏下提供基于字节位操作展开的 SIMD 量化运算同目录下的 cpu-feats.cpp 负责运行时特性检测。从源码结构看z14 及更早系统arch12由于不支持 VXE 指令集llama.cpp 的 API 仍可运行但只能走标量实现——这就是 FAQ 中“z14 需关闭 VXE”提示的来源。IBM zDNN 加速器后端zDNN 后端利用 Telum I / Telum II 处理器内置的zAIUAI 单元协同处理器做矩阵运算加速适用于 IBM z17 / LinuxONE 5 及以后机型。准备安装 IBM zDNN 库按 IBM 官方 zDNN 仓库的“Building and Installing zDNN”指引从源码编译安装。CMake 会自动在/usr、/usr/local等路径下查找zdnn.h头文件与libzdnn库若安装到了非标准路径可设置ZDNN_ROOT指向安装根目录。这一发现逻辑实现在 ggml/src/ggml-zdnn/CMakeLists.txt找不到头文件或库时会直接FATAL_ERROR并提示设置ZDNN_ROOT。编译cmake -S . -B build \ -DCMAKE_BUILD_TYPERelease \ -DGGML_ZDNNON cmake --build build --config Release -j$(nproc)GGML_ZDNN选项定义在 ggml/CMakeLists.txt默认OFF。后端实现位于 ggml/src/ggml-zdnn包含 ggml-zdnn.cpp、mmf.cpp矩阵乘法调用等文件构建成功后会注册为独立的ggml-zdnn后端库。硬件回退行为仅 IBM z17 / LinuxONE 5 及以上系统可用在 z15 / arch13 等较旧系统上API 不会报错而是回退到 CPU 例程执行。获取 GGUF 模型大端Big-Endian三路径这是 s390x 部署中最容易踩坑的环节主帧是大端架构所有模型必须转换为 GGUFv3 Big-Endian 格式才能加载。文档给出三种途径。路径一使用预转换并验证过的模型最简单直接选用已转换为 GGUF 大端、并验证过 tokenizer 在 IBM z15 及以后系统上可正确运行的模型合集。此类模型的 tokenizer 已验证在 z15 系统上运行正确无需任何本地转换操作。路径二从 safetensors 直接转换为 GGUF 大端推荐源模型必须是safetensors格式。先确保转换依赖已安装pip3 install -r requirements.txt然后执行转换关键参数为--bigendian该参数定义于 convert_hf_to_gguf.py会以is_big_endian形式传入 GGUF 写入器python3 convert_hf_to_gguf.py \ --outfile model-name-be.f16.gguf \ --outtype f16 \ --bigendian \ model-directory/以 Granite 3.3 2B 为例python3 convert_hf_to_gguf.py \ --outfile granite-3.3-2b-instruct-be.f16.gguf \ --outtype f16 \ --bigendian \ granite-3.3-2b-instruct/路径三已有 GGUF 小端模型转大端若手头是现成的小端Little-EndianGGUF 文件可用仓库自带脚本原地翻转字节序方向参数BIG表示转为大端python3 gguf-py/gguf/scripts/gguf_convert_endian.py model-name.f16.gguf BIG示例注意转换后建议重命名以-be结尾以便区分python3 gguf-py/gguf/scripts/gguf_convert_endian.py granite-3.3-2b-instruct-le.f16.gguf BIG mv granite-3.3-2b-instruct-le.f16.gguf granite-3.3-2b-instruct-be.f16.gguf脚本位置见 gguf-py/gguf/scripts/gguf_convert_endian.py。文档特别提示该端序转换脚本目前可能不支持所有数据类型对某些模型/量化格式可能失败此时请回退到路径二手动从 safetensors 重新转换为大端 GGUF。如何确认模型字节序出了问题加载小端模型时GGUF 版本字段会被按大端错误解读产生标志性报错。该报错源头在 ggml/src/gguf.cppgguf_init_from_file_impl: failed to load model: this GGUF file version 50331648 is extremely large, is there a mismatch between the host and model endianness?出现此错误时检查模型是否为 GGUFv3 大端文件通常以-be后缀命名并按上文三路径之一重新准备模型。IBM 加速器一览加速器适用系统编译开关旧系统行为VXE/VXE2 SIMDIBM z15 / LinuxONE 3 及以上-DGGML_VXEON默认开启z14/arch12 无硬件加速走标量实现zDNNIBM z17 / LinuxONE 5 及以上-DGGML_ZDNNONz15/arch13 回退到 CPU 例程SpyreIBM z17 / LinuxONE 5 及以上暂不支持目前无支持计划性能调优四要点虚拟化方式强烈建议仅使用 LPARType-1虚拟化以获得最佳性能。Type-2 虚拟化目前不受支持——虽然可以跑起来但性能不会理想。IFL核心数量建议至少为 LPAR 分配 8 个共享 IFL。超过 8 个共享 IFL 后仅 Prompt Processing 性能会提升Token Generation 不再受益。注意 IFL 数不等于 vCPU 数。SMT同时多线程强烈建议通过内核启动参数关闭 SMT它对性能有负面影响。具体操作请参照所用 Linux 发行版关闭 SMT 的官方指南。BLAS vs 无 BLASVXE/VXE2 SIMD 加速的效果依赖于 BLAS 实现强烈建议始终开启 BLAS 构建即前文的-DGGML_BLASON。常见问题FAQ1. 加载模型报错 “GGUF file version 50331648 is extremely large ... endianness”确认你下载/转换的模型是GGUFv3 大端通常以-be后缀命名如granite-3.3-2b-instruct-be.F16.gguf。否则参照上文“获取 GGUF 模型”章节手动将 safetensors 转换为大端 GGUF。2. 推理性能极差对照后文“附录 BSIMD 支持矩阵”检查你的量化类型是否受 SIMD 加速支持。若该量化如 Q2_K、IQ1_S、IQ2_S 等在矩阵中为“不支持”运行将退化为标量实现性能自然大幅下降。3. 在 IBM z17 上构建报错invalid switch -marchz17确保 GCC 版本不低于 15.1.0且binutils已更新到最新版。这与 CMake 源码中的注释一致ggml/src/ggml-cpu/CMakeLists.txt 明确注明-marchz17需要 GCC 15.1.0否则必须使用-marcharch15。若更新后仍失败应到项目 issue 区提交问题。4. GCC 15 环境下sentencepiece安装失败这是上游 sentencepiece 项目已知问题。临时 workaround 是在安装时强制头文件包含export CXXFLAGS-include cstdint例如CXXFLAGS-include cstdint pip3 install -r requirements.txt在 IBM Z LinuxONE 上求助Bug / 功能请求在 llama.cpp 项目提交 issue并确保标题包含s390x关键字以便维护者识别目标架构。其他问题可联系文档中给出的 IBM 团队邮箱aionzus.ibm.com咨询。附录 A硬件支持矩阵硬件支持状态最低编译器版本IBM z15支持已验证—IBM z16支持已验证—IBM z17支持已验证GCC 15.1.0IBM zDNN支持已验证—“支持”表示已验证可按预期运行“不支持”文档以 标注表示不太可能提供支持的系统。附录 BSIMD 支持矩阵下表说明各量化/算子在 VXE/VXE2、zDNN、Spyre 三类加速路径下的支持情况。选择模型量化时务必参考此表——不在加速范围内的类型会退化为标量实现。量化/算子VX/VXE/VXE2zDNNSpyreFP32支持支持未知FP16支持支持未知BF16支持支持未知Q4_0支持未知未知Q4_1支持未知未知MXFP4支持未知未知Q5_0支持未知未知Q5_1支持未知未知Q8_0支持未知未知Q2_K不支持标量回退未知未知Q3_K支持未知未知Q4_K支持未知未知Q5_K支持未知未知Q6_K支持未知未知TQ1_0不支持标量回退未知未知TQ2_0不支持标量回退未知未知IQ2_XXS不支持标量回退未知未知IQ2_XS不支持标量回退未知未知IQ2_S不支持标量回退未知未知IQ3_XXS不支持标量回退未知未知IQ3_S不支持标量回退未知未知IQ1_S不支持标量回退未知未知IQ1_M不支持标量回退未知未知IQ4_NL支持未知未知IQ4_XS支持未知未知FP32-FP16不支持标量回退未知未知FP16-FP32不支持标量回退未知未知“支持” 有硬件加速可用“不支持” 无加速仍以标量实现运行功能正确性能下降“未知” 加速状态未经确认文档鼓励社区自行测试并回馈结果。小结在 IBM Z / LinuxONE 上部署 llama.cpp 的关键链路可以概括为OpenBLAS 默认开启的 VXE/VXE2 完成基线加速z15z17 上可叠加 zDNN/zAIU 协同加速模型侧必须使用 GGUF 大端格式预转换、--bigendian直接转换、或gguf_convert_endian.py转端序三条路径。配合 LPAR 虚拟化、≥8 共享 IFL、关闭 SMT 等调优手段即可在主帧上获得可用的 LLM 推理性能。所有构建开关GGML_VXE、GGML_ZDNN、GGML_BLAS等均可在当前仓库的 ggml/CMakeLists.txt 中查证机型探测与向量编译标志的具体行为则体现在 ggml/src/ggml-cpu/CMakeLists.txt 与 ggml/src/ggml-cpu/arch/s390/ 的实现中。【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
llama.cpp 在 IBM Zs390x主帧上构建与部署实战VXE/VXE2 向量化、zDNN 加速器与 GGUF 大端模型【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp本篇技术指南基于 llama.cpp 仓库中面向 IBM Z LinuxONE 主帧s390x 架构的专用构建文档完整讲解如何在这类大端Big-EndianRISC 处理器上完成 llama.cpp 的编译、加速与模型准备。读完本文后你将掌握使用 OpenBLAS VXE/VXE2 SIMD 指令的原生 CPU 构建、可选的 IBM zDNN 协同处理器后端、safetensors/GGUF 小端模型向 GGUF 大端格式的三条转换路径以及 IFL 核心数、SMT、虚拟化方式等关键性能调优要点。适用范围与项目结构该构建流程仅适用于 IBM Z LinuxONE 主帧s390x 架构其他架构x86_64、aarch64 等请参考仓库通用构建文档。llama.cpp 的核心产物是llama库其 C 风格接口定义在 include/llama.h项目同时提供大量基于该库的示例程序与工具从最简单的代码片段到 OpenAI 兼容的 HTTP servertools/server一应俱全。这些工具在 s390x 上同样适用只是构建方式需要做主帧适配。获取代码git clone https://github.com/ggml-org/llama.cpp cd llama.cpp说明仓库当前检出环境如需离线获取可使用项目对应的镜像地址本文后续不再重复说明。CPU 构建OpenBLAS VXE/VXE2 向量加速文档明确建议在 s390x 上构建 llama.cpp 时开启 BLAS 支持实测有可观的性能提升。前提是环境中已安装 OpenBLAS通常通过发行版包管理器安装。标准 Release 构建cmake -S . -B build \ -DCMAKE_BUILD_TYPERelease \ -DGGML_BLASON \ -DGGML_BLAS_VENDOROpenBLAS cmake --build build --config Release -j $(nproc)VXE/VXE2 默认开启何时需要关闭VXE/VXE2 向量扩展默认启用仅在极少数场景下如针对 z14 或更早机型交叉编译才需要显式关闭文档标注“不建议关闭”cmake -S . -B build \ -DCMAKE_BUILD_TYPERelease \ -DGGML_BLASON \ -DGGML_BLAS_VENDOROpenBLAS \ -DGGML_VXEOFF cmake --build build --config Release -j $(nproc)Debug 构建与静态库构建调试构建只需切换构建类型cmake -S . -B build \ -DCMAKE_BUILD_TYPEDebug \ -DGGML_BLASON \ -DGGML_BLAS_VENDOROpenBLAS cmake --build build --config Debug -j $(nproc)若需要静态链接产物追加-DBUILD_SHARED_LIBSOFFcmake -S . -B build \ -DCMAKE_BUILD_TYPERelease \ -DGGML_BLASON \ -DGGML_BLAS_VENDOROpenBLAS \ -DBUILD_SHARED_LIBSOFF cmake --build build --config Release -j $(nproc)另外文档建议在频繁重复编译的环境安装 ccache 以加速重编译。源码剖析CMake 如何识别 z15/z16/z17上述参数背后的机型探测逻辑位于 ggml/src/ggml-cpu/CMakeLists.txt。当 CMake 检测到GGML_SYSTEM_ARCH为s390x时在原生编译GGML_NATIVE场景下读取/proc/cpuinfo中的machine字段按机型号精确映射目标架构8561/8562→ z15生成-marchz153931→ z16生成-marchz169175/9176→ z17生成-marcharch15注释说明-marchz17只有 GCC ≥ 15.1.0 且 binutils 更新到最新版才可用否则回退-marcharch15无法识别时发出警告“若你在 z14 或更早机型上编译可能需要追加-DGGML_VXEOFF”并退化为-marchnative -mtunenative。在交叉编译GGML_CPU_ALL_VARIANTS场景下可循环 z15–z17 生成多架构目标。当GGML_VXE或内部 VXE2 特性开启时追加-mvx -mzvector编译标志并定义宏GGML_USE_VXE2同时把 s390 专用量化实现 ggml-cpu/arch/s390/quants.c 加入编译源文件列表。GGML_VXE选项本身声明于 ggml/CMakeLists.txt默认跟随GGML_NATIVEoption(GGML_VXE ggml: enable vxe ${GGML_NATIVE})向量量化内核位于 ggml/src/ggml-cpu/arch/s390/quants.c约 1400 行在__VXE__/__VXE2__宏下提供基于字节位操作展开的 SIMD 量化运算同目录下的 cpu-feats.cpp 负责运行时特性检测。从源码结构看z14 及更早系统arch12由于不支持 VXE 指令集llama.cpp 的 API 仍可运行但只能走标量实现——这就是 FAQ 中“z14 需关闭 VXE”提示的来源。IBM zDNN 加速器后端zDNN 后端利用 Telum I / Telum II 处理器内置的zAIUAI 单元协同处理器做矩阵运算加速适用于 IBM z17 / LinuxONE 5 及以后机型。准备安装 IBM zDNN 库按 IBM 官方 zDNN 仓库的“Building and Installing zDNN”指引从源码编译安装。CMake 会自动在/usr、/usr/local等路径下查找zdnn.h头文件与libzdnn库若安装到了非标准路径可设置ZDNN_ROOT指向安装根目录。这一发现逻辑实现在 ggml/src/ggml-zdnn/CMakeLists.txt找不到头文件或库时会直接FATAL_ERROR并提示设置ZDNN_ROOT。编译cmake -S . -B build \ -DCMAKE_BUILD_TYPERelease \ -DGGML_ZDNNON cmake --build build --config Release -j$(nproc)GGML_ZDNN选项定义在 ggml/CMakeLists.txt默认OFF。后端实现位于 ggml/src/ggml-zdnn包含 ggml-zdnn.cpp、mmf.cpp矩阵乘法调用等文件构建成功后会注册为独立的ggml-zdnn后端库。硬件回退行为仅 IBM z17 / LinuxONE 5 及以上系统可用在 z15 / arch13 等较旧系统上API 不会报错而是回退到 CPU 例程执行。获取 GGUF 模型大端Big-Endian三路径这是 s390x 部署中最容易踩坑的环节主帧是大端架构所有模型必须转换为 GGUFv3 Big-Endian 格式才能加载。文档给出三种途径。路径一使用预转换并验证过的模型最简单直接选用已转换为 GGUF 大端、并验证过 tokenizer 在 IBM z15 及以后系统上可正确运行的模型合集。此类模型的 tokenizer 已验证在 z15 系统上运行正确无需任何本地转换操作。路径二从 safetensors 直接转换为 GGUF 大端推荐源模型必须是safetensors格式。先确保转换依赖已安装pip3 install -r requirements.txt然后执行转换关键参数为--bigendian该参数定义于 convert_hf_to_gguf.py会以is_big_endian形式传入 GGUF 写入器python3 convert_hf_to_gguf.py \ --outfile model-name-be.f16.gguf \ --outtype f16 \ --bigendian \ model-directory/以 Granite 3.3 2B 为例python3 convert_hf_to_gguf.py \ --outfile granite-3.3-2b-instruct-be.f16.gguf \ --outtype f16 \ --bigendian \ granite-3.3-2b-instruct/路径三已有 GGUF 小端模型转大端若手头是现成的小端Little-EndianGGUF 文件可用仓库自带脚本原地翻转字节序方向参数BIG表示转为大端python3 gguf-py/gguf/scripts/gguf_convert_endian.py model-name.f16.gguf BIG示例注意转换后建议重命名以-be结尾以便区分python3 gguf-py/gguf/scripts/gguf_convert_endian.py granite-3.3-2b-instruct-le.f16.gguf BIG mv granite-3.3-2b-instruct-le.f16.gguf granite-3.3-2b-instruct-be.f16.gguf脚本位置见 gguf-py/gguf/scripts/gguf_convert_endian.py。文档特别提示该端序转换脚本目前可能不支持所有数据类型对某些模型/量化格式可能失败此时请回退到路径二手动从 safetensors 重新转换为大端 GGUF。如何确认模型字节序出了问题加载小端模型时GGUF 版本字段会被按大端错误解读产生标志性报错。该报错源头在 ggml/src/gguf.cppgguf_init_from_file_impl: failed to load model: this GGUF file version 50331648 is extremely large, is there a mismatch between the host and model endianness?出现此错误时检查模型是否为 GGUFv3 大端文件通常以-be后缀命名并按上文三路径之一重新准备模型。IBM 加速器一览加速器适用系统编译开关旧系统行为VXE/VXE2 SIMDIBM z15 / LinuxONE 3 及以上-DGGML_VXEON默认开启z14/arch12 无硬件加速走标量实现zDNNIBM z17 / LinuxONE 5 及以上-DGGML_ZDNNONz15/arch13 回退到 CPU 例程SpyreIBM z17 / LinuxONE 5 及以上暂不支持目前无支持计划性能调优四要点虚拟化方式强烈建议仅使用 LPARType-1虚拟化以获得最佳性能。Type-2 虚拟化目前不受支持——虽然可以跑起来但性能不会理想。IFL核心数量建议至少为 LPAR 分配 8 个共享 IFL。超过 8 个共享 IFL 后仅 Prompt Processing 性能会提升Token Generation 不再受益。注意 IFL 数不等于 vCPU 数。SMT同时多线程强烈建议通过内核启动参数关闭 SMT它对性能有负面影响。具体操作请参照所用 Linux 发行版关闭 SMT 的官方指南。BLAS vs 无 BLASVXE/VXE2 SIMD 加速的效果依赖于 BLAS 实现强烈建议始终开启 BLAS 构建即前文的-DGGML_BLASON。常见问题FAQ1. 加载模型报错 “GGUF file version 50331648 is extremely large ... endianness”确认你下载/转换的模型是GGUFv3 大端通常以-be后缀命名如granite-3.3-2b-instruct-be.F16.gguf。否则参照上文“获取 GGUF 模型”章节手动将 safetensors 转换为大端 GGUF。2. 推理性能极差对照后文“附录 BSIMD 支持矩阵”检查你的量化类型是否受 SIMD 加速支持。若该量化如 Q2_K、IQ1_S、IQ2_S 等在矩阵中为“不支持”运行将退化为标量实现性能自然大幅下降。3. 在 IBM z17 上构建报错invalid switch -marchz17确保 GCC 版本不低于 15.1.0且binutils已更新到最新版。这与 CMake 源码中的注释一致ggml/src/ggml-cpu/CMakeLists.txt 明确注明-marchz17需要 GCC 15.1.0否则必须使用-marcharch15。若更新后仍失败应到项目 issue 区提交问题。4. GCC 15 环境下sentencepiece安装失败这是上游 sentencepiece 项目已知问题。临时 workaround 是在安装时强制头文件包含export CXXFLAGS-include cstdint例如CXXFLAGS-include cstdint pip3 install -r requirements.txt在 IBM Z LinuxONE 上求助Bug / 功能请求在 llama.cpp 项目提交 issue并确保标题包含s390x关键字以便维护者识别目标架构。其他问题可联系文档中给出的 IBM 团队邮箱aionzus.ibm.com咨询。附录 A硬件支持矩阵硬件支持状态最低编译器版本IBM z15支持已验证—IBM z16支持已验证—IBM z17支持已验证GCC 15.1.0IBM zDNN支持已验证—“支持”表示已验证可按预期运行“不支持”文档以 标注表示不太可能提供支持的系统。附录 BSIMD 支持矩阵下表说明各量化/算子在 VXE/VXE2、zDNN、Spyre 三类加速路径下的支持情况。选择模型量化时务必参考此表——不在加速范围内的类型会退化为标量实现。量化/算子VX/VXE/VXE2zDNNSpyreFP32支持支持未知FP16支持支持未知BF16支持支持未知Q4_0支持未知未知Q4_1支持未知未知MXFP4支持未知未知Q5_0支持未知未知Q5_1支持未知未知Q8_0支持未知未知Q2_K不支持标量回退未知未知Q3_K支持未知未知Q4_K支持未知未知Q5_K支持未知未知Q6_K支持未知未知TQ1_0不支持标量回退未知未知TQ2_0不支持标量回退未知未知IQ2_XXS不支持标量回退未知未知IQ2_XS不支持标量回退未知未知IQ2_S不支持标量回退未知未知IQ3_XXS不支持标量回退未知未知IQ3_S不支持标量回退未知未知IQ1_S不支持标量回退未知未知IQ1_M不支持标量回退未知未知IQ4_NL支持未知未知IQ4_XS支持未知未知FP32-FP16不支持标量回退未知未知FP16-FP32不支持标量回退未知未知“支持” 有硬件加速可用“不支持” 无加速仍以标量实现运行功能正确性能下降“未知” 加速状态未经确认文档鼓励社区自行测试并回馈结果。小结在 IBM Z / LinuxONE 上部署 llama.cpp 的关键链路可以概括为OpenBLAS 默认开启的 VXE/VXE2 完成基线加速z15z17 上可叠加 zDNN/zAIU 协同加速模型侧必须使用 GGUF 大端格式预转换、--bigendian直接转换、或gguf_convert_endian.py转端序三条路径。配合 LPAR 虚拟化、≥8 共享 IFL、关闭 SMT 等调优手段即可在主帧上获得可用的 LLM 推理性能。所有构建开关GGML_VXE、GGML_ZDNN、GGML_BLAS等均可在当前仓库的 ggml/CMakeLists.txt 中查证机型探测与向量编译标志的具体行为则体现在 ggml/src/ggml-cpu/CMakeLists.txt 与 ggml/src/ggml-cpu/arch/s390/ 的实现中。【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
