计算机视觉项目里那些让我掉头发的性能优化细节
去年三月，我坐在自习室里对着考研数学卷子发呆，心里盘算着“要是没考上就去深圳打工”。结果真没考上。四月收拾行李南下，六月入职一家做智能零售的初创公司——坐标南山科技园，腾讯大厦就在隔壁，每天看着鹅厂的同学拎着早餐优哉游哉地走进大楼，而我还在为第一个CV项目焦头烂额。
说实话，研究生没上成，但代码没少写。尤其喜欢深夜coding，写字楼安静，微信消息少，连产品都睡了，效率拉满。最近刚搞完一个商品识别系统，从算法选型到线上部署，踩了一堆坑，也攒了些经验。今天就聊聊这个实战项目里关于性能优化的那些事，顺便回答几个面试常被问到的面试题，希望能帮到和我一样在求职路上挣扎的应届生。
业务场景：便利店里的“火眼金睛”
我们做的是一款智能货架系统：摄像头拍下货架照片，AI自动识别商品种类、数量、是否缺货。听起来简单？上线第一天就被运维告状：“你们模型跑一次要8秒，门店网络卡得像2G！”——这哪行，店员扫一眼只要0.5秒，AI比人还慢？
数据集是内部采集的，约10万张货架图，涵盖500+ SKU，光照、角度、遮挡问题严重。初始方案用了现成的YOLOv5，精度不错（mAP@0.5 达到89%），但推理速度在Jetson Nano上只有3 FPS，完全没法用。
于是，优化成了生死线。Deadline是两周后的产品发布会，老板说：“搞不定，你和模型一起滚。”
算法不是越新越好，而是越“合适”越好
一开始我想上SOTA模型，比如YOLOv8或者RT-DETR，但实测发现：参数量大 ≠ 效果好，尤其在边缘设备上。
我拿GPT-4问过：“在资源受限的边缘设备上，如何平衡CV模型的精度与速度？”它给出了一套思路：量化 + 轻量化骨干 + 输入分辨率裁剪。虽然有点泛，但方向是对的。真正干活还得靠自己调参。
最终我们做了三件事：
- 换Backbone：把YOLOv5s的CSPDarknet换成MobileNetV3。参数量从7M降到2.6M，推理速度翻倍。
- 输入分辨率从640x640降到320x320。别小看这一步，计算量直接降为1/4！虽然mAP掉了5个点，但通过数据增强（随机裁剪+亮度抖动）补回了3个点。
- 用TensorRT做FP16量化。在Jetson上，这一步让推理时间从1.2s降到0.4s。
# TensorRT FP16导出示例（简化版）
import torch
from torch2trt import torch2trt
model = torch.load('yolov5s_mobilenet.pth').eval().cuda()
x = torch.randn(1, 3, 320, 320).cuda()
model_trt = torch2trt(model, [x], fp16_mode=True)
torch.save(model_trt.state_dict(), 'yolov5s_trt_fp16.pth')
注：实际部署时还要处理NMS后处理，这部分用CUDA kernel重写效果更佳。
面试题高频考点：资源 vs 精度的权衡
最近面了几家大厂（没错，还在骑驴找马），几乎每场都会问：
“在边缘设备上部署CV模型，你会从哪些维度做性能优化？”
标准答案不能只说“量化、剪枝、蒸馏”，得结合具体场景。比如我们这个项目，内存带宽比算力更关键——因为Jetson Nano的GPU显存只有4GB，频繁IO会卡死。
所以我们的优化策略是：
- 减少中间特征图尺寸：在neck部分加通道压缩（从256→128）
- 合并Conv+BN+ReLU：减少kernel launch次数
- 异步预处理：用多线程提前加载下一张图，避免GPU空等
下面是我们优化前后的性能对比（测试环境：Jetson Nano，Ubuntu 18.04）：
| 优化阶段 | 模型大小 (MB) | 推理时间 (ms) | mAP@0.5 | 内存占用 (MB) |
|---|---|---|---|---|
| 原始YOLOv5s | 14.2 | 1200 | 89.1% | 1800 |
| MobileNetV3 + 320x320 | 8.7 | 620 | 84.3% | 1100 |
| + FP16 TensorRT | 4.5 | 410 | 83.8% | 780 |
| + 后处理CUDA加速 | 4.5 | 280 | 83.8% | 750 |
280ms，接近3.5 FPS，勉强能用。虽然离“实时”还有差距，但产品妥协了——毕竟他们也没想到技术这么难。
别信“一键部署”，线上事故教会我敬畏
你以为导出ONNX、转TensorRT就完事了？Too young。
上周五晚上十点，测试突然call我：“线上识别全是错的！泡面被识别成洗发水！”我赶紧ssh进设备，发现是图像预处理不一致导致的：训练时用PIL resize，部署时用OpenCV，插值方式不同，像素值偏移了10+。
这种低级错误，GPT-4肯定不会告诉你。它只会说“确保预处理一致”，但不会提醒你PIL默认是BILINEAR，而OpenCV是INTER_LINEAR，两者在边缘像素上差很多。
修复方案很简单，但定位花了两小时。从此我立下规矩：训练和部署必须用同一套预处理代码，甚至封装成Docker镜像，保证环境一致。
给应届生的建议：别只刷LeetCode，多跑真实数据
很多同学（包括曾经的我）以为算法岗就是推公式、调loss。但现实是：工程能力决定你能不能上线，算法能力决定你能不能升职。
这个项目让我明白：
- 面试题往往来自真实痛点。比如“如何减少模型延迟？”背后可能是产品经理在催上线。
- 资源永远不够。你要在CPU、内存、带宽、电量之间做trade-off。
- GPT-4是好助手，但不能替代debug。它给的是方向，细节还得你填。
现在回头看，考研失败未必是坏事。至少在深圳，我亲手把一个模型从实验室搬到了便利店货架上。虽然工资不高，但每次看到店员用我们的系统扫码补货，心里还是有点小骄傲。
最后一点心得
性能优化不是炫技，而是在约束条件下找最优解。有时候，降低10%精度换来2倍速度，是值得的。毕竟，商业世界不看mAP，看ROI。
如果你也在做CV项目，别一上来就追SOTA。先问清楚：设备是什么？延迟要求多少？数据分布如何？再动手。
对了，最近在准备跳槽，目标是鹅厂。听说WXG很看重端侧优化经验……希望这篇总结能帮我拿到面试机会。要是你也在深圳找CV相关工作，欢迎交流（简历可私）。
深夜写完，窗外又下雨了。深圳的春天，真是又湿又卷。但代码跑通的那一刻，一切都值得。
评论 0