基于 Amazon SageMaker HyperPod 的 ComfyUI 部署方案

1. 背景介绍

1.1 ComfyUI 的持续价值

在 AI 生成内容快速发展的背景下，虽然闭源模型的各类 SaaS 已非常成熟，但在多样化的开发和生产环境里，ComfyUI 作为开源的节点式工作流平台仍然有不可替代的价值：

• 可视化、可复用的工作流编排：通过节点式界面把整个流程显式化，便于复用、版本管理与协作交付。
• 统一集成不同模型与能力：可通过 custom nodes/partner nodes，把开源模型与外部能力（含闭源服务）编排到同一条 workflow 中，减少脚本碎片化拼接带来的维护成本。
• 可控与可扩展的私域能力：在需要数据合规、运行可审计、私有模型/LoRA 微调等场景时，自建可控的运行环境与模型资产仍然是关键诉求。
• 多模态工作流承载：不仅覆盖图像，也可扩展到视频、3D、音频等任务，为多媒体内容生产提供一致的工作流入口。

1.2 SageMaker HyperPod 的技术优势

Amazon SageMaker HyperPod 为 ComfyUI 部署提供了理想的基础设施平台：

• 适合长时间运行的稳定性：自动检测并替换异常实例，适合持续运行的推理工作负载，降低集群层面的运维压力。
• 以 EKS 为核心的统一管理面：HyperPod 可以用 Kubernetes 的方式管理工作负载与网络/存储/权限，配合 HyperPod 的抽象能力，减少从零搭建集群的复杂度。
• 面向 ML 工作负载的集成：更好地承载 GPU 资源调度、训练/推理相关插件与常见依赖，便于快速落地生产化部署。
• 弹性与成本效率：结合 Kubernetes 的弹性能力按需扩缩，帮助在吞吐、延迟与成本之间做更灵活的权衡。

1.3 本项目解决什么问题

本方案提供一套在 HyperPod (EKS) 上部署 ComfyUI 的参考实现，重点解决”环境一致性、持久化共享、对外访问与自动化验证”等落地问题，便于在开发生产场景中快速复用。

2. 方案特点

• AWS CloudFormation 一键创建 HyperPod (EKS) 集群：自动化创建集群与必要的周边资源，减少手工配置成本。
• Amazon Elastic File System (EFS) 共享存储与持久化：将 ComfyUI 的运行环境、代码、模型与输入/输出统一写入 EFS，支持 Pod 重启与扩缩容时复用。
• 轻量级运行镜像：基于 astral/uv:python3.12-bookworm-slim 构建轻量镜像，加快拉取与启动，提升扩缩容效率。
• Kubernetes Job 初始化与数据准备：通过 Job 在集群内完成代码拉取、依赖安装与模型下载，便于观测与重试，提升稳定性。
• 端到端自动化验收：通过 Job 调用 ComfyUI API 执行测试 workflow，部署后可快速验证可用性。
• 一键部署与清理：setup_all.sh 覆盖控制面、EFS、Ingress、初始化、Workload 与测试；cleanup_all.sh 一键回收资源。

3. 安全注意事项

在开始部署之前，请注意以下重要的安全考虑事项：

1. 网络访问控制：
   • 本方案中的应用负载均衡器（ALB）配置为仅内部访问
   • 客户端应用需要建立适当的网络连接才能访问服务
   • 需要配置合适的安全组以确保通信正常
2. 访问安全建议：
   • 强烈建议在 ALB 前端实现自己的身份认证层
   • 可以考虑实现以下解决方案：
     • 使用 AWS Cognito 进行用户认证
     • 使用带有自定义授权器的 API Gateway
     • 使用您组织现有的认证系统
   • 实施适当的 IAM 角色和策略以进行服务访问
3. 网络要求：
   • 如果从不同的 VPC 访问，确保配置了 VPC 对等连接或 Transit Gateway
   • 配置安全组以只允许来自可信源的流量
   • 考虑使用 AWS PrivateLink 以增强安全性

4. 方案架构

本方案采用开发与部署分离的架构设计，通过 EFS 实现环境共享和版本管理，分为 workflow 开发阶段和 workflow 推理部署阶段。

4.1 workflow 开发阶段

1. 开发者在开发环境（如 EC2 实例或本地）将 EFS 挂载到 ComfyUI 项目目录，所有环境依赖安装、代码修改、custom nodes 安装以及模型下载的数据都持久化到 EFS。
2. 通过创建不同的 ComfyUI 项目目录，实现环境隔离和版本控制。每个目录包含独立的环境依赖、代码、custom nodes 和模型。

4.2 workflow 推理部署阶段

1. ComfyUI Pod 挂载 EFS，读取指定的 ComfyUI 项目目录，该目录包含运行所需的所有环境、代码以及模型。
2. 通过修改 Deployment 配置切换不同的项目目录路径，实现版本迭代和灰度发布。
3. 服务通过 Ingress 对外暴露，支持 API 调用和 Web UI 访问。

5. Demo 生成效果

本方案使用 Hunyuan3D-2mv-turbo 模型以及 sample workflow 进行 demo：

图片输入

3D 输出（下载下面的图片并拖进 ComfyUI 即可加载 workflow）

