-
Notifications
You must be signed in to change notification settings - Fork 207
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
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 |
| // 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!
pkg/epp/scheduling/framework/plugins/scorer/prefix_cache_match_scorer.go
Outdated
Show resolved
Hide resolved
pkg/epp/scheduling/framework/plugins/scorer/prefix_cache_match_scorer.go
Outdated
Show resolved
Hide resolved
|
|
||
| // PrepareDataPluginGraph creates data dependency graph and sorts the plugins in topological order. | ||
| // If a cycle is detected, it returns an error. | ||
| func (c *Config) PrepareDataPluginGraph() error { |
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.
The DAG should be built, completely agnostic of if any PrepareData plugins are in use. Will add suggestions to help clarify what I mean
| if len(c.prepareDataPlugins) == 0 { | ||
| return nil | ||
| } | ||
| dag := buildDAG(c.prepareDataPlugins) | ||
| plugins, err := sortPlugins(dag, c.prepareDataPlugins) | ||
| if err != nil { |
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.
| if len(c.prepareDataPlugins) == 0 { | |
| return nil | |
| } | |
| dag := buildDAG(c.prepareDataPlugins) | |
| plugins, err := sortPlugins(dag, c.prepareDataPlugins) | |
| if err != nil { | |
| dag := buildDAG(c.allPlugins) | |
| plugins, err := sortPlugins(dag, c.allPlugins) | |
| if err != nil { |
This is semi psuedocode. But I hope this kind of illustrates what I mean. We should always create the DAG, entirely agnostic of which plugins are in use.
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.
Ohh. I understand. Added a TODO for it and address it as a fast follow in the next PR. Let me know if that's reasonable. Thanks!
|
/retest |
672ca5e to
1a0c28c
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kfswain, rahulgurnani The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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.
This is an intermediate step towards migration of the plugin. In a following PR, scorer would be added and the existing prefix cache match plugin would be deprecated.
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?: