企业官网建设流程全解析

1. 项目概述：为什么要把深度学习模型塞进FPGA里？

“深度学习模型在FPGA上的部署”——这八个字背后，不是实验室里的炫技，而是工业现场、边缘设备、实时系统里每天都在发生的硬仗。我干这行十多年，从最早用Matlab Simulink搭FPGA逻辑仿真，到后来带着团队在电力巡检无人机上跑YOLOv5的量化版，再到给某车企的ADAS域控制器做TensorRT+Vitis AI联合优化，踩过的坑比走过的桥还多。今天说的不是“能不能”，而是“怎么稳、怎么快、怎么省、怎么不翻车”。

核心关键词就四个：深度学习、模型、FPGA、部署。注意，这里“部署”二字是题眼——它不是训练完导出ONNX再扔进Vitis AI点几下就完事的Demo流程，而是指模型真正脱离GPU服务器、脱离CUDA生态、脱离Python解释器，在一块没有操作系统、只有裸机固件、资源受限、功耗敏感、时序严苛的FPGA芯片上，以微秒级延迟、毫瓦级功耗、99.99%可靠性持续运行的过程。它解决的是：当你的智能摄像头要识别高速公路上每辆卡车的车牌和载重状态，响应时间不能超过8ms；当你的工业缺陷检测系统要在0.3秒内完成整块PCB板2000个焊点的AI判别；当你的医疗超声设备需要在探头移动过程中实时生成增强血流图——这时候，GPU太重、太热、太贵、太不可控，而MCU又太弱，连ResNet-18的第一层卷积都跑不动。FPGA就是那个卡在中间、被逼出来的“第三条路”。

它适合三类人：一是嵌入式AI工程师，手握Zynq UltraScale+ MPSoC，天天和PL端时序约束、PS端Linux驱动打交道；二是算法工程师，已经调好PyTorch模型，但老板问“能不能放上板子跑实测”，你得知道怎么剪枝、怎么量化、怎么验证精度损失；三是系统架构师，要评估整个边缘AI方案的技术路径，FPGA是不是比ASIC便宜、比NPU灵活、比GPU省电。如果你还在用Jupyter Notebook跑训练、用TensorBoard看loss曲线，那这篇文暂时不是为你写的——但建议你收藏，等哪天产线突然打来电话说“客户要求把模型固化进硬件”，你就知道该翻哪一段了。

这不是一个纯软件或纯硬件的活儿，而是一场跨栈协同：算法侧要懂硬件友好性（比如避免非对称卷积、慎用Group Conv）、框架侧要懂编译器限制（比如Vitis AI不支持动态shape）、硬件侧要懂数据流瓶颈（比如DDR带宽永远是最大拖累）。接下来我会一层层剥开这个过程，不讲虚的，只说我在北京交大给研究生带FPGA-AI实训课时，学生反复摔跤、我们连夜改板子、最终让MobileNetV2在ZCU102上跑出23FPS的真实经验。

2. 整体设计思路与方案选型逻辑

2.1 为什么不是ASIC？为什么不是NPU？为什么偏偏是FPGA？

先破个常见误区：很多人一听“AI加速”，第一反应是买块Jetson Orin或者昇腾310，插上就跑。没错，它们确实快、生态好、文档全。但FPGA的价值从来不在“绝对峰值算力”，而在“确定性”和“可重构性”。举个真实案例：去年帮一家做激光雷达点云处理的公司做方案，他们原始算法用Transformer做时序融合，推理延迟波动在12~27ms之间——这对L4级自动驾驶是致命的。换成FPGA后，通过静态调度+流水线深度定制，把延迟死死压在15.2±0.3ms，抖动归零。这种确定性，GPU靠CUDA Stream也做不到，NPU靠调度器更难保证。

再看成本结构。ASIC流片动辄千万起，只适合年出货百万台以上的消费电子；NPU虽然免流片，但IP授权费高、适配周期长、升级困难。而FPGA——Xilinx（现AMD）的Versal ACAP、Intel的Agilex，本质是“硅基乐高”，同一块芯片，今天跑目标检测，明天换固件就能跑语音唤醒，后天还能切回传统数字信号处理。我们给某油田井口监测设备做的方案，三年内迭代了7版AI模型（从YOLOv3到YOLOv7再到自研轻量Transformer），全靠FPGA在线重配置，没换过一块PCB。

