docs: add LLMInferenceService with AgentGateway integration guide#697
docs: add LLMInferenceService with AgentGateway integration guide#697mgonzalezo wants to merge 1 commit into
Conversation
✅ Deploy Preview for elastic-nobel-0aef7a ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
c557711 to
684e325
Compare
bartoszmajsak
left a comment
There was a problem hiding this comment.
Thanks for this contribution. Very happy to see that flexibility of the API makes such integration quite straightforward.
I have couple of suggestions and a gap we will address on our side.
| | Protocol detection | `http` (generic) | `llm` (LLM-aware) | | ||
| | Token parsing | No | Yes | | ||
| | Model tracking | No | Yes | | ||
| | GenAI telemetry (OTel) | No | Yes | |
There was a problem hiding this comment.
Is this accurate? We lately added this integration, so I am not sure this is AgentgatewayBackend specific feature.
There was a problem hiding this comment.
thanks for flagging #5481. I've clarified the table: KServe's distributed tracing provides request-level spans/traces, while the GenAI semantic conventions here refer to LLM-specific OTel attributes (gen_ai.usage.input_tokens, gen_ai.request.model, etc.) that AgentGateway emits at the gateway level. Added a note explaining they're complementary.
| "model-serving/generative-inference/llmisvc/llmisvc-config-composition", | ||
| "model-serving/generative-inference/llmisvc/llmisvc-dependencies", | ||
| "model-serving/generative-inference/llmisvc/llmisvc-envoy-ai-gateway", | ||
| "model-serving/generative-inference/llmisvc/llmisvc-agentgateway", |
There was a problem hiding this comment.
Maybe we could have a dedicated section for both agentgateway and envoy-ai-gateway under "Integrations"? (I am terrible at naming...)
There was a problem hiding this comment.
Moved both llmisvc-envoy-ai-gateway and llmisvc-agentgateway under a new "Integrations" subcategory within LLMInferenceService
| host: my-model-kserve-workload-svc.kserve-test.svc.cluster.local | ||
| port: 8000 |
There was a problem hiding this comment.
They should both go under .provider . https://docs.solo.io/agentgateway/2.3.x/reference/api/api/#llmprovider
There was a problem hiding this comment.
Got it, host and port now sit under .provider alongside the provider type, matching the API reference. Also switched from custom to openai provider type since KServe runtimes expose OpenAI-compatible endpoints.
| nvidia.com/gpu: 1 | ||
| ``` | ||
|
|
||
| Wait for the InferenceService to be ready: |
There was a problem hiding this comment.
| Wait for the InferenceService to be ready: | |
| Wait for the LLMInferenceService to be ready: |
| router: | ||
| scheduler: {} | ||
| route: {} | ||
| gateway: {} |
There was a problem hiding this comment.
This is not needed b/c below you are using:
parentRefs:
- group: gateway.networking.k8s.io
kind: Gateway
name: agentgateway
namespace: kserve-test
There was a problem hiding this comment.
Noted, since the route override uses explicit parentRefs, I removed it from examples.
| name: Qwen/Qwen2.5-0.5B-Instruct | ||
| replicas: 1 | ||
| router: | ||
| scheduler: {} |
There was a problem hiding this comment.
Setting scheduler: {} is unnecessary here and actually problematic - it creates an EPP deployment and InferencePool that no HTTPRoute references. AgentGateway won't write an Accepted status for the pool since no route targets it, leaving InferencePoolReady stuck at WaitingForGateway and blocking the overall Ready condition indefinitely. On top of that, AgentGateway doesn't even watch InferencePool resources unless inferenceExtension.enabled=true is set (disabled by default).
@pierDipi, maybe we should signal misconfig in the conditions?
There was a problem hiding this comment.
Thank you for the clarification, I have removed it from the examples. Happy to help with a follow-up PR once you and @pierDipi agree on the right approach here.
Signed-off-by: Marco Gonzalez <margonza@redhat.com> docs: address review feedback on AgentGateway integration guide Signed-off-by: Marco Gonzalez <margonza@redhat.com>
657fe61 to
b326be3
Compare
|
xref: kserve/kserve#5518 |
…-aware routing Proves that overriding backendRef in KServe-generated HTTPRoutes from InferencePool to AgentgatewayBackend activates AgentGateway's full LLM pipeline - GenAI telemetry, token tracking, and token-based rate limiting. Without this override, AgentGateway treats inference traffic as generic HTTP, missing model-aware observability and rate controls. The spike validates the integration described in kserve/website#697 using a tiny vLLM model on kind with no GPU required. Ref: kserve/kserve#5729 Signed-off-by: Bartosz Majsak <bartosz.majsak@gmail.com>
|
@bartoszmajsak when you have a moment, PTAL. I see you are testing this PR in https://github.com/bartoszmajsak/playground via bartoszmajsak/playground@f8a7a2c. Can you help me understand if this is part of the typical validation workflow. |
@danehans This is related I think, PTAL kserve/kserve#5776 |
@danehans not quite sure what the exact ask is - I was simply testing samples from this doc e2e out of curiosity. And both feedback here and PR linked previously are the results of this "spike". |
Related to kserve/kserve#5729
Add a procedural guide for integrating LLMInferenceService with AgentGateway
to enable LLM-aware routing, token tracking, and GenAI telemetry using the
existing
LLMInferenceServiceConfigbackendRef override mechanism.Proposed Changes
docs/model-serving/generative-inference/llmisvc/llmisvc-agentgateway.mdwith step-by-step instructions for overriding HTTPRoute backendRef to use AgentgatewayBackendspec.router.route.httpand reusableLLMInferenceServiceConfigviabaseRefs