在 AWS GovCloud 上用 Bedrock 跑 GPT OSS 与 NVIDIA Nemotron

Amazon Bedrock 在 AWS GovCloud (US) 中加入了一批美国区域可用的前沿开放权重模型：OpenAI GPT OSS 120B/20B，以及 NVIDIA Nemotron Nano 9B v2、Nano 12B v2、Nano 30B、Super 120B。对政府、公共部门、国防承包商和受监管企业来说，重点不只是“多了几个模型”，而是可以在 GovCloud 的数据驻留边界内，把更强的通用推理、代码、文本生成和代理能力接入现有 AWS 控制面。

为什么这次发布值得关注

GovCloud 项目里使用大模型，常见约束不是“能不能调 API”，而是数据边界、账号隔离、审计、采购和运行责任能否说清楚。Bedrock 把模型调用放在 AWS 托管服务里，开发者可以沿用 IAM、VPC Endpoint、CloudTrail、KMS、配额和账单体系，而不是单独维护一套模型服务入口。

这次新增的模型组合覆盖了两个方向：

• OpenAI GPT OSS 120B/20B：开放权重模型，适合需要透明模型谱系、可解释部署边界或模型选择弹性的团队。
• NVIDIA Nemotron Nano/Super 系列：从 9B、12B、30B 到 120B，给不同延迟、成本和能力要求留出梯度。

摘要里提到 Bedrock 同时覆盖了模型能力、数据驻留推理选项、服务层级和入门方式。落地时可以把它理解成三个决策：选哪个模型、在哪个 GovCloud 区域跑、用哪个服务层级承接流量。

模型选择：不要只看参数量

120B 模型通常更适合复杂推理、长链路任务拆解、代码分析和高质量生成；20B、30B 或 Nano 系列模型则更适合成本敏感、吞吐优先、任务边界明确的场景。实际工程里，参数量不是唯一指标，至少还要看：

• 延迟预算：交互式应用通常比离线批处理更敏感。
• 上下文和输出规模：摘要、分类、结构化抽取和多轮代理的 token 形态不同。
• 数据驻留要求：GovCloud 中的推理路径应和你的合规边界一致。
• 服务层级：生产流量要提前确认配额、吞吐、可用区域和升级路径。

一个实用做法是先用小模型建立评测集和调用链，再把困难样本路由到更大的模型。这样不会一开始就把所有请求压到最高成本档位。

可以这样实践：在 GovCloud 中发现并调用模型

下面示例使用 AWS CLI 和 Bedrock Runtime。运行前需要替换 AWS_REGION，并确认你的 GovCloud 账号已经开通对应模型访问权限。模型 ID 不建议手写猜测，先用 list-foundation-models 查询，再把结果填入 MODEL_ID。

export AWS_REGION=us-gov-west-1

aws bedrock list-foundation-models \
  --region "$AWS_REGION" \
  --query "modelSummaries[?contains(modelName, 'GPT') || contains(modelName, 'Nemotron')].[modelId,modelName,providerName]" \
  --output table

拿到模型 ID 后，可以用一个最小请求验证推理链路。不同模型在 Bedrock 中的请求 schema 可能不同，下面用常见的 messages 风格作为可改造模板；如果 CLI 返回 schema 错误，按该模型在 Bedrock 控制台中的示例请求调整 body 字段。

export AWS_REGION=us-gov-west-1
export MODEL_ID="替换为上一步查到的模型ID"

cat > request.json <<'JSON'
{
  "messages": [
    {
      "role": "user",
      "content": "用三句话解释为什么 GovCloud 中的数据驻留会影响大模型架构。"
    }
  ],
  "max_tokens": 300,
  "temperature": 0.2
}
JSON

aws bedrock-runtime invoke-model \
  --region "$AWS_REGION" \
  --model-id "$MODEL_ID" \
  --content-type "application/json" \
  --accept "application/json" \
  --body fileb://request.json \
  response.json

cat response.json

如果你更习惯在服务端代码里接入，可以用 Python 封装一层。下面代码保留了模型请求体的可替换性，适合放进一个内部网关或评测脚本里。

import json
import os

import boto3

region = os.environ.get("AWS_REGION", "us-gov-west-1")
model_id = os.environ["MODEL_ID"]

client = boto3.client("bedrock-runtime", region_name=region)

payload = {
    "messages": [
        {
            "role": "user",
            "content": "把下面需求改写成一条清晰的后端开发任务：为文档系统增加审计日志。",
        }
    ],
    "max_tokens": 400,
    "temperature": 0.1,
}

response = client.invoke_model(
    modelId=model_id,
    contentType="application/json",
    accept="application/json",
    body=json.dumps(payload).encode("utf-8"),
)

result = json.loads(response["body"].read())
print(json.dumps(result, ensure_ascii=False, indent=2))

运行方式：

python -m venv .venv
. .venv/bin/activate
pip install boto3
export AWS_REGION=us-gov-west-1
export MODEL_ID="替换为 Bedrock 中的 GPT OSS 或 Nemotron 模型ID"
python invoke_bedrock_govcloud.py

架构上要提前定下来的边界

把模型放进 GovCloud，不等于合规问题自动消失。你仍然需要把调用路径、日志、权限和数据生命周期做成可审计的工程事实。

建议至少检查这些点：

• IAM：应用角色只允许调用必要的 Bedrock 动作和指定模型资源。
• 网络：生产系统优先评估 VPC Endpoint、私有子网和出口控制。
• 日志：不要把原始敏感 prompt、响应和附件内容无差别写入应用日志。
• KMS：如果上下游存储 prompt、评测集或响应结果，确认加密和密钥策略。
• 配额：在压测前确认 GovCloud 区域中的模型可用性、吞吐和服务层级。
• 评测：为 20B/30B/120B 等不同模型建立同一套任务集，比较质量、延迟和成本。

采用建议

对新项目，可以从 GPT OSS 20B 或 Nemotron Nano/30B 这类中等规模模型开始，先跑通权限、网络、审计和评测闭环；当任务需要更强推理或更高质量输出时，再把部分请求升级到 120B 级别模型。对已有 Bedrock 应用，迁移重点是区域、模型 ID、请求 schema 和配额，不要假设商业区的配置可以原样搬到 GovCloud。

这次发布的核心价值，是让受监管团队在 AWS GovCloud (US) 内有更多开放权重模型选择。真正上线时，模型能力只是其中一半；另一半是把数据驻留、服务层级、成本和审计做成日常可运行的系统约束。