直接答案：今天所说的 Amazon SageMaker 可能指两个不同层级。原来用于构建、训练和部署机器学习模型的 Amazon SageMaker，已在 2024 年 12 月 3 日更名为 Amazon SageMaker AI；同日发布的新一代 Amazon SageMaker 则是把数据、分析、治理和 AI 汇集起来的统一平台。需要自定义训练脚本、容器、实例、模型制品和完整 ML 生命周期时，评估 SageMaker AI；只想通过托管 API 使用基础模型构建生成式 AI 应用时，通常先评估 Amazon Bedrock。
本文依据 AWS 的产品更名、Unified Studio、训练、推理、Pipelines、Model Registry、Model Monitor、安全和价格文档，于 2026 年 7 月 19 日复核。服务、功能、实例、配额与价格会按 Region 和账户变化。本站没有为本文开通 AWS 测试账户，也没有运行训练、延迟、吞吐、准确率或成本基准；文中的限制与流程来自官方资料，不会被描述成本站“实测”。
sagemaker API 名称仍可能出现在当前代码和控制台中。图：兰塞 AI 编辑部原创。Amazon SageMaker、SageMaker AI 和 Unified Studio 有什么区别？
AWS 的 SageMaker AI 更名说明明确：原 Amazon SageMaker 在 2024 年 12 月 3 日更名为 SageMaker AI，更名不改变原有功能。为保持向后兼容，API 命名空间、CLI 命令、带有 AmazonSageMaker 前缀的托管策略、服务端点、CloudFormation 资源、服务关联角色与部分 URL 仍保留旧名称。因此，代码里出现 boto3.client("sagemaker") 不代表代码使用的是“旧服务”。
同一份文档把新一代 SageMaker 定义为数据、分析和 AI 的统一平台，包含 SageMaker AI、Lakehouse、Data and AI Governance、SQL Analytics、Data Processing、Unified Studio 和 Bedrock 等能力。Unified Studio 用户指南则把它描述为供团队在项目中使用数据、分析、AI 与 ML 工具的统一开发体验。它是协作和访问入口，不会替用户自动解决数据许可、模型风险、IAM 与生产验收。
| 名称 | 当前含义 | 适合回答的问题 | 常见误解 |
|---|---|---|---|
| Amazon SageMaker AI | 原 Amazon SageMaker，更名后的 ML 服务 | 怎样训练、部署和管理自定义模型 | 以为 API 也全部改名 |
| Amazon SageMaker | 数据、分析、治理与 AI 统一平台 | 怎样统一数据访问、协作和 AI 工作 | 把它等同于一个训练服务 |
| SageMaker Unified Studio | 新 SageMaker 的统一开发与协作体验 | 团队怎样在项目边界内使用工具与数据 | 把 IDE 当成权限和治理本身 |
| Amazon Bedrock | 托管基础模型与生成式 AI 能力 | 怎样调用模型 API、RAG、Guardrails 或智能体 | 认为它是 SageMaker AI 的新名称 |
想先看 AWS AI 产品全景，可从站内AWS Bedrock、SageMaker 与 Amazon Q 选型指南开始；本文只深入 SageMaker AI 的训练、部署和生产治理。
应该选 SageMaker AI 还是 Amazon Bedrock？
AWS 官方决策指南的核心不是“谁更强”，而是谁承担模型开发与基础设施责任。Bedrock 适合通过托管 API 使用基础模型和平台能力；SageMaker AI 提供更细的模型、训练、容器、框架、实例和部署控制，相应地也要求更多 ML 与 AWS 专业能力。两者可以组合使用，但不要为了“全栈”而重复构建同一条链路。
| 需求 | 优先评估 | 原因 | 进入下一步前的证据 |
|---|---|---|---|
| 快速调用托管基础模型 | Bedrock | 模型 API 与生成式 AI 能力已托管 | 模型、Region、EULA、质量和成本通过 |
| 自带训练代码或算法 | SageMaker AI | 可控制训练容器、实例、数据和制品 | 训练可复现、配额与预算已核 |
| 训练传统分类、回归、时序模型 | SageMaker AI | 覆盖处理、训练、注册和多种推理方式 | 数据许可、基线和业务阈值明确 |
| 深度定制开源基础模型 | 先比较两者 | 取决于模型来源、控制粒度和运维能力 | 同一数据集的质量、延迟、成本与治理对比 |
| 企业知识助手或编码助手 | Amazon Q | 这是成品应用而非底层训练平台 | 连接器、身份、订阅和数据边界通过 |
如果目标是模型 API 与 RAG，阅读站内Amazon Bedrock 模型 API、价格与 RAG 指南；如果目标是现成的企业或开发助手，阅读Amazon Q Business 与 Developer 选型指南。产品选择应从任务与责任开始，而不是从 AWS 控制台里哪个入口最显眼开始。
用 SageMaker AI 训练模型需要准备什么？
SageMaker AI 训练架构说明，训练作业的核心是把 ML 工作负载容器化，并由服务配置计算资源。用户提供 S3 中的数据，选择内置算法、受支持框架脚本或自带容器；服务运行作业并把模型制品与输出写回指定位置。托管的是资源编排，不是数据正确性、目标函数、许可证或模型是否适合业务。
| 准备项 | 最低记录 | 验收问题 | 失败时不要做 |
|---|---|---|---|
| 数据 | 来源、许可、时间窗、版本、字段字典 | 能否重建同一训练集，是否存在泄漏 | 只上传一个无版本 CSV |
| 代码与容器 | 提交、镜像摘要、依赖、入口与参数 | 换账户或 Region 能否复现 | 只记录 Notebook 最终输出 |
| 算力 | 实例类型、数量、时长、配额、Spot 策略 | 是否会因配额或中断失败 | 用最大实例掩盖数据问题 |
| 指标 | 离线指标、切片、阈值、置信区间 | 是否与业务损失一致 | 只追求单一平均准确率 |
| 制品 | S3 URI、哈希、框架版本、签名与权限 | 部署的是不是被批准的同一制品 | 从个人目录手工复制“最新版” |
SageMaker AI 支持高层 Python SDK、Boto3、CLI 等入口。入门可用 Studio、Canvas、Autopilot 或 JumpStart，但低代码并不免除证据责任。数据输入还可能使用 File、Pipe 或 FastFile；应按数据规模、启动时间、磁盘与重读行为选择，而不是把默认模式当成永久最佳实践。训练前还要确认目标账户的 Service Quotas；出现 ResourceLimitExceeded 时，盲目重试不会创造配额。
一条可复核的训练流程应该怎样设计？
可靠流程要把“实验成功”与“可上线”分开。训练作业返回 Completed 只说明容器退出码和服务状态通过，并不能证明数据合法、模型优于基线或没有切片风险。建议从一个小而完整的垂直切片开始：固定数据版本，运行处理、训练、评估、注册和一次非生产推理，再验证删除与成本。
| 阶段 | 输入 | 应产出的证据 | 通过标准示例 |
|---|---|---|---|
| 问题定义 | 业务动作与损失 | 目标、禁止用途、人工兜底 | 错误类型和负责人明确 |
| 数据切分 | 时间、实体、标签 | 训练/验证/测试版本及泄漏检查 | 切分规则可重放 |
| 训练 | 数据、代码、镜像、参数 | 作业 ARN、日志、指标、制品 | 相同输入可得到可接受波动 |
| 离线评估 | 冻结测试集与业务切片 | 基线对比、误差样本、拒绝条件 | 关键切片均过阈值 |
| 批准 | 模型包与风险记录 | 版本、签名、审批人与时间 | 未批准版本不能进生产 |
不要把训练集指标复制到上线报告。对于会影响授信、医疗、就业、内容审核或安全的模型，应单独评估人群、地区、设备、时间段与缺失字段等切片，记录人工复核与申诉路径。需要理解模型和基础模型的层级关系，可参考站内基础模型选型与评测指南。
实时、无服务器、异步和批量推理怎么选？
AWS 当前推理选项文档列出四种方式：实时推理适合持续、低延迟或高吞吐在线流量；Serverless Inference 适合间歇或不可预测流量；Asynchronous Inference 适合大载荷和较长处理；Batch Transform 适合已有大批数据的离线处理。官方当前列出的载荷和时长上限会变化，且功能支持不完全相同，部署前必须查看推理功能矩阵。
| 方式 | 当前官方定位 | 主要成本形态 | 上线前必须测 |
|---|---|---|---|
| 实时推理 | 持久端点、持续流量、低延迟或高吞吐 | 端点实例运行时长、存储与数据 | 冷/热延迟、并发、扩缩、蓝绿回滚 |
| Serverless | 间歇或不可预测、可容忍冷启动 | 计算时长、内存、数据处理和预置并发 | 冷启动、突发、并发上限与功能缺口 |
| 异步推理 | 排队、大载荷、较长处理 | 端点实例、存储与数据；可配置缩到 0 | 队列积压、超时、重复、S3 与通知 |
| Batch Transform | 离线大批数据，无持久端点 | 批处理实例时长、存储与数据 | 分片、失败重跑、输出对齐与幂等 |
异步推理文档说明其请求通过 S3 载荷与队列处理，可把结果写入 S3，并可用 SNS 通知成功或错误。它不是“更慢的实时端点”：调用协议、结果获取、重试与幂等都不同。Serverless 也不是自动更便宜；如果持续高负载、需要预置并发或依赖不受支持的功能，常驻实例可能更合适。
怎样部署而不把一次成功请求误当成上线？
创建模型通常需要模型制品位置、推理镜像和执行角色。CreateModel 相关文档也允许从 Model Registry 的模型版本创建。这里的“模型”是部署配置实体，不等于训练算法、模型包、端点配置或端点本身；排障时要记录每一层的 ARN 和版本。
| 验收层 | 检查内容 | 证据 | 回滚触发 |
|---|---|---|---|
| 制品 | 哈希、来源、框架、序列化和签名 | 批准的模型包版本 | 制品不一致或无法加载 |
| 容器 | 镜像摘要、漏洞、启动、健康检查 | ECR 摘要与扫描记录 | 严重漏洞或启动失败 |
| 契约 | 输入输出 schema、错误码、超时 | 契约测试与反例 | 字段漂移或客户端不兼容 |
| 容量 | P95/P99、吞吐、并发、扩缩 | 目标流量压测记录 | 延迟、错误或排队超阈值 |
| 业务 | 质量、拒答、人工复核和损失 | 影子/灰度对照与样本 | 关键切片或安全阈值失败 |
生产切换应保留旧模型、旧端点配置和可验证的流量回退方式。仅测试 HTTP 200 不够：模型可能返回结构正确但业务错误的预测；客户端也可能把超时重试成重复动作。对于写入、审批或自动决策，必须设计请求 ID、幂等、超时后的状态查询和人工确认。
Pipelines 和 Model Registry 分别解决什么？
SageMaker AI Pipelines把处理、训练、评估、条件判断、注册等步骤表示为有依赖关系的 DAG，可通过 SDK、拖放界面或 JSON 定义。它能编排和记录步骤，但条件阈值仍由团队定义，错误的评估逻辑也会被稳定自动化。
Model Registry用模型组和递增版本管理模型包，可记录审批状态、部署历史与相关元数据。注册不是批准，批准也不是自动安全上线。要让“哪个模型在生产”可追溯，需要把训练作业、模型包版本、端点配置、发布单和代码版本关联起来。
| 组件 | 负责 | 不负责 | 建议门禁 |
|---|---|---|---|
| Pipelines | 步骤依赖、参数、缓存、条件和执行记录 | 判断业务目标是否正确 | 失败即停、产物不可手工替换 |
| Model Registry | 模型包分组、版本、状态和部署历史 | 自动证明模型合规 | 未批准版本禁止生产部署 |
| Experiments/MLflow | 实验、参数、指标和制品关联 | 代替独立测试集与业务复核 | 实验与发布版本可双向追溯 |
| CI/CD | 代码、基础设施和发布自动化 | 替代模型风险审查 | 代码、数据、模型门禁分别通过 |
Model Monitor 在 2026 年 7 月 30 日后怎么处理？
AWS Model Monitor 模型质量文档已经加入服务可用性变更通知：2026 年 7 月 30 日起停止向新客户开放，现有客户可继续使用，AWS 继续投入安全和可用性改进，但不计划新增功能。对正在使用的团队，这不是立即下线通知；对从未使用的新账户，则不能把教程中的“启用 Model Monitor”当成一定可执行的步骤。
Model Monitor 的模型质量监控也不是自动重训。它需要启用数据捕获、创建基线、计划监控任务、把真实标签写入 S3，再把预测与标签合并并输出指标。Model Dashboard能汇总数据质量、模型质量、偏差和特征归因漂移等结果，但告警后的调查、停用、回滚或重训仍是团队责任。
| 场景 | 2026-07-30 后策略 | 最低可替代组件 | 验证重点 |
|---|---|---|---|
| 已在用 Model Monitor | 继续使用，同时建立迁移清单 | 数据捕获、S3、CloudWatch、标签仓 | 功能、成本、告警和退出路径 |
| 新账户未使用 | 不要把它作为架构前提 | 日志/指标、计划计算、告警与工单 | 能否覆盖真实质量与切片 |
| 文本或图像模型 | 设计自定义质量与安全评测 | 采样、人工标注、规则和评估作业 | 语义错误、拒答、安全和漂移 |
| 高风险自动决策 | 加入人工复核与停机开关 | 阈值、审批、回滚、审计日志 | 错误能否被发现和撤回 |
监控设计应从“需要检测什么变化”出发：输入字段缺失、数据分布漂移、标签延迟、模型质量下降、服务延迟、错误率、成本、越权访问和异常输出不是同一种问题。没有 Ground Truth 标签时，不能把输入分布稳定等同于模型质量稳定；有告警时，也不能不分析根因就自动重训。
SageMaker AI 的成本怎么估算？
SageMaker AI 价格页说明可使用按需或 SageMaker Savings Plans，但“按使用付费”不等于只有训练作业产生费用。Notebook/Studio 应用、Processing、Training、调优、Feature Store、模型评估、端点、Serverless、监控、存储和数据处理都可能单独计费，外围的 S3、ECR、CloudWatch、KMS、NAT 与数据传输也要进入预算。
| 成本层 | 常见计量 | 最容易漏算 | 控制动作 |
|---|---|---|---|
| 开发 | Studio/Notebook 实例和存储时长 | 空闲应用未关闭、个人 EBS | 空闲策略、标签、预算和自动停机 |
| 处理与训练 | 实例类型、数量、作业时长和存储 | 失败重跑、调参乘数、数据准备 | 小样本验证、Spot、缓存与配额 |
| 推理 | 端点实例或 Serverless 时长/内存 | 多环境常驻、预置并发、空闲容量 | 按真实流量选模式与扩缩 |
| 监控与日志 | 处理任务、指标、日志、存储 | 高基数指标与长期保留 | 字段分级、采样和保留策略 |
| 网络与安全 | 数据传输、NAT、端点、KMS 请求 | 跨区、镜像拉取、私网出口 | 架构级流量表和账单标签 |
| 人力与风险 | 标注、复核、值班、事故与返工 | 把错误预测成本算作 0 | 计算每个合格预测的全链路成本 |
价格页上的示例不是你的报价。应在目标 Region 用当前单价建立三档情景：日常、峰值和失败/重跑；把开发、训练、推理、监控和外围服务分开。更有意义的比较指标是“每个通过业务验收的预测成本”，而不是单个实例小时的最低价格。模型 API 的通用预算与限流方法可参考站内模型 API 成本、限流与部署指南。
IAM、VPC、KMS 和日志应该怎样落地？
“完全托管”不改变 AWS 共享责任。训练与推理执行角色应只允许访问所需 S3 前缀、ECR 镜像、KMS 密钥和日志；开发者登录身份与作业执行角色要分开。训练作业 VPC 文档说明可把训练作业放入私有子网并通过安全组控制网络，但私网仍需为 S3、ECR、CloudWatch 等依赖设计 VPC 端点或受控出口。
SageMaker AI 静态加密文档说明，可为 Notebook、Processing、Training、调优、Batch Transform 和端点的 ML 存储卷指定 KMS 密钥；作业完成后，处理、训练与批量容器会终止并把输出写入 S3。指定自管密钥还意味着执行角色、密钥策略、跨账户访问与删除计划必须匹配。
| 边界 | 最低控制 | 应留证据 | 常见故障 |
|---|---|---|---|
| 身份 | SSO/MFA、最小权限、开发与执行角色分离 | 策略、信任关系、审批与访问日志 | 给 Notebook 管理员全权 |
| 数据 | S3 前缀、加密、版本、保留与删除 | 数据流、KMS、对象版本和责任人 | 训练输出对整个账户可读 |
| 网络 | 私有子网、安全组、端点与出口清单 | 流量图、DNS、端点策略和测试 | 断网后镜像或依赖无法拉取 |
| 镜像 | 固定摘要、扫描、签名和基础镜像更新 | ECR 摘要、SBOM 和漏洞处置 | 生产使用可变 latest 标签 |
| 日志 | 字段脱敏、访问、保留、告警与导出 | CloudTrail/CloudWatch 配置与样例 | 把原始敏感输入完整写日志 |
不要把长期访问密钥写入 Notebook、镜像、模型制品或网页代码；优先使用短期凭证和执行角色。高敏感数据还应验证容器能否访问公网、日志是否带输入样本、失败请求是否进入死信路径，以及删除模型后 S3、日志、缓存、快照和备份是否仍保留副本。
中国用户使用 SageMaker AI 要注意什么？
AWS 中国区由本地运营方运营，账户、合同、账单、控制台和服务可用性与 AWS 商业区分开。不能用商业区文档中的一个功能名称推断北京或宁夏 Region 已支持，也不能假定模型、实例、Studio 体验和周边服务完全一致。应在AWS 中国区区域产品服务表、目标账户控制台、配额页和中国区价格页逐项复核。
| 检查项 | 商业区证据 | 中国区必须重新确认 | 记录方式 |
|---|---|---|---|
| 账户 | 组织、IAM 与付款设置 | 中国区独立账户、合同和实名认证 | 账户/运营方/责任人 |
| Region | 功能与实例表 | 北京/宁夏实际服务、实例和配额 | 控制台截图与复核日期 |
| 依赖 | S3、ECR、KMS、CloudWatch 等 | 每个依赖的可用性和端点 | 部署前依赖矩阵 |
| 镜像与代码 | 商业区仓库和示例 | 镜像复制、域名、包源与出口 | 固定摘要和来源 |
| 数据 | 全球架构假设 | 跨境、合同、备案和组织政策 | 法务/安全批准与数据流图 |
如果业务要求数据留在特定区域，应从每一条实际数据路径验证，而不是引用“云服务安全”作为结论。训练数据、模型制品、镜像、日志、指标、备份、人工标注、支持工单和开发者下载都可能形成额外路径。
新项目怎样用最小 PoC 验证 SageMaker AI？
PoC 的目标不是展示一个漂亮 Notebook，而是用最小资源暴露真实风险。选择一个有明确标签、基线和人工兜底的任务；固定一小份合法数据；用一条可重复的处理和训练作业产生模型包；选择一种推理方式；再从外部客户端完成契约、容量、质量、成本、权限和删除验证。
| PoC 步骤 | 输出 | 通过条件 | 停止条件 |
|---|---|---|---|
| 1. 任务与基线 | 业务指标、基线模型、禁止用途 | 改善可量化且值得自动化 | 无法定义错误成本 |
| 2. 最小数据 | 版本化数据与切分 | 许可、泄漏、质量检查通过 | 来源或标签不可核验 |
| 3. 可复现训练 | 代码、镜像、作业、制品 | 从清洁环境可重放 | 依赖个人 Notebook 状态 |
| 4. 推理验收 | 端点/批任务与契约测试 | 质量、延迟、错误与成本过线 | 只能演示单条请求 |
| 5. 治理与退出 | 审批、告警、回滚、删除记录 | 故障可止损，资源可清除 | 没有责任人或退出路径 |
需要自动执行动作的模型，还应参考站内AI 智能体权限、工具与企业治理指南，把模型预测与外部写入、支付、发送、审批等动作隔离。模型准确率高并不等于动作权限可以放大。
上线前应检查哪些门禁？
上线门禁应能被另一名工程师复核，并能回答“哪个数据、哪个代码、哪个镜像、哪个模型、哪个端点、谁批准、如何回滚”。下面的清单不是合规保证，而是避免把演示直接推入生产的最低工程证据。
| 门禁 | 必须有 | 不通过时 |
|---|---|---|
| 需求 | 任务、边界、错误损失、人工兜底和负责人 | 退回问题定义 |
| 数据 | 来源、许可、版本、泄漏检查、删除与切片 | 停止训练或更换数据 |
| 模型 | 基线对比、关键切片、误差样本和版本 | 拒绝注册/批准 |
| 安全 | IAM、VPC、KMS、镜像、日志与密钥检查 | 阻止部署 |
| 服务 | 契约、P95/P99、容量、限流、重试和幂等 | 回到负载或架构设计 |
| 运营 | 指标、标签、告警、工单、值班和回滚演练 | 保持非生产状态 |
| 成本 | 日常/峰值/失败情景、预算与资源标签 | 缩小范围或改推理方式 |
| 退出 | 端点、模型、S3、日志、镜像和密钥删除清单 | 不得声称可安全结束试验 |
代码和模型的生产发布还应有可回滚的版本策略。可参考站内AI 编程工具与代码交付指南了解代码审查、测试和变更证据；如果工作流涉及多个工具和长任务，参考AI 工作流自动化的可靠性设计，不要让一次超时触发重复写入。
每次发布还应保存失败样本、请求 ID、模型包版本、端点配置、镜像摘要、关键指标快照和回滚结果。发生事故时，团队才能区分数据变化、模型退化、容量不足、客户端重试、权限错误与基础设施故障；如果只保留最终成功截图，后续既无法复盘，也无法证明修复真正覆盖了根因。
常见问题
SageMaker 现在是不是已经被 SageMaker AI 取代？
不是简单取代。原来的机器学习服务更名为 SageMaker AI；新一代 SageMaker 是包含 SageMaker AI 在内的统一数据、分析和 AI 平台。旧 API、CLI、CloudFormation 和角色名称仍可能保留 sagemaker。
SageMaker AI 能直接调用大语言模型吗？
可以通过 JumpStart、自带模型或自带容器等方式部署适合的模型，但需要承担实例、镜像、模型制品、推理与运维责任。若主要需求是调用托管基础模型 API、RAG、Guardrails 或生成式 AI 能力，先比较 Bedrock，避免重复建设。
Serverless Inference 一定更便宜吗？
不一定。它适合间歇或不可预测流量，并可减少空闲实例成本，但冷启动、预置并发、功能限制、处理时长和持续高负载可能改变结论。应按真实流量计算每个合格预测的全链路成本。
Model Monitor 会自动修复漂移吗？
不会。它可以按配置捕获数据、运行监控任务、计算指标并告警；标签获取、根因分析、回滚、数据修复和重训仍需团队设计。2026 年 7 月 30 日后，它还将停止向新客户开放。
删除端点后是不是就不再计费？
端点实例费用会随资源状态变化，但模型、端点配置、Studio 应用、Notebook、EBS、S3、ECR 镜像、日志、监控、快照、KMS 与外围网络资源可能仍存在。必须按资源清单验证账单和删除结果。
怎样判断 PoC 可以进入生产？
至少要有可复现数据与训练、独立测试集、关键切片、批准的模型版本、契约与容量测试、最小权限、成本情景、运行告警、人工兜底、回滚演练和删除路径。Notebook 中的一次成功预测不构成生产证据。
来源与复核记录
本文主要依据 AWS 官方的 SageMaker AI 概览与更名、Unified Studio 术语、训练架构、推理选项、Serverless Inference、异步推理、Pipelines、Model Registry、Model Monitor 可用性变更、Model Dashboard、VPC 配置、静态加密与价格页整理。
编辑复核与纠错记录：本文由兰塞 AI 编辑流程于 2026 年 7 月 19 日复核。旧稿没有反映 2024 年产品更名与新 SageMaker 平台边界，也没有说明推理方式、Model Monitor 可用性变化、完整成本与生产责任。新版用可核验的产品图、选型表、推理路由和上线门禁替换泛化宣传；如 AWS 后续调整服务可用性、限制或价格，将以官方文档和页面复核日期为准。本站的来源、更新与纠错原则见关于本站与编辑规范。
