微软发布AI智能体路由方案：大模型成本直降85%的架构解析

type

status

date

slug

summary

为什么传统负载均衡不适合AI智能体？

与普通的单次问答聊天不同，AI智能体的工作流通常包含复杂的“规划—行动—观察”循环。在这样一个闭环中，单个任务可能会触发数百次 LLM（大模型）调用。

在这数百次调用中，大部分任务（例如提取结构化数据、填写工具参数、进行简单的判断或生成摘要）其实并不需要 openai 的 chatGPT 或 claude 等顶级前沿大模型来处理。如果将每一次调用都无脑地发送给最强的大模型，随着循环长度的增加，企业的 API 账单和系统延迟将会呈指数级增长。

此外，传统的轮询负载均衡器在面对大模型推理时显得力不从心。它无法感知请求的 Token 长度和 GPU 的实际负载，可能会将一个仅需生成 200 个 Token 的简单请求，排在一个包含 10 万 Token 预填充请求的繁忙 GPU 节点后面，而旁边空闲的 GPU 节点却处于闲置状态。这种不合理的调度极大降低了系统的整体吞吐量。

微软参考架构的核心三层设计

为了解决上述痛点，微软设计的架构将智能体流量路由问题拆解为三个核心层，并将其接入一个与 openai 兼容的统一端点：

语义路由层（RouteLLM）：这是成本控制的第一道防线。RouteLLM 会实时检查输入的提示词（Prompt），并预测较便宜的“弱模型”能否达到与“强模型”相近的回答质量。它采用了一个基于人类偏好数据训练的矩阵分解（MF）路由器，实现智能分流。

策略治理层（agentgateway）：这是一个开源的 AI 代理网关。它在不解析提示词具体语义的前提下，高效地管理身份验证、每个智能体的速率限制、详细的成本跟踪以及安全护栏策略。

GPU感知放置层（Gateway API Inference Extension）：该组件的 Endpoint Picker 会实时监控后端 GPU 的状态，包括 vLLM 的 KV 缓存占用率和请求队列深度。基于这些实时指标，它能精确决定由所选模型的哪一个 GPU 副本（Replica）来处理当前请求，从而彻底避免请求排队阻塞的问题。

在这套架构中，Kubernetes 上的 KAITO 工具负责按需提供 GPU 节点池并运行 vLLM，同时向 Endpoint Picker 提供关键的性能指标。强模型路径通过网关直通托管服务，而弱模型路径则路由到集群内自托管的轻量级模型。

85% 降本背后的关键逻辑与挑战

根据微软公布的数据，在 RouteLLM 测试的模型组合中，其矩阵分解路由器达到了顶级大模型约 95% 的质量水平，但仅将约 26% 的高难调用发送给强模型。相比于将所有流量全部路由到强模型的方案，该架构最高可节省 85% 的成本。

然而，这一数据并非开箱即用。微软在AI新闻发布中强调，这一降本比例与用于训练路由器的特定模型组合高度相关。在实际应用中，用户需要根据自己使用的模型组合（如特定的开源小模型与闭源大模型），利用真实流量数据来校准路由器的升级阈值，并结合网关收集的实际流量划分进行动态调整。

此外，提示词缓存（Prompt Caching）也是影响实际成本的重要变量。缓存命中的 Token 通常享有极高的折扣，而频繁在强弱模型之间切换会导致两边的缓存“冷却”（失效）。因此，在评估真实成本时，需要综合考虑缓存命中率对单次调用成本的影响。

渐进式落地：企业如何采用该架构？

微软指出，虽然这套架构功能强大，但企业无需一步到位，完全可以根据自身的业务阶段分步实施：

治理先行阶段：如果目前只在后台使用单个托管模型且请求量较小，可以仅部署 agentgateway，专注于安全治理、速率限制和成本监控。

自托管优化阶段：当企业开始自托管单一模型时，可以引入 KAITO 和 Inference Extension，利用其 GPU 感知放置功能提升集群吞吐量。

智能路由阶段：当强弱模型之间存在显著的价格差，且简单任务流量占比较高时，引入 RouteLLM 进行语义路由将带来巨大的经济效益。对于几乎所有循环运行的智能体系统来说，这一步都是实现AI变现和规模化盈利的关键。

目前，该参考架构中的部分开源组件更新频繁，企业在 AKS 上进行端到端验证时，应注意锁定组件版本，并根据最新的官方文档调整 CRD 字段。

想要获取更多关于大模型部署、Prompt 优化以及全球最新的 AI日报 动态，请持续关注 AIGC.bar，我们为您提供最专业、最及时的人工智能前沿技术解析。