Cloudflare AI Gateway 添加模型别名和故障转移

Cloudflare AI Gateway 添加了模型别名，允许客户将模型池放置在应用程序使用的单个名称后面。别名可以应用有序回退策略或智能路由，而客户端则通过网关的 REST API.

发送别名作为模型名称

实际的变化是应用程序请求的模型标识符与最终处理请求的模型之间的分离。网关操作员可以更改池、路由策略或底层模型，而无需重新部署每个使用别名的客户端。 Cloudflare 表示别名的范围仅限于各个网关。

这不仅仅是重命名模型的便利。它为运营商提供了稳定的应用程序界面，而其背后的提供商可用性、模型版本和路由首选项会发生变化。

不断变化的模型池的稳定名称

如果没有别名层，应用程序通常依赖于特定于提供商的模型标识符。因此，替换模型、添加后备或将流量转移到另一个提供商可能需要跨多个服务进行配置更改。它还可能会将重试和提供商选择逻辑推送到每个客户端。

Cloudflare 的实施将这些决策移至网关。通过有序回退，操作员可以定义首选模型和替代方案，以便在第一个选择无法满足请求时进行尝试。智能路由提供了一种策略驱动的替代方案，其中网关从池中进行选择，而不是遵循固定顺序。

这种安排与团队的多模型API网关特别相关。软件团队可以为应用程序提供持久的模型名称，同时集中更改实现。它还可以标准化多个内部服务使用的标识符，从而减少必须与应用程序所有者协调的模型迁移数量。

不过，别名仍然是特定于网关的。如果运营多个 Cloudflare 网关的组织希望跨环境或业务部门保持一致的名称和政策，则需要单独管理等效别名。

模型池可以提高弹性，因为应用程序不再需要自己的提供程序选择和后备代码。如果操作员更改有序池，应用程序将继续调用相同的别名。相同的机制可以支持模型升级或提供商更改，而无需更改面向客户的合同。

但稳定标识符引入了运营商无法忽视的会计区别。日志和使用记录应保留客户端请求的别名和实际服务于请求的模型。否则，仅在别名下报告的请求可能会隐藏价格、延迟、输出质量或提供商处理方面的差异。

这对于退款和客户支持以及技术调试都很重要。当对同一别名的两个请求由不同的模型提供服务时，即使客户端配置不变，它们的成本和行为也可能不同。因此，开发团队的AI API控制平面需要执行级别归因，而不仅仅是按公共模型名称分组的计数。

评估也成为一项持续的运营任务。路由更改可能会在没有代码部署的情况下影响应用程序行为，因此团队应该测试策略修订并保留哪个模型为每个评估的请求提供服务的记录。警报应区分成功的回退与正常使用首选模型，因为重复的回退可能表明提供商存在问题或容量已耗尽。

别名对于发布面向客户的模型目录的平台非常有用。经销商可以公开稳定的产品名称，同时替换已弃用的模型、调整提供商组合或在其背后引入后备选项。这可以减少破坏性的目录迁移，并让运营商集中管理可用性。

这种抽象还产生了披露和计费问题。客户可能需要知道别名是否始终映射到一个模型、在多个模型中进行选择或随着时间的推移而改变行为。对于 AI API 经销商运营，发票和使用情况导出应使路由结果足够清晰，以便协调客户费用与提供商成本。

运营商还应决定是否将预算、速率限制和访问策略附加到别名、基础模型或两者上。可以路由到价格截然不同的模型的别名不应默默地绕过配置客户端时建立的支出假设。

Cloudflare 的变更日志确立了核心行为，但并未描述本公告中智能路由所使用的决策标准。它还不提供故障转移的性能测量或解释别名更改传播的速度。

这些详细信息将决定团队如何自信地将别名用于对延迟敏感或严格管理的工作负载。目前，直接的好处是显而易见的：应用程序可以依赖稳定的模型名称，而路由决策则转移到网关中。相应的义务也同样明确：报告、计费和审核必须遵循实际执行请求的模型，而不仅仅是应用程序提供的别名。