Repository navigation
llama : re-reserve the sched when the nextn extraction flags change - #30020
Merged
Merged
Conversation
The speculative MTP init enables NextN extraction on the target and draft contexts after both were created and their schedulers reserved. With unmasked extraction the trunk graph keeps every token through the last layer instead of cropping to the output rows, so the first decode reallocates to that batch's shape and the next, wider batch trips GGML_SCHED_DEBUG_REALLOC. Invalidate the reserve when the flags change so the next compute re-reserves with the new graph shape. Assisted-by: Claude
Member
|
Yes, I think we need that. I am also trying to consolidate the logic across all the graphs to make it easier to follow: #30017 |
Member
|
Let's do the following order:
|
ggerganov
approved these changes
Oct 6, 2026
ServeurpersoCom
approved these changes
Oct 6, 2026
Contributor
|
wouldn't this cause a big re-reserve during inference? Possibly this will be fixed via #30017 |
Member
Hm, did I miss some case? The nextn flags are only changed once upon speculative context construction and shouldn't change during inference? |
wanghqc
added a commit
to qualcomm/llama.cpp
that referenced
this pull request
Oct 8, 2026
…change (ggml-org#30020)" This reverts commit 1a3011c on this branch only. With it, Qwen3.8-27B with its built-in MTP head (--spec-type draft-mtp) produces a different greedy output on every request through llama-server on the X2-90, while upstream master's OpenCL backend and this branch without the change are deterministic. The re-reserve changes the compute-buffer layout and exposes a branch-specific read of unwritten memory that is still being located. E4B with its MTP assistant keeps the same speed and output without the change.
edwardyoon
pushed a commit
to edwardyoon/focus-llama
that referenced
this pull request
Oct 8, 2026
…gml-org#30020) The speculative MTP init enables NextN extraction on the target and draft contexts after both were created and their schedulers reserved. With unmasked extraction the trunk graph keeps every token through the last layer instead of cropping to the output rows, so the first decode reallocates to that batch's shape and the next, wider batch trips GGML_SCHED_DEBUG_REALLOC. Invalidate the reserve when the flags change so the next compute re-reserves with the new graph shape. Assisted-by: Claude (cherry picked from commit 1a3011c)
wanghqc
added a commit
to qualcomm/llama.cpp
that referenced
this pull request
Oct 8, 2026
… change (ggml-org#30020)" This reverts commit f409182.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#29958 fixed reallocation in the non-MTP path, but the MTP path still failed under GGML_SCHED_DEBUG_REALLOC because the initial graph was built before the nextn extraction flags were set.
Requirements