1. 项目概述与技术选型1.1 核心需求解析这个项目的起因其实挺直接的手头有一块嘉楠科技的K230开发板已经在吃灰两个月了。这板子最吸引人的地方在于它是一颗RISC-V内核的AIoT芯片内部集成了KPUKnowledge Processing Unit神经网络加速单元官方标称支持最大4TOPS的算力int8精度。但说实话芯片本身再强没有实际模型跑在上面也是白搭。正好YOLOv11在2024年9月底由Ultralytics团队发布相比YOLOv8最大的变化是引入了C3k2模块和C2PSA注意力机制在小目标检测和遮挡场景下有明显提升。于是我就想干脆把“数据集标注→模型训练→模型转换→开发板部署”这条完整链路走一遍看看到底能跑出什么效果。这一整套流程里最容易被忽视的其实是“模型转换”这一步。很多人在电脑上用PyTorch训练完模型导出个ONNX就觉得大功告成了结果一放到K230上发现要么算子不支持要么精度掉得没法看。所以这个项目我给自己定了几条硬性指标模型必须在K230的KPU上跑int8量化推理不能退化成CPU推理端到端时延控制在80ms以内也就是至少满足12FPS的实时检测需求检测类别以日常生活常见物体为主初期先覆盖5类目标1.2 为什么选择YOLOv11加K230的组合现在做目标检测的方案其实不少YOLOv5、YOLOv8、YOLOv9、YOLOv10都在持续更新但YOLOv11有几个点比较打动我第一是Ultralytics直接把YOLOv11做进了自家的ultralytics框架里这就意味着数据加载、数据增强、训练日志、超参数搜索这些闭环工作流我用一套API就能搞定不用自己在Detectron2和YOLOv5之间来回切换。对于要快速落地的人来说这种“顺手”本身就是巨大的效率红利。第二是YOLOv11的nano版本参数量只有大约2.6M计算量约6.5 GFLOPs。这个体量落到嵌入式端侧非常友好。相比之下YOLOv8n大概是3.2M参数、8.7 GFLOPs。在K230这种算力有限的平台上模型多一倍的GFLOPs实际推理时延可能不止翻一倍因为KPU的算子调度和DMA搬运都有固定开销。再来看K230这颗芯片。它和常见的树莓派、Jetson Nano最大的区别在于它采用了RISC-V双核架构C908其中一个核是1.6GHz的大核专门跑Linux系统另一个高算力核用来做实时计算。KPU部分支持int8和int16两种量化精度还集成了FPU、DSP等指令集扩展。在此基础上嘉楠提供了nncase编译工具链可以把ONNX、TFLite等格式的模型编译成K230专用的kmodel格式整个工具链是开放的。选型时也考虑过用RK3588或Jetson Orin Nano但它们一个是价格偏高另一个是功耗和体积都不适合做便携式AI设备。K230开发板的售价只有同级别开发板的零头而且板载了OV5647摄像头接口、LCD显示屏接口、网口、串口基本就是为视觉AI终端设计的形态非常适合做“训练到部署”的验证平台。1.3 完整技术链路图景在展开具体操作之前我先把这个项目要经过的完整链路画出来方便大家心里有数。整个流程可以拆成四段数据准备阶段采集图像、标注目标框、划分训练集与验证集、做数据增强。模型训练阶段基于ultralytics框架训练YOLOv11模型输出PyTorch权重文件。模型转换阶段将PyTorch权重导出为ONNX再用nncase工具链做算子解析、权重重排、int8量化校准最终生成kmodel格式文件。这一步是能否成功部署的分水岭。板端部署阶段编写K230上的AI推理程序完成KPU初始化、模型加载、输入图像预处理、推理、后处理NMS等、结果叠加显示。我这里把每个阶段的关键产出和可能遇到的问题都列了一个小表格方便后面逐段展开时对照阶段核心输入核心输出主要风险点数据准备原始图片/视频标注好的数据集YOLO格式标注质量不统一、类别不平衡模型训练数据集、预训练权重best.pt权重过拟合、召回率低模型转换best.pt、校准图片best.kmodel算子不支持、量化精度下降板端部署kmodel 摄像头画面实时检测画面帧率不足、内存越界2. 训练环境准备与模型训练实践2.1 硬件配置与软件环境搭建训练YOLOv11本身对硬件的门槛其实不高有NVIDIA独立显卡最好没有的话用CPU硬跑也不是不行只是时间会让人崩溃。我这次用的主力训练机器是i7-12700 RTX 4060 Laptop GPU8GB显存 32GB内存。训练YOLOv11n这个量级的模型batch size设到16imgsz设640显存占用大概在5GB到7GB之间刚好卡在甜点区。如果你的显卡只有6GB显存建议把batch size降到8或者直接把输入分辨率降到416不然很容易碰到CUDA out of memory。软件环境方面我的建议是直接用conda创建独立虚拟环境千万别图省事装在系统Python里否则后面装nncase或者其他工具链时很容易出现依赖冲突conda create -n yolov11 python3.10 conda activate yolov11 pip install ultralytics8.3.0 pip install torch2.1.2 torchvision0.16.2 --index-url https://download.pytorch.org/whl/cu121 pip install opencv-python pip install onnx onnxruntime这里有个细节需要注意ultralytics框架的版本迭代非常快我建议锁定到8.3.x这个版本段后面导出ONNX时踩过的坑少一些。另外就是PyTorch版本和CUDA版本要匹配如果你用的显卡是40系CUDA 12.1的预编译包用起来最省心。2.2 数据集采集与标注规范数据集的质量直接决定了模型的上限。我在这个项目里选择的是“日常桌面物体检测”定义了5个类别手机、遥控器、水杯、剪刀和书本。选择这5类的原因是它们形状相对规整而且在家居场景里很常见方便后面做实时演示。数据采集阶段我用手机拍摄了大约800张照片每张照片里包含1到5个目标物体覆盖不同角度、不同光照条件、不同遮挡程度。这个数量对于YOLOv11n这种小模型来说属于“勉强够用”的水平如果后面发现某些类别召回率偏低就针对这个类别补采数据。标注工具我推荐用LabelImg或者X-AnyLabeling。LabelImg比较老牌操作简单直接画矩形框保存为YOLO格式的txt文件。X-AnyLabeling则是新一代工具支持半自动标注可以先用一个预训练模型自动打标签然后人工修正效率会高很多尤其适合数据量大的场景。标注时有个很容易踩的坑LabelImg默认保存的是Pascal VOC格式的xml需要在保存时手动切换成YOLO格式否则后面训练时还得写脚本转换。YOLO格式的标注文件长这样class_id center_x center_y width height注意这些坐标全部是归一化到0到1之间的小数不是像素坐标。比如一张640x480的图片里目标框左上角在(160, 120)、右下角在(480, 360)那么标注内容就是0 0.5 0.5 0.5 0.5。我在标注初期就因为这个归一化问题出过错一张图上所有目标框都标飞了后来仔细看了文件才发现是坐标格式搞错了。标注完成后需要把数据集按比例切分为训练集和验证集。我这里的划分比例是8:1:1即80%训练、10%验证、10%测试。ultralytics框架要求的数据集目录结构如下datasets/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yamldata.yaml的内容比较简单但有一个点特别容易忽略就是nc类别数和names类别名称必须和标注文件里的class_id一一对应。class_id从0开始编号顺序错了模型训练出来就是乱套的。train: datasets/images/train val: datasets/images/val nc: 5 names: [phone, remote, cup, scissors, book]2.3 YOLOv11训练参数详解ultralytics框架把训练入口做得非常简单核心就一行命令yolo detect train datadatasets/data.yaml modelyolov11n.pt epochs200 imgsz640 batch16 patience40 optimizerAdamW lr00.001但参数简单不代表可以直接照抄默认值。实际操作中我重点调整了以下几个参数这里逐个说明modelyolov11n.pt选择预训练权重。YOLOv11有n、s、m、l、x五个尺寸n版最轻量适合端侧部署。用预训练权重做初始化可以让模型收敛更快特别是数据集规模不算大的时候效果非常明显。epochs200训练轮数。YOLOv11在小数据集上一般100轮到200轮就能收敛。设置200轮是为了留足余量配合早停机制patience40如果连续40轮验证集指标没有提升训练会自动停止不用担心过拟合。imgsz640训练输入分辨率。640是精度和速度的平衡点。如果你更关注小目标检测效果可以试试768甚至896但注意K230的KPU对输入分辨率有对齐要求后面部署阶段就要把分辨率固定下来训练和部署的输入尺寸最好保持一致。optimizerAdamW lr00.001YOLOv11默认的优化器其实是从SGD开始学但如果换用AdamW收敛速度会更快。尤其是batch size比较小的时候AdamW对学习率的敏感度更低不容易因为lr设置不当直接训飞。batch16这个参数受显存限制最大。RTX 4060 Laptop 8GB显存跑yolov11n640batch16已经是极限了。如果显存不够优先降低batch而不是降低imgsz因为降低imgsz会影响小目标检测精度。训练过程中终端每一轮都会打印训练损失、验证损失、mAP50、mAP50-95等指标。我重点盯mAP50和mAP50-95前者衡量粗定位准确率后者是更严格的评价标准。当mAP50-95的增速明显放缓并且连续20轮没有提升基本就是模型容量已经到极限了再训下去只会过拟合。3. 模型转换从PyTorch到kmodel的完整链路3.1 模型导出为ONNX格式训练完成之后best.pt保存在runs/detect/train/weights/目录下。接下来第一件事是把它导出为ONNX格式。在导出之前我强烈建议先在验证集上测试一下模型效果用以下命令直接跑模型推理yolo detect predict modelruns/detect/train/weights/best.pt sourcedatasets/images/val saveTrue这一步是为了确认模型本身没有问题。如果你发现图表里目标框位置正确、置信度正常就可以进入模型转换环节了。ONNX导出同样可以用ultralytics框架的一行命令完成yolo export modelruns/detect/train/weights/best.pt formatonnx opset12 imgsz640这里有几个参数需要特别说明。首先是opset12。nncase对较新的opset支持有限我自己实测过opset 12是目前兼容性最好的选择opset 13以上某些算子比如一些变形类操作在nncase里会直接报错。其次是imgsz640。这个参数必须和训练时保持一致否则模型里的anchor计算和特征图尺寸都会对不上导出后性能会大幅下降。如果你训练时用的是416导出时也必须是416。最后导出完成后用onnxruntime做一个快速验证确保ONNX模型的推理结果和PyTorch模型一致。注意输入图像的预处理要和训练保持一致BGR转RGB、归一化到0-1、resize到640x640。import cv2 import numpy as np import onnxruntime as ort session ort.InferenceSession(best.onnx, providers[CPUExecutionProvider]) img cv2.imread(test.jpg) img cv2.cvtColor(img, cv2.COLOR_BGR2RGB) img cv2.resize(img, (640, 640)) img img.astype(np.float32) / 255.0 input_tensor np.transpose(img, (2, 0, 1))[None, ...] outputs session.run(None, {session.get_inputs()[0].name: input_tensor}) print(outputs[0].shape)正常的话输出shape是(1, 7, 8400)代表8400个候选框每个候选框有7个值类别数5 box坐标4YOLOv11的最终输出已经去掉了objectness分支。3.2 nncase工具链安装与模型编译nncase是嘉楠开源的神经网络编译器专门用于把ONNX/TFLite模型编译成K230能运行的kmodel格式。安装方式有两种一种是直接pip安装预编译包另一种是用官方提供的Docker镜像。我推荐直接用pip省事pip install nncase2.9.0 pip install nncase-kpu2.9.0这里有个非常关键的点nncase的版本必须和K230开发板上的运行时库版本严格对应。如果开发板固件里的kpu驱动是2.9.x但你电脑上编译模型用的nncase是2.8.x那加载kmodel时大概率会报版本不匹配的错误。最稳妥的办法是去嘉楠官方文档页面确认当前固件推荐使用的nncase版本号再执行安装。编译kmodel的脚本其实不复杂核心过程是先加载ONNX模型再设置量化方案最后编译导出。下面是我的编译脚本关键代码import nncase target k230 onnx_model best.onnx kmodel_path best.kmodel compile_options nncase.CompileOptions() compile_options.target target compile_options.input_type float32 compile_options.output_type float32 compile_options.preprocess False compiler nncase.Compiler(compile_options) with open(onnx_model, rb) as f: model_content f.read() compiler.import_onnx(model_content) compiler.compile() kmodel compiler.gencode() with open(kmodel_path, wb) as f: f.write(kmodel)这个脚本有两个地方需要展开说明。第一是preprocess参数。如果编译时设置preprocessTrue框架会在KPU推理时自动完成图像预处理缩放、减均值、乘scale这样上位机代码就不用手动做这些操作了。但我在实际项目中推荐设置preprocessFalse原因有两个一是KPU的预处理支持有限有些归一化参数配置不对反而会导致精度下降二是预处理放到CPU上做虽然多了一点负担但调试方便出现结果异常时更容易定位问题。第二是量化方案。上面的代码看起来没有显式指定量化设置这不代表不需要量化校准。YOLOv11默认输出是float32如果要转换为int8量化模型必须提供一组校准图片让nncase统计激活值的分布范围计算出合适的量化scale。如果直接不指定量化方案编译那生成的kmodel是float32精度的KPU无法加速只能跑在CPU上性能完全不可用。正确的姿势是这样import nncase target k230 onnx_model best.onnx kmodel_path best_quant.kmodel compile_options nncase.CompileOptions() compile_options.target target compile_options.input_type float32 compile_options.output_type float32 # cpu only mode compile_options.use_mse_quant_w 0 compile_options.use_mse_quant_a 0 # calibration data calib_data [] for img_path in calib_image_paths: img cv2.imread(img_path) img cv2.resize(img, (640, 640)) img img.astype(np.float32) / 255.0 img np.transpose(img, (2, 0, 1)) calib_data.append(img) calib_dataset nncase.CalibDataset([np.stack(calib_data)]) compile_options.calibrate_data calib_dataset校准图片建议从训练集里选300张左右覆盖各个类别和不同光照场景。图片太少会导致量化参数不准确精度损失明显图片太多则校准时间成倍增加但精度提升有限。300张是我试过比较均衡的数量。3.3 算子兼容性与量化精度掉点排查做完初步编译后我遇到的一个典型问题是YOLOv11的某些算子nncase不支持编译直接报错。这时没法在项目里大量展开但可以给出排查思路。遇到这类问题我的处理清单是这样的1. 查看报错信息中的算子名称。nncase报错一般会明确指出是哪个op无法映射到KPU指令比如op not supported: resize。2. 回退到修改模型导出的方式。对于YOLOv11最常见的麻烦是后处理部分自带了很多transpose、sigmoid、split之类的操作。一个有效的做法是在导出时把后处理Operations从模型里剥离只保留Backbone和Neck部分后处理放到部署代码里用CPU实现。这样模型小了很多算子兼容性问题也大幅减少。3. 如果某个op因为精度问题被nncase降级到float32执行导致KPU利用率上不去可以尝试把该op的输入量化方案改为16位或者干脆重新设计这个模块。精度掉点是另外一个高频问题。我在这个项目里首次做int8量化后mAP50从FP32的88.2%掉到了81.6%掉点接近7个百分点这个幅度已经很难接受了。排查下来主要有三个原因校准图片数量太少只用了100张、训练时没有做Mosaic增强后的“伪量化”模拟、某个通道的计算敏感度较高。针对量化掉点我调整了校准策略并增加到了300张图使用MSE作为量化误差度量指标让nncase自动搜索每种激活值分布下最优的量化scale。调整之后量化精度回到了85.3%这个损失幅度在端侧部署中是可以接受的。提示如果量化掉点一直在3个百分点以上建议检查训练阶段是否开启了AMP混合精度训练。如果用了AMP模型权重里某些层的激活值分布可能和正常训练差别较大量化时更容易产生误差。实在不行就回到FP32训练再量化一次试试。4. K230开发板上的部署与推理优化4.1 开发环境准备与镜像烧录K230开发板本身自带一套基于Buildroot的Linux系统官方也提供了CanMV开发环境基于MicroPython和LiberAI基于C/C的AI SDK。我个人推荐使用CanMV来做快速验证它的Python API封装了摄像头采集、KPU推理和显示输出的常用功能上手难度低很多。烧录固件的步骤很常规用官方提供的烧录工具把镜像写入Micro SD卡插入开发板连接串口线和LCD屏幕上电启动。第一次上电后通过串口终端进入系统命令行。这里我提一个非常容易踩的坑K230开发板默认的串口波特率是115200一定要设置对否则串口终端里全是一堆乱码。系统起来之后验证一下AI环境是否正常from libs.PipeLine import PipeLine from libs.AIBase import AIBase from libs.AI2D import Ai2D print(AI libraries loaded successfully)如果上述导入没有报错说明CanMV环境已经正常工作可以开始写推理代码了。4.2 KPU推理代码实战在K230上部署YOLOv11模型整体代码结构分为四步初始化摄像头和KPU、加载kmodel并做预处理、执行推理并做后处理、显示结果。下面是一个精简版的推理主循环代码。这里的重点不在完整代码而在几个关键的调用逻辑上from libs.PipeLine import PipeLine from libs.AIBase import AIBase import numpy as np import ulab.numpy as np_small class YOLOv11Detector(AIBase): def __init__(self, kmodel_path, labels, input_size640, conf_thres0.25, nms_thres0.45): super().__init__(kmodel_path) self.labels labels self.input_size input_size self.conf_thres conf_thres self.nms_thres nms_thres def preprocess(self, img): # 维持宽高比做resize其余区域padding减少图像畸变对检测效果的影响 h, w img.shape[:2] scale min(self.input_size / w, self.input_size / h) new_w, new_h int(w * scale), int(h * scale) resized cv2.resize(img, (new_w, new_h)) canvas np.zeros((self.input_size, self.input_size, 3), dtypenp.uint8) canvas[:new_h, :new_w] resized return canvas def postprocess(self, outputs): predictions outputs[0] # shape: (1, 7, 8400) # 转置为 (8400, 7)解析每个候选框的类别和坐标 # 过滤低置信度框 # 执行NMS非极大值抑制 boxes [] scores [] class_ids [] for pred in predictions: score float(pred[4]) if len(pred) 4 else float(np.max(pred[5:])) class_id int(np.argmax(pred[5:])) if len(pred) 5 else 0 if score self.conf_thres: continue cx, cy, bw, bh pred[:4] x1 cx - bw / 2 y1 cy - bh / 2 x2 cx bw / 2 y2 cy bh / 2 boxes.append((x1, y1, x2, y2, score, class_id)) # 用简单NMS过滤重复框 return self.nms(boxes) def nms(self, boxes): # 按置信度排序逐个计算IoU超过阈值则抑制 ...这段代码里关键点在preprocess。很多人在部署时会用cv2.resize直接粗暴地把图像拉成640x640这样做会破坏原始宽高比导致目标框位置发生偏移尤其是形状比较窄长的物体比如遥控器、剪刀受影响最大。我改成“等比缩放灰色填充”后检测稳定性好了很多。推理本身通过self.run()CanMV里封装好的KPU推理方法完成返回的是原始模型输出。后处理阶段的NMS我建议先在PC上用Python实现验证没问题后再移植到CanMV的MicroPython环境里。注意CanMV环境有两个numpy库一个是纯Python的numpy功能全但速度慢一个是ulab.numpy内存占用小但部分API不兼容。在后处理中尽量用基础list和循环操作避免复杂的向量化运算否则在MicroPython下性能会很差。4.3 摄像头实时检测与显示输出摄像头实时检测相对简单用CanMV的PipeLine和摄像头驱动即可。上电后摄像头出图的时序是最容易出问题的环节——屏幕会短暂黑屏或卡顿原因是ISP图像信号处理器需要初始化时间。代码里必须在主循环前加一小段延时等待让ISP稳定输出。sensor_id 0 # 使用板载摄像头OV5647 sensor Sensor() sensor.reset() sensor.set_framesize(width640, height640) sensor.set_pixformat(RGB888) sensor.run() app YOLOv11Detector(kmodel_pathbest_quant.kmodel, labelslabels) while True: img sensor.snapshot() result app.run(img) for box in result: x1, y1, x2, y2, score, class_id box cv2.rectangle(img, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.putText(img, f{labels[class_id]} {score:.2f}, (x1, y1 - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 255, 0), 2) lcd.display(img)这段代码跑起来之后我实测的帧率大概在11到15FPS左右。这个性能对于实时检测演示来说勉强够用但如果要用于实际项目还有很大的优化空间。注意如果LCD屏幕显示的画面出现颜色异常很可能是摄像头输出的色度格式不对。确认set_pixformat(RGB888)是否正确配置。部分固件默认输出YUV422需要用sensor.set_framesize和set_pixformat一起配置才能切换成RGB输出。4.4 帧率优化三板斧部署完成后我在K230上做了一轮性能调优主要从三个维度入手1. CPU侧预处理优化。把图像从BGR转RGB的步骤去掉因为K230的摄像头驱动可以直接输出RGB格式。如果实在要转直接跳过CvtColor直接操作指点数据减少一次内存拷贝。在Embedded设备上内存拷贝的耗时往往比计算本身还高。2. KPU推理输入分辨率对齐。KPU内部对Feature Map有对齐要求不是任意的640x640都能高效跑。实测发现输入分辨率如果能被64整除KPU的DMA搬运效率会明显提升。所以训练和转换时分辨率尽量选择像512、576、640这种64的整倍数。3. 后处理算法裁剪。YOLOv11的输出有8400个候选框对每个框都做完整的解析和NMS是很耗CPU时间的。可以提前根据置信度做一次粗过滤只保留置信度topk比如100个的候选框再进行完整解析和NMS。把候选框数量从8400降到100后处理时间能从30ms降到8ms左右。5. 项目实战调整与避坑实录5.1 数据增强和过拟合的实战调整我在这个项目里初期用默认增强配置训练发现验证集mAP50在epoch 80左右开始停滞但训练集loss还在继续下降这是非常典型的过拟合信号。YOLOv11内置了很多增强策略包括Mosaic、MixUp、HSV变换、随机翻转、缩放等。在数据集比较小比如我这种只有800张图的的情况下我建议适当增强Mosaic和MixUp的强度同时打开Close Mosaic Last 10 Epochs的功能ultralytics框架会自动在训练最后10轮关闭Mosaic增强避免过度增强导致模型学不到真实分布。另外一个小技巧是调整类别权重。我的数据集里手机和水杯的样本数量明显多于剪刀和书本如果不做任何处理模型训练出来对剪刀的召回率会比较低。ultralytics框架里可以通过cls参数设置分类损失的权重给稀有类别更高的loss权重我设置了cls1.2实测下来剪刀类的召回率从78%提升到了85%左右。5.2 常见问题排查速查表我整理了一下这个项目从训练到部署整个过程中最容易踩的坑做成一个速查表方便大家直接对照。问题现象可能原因排查/解决方法训练时loss为nan学习率过大或者数据里有异常标注降低lr0到0.0005检查数据集中是否有全黑图片mAP很高但实际检测不准训练和部署时图像预处理不一致统一缩放方式和归一化参数部署前用同一张测试图对比PyTorch和K230输出kmodel加载失败nncase版本和固件不匹配核对官方文档中固件对应的nncase版本号重新编译检测框整体偏移resize时没有保持宽高比改用等比缩放padding方式填充推理时系统卡死内存分配过大或kmodel超过KPU内存限制查看kmodel文件大小确保不超过板端可用KPU内存摄像头画面偏绿/偏紫色度格式配置错误检查摄像头输出格式是否为RGB888排除YUV转换问题画面上没有检测框类别ID对应错误或置信度阈值过高打印输出shape和前几个预测值确认tensor布局是否匹配预期5.3 模型替换和持续迭代模型部署上线之后训练数据还会持续增加这就需要对模型做迭代更新。我这边总结出一套比较顺手的迭代流程在开发板上跑一段时间把检测错误的画面保存下来sensor.snapshot()后存到SD卡即可作为难例数据沉淀。每周将难例数据补充到数据集中重新训练模型。用新的best.pt导出ONNX再编译成kmodel替换到开发板上。对比新旧kmodel在相同测试视频上的检测效果记录mAP和漏检率变化。在训练过程中我发现很多同学在部署阶段忽略了kmodel校验这个环节——即模型转换完成之后至少要在开发板上用一张固定图片去验证输出结果和ONNX是否一致。如果这一步不做后面出现的各种问题很难区分是模型转换的问题还是后处理的问题。这一步调试建议在开发板上写一个最小测试脚本只加载kmodel跑一张静态图然后把结果输出到串口和PC端onnxruntime的结果做对比。6. 应用场景延伸与后续优化思考6.1 从实验原型到实际落地的距离K230上跑通YOLOv11只是第一步真正把模型变成产品级的功能还有不少工作要做。功耗方面K230在做纯AI推理时功耗非常低如果不需要LCD显示和复杂交互整板功耗可以控制在1.5W以内这是RISC-V架构硬件和KPU设计带来的优势。所以它很适合做电池供电的小型AI视觉设备。通信方面我后期给开发板加上了串口通信模块把检测结果以JSON格式检测到的目标类别、数量、位置坐标发送给上位机距离远一点就用WiFi模块接入局域网方便和其他设备联动。6.2 模型结构优化与蒸馏尝试YOLOv11n本身已经是极轻量级的模型了但要跑在更小的硬件上或者追求更高的帧率还有几个方向可以尝试一是结构剪枝。YOLOv11的C3k2模块和C2PSA模块里有大量卷积核用nncase编译时已经做了一定的优化但还有进一步压缩空间。二是知识蒸馏。用一个YOLOv11m或者YOLOv11l模型作为教师模型蒸馏到YOLOv11n上。通过蒸馏训练学生模型在小目标检测上往往能获得额外2到3个百分点的提升这个提升对端侧部署尤其有价值。三是自动超参数搜索。ultralytics框架内置了基于遗传算法的超参数搜索功能跑上一整夜可以自动调整学习率、权重衰减、类别损失等超参数组合找到更优的训练配置。对于追求极致效果的项目值得一试。6.3 小目标优化的专项探讨最近很多做工业质检和安防监控的人都在问YOLOv11小目标优化的问题。我在这个项目里也遇到类似情况摄像头离目标稍远一点目标像素不足32x32检测效果就开始明显下滑。提升小目标检测有几个经过实践验证的办法提高输入分辨率从640提升到960甚至1280小目标在特征图上的尺寸变大了特征能保留更多信息。代价是推理时间增加在K230上可能需要考虑KPU的负载能力。使用SAHI切片推理把大图切分成多个小图分别送入模型检测再合并结果。这种方式能大幅提升小目标召回率但会成倍增加推理次数实时性会受影响。增加高分辨率小目标数据训练时用Copy-Paste增强把小目标物体随机粘贴到不同背景中人为增加小目标样本的数量。我在K230上尝试了提高输入分辨率到768帧率略微下降到约10FPS但小目标检测效果稳定了不少。如果你的应用场景是小目标为主这个取舍是值得的。7. 项目复盘与一些掏心窝的话整个项目从训练到最终部署我前后花了大概两周时间其中至少一半时间花在模型转换踩坑和调试后处理代码上。如果让我重新做一遍我会在项目一开始就做三件事第一先把K230开发板的环境调通用官方自带的demo模型跑一遍推理确认摄像头、LCD、Sd卡、串口这些硬件链路都是好的避免训练完成之后才发现板子适应不了环境。第二训练之前先手动检查至少100张标注文件的坐标是否准确尤其是归一化坐标有没有超出0到1的范围。很多人训练了几天发现效果不对最终发现是标注文件有大量的坐标越界或者类别ID对不上。第三在训练阶段就按照部署阶段的分辨率和量化要求来做约束。也就是说训练时就固定使用640分辨率导出ONNX时也使用640校准量化时也使用640最后部署时也使用640。这里的逻辑很统一模拟一个真实的产品管线尽量减少“最后一公里”的意外。最后再分享一个小技巧这是我踩过好几次坑后才养成的习惯在K230上做调试时把摄像头采集到的原始图像和检测结果叠加图同时通过SD卡保存下来。这样做的好处是当检测效果不理想时你可以回放当时的原始画面判断是模型本身的问题还是KPU推理输出的问题还是后处理逻辑的问题不至于每次都要靠脑筋去回忆当时摄像头前到底放了什么物体。这个习惯帮我省了很多无用功。说回这个项目本身K230加YOLOv11的组合让我看到了轻量端侧AI的可行性。只要工具链顺了从训练到部署的链路并不复杂复杂的是你对每一个环节的理解深浅。希望这篇文章能帮你少走一些弯路也期待看到你用K230做出更有意思的落地应用。