llama.cpp b11292发布：CPU后端接受mul_mat的BF16 src1，Vulkan收紧支持条件
llama.cpp新构建版本b11292的更新说明显示，CPU后端开始接受mul_mat中src1为BF16的输入组合，Vulkan后端则拒绝该组合（除非src0也是BF16），并补充了conv_1d_dw与mul_mat测试。
AI解读：这条更新解决的是一个具体的“没人比”问题：ggml_conv_1d_dw在kernel为BF16时会用F32构建im2col，再调用ggml_mul_mat(im2col, kernel)，于是出现src0为F32、src1为BF16的组合。CPU后端原本拒绝这种组合，结果它在所有后端都被报为不支持，从未真正参与比较。现在把BF16在F32工作缓冲区中扩宽，与既有的把F32打包进vec_dot_type放在一起处理。
这个改动并不是一个新算子，而是让CPU路径补上Metal mat vec内核已有的算术方式：两个操作数都提升为float、在float中累加，因此两者结果完全一致而非近似一致。对跑BF16卷积类模型的人来说，这意味着原先被划为“不支持”的组合现在能在CPU上执行，而不是被调度器绕过。
Vulkan一侧则是反向操作：supports_op原先只针对非连续张量检查src1类型，导致连续的BF16 src1被接受、随后在流水线查找时触发断言。现在只有BF16 x BF16乘法的src1路径被保留，其余src0类型都报告为不支持，调度器会把它留在CPU上。
测试覆盖也一并补上：新增覆盖F32、F16和BF16 kernel的conv_1d_dw测试，以及三个src1为BF16的mul_mat用例。说明里提到，conv_1d_dw测试中的BF16 kernel用例依赖Metal后端的f32 x bf16 mat vec变体，而该变体是另外单独合入的。
发布页同时列出了各平台构建产物，包括macOS、iOS、Linux、Android、Windows以及openEuler相关构建和UI包；摘要未提供性能数据或具体模型适用范围的验证结果。
llama.cpp发布构建版本b11292，更新说明中记录了两项后端改动：CPU后端接受mul_mat中src1为BF16的输入，Vulkan后端则拒绝该组合，除非src0也是BF16。
CPU改动的背景是ggml_conv_1d_dw在kernel为BF16时用F32构建im2col，然后调用ggml_mul_mat(im2col, kernel)，使src0为F32、src1为BF16。CPU后端原本拒绝这一组合，因此该组合在所有后端都被报告为不支持，从未参与比较。
改动方式是在把F32打包进vec_dot_type的既有逻辑旁边，将BF16扩宽进F32工作缓冲区。说明称这是Metal mat vec内核已经在用的算术：两个操作数都提升为float并在float中累加，因此两者结果完全一致，而不是近似一致。
Vulkan一侧的问题是supports_op只对非连续张量检查src1类型，导致连续的BF16 src1被接受，随后在流水线查找时触发断言。现在只有BF16 x BF16乘法的src1路径保留，其他所有src0类型都把该算子报告为不支持，调度器会将其保留在CPU上。
测试方面，新增覆盖F32、F16、BF16 kernel的conv_1d_dw测试，并增加三个src1为BF16的mul_mat用例。说明提到，conv_1d_dw测试的BF16 kernel用例需要Metal后端的f32 x bf16 mat vec变体，该变体另行合入。
发布页列出macOS、iOS、Linux、Android、Windows、openEuler等多平台构建产物与UI包；macOS Apple Silicon的KleidiAI启用构建标记为DISABLED，openEuler相关构建同样标记为DISABLED。