尧图网站建设 
CircularNet 部署指南基于 Triton Inference Server 在 Google CloudT4与 Jetson 边缘设备上构建垃圾图像推理服务【免费下载链接】modelsModels and examples built with TensorFlow项目地址: https://gitcode.com/GitHub_Trending/mode/models本文围绕 CircularNetTensorFlow Model Garden 中waste_identification_ml项目提供的垃圾识别模型的部署教程展开如何为 CircularNet 创建一个基于 NVIDIA Triton Inference Server 的推理服务覆盖 Google Cloud 上挂载 NVIDIA T4 GPU 的云 VM 与 NVIDIA Jetson 边缘设备两条路径并完整拆解从克隆仓库、环境安装、启动 Triton 服务到运行推理客户端流水线的每一步操作同时结合仓库中Deploy/detr_cloud_deployment下的真实脚本源码说明各参数的作用与底层实现帮助读者独立完成 CircularNet 的端到端部署与验证。CircularNet 部署方式概述CircularNet 可以部署在任意云服务商或推荐的边缘设备上但官方部署教程聚焦于一条经过验证的路径创建并运行一个部署在 Google Cloud 或 NVIDIA 设备上的 Triton Inference Server。该服务的设计目标是高效地处理图片或视频输入——将输入拆分为逐帧图像并对每一帧执行模型预测。教程针对两类硬件给出说明部署目标硬件适用场景Google Cloud 云 VMNVIDIA T4 GPU 计算单元云端批量图像/视频推理边缘设备NVIDIA Jetson如 Jetson Orin本地/现场实时推理教程同时明确了一个前提部署 CircularNet 模型需要具备管理基础设施、执行命令、以及在云端或边缘设备上配置连接与权限的技术能力即读者应熟悉 Linux 命令行、Docker 与云平台基础操作。完整的分步文档位于教程章节circularnet-docs/content/deploy-cn/下部署须知、克隆仓库、启动服务端、启动客户端对应的部署代码位于 Deploy/detr_cloud_deployment 目录。部署前准备准备 Google Cloud VM 或 Jetson 设备Google Cloud 路径创建挂载 T4 GPU 的 VM按 before-you-begin.md 的说明Google Cloud 路径需要准备如下创建 Google Cloud 账号与项目并设置计费账户在项目中启用三个 APICompute Engine API、BigQuery API、Cloud Storage API推理结果需要写入 BigQuery 表、图像存储在 Cloud Storage因此这三个 API 缺一不可创建一台挂载 NVIDIA T4 GPU 的 Compute Engine 虚拟机关键配置如下机型n1-standard-88 vCPU30 GB 内存GPU 类型 NVIDIA T4数量 1操作系统选择 Deep Learning on Linux 镜像版本为预装 CUDA 11.3 的 Deep Learning VMDebian 11Python 3.10启动盘Balanced persistent disk容量 300 GB用于存放模型仓库与依赖身份与 API 访问使用 Compute Engine 默认服务账户访问范围选择允许完全访问所有 Cloud API后续客户端流水线需要读写 GCS 与 BigQuery防火墙允许 HTTP 与 HTTPS 流量Triton 推理端口建议为 VM 起一个易记的名字并部署在支持 GPU、且靠近你物理位置可用区的区域。在 Google Cloud 控制台的Compute Engine VM instances页面找到该实例点击SSH使用 SSH-in-browser 工具连接。若 SSH 连接失败需为 VM 创建防火墙规则放行 TCP 入站流量IAP TCP 转发场景放行 TCP 端口22,3389。NVIDIA Jetson 边缘设备路径边缘设备路径的准备相对精简获取边缘设备、完成配置并连接至本地机器确保设备有互联网连接部署过程需要安装软件包按照设备的官方开发者指南完成系统设置、安装所需软件与依赖、准备对应的开发工具包以 Jetson 为例即其 Developer Guide打开设备终端通过命令行与操作系统交互——后续所有部署命令都在这个终端中执行。克隆仓库并安装依赖环境满足上述前置条件后在 Google Cloud VM 的 SSH-in-browser 窗口或边缘设备终端中按 clone-repo.md 依次执行安装 Gitsudo apt-get install git克隆包含 CircularNetwaste_identification_ml的 TensorFlow Model Garden 仓库git clone --depth 1 https://gitcode.com/GitHub_Trending/mode/models.git浅克隆--depth 1只拉取最新提交可显著减少下载体积克隆得到的目录名为models这也是后续所有相对路径的起点。进入waste_identification_ml项目中的client目录cd models/official/projects/waste_identification_ml/Deploy/detr_cloud_deployment/client/运行 requirements.sh 安装所有必需的包和库sh requirements.sh返回上一级目录cd\。requirements.sh 实际做了什么从源码看requirements.sh 并非简单的pip install它完成了完整的环境自举强制以/bin/bash执行脚本执行sudo apt-get update后检查 Docker 是否存在若未安装则通过官方安装脚本自动安装 Docker边缘设备上这一步尤其关键因为 Triton 服务端以 Docker 容器方式运行安装python3-venv与python3-pip用python3.10 -m venv myenv创建名为myenv的虚拟环境并激活执行pip install -r requirements.txt安装 ML 依赖若当前目录下不存在models目录会再次执行浅克隆这是一个幂等保护确保后续cd models/...的相对路径一定有效最后退出虚拟环境。客户端依赖清单 requirements.txt 也印证了整条流水线的技术构成tritonclient[all]2.65.0与 Triton 服务端通信的 gRPC/HTTP 客户端从 NVIDIA PyPI 源安装、opencv-python与pillow图像读写、supervision与trackpy目标检测标注与目标跟踪、google-cloud-bigquery/google-cloud-storage/pandas-gbq结果写回 GCS 与 BigQuery、ffmpeg-python视频处理、以及cupy-cuda12x、cuml-cu12等 CUDA 12 生态的 GPU 加速库。启动 Triton 推理服务端在 VM 的 SSH-in-browser 窗口或边缘设备终端中打开server目录并启动 Triton 服务端cd models/official/projects/waste_identification_ml/Deploy/detr_cloud_deployment/server/ bash triton_inference_server.sh服务端会在后台的screen会话中持续运行。可以按以下步骤确认服务状态列出screen会话screen -ls输出中会显示(Detached)状态因为你当前不在该会话内。进入服务端的 screen 会话screen -r server会话打开后会显示服务端的持续运行日志模型部署成功后会显示READY状态表示可以接收推理请求。若想在不关闭服务端的情况下离开会话按Ctrl a然后按ddetach 脱离会话。服务端脚本源码解析模型如何被装入 Tritontriton_inference_server.sh 的注释说明其职责是“自动化 PyTorch ONNX 模型在 NVIDIA Triton Inference Server 上的部署清理旧环境、下载并整理模型、创建必需配置、确保 screen 已安装并以 GPU 支持在分离会话中启动 Triton”。具体逻辑如下清理若model_repository目录已存在则先删除保证每次启动都是干净状态模型下载脚本用一个 Bash 关联数组定义模型名与下载地址当前只有一个条目CircularNet_Segmentation_Model_v1指向 TensorFlow Model Garden 官方 GCS 公共存储桶tf_model_garden桶下waste_identification_ml/CN-ModelCheckpoints/CN-TritonInferenceServer/路径中的CircularNet_model_v2.zip随后对每个条目执行wget下载、unzip解压并删除压缩包解压产物即构成 Triton 的model_repository依赖兜底检测screen命令缺失时自动sudo apt update sudo apt install -y screen启动容器脚本最后几行核心调用链screen -dmS server bash -c sudo docker run --gpus all --rm -p 8000:8000 -p 8001:8001 -p 8002:8002 \ -v ${PWD}/model_repository:/models nvcr.io/nvidia/tritonserver:25.05-py3 tritonserver --model-repository/models即通过screen -dmS server创建一个名为server的后台会话在其中运行nvcr.io/nvidia/tritonserver:25.05-py3官方镜像--gpus all启用全部 GPU对应 T4 或 Jetson 上的 GPU 直通挂载本地model_repository到容器内/models并映射三个标准端口——8000推理端口、8001管理/健康检查端口、8002指标监控端口。这也解释了为什么 before-you-begin 要求在防火墙中放行 HTTP 流量。需要注意一个文档与仓库文件名的细微差异部署文档的克隆章节中曾以triton_server.sh指代该脚本而仓库中实际文件名为 triton_inference_server.sh与“启动服务端”章节给出的命令一致以仓库实际文件名执行即可。运行推理客户端流水线服务端就绪后按 start-client.md 启动客户端cd models/official/projects/waste_identification_ml/Deploy/detr_cloud_deployment/client/ vim run_images.shrun_images.sh 是一个带完整参数文档的流水线入口脚本它先激活myenv虚拟环境并校验VIRTUAL_ENV是否生效失败即退出随后调用inference_pipeline.py并传入全部推理参数。每个参数都带有文档注释最少需要修改的四个参数为--input_directory存放待推理图像的 GCS 输入桶路径例如gs://bucket/input-images--output_directory写入带预测结果的图像的 GCS 输出桶路径--project_id承载这些 GCS 桶的 Google Cloud 项目 ID例如my-gcp-project--bq_table_id存放推理结果的 BigQuery 表 ID例如circularnet_table若该表已存在流水线会依据--overwrite参数决定覆盖或追加结果。脚本头部注释中还定义了完整的参数集结合 run_images.sh 当前文件中的示例取值各参数含义与默认示例如下参数含义脚本中的示例值--input_directory存放输入图像的 GCS 目录gs://recykal/TestData/SmallTestData--output_directory推理输出带叠加预测的图像写入的 GCS 目录gs://recykal/TestData/SmallTestData--model_name下载并用于推理的模型名cn_segmentation_trt_model--threshold检测置信度阈值0.50--search_range_x目标跟踪中允许在 X 方向的最大像素移动量跨丢失帧150--search_range_y目标跟踪中允许在 Y 方向的最大像素移动量跨丢失帧20--memory目标可被漏检多少帧仍保持被跟踪3--project_idBigQuery 操作所用的 Google Cloud 项目 IDwaste-identification-ml-330916--bq_dataset_id存放结果的 BigQuery 数据集 IDcircularnet_dataset--bq_table_id存放结果的 BigQuery 表 IDtest_table1--overwrite设为 True 时覆盖已存在的 BigQuery 表True其中search_range_x/search_range_y/memory三个参数对应客户端目录中的目标跟踪实现object_tracking.py附有配套测试 object_tracking_test.py当目标在个别帧中丢失时跟踪器在指定像素范围内搜索、并在memory帧的记忆窗口内维持其 ID这对后续逐帧统计很有意义。修改完成后按Esc输入:wq并回车保存退出。若尚未创建 GCS 输入/输出桶并上传图片请先参考仓库文档中云端预测流水线章节中创建 Cloud Storage 输入输出桶的说明。随后进入或创建推理客户端的 screen 会话并运行流水线screen -R inference bash run_images.sh同样地按Ctrl a然后d可脱离会话而不停止推理。脚本还会在client目录下创建logs文件夹保存带排障结果与模型运行记录的日志。流水线代码结构与输出验证从client目录的源码结构看整条推理流水线由若干可独立测试的模块组成inference_pipeline.py命令行入口解析上述参数并编排整个流程triton_server_inference.py封装对 Triton 服务端的推理请求对应测试 triton_server_inference_test.pyobject_tracking.py跨帧目标跟踪由--search_range_x/--search_range_y/--memory参数控制color_extraction.py对检测结果做颜色特征提取big_query_ops.pyBigQuery 表的建表/写入操作含 big_query_ops_test.py 测试labels50.csv50 类垃圾类别标签表用于将模型输出映射为可读类别。流水线运行完成后可以验证两类产出输出桶中的图像每张图片叠加了模型的对象预测结果BigQuery 表打开该表可查看全部图像的汇总统计在项目内的 BigQuery 中定位对应表并预览数据即可。重要注意事项若对同一批图像重跑预测流水线应删除输出桶中之前的图像结果同时可利用 Cloud Storage 的生命周期管理策略控制图像存储成本。适用前提与限制云端路径假设使用NVIDIA T4的 GPU 云 VM镜像为预装 CUDA 11.3 的 Deep Learning on LinuxDebian 11 / Python 3.10服务端脚本固定使用nvcr.io/nvidia/tritonserver:25.05-py3镜像客户端 CUDA 相关依赖如cupy-cuda12x、cuml-cu12面向 CUDA 12 生态实际部署时需保证设备驱动与镜像版本匹配边缘路径假设使用NVIDIA Jetson类设备且已完成开发者套件配置设备需联网以安装 Docker 与 Python 依赖客户端流水线依赖 GCP 项目已启用 BigQuery 与 Cloud Storage API且 VM 服务账户具备相应读写权限因此 BigQuery 结果写入部分与 Google Cloud 强绑定仓库中另有一套功能更丰富的部署代码 Triton_TF_Cloud_Deployment客户端额外包含ffmpeg_ops.py、mask_bbox_saver.py等视频/掩码处理模块从目录结构看可视为同一 Triton 部署方案的不同版本实现本文以Deploy/detr_cloud_deployment为准与本教程文档一一对应整体部署仍需具备基础设施管理能力创建 VM、配置防火墙与 IAM 权限、管理 Docker 与 screen 会话等操作均由使用者自行完成教程本身不自动执行任何云资源创建。延伸阅读项目总览waste_identification_ml README部署文档章节入口deploy-cn/_index.md云端数据准备与流水线说明prediction-pipeline-in-cloud.md【免费下载链接】modelsModels and examples built with TensorFlow项目地址: https://gitcode.com/GitHub_Trending/mode/models创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CircularNet 部署指南：基于 Triton Inference Server 在 Google Cloud（T4）与 Jetson 边缘设备上构建垃圾图像推理服务
CircularNet 部署指南基于 Triton Inference Server 在 Google CloudT4与 Jetson 边缘设备上构建垃圾图像推理服务【免费下载链接】modelsModels and examples built with TensorFlow项目地址: https://gitcode.com/GitHub_Trending/mode/models本文围绕 CircularNetTensorFlow Model Garden 中waste_identification_ml项目提供的垃圾识别模型的部署教程展开如何为 CircularNet 创建一个基于 NVIDIA Triton Inference Server 的推理服务覆盖 Google Cloud 上挂载 NVIDIA T4 GPU 的云 VM 与 NVIDIA Jetson 边缘设备两条路径并完整拆解从克隆仓库、环境安装、启动 Triton 服务到运行推理客户端流水线的每一步操作同时结合仓库中Deploy/detr_cloud_deployment下的真实脚本源码说明各参数的作用与底层实现帮助读者独立完成 CircularNet 的端到端部署与验证。CircularNet 部署方式概述CircularNet 可以部署在任意云服务商或推荐的边缘设备上但官方部署教程聚焦于一条经过验证的路径创建并运行一个部署在 Google Cloud 或 NVIDIA 设备上的 Triton Inference Server。该服务的设计目标是高效地处理图片或视频输入——将输入拆分为逐帧图像并对每一帧执行模型预测。教程针对两类硬件给出说明部署目标硬件适用场景Google Cloud 云 VMNVIDIA T4 GPU 计算单元云端批量图像/视频推理边缘设备NVIDIA Jetson如 Jetson Orin本地/现场实时推理教程同时明确了一个前提部署 CircularNet 模型需要具备管理基础设施、执行命令、以及在云端或边缘设备上配置连接与权限的技术能力即读者应熟悉 Linux 命令行、Docker 与云平台基础操作。完整的分步文档位于教程章节circularnet-docs/content/deploy-cn/下部署须知、克隆仓库、启动服务端、启动客户端对应的部署代码位于 Deploy/detr_cloud_deployment 目录。部署前准备准备 Google Cloud VM 或 Jetson 设备Google Cloud 路径创建挂载 T4 GPU 的 VM按 before-you-begin.md 的说明Google Cloud 路径需要准备如下创建 Google Cloud 账号与项目并设置计费账户在项目中启用三个 APICompute Engine API、BigQuery API、Cloud Storage API推理结果需要写入 BigQuery 表、图像存储在 Cloud Storage因此这三个 API 缺一不可创建一台挂载 NVIDIA T4 GPU 的 Compute Engine 虚拟机关键配置如下机型n1-standard-88 vCPU30 GB 内存GPU 类型 NVIDIA T4数量 1操作系统选择 Deep Learning on Linux 镜像版本为预装 CUDA 11.3 的 Deep Learning VMDebian 11Python 3.10启动盘Balanced persistent disk容量 300 GB用于存放模型仓库与依赖身份与 API 访问使用 Compute Engine 默认服务账户访问范围选择允许完全访问所有 Cloud API后续客户端流水线需要读写 GCS 与 BigQuery防火墙允许 HTTP 与 HTTPS 流量Triton 推理端口建议为 VM 起一个易记的名字并部署在支持 GPU、且靠近你物理位置可用区的区域。在 Google Cloud 控制台的Compute Engine VM instances页面找到该实例点击SSH使用 SSH-in-browser 工具连接。若 SSH 连接失败需为 VM 创建防火墙规则放行 TCP 入站流量IAP TCP 转发场景放行 TCP 端口22,3389。NVIDIA Jetson 边缘设备路径边缘设备路径的准备相对精简获取边缘设备、完成配置并连接至本地机器确保设备有互联网连接部署过程需要安装软件包按照设备的官方开发者指南完成系统设置、安装所需软件与依赖、准备对应的开发工具包以 Jetson 为例即其 Developer Guide打开设备终端通过命令行与操作系统交互——后续所有部署命令都在这个终端中执行。克隆仓库并安装依赖环境满足上述前置条件后在 Google Cloud VM 的 SSH-in-browser 窗口或边缘设备终端中按 clone-repo.md 依次执行安装 Gitsudo apt-get install git克隆包含 CircularNetwaste_identification_ml的 TensorFlow Model Garden 仓库git clone --depth 1 https://gitcode.com/GitHub_Trending/mode/models.git浅克隆--depth 1只拉取最新提交可显著减少下载体积克隆得到的目录名为models这也是后续所有相对路径的起点。进入waste_identification_ml项目中的client目录cd models/official/projects/waste_identification_ml/Deploy/detr_cloud_deployment/client/运行 requirements.sh 安装所有必需的包和库sh requirements.sh返回上一级目录cd\。requirements.sh 实际做了什么从源码看requirements.sh 并非简单的pip install它完成了完整的环境自举强制以/bin/bash执行脚本执行sudo apt-get update后检查 Docker 是否存在若未安装则通过官方安装脚本自动安装 Docker边缘设备上这一步尤其关键因为 Triton 服务端以 Docker 容器方式运行安装python3-venv与python3-pip用python3.10 -m venv myenv创建名为myenv的虚拟环境并激活执行pip install -r requirements.txt安装 ML 依赖若当前目录下不存在models目录会再次执行浅克隆这是一个幂等保护确保后续cd models/...的相对路径一定有效最后退出虚拟环境。客户端依赖清单 requirements.txt 也印证了整条流水线的技术构成tritonclient[all]2.65.0与 Triton 服务端通信的 gRPC/HTTP 客户端从 NVIDIA PyPI 源安装、opencv-python与pillow图像读写、supervision与trackpy目标检测标注与目标跟踪、google-cloud-bigquery/google-cloud-storage/pandas-gbq结果写回 GCS 与 BigQuery、ffmpeg-python视频处理、以及cupy-cuda12x、cuml-cu12等 CUDA 12 生态的 GPU 加速库。启动 Triton 推理服务端在 VM 的 SSH-in-browser 窗口或边缘设备终端中打开server目录并启动 Triton 服务端cd models/official/projects/waste_identification_ml/Deploy/detr_cloud_deployment/server/ bash triton_inference_server.sh服务端会在后台的screen会话中持续运行。可以按以下步骤确认服务状态列出screen会话screen -ls输出中会显示(Detached)状态因为你当前不在该会话内。进入服务端的 screen 会话screen -r server会话打开后会显示服务端的持续运行日志模型部署成功后会显示READY状态表示可以接收推理请求。若想在不关闭服务端的情况下离开会话按Ctrl a然后按ddetach 脱离会话。服务端脚本源码解析模型如何被装入 Tritontriton_inference_server.sh 的注释说明其职责是“自动化 PyTorch ONNX 模型在 NVIDIA Triton Inference Server 上的部署清理旧环境、下载并整理模型、创建必需配置、确保 screen 已安装并以 GPU 支持在分离会话中启动 Triton”。具体逻辑如下清理若model_repository目录已存在则先删除保证每次启动都是干净状态模型下载脚本用一个 Bash 关联数组定义模型名与下载地址当前只有一个条目CircularNet_Segmentation_Model_v1指向 TensorFlow Model Garden 官方 GCS 公共存储桶tf_model_garden桶下waste_identification_ml/CN-ModelCheckpoints/CN-TritonInferenceServer/路径中的CircularNet_model_v2.zip随后对每个条目执行wget下载、unzip解压并删除压缩包解压产物即构成 Triton 的model_repository依赖兜底检测screen命令缺失时自动sudo apt update sudo apt install -y screen启动容器脚本最后几行核心调用链screen -dmS server bash -c sudo docker run --gpus all --rm -p 8000:8000 -p 8001:8001 -p 8002:8002 \ -v ${PWD}/model_repository:/models nvcr.io/nvidia/tritonserver:25.05-py3 tritonserver --model-repository/models即通过screen -dmS server创建一个名为server的后台会话在其中运行nvcr.io/nvidia/tritonserver:25.05-py3官方镜像--gpus all启用全部 GPU对应 T4 或 Jetson 上的 GPU 直通挂载本地model_repository到容器内/models并映射三个标准端口——8000推理端口、8001管理/健康检查端口、8002指标监控端口。这也解释了为什么 before-you-begin 要求在防火墙中放行 HTTP 流量。需要注意一个文档与仓库文件名的细微差异部署文档的克隆章节中曾以triton_server.sh指代该脚本而仓库中实际文件名为 triton_inference_server.sh与“启动服务端”章节给出的命令一致以仓库实际文件名执行即可。运行推理客户端流水线服务端就绪后按 start-client.md 启动客户端cd models/official/projects/waste_identification_ml/Deploy/detr_cloud_deployment/client/ vim run_images.shrun_images.sh 是一个带完整参数文档的流水线入口脚本它先激活myenv虚拟环境并校验VIRTUAL_ENV是否生效失败即退出随后调用inference_pipeline.py并传入全部推理参数。每个参数都带有文档注释最少需要修改的四个参数为--input_directory存放待推理图像的 GCS 输入桶路径例如gs://bucket/input-images--output_directory写入带预测结果的图像的 GCS 输出桶路径--project_id承载这些 GCS 桶的 Google Cloud 项目 ID例如my-gcp-project--bq_table_id存放推理结果的 BigQuery 表 ID例如circularnet_table若该表已存在流水线会依据--overwrite参数决定覆盖或追加结果。脚本头部注释中还定义了完整的参数集结合 run_images.sh 当前文件中的示例取值各参数含义与默认示例如下参数含义脚本中的示例值--input_directory存放输入图像的 GCS 目录gs://recykal/TestData/SmallTestData--output_directory推理输出带叠加预测的图像写入的 GCS 目录gs://recykal/TestData/SmallTestData--model_name下载并用于推理的模型名cn_segmentation_trt_model--threshold检测置信度阈值0.50--search_range_x目标跟踪中允许在 X 方向的最大像素移动量跨丢失帧150--search_range_y目标跟踪中允许在 Y 方向的最大像素移动量跨丢失帧20--memory目标可被漏检多少帧仍保持被跟踪3--project_idBigQuery 操作所用的 Google Cloud 项目 IDwaste-identification-ml-330916--bq_dataset_id存放结果的 BigQuery 数据集 IDcircularnet_dataset--bq_table_id存放结果的 BigQuery 表 IDtest_table1--overwrite设为 True 时覆盖已存在的 BigQuery 表True其中search_range_x/search_range_y/memory三个参数对应客户端目录中的目标跟踪实现object_tracking.py附有配套测试 object_tracking_test.py当目标在个别帧中丢失时跟踪器在指定像素范围内搜索、并在memory帧的记忆窗口内维持其 ID这对后续逐帧统计很有意义。修改完成后按Esc输入:wq并回车保存退出。若尚未创建 GCS 输入/输出桶并上传图片请先参考仓库文档中云端预测流水线章节中创建 Cloud Storage 输入输出桶的说明。随后进入或创建推理客户端的 screen 会话并运行流水线screen -R inference bash run_images.sh同样地按Ctrl a然后d可脱离会话而不停止推理。脚本还会在client目录下创建logs文件夹保存带排障结果与模型运行记录的日志。流水线代码结构与输出验证从client目录的源码结构看整条推理流水线由若干可独立测试的模块组成inference_pipeline.py命令行入口解析上述参数并编排整个流程triton_server_inference.py封装对 Triton 服务端的推理请求对应测试 triton_server_inference_test.pyobject_tracking.py跨帧目标跟踪由--search_range_x/--search_range_y/--memory参数控制color_extraction.py对检测结果做颜色特征提取big_query_ops.pyBigQuery 表的建表/写入操作含 big_query_ops_test.py 测试labels50.csv50 类垃圾类别标签表用于将模型输出映射为可读类别。流水线运行完成后可以验证两类产出输出桶中的图像每张图片叠加了模型的对象预测结果BigQuery 表打开该表可查看全部图像的汇总统计在项目内的 BigQuery 中定位对应表并预览数据即可。重要注意事项若对同一批图像重跑预测流水线应删除输出桶中之前的图像结果同时可利用 Cloud Storage 的生命周期管理策略控制图像存储成本。适用前提与限制云端路径假设使用NVIDIA T4的 GPU 云 VM镜像为预装 CUDA 11.3 的 Deep Learning on LinuxDebian 11 / Python 3.10服务端脚本固定使用nvcr.io/nvidia/tritonserver:25.05-py3镜像客户端 CUDA 相关依赖如cupy-cuda12x、cuml-cu12面向 CUDA 12 生态实际部署时需保证设备驱动与镜像版本匹配边缘路径假设使用NVIDIA Jetson类设备且已完成开发者套件配置设备需联网以安装 Docker 与 Python 依赖客户端流水线依赖 GCP 项目已启用 BigQuery 与 Cloud Storage API且 VM 服务账户具备相应读写权限因此 BigQuery 结果写入部分与 Google Cloud 强绑定仓库中另有一套功能更丰富的部署代码 Triton_TF_Cloud_Deployment客户端额外包含ffmpeg_ops.py、mask_bbox_saver.py等视频/掩码处理模块从目录结构看可视为同一 Triton 部署方案的不同版本实现本文以Deploy/detr_cloud_deployment为准与本教程文档一一对应整体部署仍需具备基础设施管理能力创建 VM、配置防火墙与 IAM 权限、管理 Docker 与 screen 会话等操作均由使用者自行完成教程本身不自动执行任何云资源创建。延伸阅读项目总览waste_identification_ml README部署文档章节入口deploy-cn/_index.md云端数据准备与流水线说明prediction-pipeline-in-cloud.md【免费下载链接】modelsModels and examples built with TensorFlow项目地址: https://gitcode.com/GitHub_Trending/mode/models创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考