最高节省 85% 成本：微软公布 AI 智能体 LLM 路由方案

作者 | Claudio Masolo

译者 | 田橙

Microsoft 发布了 一个用于在 Azure Kubernetes 服务 上路由智能体流量的参考架构。它将这个问题分解为三个关键选择：由哪个模型响应调用、如何管理调用，以及由哪个 GPU 副本处理调用。该设计结合了用于负载均衡的 Kubernetes Gateway API Inference Extension、作为 AI 代理的 agentgateway，以及用于语义路由的 RouteLLM。这三者共同接入一个与 OpenAI 兼容的端点。

其动机专门针对智能体工作负载，而非聊天。单个智能体任务可以在“规划—行动—观察”循环中发起数百次 LLM 调用，而其中大多数调用（填写工具参数、判断是或否、生成摘要）并不需要前沿模型。将每次调用都发送给顶级模型，会随着循环长度增加成本和延迟。简单的轮询负载均衡器甚至会让情况变得更糟。它可能会让一次生成 200 个 token 的请求排在繁忙 GPU Pod 上一个包含 10 万个 token 的预填充请求之后，而附近另一个空闲 Pod 却未被使用。

路由智能体流量

建议的架构完全按照信号来划分问题。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 的升级阈值。在 RouteLLM 测试的模型组合上，mf 路由器达到了 GPT-4 在 MT-Bench 上约 95% 的质量水平。它只将约 26% 的调用发送给 GPT-4，与将所有调用都路由到强模型相比，最多可节省 85% 的成本。Microsoft 表示，这个数字并不会自动适用。它与用于训练 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 管理。Microsoft 指出，其 Foundry 模型路由器是 RouteLLM 语义层的托管版本。这有助于那些不愿自行管理路由器的团队。不过，目前还没有针对 Endpoint Picker 的 GPU 感知放置功能的托管选项。无论使用哪个网关，它都必须在集群内运行。

团队可以分阶段采用该架构，而不必一次性部署全部组件。对于少量智能体背后的单个托管模型，主要需要使用 agentgateway 进行治理，因为既没有其他模型可供路由，也没有 GPU 需要进行放置。自托管单一模型类别可以受益于 KAITO 和 Inference Extension，而不需要任何语义路由层，因为只有一个模型可供选择。当强模型与弱模型之间存在明显的价格差距，并且有相当多的简单流量时，就值得加入 RouteLLM。文章认为，这几乎适用于所有循环运行的智能体。

https://www.infoq.com/news/2026/07/microsoft-agents-aks-routing/

会议推荐

2026 年 AICon 人工智能开发与应用大会 · 深圳站将于 8 月 21 日—22 日举办，聚焦 AI 基础设施、大模型系统、智能体工程、数据智能、多模态技术与行业落地等关键方向，邀请来自腾讯、阿里、华为、百度、蚂蚁集团等 50 + 头部科技企业技术负责人、科研机构一线专家，系统性分享前沿洞察与实战干货，共同探讨 AI 技术从能力到系统、从实验到生产的真实路径。限时 9 折专属优惠，现在报名立减 580，更多详情可扫码或联系票务经理 13269078023 进行咨询。

今日荐文

你也「在看」吗？