Repository navigation
fix: SurprisalScorer reuses a mutated KV cache across batches - #184
Open
flyingdoubleG wants to merge 1 commit into
Open
flyingdoubleG wants to merge 1 commit into
flyingdoubleG wants to merge 1 commit into
Conversation
compute_loss_with_kv_cache built the explanation's KV cache once and passed it to every batch, but the forward pass appends the batch's tokens to the DynamicCache in place, so later batches attended to earlier batches' sentences and got wrong losses. A partial last batch also repeat_interleaved an already repeated tensor and failed with a batch-size mismatch. Build the explanation cache for each batch.
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.
Summary
SurprisalScorer.compute_loss_with_kv_cachehas two problems:past_key_valuesto every batch. On current transformers this is aDynamicCache, which the forward pass extends in place with the batch's tokens. Every batch after the first then attends to the sentences of the earlier batches (and has shifted positions), and its losses are wrong. There is no error.explanation_tokenshas already been repeated tobatch_sizerows, and the partial-batch branch callsrepeat_interleave(current_batch_size)on it again, givingbatch_size * current_batch_sizerows. Withlen(samples) % batch_size != 0the forward pass raisesRuntimeError: Sizes of tensors must match except in dimension 2.Repro: a randomly initialised 2-layer GPT-2,
batch_size=2, four sentences. Each per-token loss is compared with a full forward pass ofexplanation + sentence:Change
Build the explanation cache inside the batch loop, sized to the current batch (
explanation_tokens.expand(current_batch_size, -1)). This fixes both problems. The cost is one extra forward pass over the short explanation prompt per batch.Tests
tests/test_scorers/test_surprisal.pybuilds a random 2-layer GPT-2 with thetokenizerfixture's vocabulary and uses 5 sentences withbatch_size=2(two full batches and a partial one). It checks every per-token loss against the full forward pass. It fails on main (theRuntimeErrorabove) and passes with this change.ruff checkandblack --checkpass. Locally I ran it with a stand-intokenizerfixture instead oftests/conftest.py, since vLLM does not install on Windows.