6. 方案部署指引

6.1 准备工作

此方案需要在当前环境安装以下工具：

• AWS CLI
• helm
• kubectl
• jq

并且当前环境的 AWS profile 需要配置 AdministratorAccess 权限（AdministratorAccess 仅限测试，生产环境请遵循最小权限原则）

6.2 自动化部署方案

git clone https://github.com/aws-samples/sample-comfyui-on-hyperpod.git
cd comfyui-on-hyperpod && git checkout stable
cp cluster_config_template.sh cluster_config.sh

编辑 cluster_config.sh 设置 REGION 以及 HP_CLUSTER_NAME (HyperPod Cluster Name)

$ cat cluster_config.sh
#!/bin/bash

# Set environment variables for the HyperPod ComfyUI cluster
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
export REGION="us-west-2"
export HP_CLUSTER_NAME="hyp-comfyui"

# Generate during deployment

执行自动化脚本进行部署

bash setup_all.sh

6.3 部署方案细节

6.3.1 创建 HyperPod Cluster 控制面及 Instance Groups

HyperPod Cluster (EKS) 可以通过 Console 以及 CloudFormation 两种方式进行创建，本方案使用 CloudFormation 创建 EKS 集群以及周边依赖的资源：

• 部署代码参考 comfyui-on-hyperpod/Hyp-Control-Plane/setup.sh
• CloudFormation 的参数为 comfyui-on-hyperpod/Hyp-Control-Plane/hyp-stack-params.json
• 当前的方案在 hyp-stack-params.json 中配置了两个 Instance Groups：
  • g5-2xl：一台 ml.g5.2xlarge 用于承载 ComfyUI Pod
  • t3-xl：两台 ml.t3.xlarge 用于承载 EKS plugin 的各种 CPU Pods
  • 由于每个 HyperPod 的 instance 有最大 pod 数量限制，所以额外启动两台 ml.t3.xlarge 的机器承载非 ComfyUI 的 Pod

6.3.2 配置 EFS 资源

本方案将 ComfyUI 的代码、models、custom nodes 以及 uv 运行环境存储在 EFS 上，提供给所有 ComfyUI Pod 共享，需要先在当前 HyperPod EKS 环境中配置 EFS 资源：

• 部署代码参考 comfyui-on-hyperpod/EFS/setup.sh
• 会创建 EFS filesystem、EFS PVC 以及 EFS CSI Driver 在 K8S 上的各种资源依赖和权限配置
• 配置完成后会创建一个测试 Pod 挂载 EFS 的 PVC 进行读写

6.3.3 配置 Ingress 资源

本方案将 ComfyUI 的 service 通过 Ingress 暴露出去，需要在当前 HyperPod EKS 环境中配置 Ingress 资源：

• 部署代码参考 comfyui-on-hyperpod/Ingress/setup.sh
• 会创建 AWS Load Balancer Controller 在 K8S 上的各种依赖和权限配置

6.3.4 初始化 ComfyUI 运行环境

本方案通过 K8S Job 的方式运行一次性任务，挂载 EFS PVC 将 ComfyUI 的代码、模型以及 uv 运行环境存储到 EFS 上：

• 部署代码参考 comfyui-on-hyperpod/ComfyUI-Datas/setup.sh
• 初始化脚本参考 comfyui-on-hyperpod/ComfyUI-Datas/prepare-comfyui-datas.sh
• 本方案使用 Hunyuan3D-2 模型进行 demo

6.3.5 部署 ComfyUI workload

本方案通过 deployment 和 service 部署并暴露 ComfyUI 服务，Pod 挂载 EFS PVC 以使用初始化好的环境、代码和模型：

• 部署代码参考 comfyui-on-hyperpod/ComfyUI-Deploy/setup.sh
• 基于安全考虑，本方案部署的 Ingress 为 internal 类型，可以在 comfyui-on-hyperpod/ComfyUI-Deploy/comfyui-service.yaml 按需求修改

6.3.6 测试 ComfyUI workload

本方案通过 K8S Job 的方式运行一次性任务调用 API 来测试 ComfyUI workload：

• 测试代码参考 comfyui-on-hyperpod/ComfyUI-Test/run_test.sh
• 测试调用完成后会在 Pod 的 ComfyUI/output/mesh 目录下生成一个 3D glb 文件
• 通过类似 kubectl cp $(kubectl get pods -l app=comfyui -o jsonpath='{.items[0].metadata.name}'):comfyui-datas/ComfyUI/output/mesh/ComfyUI_00001_.glb ComfyUI_00001_.glb 的命令可以将 3D glb 文件拷贝到本地打开

7. 清理资源

在 project 目录下执行自动化脚本清理所有资源

cd comfyui-on-hyperpod && bash cleanup_all.sh

8. 总结

本方案提供了一套在 AWS SageMaker HyperPod 上部署 ComfyUI 的生产级参考实现，通过 CloudFormation 和自动化脚本实现一键部署，利用 EFS 共享存储解决环境持久化和版本管理问题。方案采用开发与部署分离的架构设计，结合 HyperPod 的自愈能力和 Kubernetes 的弹性扩展，为企业级 AI 工作流推理服务提供了稳定可靠的基础设施方案。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用