假如你要开一家连锁餐厅，从买菜、洗菜、炒菜、调味、出餐到巡店，全都要自己盯着，很快会手忙脚乱。AWS SageMaker 就像一位全能的“中央厨房管家”：它不管你的菜谱是什么，但帮你把备菜、掌勺、试味、出餐、品控、排宴、搬厨房、算账这八件事串成一条流水线。你只需要告诉它“今天想做什么菜”，它就会把食材、灶台、厨师和出餐窗口安排得明明白白。本文就用这家中央厨房做向导，从数据准备讲到模型部署、监控、迁移和成本优化，把 SageMaker 的全流程一次看清。

岗位关联

对 AI 从业者而言，理解 SageMaker 全流程，等于拥有了一套把模型从实验台送上生产线的标准打法，是转型 MLOps 与云架构师的关键一步。

目录
  1. 可视化演示
  2. 数据准备
  3. 训练作业
  4. 自动调参
  5. 模型部署
  6. 评估监控
  7. 端到端流程
  8. 多云迁移
  9. 成本优化
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

数据准备

一家餐厅后厨的规矩是：食材先洗切再下锅。模型也一样，原始数据如果不做清洗和拆分，后面所有环节都会带着杂质。SageMaker 把这部分工作设计成“备菜间”：先用可视化工具快速探查数据，再用可编程任务做大规模处理，最后按比例切出训练集和验证集。

数据准备阶段的两个主力是 Data Wrangler 和 Processing Jobs。Data Wrangler 像一块可视化砧板，你拖拽几步就能完成缺失值补全、去重、格式转换；Processing Jobs 则是可以定制的切菜流水线，你把一段 Python 或 SQL 脚本交给它，它在托管集群上跑完，再把干净数据写回 S3。特征工程也在这里完成，比如把日期拆成星期、把类别做编码。

切好菜后还要分桌：不能把同一批食材既当训练又当验证。通常按 80/20、70/30 等比例拆分，或在类别不平衡时做分层抽样。SageMaker 支持在 Processing 脚本中统一完成拆分，并给训练集、验证集打上标签，方便后续训练作业直接读取。拆分比例可以用下面这个简单公式表达：

备菜间忙完了，后厨才敢开火。数据干净、切分合理，后续的训练与评估才不会翻车。

∣Dtrain∣=⌈α∣D∣⌉,∣Dval∣=∣D∣−∣Dtrain∣,0<α<1\displaystyle |D_{\text{train}}| = \lceil \alpha |D| \rceil, \quad |D_{\text{val}}| = |D| - |D_{\text{train}}|, \quad 0<\alpha<1
通俗理解：先把全部食材看作一筐菜，按比例拿出大部分做训练，剩下的留作验收员尝菜。
  1. 总样本集合 D表示整个数据集，|D| 是它的样本条数，也就是一筐菜里有多少棵菜。
    ∣D∣|D|
  2. 训练比例 α表示留出多少比例作为训练数据，α=0.8 就是留 80% 给模型学习。
    α\alpha
  3. 训练集大小用向上取整保证样本数不会因为比例出现小数，避免“半条数据”的尴尬。
    ∣Dtrain∣=⌈α∣D∣⌉|D_{\text{train}}| = \lceil \alpha |D| \rceil
  4. 验证集大小总数减去训练集，保证两部分不重叠，验证集才能公正地扮演评菜员。
    ∣Dval∣=∣D∣−∣Dtrain∣|D_{\text{val}}| = |D| - |D_{\text{train}}|

训练作业

厨师炒菜不会只靠一口锅，不同菜式要选不同灶台。SageMaker 里，一次训练就是一次“灶台租用”：你指定菜谱（算法）、锅型（实例类型）和几个灶眼（实例数量），训练作业就会自动开火、计时、熄火，并把煮好的模型放到 S3 这个冰箱里。

训练作业是 SageMaker 的核心执行单元。你可以直接用内置算法，也可以把自己的代码打包成 Docker 容器，SageMaker 会在 EC2 实例上拉起任务、监控日志、保存检查点。需要分布式训练时，只要增加实例数量，服务会自动协调多机通信。训练期间，CloudWatch 会记录 CPU、GPU、内存和自定义指标，像厨师长盯火候一样盯着每个灶眼。

训练结束后的产物是模型工件和推理脚本，统一放进 S3。计费方式也很好理解：灶台越多、炒得越久，账单越贵。估算训练成本的公式是：

训练作业把“掌勺”这件事变成了可重复、可计费的标准化操作，厨师只要关心菜谱，不用亲自守着灶台。

C=n×r×t\displaystyle C = n \times r \times t
通俗理解：总成本 = 灶台数量 × 每小时租金 × 开火时长，按实际用量付费。
  1. 实例数量 n同时开几个灶眼，分布式训练时通常大于 1。
    nn
  2. 单价 r每个实例每小时的租赁价格，不同 CPU/GPU 实例价格不同。
    rr
  3. 训练时长 t作业从启动到结束的小时数，包含启动与收尾的少量开销。
    tt
  4. 总成本 C三个量相乘，单位是“实例小时 × 单价”，直观对应云账单。
    C=n×r×tC = n \times r \times t

自动调参

一位好厨师不会只试一次咸淡。自动调参作业就像试菜员，他一次端出十几盘不同组合的菜，尝完用同一把尺子打分，然后留下最优组合，其余倒掉。SageMaker 的 Hyperparameter Tuning Jobs 就是这样的试菜员。

你可以定义搜索空间，比如学习率在 0.001 到 0.1 之间选值、隐藏层数量在 2 到 6 之间选值。调参作业会并行启动多组训练任务，使用随机搜索、网格搜索或贝叶斯优化策略，不断尝试新组合，并用验证集上的目标指标淘汰劣选，配合早停机制节省计算资源。

目标指标通常不止一个。例如既要准确率高，又要推理延迟低，就可以把多个指标加权成一个综合分。为了不让量纲影响权重，各指标需要先做归一化。综合评分可以写成：

自动调参不是魔法，它只是把“尝菜”这件事变成可并行的实验，最后仍然要用业务数据做最终验收。

Score=∑k=1Kwkmk,∑k=1Kwk=1\displaystyle \text{Score}=\sum_{k=1}^{K}w_k m_k,\quad \sum_{k=1}^{K}w_k=1
通俗理解：把“咸度得分”“香气得分”“卖相得分”各自乘上权重再相加，权重代表你有多在乎这个指标。
  1. 指标 m_k每个归一化后的评估指标，比如精确率、召回率、延迟得分。
    mkm_k
  2. 权重 w_k表示第 k 个指标的重要程度，业务越看重，权重越大。
    wkw_k
  3. 权重归一化所有权重加起来等于 1，保证综合分在一个可比较的区间内。
    ∑k=1Kwk=1\sum_{k=1}^{K}w_k=1
  4. 加权求和把每个指标值乘上权重再累加，得到最终用于选模型的分数。
    Score=∑k=1Kwkmk\text{Score}=\sum_{k=1}^{K}w_k m_k

模型部署

菜炒好了，不能一直放在后厨。模型部署就是“出餐窗口”：机器训练出来的成果必须端到用户面前，才能产生价值。SageMaker 提供了两种出餐方式：实时端点像是堂食窗口，请求来了马上响应；批量转换像是宴会外卖，夜间统一做一大桌再送货。

实时端点适合在线推理，比如推荐系统、聊天机器人和风险拦截。它背后是常驻的推理实例，支持配置多个模型副本，并通过自动扩缩容应对高峰期。批量转换适合离线预测，比如每天半夜对全量客户打分，按批处理任务运行，用完后实例自动释放，成本更低。

出餐窗口要防排队，这里有一个最简单的容量估算思路：如果平均每个请求处理时间是 L 秒，每秒到达 Q 个请求，那么同时进行中的请求数大约是 Q×L；用单实例最大并发 C 一除，就能估算实例数：

部署之后，菜已经上桌，但真正的考验才刚刚开始：客人会不会满意？菜品有没有变质？这就轮到品控员登场。

N=⌈Q×LC⌉\displaystyle N=\left\lceil\frac{Q \times L}{C}\right\rceil
通俗理解：需要的服务员数量 = 同时要上几道菜 ÷ 一个服务员能同时端几道菜，多出的就取整加一。
  1. 每秒请求数 Q在线服务的请求压力，也就是高峰时段每秒钟来多少桌客人点菜。
    QQ
  2. 平均延迟 L单个请求从进入端点到返回结果的平均秒数，相当于上一道菜要多久。
    LL
  3. 单实例并发 C一个实例能同时处理的请求上限，相当于一个服务员最多能端几道菜。
    CC
  4. 实例数量 N用必要的并发请求数除以单实例并发能力，结果向上取整，保证不多配也不少配。
    N=⌈Q×LC⌉N=\left\lceil\frac{Q \times L}{C}\right\rceil

评估监控

训练时模型表现很好，不代表上线后永远合格。评估监控就像品控员，站在出餐口后面，既检查菜的味道，也盯着菜品有没有随着时间变味。SageMaker 用 Model Registry 管理模型版本，像菜谱档案一样记录谁在哪天用了什么数据训练、评估分数是多少。

上线前，要在独立的验证集或测试集上算指标；上线后，还可以用 A/B 测试比较新旧模型。SageMaker 支持把流量按比例切给不同端点，让数据说话。更关键的是数据漂移检测：当线上输入数据的分布和训练时差别变大，模型准确率可能悄悄下降，这时候 CloudWatch 告警会自动拉响，提醒团队重新训练。

分类模型最常用的综合指标之一是 F1 分数，它同时照顾精确率和召回率，防止模型“偏科”：

品控员不会只盯一道菜，而是盯一整条流水线。从备菜到出餐，所有环节必须能自动衔接，这才有了端到端流程。

F1=2×P×RP+R\displaystyle \text{F1} = \frac{2 \times P \times R}{P + R}
通俗理解：精确率是“端上桌的菜里有多少是对的”，召回率是“该上的菜里有多少被端上去了”，F1 是两者的调和平均。
  1. 精确率 P预测为正类的样本中，真正例所占比例，代表端上桌的菜别端错。
    PP
  2. 召回率 R所有真正例中被找出来的比例，代表该上的菜别漏掉。
    RR
  3. 分子 2×P×R放大“两者都高”的组合，惩罚一个指标拖后腿的情况。
    2×P×R2 \times P \times R
  4. 分母 P+R将两个率相加做归一化，最终把 F1 控制在 0 到 1 之间。
    F1=2×P×RP+R\text{F1} = \frac{2 \times P \times R}{P + R}

端到端流程

办一场宴席，不能各自为战：凉菜、热菜、汤和甜品要按顺序上桌。机器学习同样需要端到端流程，SageMaker Pipelines 就像宴席总导演，把数据处理、训练、调参、评估、注册、部署等步骤编排成一张有向无环图，哪个步骤先跑、哪个步骤可以并行，都由它统一调度。

流水线的每一步都是可以重试、可以追踪的任务。数据版本、模型版本、训练参数和评估结果都会被记录成血缘关系，方便回看“这道菜是谁做的”。工程团队还可以把流水线接入 CI/CD，当训练代码变化或数据更新时，自动触发新的全流程，让模型上线变成可重复的规范动作。

流水线总耗时可以用关键路径来理解：所有从起点到终点的路径中，用时最长的那条决定了整个宴席什么时候能上齐。每条路径耗时是各步骤耗时之和：

流水线让整家餐厅有了标准作业流程，也让换到新厨房开店成为可能。于是，多云迁移的问题出现了。

Tpipeline=max⁡p∈P∑j∈pTj\displaystyle T_{\text{pipeline}}=\max_{p \in \mathcal{P}}\sum_{j \in p} T_j
通俗理解：多个步骤可以同时进行时，只有最慢的那条链路说了算，就像炖汤没熟，其他菜再快也得等它。
  1. 步骤耗时 T_j流水线中第 j 个步骤预计需要的时间，单位一般是分钟或小时。
    TjT_j
  2. 一条路径 p从流水线开始到结束经过的一组步骤，不同分支会形成不同路径。
    p∈Pp \in \mathcal{P}
  3. 路径总耗时把一条路径上所有步骤耗时相加，得到该路径完成需要的总时间。
    ∑j∈pTj\sum_{j \in p} T_j
  4. 最大值运算在所有路径中取最大耗时，就是流水线的关键路径，决定整体时长。
    Tpipeline=max⁡p∈P∑j∈pTjT_{\text{pipeline}}=\max_{p \in \mathcal{P}}\sum_{j \in p} T_j

多云迁移

中央厨房做大了，可能要搬去另一个城市开分店。问题在于，SageMaker 的部分服务像定制的厨具，换了厨房不一定能用。Data Wrangler、Studio、Endpoints 这些完全托管的服务与 AWS 深度绑定，而模型工件和标准化的推理容器镜像则更像可以带走的菜谱和半成品。

迁移前需要做“搬厨房检查”：梳理哪些组件是 AWS 专有的，哪些是标准开放的。常用的策略是把训练产物标准化，比如把模型导出为 ONNX、PMML 或打包进自定义容器，推理层用 KServe 这类开源方案替代，业务侧只改少量调用接口。迁移过程中，还可以让新老环境并行运行一段时间，灰度切换流量。

任何迁移都有风险，比如配置差异、数据权限不同、延迟变化。假设每个独立风险点发生的概率是 r_i，所有风险同时都不发生的概率是每个“不发生时概率”的乘积，那么整体迁移失败概率就是：

迁移不是从头再来，而是把能带走的带走、不能带走的替换，最后还要留好后路，才能在“新厨房”里安心营业。

R=1−∏i=1n(1−ri)\displaystyle R=1-\prod_{i=1}^{n}(1-r_i)
通俗理解：每个环节都有出错可能，环节越多，某个环节出错的整体概率越高，因此每一步都要单独设防。
  1. 单个风险 r_i第 i 个迁移步骤失败或出问题的概率，比如权限配置错误。
    rir_i
  2. 不发生风险的概率1-r_i 表示这个环节平安无事，类似每次搬家都不打碎碗的概率。
    1−ri1-r_i
  3. 全部环节都平安把所有“不发生的概率”相乘，得到整条链路没有出错的概率。
    ∏i=1n(1−ri)\prod_{i=1}^{n}(1-r_i)
  4. 整体风险 R用 1 减去“全部平安”的概率，就是至少一个环节出问题的整体风险。
    R=1−∏i=1n(1−ri)R=1-\prod_{i=1}^{n}(1-r_i)

成本优化

开餐厅要精打细算，不能所有的灶台都二十四小时开着。SageMaker 的成本优化同样围绕“按需付费”和“资源释放”展开。训练作业如果用按需实例，就像包下一整间厨房，随开随停；如果使用竞价实例，就像打听客流量低的时段租打折灶台，价格更低但可能随时被回收。

对于训练这类可以断点续跑的任务，竞价实例很划算；对于实时端点这类不能中断的服务，更适合按需实例加自动扩缩容。SageMaker Studio 里的闲置笔记本、未关掉的 Notebook 实例，也都是账单上的“潜伏者”，需要设置自动关闭策略。每一笔成本，最终都能从账单明细里找到对应资源。

竞价实例的省钱效果可以用一个比例直观表达：

成本优化不是拼命砍预算，而是让每一分钱都花在真正出菜的地方。账算清楚了，中央厨房才能长久经营。

S=1−CspotCon-demand\displaystyle S=1-\frac{C_{\text{spot}}}{C_{\text{on-demand}}}
通俗理解：如果竞价灶台每小时租金是按需灶台的 40%，那么节约率就是 1 - 0.4 = 60%。
  1. 竞价价格 C_spot训练类任务使用竞价实例时的单位成本，通常是按需价格的一个折扣。
    CspotC_{\text{spot}}
  2. 按需价格 C_on-demand不享受折扣、随时可用的标准实例价格。
    Con-demandC_{\text{on-demand}}
  3. 价格比竞价价格除以按需价格，得到你实际支付的比例。
    CspotCon-demand\frac{C_{\text{spot}}}{C_{\text{on-demand}}}
  4. 节约率 S用 1 减去价格比，得到节省下来的成本比例。
    S=1−CspotCon-demandS=1-\frac{C_{\text{spot}}}{C_{\text{on-demand}}}

AI 应用场景

电商推荐模型的全流程上线

阶段：数据准备 → 训练作业 → 自动调参 → 模型部署 → 评估监控

解决的问题：传统方式下，特征工程和模型训练散落在不同平台，上线靠手工操作，周期长且容易出错。用 SageMaker 后，从用户行为日志进入 S3 开始，Data Wrangler 完成清洗，Processing Jobs 做特征拼接，Training Jobs 训练模型，Tuning Jobs 调参，最后部署到实时端点，并在 CloudWatch 监控点击率与数据漂移。

具体案例：某电商平台每天有数亿条用户点击数据，团队用 SageMaker Pipelines 把推荐模型的更新频次从每周一次提升到每天一次，夜间自动训练，凌晨发布新模型，早高峰前完成部署。

金融欺诈模型的多云迁移

阶段：模型产物标准化 → 兼容性评估 → 灰度切换 → 回滚

解决的问题：SageMaker 托管服务与 AWS 深度绑定，直接搬到其他云平台会面临接口不兼容、权限体系不同、模型服务方式差异等风险。把模型导出为标准格式并打包成自定义容器，可以降低迁移成本。

具体案例：某支付公司在从 AWS 迁移到混合云时，将训练好的欺诈检测模型转为 ONNX，推理层替换为 KServe，线上先切 10% 流量观察效果，确认无误后逐步放大，并保留 SageMaker 端点作为回滚方案。

制造业质检模型的批量预测

阶段：批量数据准备 → 批量转换 → 结果汇总 → 成本释放

解决的问题：工厂每天夜间产生大量产品图像，不需要实时响应，但如果全部用实时端点，空闲时段会浪费成本。通过 SageMaker Batch Transform，按批处理任务在低峰期运行，任务结束后自动释放实例。

具体案例：某制造商用 SageMaker 训练缺陷检测模型，每晚定时对十万张质检图做批量预测，输出结果写入 S3 质检报表，月底统计显示推理成本比常驻端点降低约 50%。

Python 演示

