llama.cpp b11331发布：CUDA路径为NVFP4处理计算类型
该版本合并PR #29173，在cuBLAS路径上为NVFP4指定计算类型，量化模型在硬件允许时改用BF16计算，NVFP4累加精度也设为BF16。
AI解读：llama.cpp的b11331版本合并了PR #29173，改动集中在CUDA后端，让NVFP4这种 4 位浮点格式在走cuBLAS路径时正确指定计算类型。NVFP4需要至少BF16的数值范围，所以这次把累加精度设成了BF16。
对本地跑量化模型的人来说，变化是：如果硬件支持，量化模型的计算类型会改用BF16，并且per-expert matmul的op_params会被保留。这属于后端精度和兼容性修补，不改变模型格式，也不承诺速度提升。
发布包覆盖macOS、Linux、Windows、Android以及CUDA 12.8/13.4、ROCm 10.0、Vulkan、SYCL、OpenVINO等多种后端构建。普通用户没有立即行动的必要，除非你正在CUDA上用NVFP4模型并遇到精度或类型报错。
判断依据是GitHub发布页的提交信息，没有附带性能基准或测试数据，所以无法确认这一改动带来多少实际收益，适用条件也限于NVIDIA硬件和cuBLAS路径。
llama.cpp发布b11331版本，合并PR #29173，标题为“CUDA: Handle compute type for NVFP4 on cublass path”。
PR #29173 改了什么
根据发布页的提交信息，该PR在cuBLAS路径上为NVFP4处理计算类型。提交说明包括：在硬件允许时，量化模型使用BF16计算类型；NVFP4的累加精度设为BF16，因为它需要至少BF16的数值范围。
提交信息还提到保留per-expert matmul的op_params。该PR由ynankani签署，Johannes Gäßler参与共同编写并更新了ggml/src/ggml-cuda/ggml-cuda.cu。
- 在cuBLAS路径上为NVFP4处理计算类型
- 硬件允许时，量化模型使用BF16计算类型
- NVFP4累加精度设为BF16，因为至少需要BF16范围
- 保留per-expert matmul的op_params
发布包与可用平台
该版本按平台提供预编译包，包括macOS Apple Silicon（arm64）、macOS Intel（x64）、iOS XCFramework；Linux下的Ubuntu x64/arm64/s390x CPU、Vulkan、CUDA 12（12.8）与CUDA 13（13.4）、ROCm 10.0、OpenVINO 2026.4、SYCL FP32/FP16，以及Snapdragon的CPU、Adreno GPU、Hexagon NPU构建；Windows的CPU x64/arm64、OpenCL Adreno arm64、CUDA 12.4/13.4、Vulkan、OpenVINO 2026.4、SYCL、ROCm 10.0；Android arm64与Snapdragon构建；另有UI包。
- macOS Apple Silicon arm64与macOS Intel x64
- iOS XCFramework
- Ubuntu x64/arm64/s390x CPU、Vulkan、CUDA 12.8、CUDA 13.4、ROCm 10.0、OpenVINO 2026.4、SYCL FP32/FP16
- Windows x64/arm64 CPU、OpenCL Adreno arm64、CUDA 12.4/13.4、Vulkan、OpenVINO 2026.4、SYCL、ROCm 10.0
- Android arm64与Snapdragon构建
发布页标注的限制
发布页列出若干DISABLED项：macOS Apple Silicon的KleidiAI构建被禁用，链接指向PR #23780；openEuler构建整体被禁用，链接指向PR #23705，原本包含openEuler x86（310p）、x86（910b，ACL Graph）、aarch64（310p）、aarch64（910b，ACL Graph）。