本次 16 道错题 · 按 2026-09-13 AWS 官方文档校准
测试错题分析
这不是一份答案抄写表。页面把你的误选、题库预设答案和当前 AWS 官方边界分开，目标是从 16 道题提炼出下一套题仍能使用的判断规则。
01
总体诊断
先看弱项分布，再决定复习投入，而不是平均重学四个 Domain。
按考纲重新映射
D38
D25
D42
D11
题库把“监督学习示例”标成 D4；这里按 MLA-C01 内容重新归入 D2，所以与原报告的 D2=4、D4=3 不同。
从所选答案推断出的五种高频模式
- 看见“低延迟”就先选常驻端点还需要同时核对模型大小、流量是否间歇、是否接受冷启动与是否明确要求无服务器。
- 把扩缩当作所有性能问题的答案横向扩缩主要缓解并发和排队；单次推理本身慢，要看实例、容器并发、模型编译与代码路径。
- 服务能力正确，但没有回答题目最后一问Model Monitor 的技术指标不能替代 A/B 的业务结果；Bedrock 导入流程也不要求你配置 SageMaker 式扩缩策略。
- 从名词直接推断学习范式或指标“文档分类”“神经网络”“医疗”都不是充分条件；标签、输出、类别分布和 FP/FN 成本才是。
- 默认题库解析必然比你的判断更准确Firehose 亚秒级、Serverless Inference、MME 前提和 blue/green/canary 的几题都需要反查当前官方文档。
复习优先级：先投入约 60% 时间到 D3 的推理形态、端点承载和部署 guardrails；25% 用于分类指标与模型组合；余下 15% 复习监控闭环、NLP 服务边界和资源层级。
02
六步作答协议
每道场景题先在脑中完成这六步，再读取选项中的服务名。
确认最后一问
是在选模型、指标、运行时、资源、监控动作，还是发布策略？避免用相邻层的正确答案作答。
圈出硬约束
同步或异步、延迟上限、峰值形态、空闲期、成本、最少运维、模型大小和 payload。
判定工作负载
持续还是间歇、单模型还是大量模型、同框架还是异构运行时、技术验证还是业务实验。
锁定资源层
模型定义、端点配置、端点、监控器、告警和重训练属于不同资源或阶段。
写一句决策
例如：“间歇且不可预测的同步推理，优先按需 Serverless；若 p99 必须稳定，再付费预热。”
逐项做 AND 检查
多选题的每一项都必须独立必要或共同组成闭环；“能力真实”不等于“本题需要”。
03
高频决策表
这次错题最集中的知识，不按题号记，按决策边界记。
同步推理：先看流量，再看延迟稳定性
| 方案 | 什么时候优先选 | 关键代价或限制 | 本次对应 |
|---|---|---|---|
| Lambda + API Gateway | 模型和依赖足够轻、请求短、希望通用 FaaS 与完全按调用计费 | 必须验证包大小、内存、超时、并发、冷启动和预热成本；它不是 SageMaker 模型托管能力 | 未编号题 |
| SageMaker Serverless，按需 | 同步、间歇或不可预测流量，希望不管理实例和扩缩策略 | 冷启动会影响尾延迟；官方建议用于可接受 p99 波动的 spiky workload | Q62 的关键反例 |
| Serverless + Provisioned Concurrency | 仍想用 Serverless，但需要保持一部分并发为 warm | 会为预置并发付费；可自动扩缩，但最低预置值不能是 0 | Q62 |
| Real-time endpoint + Auto Scaling | 持续流量、稳定低延迟和高吞吐，需要实例/GPU/部署功能控制 | 保留最小实例容量；扩容有时延，扩缩解决容量竞争而非每次推理的计算时间 | Q45、Q62 |
| Asynchronous Inference | 请求可排队、较大 payload、较长处理时间，需要异步结果 | 不是必须立即返回的交互式实时预测；可扩到 0 | Q45 的错误选项 |
| Batch Transform | 离线批量、有完整输入集、不需要常驻端点 | 不面向逐请求同步响应 | 排除项 |
端点里放什么：模型数量不是唯一条件
| 承载方式 | 决定性信号 | 不要忽略 | 本次对应 |
|---|---|---|---|
| 单模型端点 | 高 TPS、严格延迟、独立扩缩或模型需要专用资源 | 成本更高，但隔离和性能最可预测 | Q63 的必要反例 |
| Multi-model endpoint | 大量模型、同一 ML 框架与共享 serving container、大小和延迟相近 | 不常用模型可能冷启动；高 TPS/延迟异常值应拆到专用端点 | Q63 |
| Multi-container endpoint | 少量模型需要不同容器、框架或依赖，并通过容器名直接调用 | 它解决运行时隔离，不是“大量同构模型动态加载” | Q63 |
| Serial inference pipeline | 多个容器必须顺序完成预处理、推理和后处理 | 每个请求经过整条链，不是独立模型路由 | 未编号题的预处理边界 |
实验与发布：A/B 回答业务问题，guardrails 控制上线风险
| 机制 | 核心问题 | 观测重点 | 本次对应 |
|---|---|---|---|
| Online A/B test | 哪个模型带来更好的点击、转化、留存或会话时长？ | 随机且稳定分组；业务指标是胜负指标，延迟/错误率是 guardrail | Q22 |
| Blue/green all-at-once | 新 fleet 准备好后一次切换，出现告警就回滚 | CloudWatch alarms、baking period、自动回滚 | Q65 |
| Blue/green canary | 先给 green fleet 一小部分流量，再一次切完余量 | 两阶段流量切换和烘焙期 | Q65 的用户答案近似 |
| Blue/green linear | 分多步逐渐把流量从 blue 转到 green | 每步比例、等待时间、告警触发全量回滚 | Q65 的用户答案近似 |
| Shadow test | 复制真实请求给候选模型，但候选结果不返回给用户 | 离线比较技术表现，不能直接测量候选模型改变后的用户行为 | 与 A/B 区分 |
监控闭环：检测、告警和修复是三个动作
| 能力 | 回答什么 | 不等于什么 | 本次对应 |
|---|---|---|---|
| Model Monitor: Data Quality | 生产输入的统计分布是否偏离 baseline？ | 不自动证明准确率下降，也不自动重训练 | Q12 |
| Model Monitor: Model Quality | 获得 ground truth 后，accuracy/F1 等是否漂移？ | 不替代业务 A/B 指标 | Q12、Q22 |
| Clarify / Bias Drift | 预测中的偏差指标或 feature attribution 是否变化？ | 不应笼统替代所有输入数据漂移检测 | Q12 |
| CloudWatch | 基础设施指标、日志、告警，以及应用主动发布的自定义业务指标 | CloudWatch 不会自动知道“点击率”的业务语义，应用必须埋点 | Q22、Q45 |
| Pipelines / 重训练流程 | 漂移告警后如何生成新训练数据、训练、评估、注册和审批 | “检测到漂移”与“应该立即自动上线”不是同一件事 | Q12 |
当前状态提醒：截至核对日，SageMaker Model Monitor 已不再向新客户开放，现有客户可继续使用；但它仍在 MLA-C01 当前考纲和题库中出现，考试答案仍需掌握。
分类指标：先把错误翻译成 FP 或 FN
Precision = TP / (TP + FP)
假阳性代价高时优先。问：判成阳性的样本里，有多少真的阳性？
Recall = TP / (TP + FN)
假阴性代价高时优先。问：所有真实阳性里，找回了多少？
F1 = 2PR / (P + R)
需要在 precision 与 recall 之间折中，尤其不希望多数类掩盖少数类时。
| 指标 | 适合 | 警告 | 本次对应 |
|---|---|---|---|
| Accuracy | 类别较平衡、FP/FN 成本大致对称，关心总体正确数 | 严重不平衡时可能很高却毫无价值 | Q28 |
| Balanced Accuracy | 仍想概括正负类识别，但类别不平衡 | 题目选项没有它时，再按题干选择 F1/recall/precision | Q28 的边界 |
| Precision | 误报会造成高成本或伤害 | 单独优化可能漏掉更多真正阳性 | Q32 |
| Recall | 漏报会错失治疗、欺诈或故障预警 | 单独优化可能产生大量误报 | Q32 |
| F1 | 同时在意 FP/FN，想要一个 operating-point 指标 | 默认同等看待 precision/recall；成本不对称时用 F-beta 或显式阈值 | Q32 |
| ROC-AUC / PR-AUC | 比较跨阈值的排序能力；少数正类常更关注 PR-AUC | 它不替你选择生产阈值，也不直接表达具体 FP/FN 成本 | Q32 的误选边界 |
四组容易跨层的服务与资源
| 题干动作 | 首选 | 容易误选 | 边界 |
|---|---|---|---|
| CloudFormation 定义模型工件、容器和执行角色 | AWS::SageMaker::Model | EndpointConfig、Endpoint | Model → EndpointConfig → Endpoint 是依赖链，不是三选一的同义词 |
| 文本中的 key phrases / entities / sentiment | Amazon Comprehend | Textract、Kendra、Rekognition | Textract 读文档结构；Kendra 检索；Rekognition 看图像/视频 |
| 把兼容的 Hugging Face 模型导入 Bedrock | S3 或 SageMaker AI 模型来源 + import job；导入后按需调用 | ECR 镜像、导入时配置扩缩 | 当前支持跨账号 S3，但需显式 IAM/KMS 权限；“必须同账号”已不是硬限制 |
| Firehose 降低到 OpenSearch 的缓冲延迟 | IntervalInSeconds=0 | 把“零缓冲”等同“亚秒送达” | 官方只说 within a few seconds；硬性 <1 秒要重新设计并端到端压测 |
04
16 道题逐题诊断
“题库争议”表示不能从该解析推出通用规则，不等于你的原答案在所有条件下都正确。
当前显示 16 / 16 道题
未编号轻量信用模型的无服务器实时推理Lambda vs SageMaker endpointD3需加条件
决定性线索
“轻量级”“不可预测流量”“偶发高峰”“成本控制”“倾向无服务器”共同压过了单独的“极低延迟”。
误选诱因
Real-time endpoint 的确适合低延迟推理，但它是常驻实例；再加 Lambda 只做预处理，没有解决题目最强调的无服务器与空闲成本。
考试结论
在给定选项中，Lambda 直接承载模型并通过 API Gateway 暴露最符合“轻量 + serverless + 按调用扩缩”。
官方边界
当前还有题目未提供的 SageMaker Serverless Inference。Lambda 和按需 Serverless 都可能冷启动，所以“极低延迟”必须用包大小、并发与 p99 实测校准。
迁移规则：先问模型是否能放进运行时，再问流量是否值得常驻；“实时”并不自动等于 Real-time endpoint。
Q12推荐模型漂移的检测与处置Model Monitor、Clarify、retrainingD4结论稳定
决定性线索
客户偏好和市场趋势导致输入分布变化，题目同时要求“检测”和“管理”，所以答案应组成监控 + 修复闭环。
误选诱因
Clarify 确实能监控 bias drift，但选项把“偏差”“数据分布变化”“缓解”和“启动重训练”混成一个过宽动作。
考试结论
选择 Model Monitor 的 data quality/data drift 监控与告警，再使用最新训练数据重训练。一个发现问题，一个改变模型。
官方边界
Model Monitor 也包含 model quality、bias drift 和 feature attribution drift；Clarify 不是“不能监控漂移”，而是本题的一般输入漂移首选不应被它替代。
迁移规则：监控器只产生证据与告警；重训练、上游修复、审批和部署才是处置动作。
Q14哪些属于监督学习学习范式不能由任务或模型名唯一决定D2题库争议
决定性线索
监督学习的充分条件是训练样本带目标标签，并以预测该目标为优化任务。
你的选择为何合理
文档分类只要使用带类别标签的文档，就是标准监督分类；它也可以采用半监督、自监督或零样本方法，题干未说明。
题库预设
题库接受“神经网络 + 线性回归”，并把文档分类固定称为半监督。线性回归明确；但神经网络同样可用于监督、无监督和自监督。
校准结论
该题在概念上信息不足。遇到正式考试更完整的题干时，以 labels/objective 判断；不要背“文档分类 = 半监督”或“神经网络 = 监督”。
迁移规则：算法架构和业务任务都不等于学习范式；必须问训练信号从哪里来。
Q20训练、验证与测试集的职责model selection vs final generalization estimateD1需加条件
决定性线索
题目考数据集角色：train 拟合参数，validation 选择模型/调超参数，test 只在最后提供未见数据上的独立估计。
误选原因
验证表现当然能预估泛化，但一旦反复据此调参，它就参与了模型选择；不能再作为最终无偏的测试证据。
考试结论
按题库口径选“测试集用于确定泛化能力”和“验证集可选”。绝不能用 test set 做 HPO。
官方/实践边界
“验证集可选”通常指可用交叉验证或算法内部划分替代独立 validation split；测试评估仍应与选择过程隔离。
迁移规则：凡是影响超参数、阈值或模型选择的数据，都不再是最终 test evidence。
Q22从业务成果比较推荐模型Online A/B test vs technical monitoringD4结论稳定
决定性线索
最后一问明确写“从业务成果角度”，因此 winning metric 必须是点击率、转化率、会话时长或收入，而非准确率和延迟。
误选诱因
两个端点 + Model Monitor 可以比较技术健康度，但缺少随机分组，且技术指标不能回答用户是否更愿意互动。
考试结论
随机分配一定比例用户到两个模型，应用发布业务指标到 CloudWatch，再按预先定义的统计标准决定胜者。
工程补充
同时保留 latency、error rate 和资源利用率作为 guardrails；它们能否决不安全版本，但不替代业务主指标。
迁移规则：A/B 的第一问永远是“谁被随机分到哪一组”，第二问才是“用什么业务指标判胜负”。
Q24CloudFormation 定义 SageMaker 模型Model → EndpointConfig → EndpointD3结论稳定
决定性线索
题目问“定义一个模型”，不是“让端点上线”。资源名应与被定义的对象同层。
误选诱因
AWS::SageMaker::Endpoint 确实是最终处理请求的资源，但它只引用 endpoint configuration，不直接定义模型工件与容器。
考试结论
AWS::SageMaker::Model 指定 S3 模型工件、推理镜像和执行角色；EndpointConfig 指定 production variants；Endpoint 再引用配置。
排除口诀
问“是什么”选 Model；问“用什么实例、几台、怎样分流”选 EndpointConfig；问“创建/更新在线入口”选 Endpoint。
迁移规则：CloudFormation 题先画依赖图，不要因为最终目标是在线推理就直接跳到链尾。
Q28同时最大化正负样本总体正确率Accuracy 的适用与失效条件D2结论稳定
决定性线索
目标是总体上正确预测阳性和阴性，题干未给不平衡或非对称错误成本；选项中 Accuracy 直接计算所有正确分类占比。
误选原因
RMSE 衡量连续预测误差，属于回归指标，不能作为二分类重新校准的首选目标。
考试结论
在这些选项和假设下选 Accuracy。Precision 只压 FP，Recall 只压 FN，均不等于整体正确率。
官方/实践边界
若疾病阳性稀少，或 FP/FN 代价不同，Accuracy 会误导；应改看 balanced accuracy、F1、PR-AUC 与业务成本阈值。
迁移规则：先问分类是否平衡、错误是否对称；两个答案都为“是”时，Accuracy 才变得可靠。
Q32医疗场景同时存在昂贵误报与危险漏报F1、recall 与 ROC-AUCD2需加条件
决定性线索
FP 会造成昂贵检查，FN 会错失关键治疗。题库进一步把 FN 描述为临床风险更高，因此在“平衡”之外还偏向 recall。
你的正确部分
F1 同时纳入 precision 与 recall，是给定选项中直接平衡两类错误的 operating-point 指标。
题库结论
选择 F1 + Recall：前者平衡，后者额外压低漏诊。ROC-AUC 用于跨阈值比较排序能力，但不直接确定生产阈值。
官方/实践边界
若题干真的把 FP 和 FN 设为同等严重，单独再选 Recall 并不完全对称。现实中应显式建立成本矩阵，并查看 PR curve、阈值和校准。
迁移规则：“两种错误都重要”先想 F1；若题干再强调漏掉阳性更危险，第二答案才倾向 Recall。
Q42把 Hugging Face 自定义模型导入 BedrockS3 source、import job、on-demand invocationD3需加条件
决定性线索
目标是让已微调的兼容模型通过标准 Bedrock API 被调用，因此流程是准备支持格式的模型源、创建 import job、等待完成、按需调用。
误选原因
Bedrock Custom Model Import 是托管工作流；导入时不要求用户定义 SageMaker/Application Auto Scaling 策略。
题库结论
选择模型工件的完整 S3 URI，以及导入后使用 on-demand throughput。ECR 容器和“必须量化”不是该导入流程要求。
当前官方边界
同账号 S3 是最简单路径，但已不是唯一合法路径：当前文档支持跨账号 S3/KMS，只需给 import role、bucket policy 和密钥权限。
迁移规则：Bedrock 模型导入考“模型文件来源 + IAM + import job + Bedrock Runtime”，不是容器编排与端点扩缩。
Q43从大量文档识别关键词与业务实体Comprehend vs Kendra vs Textract vs RekognitionD2结论稳定
决定性线索
动作是“从文本中识别和提取语义信息”，不是建立搜索体验、OCR 读字或分析图像内容。
误选诱因
Kendra 会索引文档并按查询检索相关内容，但它的主任务不是批量输出每份文档的 key phrase/entity 分析结果。
考试结论
选 Amazon Comprehend。通用 noun phrases 用 key phrase extraction；企业特定代码、产品名等新实体类型才训练 custom entity recognizer。
服务边界
扫描件先由 Textract 或 Comprehend 内部的文本提取流程读字；Kendra 做 enterprise search/RAG；Rekognition 处理图像和视频视觉内容。
迁移规则：读字选 Textract，理解文本选 Comprehend，找答案选 Kendra，看视觉对象选 Rekognition。
Q45单实例实时端点的延迟与吞吐下降horizontal scaling vs single-request latencyD3需加条件
决定性线索
当前只有一个实例，同时出现响应变慢和吞吐不足；这很像并发上升造成的容量竞争和排队。
误选诱因
换大实例可能降低单次计算时延，但选项额外绑定“多可用区部署”，主要回答可用性而不是动态容量，并且题干没有证明模型需要更强单机。
题库结论
启用 target tracking，以 InvocationsPerInstance 等指标调整实例数，可提高总吞吐并减少过载排队。
官方/工程边界
Auto Scaling 不会让一条完全无排队的单次推理计算自动变快。若低流量时仍慢，应压测实例类型、容器 workers、模型编译和 I/O。
迁移规则：吞吐/排队问题先横向扩；单请求计算慢再纵向扩或优化模型运行时。
Q56不同客户群体适合不同推荐模型weighted hybrid、gating、stackingD2题库争议
决定性线索
协同过滤对历史丰富用户好，内容模型对新用户好，说明“客户 segment/context”决定该信任哪个模型。
题库结论
采用基于各模型在不同客户群体表现的加权混合，最直接编码题干已给出的分段优势，复杂度也较低。
你的答案为何并非荒谬
Stacking 本来就是合法集成方法，元模型可以学习基础模型输出的组合。若还输入客户上下文并严格做 out-of-fold 训练，它可能优于固定权重。
校准结论
题目没有提供验证结果，无法断言 stacking 必然较差。考试遇到“不同 segment 各有所长”时，优先选择显式 conditional weights/gating 的选项。
迁移规则：按上下文选择专家是 gating；固定平均是 blending；用预测训练二层模型是 stacking，三者不要只按“更高级”排序。
Q59Firehose 到 OpenSearch 的亚秒级警报zero buffering is not a sub-second SLAD3题库争议
决定性线索
“低于一秒”是硬 SLO；不能因为修改更少、运维更低，就接受无法证明满足 SLO 的方案。
题库结论
题库选择把 Firehose 的 IntervalInSeconds 调为 0，理由是消除 60 秒缓冲且改动最小。
官方冲突
AWS 当前文档说 zero buffering 会“within a few seconds”交付，并没有承诺 <1 秒。题库把“零缓冲”误写成“立即交付/满足亚秒”。
你的答案边界
Kinesis Data Streams + 低延迟 consumer/Lambda 更接近硬 SLO，但也需要验证 Lambda、OpenSearch refresh 和 dashboard 查询的端到端延迟。
迁移规则：配置值为 0 不等于系统总延迟为 0；硬 SLO 必须逐段预算并压测。
Q62不可预测峰值与长低流量期的模型托管Serverless vs real-time autoscalingD3题库争议
决定性线索
流量不可预测、存在长低谷、要求自动扩展、最低成本和最低管理开销，正是官方给 Serverless Inference 的典型信号。
题库结论
题库接受 Real-time endpoint + CloudWatch target tracking，并以“峰值不可预测”否定 Serverless + Provisioned Concurrency。
官方冲突
AWS 明确把按需 Serverless 定位给 intermittent/unpredictable traffic；Provisioned Concurrency 也可以自动扩缩。Real-time autoscaling 仍需保留最小实例容量。
你的答案边界
你选的 provisioned concurrency 会产生 warm baseline 成本；若题干没有严格 p99/cold-start 要求，更好的表述应是按需 Serverless，不预置并发。
迁移规则：不可预测 + 间歇 + 可接受尾延迟波动 → on-demand Serverless；持续 + 稳定低延迟 → real-time + autoscaling。
Q63不同业务模型共享同一基础设施MME requires same-framework evidenceD3题库争议
决定性线索
题目只说业务功能和更新频率不同，没有说明模型数量、框架、容器依赖、大小、TPS 或冷启动容忍度。
题库结论
题库选择 MME，把所有模型放入共享 serving container 并按需动态加载，以降低大量端点的成本。
信息缺口
MME 最适合大量同框架、大小和延迟相近的模型；不同运行时更像 multi-container，高 TPS 或严格延迟模型应使用专用端点。
你的答案边界
“频繁更新”并不是 MME 的决定性信号，“复杂模型”也不自动等于 multi-container。混合架构可能合理，但划分条件必须来自运行时和 SLO。
迁移规则：先按“同一容器能否加载”切 MME/多容器，再按 TPS、延迟和隔离需求决定是否拆专用端点。
Q65高可用模型的版本上线与回滚blue/green contains canary and linear modesD3题库争议
决定性线索
题目强调高可用、版本控制、逐步验证和快速回滚，目标是发布安全，而不是在线业务实验。
题库结论
选择 blue/green：并行准备 green fleet，按策略切流，用 CloudWatch alarms 和 baking period 触发自动回滚。
你的答案为何接近正确
“先给小流量，再逐步增加”描述的正是 canary 或 linear traffic shifting；AWS 官方把这两者都列为 blue/green 的 traffic shifting modes。
真正缺少的条件
你的选项没有明确 green fleet、CloudWatch alarms 和 auto rollback，因此描述可能只是手工加权分流。两项不应被题库写成完全互斥。
迁移规则：blue/green 是 fleet 隔离框架；all-at-once、canary、linear 是其中的切流方式；告警与自动回滚才完成 guardrail。
05
考前一页速记
下一次做题前先闭卷写出这些句子，再开始计时。
- “实时”不等于 Real-time endpoint。还要看持续流量、尾延迟、模型运行限制和空闲成本。
- Auto Scaling 主要调整容量。并发排队慢可横向扩；单次计算慢要看实例、容器并发与模型优化。
- MME 的关键词是大量、同框架、共享容器、相近模型。多容器的关键词是不同镜像、依赖或框架。
- A/B 决定业务胜者。随机分组 + 业务指标；技术指标只是上线护栏。
- 漂移检测不等于漂移修复。baseline/monitor/alarm 之后才是数据修复、重训练、评估和审批。
- 问 FP/FN，不背行业名。FP 贵看 precision，FN 贵看 recall，两者都要看 F1/阈值与成本矩阵。
- 学习范式由训练信号决定。文档分类和神经网络都不能单独证明监督学习。
- CloudFormation 按资源层答。
Model → EndpointConfig → Endpoint。 - Comprehend 理解文本，Textract 读文档，Kendra 检索，Rekognition 看视觉内容。
- 零缓冲不是零延迟。任何硬 SLO 都要核对官方措辞并做端到端预算。
- Blue/green 是框架，canary/linear 是切流模式。CloudWatch alarm + auto rollback 才是完整 guardrail。
- 题库解析也要做 AND 检查。若它无法满足题干硬约束，标记争议，不把结论泛化。
06
8 题闭卷复盘
先用一句话回答，再展开核对。目标不是记服务名，而是说出决定性条件。
1. 同步推理、流量间歇且不可预测、可接受 p99 波动，首选什么？
按需 SageMaker Serverless Inference。它不要求选择实例或管理扩缩策略，并按使用付费；若不能接受冷启动，再评估 provisioned concurrency 或 real-time endpoint。
2. 实时端点只有高并发时延迟升高，低流量时单次推理正常，应先改什么？
先用 target tracking 扩实例数量，观察 InvocationsPerInstance、CPU/GPU、并发和模型延迟；这是容量竞争问题。
3. 有数百个同框架、大小相近且访问冷热不均的模型，能容忍偶发冷启动，怎么部署？
Multi-model endpoint。若某个模型 TPS 或延迟要求显著更高，把它拆到专用端点。
4. 两个模型由不同镜像和框架提供，要共享一个端点并独立路由，怎么部署？
Multi-container endpoint 的 direct invocation。若容器必须按顺序处理同一请求，则是 serial inference pipeline。
5. 欺诈漏报比误报代价更高，应优先看哪个指标？
Recall，因为它直接压低 FN；同时查看 precision、PR curve 和业务阈值，避免用无穷误报换取召回。
6. 两个推荐模型谁能提高点击率，最低限度需要哪两个设计元素？
随机且稳定的用户分组，以及应用发布的点击率等业务 outcome。端点 latency/error rate 作为 guardrails，不作为业务胜负的替代。
7. 输入特征分布变化与群体偏差变化，分别优先看什么？
一般输入数据漂移看 Model Monitor Data Quality；群体偏差指标变化看 Clarify/Model Monitor Bias Drift。两者都只是检测，修复另走数据与重训练流程。
8. Firehose 把 buffering interval 设为 0，能否承诺 OpenSearch 仪表盘低于 1 秒？
不能。官方表述是几秒内交付，而且端到端还包含索引 refresh 与查询显示延迟；硬性亚秒 SLO 需要低延迟消费路径和实测。
通过标准：24 小时后不看页面，8 题中至少 7 题能在 20 秒内说出“首选 + 条件 + 一个反例”。答出服务名但说不出条件，不算掌握。
07
官方来源
页面优先使用 AWS 官方考纲和开发者指南，题库解析只作为被分析对象。
- MLA-C01 Domain 1
- MLA-C01 Domain 2
- MLA-C01 Domain 3
- MLA-C01 Domain 4
- SageMaker inference options
- SageMaker Model Hosting FAQ
- Inference cost optimization
- Autoscale serverless provisioned concurrency
- Real-time endpoint auto scaling
- Multi-model endpoints
- Multi-container endpoints
- Deployment guardrails
- A/B test models in production
- SageMaker Model Monitor
- Clarify bias drift monitoring
- SageMaker metrics and validation
- CloudFormation SageMaker hosting example
- Bedrock model import job
- Bedrock cross-account S3 import access
- Invoke an imported Bedrock model
- Comprehend key phrases
- Comprehend custom entity recognition
- Amazon Data Firehose buffering hints
“结论稳定 / 需加条件 / 题库争议”是根据题干完整性、当前官方文档和选项互斥性做出的教学标注，不是 AWS 官方对题目的评级。AWS 服务行为会变化，复习临近考试时应再次核对官方页面。