边缘AI推理在工业场景的定位有三个确定性约束：产线侧毫秒级响应（视觉质检要求50ms内完成推理并输出判定）、断网自治能力（网络中断时推理不中断）、数据隐私合规（敏感工艺数据不出场）。这三个约束共同决定了模型推理必须部署在边缘侧，而非云端集中推理。
推理硬件：性能与功耗的权衡
边缘推理硬件的选择不是简单的"算力排序"，而是在性能、功耗、体积和成本四个维度上寻找平衡点。
推理硬件 | 算力(TOPS) | 功耗(W) | 典型延迟 | 工业适用场景 |
NVIDIA Jetson AGX Orin | 275 | 15-60 | 5-20ms | 视觉质检（高精度） |
华为昇腾310 | 22 | 8 | 10-30ms | 通用推理（国产化） |
FPGA（Xilinx Zynq） | 可变 | 5-15 | 1-10ms | 定制化推理（低延迟） |
Intel CPU Xeon | 依核数 | 80-250 | 50-200ms | 管理面推理（非实时） |
GPU在视觉类推理中占主导。Jetson AGX Orin提供275 TOPS算力（INT8），支持CUDA/TensorRT加速，生态最完善——PyTorch/TensorFlow模型可直接部署。但GPU功耗较高（15-60W），对边缘设备的散热设计有要求。工业现场环境温度可能达50°C，被动散热方案需要增大散热片面积，主动散热（风扇）引入故障点和粉尘防护问题。
NPU（神经网络处理器）是国产化场景的选择。华为昇腾310提供22 TOPS算力，功耗仅8W，适合功耗受限场景。昇腾的CANN（Compute Architecture for Neural Networks）支持ONNX模型格式转换，但与CUDA生态的兼容性需额外适配——部分算子需手工映射到CANN的AICore指令集。
FPGA在延迟极致场景有不可替代性。FPGA的流水线并行架构可以实现推理延迟低于10ms——对于高速产线（传送带速度2m/s，每秒10个产品），单件检测时间窗口只有100ms，FPGA的低延迟优势决定能否做到100%在线检测。但FPGA开发门槛高，模型需要从ONNX重新映射到RTL（Register Transfer Level），部署周期以月计。
CPU推理适合非实时场景。报表生成中的文本分类、设备告警的根因推理，对延迟不敏感（100ms-1s可接受），用CPU推理避免额外硬件投入。ONNX Runtime的CPU执行提供器（Execution Provider）利用AVX-512指令集加速，性能可达GPU的1/5-1/10。
模型优化：从FP32到INT8
模型训练在云端完成，使用FP32精度。边缘部署时FP32模型的内存占用和推理延迟通常不可接受——一个ResNet-50的FP32模型约100MB，INT8量化后仅25MB，推理速度提升2-3倍。
量化（Quantization）将模型权重和激活值从FP32/FP16映射到INT8。量化分训练后量化（Post-Training Quantization, PTQ）和量化感知训练（Quantization-Aware Training, QAT）两种。PTQ不需重新训练，用少量校准数据确定量化参数，操作简单但可能有精度损失（1-3%）。QAT在训练过程中模拟量化误差，精度损失更小但需要完整训练流程。
工业视觉质检模型对量化精度损失敏感——0.5%的精度下降可能导致漏检率从0.1%升到0.6%，在百万级产量下意味着多出数千个不良品。PTQ+校准数据集是最常用的方案，校准数据需覆盖正常和缺陷样本的真实分布。
剪枝（Pruning）移除模型中贡献小的参数。结构化剪枝删除整个通道或层，非结构化剪枝删除单个权重。结构化剪枝的推理加速效果更确定——删除通道后模型变小，推理计算量直接减少。非结构化剪枝需要稀疏矩阵加速支持，通用推理框架对稀疏计算优化有限。
知识蒸馏（Knowledge Distillation）用大模型（Teacher）训练小模型（Student）。Student模型结构更简单、参数更少，但学习Teacher的软标签（Soft Label）后精度接近Teacher。工业场景中，Teacher是高精度ResNet-152，Student是轻量MobileNetV3——Student的推理速度快5-10倍，精度损失2-3%。
TensorRT优化针对NVIDIA GPU做推理加速。TensorRT对模型做层融合（Layer Fusion，将连续的Conv+BN+ReLU合并为一个CUDA kernel）、精度校准（INT8校准）和动态形状优化。优化后的引擎文件（.engine）不可跨GPU架构——在Jetson AGX Orin上编译的引擎不能在Jetson Nano上运行。
推理框架：选型对比
推理框架 | 后端硬件 | 模型格式 | 部署复杂度 | 工业适配度 |
TensorRT | NVIDIA GPU | ONNX→Engine | 中（需编译） | 高（GPU场景首选） |
ONNX Runtime | CPU/GPU/NPU | ONNX | 低（跨平台） | 高（通用性最佳） |
OpenVINO | Intel CPU/iGPU/VPU | ONNX/IR | 中（需转换） | 中（Intel生态） |
TFLite | ARM CPU/Edge TPU | TF Lite | 低（移动端） | 中（边缘设备） |
ONNX Runtime是跨平台首选。它支持多种执行提供器（Execution Provider）——CPU（AVX-512加速）、CUDA（NVIDIA GPU）、TensorRT（NVIDIA GPU加速）、OpenVINO（Intel硬件）。同一ONNX模型可在不同硬件上运行，切换硬件只需更换Execution Provider配置。这种灵活性在工业场景很重要——不同产线可能使用不同推理硬件，统一模型格式降低维护成本。
TensorRT在NVIDIA场景下性能最优。但TensorRT的引擎编译与GPU架构绑定，不同Jetson型号需分别编译。部署时需建立"模型版本×硬件架构→引擎文件"的矩阵管理机制。
边缘-云端协同
边缘推理不是完全脱离云端。两类协同模式在工业中各有适用场景。
云端训练→边缘推理是主流模式。训练数据和训练过程在云端完成，训练好的模型下发到边缘设备。模型版本管理通过OTA（Over-The-Air）更新——边缘设备定期检查模型版本，下载新版本，验证完整性和签名后热切换。切换过程需保证不中断推理服务——新引擎加载完成后原子切换，旧引擎资源释放。
联邦学习在数据不可集中的场景中有价值。多个工厂各自训练本地模型，只交换模型梯度而非原始数据，聚合后得到全局模型。工业联邦学习的典型应用是设备故障预测——故障样本在单工厂内太少，多工厂联合训练可以提升模型泛化能力。联邦学习的通信开销是主要瓶颈——梯度传输量取决于模型参数量，ResNet-50约25M参数，每轮通信传输100MB梯度数据，在工厂窄带宽链路下单轮训练可能耗时数小时。
推理服务的工程化部署
模型推理不是孤立运行，需要包装为可运维的服务。
容器化推理服务将模型、推理框架和依赖环境打包为Docker镜像。容器启动时加载模型文件，暴露gRPC或REST接口供业务调用。容器化解决了环境一致性问题——开发环境训练的模型，到产线环境推理结果一致。
模型版本管理通过MLflow或自建模型仓库实现。每个模型版本记录：训练数据集版本、模型架构、超参数、评估指标（精度/召回/F1）、推理延迟基准。产线部署时按版本号拉取模型，A/B测试时按流量比例分配不同版本。
推理监控跟踪服务运行状态。QPS、延迟分布（P50/P95/P99）、错误率是基础指标。工业场景还需监控推理结果分布——如果缺陷检测的阳性率突然从2%跳到15%，可能是模型衰减（产线变化导致数据分布偏移）或采集设备故障。模型衰减检测通过监控模型置信度分布漂移实现——当输入数据分布偏离训练分布时，模型置信度整体下降，触发模型重训练告警。
TDengine在边缘AI推理链路中承担两个角色：边缘侧的推理结果存储和数据订阅源。推理结果（缺陷类型、置信度、位置坐标）写入TDengine，与原始设备数据按时间戳关联，支持追溯分析。数据订阅功能（Subscription）将设备数据流推送给推理服务——设备振动数据变化触发推理服务执行异常检测，实现数据驱动推理的实时联动。
结语
工业互联网边缘AI推理的工程链路从模型训练延伸到产线部署，横跨云端和边缘两侧。推理硬件的选择在性能和功耗间权衡，模型优化在精度和速度间折中，推理框架在通用性和极致性能间取舍。联邦学习提供了数据合规的跨工厂数据协作路径，但通信开销仍是工程瓶颈。
推理服务的工程化部署——容器化、版本管理、模型衰减监控——决定了边缘AI能否长期稳定运行。在数据基础设施层，能够同时支撑高频数据存储和数据订阅分发的数据平台，是边缘AI推理链路中数据侧的核心组件。
