Microsoft 正在扩大 Foundry Model Router 的覆盖范围：全球标准部署从两个区域扩展到 28 个区域，数据区域部署覆盖 21 个区域。同时，模型池加入 Claude Opus 4.8 和 GPT-5.6，并移除四个已弃用模型。对使用默认模型池的团队来说，这些变化会自动生效；但如果部署配置了模型子集，新模型不会自动加入。
这次更新的关键不只是“可用区域变多了”。模型池发生变化后，路由结果、上下文窗口和成本表现都可能随之改变，应用需要把模型池当成一个会演进的运行时依赖来管理。
覆盖范围扩大，部署形态仍然不同
目前需要区分两类部署范围：
- 全球标准部署覆盖 28 个区域。
- 数据区域部署覆盖 21 个区域。
区域覆盖扩大后，跨区域可用性和故障转移空间更大，但数据驻留要求不会因此消失。对受监管业务，应该继续根据数据处理边界选择数据区域部署，而不能只根据区域数量做决定。
可以这样检查团队当前的部署策略：
- 确认业务是否允许请求在多个区域之间路由。
- 确认提示词、用户输入和模型输出的驻留要求。
- 检查应用是否把区域、模型名称或部署 ID 写死在代码中。
- 为模型池变化准备监控和回归测试。
模型池更新会改变运行时行为
模型路由器会从模型池中选择模型。默认部署会自动接收模型池变更，因此 Claude Opus 4.8 和 GPT-5.6 会在符合条件时进入可选范围，四个已弃用模型则会被移除。
如果团队配置了模型子集，行为不同：新模型不会自动加入，只有显式把它们加入配置后，路由器才会使用它们。这种方式更适合对输出稳定性、合规范围或成本上限有严格要求的生产服务，但也意味着团队需要主动维护配置。
另一个容易被忽略的限制是：有效上下文窗口等于模型池中上下文窗口最小的那个模型。例如，一个池里同时放入长上下文模型和短上下文模型，路由器对外提供的有效上下文能力会受最小值限制。应用不能只查看其中一个模型的最大上下文长度来设计请求。
这会直接影响以下功能：
- 长文档总结和检索增强生成。
- 多轮对话历史保留。
- 工具调用结果回传。
- 大型结构化输入，例如日志、代码或 JSON 文档。
一个可维护的模型池配置示例
下面的 YAML 是一个实践示例，用于表达“固定模型子集、明确上下文上限、保留区域策略”的配置思路。实际字段名请以团队使用的 Foundry 管理界面或 API schema 为准。
# model-router.example.yaml
router:
name: support-router-prod
deployment_mode: data_zone
allowed_regions:
- eastus
- westeurope
# 配置子集意味着新模型不会自动加入，需要显式维护
model_pool:
- name: gpt-5.6
max_context_tokens: 128000
- name: claude-opus-4.8
max_context_tokens: 200000
# 按模型池最小值设置应用侧保护阈值
effective_context_tokens: 128000
max_output_tokens: 4096
policy:
allow_automatic_pool_updates: false
require_region_residency: true
可以在 CI 中增加一个简单的配置检查，避免模型池的最小上下文能力低于应用假设：
#!/usr/bin/env bash
set -euo pipefail
CONFIG="${1:-model-router.example.yaml}"
EXPECTED_MIN_CONTEXT="${EXPECTED_MIN_CONTEXT:-128000}"
actual_min_context="$({
yq '.router.model_pool[].max_context_tokens' "$CONFIG" \
| sort -n \
| head -n 1
})"
if [[ -z "$actual_min_context" ]]; then
echo "model pool is empty: $CONFIG" >&2
exit 1
fi
if (( actual_min_context < EXPECTED_MIN_CONTEXT )); then
echo "context window regression: ${actual_min_context} < ${EXPECTED_MIN_CONTEXT}" >&2
exit 1
fi
echo "model pool check passed: effective context = $actual_min_context"
运行前需要安装能够解析 YAML 的 yq，并把 EXPECTED_MIN_CONTEXT 调整为应用真正依赖的阈值。这个检查不能替代 Foundry 的服务端校验，但可以尽早发现配置更新导致的上下文能力下降。
默认池还是固定子集
两种策略各有适用场景。
默认模型池适合希望自动获得新模型和平台维护的团队。它减少了人工配置工作，但模型选择可能发生变化，必须接受输出风格、延迟、价格或工具调用行为的潜在变化。对于这类部署，建议持续记录路由到的模型，并对关键任务运行离线评测。
固定模型子集适合需要更强可重复性的生产服务，例如合同抽取、财务分类或严格审计场景。代价是新模型不会自动获得，弃用模型也可能要求团队主动调整配置。模型池更新后，应明确执行以下动作：
- 查看新模型是否满足区域和合规要求。
- 对 Claude Opus 4.8、GPT-5.6 等新模型进行小流量测试。
- 重新确认有效上下文窗口和输出上限。
- 更新成本、延迟、准确率和安全性基线。
- 对已弃用模型准备替代和回滚方案。
落地检查清单
Foundry Model Router 从有限区域扩展到更广的全球标准和数据区域范围，降低了区域可用性限制；模型池刷新则让部署配置的生命周期管理变得更重要。
上线前可以按这份清单检查：
- [ ] 选择全球标准或数据区域部署，并记录理由。
- [ ] 确认默认模型池是否符合数据驻留和合规要求。
- [ ] 如果使用固定子集，显式评估并加入需要的新模型。
- [ ] 按模型池最小上下文窗口限制请求大小。
- [ ] 记录模型路由结果、延迟、错误率和成本。
- [ ] 为模型移除和新模型加入建立回归测试。
- [ ] 给自动更新和固定子集分别制定运维流程。
把模型路由器当作一个动态依赖来管理，应用才能在获得新模型能力的同时，控制区域、上下文和输出稳定性带来的风险。