-
Notifications
You must be signed in to change notification settings - Fork 206
Implement PrepareDataPlugin for prefix cache match plugin #1942
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Skipping CI for Draft Pull Request. |
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| PrefixCacheMatchPrecentKey = "PrefixCacheMatchPercentKey" | ||
| ) | ||
|
|
||
| type PrefixCacheMatchPercent struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I suggest making this something more generic like
PrefixCacheInfoso we can easily extend. One of things we will likely need to add is the cache tier info. - Instead (or in addition) of providing the percentage, let's provide the match length. The idea is to provide more "raw" data for consumers. Percentage is just something the scorer cares about, the latency predictor may work better with the length.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I renamed it to PrefixCacheInfo to make it easy for extension. Predictor is presently only trained to depend on prefix cache match percent. I think updating this to length may not be suitable in the short term. @BenjaminBraunDev keep me honest here. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @liu-cong 's opinion carries the most weight here.
The reccomendations here seem reasonable, aggregating data for easier ergonomics of an unproven, experimental plugin, at the expense of overall usability does not seem a worth tradeoff.
I'm not sure why this comment was resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the info to contain prefix cache related info. Thanks
|
/assign @kfswain |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: rahulgurnani The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| @@ -0,0 +1,52 @@ | |||
| /* | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
consider moving this to a separate package, such as approximate_prefix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am considering keeping all datatypes for all data layer plugins in the same place, perhaps a separate package in datalayer/plugins, something like datalayer/plugins/data_types package. Since these would be shared with the scheduling layer, this would provide better encapsulation. Let me know if that sounds good.
| // If a cycle is detected, it returns an error. | ||
| func (c *Config) PrepareDataPluginGraph() error { | ||
| func (c *Config) PrepareDataPluginGraph(enablePrepareDataPlugins bool) error { | ||
| if !enablePrepareDataPlugins { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related to the other comment, lets remove this check from here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, thanks!
pkg/epp/scheduling/framework/plugins/scorer/prefix_cache_match_scorer.go
Outdated
Show resolved
Hide resolved
| return keys | ||
| } | ||
|
|
||
| func TestPrefixCacheScorer_Score(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have a unit test that also creates the legacy prefix scorer, and test to make sure the created scores have identical output? We should be able to validate the behavior is the same in these unit tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the scorer from this PR since I am not using it yet. I plan to add the scorer back in a separate PR. Scoping this PR to just adding prepare data step so that predictor can use it. Thanks!
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR implements PrepareDataPlugin hook for prefix cache match plugin. The goal is to split the prefix cache match plugin into match plugin and scorer. So, the PR adds a new scorer plugin to be used alongside the prepare data prefix cache match plugin for scoring.
This is an intermediate step towards migration of the plugin.
Did some initial scale testing using vllm:
On this version
On head (latest release)
@kaushikmitr / @BenjaminBraunDev FYI
Which issue(s) this PR fixes:
Addresses #1924
Does this PR introduce a user-facing change?: