企业官网建设流程全解析

前阵子帮一个做智慧农业的朋友调试果园视觉分拣系统，他原本的方案是树莓派采集图像，通过 4G 上传到云服务器跑目标检测模型，再回传结果。现场实测出大问题：果园在山区，网络信号时好时坏，快的时候一路畅通，慢的时候一帧图像传上去就没下文了，整套系统最慢能到好几秒。后来我们把模型推到了边缘端，整个检测流程从图像采集到输出结果压缩到了 80 毫秒左右，断网也照常运行。这个转变让我对 Physical AI 有了更具体的理解——AI 模型要真正进入物理世界，延迟和断网就是两道绕不过去的坎。

这篇文章我准备把这次项目里用到的思路完整梳理一遍：为什么视觉模型必须往边缘推、边缘端模型怎么选、用什么推理框架落地、延迟优化有哪些工程手段、断网情况下系统怎么兜底。每一条都是实际跑过的路线，不是纯概念科普。

1. Physical AI 边缘化的真实原因：延迟和断网不是小问题

1.1 从云端到边缘，延迟积累在哪些环节

很多人一提到 AI 落地，第一反应就是把数据丢到云端，用最强的 GPU 去跑。这个思路在图片离线处理、训练任务上没问题，但放到 Physical AI 场景里就有问题了。Physical AI 的核心特征是模型要和物理世界实时交互，比如机械臂抓取、AGV 避障、质检流水线剔除、人脸识别门禁，这些场景的通病是响应时间窗口极短，而且网络环境远没有机房那么理想。

先算一笔延迟账。假设摄像头采集一帧 1080P 图像，H.264 编码后码率按 4Mbps 算，一帧图像压缩后的数据量大约在 50KB 到 100KB 之间。在普通的 4G 弱网环境下，上行带宽可能只有 1Mbps 到 5Mbps，也就是说上传一帧图像就要 100 到 400 毫秒。再加上基站调度、内网路由、云端负载均衡、GPU 排队、后端解码、模型推理、结果回传，全链路跑下来轻松超过 500 毫秒。这个延迟对静态安防监控来说还能忍，但对 AGV 来说早撞上了，对机械臂来说早就抓空了。

我之前测过一个云端人脸识别方案，本地采集到云端返回识别结果，平均延迟在 400 到 800 毫秒之间波动，高峰期甚至飙到 2 秒以上。而边缘端用 Jetson Orin Nano 跑一个轻量人脸识别模型，端到端延迟稳定在 60 到 100 毫秒。这不是模型性能的差距，纯粹是网络链路拖了后腿。

云端方案的第二个问题是网络抖动。物理世界的网络不是稳定的，尤其产线、农田、车载、室外巡检这些场景，信号遮挡、移动切换、带宽争抢都很常见。我用 ping 连续测过一个露天厂区的 4G 网络，延迟从 30 毫秒到 300 毫秒来回跳，丢包率最高到了 5%。这种网络环境下，想要保证毫秒级响应基本是痴人说梦。

1.2 断网场景下，云端视觉方案直接失效

比高延迟更致命的是断网。很多 Physical AI 的部署位置恰恰是网络条件最差的地方：温室大棚里金属骨架遮挡信号、地下车库没有基站覆盖、移动机器人穿行在桥洞下、无人机飞行在偏远区域。一旦断网，纯云端方案就等于瞎了——摄像头继续拍，图像传不出去，系统没有输出，后续的执行机构全部停摆。

有个做智能药房的朋友跟我讲过他们踩过的坑。他们最初做视觉发药复核，摄像头拍完药品包装后把图像发到云端比对，药房内网偶尔断个几十秒，他们只能眼巴巴等着，整个发药流程堵住。后来加了边缘缓存，断网时图像和推理结果先存在本地，网络恢复后自动补传，才算把这个问题解决。这个案例让我意识到，Physical AI 的边缘化不只是为了降低延迟，更是为了让系统在断网状态下还能保持基本功能。用行业术语说，这叫"本地自主性"。一个真正合格的 Physical AI 系统，必须能在脱离云端的情况下完成核心任务，云端只有在需要全局调度、模型更新、跨站点分析时才介入。

所以结论很清晰：对于实时性要求高、部署位置网络不稳定的 Physical AI 应用，模型上边缘不是可选优化项，而是必须做的架构决策。

2. 边缘端视觉模型选型：小参数模型的取舍逻辑

2.1 为什么说小参数模型是边缘部署的第一选择

确定了推边缘的方向，接下来最核心的问题就是——边缘端能跑多大的模型？市面上主流视觉任务，目标检测用 YOLO 系列，分割用 SegFormer、FastSAM，分类用 MobileNet、EfficientNet。这些模型的参数规模从几百万到几亿不等。边缘设备的算力天花板比云端低几个数量级，所以必须学会做减法。

我部署过的最典型的设备是 Jetson AGX Orin 和 Jetson Orin Nano。AGX Orin 的算力大约在 275 TOPS（INT8），看着很猛，但它的 GPU 核心要同时处理多条视频流、跑前后处理。Orin Nano 只有 40 TOPS，跑大模型就更吃力了。在实际项目中，我总结了一个大致的模型选型参考区间，按任务类型划分如下表：

这个表不是绝对的，主要给一个体感参考。参数越小、输入分辨率越低，延迟就越低，但精度也随之下降。关键是要找到符合业务精度要求的最小模型，而不是一上来就抄大模型的配置。

2.2 模型压缩的三种常用路径：量化、剪枝、蒸馏

选好基础模型只完成了第一步。边缘设备上跑模型，还要过一遍压缩的三板斧。

第一板斧是量化。把 FP32 的权重压到 FP16 或者 INT8，是边缘部署收益最大、成本最低的手段。以 YOLOv8n 为例，FP32 模型在 Orin Nano 上大约能跑到 20ms 左右一帧；换成 TensorRT 的 FP16 推理，大概能压到 12ms；再用 INT8 加上校准集，能跑到 7-8ms。INT8 对显存带宽的压力更小，功耗也更低。代价是精度会掉，掉多少取决于校准集的质量。我做校准的时候习惯从真实场景里抓 500 到 1000 张有代表性的图，覆盖白天、黑夜、不同角度、不同光照，而不是随便找 COCO 数据集切几张。校准集跑偏了，INT8 模型的精度会莫名其妙掉很多。

第二板斧是剪枝。边缘部署我用得相对少，因为剪枝对训练流程的要求较高，不是简单地把不重要的通道删掉就完事。常规做法是结构化剪枝，按 BN 层的缩放因子来判断通道重要性，把小于阈值的通道裁剪掉，然后做微调恢复精度。这个方法适合从头训练模型、或想彻底压榨性能的场景。但在大多数项目里，用 TensorRT 的自动优化加上量化已经足够了，剪枝作为备选方案即可。

第三板斧是蒸馏。用大模型做 teacher，小模型做 student，soft label 训练让小路模型逼近大模型精度。这个我在一个零件缺陷检测项目中试过，用 YOLOv8x 蒸馏 YOLOv8n，mAP 能提升大概 2-3 个百分点，效果还是挺明显的。蒸馏训练代码也不复杂，核心思想就是让 student 同时学习真实标签和 teacher 的输出分布。

简单总结：常规项目用"小模型 + 量化"就能满足要求；对精度有更高要求的，可以先做蒸馏再做 INT8 量化；确确实实模型太大，才考虑剪枝。

3. 边缘部署实战：Jetson 平台上的推理流程优化

3.1 环境搭建最容易忽略的版本对齐问题

选好模型和压缩手段，接下来是真正的部署环节。我用得最多的平台是 NVIDIA Jetson 系列，不只是因为算力强，更因为生态成熟——TensorRT、CUDA、JetPack 直接配套，社区资料多，踩坑能找到参考。

JetPack 版本对齐是我每次都要强调的点。很多人从网上扒了一段部署教程，发现跑不起来，十有八九是版本匹配出了问题。Jetson 的 JetPack、CUDA、cuDNN、TensorRT 是绑定的，比如 JetPack 5.x 对应 CUDA 11.4、TensorRT 8.5.x；JetPack 6.0 对应 CUDA 12.2、TensorRT 8.6 左右。如果你用 pip 装了最新的 onnxruntime-gpu，它要求的 CUDA 版本可能和 JetPack 自带的不一致，一跑就报库冲突。

我现在的固定操作流程是：先设置 apt 源，然后安装 JetPack 自带的 TensorRT、Python 的 pycuda、onnx 和 onnxruntime-gpu，全部用 apt 或 pip 安装指定版本，绝不随意升级。具体命令大致如下：

sudo apt update sudo apt install nvidia-jetpack sudo apt install python3-pip pip3 install onnx==1.14.0 onnxruntime-gpu==1.15.0 pycuda

注意 jetpack 版本不同，以上包的可用版本也不同，建议安装前查一下当前 JetPack 对应的官方版本表。版本对齐做完，后面省掉大量排查时间。

3.2 把 PyTorch 模型转成 TensorRT 引擎并跑起来

在 Jetson 上用 TensorRT 推理，简单说就两步：第一步把 PyTorch 模型转成 ONNX；第二步用 TensorRT 把 ONNX 转成 engine，然后在 GPU 上执行。中间的关键点是动态尺寸和精度设置。

我以手头一个 YOLOv8n 检测模型为例，ONNX 导出命令类似这样：

import torch from ultralytics import YOLO model = YOLO("yolov8n.pt") model.export(format="onnx", imgsz=640, dynamic=True, half=True, simplify=True)

导出后生成 yolov8n.onnx。接着用 Python 调用 TensorRT 的 trtexec 或 API 构建 engine：

/usr/src/tensorrt/bin/trtexec --onnx=yolov8n.onnx \ --saveEngine=yolov8n.engine \ --fp16 \ --minShapes=images:1x3x640x640 \ --optShapes=images:1x3x640x640 \ --maxShapes=images:16x3x640x640

跑完这一步，推理时直接用 engine 文件就行。运行时用 pycuda 管理显存，输入做标准化，输出解析后套 NMS。一个简化版的推理循环长这样：

import pycuda.autoinit import pycuda.driver as cuda import tensorrt as trt import numpy as np logger = trt.Logger(trt.Logger.WARNING) runtime = trt.Runtime(logger) with open("yolov8n.engine", "rb") as f: engine = runtime.deserialize_cuda_engine(f.read()) context = engine.create_execution_context() # 分配输入输出 buffer # 输入图像 resize + normalize # context.execute_v2(bindings) # 后处理：sigmoid + decode + NMS

实际部署时，我一般把模型推理封装成一个类，输入直接传摄像头帧，输出返回检测框列表。这样在业务层调用时，只需要关心帧进框出，不用管底层 CUDA、TensorRT 这些细节。

3.3 语言模型边缘推理：Jetson 上跑 llama.cpp 的轻量部署经验

除了视觉模型，Physical AI 场景里也有语言模型的需求，比如智能语音交互、设备运维问答、机器人指令理解。大语言模型动辄几十亿上百亿参数，在 Jetson 这类边缘设备上跑之前是不可想象的，但量化模型的流行让这件事变成了可能。

llama.cpp 是当前在边缘设备上跑大语言模型的事实标准，它通过 GGUF 格式将权重量化为 4-bit 或 5-bit，大幅降低显存占用，同时针对 CPU 和 GPU 混合推理做了优化。Jetson AGX Orin 的显存有 64GB，和 CPU 共享内存，跑一个 7B 到 13B 参数量、Q4_K_M 量化的模型完全可以。实测跑 7B 模型，吞吐大约在 10-15 tokens/s，对边缘设备来说已经足够交互使用。

llama.cpp 在 Jetson 上的关键步骤是启用 CUDA 加速编译。默认 Makefile 只用 CPU 编译，速度很慢。要加一行配置：

make LLAMA_CUDA=1 CUDA_PATH=/usr/local/cuda

跑起来之后，如果遇到显存不足，可以通过调整 context 长度、减少 batch size、关掉 GPU 层数来降低占用。很多开发者不知道，llama.cpp 支持将部分层放在 GPU、部分放在 CPU，可以通过--n-gpu-layers参数控制。仅放一小部分层在 GPU 上，也能显著加速 prompt 处理，同时避免中间激活值爆显存。

对于 Physical AI 的视觉语言融合，一般是用视觉模型做感知，把结果转成文本描述，再送给语言模型进行决策或回答。两个模型可以分别独立部署，不做底层融合，这个方案实现成本低，稳定性和可维护性反而更高。

4. 延迟抖动、数据去重与边缘注意力：三个容易被忽视的优化点

4.1 滑动窗口滤波器：让延迟从"忽高忽低"变成"稳定可预测"

把视觉模型推到边缘后，总体延迟确实从几百毫秒降到几十毫秒，但实际运行中还会有一个新问题：延迟抖动。边缘设备上 GPU 资源不是专门给某一个模型服务的，系统服务、编解码、多路视频流同时跑，每一帧的推理时间都在波动。上一帧 20ms，下一帧可能 40ms，再下一帧又 20ms。对分拣机械臂这类高节拍执行器来说，延迟抖动比平均延迟更致命，因为它会造成执行周期不稳定，机械结构都来不及消化。

解决抖动最直接的手段不是加钱上更好的 GPU，而是加一个滑动窗口滤波器。思路很简单：维护一个长度为 N 的历史延迟队列，每帧的实际处理时间进入队列，用中值或均值决定当前的响应节奏。我推荐用滑动窗口中值，因为它对脉冲式异常延迟抵抗能力强。举个具体例子，如果窗口长度为 5，历史延迟是 [18ms, 22ms, 35ms, 19ms, 21ms]，排序后中值是 21ms，控制器就按 21ms 这个周期调度。35ms 的尖刺被平滑掉，不会导致系统猛一顿。

窗口长度的选择有讲究。太短，平滑效果差；太长，系统对真实负载变化的响应变慢。我自己的经验是：低节拍应用（比如静态质检，每秒处理 2-5 帧）窗口设 10-20；高节拍应用（比如高速分拣，每秒 30 帧以上）窗口设 5-10 就够了。窗口更新要避免反复排序带来的 CPU 开销，实际实现时可以维护一个有序堆，或者直接用median_filter这种现成库。

import collections import statistics class DelaySmoother: def __init__(self, window_size=10): self.window = collections.deque(maxlen=window_size) def update(self, delay_ms): self.window.append(delay_ms) return statistics.median(self.window)

加了滑动窗口后，整个系统的延迟表现从一个波动值变成一个近似稳定的常数，控制逻辑好写多了。这是我强烈建议每一个做边缘部署的人都加上的基础组件。

4.2 边缘节点去重算法：减少无效计算和无效上云

第二个优化点是边缘节点的数据去重。很多摄像头固定角度拍摄，场景几十秒都不变，如果每一帧都盲目推理，大部分计算和网络传输都是浪费。边缘节点去重算法的核心目标是：判断当前帧和上一帧的信息差异，低于阈值就直接复用上一帧的推理结果，不做重复计算。

实现层面可以简单也可以复杂。最简单的做法是计算帧间差分均值：把当前帧和上一帧做像素差，求平均绝对值，如果小于阈值就判定为"无变化"。但这个方法对光照变化太敏感，傍晚时分树影晃一晃，帧差就大了，导致误判。更可靠的做法是结合感知哈希（perceptual hash）或特征点统计，或者用轻量背景建模算法（如 MOG2）来做变化检测。

在项目里我用过一个比帧差分稳的方案：先用缩放后的灰度图做感知哈希，直接比较两帧的汉明距离，距离小于某个阈值就跳过推理。示例逻辑如下：

def perceptual_hash(img_gray, size=8): # 缩放到 8x8，计算均值哈希 resized = cv2.resize(img_gray, (size, size)) avg = resized.mean() return (resized > avg).astype(np.uint8) def is_similar(hash1, hash2, threshold=5): return np.count_nonzero(hash1 != hash2) < threshold

这个方案对光照变化有一定鲁棒性，同时计算成本非常低，整个过程开销不到 1ms。在一套 8 路摄像头的边缘设备上，如果场景大部分时间静止，去重后 GPU 利用率能下降 40% 到 60%，系统吞吐余量一下子变大了。

去重策略跟业务必须绑定。对于流水线动态场景，物体是持续移动的，帧差永远大，去重阈值可以调高；而对于仓库监控这种静态场景，去重就非常有用。合理的设计应该是：去重策略做成可配置开关，参数能在 web 管理后台调整，而不是写死在代码里。

4.3 ega++ 与边缘引导注意力：用注意力机制把算力花在刀刃上

关于 ega++，这个术语来自 WACV 2024 的一篇论文，英文全称是 Edge-Guided Attention，是在边缘检测任务中引入注意力机制的一种做法。它的核心思路是让模型在训练和推理时更关注图像中真正的边缘区域，学习阶段把边缘信息作为一种引导信号，抑制背景噪声干扰。在边缘部署的语境下，这类注意力机制的价值在于它可以优化特征提取的针对性，从而让边缘端模型在相同参数量下获得更高的精度。

简单解释一下注意力机制在这个场景里的作用。标准的卷积网络对整张图像一视同仁地提取特征，包括大量无关的背景区域。边缘引导注意力模块会让网络生成一个注意力权重图，这个权重图评估每个像素位置上有用的概率，在特征加权阶段把靠前的响应集中在边缘和物体轮廓区域，等于把算力聚焦在真正影响结果的位置上。在同等计算预算下，模型能把更多表达能力用在刀刃上。

