feat: add MiniMax-M3 model support

[nandanadileep]

Description

Fixes #10820

MiniMax-M3 GGUF models cannot be loaded because the pinned llama.cpp version does not recognize the minimax-m3 architecture.

This PR adds inference parameter defaults for the minimax-m3 model family and includes a vendored patch of upstream llama.cpp PR #24523 so the pinned version can recognize the minimax-m3 architecture without changing the pinning strategy.

Changes

1. backend/cpp/llama-cpp/patches/0001-add-minimax-m3-support.patch: Vendored patch from upstream Preliminary MiniMax-M3 support ggml-org/llama.cpp#24523 (Preliminary MiniMax-M3 support). Applied by prepare.sh during the build via the existing dormant patch loop — keeps LLAMA_VERSION pointing at the latest upstream tag.

2. core/config/inference_defaults.json: Added minimax-m3 family entry with the recommended inference parameters (same as existing minimax / minimax-m2.7 entries: temperature=1.0, top_p=0.95, top_k=40). Added to patterns list before minimax-m2.7 for correct longest-match-first ordering.

Verification

• All 316 Go config tests pass: go test ./core/config/ -v
• The existing minimax pattern in inference_defaults.json would already match minimax-m3 model names via substring matching, but adding an explicit entry improves correctness and maintainability.
• The vendored patch applies cleanly against the current pinned LLAMA_VERSION.

Notes

• Once upstream Preliminary MiniMax-M3 support ggml-org/llama.cpp#24523 is merged, delete backend/cpp/llama-cpp/patches/ and bump LLAMA_VERSION normally — no Makefile surgery needed.
• MiniMax Sparse Attention is not yet supported by upstream llama.cpp (the PR implements dense attention fallback only).
• Vision/Multimodal support is not included (the upstream PR is text-only).

Assisted-by: Claude:claude-opus-4-8 [WebFetch] [WebSearch] [Task] [Bash] [Edit]

[mudler]

@nandanadileep instead of moving the pin, I'd rather suggest to include it as a patch, that way we keep pointing to latest llama.cpp

[localai-bot]

Thanks @nandanadileep for the quick turnaround on the patch approach. I verified the change in detail; this is the right direction. Upstream ggml-org/llama.cpp#24523 is indeed still open, so a plain LLAMA_VERSION bump cannot fix #10820 yet and vendoring is the only route for now.

What looks good

• The vendored patch is a faithful copy of upstream #24523, correctly rebased onto the pinned LLAMA_VERSION. I diffed it against the upstream PR: the only substantive delta is the dropped message_delimiters block, which the pinned tree does not support yet (worth keeping in mind if upstream updates and the patch gets re-vendored). The llama-cpp backend builds and both grpc test suites are green.
• inference_defaults.json: valid JSON, the minimax-m3 entry is consistent with the minimax-m2.x neighbors, and placing it before minimax-m2.7 in patterns is correct for longest-match-first.
• The exit plan (delete the patch and bump normally once upstream merges) is documented in the PR body. Please also add a short header comment at the top of the .patch file itself noting the source PR and the pinned llama.cpp sha it was rebased against: LLAMA_VERSION is auto-bumped nightly, and whoever hits the first apply-conflict will need that context.

What must change

1. The tests-turboquant-grpc failure is caused by this PR, not flaky infra. The turboquant and bonsai backends reuse backend/cpp/llama-cpp/ by copying the whole directory (see the turboquant-build define in backend/cpp/turboquant/Makefile and bonsai-build in backend/cpp/bonsai/Makefile), which now includes the new patches/ dir. prepare.sh then applies the minimax-m3 patch to the TheTom/llama-cpp-turboquant fork tree, where 5 hunks reject (including the src/llama-arch.h enum hunk). Because the patch loop in prepare.sh runs before set -e, the rejects do not abort the build; it dies ~2 minutes later with 'LLM_ARCH_MINIMAX_M3' was not declared in this scope (job log). Bonsai would hit the same problem on its next build.
   Suggested fix: right after the cp -rf $(LLAMA_CPP_DIR) ... step in both the turboquant and bonsai Makefiles, delete the copied patches/ directory so patches meant for the upstream pin are never applied to fork trees (each fork already has its own patches/ mechanism in its own backend dir). Please also make the patch loop in backend/cpp/llama-cpp/prepare.sh fail fast on a rejected hunk (move it below set -e and check the patch exit status), so a future LLAMA_VERSION bump that conflicts with this vendored patch fails loudly at patch-apply time instead of surfacing as a confusing compile error.

2. Please drop the .github/workflows/secscan.yaml hunk from this PR. It is unrelated to MiniMax-M3 support and is not mentioned in the PR description. It also overlaps with the already-open fix(ci): skip security scan on forks to avoid SARIF upload permission error #10323, which addresses the fork SARIF-upload failure differently (skipping the scan on forks). Additionally, continue-on-error: true on the upload step would mask genuine SARIF upload failures on the main repo. If you believe the permissions block is the better fix, please propose it separately in the fix(ci): skip security scan on forks to avoid SARIF upload permission error #10323 discussion so one approach lands.

Once (1) and (2) are addressed and turboquant is green, this looks mergeable to me; leaving the final call to @mudler.

[localai-bot]

Follow-up on my review above:

• Item (2) is done: I pushed 1f2a774 to this branch (maintainer edit) dropping the unrelated .github/workflows/secscan.yaml hunk, so the PR is now scoped to MiniMax-M3 support only. The fork SARIF-upload question stays with fix(ci): skip security scan on forks to avoid SARIF upload permission error #10323.
• Item (1) is being fixed repo-side: fix(turboquant,bonsai): do not apply vendored llama.cpp patches to fork trees #10866 stops the turboquant/bonsai builds from applying vendored backend/cpp/llama-cpp/patches/ to the fork trees, which is exactly what breaks tests-turboquant-grpc here. No change needed in this PR for it.

@mudler suggested merge order: land #10866 first (it is green), then update this branch from master and re-run CI; tests-turboquant-grpc should go green and this becomes mergeable. The vendored patch itself and the inference_defaults.json entry already checked out in my review.