doc: add doc for infernecemodelrewrites. #1978
Open
+472
−34
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
k8s-ci-robot
added
the
kind/documentation
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: zetxqx 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 |
k8s-ci-robot
added
size/XL
ahg-g
reviewed
Dec 12, 2025
|
|
||
| * **Model Aliasing**: Map a model name in the request body (e.g., `food-review`) to a specific version (e.g., `food-review-v1`). | ||
| * **Generic Fallbacks**: Redirect unknown model requests to a default model. | ||
| * **Traffic Splitting**: Gradually roll out new model versions (Canary deployment) by splitting traffic between two models based on percentage weights. |
Contributor
There was a problem hiding this comment.
We should be clear here that this is scoped to traffic splitting within an inferencePool; it will not split traffic between two different pools, but two adapters served by the same inferencePool.
We need to have an overall guide that covers all traffic splitting use cases to make it clear which cases are covered by which api and by which component
| Use LoRA adapter rollouts to test improvements, bug fixes, or new features in your LoRA adapters. | ||
|
|
||
| ## Example | ||
| The [`InferenceModelRewrite`](/api-types/inferencemodelrewrite) resource allows platform administrators and model owners to control how inference requests are routed to specific models within an Inference Pool. |
Contributor
There was a problem hiding this comment.
Suggested change
| The [`InferenceModelRewrite`](/api-types/inferencemodelrewrite) resource allows platform administrators and model owners to control how inference requests are routed to specific models within an Inference Pool. | |
| The [`InferenceModelRewrite`](/api-types/inferencemodelrewrite) resource allows platform administrators and model owners to control how inference requests are routed to specific models within an InferencePool. |
| Follow [getting-started](https://gateway-api-inference-extension.sigs.k8s.io/guides/getting-started-latest/#getting-started-with-an-inference-gateway) to set up the IGW stack. | ||
|
|
||
| This guide leverages the LoRA syncer sidecar to dynamically manage adapters within a vLLM deployment, enabling users to add or remove them through a shared ConfigMap. | ||
| In this guide, we modify the LoRA adapters configMap to have two food-review models to better illustrate the gradual rollout scenario. |
Contributor
There was a problem hiding this comment.
Suggested change
| In this guide, we modify the LoRA adapters configMap to have two food-review models to better illustrate the gradual rollout scenario. | |
| In this guide, we modify the LoRA adapters ConfigMap to have two food-review models to better illustrate the gradual rollout scenario. |
| ``` | ||
|
|
||
| Change the ConfigMap to match the following (note the new entry under models): | ||
| The configMap used in this guide is as follows: |
Contributor
There was a problem hiding this comment.
Suggested change
| The configMap used in this guide is as follows: | |
| The ConfigMap used in this guide is as follows: |
| curl http://${IP}/v1/models | jq . | ||
| ``` | ||
|
|
||
| ## Step 1: Establish Baseline (Alias v1) |
Contributor
There was a problem hiding this comment.
Suggested change
| ## Step 1: Establish Baseline (Alias v1) | |
| ## Step 1: Establishing A Baseline (Alias v1) |
|
|
||
| ## Step 2: Gradual Rollout | ||
|
|
||
| Now that `food-review-v2` is loaded (from the Prerequisites step), we can begin splitting traffic. Traffic splitting allows you to divide incoming traffic for a single model name across multiple backend models. This is critical for A/B testing or gradual updates. |
Contributor
There was a problem hiding this comment.
Suggested change
| Now that `food-review-v2` is loaded (from the Prerequisites step), we can begin splitting traffic. Traffic splitting allows you to divide incoming traffic for a single model name across multiple backend models. This is critical for A/B testing or gradual updates. | |
| Now that `food-review-v2` is loaded (from the Prerequisites step), we can begin splitting traffic. Traffic splitting allows you to divide incoming traffic for a single model name across different adapters. This is critical for A/B testing or gradual updates. |
|
|
||
| Now that `food-review-v2` is loaded (from the Prerequisites step), we can begin splitting traffic. Traffic splitting allows you to divide incoming traffic for a single model name across multiple backend models. This is critical for A/B testing or gradual updates. | ||
|
|
||
| ### Scenario: 90/10 Split |
Contributor
There was a problem hiding this comment.
same as in the previous section, recommend removing the header here and just make the following paragraph part of the intro section
| food-review-v2: 3 requests | ||
| ``` | ||
|
|
||
| ### Scenario: 50/50 Split |
| Try it out: | ||
| A client requests the model `food-review`. We want to ensure this maps strictly to `food-review-v1`. | ||
|
|
||
| ### InferenceModelRewrite |
| - modelRewrite: "food-review-v1" | ||
| ``` | ||
|
|
||
| ### Result |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #1925
Does this PR introduce a user-facing change?: