跳转到主要内容

区域模型发布的“彩票”效应:当你的产品在不同大洲表现各异时

阅读需 1 分钟Tian PanTian Pan

周五下午,一封客户成功(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)存在长尾的失效模式,而不仅仅是“新模型比旧模型更好”这么简单。以下是团队在事后报告的一些情况:

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 10 分钟

当硬件说谎时:静默数据损坏遇上随机性软件

大约每千个加速器中就有一个会静默地计算出错误答案,而 LLM 推理是第一个硬件故障与采样噪声看起来完全一致的大规模工作负载。本文将探讨位翻转如何隐藏在随机输出中,以及如何利用金丝雀通道和单机统计数据来捕捉说谎的 GPU。

insider
ai-engineering
阅读需 10 分钟

爆炸半径即权限模型:按‘能破坏什么’而非‘能读取什么’来隔离智能体沙箱

Replit 智能体在删除生产数据库之前执行的每一条命令都经过了授权 —— 权限模型回答了错误的问题。为什么智能体安全取决于执行环境:作用域令牌、临时分支、出站流量白名单、支出上限,以及设置在爆炸半径边界上的审批关卡。

insider
agent-security
阅读需 11 分钟

模型 API 现已成为 Tier 0 级别。在状态页变红之前,请先设计好降级模式

模型 API 位于请求路径中,与数据库同等重要,但大多数灾备 (DR) 计划仍将其视为“锦上添花”。这份实用指南涵盖了降级模式 —— 缓存、前置版本、队列和诚实的停机 —— 以及在下一次供应商故障发生前需要做出的业务决策。

ai-engineering
reliability
阅读需 8 分钟

那个你从未进行过负载测试的备用模型

配置好的备用模型只能证明你的路由机制有效 —— 却无法证明你的应用是否能在次要模型的输出下生存。本文探讨了为什么名义上的备用方案在真实流量下会失败,以及如何在供应商出故障前先行测试你的故障转移机制。

insider
llm
阅读需 10 分钟

置信度分数税:为什么询问模型它有多确定比直接出错成本更高

在 LLM 输出中添加置信度字段看起来是免费的。但事实并非如此。本文将介绍它所带来的单次请求“税”、为什么该数字很少经过校准,以及在根据它进行生产流量路由之前需要衡量什么。

insider
llm