关于人工智能:Kubernetes-上的机器学习推理可以通过这种方式进一步增强

1次阅读

共计 5501 个字符，预计需要花费 14 分钟才能阅读完成。

创立一个牢靠、高效的机器学习推理服务须要做很多的投入。到底多麻烦？以一个基于 XGBoost 模型的服务来说：

开发人员须要创立一个欠缺的应用程序，例如通过 Flask 来加载模型，而后运行终端节点。
为了创立这个应用程序，开发人员须要思考队列治理、无故障部署以及从新加载新训练的模型等事宜。
利用开发好后被打包成容器镜像，而后推送到镜像仓库。Kubernetes 从镜像仓库拉取该镜像在集群上进行部署，部署好后才能够对外提供服务。
这些步骤须要数据科学家从事与进步模型准确性无关的工作，或引进 DevOps 工程师来做这些工作。
这些过程加到开发计划中，必然会须要更多的工夫进行服务迭代。

AWS 最近公布了实用于 Kubernetes 的 Amazon SageMaker Operator，借此，咱们能够用 SageMaker 托管的终端节点加强现有 Kubernetes 集群。借助 SageMaker Operator，开发人员只须要编写 yaml 文件来指定所保留模型的 S3 存储地位，而实时预测通过平安的终端节点即可应用。重新配置终端节点与更新 yaml 文件一样简略。

除了应用简略外，该服务还具备以下特色：

多模型终端节点 – 托管几十个或更多模型可能会给配置带来艰难，并且会导致很多机器以低利用率运行。多模型终端节点通过动静加载用于服务的模型构件来设置一个实例；
弹性推理 – 在拆离开的 GPU 上运行较小的工作负载，能够以较低的老本部署该 GPU；
高利用率和动静 Auto Scaling – 终端节点能够以 100% 的利用率运行，并基于咱们定义的自定义指标（如每秒钟的调用数量）来增加正本。或者能够按预约义的客户端性能指标配置主动扩大；
可用区转移 – 如果产生中断，Amazon SageMaker 会将终端节点主动挪动到 VPC 内的另一个可用区；
A/B 测试– 设置多个模型，并导向与单个终端节点上设置的量成比例的流量；
安全性 – 终端节点应用 HTTPS 创立，可配置为在公有 VPC（没有互联网进口）中运行并通过 AWS PrivateLink 拜访；
合规性筹备 – Amazon SageMaker 曾经过认证，合乎 HIPAA、PCI DSS 和 SOC (1, 2, 3) 规定和法规。

AWS 为 Kubernetes 开发的 SageMaker Operator 将以上这些个性打包到一起。SageMaker Operator 大大缩短模型到利用的工夫，并缩小创立和保护生产环境的人力。这能够使独自应用 EKS 或 EC2 的总领有老本降落 90%。

本文演示如何设置实用于 Kubernetes 的 Amazon SageMaker Operator，以齐全从 kubectl 为事后训练的 XGBoost 模型创立和更新终端节点。该解决方案蕴含以下步骤：

创立 IAM Amazon SageMaker 角色，提供服务模型所需的 Amazon SageMaker 权限
筹备 YAML 文件，以将模型部署到 Amazon SageMaker
将模型部署到 Amazon SageMaker
查问终端节点以获取预测
对部署的模型执行最终的一致性更新

本文假如合乎以下先决条件：

一个 Kubernetes 集群
集群上已装置 Amazon SageMaker Operator
一个能够部署的 XGBoost 模型

无关将 Operator 装置到 Amazon EKS 集群上的信息，请参阅现已推出实用于 Kubernetes 的 Amazon SageMaker Operator。咱们能够自带 XGBoost 模型，但本教程应用后面所述文中的现有模型。

Amazon SageMaker 须要一个 IAM 角色，它能够承当该角色来服务您的模型。如果还没有该角色，请应用上面的 bash 代码创立一个：

export assume_role_policy_document='{"Version":"2012-10-17","Statement": [{"Effect":"Allow","Principal": {"Service":"sagemaker.amazonaws.com"},"Action":"sts:AssumeRole"
  }]
}'
aws iam create-role --role-name <execution role name> \
    --assume-role-policy-document \
    "$assume_role_policy_document"
aws iam attach-role-policy --role-name <execution role name> \
    --policy-arn \
    arn:aws:iam::aws:policy/AmazonSageMakerFullAccess

将 <execution role name> 替换为实用的角色名称。这将创立一个 IAM 角色，Amazon SageMaker 能够应用该角色来服务咱们的模型。

Operator 提供名为 HostingDeployment 的自定义资源定义 (CRD)。咱们能够应用 HostingDeployment 在 Amazon SageMaker 托管上配置模型部署。

要筹备托管部署，请应用以下内容创立名为 hosting.yaml 的文件：

apiVersion: sagemaker.aws.amazon.com/v1
kind: HostingDeployment
metadata:
  name: hosting-deployment
spec:
  region: us-east-2
  productionVariants:
    - variantName: AllTraffic
      modelName: xgboost-model
      initialInstanceCount: 1
      instanceType: ml.r5.large
      initialVariantWeight: 1
  models:
    - name: xgboost-model
      executionRoleArn: SAGEMAKER_EXECUTION_ROLE_ARN
      containers:
        - containerHostname: xgboost
          modelDataUrl: s3://BUCKET_NAME/model.tar.gz
          image: 825641698319.dkr.ecr.us-east-2.amazonaws.com/xgboost:latest

将 SAGEMAKER_EXECUTION_ROLE_ARN 替换为在上一步中创立的执行角色的 ARN。将 BUCKET_NAME 替换为蕴含模型的存储桶。
确保存储桶区域 HostingDeployment 区域和映像 ECR 区域统一。

随后能够通过运行 kubectl apply -f hosting.yaml 来启动部署。请参阅以下代码：

$ kubectl apply -f hosting.yaml
hostingdeployment.sagemaker.aws.amazon.com/hosting-deployment created

咱们能够应用 kubectl get hostingdeployments 跟踪部署状态。请参阅以下代码：

$ kubectl get hostingdeployments
NAME                 STATUS     SAGEMAKER-ENDPOINT-NAME
hosting-deployment   Creating   hosting-deployment-38ecac47487611eaa81606fc3390e6ba

模型终端节点最多可能须要十五分钟能力部署好。咱们能够应用以下命令查看状态。终端节点达到 InService 状态后便能够立刻用于查问。

$ kubectl get hostingdeployments
NAME                 STATUS      SAGEMAKER-ENDPOINT-NAME
hosting-deployment   InService   hosting-deployment-38ecac47487611eaa81606fc3390e6ba

终端节点投入使用后，能够测试它是否能与以下示例代码联合应用：

$ aws sagemaker-runtime invoke-endpoint \
  --region us-east-2 \
  --endpoint-name SAGEMAKER-ENDPOINT-NAME \
  --body $(seq 784 | xargs echo | sed 's/ /,/g') \
  >(cat) \
  --content-type text/csv > /dev/null

bash 命令应用 AWS CLI 与 HTTPS 终端节点连贯。咱们创立的模型基于 MNIST 位数据集，预测工具会读取图像中的数字。当进行此调用时，它会以 CSV 格局发送蕴含 784 项特色的推理负载，这些特色代表图像中的像素。咱们将在负载中看到模型所认为的预测数字。请参阅以下代码：

$ aws sagemaker-runtime invoke-endpoint \
  --region us-east-2 \
  --endpoint-name hosting-deployment-38ecac47487611eaa81606fc3390e6ba \
  --body $(seq 784 | xargs echo | sed 's/ /,/g') \
  >(cat) \
  --content-type text/csv > /dev/null
8.0

此代码确认终端节点已启动并在运行。

部署好模型后，咱们能够对 Kubernetes YAML 进行更改，SageMaker Operator 将更新终端节点。这些更新将以最终统一的形式流传到 Amazon SageMaker。这样一来，咱们便能够以申明式的形式配置终端节点，并让 SageMaker Operator 解决细节。

为证实这一点，咱们能够将模型的实例类型从 ml.r5.large 更改为 ml.c5.2xlarge。请执行以下步骤：

将 hosting.yaml 中的实例类型批改为 ml.c5.2xlarge。请参阅以下代码：

apiVersion: sagemaker.aws.amazon.com/v1
kind: HostingDeployment
metadata:
  name: hosting-deployment
spec:
  region: us-east-2
  productionVariants:
    - variantName: AllTraffic
      modelName: xgboost-model
      initialInstanceCount: 1
      instanceType: ml.c5.2xlarge
      initialVariantWeight: 1
  models:
    - name: xgboost-model
      executionRoleArn: SAGEMAKER_EXECUTION_ROLE_ARN
      containers:
        - containerHostname: xgboost
          modelDataUrl: s3://BUCKET_NAME/model.tar.gz
          image: 825641698319.dkr.ecr.us-east-2.amazonaws.com/xgboost:latest

将更改利用至 Kubernetes 集群。请参阅以下代码：

$ kubectl apply -f hosting.yaml
hostingdeployment.sagemaker.aws.amazon.com/hosting-deployment configured

获取托管部署的状态。该状态将显示为正在更新，而后在筹备好当前更改为 InService。请参阅以下代码：

$ kubectl get hostingdeployments
NAME                 STATUS     SAGEMAKER-ENDPOINT-NAME
hosting-deployment   Updating   hosting-deployment-38ecac47487611eaa81606fc3390e6ba

终端节点在整个更新过程中放弃实时状态且齐全可用。无关更多信息和其余示例，请参阅 GitHub 存储库。

要删除终端节点而不会产生更多应用费用，请运行 kubectl delete -f hosting.yaml。请参阅以下代码：

$ kubectl delete -f hosting.yaml
hostingdeployment.sagemaker.aws.amazon.com "hosting-deployment" deleted

本文演示了实用于 Kubernetes 的 Amazon SageMaker Operator 如何反对实时推理。它还反对训练和超参数调整。

心愿大家能分享本人的教训和反馈，或者提交其余示例 YAML 标准或 Operator 改良信息。大家能够分享应用实用于 Kubernetes 的 Amazon SageMaker Operator 的相干状况，在 AWS 论坛中的 Amazon SageMaker 的板块下公布帖子，在 GitHub 存储库中创立问题，或发送给 AWS Support 联系人并由其代为转达。

正文完