最近花了一个周末把YOLOv11目标检测模型从训练到部署完整跑了一遍最终在嘉楠K230开发板上用摄像头实时推理成功。整个过程踩了不少坑从数据集标注、PyTorch训练、ONNX导出、NNCase量化转换到CanMV上加载kmodel做推理每一步都比想象中更考验细节。今天把这条链路完整记录下来包括那些文档里不会写、只在翻车之后才明白的坑希望能给同样想在这类端侧AI开发板上跑模型的同学省点时间。这篇内容适合两类人一是正在用K230做视觉项目、想接入YOLO系模型的开发者二是手里有边缘设备、想搞懂“训练好的模型到底怎么变成板上能跑的推理程序”的学生或工程师。我不会只贴几个命令而是会把每个环节的“为什么”也讲清楚。1. 为什么把YOLOv11搬到K230上1.1 K230开发板到底能干什么嘉楠K230是一块基于RISC-V架构双核C908处理器加自研KPU神经网络加速单元的AIoT开发板。和树莓派、Jetson Nano这类通用计算平台不同K230的思路更偏向“专用加速”把经过量化的神经网络模型跑在KPU上CPU只负责逻辑调度、图像采集、结果后处理这些活。实测下来K230在INT8精度下大概能提供2TOPS左右的算力这个数字放到今天的大算力芯片面前确实不算亮眼但它有几个不可替代的优点功耗低整板几瓦、体积小、价格便宜、有完整的中文资料和工具链。加上板载MIPI-CSI摄像头接口和LCD显示接口非常适合做“小眼睛”式的边缘视觉设备。这类开发板的定位我习惯用一个类比Jetson系列像是一台能装下整个深度学习框架的移动工作站而K230更像一台有特定插槽的专用解码器。你不需要在板子上装PyTorch也不需要折腾CUDA环境要做的只是把模型转换成它认得的那一种格式kmodel然后让它高效的跑起来。1.2 端侧目标检测的整体链路在PC上训练YOLOv11并在本地做推理验证相信绝大多数人都能搞定。但放到K230这种端侧设备上整个流程变成了这样数据集准备采集图片、标注目标框、划分训练集/验证集。模型训练用Ultralytics框架基于YOLOv11做迁移学习。模型评估看mAP、PR曲线、loss曲线确认模型没有欠拟合或过拟合。模型导出将PyTorch权重导出为ONNX格式。模型转换用NNCase工具链把ONNX量化为INT8并生成kmodel。板端部署在CanMV IDE中写Python推理脚本实现摄像头采集、KPU推理、后处理、显示。调优迭代如果精度/帧率不理想回到训练阶段改数据或参数。这条链路中的每一个箭头其实都是一道“翻译关卡”。PyTorch训练出的权重文件是一个表达方式ONNX又是另一种KPU能理解的kmodel又是完全不同的格式。每一道翻译都会损失信息尤其是INT8量化这一步处理不好精度直接崩。1.3 为什么选YOLOv11而不是YOLOv5/YOLOv8YOLOv11发布之后很多人第一反应是“又来了一个版本”。但对我来说选择v11有几个非常实际的理由Ultralytics官方直接提供了yolo11n.pt预训练权重迁移学习成本极低。同尺寸的nano版本在COCO上的精度比YOLOv8n略高而推理速度和模型体积几乎没有增加。网络结构上引入了C3k2模块和C2PSA注意力机制对中小目标的特征提取能力有所提升。依然是Anchor-Free的检测头设计后处理逻辑和v8几乎一致导出ONNX时不需要为兼容性问题大改代码。当然你完全可以继续用YOLOv8甚至YOLOv5因为K230的转换工具链对这类模型的支持已经很成熟。但既然新版本在同样算力成本下能带来一点精度收益那我没有理由不选它。需要提醒的是Ultralytics的Python包名是ultralytics模型权重是yolo11n.pt而不是yolov11n.pt。很多人在这一步会被绕晕我在项目里第一次写YOLO(yolov11n.pt)就直接报错。社区里大家习惯叫YOLOv11但代码里是yolo11这个细节记一下就行。2. 训练阶段从数据集到导出模型2.1 数据准备与标注规范我在这个项目里检测的目标是“罐装饮料”一共自己拍和采集了大概1200张图片用了LabelImg打标。LabelImg这个工具不复杂但我建议从一开始就按YOLO格式组织好目录否则后期整理数据会占用大量无效时间。目录结构参考datasets/ ├── images/ │ ├── train/ # 约900张 │ └── val/ # 约300张 ├── labels/ │ ├── train/ # 每张图片对应一个同名txt │ └── val/ └── custom.yamlLabelImg标注完成后每一张图片对应的txt文件里每一行是一个目标框类别ID 归一化中心x 归一化中心y 归一化宽 归一化高例如0 0.492187 0.367188 0.364063 0.514062这里有个容易被忽略的细节LabelImg默认保存的是Pascal VOC格式XML需要切换到YOLO模式并且一定要确认classes.txt里的类别顺序和你训练配置中的names列表一致。顺序错位了模型不会报错但推理出来的标签全乱了。数据采集时要让目标在画面中的大小、角度、光照条件尽量丰富。如果可能加入一些难例样本——比如目标被部分遮挡、多个目标紧挨着、背景与目标颜色相近。从最终效果看难例样本对模型在板端实际场景中的表现影响很大。2.2 训练环境的搭建与参数调整训练环境我使用的是带NVIDIA GPU的工作站这里不涉及太复杂的配置。最关键的一步是安装最新版ultralytics和相关依赖pip install ultralytics然后编写一个custom.yamlpath: ./datasets train: images/train val: images/val names: 0: soda_can接着进行训练from ultralytics import YOLO model YOLO(yolo11n.pt) # 加载预训练权重 model.train( datacustom.yaml, epochs120, imgsz640, batch16, device0, workers4, patience20, seed42 )参数上的经验是epochs不必死磕配合patience早停更好imgsz建议用640后面导出和板端部署时可能会降到320但训练阶段用大分辨率能让模型学得更充分batch大小根据显存来显存小的可以直接减半但学习率参数Ultralytics会自动适配。训练过程中要盯着三个东西train/loss曲线持续下降、val/loss曲线同步下降、mAP50和mAP50-95稳步上升。如果train/loss降了但val/loss不降就是过拟合信号早停机制会帮你停下来。训练结束后runs/detect/trainX/weights/目录下会生成best.pt和last.pt。记得用best.pt因为last.pt是最一个epoch的权重不一定是验证集上最优的。2.3 评估结果与导出ONNX评估阶段我习惯先跑一下验证集看一眼指标model YOLO(runs/detect/train2/weights/best.pt) metrics model.val(datacustom.yaml) print(metrics.box.map50) # mAP50 print(metrics.box.map50_95) # mAP50-95这个项目里的模型在验证集上mAP50到了0.93mAP50-95大约0.79说明检测效果已经可用。但别高兴太早这是PC上FP32的指标K230上经过INT8量化后多少会掉一些。导出ONNX时我踩了第一个真正的坑。最初用默认opset17导出结果NNCase转换时一堆算子不兼容。经过反复尝试确认opset12这个版本兼容性最好yolo export modelruns/detect/train2/weights/best.pt formatonnx opset12 imgsz320在这里我直接把imgsz设成了320。为什么因为K230的KPU计算资源和内存都有限640x640的输入会让板端推理帧率低到不可接受。320x320是实时性和精度之间的平衡点实测在这个项目里320输入比640输入每帧推理时间短了3倍以上mAP只掉了4个点左右完全够用。导出后的best.onnx可以用onnxruntime做一个快速验证import onnxruntime as ort import numpy as np session ort.InferenceSession(best.onnx) input_name session.get_inputs()[0].name # 构造一个随机输入做前向 x np.random.rand(1, 3, 320, 320).astype(np.float32) outs session.run(None, {input_name: x}) print([o.shape for o in outs])注意看一眼输出层的类型。YOLOv11导出ONNX后默认输出通常是三个不同尺度的特征图shape分别是[1, 84, 40, 40]、[1, 84, 20, 20]、[1, 84, 10, 10]在320x320输入下其中84 4框坐标 80COCO类别 。这个信息在后续板端后处理时会用到。如果你的教程是自定义单类别那么输出通道就是4 类别数。这个细节决定了你的后处理解码代码怎么改建议记下来。3. 部署阶段kmodel转换与K230板端运行3.1 用NNCase把ONNX转成kmodelK230的KPU不直接识别ONNX它需要一种叫作kmodel的格式。嘉楠提供了一套开源工具链NNCase来完成ONNX/TFLite到kmodel的转换。NNCase的安装和版本选择是个容易踩的坑。你要是随便pip install一个nncase很可能会装到PyPI上的老版本而K230官方SDK里的CanMV固件版本对nncase版本有严格要求。在正式搞之前先确认你刷的固件版本对应的nncase版本。我的建议是直接用嘉楠官方GitHub release里的nncase工具链或者安装SDK时顺便装好配套版本。转换命令大致如下不同版本参数可能稍有差异以官方文档为准ncc convert best.onnx -o best.kmodel -i 320 -t int8 --dataset calibration.txt先说关键的几个参数-i 320指定模型输入尺寸。-t int8量化精度。K230上KPU主要支持int8量化FP16和FP32会有额外限制或根本无法加速。--dataset calibration.txt指定校准数据列表文件文件中每行写着用于校准的图片路径。很多人在量化这一步精度崩了就是因为直接把训练集图片扔去校准。校准集不需要太多每个类别覆盖几十张有代表性的图片就够。我从验证集里抽了100张覆盖不同光照和角度基本能满足要求。校准集太大转换时间翻倍太小则统计的激活值范围不准。转换成功的输出会包含best.kmodel同时控制台会打印算子兼容情况。你最好仔细扫一眼日志如果有某个算子被标记为fallback to CPU那它最终会跑到C908上而占用CPU时间影响整条推理链路的速度。3.2 CanMV环境准备与开发板连接CanMV是K230板上跑的MicroPython环境类似OpenMV的思路给开发板提供了摄像头、LCD、KPU、GPIO等模块的Python绑定。好处是迭代快改一行代码跑一下就看到效果非常适合做原型验证。初次使用需要的准备工作是给K230刷入最新的CanMV固件通过k230的烧录工具即可。用USB线连接开发板在设备管理器里确认串口设备号。打开CanMV IDE连接对应的串口端口。按开发板上的复位键IDE中会看到MicroPython交互式提示符。这里有个常被忽略的细节CanMV固件的版本决定了你用的Python API是哪一套。不同版本之间摄像头对象、KPU对象甚至LCD对象的调用方式都可能有差异。为了省心建议用官方最新的CanMV固件并且对应去看该版本自带的示例代码。另外如果你像我一样在Windows上用CanMV IDE板子连接好后先执行一句print(hello)验证链路是通的再继续往下写代码。3.3 推理脚本的编写逻辑K230上跑YOLOv11的推理脚本整体逻辑可以分为五步初始化摄像头、加载kmodel、读取图像帧、执行KPU推理、后处理并显示。先看一个示意性的脚本框架具体API名称以你固件版本的官方例程为准但逻辑是一致的from canmv import canmv # 1. 初始化摄像头和LCD sensor canmv.Sensor() sensor.reset() sensor.set_framesize(320, 320) # 务必与kmodel输入尺寸一致 sensor.set_pixformat(canmv.RGB565) lcd canmv.LCD() lcd.init() # 2. 加载kmodel kmodel canmv.KModel() kmodel.load(best.kmodel) # 3. 循环读帧、推理、显示 while True: img sensor.snapshot() # 转换为KPU输入所需的CHW格式并做归一化 tensor img.to_tensor() # KPU前向推理 results kmodel.forward(tensor) # 后处理解码目标框NMS boxes decode_output(results, conf_thres0.25, iou_thres0.45) # 画框并显示 img.draw_boxes(boxes) lcd.display(img)重点说一下后处理。YOLOv11是Anchor-Free检测头输出三个不同尺度特征图每个特征图上的每个位置都对应一个预测。解码过程大致是对每个尺度的特征图做sigmoid激活得到类别置信度。将置信度高于阈值的位置提取出来。根据特征图的步长stride反算原图坐标。对同类别框做NMS非极大值抑制去重。如果使用ONNX默认导出没有合并输出那么解码代码要自己写。如果你在Ultralytics中开启了nmsTrue导出ONNX会自带NMS算子但这样在NNCase转换时大概率不支持所以还是得老老实实手动解码。我建议先把后处理代码在PC上用onnxruntime跑通把所有输出的张量形状记下来再到板子上调。这样能少掉很多在板上debug的头发。关于帧率实测在320x320输入下K230上YOLOv11n的KPU推理单帧大约在100到200毫秒之间也就是能有5到10FPS。这个速度对于门禁、垃圾桶分类、安防巡检这类场景够用但如果你想跑视频级实时检测还是得用更轻的模型或者进一步压缩输入分辨率。200毫秒一帧意味着每秒大概5帧用来检测静态目标没问题但高速运动目标就吃力了。优化的思路后面单独讲。4. 常见问题与排查技巧实录4.1 转换阶段常见坑算子兼容与版本错位这块是我踩得最深的地方。最开始用opset17导出的ONNXNNCase直接报了一堆Unsupported op。后来把opset降到12基本上就消停了。如果你遇到的是某个特定算子不支持比如某些版本的YOLOv11输出层带DFL反卷积操作可以先检查ONNX里算子名称再确认是不是开了一些复杂导出选项。另一个典型问题--dataset参数里的路径如果写不对转换不会报错但生成的kmodel精度会异常。我遇到过一种情况校准图片全指向了一张损坏图片模型转换完成后在板上几乎什么都检测不到。排查方法也简单先用一小批验证集图片单独跑一次转换如果可复现的精度差那问题往往在校准集而不是模型结构。4.2 推理帧率上不去怎么办帧率上不去先判断瓶颈在哪。最直观的方法是看KPU占用率和CPU占用率。如果KPU占用率高、CPU在NMS和画框阶段卡住就优化后处理和显示逻辑如果CPU空闲但KPU占用也高那就只能从模型侧或输入分辨率入手。优化后处理我做了三件事把CLS数量写死而非动态计算省去反复读数组长度的开销。NMS的实现从Python循环改成直接操作numpy数组的向量化写法在板上能快很多。降低置信度阈值的同时先按置信度排序再NMS减少无谓计算。如果这些做完还不够就直接把输入降到256x256帧率又能明显提升。不过要权衡好小目标的漏检率输入越小小目标越容易消失。4.3 小目标检测的专项优化我在这个项目里最开始遇到的痛点是远处的罐装饮料经常漏检。YOLOv11在大目标上的表现已经不错但小目标仍然是痛点尤其是到K230上为了帧率把输入降到320后小目标只有十几个像素确实难为人。从训练侧我试过这些手段效果从高到低排列提高输入分辨率训练用640训练、320部署虽然会有域差异但比直接320训320效果更好。Mosaic与MixUp数据增强运行时随机拼图增加小目标出现的频率。在数据集中手动裁剪小目标区域做过采样增强让模型对小目标有更多“见过”的机会。从部署侧如果必须要保留小目标检测能力我会建议做“切图推理”把一帧图像分成多个320x320的区块分别送入KPU推理再合并结果。这个方案会牺牲一部分帧率但在某些固定机位场景下其实是可用的折中方案。还有一个细节INT8量化对小目标的影响往往比大目标更明显。因为小目标的特征相对微弱量化误差会把这些弱特征淹没掉。如果量化后小目标掉得特别厉害可以试试在校准数据里多放小目标的图强制量化统计更偏向小目标特征分布。4.4 一个容易被忽视的部署问题串口与日志调试K230的时候CanMV IDE的串口终端是唯一的反馈通道。代码一崩串口会直接打出一堆异常堆栈有时候几屏都看不过来。我的做法是在推理循环的外层包一个try/except异常时把栈信息写到文件中而不是刷在终端里import sys, traceback try: while True: ... except Exception: with open(err.log, w) as f: traceback.print_exc(filef)这个动作在前期调后处理逻辑时经常救我一命。串口输出有时候被IDE刷新很快来不及看写到文件里就能随时翻。5. 一些更广阔的落地可能性模型在K230上跑通之后整个系统的应用想象空间基本就打开了。网上有人用K230做的“激光打蚊子”项目其实本质上就是一个实时目标检测链路加云台控制K230跑一个检测模型识别到画面中的蚊子位置然后把坐标换算成舵机云台的角度驱动激光器执行点射。这类玩法看起来是纯娱乐但背后用的目标检测、坐标换算、外设联动逻辑和工业上的激光除障、自动巡检设备是完全相通的。我做完这个项目后最大的感受是板子的算力其实不是最关键的瓶颈真正决定一个边缘AI设备能不能落地的是你对模型转换链路、后处理逻辑和硬件资源分配的理解有多深。同样是YOLOv11有人只能在PC上跑着玩有人能把它压成500KB左右量化模型在几瓦功耗的开发板上实现实时检测差距就在这些细节里。后续想在这个项目上做的扩展我列了三个方向结合K230的GPIO接口去驱动舵机做一个可以旋转追踪的摄像头云台。把检测结果通过串口发到上位机做统计或者告警面板。尝试用YOLOv11的分割权重yolo11n-seg.pt或姿态权重在K230上看看算子兼容性和精度表现这属于边探索边玩但也算一种学习路径。我个人在实际操作中的体会是从一个训练好的best.pt到一块真能跑起来的K230板子中间真正考验人的不是算法本身而是工程耐力。每一次报错、每一处算子不兼容、每一帧掉落的延迟都是在提醒你对这个系统每一个环节的理解还不够细。这也是做边缘AI部署最迷人的地方——你不是在跑一个现成的库而是在跟一块芯片、一套工具链、一个物理世界里的摄像头打交道。希望这篇记录能帮后来的你少踩几个坑。
K230部署YOLOv11：从训练到端侧推理的完整链路
最近花了一个周末把YOLOv11目标检测模型从训练到部署完整跑了一遍最终在嘉楠K230开发板上用摄像头实时推理成功。整个过程踩了不少坑从数据集标注、PyTorch训练、ONNX导出、NNCase量化转换到CanMV上加载kmodel做推理每一步都比想象中更考验细节。今天把这条链路完整记录下来包括那些文档里不会写、只在翻车之后才明白的坑希望能给同样想在这类端侧AI开发板上跑模型的同学省点时间。这篇内容适合两类人一是正在用K230做视觉项目、想接入YOLO系模型的开发者二是手里有边缘设备、想搞懂“训练好的模型到底怎么变成板上能跑的推理程序”的学生或工程师。我不会只贴几个命令而是会把每个环节的“为什么”也讲清楚。1. 为什么把YOLOv11搬到K230上1.1 K230开发板到底能干什么嘉楠K230是一块基于RISC-V架构双核C908处理器加自研KPU神经网络加速单元的AIoT开发板。和树莓派、Jetson Nano这类通用计算平台不同K230的思路更偏向“专用加速”把经过量化的神经网络模型跑在KPU上CPU只负责逻辑调度、图像采集、结果后处理这些活。实测下来K230在INT8精度下大概能提供2TOPS左右的算力这个数字放到今天的大算力芯片面前确实不算亮眼但它有几个不可替代的优点功耗低整板几瓦、体积小、价格便宜、有完整的中文资料和工具链。加上板载MIPI-CSI摄像头接口和LCD显示接口非常适合做“小眼睛”式的边缘视觉设备。这类开发板的定位我习惯用一个类比Jetson系列像是一台能装下整个深度学习框架的移动工作站而K230更像一台有特定插槽的专用解码器。你不需要在板子上装PyTorch也不需要折腾CUDA环境要做的只是把模型转换成它认得的那一种格式kmodel然后让它高效的跑起来。1.2 端侧目标检测的整体链路在PC上训练YOLOv11并在本地做推理验证相信绝大多数人都能搞定。但放到K230这种端侧设备上整个流程变成了这样数据集准备采集图片、标注目标框、划分训练集/验证集。模型训练用Ultralytics框架基于YOLOv11做迁移学习。模型评估看mAP、PR曲线、loss曲线确认模型没有欠拟合或过拟合。模型导出将PyTorch权重导出为ONNX格式。模型转换用NNCase工具链把ONNX量化为INT8并生成kmodel。板端部署在CanMV IDE中写Python推理脚本实现摄像头采集、KPU推理、后处理、显示。调优迭代如果精度/帧率不理想回到训练阶段改数据或参数。这条链路中的每一个箭头其实都是一道“翻译关卡”。PyTorch训练出的权重文件是一个表达方式ONNX又是另一种KPU能理解的kmodel又是完全不同的格式。每一道翻译都会损失信息尤其是INT8量化这一步处理不好精度直接崩。1.3 为什么选YOLOv11而不是YOLOv5/YOLOv8YOLOv11发布之后很多人第一反应是“又来了一个版本”。但对我来说选择v11有几个非常实际的理由Ultralytics官方直接提供了yolo11n.pt预训练权重迁移学习成本极低。同尺寸的nano版本在COCO上的精度比YOLOv8n略高而推理速度和模型体积几乎没有增加。网络结构上引入了C3k2模块和C2PSA注意力机制对中小目标的特征提取能力有所提升。依然是Anchor-Free的检测头设计后处理逻辑和v8几乎一致导出ONNX时不需要为兼容性问题大改代码。当然你完全可以继续用YOLOv8甚至YOLOv5因为K230的转换工具链对这类模型的支持已经很成熟。但既然新版本在同样算力成本下能带来一点精度收益那我没有理由不选它。需要提醒的是Ultralytics的Python包名是ultralytics模型权重是yolo11n.pt而不是yolov11n.pt。很多人在这一步会被绕晕我在项目里第一次写YOLO(yolov11n.pt)就直接报错。社区里大家习惯叫YOLOv11但代码里是yolo11这个细节记一下就行。2. 训练阶段从数据集到导出模型2.1 数据准备与标注规范我在这个项目里检测的目标是“罐装饮料”一共自己拍和采集了大概1200张图片用了LabelImg打标。LabelImg这个工具不复杂但我建议从一开始就按YOLO格式组织好目录否则后期整理数据会占用大量无效时间。目录结构参考datasets/ ├── images/ │ ├── train/ # 约900张 │ └── val/ # 约300张 ├── labels/ │ ├── train/ # 每张图片对应一个同名txt │ └── val/ └── custom.yamlLabelImg标注完成后每一张图片对应的txt文件里每一行是一个目标框类别ID 归一化中心x 归一化中心y 归一化宽 归一化高例如0 0.492187 0.367188 0.364063 0.514062这里有个容易被忽略的细节LabelImg默认保存的是Pascal VOC格式XML需要切换到YOLO模式并且一定要确认classes.txt里的类别顺序和你训练配置中的names列表一致。顺序错位了模型不会报错但推理出来的标签全乱了。数据采集时要让目标在画面中的大小、角度、光照条件尽量丰富。如果可能加入一些难例样本——比如目标被部分遮挡、多个目标紧挨着、背景与目标颜色相近。从最终效果看难例样本对模型在板端实际场景中的表现影响很大。2.2 训练环境的搭建与参数调整训练环境我使用的是带NVIDIA GPU的工作站这里不涉及太复杂的配置。最关键的一步是安装最新版ultralytics和相关依赖pip install ultralytics然后编写一个custom.yamlpath: ./datasets train: images/train val: images/val names: 0: soda_can接着进行训练from ultralytics import YOLO model YOLO(yolo11n.pt) # 加载预训练权重 model.train( datacustom.yaml, epochs120, imgsz640, batch16, device0, workers4, patience20, seed42 )参数上的经验是epochs不必死磕配合patience早停更好imgsz建议用640后面导出和板端部署时可能会降到320但训练阶段用大分辨率能让模型学得更充分batch大小根据显存来显存小的可以直接减半但学习率参数Ultralytics会自动适配。训练过程中要盯着三个东西train/loss曲线持续下降、val/loss曲线同步下降、mAP50和mAP50-95稳步上升。如果train/loss降了但val/loss不降就是过拟合信号早停机制会帮你停下来。训练结束后runs/detect/trainX/weights/目录下会生成best.pt和last.pt。记得用best.pt因为last.pt是最一个epoch的权重不一定是验证集上最优的。2.3 评估结果与导出ONNX评估阶段我习惯先跑一下验证集看一眼指标model YOLO(runs/detect/train2/weights/best.pt) metrics model.val(datacustom.yaml) print(metrics.box.map50) # mAP50 print(metrics.box.map50_95) # mAP50-95这个项目里的模型在验证集上mAP50到了0.93mAP50-95大约0.79说明检测效果已经可用。但别高兴太早这是PC上FP32的指标K230上经过INT8量化后多少会掉一些。导出ONNX时我踩了第一个真正的坑。最初用默认opset17导出结果NNCase转换时一堆算子不兼容。经过反复尝试确认opset12这个版本兼容性最好yolo export modelruns/detect/train2/weights/best.pt formatonnx opset12 imgsz320在这里我直接把imgsz设成了320。为什么因为K230的KPU计算资源和内存都有限640x640的输入会让板端推理帧率低到不可接受。320x320是实时性和精度之间的平衡点实测在这个项目里320输入比640输入每帧推理时间短了3倍以上mAP只掉了4个点左右完全够用。导出后的best.onnx可以用onnxruntime做一个快速验证import onnxruntime as ort import numpy as np session ort.InferenceSession(best.onnx) input_name session.get_inputs()[0].name # 构造一个随机输入做前向 x np.random.rand(1, 3, 320, 320).astype(np.float32) outs session.run(None, {input_name: x}) print([o.shape for o in outs])注意看一眼输出层的类型。YOLOv11导出ONNX后默认输出通常是三个不同尺度的特征图shape分别是[1, 84, 40, 40]、[1, 84, 20, 20]、[1, 84, 10, 10]在320x320输入下其中84 4框坐标 80COCO类别 。这个信息在后续板端后处理时会用到。如果你的教程是自定义单类别那么输出通道就是4 类别数。这个细节决定了你的后处理解码代码怎么改建议记下来。3. 部署阶段kmodel转换与K230板端运行3.1 用NNCase把ONNX转成kmodelK230的KPU不直接识别ONNX它需要一种叫作kmodel的格式。嘉楠提供了一套开源工具链NNCase来完成ONNX/TFLite到kmodel的转换。NNCase的安装和版本选择是个容易踩的坑。你要是随便pip install一个nncase很可能会装到PyPI上的老版本而K230官方SDK里的CanMV固件版本对nncase版本有严格要求。在正式搞之前先确认你刷的固件版本对应的nncase版本。我的建议是直接用嘉楠官方GitHub release里的nncase工具链或者安装SDK时顺便装好配套版本。转换命令大致如下不同版本参数可能稍有差异以官方文档为准ncc convert best.onnx -o best.kmodel -i 320 -t int8 --dataset calibration.txt先说关键的几个参数-i 320指定模型输入尺寸。-t int8量化精度。K230上KPU主要支持int8量化FP16和FP32会有额外限制或根本无法加速。--dataset calibration.txt指定校准数据列表文件文件中每行写着用于校准的图片路径。很多人在量化这一步精度崩了就是因为直接把训练集图片扔去校准。校准集不需要太多每个类别覆盖几十张有代表性的图片就够。我从验证集里抽了100张覆盖不同光照和角度基本能满足要求。校准集太大转换时间翻倍太小则统计的激活值范围不准。转换成功的输出会包含best.kmodel同时控制台会打印算子兼容情况。你最好仔细扫一眼日志如果有某个算子被标记为fallback to CPU那它最终会跑到C908上而占用CPU时间影响整条推理链路的速度。3.2 CanMV环境准备与开发板连接CanMV是K230板上跑的MicroPython环境类似OpenMV的思路给开发板提供了摄像头、LCD、KPU、GPIO等模块的Python绑定。好处是迭代快改一行代码跑一下就看到效果非常适合做原型验证。初次使用需要的准备工作是给K230刷入最新的CanMV固件通过k230的烧录工具即可。用USB线连接开发板在设备管理器里确认串口设备号。打开CanMV IDE连接对应的串口端口。按开发板上的复位键IDE中会看到MicroPython交互式提示符。这里有个常被忽略的细节CanMV固件的版本决定了你用的Python API是哪一套。不同版本之间摄像头对象、KPU对象甚至LCD对象的调用方式都可能有差异。为了省心建议用官方最新的CanMV固件并且对应去看该版本自带的示例代码。另外如果你像我一样在Windows上用CanMV IDE板子连接好后先执行一句print(hello)验证链路是通的再继续往下写代码。3.3 推理脚本的编写逻辑K230上跑YOLOv11的推理脚本整体逻辑可以分为五步初始化摄像头、加载kmodel、读取图像帧、执行KPU推理、后处理并显示。先看一个示意性的脚本框架具体API名称以你固件版本的官方例程为准但逻辑是一致的from canmv import canmv # 1. 初始化摄像头和LCD sensor canmv.Sensor() sensor.reset() sensor.set_framesize(320, 320) # 务必与kmodel输入尺寸一致 sensor.set_pixformat(canmv.RGB565) lcd canmv.LCD() lcd.init() # 2. 加载kmodel kmodel canmv.KModel() kmodel.load(best.kmodel) # 3. 循环读帧、推理、显示 while True: img sensor.snapshot() # 转换为KPU输入所需的CHW格式并做归一化 tensor img.to_tensor() # KPU前向推理 results kmodel.forward(tensor) # 后处理解码目标框NMS boxes decode_output(results, conf_thres0.25, iou_thres0.45) # 画框并显示 img.draw_boxes(boxes) lcd.display(img)重点说一下后处理。YOLOv11是Anchor-Free检测头输出三个不同尺度特征图每个特征图上的每个位置都对应一个预测。解码过程大致是对每个尺度的特征图做sigmoid激活得到类别置信度。将置信度高于阈值的位置提取出来。根据特征图的步长stride反算原图坐标。对同类别框做NMS非极大值抑制去重。如果使用ONNX默认导出没有合并输出那么解码代码要自己写。如果你在Ultralytics中开启了nmsTrue导出ONNX会自带NMS算子但这样在NNCase转换时大概率不支持所以还是得老老实实手动解码。我建议先把后处理代码在PC上用onnxruntime跑通把所有输出的张量形状记下来再到板子上调。这样能少掉很多在板上debug的头发。关于帧率实测在320x320输入下K230上YOLOv11n的KPU推理单帧大约在100到200毫秒之间也就是能有5到10FPS。这个速度对于门禁、垃圾桶分类、安防巡检这类场景够用但如果你想跑视频级实时检测还是得用更轻的模型或者进一步压缩输入分辨率。200毫秒一帧意味着每秒大概5帧用来检测静态目标没问题但高速运动目标就吃力了。优化的思路后面单独讲。4. 常见问题与排查技巧实录4.1 转换阶段常见坑算子兼容与版本错位这块是我踩得最深的地方。最开始用opset17导出的ONNXNNCase直接报了一堆Unsupported op。后来把opset降到12基本上就消停了。如果你遇到的是某个特定算子不支持比如某些版本的YOLOv11输出层带DFL反卷积操作可以先检查ONNX里算子名称再确认是不是开了一些复杂导出选项。另一个典型问题--dataset参数里的路径如果写不对转换不会报错但生成的kmodel精度会异常。我遇到过一种情况校准图片全指向了一张损坏图片模型转换完成后在板上几乎什么都检测不到。排查方法也简单先用一小批验证集图片单独跑一次转换如果可复现的精度差那问题往往在校准集而不是模型结构。4.2 推理帧率上不去怎么办帧率上不去先判断瓶颈在哪。最直观的方法是看KPU占用率和CPU占用率。如果KPU占用率高、CPU在NMS和画框阶段卡住就优化后处理和显示逻辑如果CPU空闲但KPU占用也高那就只能从模型侧或输入分辨率入手。优化后处理我做了三件事把CLS数量写死而非动态计算省去反复读数组长度的开销。NMS的实现从Python循环改成直接操作numpy数组的向量化写法在板上能快很多。降低置信度阈值的同时先按置信度排序再NMS减少无谓计算。如果这些做完还不够就直接把输入降到256x256帧率又能明显提升。不过要权衡好小目标的漏检率输入越小小目标越容易消失。4.3 小目标检测的专项优化我在这个项目里最开始遇到的痛点是远处的罐装饮料经常漏检。YOLOv11在大目标上的表现已经不错但小目标仍然是痛点尤其是到K230上为了帧率把输入降到320后小目标只有十几个像素确实难为人。从训练侧我试过这些手段效果从高到低排列提高输入分辨率训练用640训练、320部署虽然会有域差异但比直接320训320效果更好。Mosaic与MixUp数据增强运行时随机拼图增加小目标出现的频率。在数据集中手动裁剪小目标区域做过采样增强让模型对小目标有更多“见过”的机会。从部署侧如果必须要保留小目标检测能力我会建议做“切图推理”把一帧图像分成多个320x320的区块分别送入KPU推理再合并结果。这个方案会牺牲一部分帧率但在某些固定机位场景下其实是可用的折中方案。还有一个细节INT8量化对小目标的影响往往比大目标更明显。因为小目标的特征相对微弱量化误差会把这些弱特征淹没掉。如果量化后小目标掉得特别厉害可以试试在校准数据里多放小目标的图强制量化统计更偏向小目标特征分布。4.4 一个容易被忽视的部署问题串口与日志调试K230的时候CanMV IDE的串口终端是唯一的反馈通道。代码一崩串口会直接打出一堆异常堆栈有时候几屏都看不过来。我的做法是在推理循环的外层包一个try/except异常时把栈信息写到文件中而不是刷在终端里import sys, traceback try: while True: ... except Exception: with open(err.log, w) as f: traceback.print_exc(filef)这个动作在前期调后处理逻辑时经常救我一命。串口输出有时候被IDE刷新很快来不及看写到文件里就能随时翻。5. 一些更广阔的落地可能性模型在K230上跑通之后整个系统的应用想象空间基本就打开了。网上有人用K230做的“激光打蚊子”项目其实本质上就是一个实时目标检测链路加云台控制K230跑一个检测模型识别到画面中的蚊子位置然后把坐标换算成舵机云台的角度驱动激光器执行点射。这类玩法看起来是纯娱乐但背后用的目标检测、坐标换算、外设联动逻辑和工业上的激光除障、自动巡检设备是完全相通的。我做完这个项目后最大的感受是板子的算力其实不是最关键的瓶颈真正决定一个边缘AI设备能不能落地的是你对模型转换链路、后处理逻辑和硬件资源分配的理解有多深。同样是YOLOv11有人只能在PC上跑着玩有人能把它压成500KB左右量化模型在几瓦功耗的开发板上实现实时检测差距就在这些细节里。后续想在这个项目上做的扩展我列了三个方向结合K230的GPIO接口去驱动舵机做一个可以旋转追踪的摄像头云台。把检测结果通过串口发到上位机做统计或者告警面板。尝试用YOLOv11的分割权重yolo11n-seg.pt或姿态权重在K230上看看算子兼容性和精度表现这属于边探索边玩但也算一种学习路径。我个人在实际操作中的体会是从一个训练好的best.pt到一块真能跑起来的K230板子中间真正考验人的不是算法本身而是工程耐力。每一次报错、每一处算子不兼容、每一帧掉落的延迟都是在提醒你对这个系统每一个环节的理解还不够细。这也是做边缘AI部署最迷人的地方——你不是在跑一个现成的库而是在跟一块芯片、一套工具链、一个物理世界里的摄像头打交道。希望这篇记录能帮后来的你少踩几个坑。
