这类问题我又碰上了一次。路由配置里把模型写成 gpt-4.1-2025-04-14 这种快照名，供应商下架该快照后请求依旧成功，只是被静默指到旧版本，一周后才从回答风格上发现不对。
第一反应是「新版本只在部分区域上线，路由没做可用性探测」，验证下来不成立。
原因不止一个，得分开看。路由表用快照名而不是会跟随的别名；网关把旧的模型映射缓存了 24 小时没有失效；发布脚本读的是另一份配置，改的文件根本没被加载。
动手时先打印进程里实际生效的模型映射
python -c "import json;print(json.load(open('route.json'))['models'])"然后查供应商当前可用的别名与快照
curl -s https://api.openai.com/v1/models -H "Authorization: Bearer $KEY" | jq -r '.data[].id' | grep 4.1接着把路由键统一改成别名后预演重载
python reload_route.py --config route.json --dry-run剩下的就是用探针请求确认真正落到了哪个版本
curl -s https://api.openai.com/v1/chat/completions -H "Authorization: Bearer $KEY" -d '{"model":"gpt-4.1","messages":[{"role":"user","content":"version?"}]}' | jq -r '.model'恢复的判定其实很直接。响应体里的 model 字段与别名解析出的最新快照一致，路由表里不再出现硬编码日期，探针连续三次都命中新版本。
容易忽略的是，别名会漂移，快照会下架，两条路都有代价；关键业务用快照加可用性探测，通用场景用别名并固定回归节奏。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。