llama.cpp b11374更新OpenVINO后端至 2026.4.1，MoE预填充提速约 24 倍
llama.cpp发布b11374版本，将ggml-openvino后端升级到OpenVINO 2026.4.1并更新GPU驱动至 26.35.39758.10，同时引入MoE融合、设备枚举与stateful执行等多项改动；发布说明给出gemma-4-26B-A4B在Arc B390上的基准数据。
AI解读：llama.cpp b11374的主要变更是把ggml-openvino后端升级到OpenVINO 2026.4.1，并将GPU驱动更新到 26.35.39758.10，同时放出对应Windows、Ubuntu x64的OpenVINO二进制包。
发布说明给出的基准显示，gemma-4-26B-A4B在Arc B390、GGML_OPENVINO_REQUANT_KQUANT=q4_asym64_all、llama-bench -p 512 -n 128 -r 2条件下，预填充pp512从 66.16 t/s提升到 1608.73 t/s，解码tg128从 25.94 t/s到 26.46 t/s，对比对象是GGML_OPENVINO_MOE_OP=0 的未融合基线；12 个chunk上的困惑度未变。
这次MoE融合面向gate与up投影合并为单权重（fused gate_up）的模型，例如gemma-4；对gate/up分离权重、未启用该重量化选项、以及在CPU上运行的场景不产生效果，属于发布说明中明确写出的适用边界。
llama.cpp发布b11374版本，核心改动是将ggml-openvino后端更新至OpenVINO 2026.4.1，并更新GPU驱动到 26.35.39758.10（PR #29852）。发布页同时提供Windows x64、Ubuntu x64的OpenVINO 2026.4.1预编译包。
发布说明称，该PR包含针对Qwen3.5 MoE的性能优化、算子扩展、设备枚举与内存报告改进，以及图缓存、stateful执行和MoE融合等一系列修复。
MoE融合与性能数据
发布说明中，新增FuseMoeCompressedFusedGateUp用于匹配gate与up投影合并为单个专家权重的模型结构（如gemma-4）。说明指出，原有FuseMoeCompressed只匹配gate和up为独立GatherMatmul算子的模型，因此gemma-4的MoE块此前未融合，专家GEMM以逐token GEMV方式执行。
来源给出的基准为gemma-4-26B-A4B在Arc B390、GGML_OPENVINO_REQUANT_KQUANT=q4_asym64_all、llama-bench -p 512 -n 128 -r 2，对比基线为GGML_OPENVINO_MOE_OP=0：pp512由 66.16 t/s升至 1608.73 t/s，tg128由 25.94 t/s变为 26.46 t/s；12 个chunk的困惑度在未融合（1451.3 ± 177.9）与融合（1427.6 ± 175.1）之间未出现可辨识差异。
- 融合仅在有该重量化选项时生效；gate/up权重分离的模型以及CPU路径无此效果。
- test-backend-ops -b OPENVINO0结果未变：仍有两条MUL_MAT_ID m_v用例失败，与未修改的基线相同。
stateful执行下MoE的rank-3修复与已知限制
发布说明描述，stateful执行会去掉前导的size-1 batch维度，使OpenVINO张量为rank 3，而GgmlOvDecoder::get_shape/get_stride仍按GGML_MAX_DIMS=4 反向报告，导致部分MoE算子取错轴。修复覆盖argsort.cpp、add.cpp、get_rows.cpp、mul_mat_id.cpp、view.cpp与utils.cpp等处的轴处理；在GGML_OPENVINO_STATEFUL_EXECUTION=1 下，MoE模型此前会在建图阶段触发is_axis_valid校验失败而中止。
作者称，改动均按实际rank门控，stateless路径保持原有行为；在OV-CPU上与未修改基线对比贪心输出，dense gemma-4-E2B、granite-1b-a400m和gemma-4-26B-A4B结果一致，其中granite-1b-a400m在修改前会以该错误中止，修改后可生成且与stateless逐字节一致。
来源同时列出限制：FuseMoeCompressedFusedGateUp不匹配rank-3图，因此GGML_OPENVINO_STATEFUL_EXECUTION=1 运行MoE模型会失去预填充融合。其给出的gemma-4-26B-A4B数据为：未融合pp512 66.16、tg128 25.94；融合后stateless（默认）pp512 1608.73、tg128 26.46；融合后stateful pp512 66.18、tg128 29.91。stateful为可选项、默认关闭。
发布说明还提示，gemma-4-26B-A4B在OV上会很快进入退化重复，stateless与stateful都会如此，两种模式在该区域内产生分歧，因此不适合作为逐token对拍的正确性载体。
设备枚举、内存报告与其他改动
设备列表方面，只有GGML_OPENVINO_DEVICE选中的设备报告为GPU，其余OpenVINO设备报告为IGPU以避免llama.cpp向其卸载；初始化未选中的设备会记录警告。不可用的GGML_OPENVINO_DEVICE现在报错并列出可用设备，而不再静默回退到CPU。--list-devices、启动日志和后端测试会显示所选GGML_OPENVINO_DEVICE与当前活跃设备，并注明选择由GGML_OPENVINO_DEVICE控制，而非 -dev。
内存报告方面，iGPU/NPU空闲内存会以系统可用内存为上限，插件缺少内存属性时回退到系统内存而非 0/0，GPU用量忽略主机USM分配。此外，USM入口点改为在所选设备平台的init() 中查询，避免首个平台来自其他厂商时返回空指针导致GPU缓冲区读写与memset报错。
其他修复包括：图缓存键改用node_idx、src_idx与节点类型；GPU远程上下文创建失败时直接中止，因为远程缓冲与张量路径没有主机回退；HARDSIGMOID与EXPM1改为按f32计算后转换（NPU除外）；支持常见MTMD算子、更广的卷积融合并拒绝kernel size 0；为重塑视图分配独立的ov::Tensor并跳过空视图（Qwen3.5循环缓存结尾可能出现size 0视图）；llama传入不同计算图时重新绑定缓存的decoder，以修复llama-server按上下文检查点分块提示词时SWA与循环模型丢失大部分提示词的问题。