微软发布针对 Azure Kubernetes Service 的智能体流量路由参考架构，核心思路是不将所有 LLM 调用都发给最强模型。通过三层路由分解，在保持约 95% 质量水平的前提下，仅将约 26% 的调用发送给前沿模型，最高可节省85% 推理成本。
智能体工作负载与聊天有本质区别。一个简单的"规划→行动→观察"循环，就可能触发几十甚至上百次 LLM 调用——填写工具参数、判断是或否、生成摘要、总结中间结果。这些调用中的绝大多数，并不需要 GPT-5 或 Claude Opus 级别的模型。
但问题更隐蔽：即便你愿意为每次调用付费，简单的轮询负载均衡器反而会让事情更糟。它可能让一次只生成 200 个 token 的请求，排在繁忙 GPU Pod 上一个 10 万 token 的预填充请求之后，而附近另一个空闲 Pod 却未被使用。
两个问题，一个答案。
轮询或随机分配，不感知 GPU 实时状态。强模型与弱模型流量无差别处理，缓存无法复用。
三层分解：语义判断→策略治理→GPU 感知放置。按需分配，成本与质量可调。
微软的方案并非针对聊天场景，而是专门为"循环内调用"的智能体工作负载设计。核心洞察：不是每次调用都值付前沿模型的价钱。
架构将路由问题分解为三个独立的选择：哪个模型响应、如何管理调用、由哪个 GPU 副本处理。每个层面由独立组件负责。
检查提示词，预测低成本模型能否达到强模型回答质量。基于人类偏好数据训练的矩阵分解路由器，是节省成本的核心决策层。
开源代理，管理身份验证、速率限制、成本跟踪与护栏策略。不检查提示词含义，专注策略执行。强模型路径由此转发至 Azure OpenAI。
通过 Endpoint Picker 查看 vLLM 的 KV 缓存占用率与队列深度，将请求分配给最合适的 GPU 副本。弱模型路径由 KAITO 按需提供节点池。
三个组件全部在 AKS 集群内运行。Azure 托管的 Prometheus + Grafana 统一抓取路由、成本与 GPU 指标，提供全局可观测性。
微软在 RouteLLM 测试的模型组合上给出了基准数字，但强调这些数字不会自动适用——它们与训练 RouteLLM 的模型组合强相关，不适用于 phi-4-mini / GPT-5.1 等新组合。
一个诚实的注脚：
提示词缓存会让成本计算变得复杂。缓存命中的输入 token 享有折扣，而切换模型会使两边的缓存都冷却。这意味着一次"强模型"调用的真实成本，低于表面上看到的单价。团队需要根据实际流量校准阈值，而不是直接套用 RouteLLM 的估算值。
校准方法：在 agentgateway 中观察强模型与弱模型的实际流量划分，结合缓存命中率，动态调整升级阈值。
微软在文档中给出了直白的警告：这里使用的组件还比较年轻。Inference Extension 在迈向 v1 的过程中重命名并重构了 CRD，字段名称在不同版本之间会发生变化。
例如，InferencePool 和 InferenceObjective 位于不同的 API 组中。对于不愿自行管理路由器的团队，微软 Foundry 模型路由器是 RouteLLM 语义层的托管版本，但截至目前，尚未提供 Endpoint Picker 的 GPU 感知放置功能的托管选项——无论使用哪个网关，它都必须在集群内运行。
但架构本身是稳定的。
团队不必一次性部署全部组件。微软给出了三个清晰的演进阶段：
智能体时代，推理成本优化的核心杠杆不是模型降价，而是路由智能。谁先建立"把对的请求发给对的模型"的系统工程能力，谁就能在成本与质量之间拿到最陡的边际收益。
微软官方文档中心已发布完整参考架构，包含组件部署清单、版本锁定说明与端到端验证流程。团队可参照分阶段路径逐步落地。
微软文档中心 → 搜索「AKS 智能体路由」