微软 Foundry 模型路由扩容：覆盖区域增至 28 个，更新模型池
微软最近对 Foundry Models 中的模型路由器进行了扩容：面向全球标准部署的可用区域由 2 个扩充至 28 个，面向数据区域部署的可用区域扩充至 21 个，并更新了其可选用的模型池。在此版本发布之前，该路由器仅在 East US 2 和 Sweden Central 可用。
模型池新增了 Anthropic Claude Opus 4.8 和 GPT-5.6 系列，并移除了 gpt-5-chat、gpt-5.2-chat、gpt-5.3-chat 和 DeepSeek-V3.1，因为这些模型已到达生命周期终点。使用默认配置的团队无需重新部署即可自动生效本次变更。配置了模型子集的团队则不会自动更新。
这种区分很重要，因为公告和文档对此的描述有所不同。
Sanjeev Jagtap 在宣布此次更新时，将自动交付作为发布的重点：
最重要的一点在于你无需执行任何操作：本次更新会自动完成。在支持的模型池完成刷新的过程中，接口端点保持稳定，团队无需重新部署模型路由服务即可获取本次更新。
Azure MVP 兼云工程师 Christos Panagiotidis 指出了公告中隐含未说明的一个区别：
API 稳定性和行为稳定性是两码事。
模型池中的新模型可能会改变回答风格、工具选择行为、结构化输出可靠性、延迟分布、Token 使用量、拒绝行为和故障模式。正如他所说：
响应模式可能保持不变，但应用程序的业务结果可能会发生变化。
对于默认部署，Jagtap 的说法是成立的。模型路由器以 Balanced 模式部署，在全部受支持的模型上进行路由，除非另有指定，因此使用默认配置的工作负载现在有两个从未评估过的候选模型，而四个可能一直在使用的模型已经消失，且无需重新部署或版本升级。
官方文档介绍了公告中并未提及的规避方案。团队可以将路由限制为选定的模型子集；在这种配置下，后续新增的模型默认会被排除，只有显式添加后才会纳入可用范围。对模型池做过约束的团队恰好不会受到这篇博客所推崇的模型池刷新的影响。本次更新属于默认开启（可选择退出），而这个退出开关绝大多数团队都不会去修改。
模型路由共有三种工作模式，公告中并未提及。均衡（Balanced）模式在保障质量的同时优化成本，为默认模式。质量优先（Quality）模式面向法律审查、医疗摘要、复杂推理这类关键业务。成本优先（Cost）模式适用于高吞吐量分类以及简单问答场景。修改路由模式或模型子集配置最多需要五分钟生效。
今年早些时候发布的一项约束值得得到更多关注，因为不断变化的模型池使其成为一个动态而非固定的限制。微软声明，有效上下文窗口等于底层模型中最小的窗口，过大的提示词只有在路由器恰好选择了一个能够处理它的模型时才能正常执行。因此，向模型池中添加一个上下文窗口更小的模型会降低所有经由该路由转发请求的上下文上限。
官方说明中还提到另外两项限制。路由决策仅基于文本，因此虽然可以接收视觉输入，但图片并不会影响模型的选择，音频则不受支持。此外，路由器会对其自身的输入提示词计费，叠加在底层模型的成本上，这意味着任何成本节省的宣传背后都包含这部分额外加价。
Anthropic 模型有一个前提条件，在公告中以脚注的形式呈现，在文档中则作为故障排除条目提及。Claude 模型必须先在同一个 Foundry 账户中使用匹配的 SKU 单独部署，路由器才能选择它们，如果在子集中引用它们而没有部署，则会失败并返回 InvalidResourceProperties 错误。Claude Opus 4.8 被加入受支持清单并不意味着可以直接使用。
微软从合规角度阐述本次区域扩容，指出推理请求必须留在特定的地理边界内，以满足监管、治理或客户信任的要求。从两个区域扩展到 28 个，对有数据驻留义务的团队而言，实际可落地的方案变多了。但相关材料并未说明当候选模型在该地理边界内不可用时，数据区域约束与模型池选择之间会如何交互。
模型路由器遵循内置的 Azure Policy for Foundry 策略，在部署时通过门户、REST API、CLI 和 ARM 模板强制执行，这意味着允许使用的发布者列表需要包含微软以及模型池中每一个模型对应的发布者。这是部署阶段的治理，这就留下了一个悬而未决的问题，与微软最近为 Azure API Management 推出的 AI Gateway 层并存，后者在运行时策略前展示模型，并控制工作负载可以访问哪些模型。当两者同时部署时，公开文档并未说明二者该如何协同工作。
公告中没有包含任何实测数据：没有准确率指标、没有对比单模型基准的成本数据，也没有模型选择环节带来的延迟开销。微软给出的建议是，将初次部署视作初始配置，在接入生产流量之前完成基准测试，同时微软发布了一个开源评估管道，可以在一次运行中测量质量、成本和延迟，包括路由器感知的成本计算和报告路由器实际访问的底层模型。
每个响应都会在 model 字段中返回本次选中的模型名称，因此决策在事后是可审计追溯的。
对于平台团队而言，此次发布使模型选择成为平台可以在运行时做出的决策，而默认配置接受模型池发生变更。Panagiotidis 提出了对应的工程规范：将模型池刷新视作一次托管依赖更新，记录每一条评估请求实际选中的模型，与上一周期的数据做对比，并在更新带来不可接受的业务结果时能够限制模型池。
查看英文原文：https://www.infoq.com/news/2026/08/foundry-model-router-regions/