你的 AI 提供商是一个单点故障
上周五，美国商务部向 Anthropic 发出了一封信。到那天傍晚，Fable 5 和 Mythos 5 就消失了。
它们没有被弃用，没有被限流，而是直接消失了。
API 调用返回 404 错误。实时会话在对话中途失败。依赖这些模型的应用程序停止了工作。这一切发生在发布后的第三天。没有预警，也没有迁移窗口。
我们很幸运，因为那些模型是全新的。还没有人对它们建立起深度依赖。想象一下，如果你使用了一个模型六个月，然后发生了这种情况。
如果一封政府公函就能关停你的主数据库，你还会不在没有故障转移的情况下运行它吗？你肯定不会。然而，大多数团队在对待 AI 时却是这样做的。
许多团队把 AI 当作电力。你按下开关，就期待灯亮。你不会去思考能源来源，也不会思考停电时会发生什么。你挑选一个模型，硬编码一个端点，然后发布。
这不是工程学。这是靠“希望”驱动的架构。
模型可能因以下原因消失：
- 监管原因
- 政策变化
- 地缘政治问题
Anthropic 的情况并非 Bug 或基础设施故障。它是一个监管层面的“一键关停”开关。
你必须在模型层构建韧性。请使用以下模式：
- 抽象你的模型调用。使用接口，这样你的应用就不必关心由哪个提供商提供响应。
- 使用多个提供商。更换提供商应该只是一个配置更改，而不是彻底重写。
- 使用开放权重模型（open-weight models）。如果你自己运行模型，就没有人能远程关闭它。当电网断电时，这些模型就像发电机一样。
- 实现平滑降级（graceful degradation）。使用一个更小或更旧的模型，也比应用程序崩溃要好。
监控你的错误率。如果错误率激增，请立即“跳闸”，并将流量路由到你的备选方案。
把你的 AI 当作任何其他关键的生产级依赖项来对待。为失败而设计。
你的架构是否假设了提供商会失效？如果不是，你正处于风险之中。
你是否在技术栈中构建了多提供商回退机制？在评论区告诉我。
Source: https://dev.to/aws/your-ai-provider-is-a-single-point-of-failure-26i2
Optional learning community: https://t.me/GyaanSetuAi