Skip to content

perplexity: honor larger batch size for KLD processing - #156

Open
masel wants to merge 1 commit into
Anbeeld:v0.4.7from
masel:fix/kld-respect-batch-size-pr
Open

perplexity: honor larger batch size for KLD processing#156
masel wants to merge 1 commit into
Anbeeld:v0.4.7from
masel:fix/kld-respect-batch-size-pr

Conversation

@masel

@masel masel commented Sep 11, 2026

Copy link
Copy Markdown

Overview

This PR makes KLD baseline generation and candidate evaluation honor the batch
size requested with --batch-size (-b). --ubatch-size (-ub) continues to
control 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 2048 is reduced to 540 rows:

kl_divergence: computing over 9 chunks, n_ctx=32768, batch_size=540, n_seq=1

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 -b does not restore the
context-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 additional
storage for retaining more full-vocab rows is host memory. For the tested
248320-token vocabulary, a batch size of 2048 requires approximately:

  • 1940 MiB for the F32 logits block
  • 970 MiB for the compressed baseline block
  • 2910 MiB total block storage

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:

CUDA0 compute buffer size     = 2108.00 MiB
CUDA_Host compute buffer size = 208.34 MiB

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 2048 now reports batch_size=2048
  • patched BeeLlama and llama.cpp b10830 produced identical printed results
    against a b10830-generated baseline:
    • Mean PPL(Q): 7.026714 +/- 0.047518
    • Mean PPL(base): 7.013139 +/- 0.047018
    • Mean KLD: 0.007269 +/- 0.000738
    • Same top p: 98.540 +/- 0.031 %
  • test-perplexity-plumbing passes

Requirements

  • I have read and agree with the contributing guidelines
  • AI usage disclosure: YES - AI tools assisted with implementation review, test-result analysis, and drafting this PR description; the changes and reported results were reviewed and tested by the submitter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant