澳大利亚团队现在可以从 Amazon Bedrock 的亚太（悉尼）和亚太（墨尔本）区域，通过全球跨区域推理访问 OpenAI GPT-5.6 Sol、Terra 和 Luna 模型。这个变化的重点不只是“换一个模型 ID”，还包括如何选择全球推理配置、降低重复提示词的成本、让 Codex 使用 OpenID Connect 登录，以及把调用量纳入 CloudWatch 监控。
全球跨区域推理改变了什么
传统做法通常要求应用固定调用某个 AWS 区域内的模型。全球跨区域推理则允许 Bedrock 根据可用性和服务路由，将请求调度到支持该模型的区域。对部署在澳大利亚的团队来说，应用仍然可以使用悉尼或墨尔本区域的 Bedrock endpoint，同时获得更灵活的模型访问能力。
区域选择仍然需要经过组织的合规和网络评估。跨区域推理意味着请求可能被路由到其他区域，因此需要确认数据驻留、跨区域传输、监管要求以及企业内部的 AI 使用政策。不要仅因为“调用入口在悉尼”就默认所有推理数据都只会留在澳大利亚。
模型名称和实际调用 ID 不是一回事。控制台中展示的模型名称、模型 ID、全球推理 profile ID 或 ARN，可能会因账户、区域和 Bedrock 接入方式而不同。上线前应从目标区域的 Bedrock 控制台或 API 中确认可用标识符，并将它作为配置注入应用。
用 Bedrock Runtime 发起一次调用
下面的示例使用 Python boto3 的 converse API。将 MODEL_ID 替换为目标账户中已经启用的 OpenAI 全球跨区域推理 profile ID 或 ARN，并确保当前身份拥有调用 Bedrock 模型的权限。
import os
import boto3
region = os.getenv("AWS_REGION", "ap-southeast-2")
model_id = os.environ["MODEL_ID"]
client = boto3.client("bedrock-runtime", region_name=region)
response = client.converse(
modelId=model_id,
system=[
{
"text": "You are a concise assistant for an Australian engineering team."
}
],
messages=[
{
"role": "user",
"content": [
{"text": "Explain why global cross-Region inference needs a data residency review."}
],
}
],
inferenceConfig={
"maxTokens": 300,
"temperature": 0.2,
},
)
print(response["output"]["message"]["content"][0]["text"])
运行前可以这样准备环境：
python -m pip install boto3
export AWS_REGION=ap-southeast-2
export MODEL_ID='替换为你账户中可用的全球跨区域推理 profile ID 或 ARN'
aws sts get-caller-identity
python invoke_openai_bedrock.py
如果团队使用墨尔本区域，把 AWS_REGION 改为 ap-southeast-4，但仍应以账户实际启用情况和 AWS 区域文档为准。生产代码还应处理限流、超时、重试、响应截断和模型不可用等情况，并记录请求延迟、输入输出 token 数以及错误类型。
提示词缓存适合什么场景
当每次请求都携带一份很长、但变化很少的系统提示词、产品手册或代码规范时，提示词缓存可以减少重复处理，并改善包含长上下文的工作流。常见场景包括代码助手、客服知识库和固定格式的文档审查。
Bedrock 的具体缓存字段和支持范围需要以目标模型及当前 API 版本为准。下面是一个可改造的 converse 结构示例，展示了把稳定内容放在前面、在其后追加动态问题的方式。cachePoint 的可用位置和参数应先在目标模型上验证：
import os
import boto3
client = boto3.client(
"bedrock-runtime",
region_name=os.getenv("AWS_REGION", "ap-southeast-2"),
)
response = client.converse(
modelId=os.environ["MODEL_ID"],
system=[
{"text": "You are a software reviewer. Apply the following review policy."},
{"text": "Stable policy and reference material go here."},
{"cachePoint": {"type": "default"}},
],
messages=[
{
"role": "user",
"content": [{"text": "Review this new code change: ..."}],
}
],
)
print(response["output"]["message"]["content"][0]["text"])
这个示例假设目标模型和当前 Bedrock API 版本支持该缓存结构。实际接入时，不要把经常变化的用户问题放入缓存段；缓存边界应放在稳定上下文之后、动态内容之前。还要比较缓存命中率、延迟和费用，避免为了缓存很短的提示词而增加系统复杂度。
Codex 与 OpenID Connect
如果团队通过 CI/CD 或开发工具使用 Codex，OpenID Connect 可以让工作负载使用短期 AWS 凭证访问 Bedrock，而不必在代码仓库或开发机中保存长期访问密钥。
一个典型的信任链包括：身份提供商签发 OIDC token，AWS IAM 对 token 的 issuer、audience 和 subject 条件进行校验，随后通过 AssumeRoleWithWebIdentity 换取临时凭证。IAM role 应只授予调用所需模型和 CloudWatch 操作的最小权限。
可以用下面的策略骨架开始设计权限，资源 ARN、动作名称和条件需要根据账户中的 Bedrock profile 及组织身份提供商配置补全：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "arn:aws:bedrock:*:*:inference-profile/REPLACE_ME"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"cloudwatch:GetMetricData"
],
"Resource": "*"
}
]
}
实际生产环境中，建议为开发、测试和生产分别建立 role，限制 sub 条件到指定仓库、分支或工作流，并对 role session duration、审计日志和异常调用进行审查。OpenID Connect 减少了密钥管理负担，但不会自动解决过宽 IAM 权限或错误的 token 条件。
用 CloudWatch 看见真实使用情况
模型接入完成后，至少应监控调用次数、延迟、错误和 token 消耗。具体可用指标名称、维度和日志字段应以目标模型及 Bedrock 当前 CloudWatch 集成为准；不要直接假设所有模型都会暴露完全相同的指标。
可以用 CloudWatch 控制台建立按区域、模型 profile、应用和环境划分的仪表板。命令行查询时，时间范围和指标名称需要替换成账户中已经确认的指标：
aws cloudwatch get-metric-data \
--region ap-southeast-2 \
--metric-data-queries '[
{
"Id": "invocations",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Bedrock",
"MetricName": "REPLACE_WITH_CONFIRMED_INVOCATION_METRIC",
"Dimensions": [
{"Name": "ModelId", "Value": "REPLACE_WITH_MODEL_ID"}
]
},
"Period": 300,
"Stat": "Sum"
},
"ReturnData": true
}
]' \
--start-time "$(date -u -d '1 hour ago' +%FT%TZ)" \
--end-time "$(date -u +%FT%TZ)"
监控不应只关注总调用量。对 Codex 和自动化代理，更有价值的信号通常包括每个工作流的 token 消耗、P95 延迟、重试比例、限流次数和单次任务成本。可以将应用名、环境和业务流程写入结构化日志，再通过 CloudWatch Logs Insights 或自定义指标进行聚合。
上线前检查清单
- 在悉尼和墨尔本分别确认目标 OpenAI 模型及全球跨区域推理 profile 是否可用。
- 明确跨区域路由对数据驻留、隐私和合规的影响，并获得组织批准。
- 使用最小权限 IAM role；CI/CD 优先采用 OIDC 短期凭证。
- 先在目标模型上验证提示词缓存的 API 结构、命中率和成本收益。
- 为调用设置超时、指数退避、限流处理和可观测字段。
- 在 CloudWatch 中建立按模型、区域、环境和工作流拆分的监控与告警。
全球跨区域推理降低了澳大利亚团队接入 OpenAI 模型的区域门槛，但它不是对架构决策的替代品。真正适合生产部署的方案，应同时满足模型可用性、跨区域数据策略、身份安全、缓存收益和可观测性要求。