Vulkan: carry ggml-org#28243 (Qwen3.8-Flash-Next MTP) on our fork branch

[bong-water-water-bong]

third_party/llama.cpp-vulkan moves from ggml-org v0.5.0 to 1bit-MONSTER/llama.cpp 1bit/vulkan-upstream (62484fba): the same release plus ggml-org#28243 (Daniel Han, Ryan Monsurate), carried until upstream merges it.

What #28243 adds: Qwen3.8-Flash-Next's NextN/MTP draft head (--spec-type draft-mtp, so 1bit serve --mtp works for Flash-Next), and a fix for upstream's -md opening the target model instead of the draft file.

Review (line by line, all 849 lines): only the qwen4exp model, its converter scripts, and two lines of shared speculative decoding (the -md path fix; KV sharing limited to gemma4-assistant drafts, which is what v0.5.0 already did since only those keep ctx_other). No network, file, process or build-script changes. A draft head can only change speed: the target checks every drafted token.

Keeping it current: bump-llama-vulkan.yml now rebases the carried commits onto each new release (a commit upstream has merged drops out as empty; one that no longer applies stops the bump), tags the old tip vulkan-upstream-<sha12>, and pins the result. Dry run: the commit rebases cleanly onto upstream master (46 commits past v0.5.0).

Verified on Strix Halo (engine built from this branch, -DONEBIT_VULKAN=ON):

Check	Result
ctest	8/8, serve_e2e_vulkan_upstream PASS
Qwen3-0.6B Q4_K_M	unchanged, 315-331 tok/s
Qwen3.8-27B UD-Q4_K_XL, 1bit serve --mtp	"The capital of France is Paris."; draft acceptance 188/200, 171/252, 6/6 (identical to v0.5.0); 32.2/25.3/31.0 tok/s on a loaded box (35.0/28.1/32.2 earlier)

Not yet run here: Qwen3.8-Flash-Next + --mtp. The box had other work holding 50-65 GB, and the 104 GiB model could not load under the memory guard. Measured on the same patch code (6fcaa16) on an idle box: 40-49 tok/s. Do not merge until it runs on this build.

🤖 Generated with Claude Code

[context7]

Docs7 for 1bit-monster/engine

Result	Status	Action
Deployment	➖ Not used	—
Content review	➖ Did not run. This site has no agent runs available this month. Wait for the monthly reset or check your Docs7 plan.	—

Commit be2b426

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Workflow Logic Clarity The workflow introduces a new rebase logic that tags the old commit and pushes the rebased commit. While the intent is clear, the process of ensuring that the carried commits are correctly rebased and that the tag is properly created and pushed could be brittle. Specifically, if the rebase fails or the tag push fails, the workflow may not fail gracefully, potentially leaving the repository in an inconsistent state. A more robust error handling mechanism or additional checks could improve reliability. # master mirrors ggml-org, so the fork holds the release's objects gh api -X POST repos/1bit-MONSTER/llama.cpp/merge-upstream -f branch=master > /dev/null git init -q fork && cd fork git remote add fork "https://x-access-token:${GH_TOKEN}@github.com/1bit-MONSTER/llama.cpp.git" git remote add upstream https://github.com/ggml-org/llama.cpp.git git fetch -q --filter=blob:none upstream "$UPSTREAM" git fetch -q --filter=blob:none fork 1bit/vulkan-upstream carried=$(git rev-parse FETCH_HEAD) if [ "$carried" != "$OURS" ]; then echo "::error::1bit/vulkan-upstream (${carried:0:12}) is not the engine's pin (${OURS:0:12}); reconcile them by hand" exit 1 fi git fetch -q --filter=blob:none upstream "$OURS_BASE" git checkout -q --detach "$carried" if ! git -c user.name=llama-vulkan-bump -c user.email=llama-vulkan-bump@users.noreply.github.com \ rebase -q --onto "$UPSTREAM" "$OURS_BASE"; then git rebase --abort || true echo "::error::our commits on 1bit/vulkan-upstream do not rebase onto ${TAG}; rebase them by hand" exit 1 fi rebased=$(git rev-parse HEAD) git tag "vulkan-upstream-${carried:0:12}" "$carried" git push -q fork "refs/tags/vulkan-upstream-${carried:0:12}" git push -q --force-with-lease="refs/heads/1bit/vulkan-upstream:$carried" fork "$rebased:refs/heads/1bit/vulkan-upstream" { echo "rebased=$rebased" echo "patches<<EOF"; git log --format='- `%h` %s' "$UPSTREAM..$rebased"; echo "EOF" } >> "$GITHUB_OUTPUT" Documentation Clarity The documentation mentions that the Vulkan route allows new model architectures to reach the system without waiting for AMD's pair to move, which is a good point. However, it doesn't clearly explain how the carried PRs are managed or how they differ from the standard upstream release. Clarifying this distinction would help users understand the benefits and potential risks of using the Vulkan route. ## Carried upstream PRs `1bit/vulkan-upstream` is ggml-org's release plus these commits. On each new release `bump-llama-vulkan.yml` rebases them onto it; one that upstream has merged becomes empty and drops out, and one that no longer applies stops the bump for a hand rebase. The commit the engine pinned before is kept as the tag `vulkan-upstream-<sha12>`. | Upstream PR | What it adds | Carried as | |---|---|---| | [ggml-org#28243](https://github.com/ggml-org/llama.cpp/pull/28243) (Daniel Han, Ryan Monsurate) | Qwen3.8-Flash-Next's NextN/MTP draft head (`--spec-type draft-mtp`), and the fix for `-md` loading the target model instead of the draft file | `62484fba` on v0.5.0 | Reviewed line by line before it was pinned: it touches only the qwen4exp model, its converter, and two lines of the shared speculative decoding (the `-md` path fix, and KV sharing kept to gemma4-assistant drafts, as v0.5.0 already did). A draft head can only change speed: the target model checks every drafted token.