-
Notifications
You must be signed in to change notification settings - Fork 215
add preparedata plugin to latency based scorer to consume prefix states #2005
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
add preparedata plugin to latency based scorer to consume prefix states #2005
Conversation
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@ahg-g this PR simplifies the helm chart config to pick latency aware routing if enabled or switch to default if not. |
pkg/epp/scheduling/framework/plugins/multi/slo_aware_router/slo_aware_profile_handler.go
Outdated
Show resolved
Hide resolved
pkg/epp/scheduling/framework/plugins/multi/slo_aware_router/preparedata_hooks.go
Outdated
Show resolved
Hide resolved
|
@kaushikmitr the naming is a bit all over the place, we use slo / predictor / router etc. I thought we agreed on predicted-latency as the name of the plugin. We can change that in a follow up PR, but I think we should address it soon since the plugin name will be part of the "config api" and it is user facing. |
yes we need to clean up two things. The naming of the plugin (predicted latency) and renaming TPOT everywhere (including docs) to ITL |
| matchLen := state.PrefixCacheServers[ServerID(pod.GetPod().NamespacedName)] | ||
| pod.Put(approximateprefix.PrefixCacheMatchInfoKey, approximateprefix.NewPrefixCacheMatchInfo(matchLen, total)) | ||
| } | ||
| // Store the state in plugin state for later 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.
why do we need to change anything in the prefix plugin?
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 prefix scorer does not consume the prefix state in the same way as the predicted latency one?
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.
its a bug. We are not writing in the plugin state of the prefix-cache-scorer plugin during preparadata but only during scoring. This change will fix that. Also talked to @rahulgurnani about this. We can track it in a separate PR too.
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.
This is not addressed yet
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.
my comment was in pending state, see my response above
can we open an issue to track this work pls? |
pkg/epp/scheduling/framework/plugins/multi/slo_aware_router/scorer.go
Outdated
Show resolved
Hide resolved
| pod.Put(approximateprefix.PrefixCacheMatchInfoKey, approximateprefix.NewPrefixCacheMatchInfo(matchLen, total)) | ||
| } | ||
| // Store the state in plugin state for later use. | ||
| p.pluginState.Write(request.RequestId, plugins.StateKey(p.TypedName().String()), state) |
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.
@ahg-g @kfswain talked to @rahulgurnani figured we need to write to plugin state in the preparadata step to ensure that running scorer is not needed to have the plugin state populated. I tested both with and without the feature gate.
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.
PreRequest extension for the prefix plugin is executed even if the prefix scorer is not configured to run, right?
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.
Yes, I validated that
pkg/epp/scheduling/framework/plugins/multi/slo_aware_router/slo_aware_profile_handler.go
Outdated
Show resolved
Hide resolved
| matchLen := state.PrefixCacheServers[ServerID(pod.GetPod().NamespacedName)] | ||
| pod.Put(approximateprefix.PrefixCacheMatchInfoKey, approximateprefix.NewPrefixCacheMatchInfo(matchLen, total)) | ||
| } | ||
| // Store the state in plugin state for later 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.
its a bug. We are not writing in the plugin state of the prefix-cache-scorer plugin during preparadata but only during scoring. This change will fix that. Also talked to @rahulgurnani about this. We can track it in a separate PR too.
|
|
/lgtm Thanks! |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahg-g, kaushikmitr The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This pull request introduces refactoring and simplification of the prediction-based routing logic in the inference pool scheduler, focusing on introducing the PrepareRequestData plugin to get the prefix cache score and updating the prediction-based routing helm chart config.
Core logic and data structure simplification:
sloRequestContextstruct now stores all prediction results in a singlepredictionsForSchedulingslice, replacing the previous separate maps for TTFT and TPOT values. All code paths and tests have been updated to use this unified structure.generatePredictionsandscoreWithoutPredictionsfunctions now rely exclusively on precomputed prefix cache scores from the SLO context, removing the need to pass and use theCycleStateobject for these calculations.PrepareRequestDatamethod is introduced to precompute and populate prefix cache scores in the SLO context, further decoupling data preparation from scoring and prediction logic.Prediction-based scheduling flow and configuration:
NoLatencyRoutingProfileNameand associated logic) have been removed, consolidating the routing flow and simplifying the profile handler's logic.SLOAwareProfileHandler.Pickmethod is simplified to always return all profiles unless all have already been executed, removing conditional execution based on headers.samplingMeanin the latency scorer configuration is increased from 100.0 to 1000.0.Helm Chart: