DeepSeek 上 Amazon Bedrock 全指南：模型、价格、API 与实战配置

99% 的团队在上 DeepSeek 时，只盯着“模型效果”，却忽略了一个更贵的坑：上线后的安全、合规和成本失控。把 DeepSeek 放进 Amazon Bedrock，不只是换个 API，而是把模型接入整个 AWS 的治理体系，这一步做对了，后面很多坑可以少踩一半。

如果你已经在用 AWS，却还在自己搭推理服务，很可能白白多花了 30% 以上的运维和安全成本——这话听着有点扎心，但有数据支撑。

DeepSeek 与 Amazon Bedrock 是什么关系？

DeepSeek 在 Bedrock 里的定位

Amazon Bedrock 是 AWS 提供的托管大模型平台，让团队可以直接调用各家基础模型，而不用自己管集群、扩缩容和底层推理框架。DeepSeek 在 Amazon Bedrock 中，就是以“托管模型”的形式出现，由 AWS 负责运维、计费和安全边界，你只需要通过 Bedrock 的 API 调用。

据 AWS 文档，目前在 Bedrock 中可用的 DeepSeek 模型包括 DeepSeek V3.2、DeepSeek-V3.1 和 DeepSeek-R1。V3.2 和 V3.1 支持 Invoke、Converse 和 OpenAI 兼容的 Chat Completions，R1 支持 Invoke 和 Converse，但不支持 Chat Completions。模型 ID、区域和价格都可能更新，我自己在项目里习惯的做法是：每次上生产前都在控制台再核对一遍。

有用户反馈，在复制文档里的旧 modelId 直接上生产后，遇到“模型不可用”错误，排查半天才发现是区域和 ID 不匹配，这种低级错误完全可以通过上线前的 checklist 避免。

为什么 DeepSeek 适合放在 Bedrock 里用

DeepSeek 的强项在于推理、代码生成、数学与技术分析，多步问题拆解能力也比较突出。放在 Bedrock 里用，真正的价值是：这些能力可以直接接入 AWS 的 IAM、CloudTrail、Guardrails、Agents、Flows 和模型评估等一整套企业级能力。

对生产团队来说，调用模型只是起点，更关键的是：

• 谁能访问哪些模型、哪些数据
• 模型部署在哪个 Region，是否跨区推理
• 成本如何按项目、部门拆分和监控
• 安全审计、合规评审怎么做
• 高风险场景是否有人工复核和 Guardrails

我也不太确定这个说法对不对，但从最近一批云上 AI 项目看，真正拖慢上线的往往不是“模型不够强”，而是这些治理问题没想清楚。

Amazon Bedrock 中可用的 DeepSeek 模型

DeepSeek V3.2、V3.1、R1 能力对比

AWS 当前文档列出的三款 DeepSeek 模型：

• DeepSeek V3.2：Mixture-of-Experts 架构，强化推理、编码和指令跟随
• DeepSeek-V3.1：685B 参数 MoE，偏重代码、数学和通用推理
• DeepSeek-R1：专注推理的模型，使用 chain-of-thought 处理复杂数学、代码和逻辑问题

关键技术参数：

• V3.2：
  • 上下文窗口：164K tokens
  • 最多输出：8K tokens
  • 输入/输出：文本
  • 支持：Invoke、Converse、Chat Completions
  • 模型 ID：deepseek.v3.2（bedrock-runtime 与 bedrock-mantle 通用）
• V3.1：
  • 上下文窗口：128K tokens
  • 最多输出：8K tokens
  • 支持：Invoke、Converse、Chat Completions
  • 模型 ID：deepseek.v3-v1:0（bedrock-runtime），deepseek.v3.1（bedrock-mantle）
• R1：
  • 上下文窗口：128K tokens
  • 最多输出：8K tokens
  • 支持：Invoke、Converse（不支持 Chat Completions）
  • 模型 ID：deepseek.r1-v1:0（bedrock-runtime），us.deepseek.r1-v1:0（US geo 跨区推理）

据 AWS 模型卡信息，R1 在跨 Region 推理上采用 geo profile ID，而 V3.2、V3.1 在更多区域提供原生 in-region 部署，这会直接影响延迟和合规策略。

区域与模型 ID 的坑

模型可用性是按 Region 划分的，R1 的模型卡显示在美国区域支持跨区推理 profile，而 V3.2、V3.1 在更多区域原生可用。很多团队在多区域架构下，会混用 deepseek.r1-v1:0 和 us.deepseek.r1-v1:0，一旦搞错就会出现 4xx 或 5xx 错误。

更稳妥的做法：

• 在目标 Region 的 Bedrock 控制台中：
  • 打开模型目录
  • 搜索 DeepSeek
  • 直接复制该 Region 下的 modelId
• 把 modelId 写进配置文件，而不是硬编码在代码里
• 在 CI/CD 中加一条“模型 ID 与 Region 校验”的自动检查

为什么通过 Amazon Bedrock 用 DeepSeek？

相比直连 DeepSeek 的核心差异

对已经重度使用 AWS 的组织，通过 Bedrock 调用 DeepSeek 的吸引力主要在于：

• 统一治理：权限、审计、配额、计费都在 AWS 体系内
• 多模型对比：可以在同一套 API 下对比 DeepSeek、Anthropic、Meta 等模型
• 安全与合规：复用现有的 VPC、PrivateLink、CloudTrail、KMS 等能力
• 运维简化：不再自己维护推理集群、弹性伸缩和高可用

AWS 明确说明：

• Bedrock 的内容不会用于训练基础模型
• 内容不会共享给模型提供方
• 数据在传输和存储时均加密
• 可通过 PrivateLink 从 VPC 建立私网访问

风险与误区：Bedrock 不是“安全免死金牌”

有个常见误解：上了 Bedrock，就等于安全合规都搞定了。现实是，Bedrock 提供的是更好的“工具箱”，但安全责任仍在你这边。

需要自己补齐的部分包括：

• 数据分级与脱敏策略
• IAM 最小权限设计
• Prompt 测试与越权尝试（jailbreak 测试）
• 高风险场景的人审流程
• 模型评估与持续监控
• 成本预算与告警

我在一个金融客户项目里看到过反例：团队以为“Bedrock 默认安全”，结果把敏感客户字段直接塞进 prompt，后面做合规审计时返工成本非常高。这类问题，技术上不难，关键是流程和意识。

DeepSeek 在 Amazon Bedrock 的 API 选项

Invoke / Converse / ConverseStream / Chat Completions

AWS 把 Bedrock 的 API 能力分成几类：

• Invoke：单轮调用，适合简单补全或工具型调用
• Converse：多轮对话接口，结构化 messages，支持推理配置
• ConverseStream：流式版本，适合聊天界面或长输出
• OpenAI 兼容的 Chat Completions：通过 bedrock-mantle 暴露，方便迁移现有 OpenAI SDK 代码

DeepSeek V3.2 和 V3.1 在 bedrock-mantle 上支持 Chat Completions，R1 不支持。AWS 的 API 兼容性表中明确标注：

• V3.2 / V3.1：Invoke + Converse + Chat Completions
• R1：Invoke + Converse

如果你团队已经有一套基于 OpenAI SDK 的服务，用 bedrock-mantle + Chat Completions 能极大降低迁移成本，只需要改 base URL 和 model 名称即可。

快速上手：DeepSeek on Amazon Bedrock

环境与账号准备

你需要准备：

• 一个可用的 AWS 账号
• 目标 Region 中已开通 Amazon Bedrock，并确认 DeepSeek 模型可用
• 具备 Bedrock 与 Bedrock Runtime 权限的 IAM 角色或用户
• Python 环境与 boto3
• AWS CLI（可选，但调试很方便）
• 标准 AWS 凭证，或 Bedrock API Key（仅适合探索与开发）
• 已配置的 Amazon Bedrock Guardrails（推荐）

AWS 文档中提到，Bedrock API Key 分短期和长期两类，更推荐把 API Key 用在探索和 PoC 阶段，真正的生产应用还是用短期凭证（如 STS）配合 IAM 做细粒度控制。

从控制台到代码的实战流程

一个比较稳的落地路径可以是：

1. 打开 Amazon Bedrock 控制台
2. 在模型目录或模型卡中找到 DeepSeek
3. 选择目标模型和 Region
4. 在 Playground 中用真实业务 prompt 做几轮测试
5. 使用 boto3 或 OpenAI 兼容 Chat Completions 写最小可用 Demo
6. 为高风险场景配置 Guardrails（敏感信息、违禁话题、RAG 校验等）
7. 监控输入/输出 tokens、延迟、错误率和成本

AWS 的 DeepSeek-R1 发布博客展示了一个典型流程：在 Playground 里选 R1，调试 prompt，然后点击“View API request”直接复制 AWS CLI 和 SDK 示例，这个功能对新手非常友好。

Python 示例：用 Converse API 调用 DeepSeek-R1

下面是通过 bedrock-runtime 调用 DeepSeek-R1 的 Python 示例：

import boto3
from botocore.exceptions import ClientError, BotoCoreError

REGION = "us-west-2"

# 对于 DeepSeek-R1，请在 Bedrock 控制台确认具体 ID。
# 某些区域/场景需要使用跨区推理 profile："us.deepseek.r1-v1:0"
MODEL_ID = "us.deepseek.r1-v1:0"

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

messages = [
    {
        "role": "user",
        "content": [
            {
                "text": (
                    "Explain the trade-offs between using Amazon Bedrock "
                    "managed models and self-hosting an open-weight model."
                )
            }
        ],
    }
]

try:
    response = client.converse(
        modelId=MODEL_ID,
        messages=messages,
        inferenceConfig={
            "maxTokens": 700,
            "temperature": 0.3,
            "topP": 0.9,
        },
    )

    output_text = response["output"]["message"]["content"][0]["text"]
    print(output_text)

except (ClientError, BotoCoreError, KeyError) as error:
    print(f"Failed to invoke model {MODEL_ID}: {error}")
    raise

小提醒：R1 在不同 Region 下可能需要 deepseek.r1-v1:0 或 us.deepseek.r1-v1:0，上线前务必对照 R1 模型卡和控制台确认，否则排错会非常浪费时间。

Python 示例：调用 DeepSeek V3.2

DeepSeek V3.2 同时支持 bedrock-runtime 与 bedrock-mantle，模型 ID 均为 deepseek.v3.2。

方案 A：使用 Boto3 Converse API

import boto3
from botocore.exceptions import ClientError, BotoCoreError

REGION = "us-east-1"
MODEL_ID = "deepseek.v3.2"

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

messages = [
    {
        "role": "user",
        "content": [
            {
                "text": (
                    "Create a production readiness checklist for deploying "
                    "a customer support chatbot on Amazon Bedrock."
                )
            }
        ],
    }
]

try:
    response = client.converse(
        modelId=MODEL_ID,
        messages=messages,
        inferenceConfig={
            "maxTokens": 900,
            "temperature": 0.2,
            "topP": 0.95,
        },
    )

    print(response["output"]["message"]["content"][0]["text"])

except (ClientError, BotoCoreError, KeyError) as error:
    print(f"Failed to invoke model {MODEL_ID}: {error}")
    raise

方案 B：通过 bedrock-mantle 使用 OpenAI 兼容 Chat Completions

如果你已经有一套基于 OpenAI SDK 的服务，可以这样迁移：

export OPENAI_API_KEY=""
export OPENAI_BASE_URL="https://bedrock-mantle.us-east-1.api.aws/v1"

from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="deepseek.v3.2",
    messages=[
        {
            "role": "user",
            "content": "Explain how Amazon Bedrock Guardrails can reduce AI application risk."
        }
    ],
)

print(response.choices[0].message.content)

AWS 在 V3.2 模型卡中也给出了类似示例，核心就是：用 Bedrock 的 API Key 和 OPENAI_BASE_URL 替换原来的 OpenAI 配置，模型名改为 deepseek.v3.2。

AWS CLI 示例：命令行调用 DeepSeek

可以用 AWS CLI 快速验证模型调用是否正常：

aws bedrock-runtime invoke-model \
  --region us-east-1 \
  --model-id deepseek.v3.2 \
  --cli-binary-format raw-in-base64-out \
  --body '{
    "messages": [
      {
        "role": "user",
        "content": "Summarize the security benefits of using DeepSeek through Amazon Bedrock."
      }
    ],
    "max_tokens": 700
  }' \
  deepseek-output.json

对于 DeepSeek-R1，AWS 的发布博客展示了使用 us.deepseek.r1-v1:0 作为跨区推理 modelId 的 CLI 示例，模式类似，只是模型 ID 不同。

DeepSeek 在 Amazon Bedrock 的价格

标准价格与区域差异

DeepSeek 在 Bedrock 上的价格取决于模型、Region 和服务层级。以 AWS 当前公布的 DeepSeek V3.2 为例，在美国东部和西部区域的标准按需价格为：

• 输入：每 100 万 tokens 0.62 美元
• 输出：每 100 万 tokens 1.85 美元

其他区域价格会有差异，且 AWS 会不定期调整，正式上线前一定要再看一眼官方价格页。

一个简单的成本测算示例

假设在美国区域使用 DeepSeek V3.2，标准按需价格下：

• 输入 tokens：100,000
• 输出 tokens：25,000
• 输入成本：100,000 / 1,000,000 × $0.62 = $0.062
• 输出成本：25,000 / 1,000,000 × $1.85 = $0.04625
• 预估总成本：$0.10825

成本提醒：这只是模型 token 的费用估算，不包含日志、存储、网络、Guardrails、Knowledge Bases、Marketplace 端点、SageMaker 端点或 EC2 等其他 AWS 资源费用。生产环境前，务必对照官方 Bedrock 价格页做完整 TCO 评估。

安全、隐私与合规要点

AWS 在数据保护上的承诺

AWS 文档中说明：

• Bedrock 不会存储或记录 prompt 与输出内容
• 不会使用这些内容训练 AWS 自有模型
• 不会将内容分发给第三方
• 模型提供方无法访问 Bedrock 模型部署账号

这为很多对数据主权敏感的行业（金融、医疗、政企等）提供了基础前提，但并不意味着你可以“无脑把所有数据丢给模型”。

生产环境推荐的安全实践

在生产环境中，可以考虑落实以下控制：

• 使用 IAM 最小权限策略
• 尽量使用短期凭证（STS、IAM Identity Center）
• 开启 CloudTrail 记录所有 Bedrock 调用
• 在需要时通过 PrivateLink 建立 VPC 私网访问
• 确保传输与存储加密（TLS + KMS）
• 不在 prompt、标签、名称、日志中放入明文密钥或高度敏感信息
• 在发送数据前做数据分级与脱敏
• 使用 Guardrails 过滤敏感信息与有害内容
• 在上线前做模型评估与红队测试
• 持续监控延迟、token 使用、拒答行为和幻觉情况

有用户反馈，在未做数据分级的情况下直接把内部工单全文发给模型，后面做数据治理时发现日志中残留了大量不该出现的敏感字段，清理成本极高。这类问题完全可以通过前置的分类与脱敏流程规避。

用 Amazon Bedrock Guardrails 保护 DeepSeek 调用

Guardrails 能做什么

Amazon Bedrock Guardrails 提供一套可配置的“安全护栏”，用于检测和过滤不良内容、保护敏感信息。主要组件包括：

• 内容过滤器（暴力、仇恨、色情等类别）
• 拒绝话题（业务自定义禁区）
• 词语过滤（禁用词、品牌保护等）
• 敏感信息过滤（PII 掩码或拦截）
• 上下文 Grounding 校验（RAG 回答是否基于可信知识库）
• 自动推理检查（基于策略的输出验证）

在 DeepSeek 场景下，Guardrails 特别适合：

• 面向 C 端用户的聊天机器人
• 涉及个人信息或业务机密的内部助手
• RAG 应用，需要确保回答不“瞎编”超出知识库
• 高风险领域（医疗、投顾、法律）需要强策略约束

Guardrails 配置的常见误区

AWS 的 DeepSeek + Guardrails 相关博客中提到，R1 等推理模型在高风险场景下应配合更严格的 Guardrails 与人工复核。实践中常见两个极端：

• 配置过严：大量正常请求被拦截，用户体验极差
• 配置过松：违规内容漏网，合规风险上升

最佳实践是：在上线前用真实 prompt、对抗性 prompt、多语言输入和边界场景做充分测试，接受一定比例的“可解释的误报”，而不是追求“零误报”。

部署路径：托管模型、Marketplace、Custom Import 与 SageMaker

Bedrock 托管与 Marketplace

Amazon Bedrock Marketplace 让开发者可以发现、订阅并在托管端点上部署 100+ 模型，同时仍然通过统一的 Bedrock API 与工具访问。DeepSeek 系列模型也在 Marketplace 中提供，适合希望按订阅方式管理成本的团队。

Custom Model Import 与 Distill 版本

Amazon Bedrock Custom Model Import 支持导入 DeepSeek-R1 的蒸馏 Llama 版本，例如：

• DeepSeek-R1-Distill-Llama-8B
• DeepSeek-R1-Distill-Llama-70B

这些模型可以从 Amazon S3 或 Amazon SageMaker AI 模型仓库导入到托管无服务器环境中。AWS 也通过 Bedrock Marketplace 和 SageMaker JumpStart 宣布了多款 DeepSeek-R1 蒸馏模型，参数规模从 1.5B 到 70B 不等，适合在成本、延迟和效果之间做更细粒度的权衡。

DeepSeek 在 Bedrock 上的典型场景

适合 DeepSeek 的业务用例

DeepSeek 在 Bedrock 上特别适合：

• 复杂推理与决策支持：如风控规则解释、运营策略模拟
• 代码生成与代码审查：CI/CD 中的自动代码建议与安全检查
• 数学与量化分析：财务模型计算、量化策略原型验证
• 技术文档与知识助手：面向开发者的内部知识库问答
• 多步骤流程编排：配合 Bedrock Agents/Flows 做多步任务拆解

我在一个 SaaS 客户项目里看到的效果是：把 DeepSeek V3.2 接入工单分析流程后，复杂问题的初次分诊准确率提升到 80% 以上，人工介入时间缩短了近一半。当然，这只是单个案例，但足以说明在“复杂推理 + 结构化输出”的场景里，DeepSeek 的优势很明显。

不那么适合的情况

也有一些场景，DeepSeek 未必是最优解：

• 极端低延迟、短文本补全（某些轻量模型更便宜更快）
• 对特定语言或领域有极强优化的专用模型
• 只需要简单分类或打标签的传统 ML 场景

在这些情况下，可以在 Bedrock 模型目录中对比其他模型的延迟、价格和评估结果，再做选择。

常见限制与排错思路

常见限制

在实际项目中，DeepSeek on Bedrock 常见的限制包括：

• 上下文窗口限制：V3.2 为 164K，V3.1/R1 为 128K，超出会报错或被截断
• 输出长度限制：最大 8K tokens，长文生成需要分段
• R1 不支持 Chat Completions：迁移 OpenAI SDK 时容易踩坑
• 区域与 modelId 不匹配：导致 4xx 错误
• 成本敏感场景：大模型长上下文会迅速推高账单

排错建议

遇到调用异常时，可以按这个顺序排查：

• 确认 Region 与 modelId 是否匹配
• 检查 IAM 权限是否包含 Bedrock 与 Bedrock Runtime
• 查看 CloudTrail 中的具体错误信息
• 打印完整请求体，确认 tokens 数量与参数配置
• 在 Playground 中复现同样的 prompt，看是否模型本身限制

一个可复用的小技巧：在 CI 中加一个“模型健康检查”步骤，定期用固定 prompt 调用目标模型，并记录延迟与错误率，一旦异常就告警。

DeepSeek 与其他 AWS 模型的对比视角

不要默认“DeepSeek 一定更好”

DeepSeek 只是 Bedrock 模型家族中的一员，AWS 模型目录还包括 Amazon、Anthropic、Meta、Qwen 等多家模型。直接假设“DeepSeek 一定更强”是个常见认知误区。

更合理的选择维度包括：

• 推理质量与稳定性
• 延迟与吞吐
• 成本与计费模式
• 上下文窗口大小
• 工具调用与函数调用支持
• 语言与领域适配度
• 安全与合规要求
• 部署路径（托管、Marketplace、SageMaker 等）

信息差在于：很多团队只在 Playground 里“主观感受”模型好坏，却忽略了 Bedrock 提供的评估工具，可以用客观指标对比不同模型在同一任务上的表现。

上生产前的最佳实践

Amazon Bedrock 的评估能力可以对模型、知识库和 RAG 流程进行系统测试，包括：

• 检查检索与生成的鲁棒性与正确性
• 评估幻觉率、覆盖率和相关性
• 对比不同模型在同一数据集上的表现

一个可复用的上线流程可以是：

• 选定 2–3 个候选模型（如 DeepSeek V3.2 + 另一家模型）
• 准备一批真实业务数据作为评估集
• 使用 Bedrock 评估工具跑多轮对比
• 结合主观体验与客观指标做最终选择
• 把评估结果沉淀为内部文档，供后续项目复用

这个评估方法在多个项目里被反复验证有效，值得收藏下来当成“上线前必做清单”。如果你正面临模型选型，这套流程往往比问身边人“你们用啥模型”更靠谱。

常见问题

Q：如何判断该选 DeepSeek V3.2、V3.1 还是 R1？

A：简单说：需要最新能力和 Chat Completions 兼容时优先 V3.2，偏好“混合思考 + 直接回答”风格可以试 V3.1，推理优先且不依赖 Chat Completions 时用 R1。判断时可以从三个维度看：一是接口需求，现有系统是否大量依赖 OpenAI SDK；二是任务类型，是偏代码、数学还是通用问答；三是延迟与成本，R1 在复杂推理上可能更稳但也更“啰嗦”。建议在 Playground 中用同一批真实业务 prompt 对三者做对比，再结合 Bedrock 评估结果做决定。

Q：在 Bedrock 中使用 DeepSeek，数据会被用来训练模型吗？

A：不会，AWS 文档明确说明 Bedrock 不会使用你的 prompt 和输出训练基础模型，也不会把数据分享给模型提供方。原因在于 Bedrock 采用了隔离的账户与加密机制，模型提供方无法直接访问你的部署环境。即便如此，仍然不建议把明文密钥、极度敏感的个人信息等直接放进 prompt 或标签中。可以通过数据脱敏、字段掩码和 Guardrails 的敏感信息过滤来降低泄露风险。

Q：如何控制 DeepSeek 在 Bedrock 上的成本不失控？

A：核心是“事前预算 + 事中监控 + 事后优化”三步。事前根据预估调用量和平均 tokens 数做粗略预算，并设置项目级别的成本告警；事中通过 CloudWatch 或自建监控记录每次调用的输入/输出 tokens、延迟和错误率；事后分析哪些场景 tokens 消耗最高，是否可以通过缩短上下文、压缩系统提示、拆分长任务来优化。对于高频调用场景，可以考虑蒸馏模型或更小参数模型，必要时做 AB 测试验证效果与成本的平衡点。

Q：现有基于 OpenAI 的服务迁移到 DeepSeek on Bedrock 难度大吗？

A：如果主要使用 Chat Completions 接口，迁移难度通常不高。原因是 Bedrock 通过 bedrock-mantle 提供了 OpenAI 兼容 API，你只需修改 base URL、API Key 和模型名称（如改为 deepseek.v3.2），大部分业务逻辑可以复用。不过要注意：不同模型在输出格式、token 限制和拒答策略上会有差异，迁移后需要针对关键流程做回归测试。建议先在灰度环境中双写一段时间，对比两边输出质量和用户反馈，再逐步切流量。

Q：DeepSeek-R1 不支持 Chat Completions，会影响哪些场景？

A：主要影响的是那些强绑定 OpenAI Chat Completions 协议的现有代码和 SDK。如果你的服务完全依赖 OpenAI 官方 SDK 的 chat.completions 接口，直接切到 R1 会比较麻烦，需要改用 Bedrock 的 Converse API。原因在于 R1 在 Bedrock 中只暴露 Invoke 和 Converse，没有 Chat Completions 兼容层。可行的做法是：为 R1 单独封装一层适配器，把内部消息格式统一成类似 Chat Completions 的结构，对上层业务屏蔽差异，同时在文档中明确标注“R1 走的是 Converse 通道”。