Resolve #1047: LLM caching: Bug when sharing prefix in target #1048
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.
When caching labels we're assuming that each encoded label has an EOS token. This is not given with every tokenizer. For example the GPT2 tokenizer doesn't do this.
Without the EOS token labels with shared prefixes, e.g. '11' and '11111' (= '11' + '111'), will both have cache entries for the shared prefix '11' but will have different total label lengths (in this case 1 vs. 2 tokens). This then leads to the scenario that, when generating logits for label '11' we will have a 'next' cache entry (for '111') but no more label left. The code only checks for the EOS token (which is not present) and we run into an index error.
The solution is, in this case, to also check if the label we want logits for is already completely checked.