做视觉任务这些年YOLOv11给我的最大感触是它已经不只是一个检测器了。很多人一提到YOLOv11第一反应就是画框、出坐标但官方生态里其实同时提供了检测、分割、姿态估计、旋转框、分类五大任务。最近我在做一个“道路场景多任务分析”的小项目用同一套YOLOv11推理框架在视频流里同时拿目标框、实例掩码和人体关键点跑通之后体验完全不一样。这篇博文把分割和姿态估计的实战经验整理出来聊聊怎么让一个模型真正“干三件事”同时把环境、参数、可视化、避坑技巧都交代清楚。适合正在做目标检测、实例分割、姿态估计落地的开发者参考。1. 内容整体设计与思路拆解1.1 YOLOv11任务体系与多任务怎么理解先明确一个概念。YOLOv11不是只有一个模型文件而是一整套模型家族。按任务划分检测模型输出边界框和类别分割模型输出边界框加像素级掩码姿态模型输出边界框加关键点另外还有旋转目标检测和图像分类的版本。从文件名就能看出差别同样是最小尺寸有普通检测权重、带seg后缀的分割权重、带pose后缀的姿态权重后缀直接标识任务类型。所以“1个模型干3件事”在工程上要分两层理解。严格来说官方没有发布一个权重文件同时输出框、掩码和关键点但在实际部署中你可以把分割模型和姿态模型组合起来形成一个统一的多任务推理器。而且有个容易被忽略的点分割模型本身就是“检测分割”两个任务的二合一它同时输出边界框和实例掩码。也就是说只要一个分割模型负责检测和分割再拿一个姿态模型负责关键点两个模型就能覆盖“检测、分割、姿态估计”三件事。听起来比“一个模型”多一点但当你把它们封装在同一个推理类里外部看就是统一接口输入同一帧图像输出同一个包含框、掩码、关键点的数据结构。对业务代码来说它就是“一个模型干了三件事”。我把这个思路叫“统一多任务推理器”实战的核心就是把它搭出来。1.2 方案选型串行、并行还是共享骨干做多任务时通常有三条路线。第一条是串行调用。每帧图像先跑分割模型再跑姿态模型后处理各自独立。优点是实现最简单缺点是延迟叠加视频场景下帧率明显下降。第二条是并行调用。分割模型和姿态模型放在两个线程或两条CUDA流里各自推理同一帧最后合并结果。优点是速度比串行快不少缺点是显存占用增加还需要处理线程同步和结果对齐工程复杂度上升。第三条是自定义多任务头。把YOLOv11的backbone当共享特征提取器在neck之后挂上检测头、分割头和姿态头自己训练一个权重。最贴合“一个模型”的字面意义推理延迟最低但数据准备复杂、训练成本高普通业务里性价比不高。我个人的实践建议是离线图片处理用串行实时视频流用并行长期做算法迭代的团队再考虑共享骨干。这篇博文的代码示例会基于“统一多任务推理器 并行模型”的思路展开兼顾速度和可复现性。路线速度工程复杂度适用场景串行调用较慢低离线图片、批量任务并行调用较快中实时视频流共享骨干最快高长期算法团队2. 工具准备与环境搭建2.1 环境依赖与安装避坑YOLOv11官方生态的安装比较省心但我依然建议在项目目录里建一个虚拟环境避免和系统Python混在一起。Python版本选3.9到3.10比较稳妥PyTorch按显卡驱动安装对应的CUDA版本。这里最容易踩的坑是PyTorch的CUDA版本和显卡驱动不匹配代码能加载模型但一跑GPU推理就报错或直接回退CPU速度掉到没法看。我实际用的环境是Python 3.10、PyTorch 2.1、CUDA 11.8。安装时先激活虚拟环境再单独装PyTorch最后装YOLOv11官方库。如果只做推理不训练依赖很轻核心是torch、torchvision、opencv-python、pillow、numpy。官方库会自动处理大部分依赖不用手动把包列全。验证环境是否正常的标准很简单下载一个最小的检测权重跑一帧官方自带样例图能正常打印出类别和坐标就算成功。不要一上来就装最大尺寸的模型环境有问题的时候先跑通小模型定位问题要快得多。2.2 权重下载与任务确认权重会自动从网络下载到本地缓存目录。分割模型的权重比纯检测大一些因为多了掩码分支姿态模型的权重更小。为了验证拿到的权重有没有拿错加载模型之后可以打印任务的标识属性它会明确返回detect、segment或pose。这里整理了一张选型表按实际场景决定用哪个模型模型文件任务能力典型用途显存参考最小检测权重检测框快速目标定位约1GB以内最小分割权重检测框 实例掩码目标定位像素级分割约2GB以内最小姿态权重检测框 人体关键点姿态估计约2GB以内中等分割权重高精度检测分割精度优先场景约4GB以内表格里的显存是batch size等于1、640分辨率下的参考值。实际项目做并行推理时两个模型加起来显存会明显上涨这时候优先考虑半精度推理或者换更小的模型版本。3. 核心细节解析与实操要点3.1 检测分割一个模型出两类结果先把分割模型跑通。加载方式和检测几乎一样核心变化在results对象上。拿到results之后results.boxes里是检测头输出的坐标、置信度和类别results.masks里是分割头输出的掩码。掩码有两种常用表示masks.data是张量形状是(N, H, W)取值0到1可以直接当单通道图用masks.xy是每个实例掩码的多边形点坐标画图时更方便。分割模型最方便的一点是它天然把检测和分割对齐了。检测框的索引和掩码的索引一一对应同一个实例在boxes里的第几个位置在masks里就是第几个位置。不用额外做匹配代码负担小很多。实操时有个细节要特别留意如果原图不是正方形直接resize到640再推理检测框和掩码坐标在缩放后的图像坐标系里画回原图前必须按缩放比例还原。这个点后面单独讲。基础分割推理代码长这样# 导入方式按你本机安装的官方库调整下面统一用示意写法 from yolo import YOLO model YOLO(yolo11n-seg.pt) results model(road.jpg, tasksegment)[0] for i in range(len(results.boxes)): cls int(results.boxes.cls[i]) conf float(results.boxes.conf[i]) xyxy results.boxes.xyxy[i].tolist() mask results.masks.data[i].cpu().numpy() print(cls, conf, xyxy, mask.shape)提示mask的尺寸是模型输入尺寸的分辨率画到原图前要做resize处理。测试时先拿一张目标边界清晰的图片确认掩码轮廓没有整体偏移再进入下一步。3.2 姿态估计关键点输出格式解读姿态模型的任务输出是检测框加17个关键点顺序遵循COCO格式。从0到16分别是鼻子、左右眼、左右耳、左右肩、左右肘、左右腕、左右髋、左右膝、左右踝。如果只用官方自带绘图接口这个顺序不用死记但一旦要自己做后处理比如算跌倒角度、计算肢体比例就必须知道每个索引的含义。关键点数据在results.keypoints里。keypoints.data的形状是(N, 17, 3)N是检测到的人数第三维分别是x坐标、y坐标和置信度。这里有个很常见的坑新手看到第三维以为是xyz三维坐标实际最后一位是可见度置信度不是深度信息。置信度低于阈值的关键点通常被认为不可靠或者被遮挡业务上要单独处理。关键点画到原图上并绘制骨架连线可以参考这段代码from yolo import YOLO import numpy as np model YOLO(yolo11n-pose.pt) results model(person.jpg, taskpose)[0] skeleton [ (0, 1), (0, 2), (1, 3), (2, 4), (5, 6), (5, 7), (7, 9), (6, 8), (6, 10), (5, 11), (11, 13), (13, 15), (6, 12), (12, 14), (14, 16) ] for person in results.keypoints.data: kpt person.cpu().numpy() visible kpt[:, 2] 0.5 for start, end in skeleton: if visible[start] and visible[end]: x1, y1 kpt[start, :2] x2, y2 kpt[end, :2] # 在这里用 cv2.line 画线段骨架连线是常用的COCO 17点连接关系。姿态模型对密集人群的漏检率比纯检测高因为相互遮挡时关键点回归很吃力。实测下来两人靠很近时一个姿态模型经常只输出一到两个实例这种场景建议把检测框置信度阈值调低同时提高关键点置信度阈值减少骨架上乱飞的连线。3.3 三合一输出统一数据结构与可视化既然分割模型能出框和掩码姿态模型能出框和关键点合并的关键是设计稳定的统一数据结构。我的做法是定义一个包含三部分的字典detections只存检测框和类别segmentation存掩码keypoints存关键点。推理函数统一输入一帧图片统一输出这个字典外部业务代码完全不用关心内部是两个模型还是三个模型。合并可视化同样有讲究。三部分都画在同一张图上时顺序建议是先画掩码再画检测框最后画关键点和骨架。掩码是区域填充画太晚会把框和关键点盖住检测框居中关键点和骨架在最上层因为姿态判断最依赖视觉直觉。各层用独立颜色掩码半透明填充检测框实线关键点圆点一帧画面里三种任务的结果一眼就能分清。需要注意分割模型和姿态模型各自出的检测框并不完全一致。两个模型结构不同同一目标的框可能有一两个像素的偏差。业务里如果需要用姿态的框直接取姿态模型自己的boxes如果需要用分割的框就取分割模型自己的boxes不要混用。统一数据结构里我把两者分开存就是避免这种混淆。import cv2 class MultiTaskYOLO: def __init__(self, seg_path, pose_path): self.seg_model YOLO(seg_path) self.pose_model YOLO(pose_path) def predict(self, img): seg self.seg_model(img, tasksegment)[0] pose self.pose_model(img, taskpose)[0] return { boxes: seg.boxes, masks: seg.masks, keypoints: pose.keypoints, pose_boxes: pose.boxes, }这个类只是框架原型实际项目里要加线程同步和坐标映射。核心思路到这里已经清楚了对外是一个统一接口对内是分工明确的两个模型。调用方视角就是“一个模型干三件事”。4. 实操过程与核心环节实现4.1 端到端流程视频流三任务实时分析把上面的类扩展到视频流处理整个流程分四步读取视频帧、统一做letterbox预处理、分模型推理、合并后处理与可视化。注意视频流输入帧尺寸不固定必须在模型推理前做标准化否则拖到后处理阶段再处理坐标计算量会翻倍而且容易错位。letterbox是整个流程里的隐藏关键点。YOLO类模型的输入都是正方形原图几乎不会是正方形直接resize会把物体拉变形导致检测框和掩码不准确。letterbox的做法是把原图按比例缩放到目标尺寸以内剩余区域用灰色填充既保持比例不变也让全图内容进入模型视野。推理完成后再根据letterbox的填充参数把坐标反向映射回原图坐标系。处理管道里比较标准的主函数骨架我精简掉了线程和队列方便先跑通逻辑def process_video(video_path, multitask_model): cap cv2.VideoCapture(video_path) while cap.isOpened(): ret, frame cap.read() if not ret: break result multitask_model.predict(frame) vis multitask_model.draw(frame, result) cv2.imshow(multi-task, vis) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()实测过的参数组合n尺寸分割模型和n尺寸姿态模型并行输入640在消费级显卡上能稳住25帧左右换成s尺寸大约15到20帧m尺寸基本掉到10帧附近。这是单模型推理的大致水平。并行推理时两个模型同时占用GPU帧率还会再打折。做实时视频别迷信大模型n尺寸往往是更优选。这个数字和你的显卡算力有关系但差异不会太大可以按这个基准去调模型尺寸。4.2 letterbox坐标映射与还原细节坐标映射是分割和姿态实战里出bug最多的地方。letterbox步骤是计算原图长边和短边到目标尺寸的缩放比例取最小比例保证全图放得下然后用这个比例把原图缩放到新尺寸最后把缩放后的图放置到目标尺寸的画布中央。推理得到的所有坐标都基于这个画布还原时要先减去填充偏移量再除以缩放比例得到原图坐标。横向图片会在上下方向留灰边纵向图片会在左右方向留灰边。就算检测框和关键点在画布坐标下非常准确如果还原公式写错画面上的关键点会整体往一个方向偏。排查这类问题时最常用的方法是取一个静态画面同时画出推理结果和原图叠加再把掩码透明度调高肉眼直接看掩码轮廓是否贴住物体边缘。掩码偏了但框是准的说明掩码的缩放逻辑有问题框和掩码都偏同一个方向基本就是letterbox偏移量算错了。注意建议把letterbox和还原逻辑封装成两个函数不做成inline代码。分割模型、姿态模型、可视化模块都要共用同一套坐标变换每个模块各写一遍迟早会出现一个模块还原正确、另一个模块没有还原的情况。4.3 用半精度和ONNX进一步提速如果实时性不够第一步先试试半精度推理。模型参数转成fp16显存能省不少速度也有提升代价是精度略有下降。对大部分检测、分割、姿态任务来说这个下降幅度肉眼几乎看不出来。消费级显卡上半精度是性价比最高的优化手段。第二步才是导出ONNX模型。导出后可以脱离推理库运行适合嵌入生产环境尤其是不想装整套Python库的场景。导出时要注意检测模型和分割模型输出张量结构不同分割输出会比检测多一维掩码数据姿态模型会在最后带上关键点坐标和置信度。用的时候按对应后处理方式解析不能套同一个模板。如果项目对延迟极度敏感建议再考虑TensorRT引擎优化。但TensorRT的产物和显卡型号绑定不同卡不通用对新手调试成本不小。我的建议是先把半精度和ONNX跑通帧率不够再上TensorRT。5. 常见问题与排查技巧实录5.1 三任务不同步或结果错位并行推理时最常见的坑是分割模型和姿态模型在同一帧上各跑各的结果合并后错位。表象是检测框对应的目标到了姿态图上却变成了另一个人。根因是线程没有同步帧索引。我一次排查了很久才发现是线程里没用队列模型读到了不同帧。解决方法是给每个模型配一个帧队列主线程往队列里放帧推理线程从队列里取帧并把模型名称和帧序号一并返回。合并时以帧序号为对齐键宁可丢弃落后一帧也不要强行匹配。这类问题在单线程串行推理里不会出现。如果你第一次做并行建议先保持串行把整个流程跑通再逐步改并行。并行带来的帧率提升是实打实的但排查成本也是串行的好几倍。5.2 掩码和关键点画不到原图上这个问题多数出在坐标还原阶段。一个很典型的现象官方绘图接口显示结果没问题但自己组合的画面里掩码轮廓和物体错位几个像素甚至更严重。关键点在于官方绘图接口内部做了坐标还原它知道模型输入尺寸和原图尺寸的关系自定义画图时如果直接拿results里的数据画而没做还原错位就必然发生。掩码部分尤其要小心。masks.data是模型输入尺寸的布尔图不能当成原图尺寸直接用。先把它resize回原图大小再提取轮廓坐标画出的掩码才会严丝合缝。我见过有人直接把掩码resize到原图结果把填充边也当成了有效区域掩码外扩一圈表面看像分割质量差实际是后处理bug。5.3 显存不足与推理变慢显存不足的解决办法很直接batch size固定为1推理时用torch.no_grad包住前向过程再打开半精度。如果还不够把输入分辨率降到480。降分辨率对检测框的影响通常不大但对小目标检测和掩码精度的影响很明显尺寸越小掩码边缘越粗糙。降分辨率之前要权衡业务对小目标的敏感度。推理变慢还有一个容易被忽略的原因GPU没实际用起来。模型加载后如果设备还是CPU所有推理都在CPU上跑速度自然慢。一个快速验证方法是看显存占用如果显存为0但CPU占用拉满说明模型根本没上GPU检查设备的设置和PyTorch的CUDA可用性就行。5.4 检测正常但关键点全是0分割模型能正常出框和掩码姿态模型检测框也出来了但关键点数组里全是0或置信度全是0这个问题我遇到过几次。多数时候不是模型坏了而是后处理时关键点输出维度读错了。姿态输出是(N, 17, 3)如果代码只取[:, :2]就把置信度忽略了如果只取[:, 2]又拿不到坐标。排查时先把keypoints.data打印出来看第三维是不是0到1之间的置信度问题马上暴露。还有一个更隐蔽的原因严重遮挡或小目标场景里模型输出的关键点置信度普遍低于阈值代码过滤太狠最后只剩空数组。这时候把置信度阈值从0.5降到0.3再看一般就能看到关键点。但阈值也不能无限降否则背景噪点会被当成关键点骨架线乱成一团。我习惯先用0.5看整体效果再针对遮挡场景调到0.3到0.35之间。5.5 常见问题速查表现象可能原因解决建议分割掩码和原图错位letterbox偏移未还原统一封装坐标映射函数掩码外扩一圈把填充边当成有效区域掩码先还原再resize关键点全是0输出维度读错或置信度过滤过狠打印keypoints.data检查结构多任务结果张冠李戴并行推理帧未对齐用帧序号做结果同步帧率骤降模型跑在CPU上检查设备与显存占用显存不够模型过多或分辨率过大batch1、fp16、降分辨率6. 个人经验总结与扩展空间6.1 两个实战体会整个项目跑完之后我最大的体会有两点。第一多任务实战里最花时间的不在算法而在工程整合。检测、分割、姿态估计每个单模型都有现成用法真正需要设计的是统一接口、坐标映射和可视化分层这三个基础模块做好后面所有业务功能都会轻松很多。第二模型尺寸的选择一定要以目标场景的实时性预算为基准先定帧率再选模型不要上来就贪精度。帧率预算30帧先用最小尺寸跑通全流程再根据剩余算力一点点往上升比一开始就上大模型然后被迫砍业务功能要省事得多。6.2 可以继续扩展的方向分割掩码不只是在画面上填色它可以用来做ROI裁剪。拿到目标掩码后把掩码内的像素单独抠出来再送入姿态模型能减少背景干扰对小目标的姿态估计有明显提升。检测框可以用来做区域计数和轨迹跟踪关键点可以用来做跌倒检测和动作识别。这三件事各自都不难难的是把它们糅合在同一个框架里稳定运行。比起背模型参数先把坐标映射和结果对齐练熟收益会大得多。我就先分享到这儿有什么更好的思路欢迎一起交流。
