在 Amazon SageMaker…

当用户想把模型（LLM、embedding、reranker、扩散模型等）部署到 AWS SageMaker 时，用最少提问确定部署路径并给出实例建议。

适用场景

解决思路

1. 按工作流阶段推进：1) Discovery 弄清部署对象与约束（本技能）；2) Pathway selection 选择 real-time / serverless / async / batch / Bedrock CMI（本技能）；3) Context preflight 走 hf-cloud-aws-context-discovery，再走 hf-cloud-python-env-setup；4) IAM preflight 走 hf-cloud-sagemaker-iam-preflight；5) Image selection 走 hf-cloud-serving-image-selection；6) Deployment 走 hf-cloud-sagemaker-production-defaults。
2. Discovery 阶段只问必要信息：模型（HuggingFace ID、S3 产物路径或模型名；若用户含糊如“我微调的模型”，追问产物位置）、模型类型（text-generation LLM、embedding/reranker 或其他；通常可从模型名推断，如以 -embed-* 结尾、BAAI/bge-*、sentence-transformers/* 为 embedding，chat/instruct 为 LLM，仅在真正含糊时才问）、流量规模（大致调用频率）、延迟容忍度（交互式、近实时或异步）、成本敏感度（仅在用户暗示或流量模式含糊时问）。
3. 不要一次性抛出所有问题；常见最小集合是“什么模型 + 大致调用频率”，模型名通常已能确定模型类型，足以把路径缩小到两个候选；用户已提供的信息不要重复问。
4. Region 从 hf-cloud-aws-context-discovery 获取，除非用户主动提及否则不要问。
5. 按路径选择表决策：Real-time endpoint 适合稳定流量、亚秒到数秒延迟、常驻；不适合非常尖峰或非常稀疏的流量（空闲浪费钱）。Real-time scale to zero 适合稀疏或定时流量、开发/测试端点、客户端能容忍空闲后首次请求约 9 分钟；不适合任何交互式 SLA（唤醒期间每个请求都会以 400 失败）。Serverless inference 适合尖峰/间歇、能容忍冷启动（约 10s+）、较简单的模型；不适合超过几 B 参数的 LLM（内存/冷启动限制）和严格 SLA。Async inference 适合长推理（>60s）、大负载、可排队；不适合交互式同步调用。Batch transform 适合对数据集做离线打分；不适合任何在线或交互式场景。Bedrock Custom Model Import 适合想要 Bedrock 兼容 API、受支持的基础模型家族、仅权重；不适合自定义推理逻辑、不支持的架构。
6. 对 LLM，默认用 real-time endpoint，除非流量明确尖峰/稀疏或推理长时间运行；serverless 对“低流量”看似诱人，但大多数 LLM 超出其内存限制。
7. 对 embeddings，同样默认 real-time，但通常选 CPU 实例（更便宜，对多数 embedding 负载足够快）；不要条件反射地推荐 GPU；若模型较小（<1B 参数）且流量中等，让 hf-cloud-serving-image-selection 考虑 CPU 变体。
8. 对 text-to-image、视频生成或其他长推理负载（每请求 >30s）且流量突发：async inference 是正确答案，它支持批次之间真正 scale-to-zero 并通过 S3 排队请求，避免为空闲 GPU 付费；hf-cloud-sagemaker-production-defaults 有专门的 deploy_async.py。
9. Real-time、real-time scale-to-zero、async 是三条有脚本的路径（hf-cloud-sagemaker-production-defaults 中的 deploy.py、deploy_ic.py、deploy_async.py）；serverless、batch transform、Bedrock Custom Model Import 目前无脚本，向用户简要说明后交接，不要试图通过本工作流部署。
10. 在 scale to zero 的 real-time 与 async 之间选择：两者都能到零且空闲后首次请求都慢；当单次推理可能超过 60s 的 InvokeEndpoint 限制、负载大、或客户端能接受 S3 结果而非同步响应时选 async；当客户端需要正常同步 HTTP 响应并能重试唤醒时选 real-time scale-to-zero；real-time scale-to-zero 需要 inference components，普通 real-time 路径无法低于 1 个实例。
11. 若两条路径都合理，各用一句话说明并选一条，不要把推荐淹没在选项里。
12. 推荐实例前先查配额：端点配额按实例类型、按 region 计算，很多账号中 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。
13. 若想要的类型不在结果中，改推荐在结果中的类型，或告诉用户在创建任何东西之前先申请配额提升（数小时到数天）。
14. 若该调用本身被拒绝，说明一次并继续；配额检查是优化而非门禁，部署会以 ResourceLimitExceeded 暴露真实限制；绝不要因预检而停止工作流，也绝不要要求用户改 IAM。
15. 常见 24 GB 档的 GPU 家族说明：ml.g5.*（A10G）和 ml.g6.*（L4）在设置 gpu-3-1 AMI 时都能配合当前 vLLM 镜像（见 hf-cloud-serving-image-selection）；g6 更新且每小时略便宜，g5 内存带宽约翻倍，通常 LLM token 吞吐更好；哪个有配额就选哪个，两者都有时都合理——要吞吐选 g5，要成本选 g6。
16. 当模型放不进 24 GB 时用 ml.g6#（L40S，48 GB）。
17. 一旦信息足够就明确给出推荐，例如：“根据你告诉我的，我推荐在 ml.g5.xlarge 上用 real-time endpoint。模型足够小，这样成本划算，流量模式也足够稳定，不会为空闲付费。替代方案：如果流量会连续数小时枯竭，serverless 更便宜，但 Qwen3-0.6B 处于 serverless 内存限制边缘，冷启动会是 15–30s。要我继续用 real-time endpoint 吗？”然后等待确认；在创建任何东西之前，用户应知道将要花什么钱。
18. 计划留在对话中——除非明确要求，不要生成 plan.yaml 之类的产物。
19. 风格：调用本技能的用户是不想做 AWS 管道工作才委托给 agent，要高效而非面面俱到；一轮澄清问题通常足够，三轮就是审问；不知道具体信息（当前镜像 URI、SDK API、配额）时去查而不是猜，其他技能负责“怎么查”的细节；若用户反驳推荐就接受，他们比你更了解自己的约束。

适用边界 · 注意事项

• 用户没有 AWS/SageMaker 环境或不想用 AWS 时（本技能依赖 AWS 账号、SageMaker 端点配额与相关云服务）。
• serverless、batch transform、Bedrock Custom Model Import 这三条路径目前无脚本，不应试图通过本工作流部署，而应简要说明后交接。
• 不要在创建任何资源前跳过配额检查或用户确认，否则可能因 ResourceLimitExceeded 浪费部署周期或产生意外费用。