区域模型发布的“彩票”效应:当你的产品在不同大洲表现各异时
周五下午,一封客户成功(customer-success)邮件发了过来:“德国用户的模型效果变差了。”团队打开评估仪表板,评分没变,p95 延迟也很正常。配置中的模型名称还是三周前发布的那一个。一切都没变。但其实有些东西变了。上个迭代中,美国的端点悄悄上线了新一代模型,而欧洲的端点由于供应商还没完成地区性的分阶段发布,仍在使用旧版本。而位于两者之前的负载均衡器,则在团队的所有仪表板上掩盖了这一差异。
这就是所谓的区域性模型发布博弈。你的“单一模型”抽象并不是单一的。当供应商跨大洲分阶段发布时,它就开始分化了——而在大多数年份、对大多数供应商而言,这种情况在大多数时间里都在发生。当这种情况发生时,客户端 SDK 中的版本字符串并不会改变。你的追踪(traces)看起来一模一样。你与供应商签订的合同也没有做出其他承诺。而你赖以捕捉行为回归的评估套件,几乎肯定运行在某个地区的 CI 机器上,并访问地理位置最近的端点。
这种失败模式不是模型 Bug。这种失败模式是你从未写下来的拓扑假设:你的客户端按名称引用的模型在所有提供服务的地方行为都是一致的。当模型还是你下载的产物时,这个假设是合理的。但当模型成为由供应商按区域分阶段发布的在线服务时,这个假设在结构上就是错误的,因为供应商的发布计划是基于运营的,而非基于合同的。
为什么供应商要交错发布(以及为什么这永远不会停止)
主要供应商不会一键同步全球更新。他们做不到——容量是按区域分配的,硬件更新在不同数据中心的时间线也各不相同,而且尖端模型全球切换的流量风险是无限大的。因此,发布是按功能等级交错进行的。视觉能力先在某个区域落地,结构化输出模式则在另一个区域上线。最新的模型代次进入美国东部(US East)要早于欧洲西部(EU West),因为美国东部的集群拥有最新的 GPU SKU,而欧洲的发布还在等待硬件迁移完成。这些都不是秘密,这是每一家超大规模云厂商模型市场的运营现状。
过去两年发生的变化是,这种交错发布已从“云文档中不起眼的脚注”变成了“你的产品所依赖的关键假设”。AWS Bedrock 现在区分了区域内推理、地理跨区域推理和全球跨区域推理,每种都有不同的模型可用性矩阵,并明确指出某些推理配置文件会根据调用的源区域路由到不同的目标区域。Azure 提供涵盖特定区 域子集的“数据区”(Data Zones),用于受驻留管理的部署,并推荐像瑞典中部或美国东部 2 区这样的特定区域以获得“广泛的模型可用性”——这种措辞委婉地承认了其他区域的可用性较窄。超大规模云厂商并没有隐藏这些信息。他们只是没有宣传这对于你的产品意味着什么,因为那是你的问题。
发布计划也不是固定不变的。新区域不断被加入——Claude 模型的向中东跨区域推理、向日本和澳大利亚的 Sonnet 和 Haiku 跨区域推理、欧洲数据区的扩展、面向欧洲驻留的瑞士路由处理——每一项都为你的拓扑结构增加了另一种排列组合。一个团队在第一季度编写的描述“我们为欧洲客户使用 eu-west 端点”的部署文档,到第四季度,其关于该区域的假设可能已经过时,因为该区域的模型可用性已与文档编写时完全不同。
评估套件存在地理偏差,而你并未察觉
区域性差异最阴险的症状是,即便底层行为已经产生分歧,你的评估分数看起来依然良好。原因如下:你的 CI 运行器位于某处——几乎肯定与你工程团队的主要基础设施运行在同一个云区域。当评估套件访问模型端点时,供应商的负载均衡器会将请求路由到最近的健康区域。如果你的 CI 在 us-east-1 且该区域拥有新模型,那么评估套件测量的就是新模型。而客服团队反馈的德国用户被路由到了 eu-west-1,使用的是上一代模型。评估分数只是对一个特定端点的测量,却被呈现为对“模型”的测量。
针对此问题的两种结构化修复方案,都不是一蹴而就的。
第一,区域评估池。在你服务客户的每个区域运行评估套件,针对该区域的端点,并将结果按区域打标签。eu-west 的回归应该在仪表板上显示为区域性回归,而不是被平均到全球分数中。这在操作上很烦人——你现在需要运行 N 份评估套件副本,支付 N 倍的推理费用,并对账 N 组结果。大多数妥善处理此问题的团队每小时在每个区域运行一个较小的“金丝雀”评估套件,并每晚在每个区域运行完整套件。成本是真实存在的。但通过客户成功工单才发现问题的代价也是真实的,而且那是用信任而非金钱支付的,那是一种更糟糕的货币。
第二,在每次追踪中固定区域模型身份。每次推理调用不仅应该记录模型名称,还应该记录请求最终被处理的区域。如果你无法从追踪中回答“哪个区域处理了此请求”,你就无法回答“这个客户产生的糟糕输出是否来自一个与我们测量的不同的模型”。供应商的 SDK 让这件事变得比应有的更难——它们中的许多仅在错误路径中显示区域,而不在成功路径中显示——因此你可能需要从网关记录它,或者从请求 ID 中提取它。无论如何:如果你的追踪模式(trace schema)中没有区域字段,今天就是添加它的日子。
团队未涵盖的失效模式
一旦你开始关注这一点,就会发现地域偏斜(regional skew)存在长尾的失效模式,而不仅仅是“新模型比旧模型更好”这么简单。以下是团队在事后报告的一些情况:
- https://docs.aws.amazon.com/bedrock/latest/userguide/models-region-compatibility.html
- https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html
- https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html
- https://docs.aws.amazon.com/bedrock/latest/userguide/global-cross-region-inference.html
- https://aws.amazon.com/blogs/machine-learning/introducing-amazon-bedrock-cross-region-inference-for-claude-sonnet-4-5-and-haiku-4-5-in-japan-and-australia/
- https://aws.amazon.com/blogs/machine-learning/introducing-amazon-bedrock-global-cross-region-inference-for-anthropics-claude-models-in-the-middle-east-regions/
- https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models
- https://learn.microsoft.com/en-us/azure/foundry/reference/region-support
- https://azure.microsoft.com/en-us/blog/announcing-the-availability-of-azure-openai-data-zones-and-latest-updates-from-azure-ai/
- https://learn.microsoft.com/en-au/answers/questions/2180810/gpt-4o-deployment-in-west-europe-severe-latency-is
- https://blog.premai.io/ai-data-residency-requirements-by-region-the-complete-enterprise-compliance-guide/
- https://lyceum.technology/magazine/eu-data-residency-ai-infrastructure/
- https://www.truefoundry.com/blog/ai-gateway-data-residency-comparison
