本文基于 InfoQ 中文(作者 Steef-Jan Wiggers,2026-09-06)对 Azure AI Foundry 模型路由更新的公开报道整理与二次分析,加入 LoopRouter 在多模型接入、成本治理与路由策略上的视角;原文见文末链接。文中型号、区域数与配置行为沿用来源设定,具体数值建议以你所在区域的最新官方文档复核。
一句话结论:微软把 Foundry 模型路由从 2 个区域扩到 28 个,还塞进了 Claude Opus 4.8 和 GPT-5.6,看起来是「开箱即用的智能路由」。但真正决定它值不值得接的,是三个官方通稿一笔带过的细节——路由池的上下文窗口会被最小的那个模型拉低、路由器会对你的输入 prompt 额外计费、而且微软没给任何质量/成本/延迟的对比数据。接入前不把这三点验证清楚,省下的成本可能被隐性开销吃回去。
这次更新到底改了什么:从 2 区到 28 区
模型路由(model router)不是新概念——给它一个统一端点,它按请求自动挑一个「性价比合适」的底层模型。这次 Foundry 的更新主要是可用性和模型池的扩容:
| 维度 | 更新前 | 更新后 |
|---|---|---|
| Global Standard 区域 | 2 个(East US 2、Sweden Central) | 28 个 |
| Data Zone 区域 | — | 21 个 |
| 新增模型 | — | Claude Opus 4.8、GPT-5.6 系列 |
| 下线模型(EOL) | — | gpt-5-chat、gpt-5.2-chat、gpt-5.3-chat、DeepSeek-V3.1 |
配置行为上有个容易忽略的差异:
- 用默认配置的团队:模型池自动更新,不需要重新部署,端点保持稳定;
- 用子集配置(subset)的团队:不会自动更新,新模型除非你手动加进去,否则不会进池;
- 无论哪种,切换路由模式或改子集配置最多要 5 分钟生效。
Balanced / Quality / Cost:三种模式对应三种业务
Foundry 路由提供三种模式,本质是把「质量-成本」这根滑杆交给你按场景定档:
- Balanced(默认):在保证质量的前提下优化成本。通用聊天、内容生成这类没有极端要求的场景用它。
- Quality:优先质量。官方点名的场景是法律审阅、医疗摘要、复杂推理——这些任务一次答错的代价,远高于多花的那点 token 钱。
- Cost:优先成本。适合高吞吐分类、简单问答这类量大、单条难度低的请求。
选型逻辑很清晰:按「答错的代价」而不是「请求的数量」来分档。高频不等于该省,低频不等于该贵——真正该上 Quality 的,是那些错误会传导到业务结果的环节。
三个通稿一笔带过、但会咬人的细节
这才是接入前最该盯的部分。官方文档把它们写得很轻,实际影响却不小:
1. 上下文窗口按「池内最小」取值
路由池的有效上下文窗口 = 池里所有模型中最小的那个。也就是说,你往池里加了一个窗口较小的模型,整个路由端点对所有请求的上下文上限都会被这个短板拉低。想靠加模型来「丰富选择」,结果可能是把长文档场景的能力一起削掉了。加模型前,先核对每个候选的窗口。
2. 路由器对自己的输入 prompt 单独计费
路由器要读你的输入才能决定走哪个模型,所以除了被选中模型的推理费,路由器还会对它处理的那段输入 prompt 再收一次费。这层「路由税」在高频短请求场景下占比可能不低。算账时别只按目标模型单价估——要把路由器这一层加进去。
3. 选路只看文本,音频不支持
路由决策只基于文本:图片可以传但不参与选路判断,音频直接不支持。多模态场景要清楚,它路由的依据是文本部分,不是整个 payload。
4. 接 Claude 有前置条件
想让池里包含 Claude,必须先在同一个 Foundry 账户下按匹配的 SKU 单独部署好 Claude 模型,否则会直接报 InvalidResourceProperties 错误。跨供应商不是「勾选即用」,底层要先各自落地。
微软没给一个数,却给了一把尺子
值得注意的是,整份公告里没有任何质量指标、成本对比或延迟开销数据——没有说路由比单模型省多少、也没有说路由本身增加多少延迟。微软自己的建议是:上线前先自己跑基准,并为此开源了评测管线 github.com/microsoft/foundry-model-router-autoeval,能在一次运行里同时测质量、成本和延迟,还带「路由感知」的成本计算。
配合文中两句话看会更清醒:
- 「API 稳定性和行为稳定性是两码事」;
- 「响应模式可能保持不变,但应用程序的业务结果可能会发生变化」。
翻译成人话:端点没变、返回格式没变,不代表你的业务效果没变。路由把「今天走哪个模型」这件事交给了平台,模型池一更新,同样的请求可能落到不同模型上,输出质量随之漂移。可审计性上,好在每次响应的 model 字段会返回实际被选中的模型,便于回溯和监控——这是接入后必须接进日志的一个字段。
对企业多模型接入意味着什么
托管路由(Foundry、Azure API Management 的 AI Gateway tier 等)降低了「用起来」的门槛,但也把关键决策权交给了单一云平台:模型池、生效延迟、计费口径、窗口取值规则,都由平台定义。从 LoopRouter 的接入与成本治理视角,有几点通用建议,不限于用哪家路由:
- 路由策略要对齐「错误代价」,不是请求量:高频低难度走成本档,低频高代价走质量档,别用一个默认档打天下。
- 把隐性成本算进 TCO:路由器自身计费、窗口被最小模型拉低导致的降级或分块开销,都要计入,而不是只看目标模型单价。
- 上线前必须自测基准:官方不给对比数据时,用自己的真实任务集复测质量/成本/延迟,别拿通用榜单当验收标准。
- 保留可审计性与可迁移性:把每次请求实际命中的模型记进日志;同时评估是否要被单一云的 SKU 和部署前置条件绑死——跨供应商、可自定义策略的统一接入层,能在「省成本」和「不被锁定」之间留出余地。
说到底,模型路由的价值不在「自动帮你选」,而在你能不能看清它为什么这么选、并按自己的业务规则去调。把上面这几点验证清楚,再决定要不要把路由权交出去。
来源:InfoQ 中文《微软 Foundry 模型路由扩容:覆盖区域增至 28 个,更新模型池》(作者 Steef-Jan Wiggers,2026-09-06)——https://www.infoq.cn/article/ba7Tq1EZbAD6JEzG16uE