llama.cpp b11064让Metal后端支持任意hc的dsv4_hc_pre算子
此前该算子把hc硬编码为 4，其他取值会被supports_op拒绝并回退到CPU；新版本改为以函数常量传参并按n_hc生成Metal管线变体。
AI解读：这条更新解决的是一个很具体的回退问题：llama.cpp的Metal后端里，dsv4_hc_pre算子过去把hc写死成 4，导致其他取值直接被supports_op拒绝，任务掉回CPU执行。对在Mac上跑Kimi-K3这类模型的人来说，这就是GPU明明在却帮不上忙。
现在n_hc改为通过函数常量FC_DSV4_HC传入，并针对每个n_hc生成Metal管线变体，两个pre kernel里都改成用直接加载做循环。提交还补了hc = 1、2、3、5、8、65 的后端算子测试，涵盖gated和非gated两种情况。
需要留意的边界是：来源只说明支持范围扩大，没有给出任何性能对比数据，所以“从CPU回退切到Metal会快多少”目前没有可引用的数字。受影响的主要是在Apple Silicon上用llama.cpp跑跨层残差栈随层数增长模型的人。
如果你只跑hc = 4 的模型，这次改动对你的日常使用基本无感，但升到b11064不会有副作用；如果你正好卡在回退CPU的路径上，这个版本的测试范围本身就是一个可验证的信号。
llama.cpp发布b11064版本，其中一项改动是让Metal后端支持dsv4_hc_pre算子的任意hc取值。
根据提交说明，dsv4_hc_pre的kernel此前通过constexpr把hc硬编码为 4，并与simd_shuffle一起使用，因此任何其他hc取值都会被supports_op拒绝，算子回退到CPU执行。
提交指出，Kimi-K3使用dsv4_hc_pre时，hc等于跨层残差栈中banked checkpoints的数量，而该数量随层索引增长。
修复方式是把n_hc作为函数常量FC_DSV4_HC传入，并生成针对每个n_hc的Metal管线变体，同时在两个pre kernel中循环处理它，改为直接加载。
提交还新增了test-backend-ops用例，覆盖hc = 1、2、3、5、8 和 65，包含gated与非gated两种情况。
该提交标注Assisted-by: pi:llama.cpp/Qwen3.8-27B。