导读2026 年 7 月，微软给出了一套在 AKS 上路由 Agent 请求的参考架构。它最值得拿出来复盘的，不是“最多节省 85%”这个数字，而是一个很容易被混淆的拆分：模型选择、请求治理和 GPU 副本放置，分别解决不同的问题。对准备把多模型 Agent 推进生产环境的团队来说，先分清这三层，才能知道该补的是预算护栏、模型策略，还是拥塞中的推理调度。
一条 Agent 请求，至少有三道不同的选择题
“给 Agent 加个模型路由”这句话，听起来像是给请求找一个更便宜的模型。
但一个真实的 Agent 任务不是一次聊天。它会计划、调工具、读取结果、再决定下一步；同一任务里既有需要复杂推理的调用，也有抽取参数、判断状态、压缩上下文这类相对简单的调用。请求从 Agent 发出以后，至少会遇到三道不同的选择题。
第一道是：这次调用该由哪个模型回答？这才是通常所说的语义路由。它要根据提示词和任务的难度，判断弱模型是否已经足够，还是需要升级到强模型。
第二道是：谁有资格调用、最多花多少、哪些输入不能放行？这是治理。身份、限流、预算、审计、护栏，都不是“哪个模型更聪明”能够回答的问题。
第三道是：模型已经选好了，究竟送到哪个正在运行的副本？如果模型部署在多个 GPU Pod 上，这是一道运行时调度题：一个副本可能正在做很长的预填充，另一个却很空闲；简单轮询并不知道 KV Cache、排队深度和前缀缓存的差别。
微软 7 月公开的 AKS 参考架构，把这三题分别交给 RouteLLM、agentgateway 和 Kubernetes Gateway API Inference Extension 来处理。它未必是每个团队都该照搬的技术栈，但这个拆分本身很有价值：语义、组织策略和机器实时状态，是三种不同的信号。
把它们混在一个“智能网关”里，短期配置看起来省事，长期却很难回答三个基本问题：为什么这次升级了强模型？是谁让一个 Agent 把预算用完？为什么明明有空闲 GPU，请求还在等？
第一层：模型选择是在赌“弱模型够不够”
RouteLLM 做的是最容易被看见的一层。它尝试判断一个请求是否可以交给较弱、较便宜的模型；若不够，再交给较强模型。这里的输入是提示词或请求本身，输出是模型选择。
它的关键不是“有两个模型”，而是阈值。阈值越激进，越多请求会被送往弱模型，账面成本可能下降，但质量风险也会变大。RouteLLM 的公开材料给过“最高节省 85% 成本，同时保留 95% GPT-4 的 MT-Bench 表现”这一结果。这个数字很容易被截成一句营销文案，但它来自特定模型对、特定基准和特定阈值，并不是任何强弱模型组合的默认收益。
RouteLLM 自己的文档反而说得很直接：阈值应该用与实际入站请求相近的样本校准。原因并不神秘。你的 Agent 如果大部分请求是结构化抽取和工具参数填写，弱模型可能确实覆盖很高比例；如果每一步都要读长上下文、做代码修改或处理高风险决策，升级比例会完全不同。
所以这层应该回答的是：在可接受的失败率下，哪些任务可以降级？
它不应该替你回答“这个调用者有没有权限”，也不能回答“哪张 GPU 现在最适合跑它”。前者需要组织和业务上下文，后者需要实时遥测。把所有成本问题都压给语义路由，还会漏掉一个现实：即使模型没选错，重试、长输出、缓存失效和工具循环也会让单次任务的总成本失控。
第二层：治理不是为了挑模型，而是为了管住请求
模型选定之后，请求仍然需要一个管控点。agentgateway 这类 AI 网关可以把调用者身份、用量、模型价格目录和预算规则放到统一路径上；它公开支持按 key、团队、模型或提供商查看成本，并设置 token 或金额预算上限。
这层的价值，不是替模型评分，而是让系统有能力说清楚：
哪个 Agent、团队或工具在消耗资源；
某个循环是否该被限流或截断；
预算越界时，团队预先规定是拒绝、降级，还是告警；
不同模型和后端的调用，能否在同一个身份与审计口径下追踪。
这也是为什么单一托管模型的团队，往往先需要治理，未必先需要语义路由。没有第二个模型可选时，RouteLLM 没有发挥空间；没有自托管 GPU 副本时，也没有副本放置问题。但只要多个 Agent 共用一个昂贵模型，限流、身份归因和预算已经是生产问题。
还有一个容易混淆的边界：网关记录到的模型调用成本，不等于业务任务的最终价值。一个模型调用便宜，可能因为它答得不够好而触发更多重试；一个调用贵，也可能因为复用了缓存或一次完成而更划算。因此治理层应当把请求成本和任务结果关联起来观察，而不是只追一条“每 token 更便宜”的曲线。
第三层：GPU 放置关心的不是提示词，而是此刻谁不堵
不管模型选择与治理在你的系统里谁先执行，一旦某个自托管模型已经成为目标，剩下的麻烦就落到推理服务上。
多个 vLLM 副本并不等价于多个普通 Web 服务实例。一个副本可能正在为超长上下文做预填充（prefill），另一个副本可能保留着与当前请求相同系统提示词的前缀缓存。把请求随机或轮流分发，容易让短请求排在长请求后面，也会错过已经暖起来的缓存。
Microsoft 当前的 Inference gateway 文档把 InferencePool 和普通 Kubernetes Service 明确分开：前者对应一组模型服务 Pod，并调用 Endpoint Picker（EPP）选择具体端点。EPP 可以根据队列深度、KV Cache 利用率和前缀缓存亲和性对候选副本打分；若启用了相应能力，还可以让共享提示词前缀的请求更倾向去同一个副本，以提高缓存命中并降低首 token 等待时间。
这里的输入不是“这段提示词难不难”，而是运行时的队列、缓存和副本状态。它解决的是：已经选对模型之后，怎么别把请求排错队。
这层也有明确边界。Microsoft 文档把 Application Gateway for Containers 的 inference gateway 标为预览功能，并提醒 Inference Extension 会独立演进。也就是说，三层职责可以借鉴，具体 CRD、字段名和部署清单不能当成长期不变的配方。要上线，仍要以自己集群里的版本、失败策略和压测数据为准。
不是每个 Agent 都需要三层：按缺的能力补
这套拆分最实用的地方，是它不要求一次性引入三个组件。可以沿着一条请求路径，判断当前真正的瓶颈在哪里。
场景一：少量 Agent 调一个托管模型。
优先补治理层。统一身份、限流、预算和审计，比再造一个“模型路由器”更紧急。既没有模型选择，也没有 GPU 放置，过早引入两层只会增加排障面。
场景二：自托管一个模型，但有多个 GPU 副本。
先看运行时调度。此时没有强弱模型可选，语义路由仍然不是重点；但如果请求长度差异很大、并发上来后尾延迟明显，队列和缓存感知的副本选择可能比普通轮询更有意义。
场景三：强弱模型并存，Agent 里确实有大量简单调用。
再加入语义路由。前提不是“便宜模型存在”，而是你能拿出一批有代表性的真实请求，定义什么叫合格结果，并量出不同阈值下的升级比例、质量损失和任务完成成本。
场景四：三种问题同时出现。
这时三层才形成完整的协作：模型选择给出目标模型，治理层决定谁能调用、如何归因，运行时调度再在目标模型的副本中挑选端点。它们可以经过同一个 OpenAI 兼容入口，组件的先后和部署位置也可以不同，但不应该共享同一个模糊的“路由成功”指标。
相关资料
RouteLLM 项目与阈值校准说明： https://github.com/lm-sys/RouteLLM
Microsoft Inference gateway 文档（含 InferencePool 与 EPP）： https://learn.microsoft.com/en-us/azure/application-gateway/for-containers/inference-gateway
agentgateway 成本控制文档： https://agentgateway.dev/docs/standalone/latest/documentation/llm/cost-controls/
真正该统一的，不是组件，而是验证口径
三层拆开后，最容易犯的另一个错误是给每层各自挑一个漂亮指标：语义路由看弱模型比例，网关看 token 成本，EPP 看 GPU 利用率。它们都可能变好，却不代表用户任务变好了。
更可靠的做法是，用同一批真实 Agent 任务贯穿验证：完成率是否下降；失败时是否增加重试；每个合格结果花了多少钱；高峰时首 token 和完成延迟是否仍在目标范围内；预算或限流触发后，系统是否按预期降级而不是悄悄失败。
这套口径并不要求一开始就有很复杂的评测平台。哪怕先挑出几十条代表性的任务回放，也比拿一个通用基准直接推导生产节省更可靠。RouteLLM 的基准结果、网关的成本报表和 EPP 的 GPU 指标，在这里各自才有了正确的位置：它们是诊断同一个任务结果的不同观测面。
所以，微软这套架构真正值得借走的，不是三个组件名字，而是一个更朴素的工程判断：选模型、管请求、排 GPU，是同一条调用上的三类决策；把每件事交给能看见相应信号的那一层，才有可能把 Agent 从“能跑”带到“跑得住”。
参考资料
Microsoft Three-Layer LLM Routing Architecture for AI Agents on AKS： https://www.infoq.com/news/2026/07/microsoft-agents-aks-routing/
RouteLLM： https://github.com/lm-sys/RouteLLM
Application Gateway for Containers - Inference gateway： https://learn.microsoft.com/en-us/azure/application-gateway/for-containers/inference-gateway
agentgateway Cost controls： https://agentgateway.dev/docs/standalone/latest/documentation/llm/cost-controls/
— THE END —
文章仅做学术分享，如有侵权请联系删除，非常感谢！