Add EntropyGatedChunkKVPress - #263
Open
ShaharBenIshay wants to merge 1 commit into
Open
Conversation
Co-authored-by: Liran Azran <liran.azr90@gmail.com> Signed-off-by: Shahar Ben-Ishay <shahar.benishay@gmail.com>
|
Some further results. All runs used the same model and same hyperparams ( RULER-4096, mean over the 13 subtasks:
The gate is not tied to one scorer. Swapping the inner
Thanks! |
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.
PR description
Adds
EntropyGatedChunkKVPress(EG-ChunkKV), as proposed and approved in #261.ChunkKVPressscores each chunk by its aggregate token importance and then keeps or drops thatchunk as a whole. Because the score is a magnitude statistic, it cannot distinguish a coherent
chunk, whose importance is spread across its tokens, from a spiky one, where a single needle
token holds nearly all the mass and the remaining
chunk_length - 1tokens are filler. Both canscore identically, and for the spiky chunk, keeping it whole spends
chunk_lengthcache slots topreserve one useful token — which, under a fixed budget, evicts a chunk that would otherwise be kept.
EG-ChunkKV adds a second, shape statistic computed from the same per-token scores ChunkKV already
has: the normalized within-chunk Shannon entropy
H̃_i ∈ [0, 1], where 1 means coherent and 0 meansconcentrated in a few tokens. Important-but-spiky chunks are reduced to their top-
rescue_sizetokens rather than kept whole, and the freed budget is spent on further chunks. The number of
retained tokens is exactly
max(1, floor((1 - compression_ratio) * kv_len)), identical toChunkKVPress, so the two are budget-matched by construction.Selection procedure
S_i: the mean of the head-summed, non-negative token scores in chunki. This is the samestatistic
ChunkKVPressranks chunks by, so both methods order chunks identically.H̃_i: the normalized Shannon entropy of those same token scores within the chunk.Lthat ChunkKV uses and walk chunks greedily in decreasing
S_i, spending budget as we go:If the rescues leave budget unspent, a final fill adds the highest-scoring not-yet-retained tokens,
so exactly
Lpositions are kept and the retained indices are sorted back into original order.Both gating masks are computed vectorized and moved to CPU once, so the sequential budget walk reads
no GPU scalars per iteration — without that, the per-chunk synchronization made this measurably
slower than plain ChunkKV.
Results
Llama-3.1-8B-Instruct, SnapKV as the inner scorer(for a fair comparison vs chunkkv, although we are even stronger with expected attention),
chunk_length=10,rescue_size=4.cris thefraction of the KV cache removed. LongBench is the 16-task average; LOOGLE is ROUGE-L × 100. Higher
is better. ChunkKV is run at the same
chunk_length=10so the comparison isolates the entropy gate.The gain holds at every ratio and grows as the budget tightens, peaking at +1.35 at
cr=0.90. LOOGLE shows the same direction under aggressive compression (+0.42 and +0.46) but isslightly behind at
cr=0.70(−0.11), which is consistent with the mechanism: the wasted budget onlybecomes costly once slots are genuinely scarce.
Notes for review
docstring cites only the ChunkKV paper.
default_pressescheckbox is intentionally unticked. That list is instantiated ascls(compression_ratio=...), but this press requirespress=and exposescompression_ratioas adelegating property, so it cannot be constructed that way.
ChunkKVPressis absent from the listfor the same reason. Instead the press is added to the
wrapper_pressmatrix intests/presses/test_presses.py, following theChunkKVPressprecedent, which exercises it againstevery press in
default_presses.chunk_lengthdefaults to 10, not 20 as inChunkKVPress. Finer granularity gives the gatemore chunks to reallocate budget between — the table above shows the mechanism is markedly stronger
at 10 — and it is the configuration all reported numbers use (however we did measure our method at c=20 and it will be presented in our preprint in depth).
Checklist
Before submitting a PR, please make sure:
Tests are working (
make test)Code is formatted correctly (
make style, on errors try fix withmake format)Copyright header is included
All commits are signed-off using
git commit -s(new press)
mypress_press.pyis in thepressesdirectory(new press)
MyPressis in__init__.py(new press)
README.mdis updated with a 1 liner about the new press in the Available presses section(new press) New press is in the
default_presseslist intests/default_presses.py(new press) A docstring is provided that follows the same structure as the existing ones