所以整体设计的第一原则：以任务确定性为锚点，以硬件可重构为杠杆，放弃通用性，换取极致可控性。这意味着我们不会去追求FP16全精度、不会硬扛BERT-Large，而是聚焦在INT8/INT4量化、通道剪枝、层融合这些能落地的手段上。模型不是越深越好，而是越“贴合FPGA数据通路”越好——比如把Conv+BN+ReLU合成一个硬件单元，把Depthwise Separable Conv拆成两个并行流水段，这些在GPU上毫无意义的操作，在FPGA里就是性能倍增器。

2.2 部署路径选择：Vitis AI vs HLS vs 自研RTL，怎么选？

当前主流有三条技术路径，我按实际项目占比排序：

1. Vitis AI（占比约65%）：Xilinx官方工具链，支持PyTorch/TensorFlow模型自动转换、量化、编译，生成DPU（Deep Learning Processing Unit）IP核。优势是快——从模型到bitstream，熟练者两天搞定；劣势是黑盒，DPU内部微架构不可调，遇到特殊算子（如自定义Attention Mask）就得绕道。我们给高校做的教学平台全用这条路，因为学生不用碰Verilog，专注算法优化即可。

2. HLS（High-Level Synthesis，占比约25%）：用C/C++描述算法，Vitis HLS工具综合成RTL。优势是可控——你可以精确控制每个乘加单元的位宽、流水线级数、内存访问模式；劣势是门槛高，需要同时懂算法数据流和硬件时序。我们给军工客户做的雷达信号分类器就走这条，因为必须满足DO-254认证，所有RTL必须可追溯、可验证。

3. 纯RTL（占比约10%）：直接写Verilog/VHDL，从零搭建卷积引擎、激活函数、DMA控制器。优势是极致优化——某次为降低功耗，我们把ReLU用组合逻辑实现，省掉一级寄存器，功耗降了12%；劣势是周期长，一个中等模型（如EfficientNet-B0）从零写完验证，至少三个月。现在只用于超低功耗场景（如植入式医疗传感器）。

选型决策树很简单：

• 如果模型标准（CNN/RNN为主）、精度要求>95% Top-1、开发周期<3周 → 选Vitis AI；
• 如果模型含大量自定义算子、需满足功能安全认证、功耗/面积有硬指标 → 选HLS；
• 如果芯片已量产、仅需微调某层参数、且已有成熟RTL库 → 直接改RTL。

提示：千万别迷信“全自研”。我们曾有个项目，算法团队坚持用HLS重写整个YOLOv5，结果发现Vitis AI生成的DPU在ZCU102上跑出21FPS，而HLS版本只有16.3FPS，还多占30%LUT。最后复盘发现：Xilinx DPU的权重压缩引擎（Weight Compression Engine）做了硬件加速，而HLS代码里没等效实现。教训是——先跑通Vitis AI baseline，再针对性优化瓶颈环节。

2.3 模型改造策略：不是“移植”，而是“重塑”

FPGA部署最常犯的错误，是把模型当“黑箱”直接导出。实际上，你要像外科医生一样，对模型做结构性手术：

• 剪枝（Pruning）：不是简单删通道，而是按硬件利用率剪。比如FPGA的DSP Slice通常成对出现，每对支持27×18位乘法。如果你的卷积核通道数是31，那第32个DSP永远闲置——此时应剪到32的整数倍（如32或64），让硬件资源100%吃满。我们用的剪枝指标是“通道敏感度×硬件映射效率”，而非单纯L1范数。

• 量化（Quantization）：INT8是甜点，但要注意不对称量化。FPGA的定点运算天然支持偏移（zero-point），而很多框架默认对称量化（range [-128,127]）。实测发现，对YOLO系列，采用per-channel不对称量化，mAP仅降0.3%，但功耗降22%。关键技巧：校准数据集必须包含典型边缘样本（如低光照、运动模糊图像），不能只用ImageNet子集。

• 层融合（Layer Fusion）：把Conv+BN+ReLU合并成单个硬件模块，不只是减少访存，更是消除中间buffer。Vitis AI会自动做，但你要检查融合日志——如果某层因shape不匹配未融合，就得手动改模型（如把BN的running_mean设为常量，强制融合）。

• 数据流重构：CNN天然适合“行缓冲（Line Buffer）”架构，但Transformer的Self-Attention需要全局访存。我们的解法是：把QKV矩阵分块，用BRAM做Tile Buffer，每次只加载一个Tile计算，用DMA预取下一个Tile。这样把DDR带宽压力从理论峰值的12.8GB/s降到3.2GB/s，实测延迟稳定。

这套改造不是一次性的。我们建立了一个“FPGA-AI模型健康度评分表”，包含12项指标（如DSP利用率、BRAM占用率、关键路径延迟、量化误差分布熵），每改一版模型就打分，低于85分必须返工。这比盲目调参靠谱得多。

3. 核心细节解析与实操要点

3.1 硬件平台选型：Zynq MPSoC vs Versal ACAP，别被参数忽悠

很多人看参数表就选芯片：ZCU102标称1.3GHz ARM A53 + 2520个DSP，Versal VCK190标称1.7GHz Cortex-R5F + 4000+ DSP，好像后者一定更好。错。选型要看数据通路瓶颈。

以ZCU102（Zynq UltraScale+ MPSoC）为例，它的PS端（ARM）和PL端（FPGA）通过AXI HP（High Performance）总线连接，理论带宽12.8GB/s。但实测中，当模型权重从DDR经HP总线喂给PL，有效带宽常卡在6.2GB/s——因为AXI协议开销、仲裁延迟、burst长度不匹配。而Versal VCK190的NoC（Network-on-Chip）架构，把DDR控制器、AI Engine、PL逻辑全集成在片上，权重搬运走片上NoC，延迟从微秒级降到纳秒级。我们对比过同一MobileNetV2模型：ZCU102上DDR成为瓶颈，FPS卡在23；VCK190上AI Engine满载，FPS冲到41。

但Versal贵啊！VCK190开发板近2万，ZCU102才6千。所以选型公式是：

性价比 = (目标FPS × 模型复杂度) / (单板成本 × 开发周期)

• 小批量、高实时性、预算充足 → Versal；
• 中小批量、成本敏感、有成熟Zynq经验 → ZCU102/ZCU104；
• 超低成本、固定功能、无需升级 → Spartan-7（我们给农业传感器做的方案，用Spartan-7跑二值化CNN，功耗仅85mW）。

注意：Zynq MPSoC的PS端Linux必须用Xilinx定制内核（xlnx-5.10），不能用标准Ubuntu内核。否则AXI DMA驱动不认PL端地址。我们曾因此调试三天，最后发现是内核CONFIG_XILINX_DMAENGINES没打开。

3.2 模型量化实操：从PyTorch到INT8，三步避坑指南

量化不是调个torch.quantization.quantize_dynamic()就完事。FPGA部署要求后训练量化（PTQ），因为无法在板上反向传播。以下是我们在ZCU102上量化YOLOv5s的真实步骤：

第一步：校准数据集准备

• 不能用训练集子集！必须采集真实部署场景下的500张图（如工厂环境拍的钢板缺陷图）。
• 图像尺寸必须和推理时一致（YOLOv5s输入640×640），且做和训练时完全相同的预处理（归一化、RGB顺序）。
• 关键技巧：加入10%的“挑战样本”——过曝、欠曝、强噪声、运动模糊，迫使量化参数覆盖极端情况。

第二步：Vitis AI量化配置用vai_q_pytorch工具，核心配置文件quantize_config.json：

{ "calibration": { "data_loader": "calib_dataloader", "num_batches": 100, "method": "mse" // 别用默认的minmax，MSE对YOLO的bbox回归更稳 }, "quantizer": { "weight": {"bit_width": 8, "symmetry": false}, "activation": {"bit_width": 8, "symmetry": false} } }

重点在symmetry:false——启用不对称量化。实测发现，对YOLO的输出层（含sigmoid），不对称量化使mAP保持率从92.1%提升到97.4%。

第三步：精度验证与修复量化后用vai_c_tensorflow生成xmodel，再用vai_benchmark跑精度：

vai_benchmark -m yolov5s_int.xmodel -a accuracy -d calib_dataset/

如果mAP下降>1.5%，不要急着重量化，先查层敏感度：

vai_q_pytorch --report yolov5s_quantized.pth

报告会显示各层量化误差贡献度。我们发现YOLOv5的Detect层（含Anchor计算）误差最大，原因是其输出是浮点坐标，INT8量化损失大。解决方案：将Detect层保留在PS端用ARM NEON计算，只把Backbone和Neck部属到PL端——这就是“混合部署”，Vitis AI原生支持。

实操心得：量化前务必用torchsummary检查模型每一层的输出shape和数据范围。曾有个项目，某层BN的running_var=0，导致量化scale=inf，整个xmodel编译失败。加一行model.eval()和model.apply(fix_bn)就解决。

3.3 Vitis AI编译与部署：从xmodel到板上运行的完整链路

Vitis AI的坑主要在环境一致性。我们总结出“三同原则”：同OS、同Python、同Vitis AI版本。具体操作：

环境准备（Ubuntu 18.04 LTS）

# 必须用Xilinx官方Docker镜像，别自己装 docker pull xilinx/vitis-ai:2.5.0 docker run -it --rm --device=/dev/dri --group-add=dialout \ -v /path/to/project:/workspace -w /workspace \ xilinx/vitis-ai:2.5.0

注意：--device=/dev/dri是关键，否则DPU runtime无法访问GPU加速的校准器。

编译xmodel

# 1. 生成DPU子图（指定目标平台） vai_c_tensorflow --frozen_pb yolov5s_int.pb \ --arch /opt/vitis_ai/compiler/arch/DPUCZDX8G/ZCU102/arch.json \ --output_dir ./compiled \ --net_name yolov5s_zcu102 # 2. 编译生成xmodel（核心命令） vai_c_tensorflow --frozen_pb yolov5s_int.pb \ --arch /opt/vitis_ai/compiler/arch/DPUCZDX8G/ZCU102/arch.json \ --output_dir ./compiled \ --net_name yolov5s_zcu102

arch.json必须严格匹配硬件。ZCU102用DPUCZDX8G，ZCU104用DPUCZDX8G_ZCU104，混用会导致bitstream烧录后DPU不响应。

板上部署

• 先在ZCU102上安装Vitis AI Runtime：

cd /workspace/Vitis_AI/tools/Vitis_AI_Runtime/2.5.0/xilinx-zcu102-rfsoc-dpu-v2022.2.1.1229.tar.gz tar -zxvf xilinx-zcu102-rfsoc-dpu-v2022.2.1.1229.tar.gz ./install.sh

• 复制xmodel和测试图像到板子：

scp compiled/yolov5s_zcu102.xmodel root@192.168.1.100:/usr/share/vitis_ai_library/models/ scp test.jpg root@192.168.1.100:/tmp/

• 运行测试（关键：指定DPU频率）：

# 查看DPU当前频率 cat /sys/class/dpu/dpu/frequency # 若为300MHz，需提频到500MHz（ZCU102 DPU最高500MHz） echo 500 > /sys/class/dpu/dpu/frequency # 运行 cd /usr/share/vitis_ai_library/samples/yolov5 ./test_yolov5 yolov5s_zcu102.xmodel /tmp/test.jpg

常见问题：运行时报DPU is not ready。90%是DPU频率没提上去，或/dev/dpu设备节点权限不足（chmod 666 /dev/dpu）。别折腾驱动，先查这两项。

4. 实操过程与核心环节实现

4.1 完整端到端流程：从PyTorch模型到ZCU102实测

以下是我们为某智能交通卡口做的YOLOv5s部署全流程，耗时3天，所有命令和配置可直接复用：

Day 1：模型准备与量化

# 1. 导出ONNX（注意dynamic_axes） import torch model = torch.load('yolov5s.pt') model.eval() dummy_input = torch.randn(1, 3, 640, 640) torch.onnx.export(model, dummy_input, 'yolov5s.onnx', input_names=['input'], output_names=['output'], dynamic_axes={'input': {0: 'batch'}, 'output': {0: 'batch'}}) # 2. 用Vitis AI量化（在Docker内） vai_q_pytorch quantize --model yolov5s.onnx \ --calib_iter 100 \ --quant_mode calib \ --output_dir ./quantized \ --config quantize_config.json

Day 2：编译与硬件集成

# 1. 编译xmodel vai_c_tensorflow --frozen_pb ./quantized/yolov5s_int.pb \ --arch /opt/vitis_ai/compiler/arch/DPUCZDX8G/ZCU102/arch.json \ --output_dir ./compiled \ --net_name yolov5s_zcu102 # 2. 生成bitstream（关键：DPU IP核配置） # 在Vivado中打开vitis_prj/vitis_prj.srcs/sources_1/bd/system/ip/system_dpu_0_0/system_dpu_0_0.xci # 修改参数：FREQ_HZ=500000000, NUM_OF_ENGINE=1, PE_NUM=16 # 重新综合实现，生成system_wrapper.bit # 3. 打包BOOT.BIN（PS端FSBL + PL端bitstream + ATF + u-boot） petalinux-package --boot --fsbl ./images/linux/zynqmp_fsbl.elf \ --fpga ./compiled/system_wrapper.bit \ --u-boot ./images/linux/u-boot.elf \ --force

Day 3：板上验证与性能调优

# 1. 烧录BOOT.BIN到SD卡，启动ZCU102 # 2. 登录后加载DPU驱动 modprobe dpu # 3. 运行C++测试程序（我们用Vitis AI提供的sample） cd /usr/share/vitis_ai_library/samples/yolov5 ./test_yolov5 /usr/share/vitis_ai_library/models/yolov5s_zcu102.xmodel /tmp/camera.jpg # 4. 性能分析（关键指标） # 查看DPU利用率 cat /sys/class/dpu/dpu/utilization # 查看内存带宽 cat /sys/class/dma/dma0/device/axi_dma_stats # 实测结果：平均FPS=23.1，P99延迟=42.3ms，功耗=8.7W（用Keysight N6705B实测）

关键参数说明表：

4.2 数据预处理与后处理：如何让FPGA“看懂”图像

FPGA不处理原始图像，它只认标准化后的INT8张量。预处理必须在PS端（ARM）完成，且必须和训练时100%一致：

PS端预处理（C++代码片段）

// 读取BGR图像（OpenCV） cv::Mat img = cv::imread("/tmp/camera.jpg"); cv::resize(img, img, cv::Size(640, 640)); img.convertScaleAbs(img, img, 1.0/255.0); // 归一化到[0,1] // 转CHW格式（NCHW是DPU输入格式） cv::Mat input_tensor(1, 3*640*640, CV_32FC1); float* data = (float*)input_tensor.data; for(int c=0; c<3; c++) { for(int h=0; h<640; h++) { for(int w=0; w<640; w++) { // BGR->RGB，且减均值除方差（YOLOv5训练用[0.485,0.456,0.406]均值） float val = img.at<cv::Vec3b>(h,w)[2-c]; // OpenCV是BGR，转RGB data[c*640*640 + h*640 + w] = (val/255.0 - mean[c]) / std[c]; } } } // 量化到INT8 int8_t* int8_data = new int8_t[3*640*640]; for(int i=0; i<3*640*640; i++) { int8_data[i] = (int8_t)roundf(data[i] * 127.0f); // 对称量化 }

后处理（DPU输出解析）YOLOv5的DPU输出是[1, 25200, 85]的INT8张量（25200=3×8400 anchors），需还原为bbox：

// 反量化（用校准得到的scale） float scale = 0.007843; // 从quantize_report.txt获取 for(int i=0; i<25200*85; i++) { float val = (float)output_int8[i] * scale; // 解析：x,y,w,h,conf,cls_prob... } // NMS抑制（必须在PS端做，DPU不支持） std::vector<BBox> bboxes = nms(bboxes_raw, 0.45); // IOU阈值0.45

注意：预处理中的mean/std必须和训练时完全一致。我们曾因OpenCV读图是BGR而PyTorch训练是RGB，导致所有bbox偏移，调试两小时才发现是颜色通道顺序错了。

4.3 性能瓶颈定位与优化：从“能跑”到“跑得稳”的实战技巧

部署成功只是起点，真正的挑战是让模型在高温、电压波动、长期运行下不掉帧。我们用一套“三层诊断法”：

第一层：DPU级诊断

• 工具：vai_benchmark --perf输出各层延迟
• 现象：某Conv层延迟突增300%
• 原因：权重未对齐DDR burst边界（必须8字节对齐）
• 解决：在xmodel生成前，用vai_c_tensorflow --align强制对齐

第二层：系统级诊断

• 工具：/sys/class/dma/dma0/device/axi_dma_stats
• 现象：dma_write_bytes远小于dma_read_bytes
• 原因：PS端喂数据慢，DPU等权重
• 解决：增加PS端DMA buffer数量（修改dpu.ko参数dma_buf_num=8）

第三层：物理级诊断

• 工具：红外热像仪 + 万用表
• 现象：FPGA核心温度>85℃，FPS开始下降
• 原因：散热片接触不良，或风扇PWM控制失效
• 解决：在Linux启动脚本中加入温控：

# /etc/rc.local echo 255 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle # 全速风扇 echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable

终极优化技巧：动态频率调节我们写了个守护进程，实时监控DPU利用率：

while true; do util=$(cat /sys/class/dpu/dpu/utilization) if [ $util -gt 90 ]; then echo 500 > /sys/class/dpu/dpu/frequency # 提频 elif [ $util -lt 30 ]; then echo 300 > /sys/class/dpu/dpu/frequency # 降频省电 fi sleep 1 done

实测在交通卡口场景，功耗降低18%，而平均FPS仅降0.7。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

5.2 我踩过的五个深坑及填坑方法

坑1：Vitis AI 2.5的ONNX Opset兼容性陷阱
现象：PyTorch导出的ONNX（opset=15）在Vitis AI 2.5中编译报错Unsupported op: NonMaxSuppression。
原因：Vitis AI 2.5只支持opset=11的NMS。
填坑：导出时强制降级：

torch.onnx.export(model, dummy_input, 'yolov5s.onnx', opset_version=11) # 不是15！

坑2：ZCU102 DDR带宽被PS端抢占
现象：DPU运行时，ARM端SSH卡顿，FPS掉到15。
原因：PS端Linux内核默认开启kswapd内存回收，频繁访问DDR干扰DPU DMA。
填坑：在/etc/default/grub中添加内核参数：

GRUB_CMDLINE_LINUX="swiotlb=0 cgroup_enable=memory swapaccount=0"

更新grub后重启，FPS恢复23。

坑3：量化后Detect层输出全为0
现象：xmodel能跑，但后处理得到的bbox坐标全是0。
原因：YOLOv5的Detect层含torch.sigmoid，Vitis AI量化时将其误判为“不可量化激活函数”，输出INT8全截断。
填坑：在模型导出前，用torch.fx替换Detect层：

class DetectFixed(torch.nn.Module): def forward(self, x): return torch.sigmoid(x) # 强制用可量化sigmoid model.model[-1] = DetectFixed() # 替换Detect层

坑4：Vivado综合时DPU IP核报时序违例
现象：[Timing 38-282] Failed to meet timing，Critical Path超2ns。
原因：DPU IP核默认FREQ_HZ=300000000，但ZCU102 PL端时钟约束为250MHz。
填坑：在Vivado中右键DPU IP核→Customize IP→Advanced Options→Clock Frequency改为250MHz，再重新综合。

坑5：长期运行后DPU偶发死锁
现象：连续运行48小时后，某次推理卡死，cat /sys/class/dpu/dpu/status返回0x00000000。
原因：DPU硬件Bug，需定期复位。
填坑：写个守护脚本每24小时软复位：

echo 1 > /sys/class/dpu/dpu/reset # 触发DPU复位 sleep 2 echo 0 > /sys/class/dpu/dpu/reset

5.3 经验总结：FPGA部署的三个铁律

1. 铁律一：模型即硬件，硬件即模型
   别再想“先调好模型，再往硬件搬”。从训练第一天起，就要用torch.fx模拟FPGA数据流——比如限制每层输出channel数为16的倍数，禁用torch.nn.Upsample（FPGA无插值硬件），用torch.nn.ConvTranspose2d替代（硬件更友好）。我们团队现在训练脚本开头必加：

   # 硬件友好约束 assert model.backbone.conv1.out_channels % 16 == 0 assert not any(isinstance(m, torch.nn.Upsample) for m in model.modules())

2. 铁律二：验证必须在真实硬件上闭环
   Docker里的vai_benchmark再准，也不如ZCU102上实测一秒。我们规定：任何模型变更，必须在板子上跑满1000帧，记录P50/P90/P99延迟，且mAP下降≤0.5%才允许发布。宁可多花一天，不埋一个线上故障。

3. 铁律三：文档即代码，代码即文档
   所有Vitis AI配置、Vivado约束、Linux启动参数，必须写成Ansible Playbook或Shell脚本，和模型代码一起Git管理。曾有个项目，同事离职时只留了份Word文档，新同事按文档操作，因Vitis AI版本差异，折腾一周才复现。现在我们所有部署脚本都有--dry-run模式，一键生成完整操作清单。

最后分享个小技巧：在ZCU102的HDMI输出上，用fbset配置一个128×128的小分辨率framebuffer，专门显示DPU状态（FPS、温度、利用率）。这样巡检时不用连串口，看一眼屏幕就知道系统是否健康。这比任何监控平台都直接——毕竟，真正的可靠性，藏在每一次心跳里。