# Amazon Bedrock 在首尔和新加坡提供 Claude 模型区域内推理

- Source: MechNext — https://mechnext.eu/zh/article/25-amazon-bedrock-adds-in-region-claude-inference-in-seoul-and-singapore
- Published: 2026-09-30
- Updated: 2026-09-30
- Category: Industry News
- Language: zh (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=pl, ?lang=ru)

> 据 AWS 介绍，首尔区域支持 Claude Opus 5 和 Sonnet 5 的区域内推理，新加坡区域支持 Sonnet 5。每次请求的输入提示和输出结果在请求期间都留在所调用的区域。

据 AWS 发布的信息，Amazon Bedrock 现已在首尔支持 Claude Opus 5 与 Claude Sonnet 5 的区域内推理，并在新加坡支持 Claude Sonnet 5 的区域内推理。首尔对应的 AWS 区域标识为 `ap-northeast-2`，新加坡对应的标识为 `ap-southeast-1`。这项发布对两个地点列出的模型并不相同：首尔列出 Opus 5 和 Sonnet 5，新加坡列出 Sonnet 5。因此，理解可用范围时需要同时看模型名称和所调用的区域，而不能只看其中一项。

### 一次请求中的区域边界

所谓区域内推理，在这项发布中的含义很具体：Amazon Bedrock 在调用方指定的单个区域内处理请求。输入提示和输出结果在该请求的整个处理过程中留在这个区域。若读者关注请求在哪里被处理，判断依据就是实际调用的区域。比如评估首尔对应的选项时，应以首尔的区域标识和该处列出的模型为准；评估新加坡对应的选项时，则应以新加坡的区域标识及其列出的 Sonnet 5 为准。这里讨论的是推理请求期间的处理位置，以及输入与输出在这段期间所在的区域。

这一表述也说明了为什么“区域内”不能脱离具体调用来理解。同一个模型名称本身只说明所选模型，并不单独说明一次请求被送往哪个区域。AWS 给出的区域标识使两个地点可以被明确区分，而模型可用性列表进一步限定了每个地点能够使用这项区域内推理能力的模型。对于需要把处理位置与请求对应起来的团队，区域和模型是需要一起核对的两项信息。

### 路由和区域容量

AWS 表示，区域内推理没有路由层，吞吐量受所调用区域的容量限制。这意味着区域选择不仅对应请求的处理位置，也对应请求所面对的容量边界。讨论使用规模时，应把实际调用的区域作为参照，因为这里描述的吞吐量边界属于那个区域。首尔与新加坡在公告中各有明确的模型清单；容量约束同样按调用的区域来理解，而不是仅凭模型名称来理解。

这项信息不构成 Claude Opus 5 与 Claude Sonnet 5 的性能比较。公告给出的明确事实是两地的模型可用范围、请求的区域内处理方式，以及与所调用区域相关的运行条件。读者若要从公告中提取可操作的信息，重点在于确认目标模型是否列在目标区域之下，并理解请求会受到那个区域的容量、配额和计费条件约束。

### 通过哪些接口调用

这些区域内模型可在 `bedrock-runtime` 端点使用直接模型标识调用，例如 `anthropic.claude-opus-5` 和 `anthropic.claude-sonnet-5`。对于这些模型，该端点支持 Anthropic 的 Messages API，也支持 Amazon Bedrock 的 InvokeModel 和 Converse API。直接模型标识用于指出要调用的模型；调用区域则指出请求落在哪一个已公布的区域选项中。两者承担不同作用，组合起来才能准确表达一次调用所选的模型和区域。

AWS 还指出，用户可以通过 Amazon Bedrock 控制台的文本 Playground 访问 Claude 模型，无需编写代码，也无需设置 SDK。这提供了与上述运行时 API 并列的控制台入口。无论读者关注控制台中的访问方式，还是关注 Messages API、InvokeModel 或 Converse，公告中的区域与模型对应关系都相同：首尔是 Opus 5 和 Sonnet 5，新加坡是 Sonnet 5。

### 配额、价格与运行记录

请求适用所调用区域各自的服务配额，也适用该区域标准的按需定价。配额消耗、CloudWatch 指标和 CloudTrail 日志条目同样限定在所调用的区域。因而，在查看一次请求带来的配额使用量、相关指标或日志条目时，应把请求实际调用的区域作为查找和理解这些信息的依据。区域选择贯穿了这项发布所描述的多个方面：它决定请求在哪个区域处理，决定受哪个区域的容量限制，也决定按哪个区域的配额、价格和运行记录来观察请求。

这些运行条件和数据处理边界相互关联，但各自回答的问题不同。输入提示和输出结果留在所调用区域，回答的是一次推理请求期间它们位于何处；没有路由层以及吞吐量受区域容量限制，回答的是这一模式如何受区域容量约束；按区域划分的配额、价格、指标和日志，则说明如何从所调用区域的角度查看使用情况。把这些具体表述放在一起，能更准确地理解 AWS 所称的区域内推理，而不把公告扩大为对其他事项的承诺。

### 如何阅读这次发布

如果关注本地数据处理要求，最精确的起点是 AWS 对单次请求的说明：Amazon Bedrock 在被调用的单个区域内处理请求，输入提示与输出结果在请求期间都留在那里。接下来可以核对该区域是否列出了所需模型。首尔的区域标识是 `ap-northeast-2`，列出的模型是 Claude Opus 5 与 Claude Sonnet 5；新加坡的区域标识是 `ap-southeast-1`，列出的模型是 Claude Sonnet 5。最后，区域配额、标准按需价格和相关运行记录也都按实际调用的区域理解。

上述信息来自 AWS 关于[首尔与新加坡区域内推理模型的发布](https://aws.amazon.com/blogs/machine-learning/introducing-anthropic-models-on-amazon-bedrock-for-in-region-inference-in-seoul-and-singapore)。其核心是明确的地点、模型和请求边界：选择一个已列出的模型，调用相应区域，并按该区域理解请求处理、容量约束、配额、计费与运行记录。对需要评估区域内推理的读者而言，这些边界比笼统地说模型“可用”更有帮助，因为它们说明了公告究竟覆盖哪些模型、哪些区域，以及一次请求在所调用区域内如何被描述。