自动化 IoT 机器学习:通过 AI Platform 结合云和设备的优势

渲染图片

本教程介绍如何自动化可将新的或更新后的机器学习 (ML) 模型直接交付给 IoT(物联网)设备的工作流。

工作流如下:

  • 使用 AI Platform 训练机器学习模型版本。
  • 使用逼真的 CAD 渲染数据训练机器学习模型。
  • 自动打包新的或修改后的模型并交付给在本地运行推断(模型预测)的远程 IoT 设备。

通过自动化合并的机器学习训练和部署过程,您可以更轻松地优化模型,并将这些模型更快地部署到大量设备。

本教程还演示了如何使用云端 3D 渲染为基于视觉的图片模型自动生成训练数据。

零件检测

您的工作流使用自定义机器学习视觉检测模型来检测零件。随着零件库存逐渐发生变化,您可以定期更新机器学习模型,以识别新添加的零件并改进模型设计。然后,您可以将更新后的模型交付给多个实地现场中已获授权的部署设备。

另请参阅本教程的参考代码

目标

费用

本教程使用多项计费服务。但只需极低的费用即可简单运行。在生产环境中,最终费用取决于您最常使用教程的哪些部分。

准备工作

  1. 创建 Google Cloud Platform (GCP) 项目:

    转到“项目”页面

  2. 启动 Cloud Shell 实例。从 Cloud Shell 运行本教程中的所有终端命令。

    打开 Cloud Shell

  3. 启用 AI Platform Training and Prediction API、Compute Engine API、Container Registry API、Cloud Build API、Cloud Functions API 和 Cloud Dataflow API:

    启用 API

    此步骤可能需要几分钟才能完成。

  4. 跳过创建凭据的步骤。请改为在 Google Cloud Platform Console 横幅菜单中选择项目。

应用背景和架构

本教程将应对以下场景:附加到联网设备的摄像头通过视觉识别沿传送带或其他机构移动的机械零件。本教程重点介绍如何向启用摄像头且基于 Linux 的 IoT 设备进行交付,但您可以为具有不同传感器输入的其他类型设备构建类似的系统。

鉴于此应用的高可靠性要求,即使网络连接中断,零件检测设备也必须继续运行。为帮助实现这种可靠性,您可以在 GCP 上训练 TensorFlow 模型,然后在联网设备上本地运行该模型。已部署的模型无需云端连接即可进行预测。该模型可以存储记录的预测,并在重新联网时传输该预测。

解决方案架构包含以下主要部分:

  • 云端渲染训练数据
  • 训练和打包模型
  • 部署和交付新模型
  • 在边缘设备上执行训练的模型

下图高度概括地显示了这种架构。

架构

云端渲染训练数据

训练有效的机器学习模型需要大量准确添加标签的图片。然而,手动收集图片并为其添加标签的过程不仅枯燥而且耗时。此过程常常会发生标签添加错误,例如将青蛙划分为猫Inception 视觉模型使用的迁移学习技术可以减少对添加标签的图片的需求量,同时加快训练过程。不过,机器学习训练始终需要大量准确添加标签的图片。

对于某些使用场景(例如此图中显示的机械零件),您可能已拥有一整套的 CAD 设计的 3D 形状文件。

机械零件

您可以使用逼真的渲染软件自动为这些零件生成大量图片变体。这些变体可包括背景特征、方向、光源、灯光亮度、焦距以及镜头上的模拟污垢,准确训练指定应用的模型所需的各种特征都可以包含在内。渲染软件按照特定零件模型生成这些图片,因此可以自动准确地为输出图片添加标签。整个过程不涉及人工添加标签。

渲染是一项计算密集型任务,如果拥有同一零件的大量视图,数据集的训练将因此受益。为了帮助渲染和训练,Google Cloud Platform 提供了 ZYNC Render 服务。ZYNC 是一种在线 3D 渲染工具,可以为基于图片的自定义机器学习模型快速生成自动添加了标签的数据集。基于 CAD 的零件非常适合这种方法。然而,好莱坞已经证明了几乎一切事物均可逼真渲染。得益于云端渲染,难以收集训练图片并添加标签的几乎任何场景都可以考虑采用这种方法。

本教程提供了预先渲染的训练图片。要详细了解如何使用 ZYNC 自动渲染图片,请参阅本教程

自动生成图片的过程会产生一组渲染图片。为了向机器学习训练任务指示图片标签,请将这些图片集存储在 Cloud Storage 中名称对应于图片集分类标签的目录中。

训练和封装模型

AI Platform 为 TensorFlow 模型训练提供了完全托管的环境。通过利用并行训练,此环境使您能够快速迭代和调整模型性能,从而获得更准确的模型。AI Platform Training 会输出一个 TensorFlow SavedModel。您可以将这个工件部署到 IoT 设备并将其加载到本地预测服务器。

虽然本教程演示了云端渲染的图片训练数据集的用法,但以下架构适用于任何类型的机器学习模型,包括基于 IoT 传感器数据集的模型。

通用模型

定义模型标识符

定义模型时,请考虑如何处理训练某个模型版本所需的大量训练图片。

处理训练输入文件

经过训练的模型是以下两者的唯一组合:1) 训练算法代码和配置参数;2) 一组特定的训练输入。您可以使用 Git 等源代码管理工具来管理算法和配置代码并更新其版本。但这类工具无法处理生成特定模型版本所需的大量训练图片。

根据训练数据的性质,以下指南可帮助您管理训练输入。这些指南还可以帮助您重新创建用于某个训练作业的特定图片集合:

  • 在训练代码所属的代码库中,添加用于训练模型的输入文件清单。
  • 创建永久性磁盘快照
  • 使用 Git Large File 工具。
  • 将 BigQuery 数据集或 Cloud Storage 数据的副本复制到费用更低的归档层

在生产环境中,请务必确定合适的数据快照方法。在本教程中,您只使用演示数据集,因此无需管理训练数据。

模型版本

模型版本由特定的训练数据集和用于训练它的代码组成。类似于软件版本,模型版本也可受益于遵循明确约定,例如语义版本控制。在语义版本控制中,重大更改会改变模型输入的形状,而次要更改会提高模型的准确率,或者在输出中进行其他分类,例如添加到产品目录中的新零件

模型版本并不会捕获发布版本,如 Alpha 版或测试版。相反,模型版本类似于 Git 哈希。但在 Git 和 Docker 中,隐式发布版本称为 master (Git) 或 latest(Docker 代码库)。您可以使用发布版本将不同阶段的模型路由到特定的 IoT 设备组,例如 Alpha 版测试组。

下图显示了特定版本(由绿色或粉红色表示)在发布版本之间的移动轨迹。由粗体轮廓圆圈表示的版本会始终将客户端引导至该版本中的最新版本号。您可以在多个版本中使用同样的版本号,就像此处所示的粉红色版本一样。

多个版本中的版本号

此解决方案使用 [MODEL_NAME]_[MAJOR_VERSION]_[WORKFLOW_START_TIMESTAMP_AS_MINOR_VERSION] 作为模型版本,例如:

  • EquipmentParts_1_1501089026

    其中:

    • [MODEL_NAME]EquipmentParts
    • [MAJOR_VERSION]1
    • [WORKFLOW_START_TIMESTAMP_AS_MINOR_VERSION]1501089026

如果模型还会被部署到 AI Platform Prediction 以进行在线预测,您可以在 name 字段中使用模型版本字符串以获取在线资源的信息。如果将模型用于仅支持整数版本的 TensorFlow Serving,则可以使用 Unix 时间戳组件。

设置环境和存储分区

在本部分中,您将使用 Cloud Shell 克隆代码库,然后为项目配置并自定义该代码库。在本教程的剩余部分中,您将使用同一环境和 shell。如果要在默认区域 us-central1 以外的区域中运行,请更新 REGION 设置。

为此,请完成以下步骤:

  1. 首先,设置环境变量:

    export FULL_PROJECT=$(gcloud config list project --format "value(core.project)")
    export PROJECT="$(echo $FULL_PROJECT | cut -f2 -d ':')"
    export REGION='us-central1' #OPTIONALLY CHANGE THIS
    
  2. 创建几个在不同阶段中使用的存储分区:

    gsutil mb -l $REGION gs://$PROJECT-training
    gsutil mb -l $REGION gs://$PROJECT-model-output
    gsutil mb -l $REGION gs://$PROJECT-deploy
    
  3. 克隆演示代码库:

    git clone https://github.com/GoogleCloudPlatform/cloudml-edge-automation
    cd cloudml-edge-automation
  4. 运行自动搜索并替换某些代码库文件以配置项目。然后,将这些更改推送到项目的云端代码库中。由于某些平台工具会直接从此代码库中提取代码,因此您需要使此代码库的副本连接到网络:

    python bootstrap.py

    如果您之前未在 Cloud Shell 中配置 git:

    git config --global user.email "you@example.com"
    git config --global user.name "Your Name"
    
    git commit -a -m "custom project"
    gcloud source repos create ml-automation
    git config credential.helper gcloud.sh
    git remote add google https://source.developers.google.com/p/$FULL_PROJECT/r/ml-automation
    git push google master
    
  5. 最后,将现在修改过的模板文件推送到存储分区中:

    gsutil -m rsync -r model-deployment/deploy-bucket-bootstrap/ gs://$PROJECT-deploy

运行训练作业

本教程使用基于图片的训练数据,但您可以将“在云端上进行训练,然后分发到边缘进行预测”的自动原则应用到任意 TensorFlow 模型。以图片作为输入,就可以利用 Inception-v3 视觉模型的迁移学习功能。该方法仅重新训练深度神经网络模型的靠后层级,以此为不同的图片分类任务创建自定义模型。要详细了解 Inception 迁移学习,请参阅这篇博文

利用 Cloud Storage 中提供的渲染训练数据,您可以使用以下命令启动标准 AI Platform Training 作业:

cd trainer
pip install --user -r requirements.txt

export MODEL_NAME=equipmentparts
export MODEL_VERSION="${MODEL_NAME}_1_$(date +%s)"

bash run-training.sh

训练包括在托管式服务中进行图片预处理和机器学习训练。您可以在 Cloud Dataflow 控制台中跟踪预处理任务的训练进度,然后在控制台的机器学习部分进行跟踪。

将模型封装到容器中,以进行设备交付

训练作业的结果包括 Tensorflow 保存的模型,该模型存储在 Cloud Storage 存储分区中特定于模型 ID 的路径中。您可以通过各种方式运行这个可移植的模型。本教程重点介绍如何将模型部署到设备。本教程介绍了如何在线并行部署经过训练的模型,以便其他服务可以将其用于批量在线预测。

即使在 GCP 上,机器学习作业也可能需要一些时间才能完成。所提供的样本训练集和配置大约需要 15-20 分钟在 Cloud Dataflow 中进行图片预处理,需要 10 分钟在 AI Platform 中进行训练。

训练完成后,如果您不希望执行一系列手动任务,以通过多个发布阶段将经过训练的模型推送到设备,可以执行以下操作。

首先,您可以自动将经过训练的模型和模型运行程序代码打包到表单中,以便轻松交付给设备。要完成此打包操作,请借用基于服务器的应用所使用的常用技术,将模型数据和运行程序引擎打包到 Docker 容器中。

打包步骤使用 Cloud Build。Cloud Build 是一个托管的 Container Builder 服务,可通过多个构建步骤组成最终的 Docker 映像。生成的容器存储在 Container Registry 中,Container Registry 提供一个私有容器注册表,有助于安全地存储敏感模型。Container Registry 还会向设备提供经过身份验证的容器下载。通过全球网络边缘缓存,Container Registry 能够可靠地将打包模型交付给全球各地的设备。

要自动化 Cloud Build 构建,您可以使用 Cloud Function 监视要写入 Cloud Storage 的已保存模型的最终部分。使用 Cloud Storage 和 Cloud Function 之间的内置触发器通道监视输出存储分区中的所有文件写入。然后在写入最后导出的模型文件后,触发 Container Build。

要部署 Cloud Function,请运行以下命令:

cd ../model-packaging/build-trigger-function/
gcloud functions deploy modelDoneWatcher --trigger-bucket $PROJECT-model-output

Cloud Function 可执行以下任务:

  • 响应训练输出写入的最后一个文件。
  • 提取整个模型输出位置和路径中编码的模型版本。
  • 使用该数据填充发送到 Cloud Build 服务的构建提交内容中的变量。系统将为模型供应软件包的每个运行时架构分派一个构建提交内容。
  • 将生成的模型的已命名版本部署到 AI Platform 以进行在线预测。此功能为可选功能,可以停用。

如需了解详情,请参阅解决方案代码库中的 Cloud Function 源。

此软件包需要具有基础映像。请使用以下命令进行创建:

cd ../model_base_container/
gcloud builds submit --config cloudbuild-model-base-x86_64.yaml .

从 Cloud Functions 函数接收到构建请求后,Cloud Build 服务会执行以下步骤:

  1. 将模型输出复制到容器中。
  2. 将运行服务代码的模型复制到容器中。
  3. 将模型版本和 latest 标志应用于构建的容器。

自动部署打包的模型容器

本部分介绍如何自动执行按签署步骤打包模型并将其交付给边缘设备的过程。下图显示了该工作流。

工作流

通过使用容器作为打包类型,您可以利用易于理解、封装和移植的运行时打包系统。您还可以通过它使用某些工具和模式实现服务器容器交付,从而实现无线 (OTA) 更新。

Kubernetes 是一个得到广泛部署的、复杂的容器编排系统。在大型(服务器规模)边缘基础架构或混合环境中,您可以运行完整的 Kubernetes 控制平面,但在大多数资源有限的 IoT 设备上却不现实。因为这些设备可能只有 1 或 2 GB 的 RAM,而且是在比一般的服务器更慢的处理器上运行。

不过,您仍然可以在受限的 IoT 设备上使用各种 Kubernetes 系统组件,如 PodKubelet。Kubelet 是 Kubernetes 集群的每个节点上存在的主要代理。它的一些关键任务是:

  • 从注册表下载指定的容器。
  • 安装 pod 所需的卷。
  • 使用容器运行时运行 pod 的容器。

本教程中的解决方案并不是要尝试将许多 IoT 设备作为大型分布式 Kubernetes 集群(一种 Kubernetes 反模式)运行。Kubernetes 控制平面和服务专门面向数据中心级别的低延迟网络,这种网络可将集群内的节点相互连接。相反,该解决方案使用 Kubernetes 构建块作为声明式容器下载代理和进程管理器。

通常情况下,集群主实例上运行的 API 服务器会直接指定在计算机上运行哪个 Kubernetes pod。不过,Kubelet 可以使用本地清单文件夹,其中包含 PodSpec 格式的 YAML 文件,解决方案会使用该文件传达要在设备上加载和传送哪个模型。

单独使用 Kubelet 的一个结果是,您可以部署 pod,但不能部署集群级别更高的抽象化,例如部署复制集。对于此解决方案,只需在 IoT 设备上运行几个基于容器的服务,因此使用 pod 就足够了。您已将软件包构建为容器并将其存储在 Container Registry 中。Container Registry 可以安全可靠地提供构成 Docker 映像的层级。

下面介绍您需要在远程设备上安装哪些内容才能使这些设备开始接收模型更新。

映像标记和发布渠道

模型版本部分介绍了使用发布版本或渠道来定位具有不同模型版本的各种设备种类,例如,在一组 alpha 版设备上测试新的模型版本。

Docker 映像支持将一个或多个标记与映像相关联的概念。每个映像都包含一组由 digest 标记的层级版本。特定标记每次只能与一个 digest 相关联。按照惯例,latest 标记应用于映像最新添加的 digest 层。

您可以使用映像标记表示哪个版本的映像与哪个发布渠道相关联。此解决方案使用以下渠道:

  • latest
  • alpha
  • beta
  • stable

当自动化的 Cloud Build 服务构建映像版本之后,它会将 latest 标记应用到每个映像版本。您可以通过 Container Registry 控制台或其他 CLI 工具应用其他标记。

即使底层 digest 已发生更改,Kubernetes 也不会重新提取给定的映像标记。您需要一种方法,能够在构建了新的模型版本或每次更新标记时,都可以自动生成新的或更新后的 Kubernetes pod 清单。

您可以使用 Cloud Functions 作为自动化工具来实现此目的。Container Registry 会将构建通知发布到 Cloud Pub/Sub。您可以使用 Cloud Functions 监控 Container Registry 中的这些映像变化,并自动将新的或已修改的 Pod 清单写入部署存储分区。由于模型封装器会为每个目标设备架构构建映像,因此每个架构都有一个对应的子文件夹。该架构文件夹中包含每个发布版本对应的文件夹。您可以使用特殊的 all 文件夹保存需要部署到所有发布版本的通用基础软件包。

典型的目录结构如下所示:

  • 部署存储分区

    • x86_64

      • all
      • latest
      • alpha
      • beta
      • stable
    • armv7l

      • all
      • latest
      • alpha
      • beta
      • stable

部署 Cloud Function 以监控 Container Registry 中的映像更改,并将更新后的 PodSpec 格式的 YAML 文件写入部署存储分区文件夹:

cd ../../model-deployment/tag-monitor-function/
gcloud pubsub topics create gcr
gcloud functions deploy tagMonitor --trigger-topic gcr

运行设备端组件

