Llama.cpp b11026: When the qwen35moe Tensor-Skip Fix Warrants an Upgrade Test

If you maintain a local or self-hosted llama.cpp service, b11026 warrants a targeted upgrade test when your configuration uses qwen35moe with fused MTP tensors that are not loaded. That is the condition named by the release, not a general recommendation to upgrade every inference server.

The b11026 release page, captured on September 18, labels the build Pre-release and links commit b49650adb31f2e49a0d76113aeb1792134fd8413. Its change note is unusually specific:

model : skip gate_up_exps if TENSOR_SKIP is set

required for qwen35moe if MTP tensors are fused but not loaded

The note links PR #29014. The recommendation here rests on the release note, not on an inspection of that PR’s implementation or tests.

Check applicability before scheduling the upgrade

There are three useful branches for this decision:

Your configuration Suggested next step
qwen35moe, with fused MTP tensors present but not loaded Prioritize a controlled b11026 model-load and inference test.
qwen35moe, but the tensor/loading condition is unknown Establish the model artifact and actual loading configuration first. The identifier alone is not enough.
A different model path, or a configuration that does not match that condition Do not use this particular note as the reason to change the deployment. Evaluate other upgrade reasons separately.

Keep qwen35moe as the source’s identifier: the note does not map it to a marketed model size or hosted API offering. It also does not name an error message or an affected-version range. An unexplained loading failure, by itself, is not proof that this fix applies.

Make the test answer a loading question

For a matching setup, I would use the following comparison. This is a proposed validation procedure, not a reported benchmark or upstream test result.

  1. Record the existing runtime revision, exact model artifact, loading settings, hardware and backend. Preserve a way to return to that build and configuration.
  2. Run the existing build in a test environment and retain the load logs and the outcome of a small, fixed set of inference requests.
  3. Repeat with b11026, keeping the model artifact, loading settings, hardware, backend and inference inputs unchanged. Check whether loading completes and whether the same requests complete with usable outputs.
  4. Keep load and inference outcomes separate in the comparison. If loading succeeds but inference fails, do not treat the upgrade as validated. If both builds work, do not manufacture a benefit that the comparison did not demonstrate.

A successful comparison would support using that build in the tested configuration. It would not isolate this one change from every other difference between the builds, or establish that other model artifacts and backends behave identically. Production adoption still needs your normal regression checks; the immediate decision is whether this narrowly applicable prerelease deserves a test.

What this release does not establish

The page lists platform and backend downloads, but download availability is not evidence that this fix was validated on all those environments. It supplies no throughput, latency, memory, output-quality or production-reliability measurements. Skipping gate_up_exps when TENSOR_SKIP is set should therefore not be retold as a general speedup or quality improvement.

The useful takeaway is conditional: match the fused-but-not-loaded MTP condition first, then validate loading and inference on the exact setup you intend to serve. Without that match, this release note supplies no specific reason to disturb an unrelated deployment.

The test needs a definition of “usable outputs” before either build runs. Otherwise, a loading failure can disappear while the inference check quietly becomes “it returned some text.”

For the matching qwen35moe setup, I would turn the fixed requests into a small acceptance set: a factual prompt with a known answer, a constraint-following prompt with an explicit pass condition, and a representative application request scored against a short rubric. Record the prompt formatting and generation settings alongside the runtime configuration. These are proposed evaluation controls, not upstream tests or claims about this model’s capabilities.

Keep completion and answer correctness as separate columns. A completed request with a wrong answer passes the execution check but fails the relevant content check. Conversely, different wording need not mean a regression if both responses satisfy the same predeclared criteria; byte-for-byte output identity should not substitute for those criteria.

The b11026 note supports the fused-but-not-loaded MTP condition, not an expected answer-quality change. This small acceptance set would help decide whether a newly loadable configuration merits broader evaluation. It would not establish a quality gain, and if the old build cannot load, there is no old-build answer baseline to compare against.