1. 课程导论与行业背景
1.1 工业视觉检测：为什么我们还需要这门课？
先说说现状。工业视觉检测，说白了就是用摄像头代替人眼去挑产品毛病。听起来不复杂，对吧？但真正在产线上干过的人都知道，这里面的坑比想象中多得多。
我2018年第一次去一家3C电子厂做项目，客户要求检测手机中框上的划痕。精度要求0.1mm，节拍要求每件200毫秒。当时我们团队信心满满，觉得深度学习模型在实验室跑得那么好，上产线还不是分分钟的事？结果呢？
嗯，现实给了我们一记重拳。
核心痛点清单：
- 数据困境：良品数据堆积如山，缺陷样本凤毛麟角。正负样本比经常达到10000:1，甚至更高。
- 环境敏感：光照变化、产品来料角度偏移、产线振动，任何一个因素都能让模型精度从99%掉到80%。
- 节拍压力：产线要求毫秒级响应，而深度学习模型在GPU上跑一次推理可能就要几十毫秒，更别提还要做前后处理。
- 部署鸿沟：实验室用PyTorch/TensorFlow，产线端是C++、是ARM、是FPGA。模型格式转换、算子兼容性、量化精度损失，每一步都可能翻车。
我见过太多团队，算法在服务器上跑得风生水起，一到嵌入式设备上就各种报错。算子不支持、内存溢出、推理时间超标……说白了，模型移植这件事，从来就不是简单的“导出-加载”两步走。
1.2 模型移植的挑战：从服务器到产线的最后一公里
模型移植，我个人的定义是：把在GPU服务器上训练好的深度学习模型，高效、稳定地部署到资源受限的边缘设备上，并保持可接受的精度和速度。
这个过程，我把它拆成三个层面的挑战：
| 挑战层面 | 具体问题 | 我踩过的坑 |
|---|---|---|
| 算法层 | 模型结构过于复杂，参数量大，算子不兼容 | 曾经用了一个带自定义算子的检测头，转ONNX时直接报错，最后不得不重写算子 |
| 工程层 | 推理框架选择、内存管理、多线程调度 | 有一次在RK3399上跑模型，内存泄漏导致连续运行72小时后系统崩溃 |
| 业务层 | 产线节拍、稳定性、易维护性 | 客户要求7×24小时不间断运行，模型精度漂移问题让我熬了好几个通宵 |
避坑指南：我曾经接手过一个项目，前团队在服务器上用了FP16推理，精度达标。但移植到边缘设备的INT8量化后，mAP直接掉了15个点。为什么？因为量化校准集没有覆盖所有缺陷类型。记住：量化不是免费的午餐。
1.3 课程整体技术栈与学习路径
这门课，我不会跟你讲太多花里胡哨的理论。咱们就聚焦一件事：怎么把模型从服务器搬到产线上，并且跑得稳、跑得快。
下面这张图，是我梳理的课程知识体系。你一看就明白我们要学什么。
你看，整个技术栈分四层。底层是基础，顶层是目标。我们这门课，重点在中间两层——模型转换与推理引擎适配和嵌入式部署优化。为什么？因为这两层是真正的“硬骨头”，也是市面上课程讲得最少的地方。
1.4 学习路径建议
我个人建议的学习顺序是这样的：
- 先修基础：Python、C++基础、深度学习基础（CNN、目标检测）。如果你对这些还不熟，建议先补一补。
- 核心攻坚：跟着课程节奏，从模型压缩量化开始，逐步深入到各个推理引擎的适配与优化。
- 实战演练：每个章节都有配套的代码和项目，一定要动手跑一遍。光看不练，等于白学。
- 项目复盘：课程最后会带大家完整走一遍从0到1的项目落地流程，包括我踩过的坑和解决方案。
我的建议：准备一块开发板，比如NVIDIA Jetson Nano或者RK3588。别只看文档，一定要把模型烧进去跑一跑。你想想看，模型在服务器上跑1000张图只要1秒，在开发板上可能要10秒。这10倍的差距，就是我们要解决的问题。
好了，第一章就到这里。记住一句话：模型移植不是终点，稳定运行才是。接下来，我们就要开始动手了。