OpenAI GPT-5.6 的 Sol、Terra、Luna 三个能力档位已在 Amazon Bedrock 上正式可用。做 agent 编码、长程推理，或需要高吞吐、低延迟推理时，你可以用熟悉的 OpenAI API 形态调用它们，而不必自己搭一套模型基础设施。
三个模型都走 bedrock-mantle 端点上的 OpenAI Responses API。Sol 面向深度推理与自主编码，Terra 照顾日常生产里的性能与成本平衡，Luna 偏向分类、摘要、路由这类快且便宜的调用。价格与 OpenAI 官方一致，用量可以计入既有的 AWS commitment。默认情况下，提示词和补全不会用来训练模型，也不会共享给模型提供商。
下面按选型、接入、推理控制、缓存、Codex 与配额，把落地路径理一遍。
三个能力档位怎么选
GPT-5.6 用数字表示代际，用 Sol / Terra / Luna 表示可独立演进的能力档位。在 Bedrock 上的关键规格如下：
| 模型 | Model ID | 更适合 | 可用区域 |
|---|---|---|---|
| Sol | openai.gpt-5.6-sol |
自主编码、安全研究、科学分析、多步深度推理 | 美国东部（弗吉尼亚北部）、美国东部（俄亥俄） |
| Terra | openai.gpt-5.6-terra |
通用生产负载，兼顾推理、性能与成本 | 上述两区 + 美国西部（俄勒冈） |
| Luna | openai.gpt-5.6-luna |
高吞吐、延迟敏感：分类、摘要、路由等 | 上述两区 + 美国西部（俄勒冈） |
共性也很明确：都支持文本和图像输入、文本输出，上下文窗口 272K token，统一用 Responses API；reasoning effort 都支持 none、low、medium、high、xhigh、max。因此换档位时，往往只需改 model ID，不必重写集成层。
选型可以很直接：复杂重构、多步排查用 Sol；常规业务接口用 Terra；批量分类或路由用 Luna。同一套客户端可以按任务切换。
通过 bedrock-mantle 调用 Responses API
端点形态
Base URL：
https://bedrock-mantle.{region}.api.aws
Responses API 路径：
/openai/v1/responses
{region} 换成支持区域，例如 us-east-1。openai/v1 这条路径专用于 OpenAI 模型，兼容 OpenAI 的 Python 与 TypeScript SDK。已有 OpenAI SDK 应用迁到 Bedrock 时，通常只要改 base URL、换成 Bedrock 上的 model ID，并用 Bedrock API key 或 AWS 凭证认证。
权限与 SDK
账号需要对 bedrock-mantle 具备推理权限。一种做法是给 IAM 主体挂上托管策略 AmazonBedrockMantleInferenceAccess，其中包含示例所需的 bedrock-mantle:CreateInference、bedrock-mantle:CallWithBearerToken 等读与推理创建权限。
OpenAI Python SDK 需要 2.45.0 及以上：
pip install "openai>=2.45.0"
两种认证方式
1. 自动刷新的短期 key（更适合生产）
用 BedrockOpenAI，配合 token provider，按请求从 AWS 凭证生成并刷新短期 key：
from aws_bedrock_token_generator import provide_token
from openai import BedrockOpenAI
region = "us-east-1"
client = BedrockOpenAI(
aws_region=region,
bedrock_token_provider=lambda: provide_token(region=region),
)
2. 环境变量里的短期 key
把 key 放在 AWS_BEARER_TOKEN_BEDROCK。这种 key 不会自动刷新，最长约 12 小时就会过期。生产环境更建议自动刷新，或把 key 放进 AWS Secrets Manager。
import os
from openai import OpenAI
client = OpenAI(
base_url="https://bedrock-mantle.us-east-1.api.aws/openai/v1",
api_key=os.environ["AWS_BEARER_TOKEN_BEDROCK"],
)
第一次推理
Responses API 用单一 input 字段，生成文本在 output_text：
response = client.responses.create(
model="openai.gpt-5.6-terra",
input="Explain the benefits of prompt caching for agentic workloads.",
max_output_tokens=512,
store=False,
)
print(response.output_text)
调节 reasoning effort
复杂多步任务可以让模型在作答前多花一些 reasoning token，结果通常更好，但延迟和费用也会上去。通过 reasoning 参数设定档位，并按任务匹配即可：
response = client.responses.create(
model="openai.gpt-5.6-sol",
input=(
"A train leaves at 3 PM at 60 km/h. Another leaves an hour later at "
"90 km/h from the same station. When does the second catch up?"
),
reasoning={"effort": "high"},
)
print(response.output_text)
Sol、Terra、Luna 都支持从 none 到 max 的同一套档位，换模型时推理强度接口保持一致。
工具调用（tool calling）
模型可以请求你定义的工具，由应用侧执行后把结果回传，再生成最终回答。下面是一次客户端侧 round-trip 的完整形状：定义 get_weather，把用户问题与 tools 一并送出，解析 function_call，追加 function_call_output，再请求最终回复。
import json
tools = [
{
"type": "function",
"name": "get_weather",
"description": "Get the current weather for a given location",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City and country (for example, Seattle, US)",
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "Temperature unit",
},
},
"required": ["location"],
},
}
]
input_list = [{"role": "user", "content": "What's the weather like in Seattle?"}]
response = client.responses.create(
model="openai.gpt-5.6-terra",
input=input_list,
tools=tools,
)
# 下一轮要带上模型输出（可能含 reasoning items）
input_list += response.output
for item in response.output:
if item.type == "function_call":
args = json.loads(item.arguments)
result = {
"location": args["location"],
"temperature": 64,
"condition": "Partly cloudy",
}
input_list.append(
{
"type": "function_call_output",
"call_id": item.call_id,
"output": json.dumps(result),
}
)
final_response = client.responses.create(
model="openai.gpt-5.6-terra",
input=input_list,
tools=tools,
)
print(final_response.output_text)
有一点容易漏：GPT-5.6 会先推理再回复，多轮时必须把 response.output（可能包含 reasoning）一并带回。生产环境还可叠加 Amazon Bedrock Guardrails，按用例与负责任 AI 策略加护栏。
在控制台先试再写代码
GPT-5.6 跑在新一代推理引擎上，对应新版 Amazon Bedrock 控制台：面向 bedrock-mantle，并兼容 OpenAI / Anthropic 风格 API。体验是 project 制——建项目、分配模型、配置 API key，还可并排对比，不必先写应用代码。
简要步骤：
- 打开模型可用区域（如美国东部弗吉尼亚北部）的新版 Bedrock 控制台；若在旧控制台，选择 Try the new Bedrock console。
- 创建或打开 project。
- 在 model catalog 里查看 GPT、Claude 与开源权重模型，最多并排对比 3 个模型的能力、模态、上下文、定价与区域。
- 把某个 GPT-5.6 模型加入项目。
- 发起 evaluation，输入 prompt，查看回复；同一 prompt 最多可选 3 个模型对比。
用 prompt caching 压低重复前缀成本
Agent 与多步工作流里，系统指令、工具定义、参考文档常在请求间重复，只有最新输入在变。GPT-5.6 在 Bedrock 上提供两种 prompt caching：
- 隐式缓存：默认开启，符合条件的请求会自动缓存，不必改代码结构。
- 显式缓存：用 cache breakpoint 精确标记可复用前缀。
两种模式都能在请求量上去后减少对共享上下文的重复计费处理。缓存读相对未缓存输入有 90% 折扣；写入缓存的 token 按未缓存输入价的 1.25 倍 计费。具体费率以 Amazon Bedrock 定价页为准。
缓存内容至少保留约 30 分钟，够覆盖一次 agent burst 调用。每个断点前缀至少 1,024 tokens，单请求最多 4 个 cache checkpoint。前缀不足最小长度时请求仍会成功，但不会写入缓存，cached_tokens 为 0。
显式断点
在可复用段落末尾的 content block 上加 prompt_cache_breakpoint，并把 prompt_cache_options 设为 explicit。跨请求使用稳定的 prompt_cache_key，有助于命中同一缓存。系统指令放在断点前，用户问题放在断点后，问题变化不会打掉已缓存前缀：
# system_prompt 需为真实内容且至少 1,024 tokens
system_prompt = "You are a technical support agent for Example Corp. ...(1,024+ tokens)..."
def ask(question):
return client.responses.create(
model="openai.gpt-5.6-terra",
prompt_cache_key="support-agent:system-prompt-v1",
prompt_cache_options={"mode": "explicit"},
input=[
{
"type": "message",
"role": "developer",
"content": [
{
"type": "input_text",
"text": system_prompt,
"prompt_cache_breakpoint": {"mode": "explicit"},
}
],
},
{
"type": "message",
"role": "user",
"content": [{"type": "input_text", "text": question}],
},
],
)
first = ask("How do I configure single sign-on?")
print("write:", first.usage.input_tokens_details.cache_write_tokens)
second = ask("How do I reset a password?")
print("read: ", second.usage.input_tokens_details.cached_tokens)
print(second.output_text)
前缀足够大时，第一次调用应看到非零 cache_write_tokens，第二次看到非零 cached_tokens。Agent 循环里前缀大且稳定时，显式模式更合适，因为你能钉死缓存边界，减少无用写入。
隐式缓存
不设置 prompt_cache_options 时走默认隐式模式。端点会在最新 message 上放自动断点，也会尊重你加的显式断点。静态内容（系统指令、工具定义、参考文档）放前面，可变内容放后面，再配上稳定的 prompt_cache_key，就能复用已处理前缀：
response = client.responses.create(
model="openai.gpt-5.6-terra",
prompt_cache_key="support-agent:kb-v1",
input=[
{
"type": "message",
"role": "developer",
"content": [{"type": "input_text", "text": system_prompt}],
},
{
"type": "message",
"role": "user",
"content": [{"type": "input_text", "text": "How do I configure single sign-on?"}],
},
],
)
print(response.output_text)
隐式模式省事，但你无法精确指定缓存边界。聊天、RAG 这类前缀天然稳定的场景更合适；agent 大前缀更适合显式。两种模式计费规则相同。若要关闭缓存，可把 prompt_cache_options 设为 explicit 且不添加任何断点。
监控命中率
每次响应的 usage 里可看缓存活动：input_tokens_details.cached_tokens 是从缓存读入的输入 token，cache_write_tokens 是写入量。cached_tokens 已计入总 input_tokens，命中率可用 cached_tokens / input_tokens 估算：
usage = response.usage
details = usage.input_tokens_details
cached = getattr(details, "cached_tokens", 0) or 0
cache_write = getattr(details, "cache_write_tokens", 0) or 0
total_input = usage.input_tokens
hit_rate = cached / total_input if total_input else 0.0
print(f"Cached tokens: {cached}")
print(f"Written tokens: {cache_write}")
print(f"Total input: {total_input}")
print(f"Cache hit rate: {hit_rate:.1%}")
一次命中的典型信号是 cached_tokens > 0 且 cache_write_tokens == 0。仅凭 cache_write_tokens == 0 不能确认命中，因为什么都没缓存时也会是 0。即便前缀相同，也不保证每次必中，应跨多次请求统计，而不是盯单次结果。
bedrock-mantle 会把账户、项目、模型级 token 指标发到 CloudWatch 命名空间 AWS/BedrockMantle，但没有专门的 cache 指标；缓存测量以响应里的 usage 为准。应用日志里汇总 cached_tokens 与 cache_write_tokens 即可长期跟踪。
把 Codex 接到 Bedrock
OpenAI Codex 是面向开发者的编码 agent，能操作本地文件、仓库、终端与开发环境：写功能、修 bug、跑测试、开 PR。Codex CLI、VS Code / JetBrains 扩展，以及 ChatGPT 桌面应用，都可以把模型推理路由到 Amazon Bedrock，在你的 AWS 账号内做 In-Region 处理，并沿用前述访问控制。
在 ~/.codex/config.toml 指定模型与 provider（新版 Bedrock 控制台的 Clients 区也会生成连接说明）：
model = "openai.gpt-5.6-sol"
model_provider = "amazon-bedrock"
[model_providers.amazon-bedrock.aws]
region = "us-east-1"
认证优先读 AWS_BEARER_TOKEN_BEDROCK，否则走 AWS SDK 凭证链。ChatGPT 桌面应用和 IDE 扩展未必继承 shell 环境，可把变量写在 ~/.codex/.env：
AWS_BEARER_TOKEN_BEDROCK=<your-api-key>
改完 config.toml 或 .env 后重启应用或扩展。CLI 则可以在 shell 里 export 同一变量。Codex 通过支持的商业区域里的 bedrock-mantle 发推理。复杂重构、调试适合更高 reasoning；日常小改用较低档位更快。ChatGPT 桌面端可为任务选择 Light、Medium、High、Extra High 等推理强度。
安全与数据处理
每次调用都受你的 IAM 策略约束，可在 VPC 内运行，并记入 AWS CloudTrail。In-Region inference 把请求留在你指定的区域，方便满足数据驻留要求。
Sol、Terra、Luna 是 OpenAI 第三方模型，通过 Bedrock 提供，并受 OpenAI 条款约束。被 classifier 标记的流量，最长可保留 30 天 做自动化离线滥用检测；保留的输入输出由 AWS 存储与处理，默认不共享给模型提供商（除非你 opt-in）。保留策略可通过 data retention mode 配置。
配额、限流与清理
调用走 on-demand、Standard 服务层级，按 token 付费，无需预留容量。bedrock-mantle 按模型 + 区域管理两道配额：每分钟输入 token、每分钟输出 token；没有 requests-per-minute 配额。通过 prompt caching 读到的缓存输入 token 不计入每分钟输入 token 配额，量级上来时缓存更有价值。
超限会返回 HTTP 429。瞬时限流可用指数退避与有上限的重试，OpenAI SDK 的 max_retries 可配置：
from aws_bedrock_token_generator import provide_token
from openai import BedrockOpenAI
region = "us-east-1"
client = BedrockOpenAI(
aws_region=region,
bedrock_token_provider=lambda: provide_token(region=region),
max_retries=6,
)
持续高流量时，把大批请求摊到多分钟，而不是瞬时打满；逐步抬高并发，让吞吐跟区域容量对齐。
On-demand 只在实际调用时计费，没有需要拆掉的基础设施。短期 API key 最长约 12 小时自动过期；若要提前作废，在新版 Bedrock 控制台删除 key——删除会立刻切断所有依赖该 key 的应用，先确认没有在线流量再操作。单价以 Amazon Bedrock 定价为准。
落地时可以怎么排
- 在新版控制台建 project，用真实 prompt 对比 Sol / Terra / Luna。
- 用 Responses API 样本对接你自己的数据与 model ID。
- 对重复前缀加上显式 cache breakpoint，并统计
cached_tokens命中率。 - 按成本与延迟曲线在真实负载上选定默认档位；编码场景再考虑把 Codex 指到同一账号与区域。
同一套 Responses API 与 model ID 约定，就能在深度推理、日常生产与高吞吐路由之间切换，同时把调用留在你的 AWS 边界内。