python58 行
import random random.seed(42)  def build_dataset(sample_count=100):    x_values = [i / (sample_count - 1) for i in range(sample_count)]    y_values = [3.0 * x + 0.5 + random.uniform(-0.05, 0.05) for x in x_values]    return x_values, y_values  def train_linear_model(x_train, y_train, epochs=200, learning_rate=0.1):    weight = 0.0    bias = 0.0    for _ in range(epochs):        weight_grad = sum(            (weight * x + bias - y) * x for x, y in zip(x_train, y_train)        ) / len(x_train)        bias_grad = sum(            weight * x + bias - y for x, y in zip(x_train, y_train)        ) / len(x_train)        weight -= learning_rate * weight_grad        bias -= learning_rate * bias_grad    return weight, bias  def evaluate_model(weight, bias, x_data, y_data):    return sum(        (weight * x + bias - y) ** 2 for x, y in zip(x_data, y_data)    ) / len(x_data)  def simulate_sagemaker_pipeline():    x_values, y_values = build_dataset()    split_point = int(len(x_values) * 0.8)    x_train = x_values[:split_point]    y_train = y_values[:split_point]    x_val = x_values[split_point:]    y_val = y_values[split_point:]    print("[data-prep] train samples:", len(x_train), "val samples:", len(x_val))     best_model = None    for learning_rate in [0.01, 0.1, 0.5]:        weight, bias = train_linear_model(            x_train, y_train, learning_rate=learning_rate        )        loss = evaluate_model(weight, bias, x_val, y_val)        print("[tuning] lr =", learning_rate, "val loss =", round(loss, 4))        if best_model is None or loss < best_model[2]:            best_model = (weight, bias, loss)     weight, bias, loss = best_model    print("[deploy] predict x=1.5 ->", round(weight * 1.5 + bias, 3))    print("[monitor] final val loss:", round(loss, 4))  if __name__ == "__main__":    simulate_sagemaker_pipeline()
目的：用纯 Python 模拟 SageMaker 的“备菜、训练、调参、部署、监控”主流程，帮助理解各阶段如何衔接。
  1. split_point = int(len(x_values) * 0.8)把数据集按 80/20 分成训练集和验证集，对应备菜间的切分动作。
  2. train_linear_model(...)用梯度下降训练一个简单线性回归模型，对应 SageMaker Training Jobs。
  3. for learning_rate in [0.01, 0.1, 0.5]模拟自动调参，用几组不同学习率做实验。
  4. if best_model is None or loss < best_model[2]用验证集 loss 淘汰劣势候选，保留最优模型。
  5. print("[deploy] predict x=1.5 ->", ...)用最优模型做推理，相当于把模型放到端点出餐。

常见误区

误区很多初学者打开 SageMaker Studio 看到的是 Jupyter 界面，就以为 SageMaker 等于“云上写代码的笔记本”，训练也必须在笔记本里进行。

正解Studio 只是入口，真正的全流程由 Data Wrangler、Processing Jobs、Training Jobs、Hyperparameter Tuning、Pipelines、Endpoints 等模块组成。笔记本更像厨师手边的便签，备菜和掌勺都另有其人。

为何常见：官方教程和演示视频都从 Studio 界面开始，视觉冲击最强，容易让人以偏概全。

误区有人以为用一次 SageMaker Hyperparameter Tuning 得到最优参数，模型就可以一直用下去，不需要再关注线上表现。

正解业务数据的分布会随时间变化，模型上线后可能出现数据漂移，原来的最优参数也会慢慢失效。正确做法是把调参纳入流水线，定期用新数据触发重新训练与评估。

为何常见：调参作业输出“最佳训练作业”的称呼，容易给人一种一劳永逸的错觉。

误区刚接触 SageMaker 的人以为只要创建了实时端点，系统就会根据流量自动伸缩，不需要任何额外配置。

正解自动扩缩容必须显式配置 Application Auto Scaling 策略，包括最小实例数、最大实例数和目标指标。没有策略的端点在高流量下仍会排队或超时。

为何常见：云服务名称里带着“自动”二字，用户容易高估托管服务的默认行为。

误区认为 SageMaker 训练好的模型和流水线可以直接在其他云厂商运行，最多改一下密钥。

正解模型工件和标准容器可以带走，但 Data Wrangler、Endpoints、Studio、Pipelines 等服务与 AWS 深度绑定，需要替换或重构。迁移前要做兼容性评估、灰度切换和回滚方案。

为何常见：模型本身是开放文件，容易让人忽略周边托管服务的强耦合。

面试题

Q1. SageMaker 中负责数据清洗与特征工程的主要模块是？

单选题 · easy

  • A.数据准备工具 Data Wrangler← 正确答案
  • B.在线推理服务 Endpoints
  • C.模型注册表 Model Registry
  • D.超参调优作业 Tuning Job

答案：A。Data Wrangler 专门负责数据整理和特征工程，Endpoints 管上线推理，Model Registry 管版本，Tuning Job 管调参。记忆口诀是“备菜找 Data Wrangler，出餐找 Endpoints”。

Q2. 训练作业使用了 n 个实例、每个实例每小时单价 r、训练时长 t，总费用公式是？