实际部署中我不推荐自己从头实现这个模块，因为在 Jetson 上用 TensorRT 转换自定义注意力算子可能踩不少算子不支持的坑。更务实的做法是选预训练模型时优先考虑带注意力机制的轻量骨干网络，比如 MobileNetV3 的 SE 模块、EfficientNet 的 SE 模块，或者是带 GAM 注意力机制的 YOLO 变体。如果你要做的任务刚好是边缘检测或车道线检测，可以直接去试带 effective 边缘引导头的预训练模型，这类模型在公开数据集上的精度表现都不错，转 TensorRT 的兼容性也比自己改原生的注意力算子好得多。

5. 断网场景的兜底设计：本地缓存与消息队列的工程化用法

5.1 断网时推理结果存在哪：轻量本地存储方案

边缘部署的第二道防线是断网。视觉模型在边缘端完成推理只是第一步，推理结果后续还要用于统计、追溯、训练数据回流。断网时这些结果不能丢，必须可靠地存在本地，等网络恢复后再同步上云。

本地存储选型，我试过几种方案。如果你只存结构化数据，比如检测框、类别、置信度、时间戳，首选 SQLite。它零配置、单文件、支持 SQL，天生适合嵌入式场景。数据量稍微大一点，或者有高并发需求，可以用 RocksDB 这种 KV 存储。如果你要同时存图像或视频片段，那就用文件系统加索引的方式：图像按日期/站点/摄像头 ID 分目录存好，把文件路径、检测结果、时间戳写进 SQLite。这样既保证查询方便，又避免把大文件塞进数据库拖慢性能。

一个比较完整但不过度的本地存储结构大致是这样：

/data/edge_store/ videos/2025/01/15/cam01_001.mp4 frames/2025/01/15/cam01_000123.jpg db/edge_meta.db

edge_meta.db里的表记录每一帧的原始文件路径、目标检测结果、模型版本、推理耗时等。断网时，推理服务照常写库；网络恢复后，同步服务把增量数据推到云端。用 SQLite 的好处是单文件备份非常方便，运维时直接拷贝文件就是一个完整的本地快照。

5.2 Kafka 延迟消费在弱网场景中的实际用法

边缘节点与云端进行数据同步，消息队列是常用的选项。Kafka 在工业界的地位无需多说，边缘场景里它的一个特性很值得利用：延迟消费。所谓延迟 30 分钟消费，不是指数据处理慢，而是指消费者可以主动控制拉取消息的时机，故意等到某个时间点或某个条件满足后再处理。

弱网环境下的用法是这样的：边缘端作为生产者，把推理结果写入本地 Kafka 或本地消息文件；云端消费者不实时拉取，而是等网络条件好的窗口期（比如凌晨空闲时段）再批量消费。这样既避免弱网时的流量争抢和消息丢失，又能保证数据最终一致。如果你完全不想在边缘端装 Kafka 这种"重量级"组件，也可以用文件加定时上传的方式模拟延迟消费——本质上就是把"消费者延迟"变成了"上传调度延迟"。

真正使用 Kafka 时有一个细节容易踩坑：边缘端设备经常掉线，消费者 rebalance 频繁，导致处理延迟不稳定。建议把边缘端生产者的acks设为 1（不等待所有副本确认），把消费者的session.timeout.ms调大（比如 30 秒以上），减少因网络抖动造成的误判。还有一点，Kafka 默认的log.retention.hours是 168 小时（7 天），如果断网时间超过这个期限，云端消费前消息就已过期。所以边缘场景下要么把生产端的保留时间调大到 72 小时以上，要么加上持久的本地落盘作为兜底。我的习惯是：Kafka 只做传输通道，本地 SQLite 才是可靠的数据源。

5.3 边云同步的整体流程：断点续传与幂等设计

断网恢得后的同步流程，至少要保证两个特性：断点续传和幂等性。断点续传好理解，就是上传过程中网络再次中断，下次从上次中断的位置继续，不能从头再来。实现方式可以是记录每个文件的上传偏移量，或者按小批次分发消息，标记每批次的完成状态。

幂等性指的是云端重复收到同一条消息时不会产生重复数据。边缘端在自己没收到云端 ack 时可能会重发，云端需要按消息 ID 去重。在设计消息格式时，我给每条消息加一个全局唯一的msg_id，格式是设备ID+时间戳+随机数。云端以msg_id作为主键或唯一索引写入，重复消息自然被数据库拦掉。这套设计看起来简单，但能解决真实场景中 80% 的数据同步问题。

整个同步链路在我项目中的最终形态是：边缘推理服务 -> SQLite 落盘 -> 上传调度器（网络状态检测 + 分批拉取）-> Kafka 生产 -> 云端消费者 -> 数据库去重入库。断网时只有第一步和第二部在运行，云端服务完全不可用也不影响现场业务。这套架构我们在弱网果园环境连续跑了两个月，没有出现数据丢失。

6. 实测数据与踩坑记录

6.1 边云延迟对比：一份来自真实场景的测试数据

为了给读者更直观的判断，我把部署在 Orin Nano 上的边缘视觉方案和原本的云端方案做了对比测试。测试任务都是 YOLOv8n 目标检测，输入 640x640，云端是单张 T4 GPU，边缘端是 Orin Nano 8GB，具体数据如下：

关键不在边缘端的推理有多快——实际上 Orin Nano 的推理速度还不如 T4——但把传输时间消掉以后，端到端延迟直接下降了一个数量级。这个对比说明，Physical AI 场景里的主要矛盾往往是网络而不是算力。

6.2 部署过程中踩过的坑和解决办法

最后整理几个真实踩坑记录，希望能帮读者少走弯路。

第一个坑是 TensorRT 动态尺寸设置不当导致显存爆炸。很多人图省事，把maxShapes设得很大，比如一次能处理 32 张 1080P 图片。TensorRT 会在构建时按最大尺寸分配显存，直接导致小模型也占满整块设备显存。解决办法是 maxShapes 只设到实际业务可能的最大并发量，宁缺毋滥。多路视频并发需要平衡：如果 Orin Nano 要同时处理 8 路视频，每路推理分辨率用 640 而不是 1080，能显著降低显存峰值。

第二个坑是散热降频。Jetson 设备在持续高负载下温度会快速上升，GPU 自动降频导致推理时间从 20ms 涨到 50ms，延迟直接翻倍。Jetson 系列的默认功耗模式是 MAXN（最大性能），但散热跟不上照样掉速。建议手动设置功耗模式为适合的档位，比如 Orin Nano 设为 10W 或 15W 模式，配合主动散热风扇，稳定运行温度控制在 60 度以下。性能可能略微下降，但延迟曲线平直得多。

第三个坑是 ONNX 算子不兼容。PyTorch 模型里一些自定义 op 或较新的算子，转成 ONNX 后 TensorRT 可能不支持。我的排查经验是：先把动态维度固定成静态维度测试，如果通过，再逐步开放动态维度。如果某个算子报不支持，回到 PyTorch 里用等价的传统算子替换，比如把 GridSample 改成双线性插值配合 Sampler，或者用 ONNX Simplifier 做图优化，很多普通算子组合可以自动融合成 TensorRT 支持的单个算子。

第四个坑是多人共用一个 GPU 时显存泄漏。在开发环境反复加载 engine、运行推理、释放显存，长时间跑下来内存碎片会越来越多，最终导致显存分配失败。解决办法是不要在热路径里反复创建和销毁执行上下文。一个 engine 对应一个 context，长时间运行的进程应该做到初始化时创建，持续复用到进程结束。如果确实需要频繁切换模型，那最好在子进程里做隔离，模型跑完直接杀掉子进程。

第五个坑是 INT8 量化后精度明显下降。我遇到过目标框偏移、漏检的情况。排查后发现校准集里全是白天的图，没有夜间图像，导致模型在夜间场景下量化误差被放大。重新采集包含夜间和逆光场景的校准图后，精度基本恢复。这也印证了前面说的：量化校准集的代表性比数量更重要。

回过头来看，Physical AI 项目从云端搬到边缘，本质上是一次对系统实时性和鲁棒性的重新设计。模型变小了，但工程复杂度没有变小——模型压缩、推理框架调优、延迟平滑、断网容灾、数据同步，每一个环节都会遇到具体的坑。这也正是边缘部署有意思的地方：同样的模型，换个部署环境，就是一场全新的实战。对我个人来说，最大的收获不是把延迟从几百毫秒压到了几十毫秒，而是明白了物理世界中的 AI 系统，不能只看模型精度，更要看它在真实环境里能不能稳定地活下去。