企业官网建设流程全解析

1. 项目概述：当智能监控遇见边缘计算

最近在折腾家里的智能安防系统，发现了一个挺有意思的组合：把 Frigate 这个开源的、主打本地 AI 对象检测的 NVR（网络视频录像机）软件，部署到 reComputer 这类基于 NVIDIA Jetson 平台的边缘计算设备上。这可不是简单的“把软件装到硬件上”，而是一次典型的边缘计算应用实践。简单来说，它解决了一个核心痛点：如何在不依赖云端、不占用大量家庭网络带宽、且能保证低延迟和高隐私性的前提下，实现 7x24 小时、高准确度的智能视频分析。

Frigate 本身是个明星项目，它利用 Google Coral TPU 或 CPU 上的 TensorFlow 来实时分析摄像头视频流，识别出人、车、宠物等对象，并触发 Home Assistant 等智能家居平台的自动化。而 reComputer 是 NVIDIA Jetson 系列（如 Jetson Nano, Xavier NX, Orin NX 等）的官方开发者套件或合作伙伴产品，其核心是一块集成了强大 GPU（含专用 AI 加速器）的嵌入式系统模块（SoM）。将 Frigate 部署到 Jetson 上，意味着你可以直接利用 Jetson 内置的 NVIDIA GPU 进行 AI 推理，省去了额外购买 Coral TPU 的成本，并且能获得更灵活的算力配置。

这个方案特别适合哪些场景呢？首先是注重隐私的家庭用户，所有视频分析都在本地设备完成，数据不出家门。其次是中小型商铺或办公室的安防升级，无需部署复杂的服务器。再者是物联网开发者，可以将其作为一个高性能的边缘 AI 节点来构建更复杂的应用。如果你已经有一台 Jetson 设备在吃灰，或者正打算构建一个本地化的智能监控系统，那么这次部署会是一个极具性价比和实用性的选择。整个过程涉及 Linux 系统操作、Docker 容器化部署以及一些特定的硬件加速配置，我会把每一步的细节、踩过的坑和优化技巧都捋清楚。

2. 整体方案设计与核心思路拆解

2.1 为什么选择 Jetson + Frigate 组合？

在决定部署之前，我们需要理清这个技术栈的优势和挑战。传统的 Frigate 部署大多在 x86 平台配合 Coral USB TPU，其优势是生态成熟、文档丰富。而转向 ARM 架构的 Jetson 平台，主要基于以下几点考量：

核心优势：

1. 一体化边缘算力：Jetson 模块集成了 CPU、GPU、内存和存储，功耗低、体积小。其 GPU 内置的 Tensor Cores（针对 Orin 等新款）或 NVIDIA AI 加速器，为运行 Frigate 所需的 YOLO 等目标检测模型提供了强大的本地算力，无需额外加速卡。
2. 成本与能效：对于已经拥有 Jetson 设备的开发者，这是盘活闲置资源的好方法。即使新购，一台 Jetson Orin Nano 的算力足以轻松处理多路 1080p 视频流的实时分析，其长期运行的功耗和散热远低于一台同等算力的 x86 小主机。
3. 架构一致性：Frigate 本身采用 Docker 容器化部署，这与 Jetson 上主流的应用部署方式（如使用 NVIDIA 的jetson-containers项目）完美契合，保证了环境的一致性和可移植性。

需要面对的挑战：

1. ARM 架构适配：Frigate 的官方 Docker 镜像主要面向 x86_64 和 Coral TPU。在 ARM64 的 Jetson 上，我们需要为其准备能在 NVIDIA GPU 上运行的 AI 推理后端，通常是 TensorRT。
2. 模型转换与优化：Frigate 默认使用 TensorFlow Lite 模型。为了在 Jetson GPU 上获得最佳性能，我们需要将模型转换为 TensorRT 引擎格式（.plan或.engine文件），这个过程需要一些额外的步骤。
3. 硬件编码/解码：为了降低 CPU 负载，必须充分利用 Jetson 的硬件视频编解码器（NVENC/NVDEC）来处理摄像头的视频流。Frigate 需要通过正确的配置来调用这些硬件能力。

方案选型思路：经过社区实践，目前相对稳定的路径是：在 Jetson 上安装标准的 Docker 和 Docker Compose，然后使用一个集成了 TensorRT 支持的特殊版本 Frigate 镜像，或者通过一些配置让官方镜像在 Jetson 上运行起来。我们将采用一种经过验证的方法，即使用一个社区维护的、针对 Jetson 和 TensorRT 优化过的 Frigate 分支或镜像。这避免了从零开始交叉编译的复杂性。

2.2 硬件与软件环境准备

工欲善其事，必先利其器。在开始之前，请确保你的环境符合以下要求：

硬件清单：

• reComputer / NVIDIA Jetson 设备：如 Jetson Nano（4GB）、Jetson Xavier NX、Jetson Orin Nano/NX 等。性能越强，能同时处理的路数越多。以 Jetson Orin Nano（8GB）为例，处理 3-4 路 1080p@15fps 的流进行 AI 检测是相对轻松的。
• 存储：推荐使用高速的 MicroSD 卡（A2 级别）或 NVMe SSD（如果设备支持）。视频录制和对象检测会产生大量 IO，低速存储会成为瓶颈。至少准备 64GB 以上容量。
• 网络：设备需通过有线网络连接到路由器，保证稳定的带宽。用于接入的摄像头建议支持主流编码格式（如 H.264/H.265）和 RTSP/RTMP 流。
• 摄像头：至少一个用于测试的网络摄像头（IP Camera）。确保你知道它的 RTSP 流地址，格式通常如rtsp://username:password@camera_ip:554/stream1。

软件基础：

• Jetson 系统：设备需已安装好 NVIDIA JetPack SDK。这是包含 Ubuntu 系统、CUDA、cuDNN、TensorRT 等核心驱动和库的软件栈。通过命令sudo apt-cache show nvidia-jetpack可以查看已安装版本。建议使用较新的 JetPack 5.x/6.x 版本以获得更好的 TensorRT 支持。
• Docker 与 Docker Compose：这是部署 Frigate 的容器运行时。Jetson 上的 Docker 安装略有不同，需要安装 NVIDIA 维护的版本以支持 GPU 透传。

注意：在 Jetson 上，切勿直接使用apt install docker.io，这可能导致与 NVIDIA 容器工具链的兼容性问题。必须按照 NVIDIA 官方文档安装适用于 ARM64 的 Docker 版本。

3. 核心环境配置与依赖安装

3.1 配置 Jetson 系统与安装 Docker

首先，登录到你的 Jetson 设备。假设你使用的是 JetPack 5.1 或更新版本，系统基于 Ubuntu 20.04/22.04。

步骤 1：系统更新与基础工具

sudo apt update sudo apt upgrade -y sudo apt install -y curl wget gnupg2 software-properties-common

步骤 2：安装 NVIDIA Container Toolkit这是让 Docker 容器能够使用 Jetson GPU 的关键。

# 添加 NVIDIA 容器工具包仓库 distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit

步骤 3：安装 Docker Engine这里我们使用 Docker 官方提供的安装脚本，它能够正确识别 ARM64 架构。

# 卸载可能存在的旧版本 sudo apt remove -y docker docker-engine docker.io containerd runc # 安装 Docker 官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 添加 Docker APT 仓库 echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

步骤 4：配置 Docker 使用 NVIDIA 运行时告诉 Docker 默认使用nvidia-container-runtime来运行容器，这样容器内才能访问 GPU。

sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker

步骤 5：验证安装运行一个测试容器，检查 GPU 是否在容器内可见。

sudo docker run --rm --runtime=nvidia --gpus all nvidia/cuda:11.8.0-base-ubuntu20.04 nvidia-smi

如果看到与在宿主机上运行nvidia-smi类似的 GPU 信息输出，说明 Docker 和 GPU 透传配置成功。

3.2 获取适用于 Jetson 的 Frigate 镜像

官方 Frigate 镜像 (blakeblackshear/frigate:stable) 不包含 TensorRT 支持，也无法在 ARM64 上直接运行。我们需要寻找替代方案。社区中有一些热心开发者维护了针对 Jetson 的版本。

一个比较流行的选择是使用ghcr.io/username/frigate:jetson这类镜像。但为了确保稳定性和可复现性，我推荐以下两种方法：

方法 A：使用社区构建的镜像（快速上手）可以在 Docker Hub 或 GitHub Container Registry 上搜索frigate jetson或frigate tensorrt标签。例如，我曾成功使用过某个社区镜像。在部署时，你需要在docker-compose.yml中指定这个镜像名。

方法 B：自行构建镜像（更可控，推荐）如果你想获得最新版本的 Frigate，或者希望对构建过程有完全的控制，可以基于 Frigate 的源代码和 NVIDIA 的 TensorRT 基础镜像自行构建。这需要一些时间，但能确保兼容性。

这里简述一下自行构建的思路：

1. 准备一个 Dockerfile，基于nvcr.io/nvidia/tensorrt:xx.xx-py3镜像（选择与 JetPack 中 TensorRT 版本兼容的标签）。
2. 在其中安装 Frigate 的 Python 依赖。
3. 克隆 Frigate 源码，并安装其 Python 包。
4. 关键一步：替换或修改 Frigate 的检测后端。Frigate 默认使用detectors配置项。我们需要为其添加一个支持 TensorRT 的后端。这通常需要编写一个自定义的检测插件，或者使用社区已有的frigate-tensorrt插件项目。
5. 构建镜像并推送到你自己的仓库或直接在本地使用。

由于自行构建涉及较多细节，对于初次部署，我建议先使用方法 A 的现有镜像进行快速验证。待整个流程跑通后，再考虑深度定制。在接下来的配置中，我们将假设你已获得一个可用的镜像，例如ghcr.io/someuser/frigate-jetson:latest。

4. Frigate 配置详解与部署实操

4.1 准备 Frigate 配置文件与目录结构

Frigate 通过一个 YAML 配置文件来定义所有行为。我们先创建必要的工作目录和配置文件。

# 创建一个工作目录，所有相关文件都放在这里 mkdir -p ~/frigate cd ~/frigate # 创建配置文件和存储目录 mkdir -p config mkdir -p storage touch config/config.yml

接下来是核心环节：编写config/config.yml。以下是一个针对 Jetson 的基础配置示例，包含了一个摄像头和 TensorRT 检测器的配置。

mqtt: host: 192.168.1.xxx # 你的 MQTT 服务器地址，如果使用 Home Assistant 集成，通常是 HA 的 IP port: 1883 user: mqtt_user # 可选 password: mqtt_pass # 可选 detectors: tensorrt: type: jetson # 关键！指定使用 Jetson 检测器。具体类型取决于你使用的镜像或插件。 device: 0 # 指定 GPU 设备 ID，通常是 0 # 模型配置。需要指定一个与 TensorRT 兼容的模型文件。 # 你需要提前将模型（如 yolov7-tiny-416.trt 或 .plan）放到容器内可访问的路径。 model: path: /path/to/your/model.plan # 例如 /config/model/ssd_mobilenet_v2_coco.plan width: 300 height: 300 labelmap_path: /config/model/labelmap.txt # 模型对应的标签文件 cameras: front_door: # 摄像头名称，可自定义 ffmpeg: inputs: - path: rtsp://admin:password@192.168.1.100:554/Streaming/Channels/101 roles: - detect - record detect: width: 1280 # 检测区域的宽度，建议与视频流分辨率匹配或等比例缩小以提升性能 height: 720 # 检测区域的高度 fps: 5 # 检测帧率，并非视频流帧率。降低此值可大幅减少 GPU 负载。 record: enabled: true retain: days: 7 snapshots: enabled: true retain: default: 10 objects: track: - person - car - dog - cat filters: person: min_area: 5000 max_area: 100000 threshold: 0.8 # 可选：启用 Go2RTC 以提供 WebRTC 流，改善实时预览体验 go2rtc: streams: front_door: rtsp://admin:password@192.168.1.100:554/Streaming/Channels/101 # Jetson 性能优化相关配置 ffmpeg: hwaccel_args: -c:v h264_nvmpi # Jetson 上的硬件解码参数，不同 JetPack 版本可能不同

配置文件关键点解析：

1. detectors: 这是与标准 Frigate 配置最大的不同。我们不再配置cpu或coral，而是配置一个tensorrt或jetson类型的检测器。具体的类型名（jetson）需要根据你使用的镜像或插件来确定。
2. model: 你必须提供一个已转换为 TensorRT 格式的模型文件及其标签。你可以从 NVIDIA 官方模型库（如 TAO Toolkit 预训练模型）转换，或使用社区提供的适用于 Frigate 的转换脚本。这是一个前置难点。
3. ffmpeg.hwaccel_args: 对于 Jetson，硬件解码至关重要。h264_nvmpi或hevc_nvmpi是常见的 NVMPI（NVIDIA Multimedia Programming Interface）解码器，能有效利用 Jetson 的 NVDEC 硬件单元。如果这个参数不正确，CPU 占用率会飙升。
4. detect.fps: 这是最重要的性能调优参数。它控制 Frigate 从视频流中抽帧进行检测的频率。对于安防场景，5 FPS 的检测率通常已足够，这能将 GPU 负载降低到原来的 1/6（相对于 30 FPS 全帧检测）。

4.2 准备 TensorRT 模型文件

这是部署成功的关键一步。Frigate 默认期望的是 COCO 数据集格式的 SSD-MobileNet 或 YOLO 模型。你需要一个.plan或.engine文件。

获取模型的常见途径：

1. 使用社区预转换模型：在 Frigate 或 Jetson 相关的 GitHub 社区中，有时能找到热心网友分享的已转换好的 TensorRT 模型文件。这是最快捷的方式。
2. 自行转换：
   • 步骤 1：获取 ONNX 模型。可以从 Frigate 官方文档找到其使用的模型（如ssd_mobilenet_v2_coco），并找到其 ONNX 格式文件。
   • 步骤 2：在 Jetson 上使用 TensorRT 的trtexec工具进行转换。JetPack 通常自带此工具。

   # 示例转换命令（参数需根据模型调整） /usr/src/tensorrt/bin/trtexec --onnx=ssd_mobilenet_v2_coco.onnx \ --saveEngine=ssd_mobilenet_v2_coco.plan \ --workspace=1024 \ --fp16 # 如果 Jetson 支持 FP16，启用以提升性能

   • 步骤 3：准备标签文件。创建一个labelmap.txt，内容为 COCO 数据集的类别名称，每行一个，顺序与模型输出一致。通常可以从 Frigate 或 TensorFlow 模型仓库中找到。

将转换好的.plan模型文件和labelmap.txt标签文件放入~/frigate/config/model/目录下，并在配置文件中正确引用。

4.3 编写 Docker Compose 文件并启动

现在，我们创建docker-compose.yml来定义和运行 Frigate 容器。

version: '3.8' services: frigate: # 使用适用于 Jetson 的镜像，此处为示例，请替换为你实际使用的镜像 image: ghcr.io/your-username/frigate-jetson:latest container_name: frigate restart: unless-stopped shm_size: '128mb' # 共享内存大小，用于进程间通信，对于多摄像头可适当增加 devices: - /dev/bus/usb:/dev/bus/usb # 如果使用 USB 摄像头可能需要 - /dev/video0:/dev/video0 # 如果使用 CSI 摄像头可能需要 # 对于 GPU，我们通过 runtime 和 deploy 资源限制来暴露 deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu, utility, compute, video] volumes: - /etc/localtime:/etc/localtime:ro - ./config:/config:rw - ./storage:/media/frigate:rw # 可选：将模型目录单独挂载 - ./config/model:/config/model:ro ports: - "5000:5000" # Frigate Web UI - "8554:8554" # RTSP 流（如果启用 go2rtc） - "8555:8555/tcp" # WebRTC API - "8555:8555/udp" # WebRTC API environment: - FRIGATE_RTSP_PASSWORD=your_password # 设置 RTSP 流的密码 # 关键：使用 nvidia 运行时 runtime: nvidia networks: - frigate-net networks: frigate-net: driver: bridge

关键配置说明：

1. image: 务必替换为你能获取到的、真正能在 Jetson 上运行的 Frigate 镜像。
2. shm_size: 共享内存不足会导致 Frigate 出现“无法创建共享内存”的错误。对于多路摄像头，建议增加到256mb或512mb。
3. devices与runtime: 我们通过runtime: nvidia和deploy.resources来将整个 GPU 资源暴露给容器，这是推荐的方式。同时，挂载了视频设备节点以备使用本地摄像头。
4. volumes: 将本地的config和storage目录映射到容器内，确保配置和录制的视频数据持久化。
5. ports: 映射了 Frigate 的 Web 界面端口（5000）和可能的流媒体端口。

启动 Frigate：

cd ~/frigate sudo docker compose up -d

使用sudo docker compose logs -f frigate查看实时日志。如果一切顺利，你将看到 Frigate 启动，加载 TensorRT 模型，并开始从摄像头拉流。稍等片刻，即可通过浏览器访问http://你的Jetson设备IP:5000打开 Frigate 的 Web 界面。

5. 性能调优、问题排查与实战心得

5.1 Jetson 平台专属性能调优指南

部署成功只是第一步，要让 Frigate 在 Jetson 上流畅运行，必须进行精细调优。

1. 检测帧率 (detect.fps) 是黄金参数这是平衡检测精度和系统负载的最有效杠杆。对于门口、庭院等场景，物体移动相对缓慢，将fps设置为3-5足以捕捉到所有有效事件。每降低 1 FPS，GPU 的推理负载就线性下降。可以通过 Frigate UI 的“调试”视图查看实际检测帧率和推理耗时（inference_speed），目标是让推理耗时低于检测帧间隔（例如 5 FPS 对应 200ms）。如果推理耗时接近或超过帧间隔，就会掉帧，需要降低fps或换用更轻量的模型。

2. 视频流分辨率与编码

• 输入流分辨率：在摄像头配置中，detect下的width和height定义了用于检测的视频区域大小。不要盲目设置为摄像头原始分辨率（如 4K）。将其设置为 720p（1280x720）甚至 480p（640x480）可以极大减少需要处理的像素数量，从而提升推理速度。Frigate 会先将原始流缩放到这个分辨率再进行检测。
• 硬件解码：确保ffmpeg.hwaccel_args参数正确。对于 H.264 流，通常是-c:v h264_nvmpi；对于 H.265，则是-c:v hevc_nvmpi。可以通过在 Jetson 上运行ffmpeg -decoders | grep nvmpi来查看支持的硬件解码器。正确的硬件解码能将 CPU 占用从 50% 以上降到个位数。

3. 模型选择与优化

• 模型复杂度：在 Jetson Nano 上，可能只能流畅运行ssd-mobilenet-v1这类轻量模型。而在 Orin NX 上，则可以尝试yolov5s或yolov7-tiny以获得更好的精度。始终在精度和速度之间权衡。
• 精度与量化：TensorRT 支持 FP16 和 INT8 量化。在支持这些精度的 Jetson 设备上（如 Orin 系列），使用--fp16或--int8转换模型可以显著提升推理速度，同时精度损失在可接受范围内。INT8 量化需要校准数据集，过程更复杂，但提速效果最明显。

4. 系统级优化

• JetPack 电源模式：Jetson 设备有不同的电源模式（nvpmodel）。例如 Jetson Orin Nano 有 10W、15W、25W 等模式。更高的功率模式解锁更强的 CPU 和 GPU 性能。使用sudo nvpmodel -m <mode_id>设置。对于持续运行的 Frigate，建议设置为中高性能模式（如 15W），在性能和发热/功耗间取得平衡。
• 禁用图形桌面：如果你的 Jetson 只用作 Frigate 服务器，可以考虑禁用 Ubuntu 的图形桌面（使用sudo systemctl set-default multi-user.target并重启），以节省内存和 CPU 资源。

5.2 常见问题与排查实录

在部署和运行过程中，你几乎一定会遇到以下一些问题。这里是我的排查笔记：

问题 1：容器启动失败，日志显示Cannot connect to the Docker daemon或权限错误。

• 原因：Docker 服务未运行，或者当前用户不在docker组。
• 解决：

  sudo systemctl start docker # 启动服务 sudo systemctl enable docker # 设置开机自启 sudo usermod -aG docker $USER # 将当前用户加入 docker 组

  重要：执行usermod后，需要完全注销并重新登录，或者新开一个终端会话，组权限更改才会生效。

问题 2：Frigate 日志报错Failed to initialize detector或TensorRT engine file not found。

• 原因：配置文件中的detectors类型不正确，或者模型文件路径错误、格式不对。
• 排查：
  1. 确认config.yml中detectors部分配置的type与所用镜像支持的检测器名称完全一致（区分大小写）。
  2. 进入容器内部检查模型文件：

     sudo docker exec -it frigate bash ls -la /config/model/ # 确认模型文件存在

  3. 确认模型文件是为当前 JetPack 版本的 TensorRT 所转换。不同版本的 TensorRT 引擎可能不兼容。

问题 3：Web 界面能打开，但摄像头画面显示“不可用”或一直加载，日志中有 FFmpeg 错误。

• 原因：最常见的是视频流拉取失败或解码失败。
• 排查：
  1. 测试流地址：在 Jetson 宿主机上，用ffplay或vlc直接播放摄像头的 RTSP 地址，确认网络和认证无误。
  2. 检查硬件解码：查看 Frigate 日志中 FFmpeg 相关的错误。如果看到hwaccel相关的错误，尝试在config.yml中注释掉ffmpeg: hwaccel_args这一行，让 Frigate 使用软件解码。如果能成功，说明硬件解码参数不对。需要根据你的摄像头编码格式（H.264/H.265）和 JetPack 版本查找正确的nvmpi解码器参数。
  3. 降低码流：有些摄像头的高码率主码流可能给解码带来压力。尝试在摄像头配置中使用子码流（通常分辨率更低），路径可能类似.../Streaming/Channels/102。

问题 4：系统运行一段时间后卡顿，或 Frigate 进程崩溃。

• 原因：可能是内存耗尽、存储 IO 瓶颈或 GPU 过热降频。
• 排查：
  1. 监控资源：使用tegrastats命令（Jetson 专属）或htop、nvtop监控 CPU、GPU、内存和显存使用情况。
  2. 检查存储：如果开启了录制（record），视频会持续写入存储。使用iotop或df -h检查存储空间和 IO 延迟。确保使用高速 SD 卡或 SSD。
  3. 检查温度：运行sudo jetson_clocks --show查看温度。如果温度持续过高（如 >85°C），GPU 会降频。确保设备通风良好，必要时加装散热风扇。

问题 5：检测延迟高，事件触发慢。

• 原因：推理速度跟不上，或者detect.fps设置过高，导致队列积压。
• 解决：
  1. 首先，降低detect.fps到 3-5。
  2. 在 Frigate Web UI 的“系统”->“日志”中，查看detection_fps和process_fps。如果process_fps远低于detection_fps，说明检测环节是瓶颈。
  3. 考虑更换更轻量的 AI 模型。

5.3 进阶配置与扩展思路

当基础功能稳定后，可以考虑以下进阶玩法：

1. 多摄像头管理与区域划分在config.yml的cameras部分添加多个摄像头配置即可。Frigate 会自动为每个摄像头分配检测进程。你需要根据 Jetson 的算力来决定上限。可以为每个摄像头设置不同的detect.fps和检测区域（zones），例如对重点区域（如大门）设置更高的检测灵敏度。

2. 与 Home Assistant 深度集成这是 Frigate 的精华所在。在 Home Assistant 中安装 Frigate 集成后，可以实现：

• 实时通知：当检测到“人”时，向手机推送快照和视频片段。
• 自动化联动：检测到“车”时，自动打开车库灯；检测到“包裹”时，播放语音提示。
• 虚拟摄像头：将 Frigate 检测后的视频流（带 bounding box）作为一个虚拟摄像头接入 HA，用于仪表盘展示。

3. 使用更高效的模型格式：ONNX Runtime with TensorRT EP除了直接使用 TensorRT 引擎，另一种思路是让 Frigate 使用 ONNX Runtime 作为推理后端，并启用其 TensorRT Execution Provider (EP)。这样你可以直接使用 ONNX 模型文件，由 ONNX Runtime 在运行时自动调用 TensorRT 进行加速。这种方法可能更方便模型管理和更新。这需要对 Frigate 的检测器配置进行更深入的定制，通常需要修改自定义检测器代码。

4. 硬件加速视频编码（录制）除了解码，录制视频也可以硬件加速。在 Frigate 的record配置中，可以尝试设置编码参数：

record: enabled: true encoder: h264_nvmpi # 使用 Jetson 的硬件编码器

这可以大幅降低录制视频时的 CPU 占用。

将 Frigate 部署到 NVIDIA Jetson 上，是一个充满挑战但回报丰厚的项目。它迫使你去理解边缘 AI 的完整链条：从硬件驱动、容器化环境、模型转换，到最终的软件配置和性能调优。整个过程里，最深的体会是“平衡”二字——在有限的边缘算力下，平衡检测精度、响应速度、系统功耗和稳定性。每一次参数的调整，都是对应用场景的再思考。比如，你真的需要 10 FPS 的检测率来监控一个静态的停车场吗？或许 2 FPS 加上更准确的区域检测就能达到更好的效果。

最后分享一个小心得：务必做好日志管理。Frigate 的日志非常详细，是排查问题的第一手资料。建议在docker-compose.yml中配置日志轮转，避免日志文件撑满存储空间。同时，善用tegrastats这个 Jetson 神器，它能帮你建立起对设备资源状态的直观感知，让你从“凭感觉调参”进化到“看数据优化”。这个项目一旦跑顺，它就会成为一个安静而可靠的智能守护者，而你在这个过程中积累的边缘部署经验，其价值远不止于一套监控系统。