AWS发布六个Hugging Face智能体技能，用编码代理部署SageMaker实时端点
AWS机器学习博客介绍从huggingface/skills仓库安装六个技能，让Kiro、Claude Code等编码代理自动完成容器选择、IAM角色检查、自动扩缩容与CloudWatch告警配置，避免无引导代理反复失败并烧掉GPU时长。
AI解读：这套技能要解决的是编码代理“看起来很会、部署起来很废”的问题。AWS测试中，Kiro和Claude Code在无引导情况下都先选TGI容器，结果因镜像版本早于Qwen3架构而健康检查失败，多次重试都计费GPU时间。
六个开源技能把部署拆成AWS环境发现、Python环境准备、IAM执行角色检查、服务镜像选择和生产默认配置，再由规划技能统一调用。它们用Python和AWS CLI，在macOS、Linux、Windows上行为一致。
对真正部署模型的人，变化在于容器选择不再靠猜：技能强制从AWS DLC目录解析镜像URI，避免硬编码过时标签，并默认给端点加上自动扩缩容和三组CloudWatch告警。
限制也写得很明确：需要AWS CLI v2、现有或可创建的SageMaker执行角色，Python仅支持 3.10 到 3.12；实时端点按实例持续计费，用完必须执行teardown。普通读者不需要为这条新闻做任何操作。
AWS机器学习博客发布了一套由六个开源智能体技能组成的Hugging Face模型部署方案，让编码代理在Amazon SageMaker AI上部署生产级实时端点。博文作者Dario Salvati介绍，这些技能来自huggingface/skills仓库，固定到提交f3186efbbc322121eb5d0f31e8a1d669ee961159，使用Python和AWS CLI编写，在macOS、Linux和Windows上无需修改即可运行。
博文给出的核心场景是：用户用自然语言描述要部署的Hugging Face模型，编码代理自动选择服务容器、解析IAM执行角色、创建端点并附加自动扩缩容和Amazon CloudWatch告警，最后执行冒烟测试并留下可验证的清理路径。默认部署为实时端点，技能同时支持实时加缩容到零、无服务器推理、异步推理、批量转换以及Amazon Bedrock自定义模型导入。
AWS用测试说明不装技能会出什么问题。团队要求Kiro（Auto或Claude Fable 5）和Claude Code（Opus 4.8）把Qwen/Qwen3-0.6B部署为实时端点，先写计划文件并记录每一步。两个代理最初都选了Text Generation Inference（TGI）作为服务容器，但该区域可用的TGI构建早于Qwen3架构，无法加载模型，端点健康检查失败；代理升级TGI版本后再次失败，最后转向vLLM，期间多次部署失败，每次启动都计费GPU时间。
第二次测试暴露了更安静的问题：代理被要求部署一个发布仅数周的多模态混合专家（MoE）扩散模型，它确认模型存在，却仍写了基于TGI的脚本，而TGI是文本生成服务器，没有该离散扩散图文模型的后端。博文称这种失败不会大声报错，只会在端点起不来时才发现。作者把两次失败归因于缺少最新部署事实，而非代理推理能力不足。
博文列出的具体知识包括：较新的Qwen模型需要vLLM；Python 3.13缺少机器学习栈所需的可用wheel；容器镜像应从已发布的AWS Deep Learning Containers目录解析。作者称这类知识比模型权重更新得更快，所以做成可编辑的技能文件，而不是指望模型的最新版本自行吸收。
六个技能覆盖的部署阶段
六个技能分别对应部署流程中的不同阶段：hf-cloud-sagemaker-deployment-planner负责编排并只询问必要信息；hf-cloud-aws-context-discovery发现本地AWS上下文；hf-cloud-python-env-setup创建隔离的Python环境；hf-cloud-sagemaker-iam-preflight验证可用的执行角色；hf-cloud-serving-image-selection选择容器族并解析镜像URI；hf-cloud-sagemaker-production-defaults用自动扩缩容、告警和标签完成部署。
博文描述部署经过六个阶段：用只读调用发现AWS配置、区域、账户和调用者身份；建立受支持的Python环境并安装当前boto3；查找现有SageMaker执行角色、仅在无角色且有权限时创建；从AWS DLC目录选择服务容器族并解析当前镜像URI；创建模型、端点配置和端点，再附加自动扩缩容和CloudWatch告警；对运行中的端点执行冒烟测试并报告结果。
技能通过Boto3和AWS CLI调用五个AWS服务：SageMaker AI托管端点，IAM提供执行角色，Amazon ECR和AWS Deep Learning Containers提供镜像，CloudWatch提供告警。博文称SageMaker Python SDK也能用，但技能默认使用Boto3，从而保留对创建内容的完整控制。
- 规划技能：编排其余五个技能，只询问必要信息
- 环境发现技能：发现本地AWS上下文
- Python环境技能：创建隔离的Python环境
- IAM预检技能：验证可用的执行角色
- 镜像选择技能：选择正确的容器族和镜像URI
- 生产默认技能：以自动扩缩容、告警和标签部署
镜像选择技能明确不默认TGI
博文给出hf-cloud-serving-image-selection技能文件的删减版本，其描述覆盖“部署这个LLM”“托管这个HuggingFace模型”“服务这个微调模型”等表述，以及即将在部署代码中硬编码任何容器URI的场景。技能指令要求始终优先使用Hugging Face定制的Deep Learning Containers：LLM和生成式重排序用Hugging Face vLLM，多模态用Hugging Face vLLM-Omni，嵌入和交叉编码重排序用TEI，其他transformers用HF Inference Toolkit。
技能规定，只有在没有兼容的Hugging Face镜像时才使用通用镜像（AWS vLLM、DJL-LMI、SGLang），绝不能仅仅因为版本更新就选它们；不得凭记忆硬编码容器URI，也不得默认使用TGI，理由是这能防止过时镜像和错误区域URI带来的失败。
博文称，服务容器是最容易让“纸面上正确”的部署崩掉的一环，容器错误、标签过时或AMI错误都会产生同一个含糊的Failed to pass health check错误。
部署Qwen3-0.6B的实测参数与限制
博文以Qwen/Qwen3-0.6B为例，部署到美国东部（弗吉尼亚北部）区域us-east-1的一个ml.g5.xlarge实时推理实例。前提条件包括：具备Amazon SageMaker AI使用权限的AWS账户以及现有执行角色，技能可自动查找，或在无角色且凭据允许时创建；配置好该账户凭据的AWS CLI v2；Python 3.10、3.11 或 3.12，明确不支持Python 3.13及更高版本，因为许多机器学习库尚未发布对应wheel；支持技能的编码代理，博文使用的是Kiro IDE；以及用于克隆技能仓库的Git。博文提醒，开始前确认账户有该实例类型的可用配额。
代理日志中的镜像选择结果显示，解析出的镜像URI为 763104351884.dkr.ecr.us-east-1.amazonaws.com/huggingface-vllm:0.28.0-transformers5.15.0-gpu-py312-cu130-ubuntu24.04，InferenceAmiVersion为al2-ami-sagemaker-inference-gpu-3-1，SM_VLLM_MODEL为Qwen/Qwen3-0.6B，SM_VLLM_HOST设为 0.0.0.0（否则vLLM绑定localhost，ping失败，容器退出），SM_VLLM_TRUST_REMOTE_CODE为false，SM_VLLM_MAX_MODEL_LEN为 8192。博文补充，门控模型需要增加HUGGING_FACE_HUB_TOKEN环境变量。
IAM预检技能的check_role.py脚本会在账户中搜索匹配AmazonSageMaker-ExecutionRole-* 和 *SageMaker*Execution* 等模式的现有角色，按最近使用日期排序，验证信任策略并返回ARN；只有在无现有角色且调用者拥有iam:CreateRole权限时才创建角色。博文提醒，创建的角色带有AmazonSageMakerFullAccess，建议按照最小权限原则更新为仅授予所需权限。
生产默认技能会为每个端点应用一套基线配置。博文表格显示，名为qwen3-06b-internal的端点按 $1.408/小时每实例计费；自动扩缩容目标和策略作用于endpoint/.../variant/AllTraffic，最少 1 个、最多 4 个实例；还包括三组CloudWatch告警：-Invocation5XXErrors、-ModelLatencyP99和 -OverheadLatencyP99。博文称生产部署还需添加用户特定配置，例如Amazon Virtual Private Cloud和AWS Key Management Service配置。
代理自行判断的两个案例与清理要求
博文记录了两个由编码代理自行判断的案例。一次是代理查询Amazon ECR获取最新镜像标签时，因IAM Identity Center角色缺少ecr-public:DescribeImages权限而被拒绝；代理没有让部署失败，而是回退到技能内置的已知良好标签，并在日志中记录原因。
另一次是冒烟测试返回HTTP 200后，代理注意到实际答案没有被输出，原因是模型回复在Qwen3推理块内就被max_tokens截断。代理在日志中将其标记为配置问题，并指出调用应用应提高token上限，而不是把测试当作通过。
博文强调实时端点只要存在就持续按实例计费，要求删除所创建资源以避免持续费用。生产默认技能包含teardown.py脚本，会删除部署资源并确认其消失；用户可要求代理拆除部署，或直接用端点名和区域运行teardown.py，确认端点、端点配置和模型已删除，并检查自动扩缩容策略和CloudWatch告警是否也已移除。
博文在结论中称，六个可复用技能把无引导的编码代理变成能在SageMaker AI端点上部署Hugging Face模型、并带有生产就绪功能的代理，每次部署都包含正确的容器、自动扩缩容、CloudWatch告警和经过验证的拆除路径；没有这些技能，代理会选用过时容器、跳过生产保障并留下误导性文档。博文还提到团队也可使用Amazon SageMaker JumpStart从控制台部署一批热门Hugging Face模型，并使用Inference Recommendations自动基准测试并选择最优实例类型。