You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pkg/epp/framework/plugins/scheduling/scorer/prefix/README.md
+35-13Lines changed: 35 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,37 +2,59 @@
2
2
3
3
**Type:**`prefix-cache-scorer`
4
4
5
-
Scores candidate endpoints using `PrefixCacheMatchInfo` prepared earlier in the request pipeline.
5
+
Scores candidate endpoints based on how much of the request's prefix is already cached. It can consider both the *ratio* of the prefix matched and the *absolute length* of the match. By default it only considers the ratio of prefix matched.
6
6
7
7
## What it does
8
8
9
-
For each candidate endpoint, the scorer reads the `PrefixCacheMatchInfo` attribute and computes:
9
+
The scorer computes a score between `0.0` and `1.0` for each endpoint using a weighted combination of two metrics:
10
+
11
+
1.**Match Ratio**: The proportion of the request prefix that is cached.
12
+
2.**Match Length**: The absolute number of cached tokens, normalized against a scale factor.
***`matchLengthScaleTokens`** is the scaling factor.
16
25
17
-
- higher score: more of the request prefix is expected to be reusable from cache
18
-
- lower score: less prefix cache reuse is expected
26
+
If `matchLengthWeight` is `0.0` (default), the score simplifies to just the `matchRatioScore`.
19
27
20
28
If the attribute is missing, has the wrong type, or `totalBlocks` is zero, the endpoint receives score `0`.
21
29
22
-
## Inputs consumed
30
+
### Why the Quadratic Term?
31
+
32
+
The squaring of `matchLengthScore` introduces a non-linearity motivated by the fact that attention computation grows quadratically as a function of prompt length. This ensures that the scoring function assigns a higher priority to longer requests, where the computational and latency savings of KV-cache reuse are significantly more critical.
23
33
24
-
This scorer consumes:
34
+
## Inputs Consumed
25
35
26
36
-`PrefixCacheMatchInfo`
27
37
28
38
The attribute is typically produced by the approximate prefix cache data producer before scheduling.
29
39
30
40
## Configuration
31
41
32
-
This plugin does not define any plugin-specific parameters.
42
+
| Parameter | Type | Description | Default |
43
+
| :--- | :--- | :--- | :--- |
44
+
|`matchLengthWeight`| float | Weight of the absolute match length in the score. Must be between `0.0` and `1.0`. |`0.0`|
45
+
|`matchLengthScaleTokens`| integer | The number of tokens used to normalize `matchLengthScore`. |`8192`|
46
+
47
+
### Example
48
+
49
+
```yaml
50
+
plugins:
51
+
- type: prefix-cache-scorer
52
+
parameters:
53
+
matchLengthWeight: 0.5
54
+
matchLengthScaleTokens: 16384
55
+
```
33
56
34
-
## Operational notes
57
+
## Operational Notes
35
58
36
-
- The scorer itself does not hash prompts or maintain cache state.
37
-
- It only converts previously prepared prefix match data into endpoint scores.
38
-
- To be useful, it should be used together with a data producer that populates `PrefixCacheMatchInfo`.
59
+
* **Tuning `matchLengthScaleTokens`**: This should be set to reflect your workload. A good rule of thumb is to set it to the **P95 prompt length** of your typical requests. Setting it too high (e.g., to the model's maximum limit when actual requests are short) will compress the score range and make the scorer less effective.
60
+
* The scorer is stateless; it does not manage cache state or hash prompts itself. It relies entirely on the data producer.
0 commit comments