文章摘要
微软针对智能体工作负载LLM调用成本高、资源浪费问题，推出Azure Kubernetes服务上AI智能体流量路由参考架构方案。该方案将路由问题拆成三环节，整合三大组件，通过多组件协作完成不同类型请求处理。测试显示其能节省成本，但升级阈值因模型组合而异。方案组件较新，版本迭代快，团队可按需分阶段采用。

智能体工作负载的LLM调用往往存在大量轻量请求，如果全部使用顶级高性能模型，会大幅提升成本和延迟，普通的轮询负载均衡器还会加剧资源浪费的问题。针对这个痛点，微软近日推出了针对Azure Kubernetes服务上AI智能体流量路由的参考架构方案。

这套设计将智能体的LLM调用路由问题拆解为三个核心环节：选择适配的模型、管理调用流程、分配合适的GPU副本处理请求。整个方案整合了三大组件：用于负载均衡的Kubernetes Gateway API Inference Extension、作为AI代理管理的agentgateway，以及负责语义路由的RouteLLM，三者共同对接兼容OpenAI标准的服务端点。

建议的架构按照信号维度拆分了整个路由问题：首先由RouteLLM对输入的提示词进行分析，预测使用成本更低的模型是否可以达到高性能模型的回答质量，它基于人类偏好数据训练的矩阵分解模型实现路由决策。

agentgateway是一款可以兼容OpenAI生态的开源代理工具，它负责处理身份验证、单智能体的速率限制、成本追踪以及安全护栏等策略类工作，在运行过程中不会对提示词的语义内容进行检查。

Gateway API Inference Extension的Endpoint Picker组件则会实时监控GPU的运行状态，包括vLLM的KV缓存占用率和请求队列深度，以此来决定由所选模型的哪个具体副本处理当前请求。对于自托管的部署场景，agentgateway可以通过ext-proc直接调用Endpoint Picker，无需额外的独立Gateway API网关，简化了整体架构。

KAITO可以按需提供GPU节点池并运行vLLM服务，它会暴露vllm:num_requests_waiting和vllm:kv_cache_usage_perc等关键指标，供Endpoint Picker使用。整个流量路径分为两类：强模型的请求会通过agentgateway中的AI后端对接Azure OpenAI；而轻量模型的请求则通过服务后端路由到由KAITO提供支持的Pod。这个后端会使用inferenceRouting策略，将请求定向到Endpoint Picker，并将destinationMode设置为passthrough模式。Azure托管的Prometheus和Grafana可以采集agentgateway的路由和成本指标，以及vLLM的GPU运行指标，形成统一的可观测视图。

这套方案的核心关键参数是RouteLLM的升级阈值。在测试的模型组合中，mf路由器可以达到GPT-4在MT-Bench上约95%的回答质量，仅需要将约26%的调用请求发送给GPT-4，相比将所有请求都路由到强模型的方案，最多可以节省85%的成本。微软提醒，这个比例并不是通用的，它和训练RouteLLM时使用的模型组合强相关，并不适用于phi-4-mini和GPT-5.1这类其他模型组合。因此用户需要根据自身的实际流量情况校准阈值，结合agentgateway中强模型和弱模型的实际流量占比进行调整，而非直接套用RouteLLM的默认估算结果。此外，提示词缓存会让token的实际成本变得复杂：缓存命中的输入token可以享受折扣，而切换模型会导致两侧的缓存都失效，这意味着一次“强模型”调用的真实成本会比表面上的计费金额更低。

方案的开发者提醒，文中提到的多个组件都处于较新的阶段，不同版本之间的字段名称可能会发生变化——比如Inference Extension在迈向v1正式版的过程中，对CRD进行了重命名和重构。所有的测试内容都是在2026年年中基于AKS集群完成的，使用的是Inference Extension v1.0.0和agentgateway v1.3.1的版本。用户在部署时应该将这些组件的版本固定，并且参考官方文档确认字段参数。整体的架构分解思路是稳定的，但具体的标志和CRD字段会快速迭代变化。例如，InferencePool和InferenceObjective位于不同的API组中。

三大开源组件都可以直接在AKS集群内运行，而KAITO服务、Azure OpenAI以及Prometheus和Grafana的可观测性栈则由Azure托管。微软还提到，其Foundry模型路由器是RouteLLM语义层的托管版本，可以帮助那些不愿意自行管理路由组件的团队。不过目前Endpoint Picker的GPU感知调度功能还没有托管选项，无论使用哪种网关，都需要在集群内部署运行。

团队可以根据自身需求分阶段采用这套架构，无需一次性部署全部组件。比如当仅使用单个托管模型来支撑少量智能体时，只需要使用agentgateway进行治理即可，此时没有其他模型可供路由，也不需要针对GPU进行调度。如果是自托管单一模型的场景，可以借助KAITO和Inference Extension来提升效率，但不需要语义路由层，因为只有一种模型可选。当强模型和弱模型之间存在明显的价格差异，且存在大量轻量请求流量时，加入RouteLLM语义路由层就非常有价值，微软认为这几乎适用于所有循环运行的智能体场景。

以上内容不代表本平台立场，仅供读者参考