单选题 · easy

  • A.总费用等于单价乘时长
  • B.总费用等于单价乘实例数再乘时长← 正确答案
  • C.总费用只取决于实例数量
  • D.总费用只取决于训练时长

答案：B。SageMaker 按实例小时计费，多个实例并行时费用需要再乘实例数。类比中央厨房：三个灶台开两小时，费用就是单灶时长的三倍。

Q3. 关于 SageMaker 自动调参，下列说法合理的是？

多选题 · mid

  • A.自动调参同时尝试多个组合← 正确答案
  • B.验证指标可以淘汰劣势候选← 正确答案
  • C.调参完成后无需线上监控
  • D.调参会修改历史业务数据

答案：AB。自动调参会并行训练多个超参组合，并用验证指标逐步淘汰差组合。调参完成不代表模型永远可靠，仍需监控线上漂移；调参也不会修改历史数据。

Q4. 实时端点需要支持 1000 QPS，单实例最大并发请求为 50，平均延迟 0.2 秒，理论上最少需要几个实例？

单选题 · mid

  • A.2 个实例
  • B.4 个实例← 正确答案
  • C.10 个实例
  • D.100 个实例

答案：B。1000×0.2=200 个并发请求，除以单实例并发 50，得到 4 个实例。计算时先算峰值并发，再按每个出餐员能同时端几道菜来配人。

Q5. 部署后检测到线上数据漂移，最合理的下一步是？

单选题 · mid

  • A.暂停一切模型服务
  • B.触发重新训练并评估← 正确答案
  • C.删除全部历史数据集
  • D.关闭自动扩缩容策略

答案：B。数据漂移说明线上输入分布已经变化，原模型可能失真。正确做法是触发重新训练，在验证集上评估后再替换，而不是停机或删数据。

Q6. 从 SageMaker 迁移到其他云平台时，最可能直接复用的是？

单选题 · hard

  • A.SageMaker 端点配置
  • B.SageMaker Studio 项目
  • C.模型工件和推理容器镜像← 正确答案
  • D.Data Wrangler 数据流

答案：C。模型工件和标准化的推理容器属于可携带产物，原始配置、Studio 项目和 Data Wrangler 数据流都与 AWS 托管服务绑定，迁移时需要重建或替换。

Q7. 使用 Spot 竞价实例训练模型，最能降低哪类成本？

单选题 · hard

  • A.数据存储成本
  • B.训练计算成本← 正确答案
  • C.网络流量成本
  • D.长期技术支持成本

答案：B。竞价实例主要作用于计算资源，能够以较低价格获得可中断的 CPU/GPU 算力；存储、流量和支持费用不受影响。适合可断点续跑的训练任务。

Q8. 下列哪些做法符合 SageMaker 全流程最佳实践？

多选题 · mid

  • A.训练前先划分训练验证集← 正确答案
  • B.跳过评估直接部署上线
  • C.部署后持续监控数据漂移← 正确答案
  • D.用流水线串联各阶段任务← 正确答案

答案：ACD。先做数据划分，再训练；部署后要监控漂移；端到端流程应自动化。跳过评估就上线相当于不试菜直接出餐，风险很大。

Q9. 关于 SageMaker 模型部署方式，下列哪些说法正确？

多选题 · hard

  • A.实时端点适合在线推理← 正确答案
  • B.批量转换适合低延迟交互
  • C.批量转换适合离线批量预测← 正确答案
  • D.自动扩缩容无需设置策略

答案：AC。实时端点用于在线请求，批量转换用于离线大批量任务，二者服务对象不同。自动扩缩容必须显式配置，否则不会自己生效。

Q10. 若模型精确率 P=0.8，召回率 R=0.5，则 F1 分数最接近？

单选题 · extreme

  • A.0.40
  • B.0.62← 正确答案
  • C.0.65
  • D.0.80

答案：B。F1=2×0.8×0.5/(0.8+0.5)=0.8/1.3≈0.615，最接近 0.62。F1 是精确率和召回率的调和平均，不会取简单的算术平均值。