ZLUDA 下运行 llama.cppCUDA 架构选择与 cuBLAS 编译配置实战指南【免费下载链接】ZLUDACUDA on non-NVIDIA GPUs项目地址: https://gitcode.com/GitHub_Trending/zl/ZLUDA本文基于 ZLUDA 官方文档 llama_cpp.md 展开讲解如何在 ZLUDAAMD GPU 上的 CUDA 替代方案中正确编译并运行 llama.cpp给出官方推荐的完整 cmake 构建命令、逐参数解释其含义、说明为何 CUDA 架构必须选择 80/86/89 之一结合 ZLUDA 报告的算力等级实现、解释 cuBLAS 强制开启与底层 rocBLAS 的映射关系以及 Windows 平台 HIP SDK 的安装前提。读完本文你将能够独立完成 llama.cpp 在 ZLUDA 环境下的构建、运行与常见故障定位。前置条件ZLUDA 是什么运行 llama.cpp 需要什么ZLUDA 的定位是非 NVIDIA GPU 上的 CUDA 直接替换件drop-in replacement它向应用提供 CUDA 驱动层与各性能库接口底层将 CUDA 编译产物PTX/SASS转换并在 AMD GPU 上执行目标是让未经修改的 CUDA 应用以接近原生的性能运行见 README.md。llama.cpp 是典型的 CUDA 推理应用其大矩阵乘部分高度依赖 cuBLAS因此能否正确编译、ZLUDA 能否映射 cuBLAS 到 AMD 的 rocBLAS是性能的关键。运行前提来自 quick_start.md 与 faq.md硬件ZLUDA 支持 AMD Radeon RX 5000 系列及更新的桌面/集成 GPUPolaris、Vega 等旧架构以及服务器级 GPU 不在支持范围faq.md Hardware 一节系统Windows 与 Linux 均可macOS 不受支持Windows 额外要求安装 AMD GPU 驱动并安装 HIP SDK原因见下文 Windows 平台必须安装 HIP SDK。核心构建命令官方推荐的 llama.cpp 编译方式官方文档 llama_cpp.md 给出的结论是llama.cpp 在为 CUDA 架构 86 编译并启用 cuBLAS 的情况下可以以原生速度运行。官方推荐的构建命令为cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES86 -DGGML_CUDA_FORCE_CUBLAStrue逐参数解读参数作用说明-DGGML_CUDAON开启 llama.cpp 的 ggml CUDA 后端使 ggml 以 CUDA kernel cuBLAS 路径执行张量运算-DCMAKE_CUDA_ARCHITECTURES86指定 nvcc 目标架构为 compute capability 8.6这是 ZLUDA 文档明确推荐的目标生成的 PTX/cubin 与 ZLUDA 暴露的算力等级匹配-DGGML_CUDA_FORCE_CUBLAStrue强制 ggml 的矩阵乘走 cuBLAS 路径文档明确指出关闭 cuBLAS 编译可能导致性能下降Compiling with cuBLAS disabled might lead to performance degradation两条补充约束同样来自官方文档务必遵守多架构编译是可以的前提是列表中包含 80、86、89 三者之一。例如-DCMAKE_CUDA_ARCHITECTURES80;86;89合法而全部写成75;90则不符合文档建议不要关闭 cuBLAS。ZLUDA 项目本身就内置了 cuBLAS → rocBLAS 的完整映射实现见下文关闭 cuBLAS 只会让 llama.cpp 退回纯 CUDA kernel 路径损失性能优势。为什么架构要选 80 / 86 / 89ZLUDA 报告的算力等级llama.cpp 这类 CUDA 应用在运行时通过驱动 API 查询 GPU 的 compute capability并据此加载匹配架构的内核cubin或 JIT 编译 PTX。因此编译目标架构必须落在 ZLUDA 驱动所报告的算力等级能够承接的范围内。从 ZLUDA 源码可以确认其默认报告行为zluda_common/src/constants.rs 中定义了默认算力等级为 (8, 5)并支持通过环境变量覆盖const COMPUTE_CAPABILITY_MAJOR: i32 8; const COMPUTE_CAPABILITY_MINOR: i32 5; pub fn compute_capability() - (i32, i32) { std::env::var(ZLUDA_CC) .or_else(|_| std::env::var(ZLUDA_SM)) .ok() .and_then(|s| { let mut parts s.split(.); let major parts.next()?.parse::i32().ok()?; let minor parts.next().unwrap_or(0).parse::i32().ok()?; Some((major, minor)) }) .unwrap_or((COMPUTE_CAPABILITY_MAJOR, COMPUTE_CAPABILITY_MINOR)) }也就是说ZLUDA 默认向应用报告 compute capability 8.5同时提供两个环境变量供高级场景调整ZLUDA_CC形如8.6直接指定报告的算力等级优先读取ZLUDA_SM形如86的等价覆盖方式。结合文档推荐编译目标 80/86/89 之一可以推断ZLUDA 的 PTX 编译路径覆盖 Ampere/Hopper 一代的 PTX 特性将 llama.cpp 编译到这些 Ampere/Hopper 架构之一可以确保其 PTX 落在 ZLUDA PTX 编译器支持的能力范围内从而获得文档所称的原生速度。如果你的应用实际表现与预期算力不符可以尝试设置ZLUDA_CC与编译目标保持一致后再测试此为源码能力支持的做法官方文档未针对 llama.cpp 给出具体取值建议请以实验为准。cuBLAS 在哪里被实现rocBLAS 映射与 Windows 的 HIP SDK 要求官方文档 llama.cpp 一节在 Windows 小节只说了一句You need to install HIP SDK to have access to rocBLAS。其背后的实现机制可以从仓库源码得到印证ZLUDA 的 cuBLAS shimcratezluda_blas内部并不直接依赖任何 NVIDIA 实现而是把 cuBLAS handle 包装成 rocBLAS handle并将 SGEMM、strided batched GEMM、数学模式、stream、workspace 等 cuBLAS 调用逐一转发给 rocBLAS。见 zluda_blas/src/impl.rsfn rocblas() - Resultstatic super::RocblasVtable, rocblas_error { static LOCK: OnceLockResultsuper::RocblasVtable, rocblas_error OnceLock::new(); let unwrapped: Resultsuper::RocblasVtable, rocblas_error ...以及 zluda_blas/src/impl.rs 中当找不到rocblas.dll时返回给应用的错误信息直接指回 HIP SDK 安装文档if cfg!(windows) status.is_err() status.err() rocblas().err().map(Into::into) { return crocblas.dll could not be found. Please install HIP SDK: ....as_ptr(); }这说明GGML_CUDA_FORCE_CUBLAStrue在 ZLUDA 下实际落到了 rocBLAS 上llama.cpp 的 GEMM 性能取决于本机 HIP SDK 中 rocBLAS 的质量与版本Windows 上rocblas.dll由 HIP SDK 提供不安装 HIP SDK 时 cuBLAS 初始化会失败llama.cpp 的 CUDA 路径将无法正常工作Linux 上通常由 ROCm 发行版提供等价库Windows 则必须按 hip_sdk.md 安装官方 HIP SDK 或 nightly 构建二选一nightly 构建还额外包含 MIOpen 等机器学习库文档中用cuda_check.exe的验证输出展示了各性能库到 HIP 库的映射如cublas13 : OK (...\rocblas.dll)、cudnn9 : OK (...\MIOpen.dll)。构建之后如何启动 llama.cpp 与验证环境llama.cpp 构建完成后按 ZLUDA 标准方式启动即可见 quick_start.mdWindows推荐 ZLUDA 启动器ZLUDA_DIRECTORY\zluda.exe -- llama-cli.exe APPLICATION_ARGUMENTS也可以把 ZLUDA 发行包或target\release中的全部文件含nvcuda.dll复制到应用加载 CUDA 的路径通常是可执行文件所在目录。Linux推荐LD_LIBRARY_PATHZLUDA_DIRECTORY:$LD_LIBRARY_PATH llama-cli APPLICATION_ARGUMENTS其中ZLUDA_DIRECTORY是包含 ZLUDA 提供的libcuda.so的目录下载预编译包时为zluda源码构建时为target/release。备选方式为LD_AUDITZLUDA_DIRECTORY/zluda_ld:$LD_AUDIT。环境自检ZLUDA 自带cuda_check工具用于测试所有性能库的加载与初始化见 cuda_check/src/main.rs在 Windows 上运行zluda.exe -- cuda_check.exe输出中每一行对应一个性能库nvcuda / nvml / cufft / cudnn / cublas / cublaslt / cusparse 等及其底层的 HIP SDK 库路径。注意 hip_sdk.md 中的三个已知问题括号中的路径不保证一定被使用若应用先于 ZLUDA 加载了同名库ZLUDA 会复用已加载的那个cuda_check.exe偶尔因 MIOpen 的 bug 挂起使用官方非 nightlyHIP SDK 时cudnn8/cudnn9会因 SDK 不含 MIOpen 而加载失败。llama.cpp 主要依赖 cuBLAS因此重点确认cublas*行为 OK 即可。出问题时的排查路径zluda_trace如果 llama.cpp 在 ZLUDA 下报错或结果异常按 troubleshooting.md 使用zluda_traceshim 记录完整的 CUDA 调用序列WindowsAMD GPUzluda.exe --zluda-trace -- llama-cli.exe APPLICATION_ARGUMENTS日志输出到%TEMP%\zluda下按可执行名建的目录。LinuxAMD GPUZLUDA_CUDA_LIBZLUDA_DIRECTORY/libcuda.so LD_LIBRARY_PATHZLUDA_DIRECTORY/trace/ \ ZLUDA_LOG_DIRLOG_DIRECTORY llama-cli APPLICATION_ARGUMENTStrace 目录中会包含log.txt逐条 CUDA 调用及返回值、每次运行的模块文件.ptx/.elf以及 ZLUDA PTX 编译器产生的错误日志如Unrecognized statement ...。对于 llama.cpp 这类大型 CUDA 应用未被识别的 PTX 指令类错误是最常见的失败原因compiler log 能直接指出具体是哪条指令不被当前 ZLUDA 版本支持便于向项目方报告。小结围绕 llama_cpp.md 这份简短但结论明确的官方文档可以归纳出在 ZLUDA 上跑 llama.cpp 的完整操作链路编译cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES86 -DGGML_CUDA_FORCE_CUBLAStrue多架构时必须含 80/86/89 之一且不要关闭 cuBLAS理解架构约束ZLUDA 默认报告 compute capability 8.5可用ZLUDA_CC/ZLUDA_SM覆盖zluda_common/src/constants.rsWindows 装 HIP SDKcuBLAS 底层映射到 rocBLASzluda_blas/src/impl.rsrocblas.dll由 HIP SDK 提供hip_sdk.md标准方式启动Windows 用zluda.exe --启动器Linux 用LD_LIBRARY_PATH指向libcuda.so所在目录quick_start.md验证与排障cuda_check.exe确认性能库全部 OK异常时用zluda_trace抓取调用日志与 PTX 编译错误troubleshooting.md。需要再次强调的前提ZLUDA 文档 quick_start.md 明确标注当前版本处于快速开发阶段will likely not work with your application yetllama.cpp 的原生速度结论基于文档发布时的版本不同预发布版本间行为可能有差异建议始终使用最新预发布构建并以cuda_check结果为准。【免费下载链接】ZLUDACUDA on non-NVIDIA GPUs项目地址: https://gitcode.com/GitHub_Trending/zl/ZLUDA创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
