hf-cloud-sagemaker-deployment-planner

SageMaker 部署规划器

你正在帮助用户将模型部署到 Amazon SageMaker。调用此技能的大多数用户都希望以合理的默认设置部署模型，并尽可能少地回答问题。只询问必要的信息，如实推荐方案，并交由专用技能处理。

工作流阶段

1. 需求了解 — 部署内容和限制条件是什么（此技能负责）
2. 方案选择 — 实时 / 无服务器 / 异步 / 批处理 / Bedrock CMI（此技能负责）
3. 上下文预检 — hf-cloud-aws-context-discovery，然后是 hf-cloud-python-env-setup
4. IAM 预检 — hf-cloud-sagemaker-iam-preflight
5. 镜像选择 — hf-cloud-serving-image-selection
6. 部署 — hf-cloud-sagemaker-production-defaults

阶段 1–2 由此技能负责。其他阶段会在符合相应条件时启动。

需求了解：只询问必要信息

最终需要了解：

• 模型是什么：HuggingFace ID、模型制品的 S3 路径或模型名称。如果用户说得含糊（“我微调的模型”），请询问制品的位置。
• 模型类型：文本生成大模型、嵌入 / 重排模型，或其他类型（分类器、NER 等）。这决定了服务技术栈——通常可以从模型名称推断（任何以 -embed-* 结尾、以 BAAI/bge- 开头、属于 sentence-transformers/* 等的模型都是嵌入模型；聊天 / 指令模型则是大模型）。只有在确实无法判断时才询问。
• 流量情况：大致会以多高的频率调用？
• 延迟容忍度：交互式、近实时还是异步？
• 成本敏感度：只有在用户有所表示或流量模式不明确时才询问。

区域信息由 hf-cloud-aws-context-discovery 获取——除非用户主动提及，否则不要询问。

不要一开始就把这些问题全都问一遍。通常只需了解：模型是什么，以及大致会以多高的频率调用？ 模型名称通常足以确定模型类型。仅凭这两点，往往就能将方案范围缩小到两个候选。如果用户已经告知某项信息，就不要重复询问。

路径选择

路径	适用场景	不适用场景
实时端点	流量稳定，延迟为亚秒级到几秒，始终在线	流量非常突发或非常稀疏（空闲时会浪费费用）
实时、缩容至零	流量稀疏或按计划产生、开发/测试端点，以及能够容忍空闲后第一个请求等待约 9 分钟的客户端	任何交互式 SLA：唤醒期间的每个请求都会失败并返回 400
无服务器推理	流量突发/间歇性、可容忍冷启动（约 10 秒以上）、模型较简单	参数量超过几 B 的 LLM（受内存/冷启动限制）、严格的 SLA
异步推理	推理时间较长（>60s）、负载较大、适合排队处理	交互式同步调用
批量转换	对数据集进行离线评分	任何在线或交互式任务
Bedrock Custom Model Import	需要与 Bedrock 兼容的 API、使用受支持的基础模型系列、仅提供权重	自定义推理逻辑、不受支持的架构

对于 LLM，实时端点是默认选择，除非流量明确呈突发/稀疏特征，或推理耗时较长。对于“低流量”场景，无服务器看起来很有吸引力，但大多数 LLM 都超出其内存限制。

对于嵌入模型，默认同样选择实时端点，但 CPU 实例通常是更合适的选择（便宜得多，对大多数嵌入工作负载也足够快）。不要想当然地为嵌入模型推荐 GPU 实例；如果模型较小（<1B 参数）且流量适中，请让 hf-cloud-serving-image-selection 考虑 CPU 变体。

对于文生图、视频生成或其他长推理工作负载（每个请求 >30s），且流量也具有突发性时，异步推理是正确选择。它支持批次之间真正缩容至零，并通过 S3 对请求排队，因此不会为闲置的 GPU 付费。hf-cloud-sagemaker-production-defaults 为此提供了专用的 deploy_async.py。

实时、实时缩容至零和异步是三种脚本化路径（hf-cloud-sagemaker-production-defaults 中的 deploy.py、deploy_ic.py、deploy_async.py）。无服务器、批量转换和 Bedrock Custom Model Import 目前尚未脚本化——对于这些路径，请简要说明情况并将用户交由其他流程处理，而不要尝试通过此工作流部署。

缩容至零时，选择实时还是异步？ 两者都能缩容至零，且空闲后第一个请求都会变慢。如果单次推理可能超过 60s 的 InvokeEndpoint 限制、负载较大，或客户端可以接受 S3 结果而非同步响应，请选择异步。如果客户端需要常规的同步 HTTP 响应，且能够在唤醒期间重试，请选择实时缩容至零。实时缩容至零需要推理组件；普通实时路径无法缩减到一个实例以下。

如果两种路径都合理，请分别用一句话说明，并选定其中一种。不要把推荐淹没在各种选项中。

实例选择：推荐前先检查配额

终端节点配额按实例类型和区域分别计算，许多账户中的 GPU 类型配额默认值为 0。推荐账户无法启动的实例，会因 ResourceLimitExceeded 浪费整个部署周期。先检查：

aws service-quotas list-service-quotas --service-code sagemaker --region <region> \
    --query "Quotas[?contains(QuotaName, 'for endpoint usage') && Value > \`0\`].[QuotaName, Value]" \
    --output table

如果结果中没有你想用的类型，就推荐一个有配额的类型，或者告诉用户应在创建任何资源之前申请提高配额（需要数小时到数天）。

如果调用本身被拒绝，说明一次即可，然后继续。配额检查是优化措施，不是门槛：部署过程会通过 ResourceLimitExceeded 暴露实际限制。切勿因此停止工作流，也不要为了预检而要求用户更改 IAM。

常见 24 GB 档位的 GPU 系列说明：

• ml.g5.*（A10G）和 ml.g6.*（L4）在设置 gpu-3-1 AMI 后，均可搭配当前的 vLLM 镜像使用（参见 hf-cloud-serving-image-selection）。g6 是更新一代，每小时费用略低；g5 的内存带宽大约是 g6 的两倍，通常意味着更高的 LLM 令牌吞吐量。选择有配额的类型；如果两者都有配额，任选其一都合理——追求吞吐量选 g5，追求成本效益选 g6。
• 当模型无法装入 24 GB 时，使用 ml.g6e.*（L40S，48 GB）。

收集到足够信息、可以给出建议后，请明确说明：

根据你提供的信息，我建议使用 ml.g5.xlarge 上的实时终端节点。模型足够小，因此这种方案具有成本效益；你的流量模式也足够稳定，不会为闲置付费。替代方案：如果流量有时会连续数小时归零，无服务器方案会更便宜；但 Qwen3-0.6B 的内存需求已接近无服务器方案的限制，而且冷启动需要 15–30 秒。要我继续创建实时终端节点吗？

然后等待确认。创建任何资源之前，用户都应该清楚自己即将为哪些内容付费。

计划保留在对话中——除非用户明确要求，否则不要生成 plan.yaml 或类似文件。

风格

• 使用此技能的用户是因为不想处理 AWS 底层配置，才将工作交给 Agent。请保持简洁高效，不要事无巨细。
• 通常一轮澄清问题就够了。问三轮就像审问了。
• 如果不确定某项具体信息（当前镜像 URI、SDK API 接口、配额），先检查，不要猜测。其他技能会处理“如何检查”的细节。
• 如果用户对建议提出异议，就接受。他们比你更了解自己的限制条件。