微软发布了一款参考架构，专门用于在 Azure Kubernetes 服务（AKS）上路由智能体（Agent）流量。该架构将智能体调用路由问题拆解为三个关键决策：由哪个模型响应调用、如何管理调用、以及由哪个 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% 的成本。不过微软特别提醒，这一数字并不自动适用于所有场景：它与用于训练 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 的一个替代选项。
热门跟贴