llama.cpp b12191让部分MoE缓存未命中专家改在CPU计算，并新增调参脚本
该版本引入 --moe-cache-cpu-share参数，按比例把MoE缓存未命中的专家交给主机CPU计算，不再上传到设备；同时新增moe-cache-tune.py，用两档缓存大小和三档CPU份额实测后预测推荐的 --moe-cache-mib与 --moe-cache-cpu-share。
AI解读：llama.cpp发布b12191版本，核心变更是MoE缓存允许把一部分未命中的专家放到CPU上、用主机端专家权重计算，由参数 --moe-cache-cpu-share F控制比例F。
实现上，计算图会构建两次专家FFN：设备端用缓存槽位计算，留待CPU的未命中读取零槽位；CPU端用主机专家计算，设备端已算的专家id记为 -1，两者在down bias之前相加。
为配合该机制，ggml-cpu的MUL_MAT_ID会跳过负id并写入零行；调度器的拷贝回调覆盖一个split的全部输入，无事件时在host sync之前调用；CPU部分的槽位查找与所选专家一起读取，因此不必等待设备，结果异步拷回。
来源说明mul_mat_id不支持同一token重复选择同一个专家，因此每个token使用各自不同的零槽位；LLAMA_MOE_CACHE_TRACE可记录每次查找选中的专家，供缓存模拟器使用。
新增scripts/moe-cache-tune.py：它包装一条llama-server命令，在两种缓存大小和三种CPU份额下启动服务，拟合机器的上传速度与CPU速度，再用缓存逻辑副本重放路由，预测其他缓存大小和份额，输出推荐的 --moe-cache-mib与 --moe-cache-cpu-share；docs/moe-cache.md记录了这些参数和脚本。
另一项行为调整：当 --moe-cache-cpu-share设得很高时，上传的未命中很少，空缓存填充慢，会有超出需要的未命中被分到CPU；现在只有当一个缓存组的所有槽位都持有专家后，CPU份额才生效，调参脚本按同一规则重放。
llama.cpp发布b12191，合并PR #30966：MoE缓存新增“未命中专家在CPU上计算”的选项，并附带调参脚本。
按发布说明，--moe-cache-cpu-share F会让比例为F的MoE缓存未命中改用主机端专家在CPU上计算，而不再上传到设备。
CPU份额如何参与专家计算
发布说明描述，计算图会构建两次专家FFN：设备端从缓存槽位计算，留给CPU的未命中读取零槽位；CPU端从主机专家计算，设备端已算的专家id为 -1。两部分结果在down bias之前相加。
配套改动包括：ggml-cpu的MUL_MAT_ID跳过负id并写零行；调度器对一个split的所有输入调用拷贝回调，无事件时在host sync之前调用；CPU部分的槽位查找与所选专家一起读取，使其不等待设备，结果异步拷回。
- 每个token使用各自不同的零槽位，因为mul_mat_id不支持一个token两次选择同一专家
- LLAMA_MOE_CACHE_TRACE记录每次查找选中的专家，供缓存模拟器使用
- 后续改动把CPU部分的后端逻辑移出计算图：CPU部分读取主机专家，调度器将其放上CPU而无需set_tensor_backend；有CPU部分的计算图自行查找槽位映射
缓存填充规则的一处修正
发布说明称，当 --moe-cache-cpu-share设得很高时，上传的未命中很少，空缓存会填充缓慢，导致比实际需要更多的未命中被分到CPU。现在的规则是：只有当一个缓存组的所有槽位都持有专家之后，CPU份额才开始生效；moe-cache-tune.py重放同一规则。
调参脚本moe-cache-tune.py
脚本包装一条llama-server命令，在两种缓存大小和三种CPU份额下启动服务，拟合机器的上传速度与CPU速度，再通过缓存逻辑的副本重放运行中的路由，预测其他缓存大小和份额下的表现。
脚本最终打印推荐的 --moe-cache-mib和 --moe-cache-cpu-share。docs/moe-cache.md记录了MoE缓存参数与该脚本。发布说明还提到将am17an加为MoE缓存的codeowner。