perplexity: honor larger batch size for KLD processing - #156
Open
masel wants to merge 1 commit into
Open
Conversation
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
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.
Overview
This PR makes KLD baseline generation and candidate evaluation honor the batch
size requested with
--batch-size(-b).--ubatch-size(-ub) continues tocontrol the internal physical split.
The KLD path currently applies a fixed 512 MiB cap to the number of full-vocab
F32 logits rows. This silently reduces the effective decode batch even when the
context and compute graph were configured for a larger value. For example, with
a vocabulary of 248320 tokens,
-b 2048 -ub 2048is reduced to 540 rows:That is surprising when the batch size was explicitly requested and differs from the
KLD behavior in the corresponding llama.cpp b10830 base. The KLD implementation
already processes data block by block, so honoring
-bdoes not restore thecontext-wide logits retention of the older upstream implementation. The 512 MiB
row cap remains in place for ordinary perplexity calculation.
The change also sizes the compressed baseline block from the effective decode
batch and adds a plumbing regression test and memory guidance to the perplexity
README.
Additional information
The existing batch-size setting is already the memory/performance control for
this path; users who need lower host-memory use can reduce
-b. The additionalstorage for retaining more full-vocab rows is host memory. For the tested
248320-token vocabulary, a batch size of 2048 requires approximately:
This is about 2.1 GiB more host memory than the previous 540-row limit.
In the tested CUDA configuration (
-c 32768 -b 2048 -ub 2048 -fa on, Q8_0 KV),the backend-reported allocations were unchanged between the capped and patched
runs because the context had already reserved the graph for the requested batch:
This observation is specific to the tested configuration; other backends or
larger batch/ubatch settings may have different device-memory requirements.
Validation performed on Windows/CUDA with a Qwen3.8 27B model and 248320-token
vocabulary:
-c 32768 -b 2048 -ub 2048now reportsbatch_size=2048against a b10830-generated baseline:
7.026714 +/- 0.0475187.013139 +/- 0.0470180.007269 +/- 0.00073898.540 +/- 0.031 %test-perplexity-plumbingpassesRequirements