1. 为什么要在 C 里跑 YOLO-Pose而不是继续用 Python我最早做人体关键点检测是在 Python 里用 PyTorch 直接推理模型加载、前处理、后处理全用 NumPy 写开发效率确实高。但一旦要往实际产品里塞问题就来了目标机器上不一定有 Python 环境即便有版本冲突、依赖体积、启动速度都是麻烦事。更关键的是Python 推理的延迟波动很大尤其是多路视频并发的时候GIL 锁和内存管理会让帧率忽高忽低这在需要稳定输出的场景里是致命的。后来我把推理部分整体迁到 C用 MNN 作为推理引擎模型换成 YOLOv8-Pose实测下来单帧端到端延迟从 Python 的 40 多毫秒压到了 15 毫秒以内CPU 上1080P 输入缩放到 640 分辨率。这个差距不是玄学而是几个因素叠加的结果C 没有解释器开销MNN 的算子实现针对 ARM 和 x86 都做了手写优化内存复用策略也比 Python 侧手动管理更激进。这篇文章要聊的就是这套方案的完整落地过程怎么把 YOLOv8-Pose、YOLO11-Pose、YOLO26-Pose 这几个模型在 MNN 上跑起来怎么同时支持 CPU 和 GPU 后端以及我在实际部署中踩过的那些坑。适合已经了解 YOLO 基本概念、想在 C 工程里集成关键点检测的开发者也适合正在做边缘设备部署、对推理性能有要求的朋友。提示本文涉及的模型导出、MNN 转换、C 推理代码均基于公开工具链和常见实践不涉及任何特定平台或受限资源。2. 模型选型YOLOv8-Pose、YOLO11-Pose、YOLO26-Pose 到底差在哪2.1 三个版本的关键点检测头设计差异YOLOv8-Pose 用的是 C2f 骨干加解耦头关键点分支和检测分支共享部分特征但各自独立输出。它的关键点输出是 17 个点每个点三个值x、y、置信度总共 51 维加上边界框的 4 维和类别置信度单个人体实例的输出维度是 56。这个设计在 COCO 关键点数据集上已经相当成熟精度和速度平衡得不错。YOLO11-Pose 在骨干上做了调整引入了 C3k2 模块本质上是对 C2f 的轻量化改进参数量更少但感受野控制更灵活。它的关键点检测头结构跟 v8 差别不大主要优化在特征融合阶段PAN 结构的跨层连接方式有变化对小目标关键点的召回率有提升。YOLO26-Pose 是较新的版本最大的变化是去掉了 NMS 后处理改成端到端的直接输出。这对 C 部署来说其实是好事因为 NMS 在 CPU 上做排序和 IoU 计算挺耗时的去掉之后后处理逻辑简化了不少。但代价是模型本身需要更强的学习能力来抑制重复检测训练难度会高一些。特性YOLOv8-PoseYOLO11-PoseYOLO26-Pose骨干模块C2fC3k2改进 C3k2后处理NMSNMS无 NMS关键点输出17×317×317×3输入尺寸640×640640×640640×640MNN 转换难度低中中高CPU 推理速度快较快快GPU 推理速度很快很快很快2.2 为什么最终选了 MNN 而不是其他推理框架我对比过 ONNX Runtime、NCNN、TNN 和 MNN。ONNX Runtime 在 x86 上表现很好但 ARM 上算子覆盖不全有些自定义算子会回退到 CPU 慢速实现。NCNN 很轻量但 GPU 支持相对弱Vulkan 后端在某些设备上兼容性一般。TNN 是腾讯的跟 MNN 同源但社区活跃度稍低。MNN 的优势在于第一它自带模型转换工具从 ONNX 到 MNN 的转换链路很顺第二它的 CPU 后端有手写汇编优化ARM 上能用上 NEONx86 上能用上 AVX2第三GPU 后端支持 OpenCL 和 Vulkan移动端和桌面端都能覆盖第四它的内存管理是池化的反复推理时不会频繁申请释放内存。注意MNN 社区版可以直接从官方仓库获取编译时记得打开MNN_BUILD_CONVERTER和MNN_OPENCL选项否则后面转换模型和用 GPU 都会缺东西。2.3 模型导出时的几个关键决策从 PyTorch 导出 ONNX 的时候有几个参数必须注意。首先是opset_version建议用 12 或以上因为关键点检测里的某些 reshape 操作在低版本 opset 里会出问题。其次是dynamic_axes如果你想让模型支持动态输入尺寸需要把 batch 和 height、width 都设为动态但实测下来动态尺寸在 MNN 上会稍微慢一点因为没法做静态内存规划。我的做法是固定 640×640 输入导出时不做动态轴。这样 MNN 转换后能做更激进的内存复用推理速度更稳。如果确实需要多尺寸可以导出两个模型分别对应不同的输入分辨率运行时按需切换。导出命令大概是这样python export.py --weights yolov8n-pose.pt --include onnx --imgsz 640 640 --opset 12导出完成后用 MNN 的转换工具转成.mnn格式./MNNConvert -f ONNX --modelFile yolov8n-pose.onnx --MNNModel yolov8n-pose.mnn --bizCode MNN转换过程中如果遇到不支持的算子MNN 会给出警告。YOLOv8-Pose 里比较常见的坑是Resize算子的坐标变换模式ONNX 默认是half_pixelMNN 转换时可能需要手动指定为align_corners或asymmetric否则关键点坐标会有系统性偏移。3. MNN C 推理工程的骨架搭建3.1 工程目录结构与依赖管理我习惯把工程分成几个清晰的模块model放模型文件和转换脚本include放头文件src放源文件third_party放 MNN 的预编译库和头文件test放测试图片和视频。这样结构清晰后面换模型或者加新功能都不会乱。MNN 的 C 库有两种用法一种是直接编译源码把 MNN 作为子模块编进工程另一种是用预编译的libMNN.so和头文件。我推荐后者因为编译 MNN 源码挺耗时的而且预编译库已经开了常用算子优化。从官方 release 页面下载对应平台的压缩包解压后把include和lib目录拷到third_party/MNN下就行。CMakeLists.txt 里关键就几行find_package(OpenCV REQUIRED) include_directories(${OpenCV_INCLUDE_DIRS} ${CMAKE_SOURCE_DIR}/third_party/MNN/include) link_directories(${CMAKE_SOURCE_DIR}/third_party/MNN/lib) add_executable(yolo_pose_demo src/main.cpp src/yolo_pose.cpp) target_link_libraries(yolo_pose_demo ${OpenCV_LIBS} MNN)OpenCV 用来做图像读取、缩放和画关键点MNN 负责推理。如果你不想依赖 OpenCV也可以用 stb_image 之类的轻量库但画骨架和视频读写还是 OpenCV 方便。3.2 模型加载与 Session 配置MNN 的推理入口是Interpreter加载模型用Interpreter::createFromFile。加载之后要配置ScheduleConfig这里决定了用 CPU 还是 GPU、用几个线程、精度模式是什么。std::shared_ptrMNN::Interpreter interpreter; MNN::ScheduleConfig config; config.type MNN_FORWARD_CPU; // 或 MNN_FORWARD_OPENCL / MNN_FORWARD_VULKAN config.numThread 4; MNN::BackendConfig backendConfig; backendConfig.precision MNN::BackendConfig::Precision_High; backendConfig.power MNN::BackendConfig::Power_High; config.backendConfig backendConfig; interpreter.reset(MNN::Interpreter::createFromFile(yolov8n-pose.mnn)); MNN::Session* session interpreter-createSession(config);CPU 模式下numThread设成物理核心数比较合适设太大反而会因为线程切换开销导致性能下降。GPU 模式下numThread无效但要注意 OpenCL 后端在部分集成显卡上可能不如 CPU 快需要实测。提示如果模型转换时用了--bizCode MNN加载时不需要额外指定如果用了自定义 bizCode需要在createFromFile后调用setBizCode。3.3 输入输出的张量绑定MNN 的输入输出通过getSessionInput和getSessionOutput获取。YOLOv8-Pose 的输入通常是images形状是[1, 3, 640, 640]输出是一个[1, 56, 8400]的张量。8400 是候选框数量56 是每个候选的 4 个框坐标加 1 个类别置信度加 51 个关键点值。MNN::Tensor* inputTensor interpreter-getSessionInput(session, images); MNN::Tensor* outputTensor interpreter-getSessionOutput(session, output0);如果模型有多个输出需要根据转换后的名字分别获取。YOLO11-Pose 和 YOLO26-Pose 的输出名字可能不同建议用 Netron 打开.mnn文件确认一下。输入数据的填充有两种方式一种是直接操作inputTensor-hostfloat()指针把预处理好的数据拷进去另一种是创建一个MNN::Tensor包装外部内存然后用copyFromHostTensor。前者更直接后者适合零拷贝场景。4. 前处理、推理、后处理的完整链路4.1 图像预处理letterbox 的细节决定关键点精度YOLO 系列的标准预处理是 letterbox保持宽高比缩放短边补灰边到 640×640。这个操作看起来简单但里面有几个容易出错的点。首先是缩放比例的计算。假设原图是 1920×1080缩放比例应该是640 / max(1920, 1080) 0.333缩放后尺寸是 640×360然后上下各补 140 像素的灰边。如果你直接用cv::resize到 640×640图像会被拉伸变形关键点坐标会整体偏移。其次是归一化。YOLOv8-Pose 要求输入像素值除以 255然后按 RGB 通道分别减均值除标准差。均值和标准差是 ImageNet 的[0.485, 0.456, 0.406]和[0.229, 0.224, 0.225]。这一步如果漏了或者顺序错了关键点置信度会明显下降。cv::Mat letterbox(const cv::Mat src, int targetSize, float scale, int padW, int padH) { int w src.cols, h src.rows; scale std::min(targetSize / (float)w, targetSize / (float)h); int newW (int)(w * scale), newH (int)(h * scale); cv::Mat resized; cv::resize(src, resized, cv::Size(newW, newH)); padW (targetSize - newW) / 2; padH (targetSize - newH) / 2; cv::Mat padded(targetSize, targetSize, CV_8UC3, cv::Scalar(114, 114, 114)); resized.copyTo(padded(cv::Rect(padW, padH, newW, newH))); return padded; }补边的颜色用 114 是 YOLO 官方实现里的默认值不是随便选的。这个值在训练时就是用的这个灰度推理时保持一致能减少分布偏移。4.2 推理执行与张量拷贝预处理完的图像是cv::Mat需要转成 MNN 能吃的格式。MNN 的输入张量是 NCHW 布局而 OpenCV 的cv::Mat是 HWC 布局所以需要做一次转换。我一般先把cv::Mat转成 float 数组然后按通道拆分填充。std::vectorfloat inputData(1 * 3 * 640 * 640); for (int c 0; c 3; c) { for (int h 0; h 640; h) { for (int w 0; w 640; w) { float val padded.atcv::Vec3b(h, w)[c] / 255.0f; val (val - mean[c]) / std[c]; inputData[c * 640 * 640 h * 640 w] val; } } } memcpy(inputTensor-hostfloat(), inputData.data(), inputData.size() * sizeof(float)); interpreter-runSession(session);这段代码是三重循环在 640×640 下大概有 120 万次迭代实测在 i7 上耗时约 3 到 5 毫秒。如果嫌慢可以用 OpenCV 的split和convertTo做向量化或者直接用 MNN 的copyFromHostTensor配合预分配的MNN::Tensor。推理完成后输出张量的数据在outputTensor-hostfloat()里。注意 MNN 的输出张量可能是 NC4HW4 格式为了 SIMD 优化需要用MNN::Tensor::createHostTensorFromDevice转成普通 NCHW 才能按线性索引读取。4.3 后处理从 8400 个候选里提取人体关键点YOLOv8-Pose 的输出是[1, 56, 8400]8400 是候选框数量56 是每个候选的属性。前 4 个是cx, cy, w, h第 5 个是类别置信度人体后面 51 个是 17 个关键点的x, y, score。后处理的第一步是过滤低置信度的候选。阈值一般设 0.25 到 0.5 之间太低会引入大量误检太高会漏掉小目标。我实测下来 0.3 是个比较稳的起点。std::vectorDetection detections; for (int i 0; i 8400; i) { float conf outputData[4 * 8400 i]; if (conf 0.3) continue; float cx outputData[0 * 8400 i]; float cy outputData[1 * 8400 i]; float w outputData[2 * 8400 i]; float h outputData[3 * 8400 i]; Detection det; det.box cv::Rect(cx - w/2, cy - h/2, w, h); det.conf conf; for (int k 0; k 17; k) { det.keypoints[k].x outputData[(5 k*3) * 8400 i]; det.keypoints[k].y outputData[(5 k*3 1) * 8400 i]; det.keypoints[k].score outputData[(5 k*3 2) * 8400 i]; } detections.push_back(det); }然后是 NMS。YOLOv8-Pose 和 YOLO11-Pose 都需要 NMSYOLO26-Pose 如果导出时已经做了端到端处理可以跳过。NMS 的 IoU 阈值一般设 0.45 到 0.5我习惯用 0.45因为人体框重叠度通常不会太高稍微严格一点能减少重复检测。关键点坐标需要从 640×640 的 letterbox 空间映射回原图。映射公式是float x (kp.x - padW) / scale; float y (kp.y - padH) / scale;这里padW和padH是 letterbox 时补边的像素数scale是缩放比例。如果这一步忘了减padW和padH关键点会整体偏移偏移量就是补边的像素数。注意关键点的置信度也要过滤一般低于 0.5 的点就不画了否则骨架会连到错误的位置。但过滤后的点仍然要保留在数组里只是绘制时跳过因为有些应用需要知道哪些点不可信。5. CPU 与 GPU 后端的切换与性能对比5.1 CPU 后端的线程数与精度配置MNN 的 CPU 后端支持多线程numThread设成物理核心数通常最优。我在一台 8 核 i7 上测试numThread4时单帧推理约 12 毫秒numThread8时反而升到 14 毫秒因为线程调度和缓存同步的开销超过了并行收益。精度模式有三个选项Precision_Low、Precision_Normal、Precision_High。Low会用 FP16 甚至 INT8 量化速度最快但关键点精度会掉High用 FP32精度最好但速度稍慢。实测下来Normal是个不错的折中关键点误差在 1 到 2 像素以内速度比High快 15% 左右。backendConfig.precision MNN::BackendConfig::Precision_Normal; backendConfig.power MNN::BackendConfig::Power_High;Power_High会让 CPU 跑在高频率适合对延迟敏感的场景如果是在移动设备上可以设成Power_Normal或Power_Low来省电。5.2 GPU 后端的 OpenCL 与 Vulkan 选择MNN 的 GPU 后端支持 OpenCL 和 Vulkan。OpenCL 在移动端和高通、Mali 的 GPU 上支持较好Vulkan 在桌面端和较新的移动 GPU 上更通用。我一般优先用 OpenCL因为 MNN 对 OpenCL 的算子优化更成熟。切换 GPU 后端只需要改config.typeconfig.type MNN_FORWARD_OPENCL; // 或 MNN_FORWARD_VULKAN但 GPU 后端有几个坑。第一首次推理会有编译 shader 的开销可能达到几百毫秒所以第一次跑的时候要预热一下。第二GPU 的内存和 CPU 内存是分开的输入输出张量需要显式拷贝copyFromHostTensor和copyToHostTensor的开销不能忽略。第三部分算子 GPU 不支持MNN 会自动回退到 CPU这时候性能可能还不如纯 CPU。实测数据在 NVIDIA GTX 1650 上YOLOv8n-Pose 的 GPU 推理约 5 毫秒但加上内存拷贝和 shader 预热端到端约 8 毫秒。在 Intel UHD 630 集成显卡上GPU 推理反而要 20 毫秒不如 CPU 的 12 毫秒。所以 GPU 不是万能的得看具体硬件。后端硬件推理耗时端到端耗时CPUi7-8700 4线程12ms15msOpenCLGTX 16505ms8msOpenCLUHD 63020ms25msVulkanGTX 16506ms9ms5.3 多路视频并发时的资源竞争问题如果你要同时处理多路视频每个路都开一个 Session 会吃很多内存。MNN 的 Session 不是线程安全的多个线程同时跑同一个 Session 会出问题。我的做法是每路视频独立一个 Session但共享同一个 Interpreter。Interpreter 加载模型后是只读的可以安全共享。auto interpreter std::shared_ptrMNN::Interpreter( MNN::Interpreter::createFromFile(yolov8n-pose.mnn), MNN::Interpreter::destroy); // 每路视频 MNN::ScheduleConfig config; config.type MNN_FORWARD_CPU; config.numThread 2; // 每路少一点避免总线程数爆炸 MNN::Session* session interpreter-createSession(config);如果总线程数超过物理核心数上下文切换会严重拖慢速度。4 路视频、每路 2 线程、总共 8 线程在 8 核机器上刚好跑满。如果路数更多就得考虑用 GPU 或者降低每路的线程数。6. 实际部署中踩过的坑与排查过程6.1 关键点整体偏移letterbox 参数没传对第一次跑通的时候检测框位置是对的但关键点整体往左上角偏了大概 100 多像素。排查了半天发现是后处理映射时忘了减padW和padH。因为 letterbox 是在左上角补边关键点坐标是在补边后的 640×640 空间里的映射回原图必须先把补边的偏移减掉。这个问题的隐蔽性在于检测框的cx, cy也是同样的映射逻辑但检测框的宽高比较大偏移 100 像素看起来只是框稍微偏了一点不容易察觉。关键点是精确坐标偏移就很明显。修复方法就是在映射时统一减padW和padHfloat x (kp.x - padW) / scale; float y (kp.y - padH) / scale;6.2 GPU 推理结果和 CPU 不一致同一个模型CPU 后端跑出来的关键点坐标和 GPU 后端差了几个像素。一开始以为是精度问题后来发现是 GPU 后端的Precision_Normal实际上用了 FP16而 CPU 的Precision_Normal是 FP32。FP16 的数值范围有限在坐标回归这种需要精细数值的任务上会有精度损失。解决办法是把 GPU 后端的精度设成Precision_High强制用 FP32。代价是速度慢一点但关键点精度和 CPU 一致了。backendConfig.precision MNN::BackendConfig::Precision_High;提示如果你的应用对关键点精度要求不高比如只做动作分类FP16 的精度损失可以接受那就用Normal换速度。6.3 内存泄漏Session 没释放MNN 的 Session 是手动管理的createSession之后必须releaseSession否则每创建一次就泄漏一块内存。我在一个循环里反复创建 Session 做测试跑了 1000 次之后内存涨了 2GB直接 OOM。正确的做法是用 RAII 包装或者确保每次createSession都有对应的releaseSessionMNN::Session* session interpreter-createSession(config); // ... 使用 session ... interpreter-releaseSession(session);如果 Session 的生命周期跨越整个程序那就在程序退出时统一释放。但如果是动态创建销毁一定要成对出现。6.4 YOLO26-Pose 的无 NMS 输出解析YOLO26-Pose 如果导出时带了端到端处理输出格式和 v8 不一样。它可能直接输出[1, 300, 56]这样的张量300 是最大检测数56 是属性。这时候不需要做 NMS但需要过滤掉置信度为 0 的填充项。for (int i 0; i 300; i) { float conf outputData[i * 56 4]; if (conf 0.3) continue; // 解析框和关键点 }如果导出时没带端到端处理输出还是[1, 56, 8400]那就跟 v8 一样处理。所以拿到模型后先用 Netron 看一眼输出形状能省很多调试时间。7. 源码组织与可复用的工程实践7.1 把推理逻辑封装成独立类我把整个推理流程封装成了一个YoloPoseDetector类对外只暴露detect(cv::Mat image)接口返回std::vectorDetection。这样上层业务不需要关心 MNN 的细节换模型或者换后端只需要改类的内部实现。class YoloPoseDetector { public: YoloPoseDetector(const std::string modelPath, bool useGPU); std::vectorDetection detect(const cv::Mat image); private: std::shared_ptrMNN::Interpreter interpreter_; MNN::Session* session_; float mean_[3] {0.485f, 0.456f, 0.406f}; float std_[3] {0.229f, 0.224f, 0.225f}; int inputSize_ 640; };构造函数里做模型加载和 Session 创建析构函数里释放 Session。detect里做前处理、推理、后处理返回结果。这样代码干净也方便写单元测试。7.2 关键点骨架的绘制与可视化调试的时候可视化很重要。我写了一个drawSkeleton函数把 17 个关键点按 COCO 定义的连接关系画出来。COCO 的骨架连接是鼻子到左右眼、左右耳肩膀到肘到腕髋到膝到踝以及肩膀到髋的躯干连接。const std::vectorstd::pairint, int skeleton { {0, 1}, {0, 2}, {1, 3}, {2, 4}, {5, 6}, {5, 7}, {7, 9}, {6, 8}, {8, 10}, {5, 11}, {6, 12}, {11, 12}, {11, 13}, {13, 15}, {12, 14}, {14, 16} };绘制时只画两端置信度都大于 0.5 的连线否则骨架会乱。颜色可以按置信度做渐变高置信度的线用亮色低置信度的用暗色一眼就能看出哪些点不可靠。7.3 性能优化的几个实用技巧第一预处理用 OpenCV 的cv::dnn::blobFromImage替代手写循环它内部做了 SIMD 优化速度快不少。第二输出张量的解析可以用指针偏移代替二维索引减少乘法计算。第三如果输入图像尺寸固定可以预分配输入输出张量的内存避免每次推理都重新分配。// 预分配输入张量 MNN::Tensor inputTensorWrapper(inputTensor, inputTensor-getDimensionType()); // 每次推理只更新数据不重新创建第四如果做视频流处理可以用双缓冲一个线程做预处理一个线程做推理一个线程做后处理流水线并行能把吞吐量提升 30% 以上。8. 从单帧到视频流工程化落地的最后一步单帧推理跑通之后往视频流上迁是另一个故事。视频流的核心问题是帧率稳定性和延迟控制。如果每帧都同步做预处理、推理、后处理帧率会被最慢的环节拖累。我的做法是把这三个阶段拆成独立的线程用队列连接。预处理线程从视频源读帧做 letterbox 和归一化把结果放进队列 A。推理线程从队列 A 取数据跑 MNN把输出放进队列 B。后处理线程从队列 B 取输出做 NMS 和坐标映射画骨架输出到显示或编码器。队列长度要设上限比如 3 到 5 帧。如果队列满了预处理线程就丢帧保证延迟不会无限增长。实测下来这种流水线结构在 1080P 25fps 的视频上端到端延迟能控制在 60 毫秒以内帧率稳定在 25fps 不掉。如果要做多路每路一套流水线但共享同一个 Interpreter。Session 每路独立线程数按总核心数均分。8 核机器跑 4 路每路 2 线程刚好跑满。如果路数更多就得考虑用 GPU 或者降低分辨率。注意多路场景下GPU 后端的 Session 创建开销比 CPU 大因为每个 Session 都要编译 shader。建议在程序启动时一次性创建所有 Session不要动态创建销毁。最后分享一个我踩过的坑视频流的帧时间戳和推理时间戳要对齐否则做动作分析的时候时间轴会乱。我习惯在预处理阶段记录帧的原始时间戳一路传到后处理这样输出的关键点数据自带时间信息后面做时序分析不用再猜。 
长河君 · 2026/10/2 5:49:55 · 阅读 1.2k C++ 部署 YOLOv8/11/26-Pose：MNN 推理与 CPU/GPU 后端实战
1. 为什么要在 C 里跑 YOLO-Pose而不是继续用 Python我最早做人体关键点检测是在 Python 里用 PyTorch 直接推理模型加载、前处理、后处理全用 NumPy 写开发效率确实高。但一旦要往实际产品里塞问题就来了目标机器上不一定有 Python 环境即便有版本冲突、依赖体积、启动速度都是麻烦事。更关键的是Python 推理的延迟波动很大尤其是多路视频并发的时候GIL 锁和内存管理会让帧率忽高忽低这在需要稳定输出的场景里是致命的。后来我把推理部分整体迁到 C用 MNN 作为推理引擎模型换成 YOLOv8-Pose实测下来单帧端到端延迟从 Python 的 40 多毫秒压到了 15 毫秒以内CPU 上1080P 输入缩放到 640 分辨率。这个差距不是玄学而是几个因素叠加的结果C 没有解释器开销MNN 的算子实现针对 ARM 和 x86 都做了手写优化内存复用策略也比 Python 侧手动管理更激进。这篇文章要聊的就是这套方案的完整落地过程怎么把 YOLOv8-Pose、YOLO11-Pose、YOLO26-Pose 这几个模型在 MNN 上跑起来怎么同时支持 CPU 和 GPU 后端以及我在实际部署中踩过的那些坑。适合已经了解 YOLO 基本概念、想在 C 工程里集成关键点检测的开发者也适合正在做边缘设备部署、对推理性能有要求的朋友。提示本文涉及的模型导出、MNN 转换、C 推理代码均基于公开工具链和常见实践不涉及任何特定平台或受限资源。2. 模型选型YOLOv8-Pose、YOLO11-Pose、YOLO26-Pose 到底差在哪2.1 三个版本的关键点检测头设计差异YOLOv8-Pose 用的是 C2f 骨干加解耦头关键点分支和检测分支共享部分特征但各自独立输出。它的关键点输出是 17 个点每个点三个值x、y、置信度总共 51 维加上边界框的 4 维和类别置信度单个人体实例的输出维度是 56。这个设计在 COCO 关键点数据集上已经相当成熟精度和速度平衡得不错。YOLO11-Pose 在骨干上做了调整引入了 C3k2 模块本质上是对 C2f 的轻量化改进参数量更少但感受野控制更灵活。它的关键点检测头结构跟 v8 差别不大主要优化在特征融合阶段PAN 结构的跨层连接方式有变化对小目标关键点的召回率有提升。YOLO26-Pose 是较新的版本最大的变化是去掉了 NMS 后处理改成端到端的直接输出。这对 C 部署来说其实是好事因为 NMS 在 CPU 上做排序和 IoU 计算挺耗时的去掉之后后处理逻辑简化了不少。但代价是模型本身需要更强的学习能力来抑制重复检测训练难度会高一些。特性YOLOv8-PoseYOLO11-PoseYOLO26-Pose骨干模块C2fC3k2改进 C3k2后处理NMSNMS无 NMS关键点输出17×317×317×3输入尺寸640×640640×640640×640MNN 转换难度低中中高CPU 推理速度快较快快GPU 推理速度很快很快很快2.2 为什么最终选了 MNN 而不是其他推理框架我对比过 ONNX Runtime、NCNN、TNN 和 MNN。ONNX Runtime 在 x86 上表现很好但 ARM 上算子覆盖不全有些自定义算子会回退到 CPU 慢速实现。NCNN 很轻量但 GPU 支持相对弱Vulkan 后端在某些设备上兼容性一般。TNN 是腾讯的跟 MNN 同源但社区活跃度稍低。MNN 的优势在于第一它自带模型转换工具从 ONNX 到 MNN 的转换链路很顺第二它的 CPU 后端有手写汇编优化ARM 上能用上 NEONx86 上能用上 AVX2第三GPU 后端支持 OpenCL 和 Vulkan移动端和桌面端都能覆盖第四它的内存管理是池化的反复推理时不会频繁申请释放内存。注意MNN 社区版可以直接从官方仓库获取编译时记得打开MNN_BUILD_CONVERTER和MNN_OPENCL选项否则后面转换模型和用 GPU 都会缺东西。2.3 模型导出时的几个关键决策从 PyTorch 导出 ONNX 的时候有几个参数必须注意。首先是opset_version建议用 12 或以上因为关键点检测里的某些 reshape 操作在低版本 opset 里会出问题。其次是dynamic_axes如果你想让模型支持动态输入尺寸需要把 batch 和 height、width 都设为动态但实测下来动态尺寸在 MNN 上会稍微慢一点因为没法做静态内存规划。我的做法是固定 640×640 输入导出时不做动态轴。这样 MNN 转换后能做更激进的内存复用推理速度更稳。如果确实需要多尺寸可以导出两个模型分别对应不同的输入分辨率运行时按需切换。导出命令大概是这样python export.py --weights yolov8n-pose.pt --include onnx --imgsz 640 640 --opset 12导出完成后用 MNN 的转换工具转成.mnn格式./MNNConvert -f ONNX --modelFile yolov8n-pose.onnx --MNNModel yolov8n-pose.mnn --bizCode MNN转换过程中如果遇到不支持的算子MNN 会给出警告。YOLOv8-Pose 里比较常见的坑是Resize算子的坐标变换模式ONNX 默认是half_pixelMNN 转换时可能需要手动指定为align_corners或asymmetric否则关键点坐标会有系统性偏移。3. MNN C 推理工程的骨架搭建3.1 工程目录结构与依赖管理我习惯把工程分成几个清晰的模块model放模型文件和转换脚本include放头文件src放源文件third_party放 MNN 的预编译库和头文件test放测试图片和视频。这样结构清晰后面换模型或者加新功能都不会乱。MNN 的 C 库有两种用法一种是直接编译源码把 MNN 作为子模块编进工程另一种是用预编译的libMNN.so和头文件。我推荐后者因为编译 MNN 源码挺耗时的而且预编译库已经开了常用算子优化。从官方 release 页面下载对应平台的压缩包解压后把include和lib目录拷到third_party/MNN下就行。CMakeLists.txt 里关键就几行find_package(OpenCV REQUIRED) include_directories(${OpenCV_INCLUDE_DIRS} ${CMAKE_SOURCE_DIR}/third_party/MNN/include) link_directories(${CMAKE_SOURCE_DIR}/third_party/MNN/lib) add_executable(yolo_pose_demo src/main.cpp src/yolo_pose.cpp) target_link_libraries(yolo_pose_demo ${OpenCV_LIBS} MNN)OpenCV 用来做图像读取、缩放和画关键点MNN 负责推理。如果你不想依赖 OpenCV也可以用 stb_image 之类的轻量库但画骨架和视频读写还是 OpenCV 方便。3.2 模型加载与 Session 配置MNN 的推理入口是Interpreter加载模型用Interpreter::createFromFile。加载之后要配置ScheduleConfig这里决定了用 CPU 还是 GPU、用几个线程、精度模式是什么。std::shared_ptrMNN::Interpreter interpreter; MNN::ScheduleConfig config; config.type MNN_FORWARD_CPU; // 或 MNN_FORWARD_OPENCL / MNN_FORWARD_VULKAN config.numThread 4; MNN::BackendConfig backendConfig; backendConfig.precision MNN::BackendConfig::Precision_High; backendConfig.power MNN::BackendConfig::Power_High; config.backendConfig backendConfig; interpreter.reset(MNN::Interpreter::createFromFile(yolov8n-pose.mnn)); MNN::Session* session interpreter-createSession(config);CPU 模式下numThread设成物理核心数比较合适设太大反而会因为线程切换开销导致性能下降。GPU 模式下numThread无效但要注意 OpenCL 后端在部分集成显卡上可能不如 CPU 快需要实测。提示如果模型转换时用了--bizCode MNN加载时不需要额外指定如果用了自定义 bizCode需要在createFromFile后调用setBizCode。3.3 输入输出的张量绑定MNN 的输入输出通过getSessionInput和getSessionOutput获取。YOLOv8-Pose 的输入通常是images形状是[1, 3, 640, 640]输出是一个[1, 56, 8400]的张量。8400 是候选框数量56 是每个候选的 4 个框坐标加 1 个类别置信度加 51 个关键点值。MNN::Tensor* inputTensor interpreter-getSessionInput(session, images); MNN::Tensor* outputTensor interpreter-getSessionOutput(session, output0);如果模型有多个输出需要根据转换后的名字分别获取。YOLO11-Pose 和 YOLO26-Pose 的输出名字可能不同建议用 Netron 打开.mnn文件确认一下。输入数据的填充有两种方式一种是直接操作inputTensor-hostfloat()指针把预处理好的数据拷进去另一种是创建一个MNN::Tensor包装外部内存然后用copyFromHostTensor。前者更直接后者适合零拷贝场景。4. 前处理、推理、后处理的完整链路4.1 图像预处理letterbox 的细节决定关键点精度YOLO 系列的标准预处理是 letterbox保持宽高比缩放短边补灰边到 640×640。这个操作看起来简单但里面有几个容易出错的点。首先是缩放比例的计算。假设原图是 1920×1080缩放比例应该是640 / max(1920, 1080) 0.333缩放后尺寸是 640×360然后上下各补 140 像素的灰边。如果你直接用cv::resize到 640×640图像会被拉伸变形关键点坐标会整体偏移。其次是归一化。YOLOv8-Pose 要求输入像素值除以 255然后按 RGB 通道分别减均值除标准差。均值和标准差是 ImageNet 的[0.485, 0.456, 0.406]和[0.229, 0.224, 0.225]。这一步如果漏了或者顺序错了关键点置信度会明显下降。cv::Mat letterbox(const cv::Mat src, int targetSize, float scale, int padW, int padH) { int w src.cols, h src.rows; scale std::min(targetSize / (float)w, targetSize / (float)h); int newW (int)(w * scale), newH (int)(h * scale); cv::Mat resized; cv::resize(src, resized, cv::Size(newW, newH)); padW (targetSize - newW) / 2; padH (targetSize - newH) / 2; cv::Mat padded(targetSize, targetSize, CV_8UC3, cv::Scalar(114, 114, 114)); resized.copyTo(padded(cv::Rect(padW, padH, newW, newH))); return padded; }补边的颜色用 114 是 YOLO 官方实现里的默认值不是随便选的。这个值在训练时就是用的这个灰度推理时保持一致能减少分布偏移。4.2 推理执行与张量拷贝预处理完的图像是cv::Mat需要转成 MNN 能吃的格式。MNN 的输入张量是 NCHW 布局而 OpenCV 的cv::Mat是 HWC 布局所以需要做一次转换。我一般先把cv::Mat转成 float 数组然后按通道拆分填充。std::vectorfloat inputData(1 * 3 * 640 * 640); for (int c 0; c 3; c) { for (int h 0; h 640; h) { for (int w 0; w 640; w) { float val padded.atcv::Vec3b(h, w)[c] / 255.0f; val (val - mean[c]) / std[c]; inputData[c * 640 * 640 h * 640 w] val; } } } memcpy(inputTensor-hostfloat(), inputData.data(), inputData.size() * sizeof(float)); interpreter-runSession(session);这段代码是三重循环在 640×640 下大概有 120 万次迭代实测在 i7 上耗时约 3 到 5 毫秒。如果嫌慢可以用 OpenCV 的split和convertTo做向量化或者直接用 MNN 的copyFromHostTensor配合预分配的MNN::Tensor。推理完成后输出张量的数据在outputTensor-hostfloat()里。注意 MNN 的输出张量可能是 NC4HW4 格式为了 SIMD 优化需要用MNN::Tensor::createHostTensorFromDevice转成普通 NCHW 才能按线性索引读取。4.3 后处理从 8400 个候选里提取人体关键点YOLOv8-Pose 的输出是[1, 56, 8400]8400 是候选框数量56 是每个候选的属性。前 4 个是cx, cy, w, h第 5 个是类别置信度人体后面 51 个是 17 个关键点的x, y, score。后处理的第一步是过滤低置信度的候选。阈值一般设 0.25 到 0.5 之间太低会引入大量误检太高会漏掉小目标。我实测下来 0.3 是个比较稳的起点。std::vectorDetection detections; for (int i 0; i 8400; i) { float conf outputData[4 * 8400 i]; if (conf 0.3) continue; float cx outputData[0 * 8400 i]; float cy outputData[1 * 8400 i]; float w outputData[2 * 8400 i]; float h outputData[3 * 8400 i]; Detection det; det.box cv::Rect(cx - w/2, cy - h/2, w, h); det.conf conf; for (int k 0; k 17; k) { det.keypoints[k].x outputData[(5 k*3) * 8400 i]; det.keypoints[k].y outputData[(5 k*3 1) * 8400 i]; det.keypoints[k].score outputData[(5 k*3 2) * 8400 i]; } detections.push_back(det); }然后是 NMS。YOLOv8-Pose 和 YOLO11-Pose 都需要 NMSYOLO26-Pose 如果导出时已经做了端到端处理可以跳过。NMS 的 IoU 阈值一般设 0.45 到 0.5我习惯用 0.45因为人体框重叠度通常不会太高稍微严格一点能减少重复检测。关键点坐标需要从 640×640 的 letterbox 空间映射回原图。映射公式是float x (kp.x - padW) / scale; float y (kp.y - padH) / scale;这里padW和padH是 letterbox 时补边的像素数scale是缩放比例。如果这一步忘了减padW和padH关键点会整体偏移偏移量就是补边的像素数。注意关键点的置信度也要过滤一般低于 0.5 的点就不画了否则骨架会连到错误的位置。但过滤后的点仍然要保留在数组里只是绘制时跳过因为有些应用需要知道哪些点不可信。5. CPU 与 GPU 后端的切换与性能对比5.1 CPU 后端的线程数与精度配置MNN 的 CPU 后端支持多线程numThread设成物理核心数通常最优。我在一台 8 核 i7 上测试numThread4时单帧推理约 12 毫秒numThread8时反而升到 14 毫秒因为线程调度和缓存同步的开销超过了并行收益。精度模式有三个选项Precision_Low、Precision_Normal、Precision_High。Low会用 FP16 甚至 INT8 量化速度最快但关键点精度会掉High用 FP32精度最好但速度稍慢。实测下来Normal是个不错的折中关键点误差在 1 到 2 像素以内速度比High快 15% 左右。backendConfig.precision MNN::BackendConfig::Precision_Normal; backendConfig.power MNN::BackendConfig::Power_High;Power_High会让 CPU 跑在高频率适合对延迟敏感的场景如果是在移动设备上可以设成Power_Normal或Power_Low来省电。5.2 GPU 后端的 OpenCL 与 Vulkan 选择MNN 的 GPU 后端支持 OpenCL 和 Vulkan。OpenCL 在移动端和高通、Mali 的 GPU 上支持较好Vulkan 在桌面端和较新的移动 GPU 上更通用。我一般优先用 OpenCL因为 MNN 对 OpenCL 的算子优化更成熟。切换 GPU 后端只需要改config.typeconfig.type MNN_FORWARD_OPENCL; // 或 MNN_FORWARD_VULKAN但 GPU 后端有几个坑。第一首次推理会有编译 shader 的开销可能达到几百毫秒所以第一次跑的时候要预热一下。第二GPU 的内存和 CPU 内存是分开的输入输出张量需要显式拷贝copyFromHostTensor和copyToHostTensor的开销不能忽略。第三部分算子 GPU 不支持MNN 会自动回退到 CPU这时候性能可能还不如纯 CPU。实测数据在 NVIDIA GTX 1650 上YOLOv8n-Pose 的 GPU 推理约 5 毫秒但加上内存拷贝和 shader 预热端到端约 8 毫秒。在 Intel UHD 630 集成显卡上GPU 推理反而要 20 毫秒不如 CPU 的 12 毫秒。所以 GPU 不是万能的得看具体硬件。后端硬件推理耗时端到端耗时CPUi7-8700 4线程12ms15msOpenCLGTX 16505ms8msOpenCLUHD 63020ms25msVulkanGTX 16506ms9ms5.3 多路视频并发时的资源竞争问题如果你要同时处理多路视频每个路都开一个 Session 会吃很多内存。MNN 的 Session 不是线程安全的多个线程同时跑同一个 Session 会出问题。我的做法是每路视频独立一个 Session但共享同一个 Interpreter。Interpreter 加载模型后是只读的可以安全共享。auto interpreter std::shared_ptrMNN::Interpreter( MNN::Interpreter::createFromFile(yolov8n-pose.mnn), MNN::Interpreter::destroy); // 每路视频 MNN::ScheduleConfig config; config.type MNN_FORWARD_CPU; config.numThread 2; // 每路少一点避免总线程数爆炸 MNN::Session* session interpreter-createSession(config);如果总线程数超过物理核心数上下文切换会严重拖慢速度。4 路视频、每路 2 线程、总共 8 线程在 8 核机器上刚好跑满。如果路数更多就得考虑用 GPU 或者降低每路的线程数。6. 实际部署中踩过的坑与排查过程6.1 关键点整体偏移letterbox 参数没传对第一次跑通的时候检测框位置是对的但关键点整体往左上角偏了大概 100 多像素。排查了半天发现是后处理映射时忘了减padW和padH。因为 letterbox 是在左上角补边关键点坐标是在补边后的 640×640 空间里的映射回原图必须先把补边的偏移减掉。这个问题的隐蔽性在于检测框的cx, cy也是同样的映射逻辑但检测框的宽高比较大偏移 100 像素看起来只是框稍微偏了一点不容易察觉。关键点是精确坐标偏移就很明显。修复方法就是在映射时统一减padW和padHfloat x (kp.x - padW) / scale; float y (kp.y - padH) / scale;6.2 GPU 推理结果和 CPU 不一致同一个模型CPU 后端跑出来的关键点坐标和 GPU 后端差了几个像素。一开始以为是精度问题后来发现是 GPU 后端的Precision_Normal实际上用了 FP16而 CPU 的Precision_Normal是 FP32。FP16 的数值范围有限在坐标回归这种需要精细数值的任务上会有精度损失。解决办法是把 GPU 后端的精度设成Precision_High强制用 FP32。代价是速度慢一点但关键点精度和 CPU 一致了。backendConfig.precision MNN::BackendConfig::Precision_High;提示如果你的应用对关键点精度要求不高比如只做动作分类FP16 的精度损失可以接受那就用Normal换速度。6.3 内存泄漏Session 没释放MNN 的 Session 是手动管理的createSession之后必须releaseSession否则每创建一次就泄漏一块内存。我在一个循环里反复创建 Session 做测试跑了 1000 次之后内存涨了 2GB直接 OOM。正确的做法是用 RAII 包装或者确保每次createSession都有对应的releaseSessionMNN::Session* session interpreter-createSession(config); // ... 使用 session ... interpreter-releaseSession(session);如果 Session 的生命周期跨越整个程序那就在程序退出时统一释放。但如果是动态创建销毁一定要成对出现。6.4 YOLO26-Pose 的无 NMS 输出解析YOLO26-Pose 如果导出时带了端到端处理输出格式和 v8 不一样。它可能直接输出[1, 300, 56]这样的张量300 是最大检测数56 是属性。这时候不需要做 NMS但需要过滤掉置信度为 0 的填充项。for (int i 0; i 300; i) { float conf outputData[i * 56 4]; if (conf 0.3) continue; // 解析框和关键点 }如果导出时没带端到端处理输出还是[1, 56, 8400]那就跟 v8 一样处理。所以拿到模型后先用 Netron 看一眼输出形状能省很多调试时间。7. 源码组织与可复用的工程实践7.1 把推理逻辑封装成独立类我把整个推理流程封装成了一个YoloPoseDetector类对外只暴露detect(cv::Mat image)接口返回std::vectorDetection。这样上层业务不需要关心 MNN 的细节换模型或者换后端只需要改类的内部实现。class YoloPoseDetector { public: YoloPoseDetector(const std::string modelPath, bool useGPU); std::vectorDetection detect(const cv::Mat image); private: std::shared_ptrMNN::Interpreter interpreter_; MNN::Session* session_; float mean_[3] {0.485f, 0.456f, 0.406f}; float std_[3] {0.229f, 0.224f, 0.225f}; int inputSize_ 640; };构造函数里做模型加载和 Session 创建析构函数里释放 Session。detect里做前处理、推理、后处理返回结果。这样代码干净也方便写单元测试。7.2 关键点骨架的绘制与可视化调试的时候可视化很重要。我写了一个drawSkeleton函数把 17 个关键点按 COCO 定义的连接关系画出来。COCO 的骨架连接是鼻子到左右眼、左右耳肩膀到肘到腕髋到膝到踝以及肩膀到髋的躯干连接。const std::vectorstd::pairint, int skeleton { {0, 1}, {0, 2}, {1, 3}, {2, 4}, {5, 6}, {5, 7}, {7, 9}, {6, 8}, {8, 10}, {5, 11}, {6, 12}, {11, 12}, {11, 13}, {13, 15}, {12, 14}, {14, 16} };绘制时只画两端置信度都大于 0.5 的连线否则骨架会乱。颜色可以按置信度做渐变高置信度的线用亮色低置信度的用暗色一眼就能看出哪些点不可靠。7.3 性能优化的几个实用技巧第一预处理用 OpenCV 的cv::dnn::blobFromImage替代手写循环它内部做了 SIMD 优化速度快不少。第二输出张量的解析可以用指针偏移代替二维索引减少乘法计算。第三如果输入图像尺寸固定可以预分配输入输出张量的内存避免每次推理都重新分配。// 预分配输入张量 MNN::Tensor inputTensorWrapper(inputTensor, inputTensor-getDimensionType()); // 每次推理只更新数据不重新创建第四如果做视频流处理可以用双缓冲一个线程做预处理一个线程做推理一个线程做后处理流水线并行能把吞吐量提升 30% 以上。8. 从单帧到视频流工程化落地的最后一步单帧推理跑通之后往视频流上迁是另一个故事。视频流的核心问题是帧率稳定性和延迟控制。如果每帧都同步做预处理、推理、后处理帧率会被最慢的环节拖累。我的做法是把这三个阶段拆成独立的线程用队列连接。预处理线程从视频源读帧做 letterbox 和归一化把结果放进队列 A。推理线程从队列 A 取数据跑 MNN把输出放进队列 B。后处理线程从队列 B 取输出做 NMS 和坐标映射画骨架输出到显示或编码器。队列长度要设上限比如 3 到 5 帧。如果队列满了预处理线程就丢帧保证延迟不会无限增长。实测下来这种流水线结构在 1080P 25fps 的视频上端到端延迟能控制在 60 毫秒以内帧率稳定在 25fps 不掉。如果要做多路每路一套流水线但共享同一个 Interpreter。Session 每路独立线程数按总核心数均分。8 核机器跑 4 路每路 2 线程刚好跑满。如果路数更多就得考虑用 GPU 或者降低分辨率。注意多路场景下GPU 后端的 Session 创建开销比 CPU 大因为每个 Session 都要编译 shader。建议在程序启动时一次性创建所有 Session不要动态创建销毁。最后分享一个我踩过的坑视频流的帧时间戳和推理时间戳要对齐否则做动作分析的时候时间轴会乱。我习惯在预处理阶段记录帧的原始时间戳一路传到后处理这样输出的关键点数据自带时间信息后面做时序分析不用再猜。