ggml-openvino: fix Gemma-4 26B MoE crashes on the GPU device

Author: cavusmustafa

ggml/src/ggml-openvino/ggml-openvino.cpp

@@ -961,13 +961,24 @@ static bool mul_mat_id_requires_large_tmp(const ggml_tensor * op) {
     }
     // On the full-MoE GPU path the real gemma4 expert matmuls (ffn_moe_gate_up /
     // ffn_moe_down) legitimately exceed this cap and are handled correctly, so
-    // exempt only those named ops. Other MUL_MAT_ID ops (e.g. the large-n
-    // MUL_MAT_ID_FUSION test cases) still hit the cap and stay on CPU, since the
-    // GPU translation produces wrong results for those oversized temporaries.
-    if (gpu_full_moe_enabled() &&
-        (strncmp(op->name, "ffn_moe_gate_up", sizeof("ffn_moe_gate_up") - 1) == 0 ||
-         strncmp(op->name, "ffn_moe_down", sizeof("ffn_moe_down") - 1) == 0)) {
-        return false;
+    // exempt those named ops. The scheduler also queries these same expert matmuls
+    // during its reserve/measurement pass with an EMPTY name (and a worst-case
+    // full-batch ids->ne[1] that blows past the tmp cap); if we send them to CPU there
+    // the placement can stick for the real graph, and the expert matmul then runs on
+    // CPU reading OpenVINO-produced routing ids across the split boundary — which are
+    // garbage (crash in ggml-cpu mul_mat_id: "i02 >= 0 && i02 < n_as"). So for the
+    // unnamed reserve-pass query, fall back to a STRUCTURAL match: a genuine gemma4
+    // expert matmul routes over a 3D quantized expert-weight tensor
+    // (as->ne[2] == n_expert > 1). Real graph ops always have a name, so the named
+    // MUL_MAT_ID_FUSION test cases (op named "out") are unaffected and still hit the
+    // cap / stay on CPU as before.
+    if (gpu_full_moe_enabled()) {
+        const bool name_match = strncmp(op->name, "ffn_moe_gate_up", sizeof("ffn_moe_gate_up") - 1) == 0 ||
+                                strncmp(op->name, "ffn_moe_down", sizeof("ffn_moe_down") - 1) == 0;
+        const bool unnamed_expert_matmul = op->name[0] == '\0' && as->ne[2] > 1 && ggml_is_quantized(as->type);
+        if (name_match || unnamed_expert_matmul) {
+            return false;
+        }
     }
 
     size_t tmp_elems = 1;

ggml/src/ggml-openvino/openvino/utils.cpp

@@ -302,6 +302,17 @@ ov::Output<ov::Node> process_view_input_new(const NodeContext & context, int inp
     // re-slice/flatten the already-resolved view (a Reshape to the full flattened
     // n_expert_used*n_embd tail, which then conflicts with the single-plane input). Treat a
     // dynamic-vs-dynamic axis as matching so the already-resolved view is reused as-is.
+    //
+    // A third case matters for split-model MoE fragments: translate_view resolves the
+    // expert-plane view against the fragment's INPUT parameter. When the graph is split
+    // the token axis of that parameter may already be concrete (static n_tokens) even
+    // though get_view_input_ov_shape() still reports it as dynamic (-1). The resolved
+    // view is then static [1,1,n_tokens,n_embd] while `expected` is [1,1,?,n_embd].
+    // An "expected dynamic, actual static" axis is a valid concretization of the SAME
+    // resolved view, so treat it as matching too. Falling through to process_single_view
+    // here would re-slice/re-flatten the already-resolved single-plane view against the
+    // recorded (multi-plane) source strides and emit a constant-target Reshape whose baked
+    // dims no longer divide the concretized input -> "dimensions do not evenly divide".
     auto expected_ov_shape = context.get_view_input_ov_shape(input_index, 0);
     auto actual_shape = input.get_partial_shape();
     if (expected_ov_shape.rank().is_static() && actual_shape.rank().is_static() &&
@@ -311,7 +322,10 @@ ov::Output<ov::Node> process_view_input_new(const NodeContext & context, int inp
             const bool both_dynamic = expected_ov_shape[i].is_dynamic() && actual_shape[i].is_dynamic();
             const bool both_static_equal = expected_ov_shape[i].is_static() && actual_shape[i].is_static() &&
                                            expected_ov_shape[i] == actual_shape[i];
-            if (!both_dynamic && !both_static_equal) {
+            // expected dynamic, actual static: the resolved view already carries the
+            // concrete size for this fragment; reuse it rather than re-materializing.
+            const bool expected_dyn_actual_static = expected_ov_shape[i].is_dynamic() && actual_shape[i].is_static();
+            if (!both_dynamic && !both_static_equal && !expected_dyn_actual_static) {
                 shapes_match = false;
                 break;
             }