当 AWS Bedrock 中的某个特定模型提供商（如 AI21 或 Anthropic）发生故障，而其他提供商正常工作时，问题通常源于提供商特定的限制、错误配置或区域/版本约束。首先，提供商的服务可能遇到中断、速率限制或扩展挑战。例如，AI21 的 API 可能因维护而暂时不可用，或者如果您的帐户超过其分配的配额，Anthropic 的模型可能会限制请求。与 Bedrock 的统一界面不同，每个提供商都是独立运作的，因此一个模型的停机时间不会影响其他模型。您可以查看 AWS 服务运行状况仪表板或提供商的状态页面以确认中断。此外，提供商可能会强制执行独特的速率限制——如果您的应用程序突然向 AI21 发送大量请求，则可能会触发错误，而流量较低的模型（如 Claude）仍不受影响。
其次，您的应用程序或 AWS 权限中的错误配置可能会将问题隔离到单个提供商。例如，如果您的 IAM 角色缺少特定模型系列（例如，anthropic.claude-v2）的 bedrock:InvokeModel 权限，则对 Anthropic 的请求将失败，而其他请求将成功。同样，模型特定的参数可能会导致错误：AI21 的 Jurassic-2 模型需要 0-1 之间的 temperature 值，但如果您的代码意外地发送了像 1.5 这样的值，它将拒绝该请求。其他提供商可能会静默地限制无效值而不是失败，从而掩盖问题。使用 AWS CloudTrail 日志或通过 Bedrock API 的 ValidateException 标志进行测试来验证参数和权限，以便及早发现这些问题。
最后，区域可用性和模型版本控制可能会导致差异。某些模型仅在特定 AWS 区域中受支持——如果您的基础设施部署在 us-west-2 中，但 AI21 的模型仅在 us-east-1 中可用，则请求将失败。同样，提供商偶尔会弃用较旧的模型版本（例如，anthropic.claude-v1）。如果您的代码硬编码了过时的版本，而其他模型使用最新版本，则会中断。始终验证 Bedrock 文档中的模型 ARN，并使用 AWS 的 ListFoundationModels API 来确认可用性。这些因素突出了在代码中隔离提供商特定依赖项并独立监控其状态的重要性。