-
Notifications
You must be signed in to change notification settings - Fork 139
Implement Inference Extension #4091
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
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #4091 +/- ##
==========================================
- Coverage 86.71% 86.59% -0.12%
==========================================
Files 128 131 +3
Lines 16758 17788 +1030
Branches 62 74 +12
==========================================
+ Hits 14531 15404 +873
- Misses 2042 2185 +143
- Partials 185 199 +14 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Did some manual testing for inference extension and with some other path based headers, query params and seemed to be fine. Did not work with URLRewrite filter, is that expectation correct? |
|
looks like the helm chart is failing Also not sure what pipeline wants to do here. Do we just test by installing minimum args needed? or this should have inference flag to test with |
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.
lgtm if we can just get those helm tests working
Problem: To support the full Gateway API Inference Extension, we need to be able to extract the model name from the client request body in certain situations. Solution: Add a basic NJS module to extract the model name. This module will be enhanced (I've added notes) to be included in the full solution. On its own, it is not yet used.
This commit adds support for the control plane to watch InferencePools. A feature flag has been added to enable/disable processing these resources. By default, it is disabled. When an HTTPRoute references an InferencePool, we will create a headless Service associated with that InferencePool, and reference it internally in the graph config for that Route. This allows us to use all of our existing logic to get the endpoints and build the proper nginx config for those endpoints. In a future commit, the nginx config will be updated to handle the proper load balancing for the AI workloads, but for now we just use our default methods by proxy_passing to the upstream.
Problem: In order for NGINX to get the endpoint of the AI workload from the EndpointPicker, it needs to send a gRPC request using the proper protobuf protocol. Solution: A simple Go server is injected as an additional container when the inference extension feature is enabled, that will listen for a request from our (upcoming) NJS module, and forward to the configured EPP to get a response in a header.
Problem: We need to connect NGINX to the Golang shim that talks to the EndpointPicker, and then pass client traffic to the proper inference workload. Solution: Write an NJS module that will query the local Go server to get the AI endpoint to route traffic to. Then redirect the original client request to an internal location that proxies the traffic to the chosen endpoint. The location building gets a bit complicated especially when using both HTTP matching conditions and inference workloads. It requires 2 layers of internal redirects. I added lots of comments to hopefully clear up how we build these locations to perform all the routing steps.
Update the inference extension design doc to specify different status that needs to be set on Inference Pools to understand its state
…4006) Update gateway inference extension proposal on inability to provide a secure TLS connection to EPP.
Add status to Inference Pools Problem: Users want to see the current status of their Inference pools Solution: Add status for inference pools
Proposed changes Problem: Want to collect number of referenced InferencePools in cluster. Solution: Collect the count of referenced InferencePools. Testing: Unit tests and manually verified collection via debug logs.
When setting inference pool statuses, it loops through all the inference pools and checks if there are any nginx gateways that have parentRefs in the statuses. If there are AND the infernece pool is not referenced (not connected to the graph), it will remove that parentRef.
Enable conformance tests for Inference Extension Co-author: Ciara Stacker <c.stacke@f5.com>
941ac2d to
3bdae01
Compare
Proposed changes
Problem: As a cluster operator managing traffic for generative models
I want to route prompt traffic within my cluster based on generative model request criteria
So that I can build a system to host multiple generative models.
Solution: Add Gateway API Inference Extension support
Ref: https://gateway-api-inference-extension.sigs.k8s.io/
Testing: Extensive manual testing, and conformance testing is enabled in the pipeline, and everything is passing
Closes #3644
Checklist
Before creating a PR, run through this checklist and mark each as complete.
Release notes
If this PR introduces a change that affects users and needs to be mentioned in the release notes,
please add a brief note that summarizes the change.