此解决方案支持在多种计算架构上运行模型,包括:x86_64(笔记本电脑和服务器通用)和 ARM(许多 IoT 设备通用)。

为了以可供最广泛的受众群体测试的方式演示自动化工作流,本部分将使用 Compute Engine 虚拟机 (VM) 作为模拟 IoT 设备。如果您拥有所需的硬件,则可以将 ARM 容器部署到较小的受限设备,例如常见的 Raspberry Pi。

目标设备具有两个主要管理基础架构:

  • Kubelet

    您需要安装并运行 Kubelet。

  • 配置

    您需要使用指向 pod 同步的指针来引导 YAML pod 文件夹。服务容器。

在虚拟机实例上创建模拟设备

  1. 运行以下命令,创建一个基于 Ubuntu 的虚拟机实例以用作模拟 IoT 设备:

    gcloud compute --project $FULL_PROJECT \
        instances create "mock-device" \
        --zone "us-central1-f" \
        --machine-type "g1-small" \
        --subnet "default" \
        --scopes "https://www.googleapis.com/auth/cloud-platform" \
        --image "ubuntu-1710-artful-v20180109" \
        --image-project "ubuntu-os-cloud" \
        --boot-disk-size "10" \
        --boot-disk-type "pd-standard" \
        --boot-disk-device-name "mock-device-disk"
        
  2. setup 脚本复制到该设备:

    cd ../../client-files/
    gcloud compute scp --zone "us-central1-f" kubelet.service mock-device:/tmp
    # note you might need to generate GCP SSH keys if this is the first time
    gcloud compute scp --zone "us-central1-f" setup-mock-gce-vm.sh mock-device:
    gcloud compute scp --zone "us-central1-f" demo_client.py mock-device:
    
  3. 连接并执行设置脚本。要区分 Cloud Shell 和模拟设备的 shell,请直接打开设备的 SSH 终端,而不是从 Cloud Shell 中打开。您可以从 GCP Console 或您的本地终端执行该操作。

    # click the SSH button in the Compute Engine list or run
    # gcloud compute ssh --zone "us-central1-f" mock-device
    # in the mock-device shell:
    chmod +x setup-mock-gce-vm.sh
    ./setup-mock-gce-vm.sh
    

    此脚本将 Docker 和 Kubelet 作为服务进行安装。

构建同步服务 pod

接下来,您将创建一个容器,它负责在更新后的部署存储分区和目标设备之间同步 pod 清单。然后向每个发布版本引导此同步工具的不同配置。您使用的工具版本决定了设备的发布版本。例如,如果您在设备上使用测试版同步工具,则可以下拉该模型的测试版。此工具使用 gsutil rsync 下载最新清单,并确保当前清单为最新版本。

创建同步 pod

这些 Cloud Build 任务会构建容器,以运行定期调用 gsutil rsync 命令的脚本。容器会选取特定于每个发布版本的 PodSpec 格式的 YAML 文件中指定的环境变量设置。在 Cloud Shell 中运行以下代码:

cd ../model-deployment/sync-pod
gcloud builds submit . --config=cloudbuild-x86_64.yaml &
gcloud builds submit . --config=cloudbuild-armv7l.yaml

在设备上安装同步 pod

现在,在模拟设备的 shell 中,运行以下代码以安装最新发布版本的同步 pod:

export PROJECT=`curl -s "http://metadata.google.internal/computeMetadata/v1/project/project-id" -H "Metadata-Flavor: Google"`

sudo gsutil cp  gs://$PROJECT-deploy/x86_64/latest/sync-pod.yaml /opt/device/pods/

片刻之后,您应该能够使用以下命令查看 pod 的运行情况:

sudo docker ps

此容器运行之后便会立即下载指定发布版本的容器。

执行部署自动化

在关闭机器学习作业训练和打包器之间的循环之前,先了解自动部署的工作原理会非常有用。这样您很有可能在所有基于 Cloud Function 的自动化部署完成之前,就可以完成提交的第一个机器学习训练作业。在提交并测试另一个模型版本之前,请先尝试使用可在更快时间内构建的模型部署自动化。

对于这种方法,您将使用简单的网络服务器,该服务器可以快速迭代以创建新版本。生成新版本后,您可以测试在生成的 OTA 更新中操控映像标记的效果。

在 Cloud Shell 中运行以下代码,以生成网络服务器:

cd ../simple-web-test
gcloud builds submit . --config=cloudbuild-x86_64.yaml

构建此网络服务器时:

  • 创建一个新容器。
  • 容器标有 latest.
  • 使用该映像的哈希呈现 pod 清单文件。
  • 设备的同步 pod 会拉下新的清单。
  • Kubelet 拉下容器并确保它正在运行。
  1. 在设备的 shell 中,确定当前部署的版本:

    curl localhost:8080/version/

    输出是由此容器提供的当前映像哈希,由一串随机的长字符串组成。

  2. 接下来,在 Cloud Shell 中重复 Cloud Build 命令:

    gcloud builds submit . --config=cloudbuild-x86_64.yaml
  3. 所有前面的步骤都是重复的,大约一分钟后,设备会运行最新的映像。您可以通过在设备的 shell 中重复版本检查来验证这一点:

    curl localhost:8080/version/

在 Container Registry 控制台中,您可以看到容器的不同构建版本。您可以通过修改标记来更改要部署到 latest 路径的特定映像。您可以将特定标记仅应用于一个映像版本。通过编修改早期版本的标记并添加 latest 标记可验证这一点。该标记将从最新的映像版本中移除,并应用到您正在修改的版本中。

您还可以将 alpha 标记添加到特定映像版本。如果查看部署存储分区,则会在 alpha 部署子文件夹中看到该哈希的新 pod 清单。

通过此过程,您可以轻松地将不同的模型版本从 latest 迁移到 alphabeta 等等。这些版本会自动交付到相应的目标设备群。

要显示完整的端到端自动化工作,您需要启动另一项训练作业。您可以通过修改制作工具文件来模拟完成训练,也可以重新运行模型训练以创建新的模型版本。

模拟完成早期训练:

gsutil mv -p gs://$PROJECT-model-output/equipmentparts/$MODEL_VERSION/model/TRAINER-DONE gs://$PROJECT-model-output/equipmentparts/$MODEL_VERSION/model/TRAINER-DONEx
gsutil mv -p gs://$PROJECT-model-output/equipmentparts/$MODEL_VERSION/model/TRAINER-DONEx gs://$PROJECT-model-output/equipmentparts/$MODEL_VERSION/model/TRAINER-DONE

要重新运行新模型训练,首先您要确保在 Cloud Shell 中使用新的唯一模型版本环境变量:

export MODEL_VERSION="${MODEL_NAME}_1_$(date +%s)"

如果您在断开连接后重新连接,则必须按照上文所述重新安装所需的 Python 内容,因为它们不会保留在 Cloud Shell 环境中。移至代码库的训练程序目录并执行以下命令:

bash run-training.sh

当此模拟或训练完成时,您会看到以下自动生成的工件:

  1. 每个目标架构的容器注册表映像。这些映像包含打包的模型以及小型模型服务器示例。
  2. 对应于 [PROJECT]-deploy 存储分区中每个架构的 latest 子文件夹中的更新后的 pod YAML 清单。

运行模型推断

模型运行程序以小型网络应用的形式实现,它与特定模型版本一起打包到容器中。

您还可以分发客户端作为容器,但在这种情况下,您可以在设备的 shell 中直接输入命令。

  1. 通过检查版本端点来验证更新:

    curl localhost:5000/version/

    此命令返回当前映像哈希。

  2. 对容器运行的当前模型运行推理:

    wget -P /tmp/images https://storage.googleapis.com/iot-ml-edge-public/test-images/part1-test.jpeg
    python demo_client.py /images/part1-test.jpeg

    输出类似于以下内容:

    [
      [
        "part-1",
        0.9626434445381165
      ],
      [
        "part-2",
        0.01897098496556282
      ],
      [
        "part-3",
        0.01838531903922558
      ],
      [
        "part-4",
        2.7895106313735596e-07
      ]
    ]
    

    此输出显示模型排序后的预测,在本例中,该模型为 part-1 的置信度为 96%。现在,您已将更新后的 TensorFlow 模型自动部署到边缘。从此处,您可以在本地处理该数据,或使用 Cloud IoT Core 向在云端托管的应用报告推断遥测。

清理

为避免因本教程中使用的资源而导致系统向您的 Google Cloud Platform 帐号收取费用,请执行以下操作:

  1. 在 GCP Console 中,转到“项目”页面。

    转到“项目”页面

  2. 在项目列表中,选择要删除的项目,然后点击删除
  3. 在对话框中输入项目 ID,然后点击关闭以删除项目。

后续步骤

此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
解决方案