Prebuilt: repin on the rebased Kimi-K3 text PR and the fixed Inkling head

[danielhanchen]

The nightly prebuilt has been red since 2026-07-31. This repins scripts/unsloth/pr-set.json so it resolves, merges and builds again.

What broke

Resolve tag refused and skipped every build job:

refusing ggml-org/llama.cpp#26185: pinned commit cf67f0d2... is not a commit of
that PR (wrong paste, or force-pushed away)

pwilkin force-pushed kimi-k3-text at 2026-07-31T21:16:01Z, eleven minutes before that night's schedule. The pin named cf67f0d2, a merge commit the rebase wrote out of the branch, so the membership gate fired. Runs 30666643530 and 30718507279 both died there. The gate did its job.

The set

PR	pin	change
ggml-org#24423 DiffusionGemma	c3fb9724	unchanged
ggml-org#25731 Inkling	02142bbc	was d69b7e60
#48 Kimi-K3 fixes + MoonViT-3d	daef2b3e	replaces #44
ggml-org#26185 Kimi-K3 text	04d6828b	was cf67f0d2

Inkling was pinned to d69b7e60, the commit three separate reporters got garbage output from: CPU, Mac, and ROCm/gfx1151 with -fa on (" the of France is the of France is"). ggml-org#25731 fixed those in 02142bbc. The nightly was shipping the broken one, which is the more urgent half of this change.

Kimi-K3 moves from #44 to #48. #44 was the everything-merged branch; #48 is the stacked pair of commits on top of ggml-org#26185, which is what we actually want to upstream.

Why ggml-org#26185 needed #48 to change

After the rebase, ggml-org#26185 does not merge onto current master, and Kimi-K3 and Inkling register in the same arch, model and mtmd tables. They cannot go in as two independent heads, so one has to know about the other.

kimi-k3-text-base (the base branch of #48) was advanced to the rebased ggml-org#26185 head, then merged with b10223 and with Inkling 02142bbc. Four collisions, all additive, both arches belonging in every group:

file	collision
src/llama-arch.cpp	LLM_ARCH_KIMI_K3 vs LLM_ARCH_INKLING in one fallthrough
src/llama-model.cpp	same, in the LLAMA_ROPE_TYPE_NONE group
tests/test-llama-archs.cpp	master's MINIMAX_M3 vs KIMI_K3
tools/mtmd/CMakeLists.txt, models/models.h	source list and graph registry

The two Kimi-K3 commits were rebased on top, so #48 is still a 10-file stacked diff against its base rather than a merge blob.

ggml-org#26185 stays listed, and stays last. Its head is now an ancestor of #48, so the resolver merges it as a no-op and the release manifest still names it.

Verification

Replayed the resolver's own merge sequence against b10223:

OK   c3fb972412  (24423)   15 auto-merged files
OK   02142bbc33  (25731)   19 auto-merged files
OK   daef2b3e1b  (48)      10 auto-merged files
OK   04d6828b2b  (26185)    0 auto-merged files  <- no-op, as intended
UNMERGED PATHS: 0

All four pins pass the resolve step's gate: open, membership OK, each at its PR head.

The merged tree builds clean with -DGGML_CUDA=ON -DLLAMA_BUILD_TESTS=ON. On it:

• test-chat passes
• test-llama-archs -a kimi-k3 is OK on CUDA and CPU (NMSE 8.77e-08). On the old pin it could not even load the model: key not found in model: kimi-k3.expert_latent_length
• both clip_graph_kimik3 and clip_graph_inkling link into libmtmd

One note, not caused by this change: test-llama-archs aborts on qwen3next on the Meta backend, at a graph-split assert in ggml-backend-meta.cpp. Pristine b10223 aborts at the same assert, so it is an upstream issue, not ours.