llama.cpp b11203为CUDA FWHT加入F16输入支持
llama.cpp发布b11203，CUDA后端的快速沃尔什-哈达玛变换（FWHT）现在可直接读取F16源，不再需要先转成F32；F32路径保持不变。
AI解读：llama.cpp的CUDA后端过去只接受F32输入做FWHT，F16数据得先转一份，多一步拷贝。b11203把源类型改成模板参数，内核可以直接读F16，省掉这次转换。
这个改动只放行一种组合：src1是F16、src0是F32、且带Hadamard提示。其他F16 src1配非F16 src0的情况仍然被拒绝，所以不是全面放开混合精度。
开发者在A10上跑test-backend-ops，MUL_MAT 1297/1297全过，其中Hadamard用例 24 个（18 个原有F32，6 个新增F16）。如果你的CUDA推理路径正好走FWHT，这个版本才与你有直接关系。
llama.cpp发布b11203，CUDA后端的FWHT（快速沃尔什-哈达玛变换）新增F16输入支持（PR #29096）。此前CUDA FWHT只接受F32输入，F16源需要先转换成一份F32副本；改动把源类型变成模板参数，内核可直接读取F16源。F32路径保持不变。
支持范围有明确边界：supports_op允许在Hadamard提示下使用F16 src1配F32 src0；其他任何F16 src1配非F16 src0的组合仍被拒绝。
改动还统一了判定逻辑：ggml_cuda_op_mul_mat_use_fwht现在是supports_op和分派调用共用的唯一谓词，除类型与Hadamard提示条件外，还检查连续性以及src1与dst形状相同。作者指出，没有共享谓词时，supports_op可能放行某个op，而ggml_cuda_op_fwht只在无条件的同形状断言触发后才拒绝它；这个缺口早于本次改动（同样存在于既有F32路径），但本次PR触及supports_op，因此在此一并关闭。
第二笔提交在FWHT加载中使用ggml_cuda_cast，并删除相关注释。
验证方面，在A10（lambdalabs）上运行test-backend-ops：MUL_MAT 1297/1297通过，包括全部 24 个Hadamard用例（18 个既有F32，6 个新增F16）。