简介：面向需要把人体姿态识别能力集成到Windows桌面应用的C#开发者，这套基于YOLOv11-Pose的源码工程提供开箱即用的部署方案。工程可直接在Visual Studio 2019中打开运行，基于.NET Framework 4.8，融合OpenCvSharp和ONNX Runtime，免去从零搭建环境的繁琐过程。资源共包含63个文件，压缩包整体约63.46MB，核心构成包括C#源码、运行依赖库、配置信息、示例图片、ONNX模型以及演示视频，其中DLL提供图像处理与推理加速支持，CS文件实现界面交互与姿态解析逻辑，模型负责输出人体关键点坐标。相比普通目标检测，本项目还处理了关键点回归与骨骼连线绘制，完整呈现姿态估计的技术难点。目前已有1094人学习下载，可通过源码逐步掌握模型加载、图像预处理、张量解析到关键点可视化的全链路。工程内附带窗体设计、结果类封装和所需资源，并区分调试与发布目录，结构清晰，便于二次开发，对智能监控、人机交互等场景具有直接参考价值。
1. 用 C# WinForm 部署 YOLOv11-Pose：这个 ONNX 源码包帮你省掉的那几步
你手上这份 C# winform 部署 yolov11-pose 姿态估计 onnx 模型源码，解决的是桌面端最现实的一件事：不装 Python、不开服务，双击 exe 就能对图片或摄像头画面做 17 个人体关键点检测。做上位机的同事拿它接串口和视觉工位，做毕业设计的拿它当骨架来改界面，更多人只是想把模型从 PyTorch 搬到 Windows 上跑通——结果常常卡在半路。反直觉的是，真正耗时的不在 ONNX 加载，而在三处：letterbox 预处理和坐标反算、输出 Tensor 的维度排布、WinForm 跨线程刷新。把这三处理顺了，这套源码才真正属于你。
2. 从 ONNX 模型到 C# 调用链：先看懂输入输出形状，再谈部署
把 ONNX 模型当成黑匣子直接塞给 InferenceSession，这是部署翻车的第一来源。YOLOv11-Pose 和检测模型最大的区别在于输出结构：它不是一个张量装到底，而是把边界框、类别置信度、17 个关键点坐标分开排布，甚至不同导出方式给出的维度都不一样。所以拿到源码包第一步不是跑界面，而是先打印模型输入输出元数据，确认当前这个 onnx 的 shape 再写后处理。
2.1 模型输出到底长什么样：Tensor 维度和两种常见排布
在 Ultralytics 官方导出流程里，YOLOv11-Pose 的 ONNX 一般会输出多个 Tensor：一个包含边界框和置信度，另一个包含关键点。常见的是输入 [1, 3, 640, 640]，输出三个张量分别对应 boxes、scores、kps；但也有很多仓库会把结果合并成一个 [1, 56, 8400] 的大张量，其中 56 = 4（框坐标 cx, cy, w, h）+ 1（置信度）+ 51（17 个关键点 × x, y, score）。如果你拿到的是合并版本，后处理逻辑就完全不一样。
我拿到源码包后第一件事永远是加一段打印代码，把每个输入输出张量的名称和维度打出来，再决定后处理怎么解析。
using Microsoft.ML.OnnxRuntime; using Microsoft.ML.OnnxRuntime.Tensors; // 创建会话，模型路径按你的实际路径改 using var session = new InferenceSession(@"models\yolov11n-pose.onnx"); // 遍历输入元数据，确认输入 shape 是不是 [1,3,640,640] foreach (var inputMeta in session.InputMetadata) { Console.WriteLine($"输入: {inputMeta.Key} 维度: {string.Join(",", inputMeta.Value.Dimensions)}"); } // 遍历输出元数据，确认是 3 个张量还是 1 个合并张量 foreach (var outputMeta in session.OutputMetadata) { Console.WriteLine($"输出: {outputMeta.Key} 维度: {string.Join(",", outputMeta.Value.Dimensions)}"); }这段代码的作用是让模型自己告诉你它长什么样。InputMetadata和OutputMetadata返回每个张量的名称和维度数组，Dimensions里带-1表示动态维度。比如输出是[1, 56, 8400]，说明这是合并张量，解析时按 56 维切分；如果是[1, 17, 8400]之类，就说明关键点单独输出。我踩过的坑就是拿上一个项目的解析逻辑硬套，结果 NMS 全乱。参数上注意InferenceSession实现了IDisposable，用using包住，否则重复创建会话会吃掉大量内存。
2.2 ONNX Runtime 和 onnx 的差别：C# 里加载模型选哪个 NuGet 包
很多人一开始分不清 onnx 和 onnxruntime 是什么关系。onnx 是模型格式，相当于一个跨框架的模型描述文件；onnxruntime 是微软开源的推理引擎，负责把这个格式跑起来。在 C# 里引入的是Microsoft.ML.OnnxRuntime这个 NuGet 包，它不是把 Python 的 onnxruntime 搬过来，而是直接封了一层 Native 库，C# 侧通过 P/Invoke 调 C++ 核心。所以工程配置上必须保证平台目标和你下载的运行时一致，x64 工程配 x64 包。
using Microsoft.ML.OnnxRuntime; // 推荐显式配置 SessionOptions，而不是直接 new InferenceSession 时省略 var options = new SessionOptions { GraphOptimizationLevel = GraphOptimizationLevel.ORT_ENABLE_ALL, // 开启所有图优化 EnableMemoryPattern = true, // 打开内存复用 ExecutionMode = ExecutionMode.ORT_SEQUENTIAL // 单模型推理够用 }; // CPU 是默认 EP，无需额外配置；如果做 GPU 部署需要单独装 OnnxRuntime.Gpu using var session = new InferenceSession(@"yolov11-pose.onnx", options);这里ORT_ENABLE_ALL会做算子融合和常量折叠，对 CPU 推理提升很明显。ORT_SEQUENTIAL表示按顺序执行算子，对单图推理足够；如果你在一台机器上同时跑多个模型，再考虑ORT_PARALLEL。还要注意一点：NuGet 包默认只带 CPU 的 Native 库，体积小、部署方便；GPU 版本要换Microsoft.ML.OnnxRuntime.Gpu，同时要求显卡驱动满足 CUDA 版本。
2.3 预处理这一步的坑：Letterbox、归一化与 BGR/CHW
模型训练时图片被缩放到 640×640，而且是保持宽高比的 letterbox 方式。部署端如果不加 letterbox 直接Resize成正方形，人会变扁，关键点坐标自然全偏。C# 这边我一般用 OpenCvSharp4 来处理图像，先做缩放再做填充，最后转成 CHW 浮点数组喂给模型。
using OpenCvSharp; /// <summary> /// 将输入 Mat 转成模型需要的 float 张量 /// </summary> private static float[] Preprocess(Mat src, out float ratio, out int padW, out int padH) { const int InputSize = 640; ratio = Math.Min((float)InputSize / src.Width, (float)InputSize / src.Height); var newW = (int)Math.Round(src.Width * ratio); var newH = (int)Math.Round(src.Height * ratio); padW = (InputSize - newW) / 2; padH = (InputSize - newH) / 2; // 先缩放，再填充，填充值 114 是训练时的默认填充 using var resized = new Mat(); Cv2.Resize(src, resized, new Size(newW, newH)); Cv2.CopyMakeBorder(resized, resized, padH, InputSize - newH - padH, padW, InputSize - newW - padW, BorderTypes.Constant, new Scalar(114, 114, 114)); // OpenCvSharp 默认 BGR，模型训练通常是 RGB，所以这里要翻转通道 using var rgb = new Mat(); Cv2.CvtColor(resized, rgb, ColorConversionCodes.BGR2RGB); rgb.ConvertTo(rgb, MatType.CV_32FC3, 1.0 / 255.0); // HWC 转 CHW 到一维数组，供 OnnxRuntime 的 DenseTensor 使用 var tensor = new float[3 * InputSize * InputSize]; for (int y = 0; y < InputSize; y++) { for (int x = 0; x < InputSize; x++) { var pixel = rgb.At<Vec3f>(y, x); int baseIdx = (y * InputSize + x) * 3; tensor[0 * InputSize * InputSize + y * InputSize + x] = pixel.Item0; tensor[1 * InputSize * InputSize + y * InputSize + x] = pixel.Item1; tensor[2 * InputSize * InputSize + y * InputSize + x] = pixel.Item2; } } return tensor; }这段代码的关键点是ratio、padW、padH三个值必须传出，后面坐标反算要用。注意CopyMakeBorder的参数：上下左右各填充多少，InputSize - newH - padH是手动算底部填充量，因为(640 - newH)不一定是偶数，会出现上下 pad 不对称的情况。ConvertTo用1.0 / 255.0归一化后，还得把 BGR 换成 RGB——很多源码包在这步不加BGR2RGB，结果关键点画出来的位置不对，但其实不是模型的问题。
2.4 后处理：置信度阈值、NMS 和 17 个关键点解包
推理完成后拿到输出张量，剩下的工作就是解析。以最常见的合并输出 [1, 56, 8400] 为例，8400 是三个尺度特征图（80×80、40×40、20×20）的 anchor 数量总和，每个 anchor 对应 56 个值。解析时先按框的置信度过滤一遍，再做 NMS，最后把关键点按 anchor 索引取出来。
using Microsoft.ML.OnnxRuntime.Tensors; public static List<PoseInstance> DecodePose(DenseTensor<float> output, float confThreshold, float nmsThreshold) { // output 形状: [1, 56, 8400]，先拿到当前批次 var data = output.Buffer; int numAnchors = output.Dimensions[2]; var boxes = new List<Rect>(); var scores = new List<float>(); var kps = new List<float[]>(); for (int i = 0; i < numAnchors; i++) { // 5 号位置是置信度，56 维里前 4 位是 cx, cy, w, h float score = data[5 * numAnchors + i]; if (score < confThreshold) continue; float cx = data[i]; float cy = data[numAnchors + i]; float w = data[2 * numAnchors + i]; float h = data[3 * numAnchors + i]; // 转成 OpenCvSharp 的 Rect 方便后面做 NMS int left = (int)(cx - w / 2); int top = (int)(cy - h / 2); var rect = new Rect(left, top, (int)w, (int)h); // 第 6 维开始是 17 个关键点，每个点 x, y, score 三个值 var pointArr = new float[51]; Array.Copy(data, 6 * numAnchors + i, pointArr, 0, 51); // 注意这里每隔 numAnchors 取一个值，不能连续读 boxes.Add(rect); scores.Add(score); kps.Add(pointArr); } // OpenCvSharp 自带 NMS，省得自己写排序 Cv2.Dnn.NMSBoxes(boxes, scores, confThreshold, nmsThreshold, out int[] indices); var results = new List<PoseInstance>(); foreach (int idx in indices) { results.Add(new PoseInstance(boxes[idx], kps[idx])); } return results; }这里的细节在Array.Copy那一步。56 维的排布规律是一个属性跨着 8400 个 anchor 连续存储，也就是所谓 NCHW 式排布。你要读第 6 个属性，下标是6 * numAnchors + i，而不是从当前位置连续读 51 个。这个结构不摸清楚，拿到的关键点全是错位的。confThreshold我一般设 0.5，nmsThreshold设 0.6，如果你检测的是多人密集场景，可以把confThreshold降到 0.3，但会出现更多误检框，后处理耗时也会上去。
3. 关键点坐标映射与骨架绘制：从模型坐标到 WinForm 界面
模型推理跑通了，结果却画不出来或者画在错误位置上，这种情况在部署姿态估计时比检测模型多得多。原因是姿态估计输出的是 17 个点的浮点坐标，这些坐标是在 640×640 letterbox 后的图上算出来的，必须反算回原始图像分辨率。再加上 WinForm 的 GDI+ 绘制是在 UI 线程，推理在后台线程，跨线程刷新如果处理不好，界面直接卡死或黑屏。
3.1 把关键点映射回原图：scale、pad 与坐标反算
反算公式很简单：原图坐标 = (模型坐标 - padding) / scale。真正容易漏的是把关键点、检测框、绘图用的三套坐标搞混。模型输出的检测框坐标也在 640×640 坐标空间里，必须用同一个ratio和padW/padH反算，否则会看到框和骨架对不上。
/// <summary> /// 模型坐标反算回原图坐标 /// </summary> public static Point ToOriginal(float modelX, float modelY, float ratio, int padW, int padH) { // 公式: 先去掉 letterbox 的填充，再除以缩放比例 int x = (int)Math.Round((modelX - padW) / ratio); int y = (int)Math.Round((modelY - padH) / ratio); return new Point(x, y); }这个方法的输出是 WinForm 里System.Drawing.Point，可以直接给Graphics.DrawLine用。注意ratio是640.0 / src.Width和640.0 / src.Height中的较小值，如果你在预处理时用了除法而不是乘法，反算时要保持一致，否则会出现 1～2 像素的偏移。对单目标来说偏移不明显，多人和小目标场景就直接偏离身体了。
3.2 用 GDI+ 画骨架线：LimbPairs 与关键点绘制
COCO 17 关键点的定义顺序是固定的：0 鼻子、1 左眼、2 右眼、3 左耳、4 右耳、5 左肩、6 右肩、7 左肘、8 右肘、9 左腕、10 右腕、11 左髋、12 右髋、13 左膝、14 右膝、15 左踝、16 右踝。连接关系需要自己定义，比如 5→7→9 是左臂，6→8→10 是右臂。这个连接表我直接放在静态数组里。
private static readonly (int, int)[] LimbPairs = { (5, 7), (7, 9), // 左臂 (6, 8), (8, 10), // 右臂 (5, 6), // 肩膀 (5, 11), (6, 12), // 躯干 (11, 12), // 髋部 (11, 13), (13, 15), // 左腿 (12, 14), (14, 16) // 右腿 }; private static readonly Color LimbColor = Color.LimeGreen; /// <summary> /// 在 Graphics 上绘制骨架 /// </summary> public static void DrawSkeleton(Graphics g, Point[] points) { using var pen = new Pen(LimbColor, 3); foreach (var (start, end) in LimbPairs) { // 关键点置信度低时坐标会是负数，跳过即可 if (points[start].X < 0 || points[end].X < 0) continue; g.DrawLine(pen, points[start], points[end]); } using var dotBrush = new SolidBrush(Color.Red); foreach (Point p in points) { if (p.X < 0) continue; g.FillEllipse(dotBrush, p.X - 3, p.Y - 3, 6, 6); } }Pen 的宽度设成 3 在 640×480 图上看着合适，如果你在 1920×1080 的大图上画，建议按原图宽度动态计算Math.Max(2, width / 400)。using关键字在这里不是语法糖，GDI+ 的Pen和SolidBrush是 GDI 对象的封装，不释放会积累到 GDI 对象上限，程序跑几个小时后绘画就消失。界面美化方面，很多人花大力气换皮肤，其实把骨架线条颜色、透明度、线宽调好，比贴背景图提升更明显。
3.3 摄像头实时姿态估计：后台推理与 UI 线程刷新
实时摄像头场景下，推理如果放在 UI 线程，画面会一卡一卡。常见做法是用Task.Run把InferenceSession.Run扔到线程池，再把结果通过BeginInvoke抛回 UI 线程绘制。这里有个老生常谈的坑：Bitmap是 GDI+ 对象，不能在后台线程创建后直接在前台使用，必须在 UI 线程做绘制。
private async Task CaptureLoopAsync(CancellationToken ct) { using var capture = new VideoCapture(0); // 打开默认摄像头 using var frame = new Mat(); while (!ct.IsCancellationRequested) { if (!capture.Read(frame)) continue; // 后台线程推理，不阻塞 UI var detections = await Task.Run(() => _detector.Infer(frame), ct); // 回到 UI 线程更新画面 _pictureBox.BeginInvoke(new Action(() => { using var bmp = OpenCvSharp.Extensions.BitmapConverter.ToBitmap(frame); using var g = Graphics.FromImage(bmp); foreach (var detection in detections) { DrawSkeleton(g, detection.GetPoints(...)); } _pictureBox.Image?.Dispose(); _pictureBox.Image = bmp; })); // 控制在 30fps 左右，给 UI 留喘息时间 Thread.Sleep(30); } }BeginInvoke是异步的，不会等待 UI 线程处理完成，这能让采集循环保持速度，但也意味着如果 UI 绘制太慢，会堆积大量待执行委托。缓解办法是在委托里先检查_pictureBox.IsHandleCreated，并加一个标志位，上一帧没画完就不提交新帧。Thread.Sleep(30)是个粗糙的帧率控制，想更精确可以用Stopwatch计算每帧耗时动态调整睡眠时间。多人姿态估计时，后处理 NMS 会返回多组结果，绘制前需要先按置信度排序，否则画出来的人体顺序不稳定，视觉上会闪烁。
3.4 界面布局与性能：PictureBox 模式、双缓冲和分辨率选择
WinForm 里显示视频无非两种方式：PictureBox.Image整体替换，或者在Panel上自绘。对实时摄像头来说，整体替换更简单，但每次都创建新Bitmap会有 GC 压力。更好的做法是在初始化时创建一个固定大小的Bitmap，每次只把帧数据DrawImage进去。
_pictureBox.DoubleBuffered = true; // 关键：减少闪烁 _pictureBox.SizeMode = PictureBoxSizeMode.Zoom;DoubleBuffered是 WinForm 控件自带的双缓冲开关，打开后能明显减少绘制闪烁，代价是稍微增加内存占用。SizeMode用Zoom等比缩放，但要注意这会引入第二次缩放，导致骨架线和你看到的位置又有偏差。更稳妥的做法是把PictureBox的尺寸设成和采集分辨率一致，让SizeMode为Normal。
如果要在界面里同时显示每个人的检测框和置信度，常见的做法是旁边放一个DataGridView，把每个人的置信度、关键点数填进列表里。这时候如果你习惯把List<T>直接绑定到DataSource，记得处理布尔值显示问题——比如把“是否检测到左手腕”这种 0/1 列转成DataGridViewCheckBoxColumn，否则默认显示成数字，看着别扭。
4. 部署避坑记录：5 个让 WinForm 姿态估计翻车的常见问题
这套方案我前后调过三轮，踩过的坑远不止一个。以下这五个问题基本覆盖了 90% 的 C# WinForm 部署姿态估计翻车现场，每一条都是“现象 → 原因 → 解决”的路线，希望能帮你少走一段弯路。
4.1 AccessViolationException (C0000005) 一出来，先查平台目标
现象：程序在别人电脑上跑得好好的，换到你这边启动后直接抛AccessViolationException，错误码0xC0000005，关键信息是“试图读取或写入受保护的内存”。在 C# 调用 C++ 的 Native 库时，这个问题出现频率极高。
原因：ONNX Runtime 的 Native 层是 C++ 写的，它要求进程架构和 Native 库一致。你工程是x86，但 NuGet 默认拉的是x64的 Native 库；或者你下载了 GPU 版运行库，机器上 CUDA 环境不对，Native 层初始化失败，最后暴露成访问违规。还有一种是 Debug 模式下混用了 Release 版 Native 库，导致 ABI 不一致。
解决：把解决方案平台和项目属性 → 生成 → 平台目标都统一改成x64，然后清空解决方案重新编译。如果还报错，在App.config里加上：
<configuration> <runtime> <legacyCorruptedStateExceptionsPolicy enabled="true" /> </runtime> </configuration>这是在 .NET Framework 4.6.1 以下项目里让托管代码捕获 Native 异常的老办法，新版 .NET 5+ 一般不需要。最后一步是检查目标机器是否装了 VC++ 2019-2022 x64 运行库，很多工控机是精简系统，缺这个库时 C++ 层直接崩。
4.2 检测框正确但关键点全部偏移：前后两套 letterbox 参数没统一
现象：框框得很准，但是骨架整体偏向右下方，尤其是人体边缘的关键点，偏移量越靠近图片边缘越大。
原因：模型训练时对图片做了 letterbox，推理端预处理也做了 letterbox，但后处理画框时用的映射参数和画点用的映射参数不是同一套——比如预处理里画框用了宽高比缩小的方式，画点时用了直接拉伸的方式，两套 scale 不一致，点和框就对不上。还有一种情况是预处理里填充值不是 114，但画点时用的 padding 偏移量还是按 114 那套算的。
解决：把ratio、padW、padH三个值放在一个PreprocessResult类里，同时传给画框和画点的函数，保证只用一套参数。我习惯在调试阶段把关键点和框映射到图上并输出文本日志，对比(原始坐标 - 反算坐标)的差值，差值超过 2 个像素就说明映射关系有矛盾。
4.3 输出张量维度对不上，直接 IndexOutOfRange
现象：模型加载正常，推理也不报错，但在解析输出时抛出IndexOutOfRangeException，或者拿到的坐标全是 NaN 和极小数。
原因：你按 [1, 56, 8400] 的合并张量写的解析，但当前这个 onnx 输出是三个独立张量 [1, 4, 8400]、[1, 17, 8400]、[1, 17, 8400]。很多仓库在导出 YOLOv11-Pose 时做了结构优化，把输出拆得更干净。上一个是合并格式是因为导出时没有简化，换成simplify=True后输出结构直接变了。
解决：不做任何假设，启动时先执行 2.1 节的打印代码，把所有输出张量名称和维度列出来。然后根据Dimensions[1]动态判断：如果shape[1] == 56，走合并解析；如果输出里存在[1, 17, 8400]，则分别解析三个张量。还可以在配置类里加一个OutputType枚举，Merged或Split，避免每次推断。
4.4 多人场景骨架互相串：关键点没按实例分组
现象：两个人站在画面里时，骨架线从第一个人肩膀直接连到第二个人手腕，交叉得一塌糊涂。
原因：关键点后处理时没有按 instance 分组。合并张量里每个 anchor 对应一个实例的 51 个关键点，但如果你在解包时把 17 个点的 x、y、score 拆开读取，然后按全局索引重新组合，就会出现 A 实例的肩膀坐标配 B 实例的手腕坐标的问题。NMS 之后，每个 instance 的索引必须保留原始 anchor 位置。
解决：解析时以 anchor 为单位，把 51 个值（或拆分输出下的三组 17 个值）一次性读进PoseInstance类，NMS 过滤后才允许做连线。同时 NMS 参数要调整：检测模型常用 class-agnostic 的 NMS，姿态估计建议用每个实例独立 NMS，两个高度重叠的人体实例不能因为 IoU 高就被干掉一个，否则画面里永远只有一个人。
4.5 推理速度慢到没法看：Debug 模式、线程数和动态 shape 的锅
现象：单张 640×640 图在 Python 里跑 20ms，在 C# WinForm 里却跑 200ms，摄像头画面像幻灯片。
原因：最常见的三个原因——编译成了 Debug 模式（JIT 不做优化，数组边界检查全开）；InferenceSession每次推理时重新创建；模型导出时用了动态输入维度，batch=1也会触发动态 shape 的额外开销。还有一点，OnnxRuntimeNuGet 包的 CPU 版本默认使用所有逻辑核心，在工控机上线程间切换反而更慢。
解决：发布时切 Release + x64；InferenceSession在窗体初始化时创建一次，全程复用；导出 onnx 时固定imgsz=640，避免动态维度。线程数可以在SessionOptions里设置：
options.AppendExecutionProvider_CPU(1); // 参数控制 CPU 线程数这个参数在低端机器上设置为 2 或 4，比默认值稳定很多。还有个容易被忽略的点：OpenCvSharp 的Mat如果没释放，内存在几百帧后会爆，必须在每帧处理完后Dispose，尤其是摄像头画面里的Mat，不要等 GC 来回收。
5. 换模型之前先做这几件事：导出参数、量化选择和耗时验证
很多人拿到源码包只跑通默认模型就开始改界面，等到要换自己的数据集时才发现模型导出参数不对，回到 C# 端各种报错。如果你只想要现成模型，这章可以跳过；如果你打算换关键点类别、换模型大小，这章是给你准备的。
5.1 用 PyTorch 导出适合 C# 部署的 ONNX：opset、simplify 与 imgsz
Ultralytics 模型导出一般用官方命令，但有几个参数必须经手改，否则导出结果在 C# 里跑起来很别扭。最关键的是opset不能太高，ONNX Runtime 对 opset 14~17 支持最稳定；simplify=True可以去掉大量冗余算子，减少模型体积和推理时间；imgsz固定成训练时的尺寸，别写动态值。
from ultralytics import YOLO model = YOLO("yolov11n-pose.pt") model.export( format="onnx", opset=17, imgsz=640, simplify=True, # 去掉 reshape 等冗余算子，输出结构更规整 dynamic=False # 固定输入尺寸，避免动态 shape 的额外开销 )导出后建议用onnxruntime直接跑一次输入检查输出维度。如果你要做 int8 量化，量化的模型通常体积小一半，CPU 推理能快 20%-30%，但姿态估计关键点坐标是回归任务，int8 量化带来的精度损失比检测框明显得多。我的经验是：先 fp32 跑通全流程，再尝试量化；量化后关键点偏差超过 5 像素就放弃 int8，改用 fp16（CPU 不吃 fp16，收益不大）或干脆保持 fp32。
5.2 三件套验证：同一张图对比、耗时 Benchmark、长时间稳定性
换完模型别直接上摄像头，先做三件事。第一件是用同一张测试图分别跑 Python 端和 C# 端，把两边的 17 个关键点坐标打印出来对比，误差在 0.5 像素以内说明前处理和后处理完全一致。第二件是耗时基准，C# 端用Stopwatch连续跑 100 帧，前 5 帧是预热（ONNX Runtime 第一次推理会做内存分配），记录后面的平均耗时。第三件是稳定性，摄像头连续跑 30 分钟，看内存占用是否持续增长，GDI 对象数是否稳定。
var sw = System.Diagnostics.Stopwatch.StartNew(); for (int i = 0; i < 100; i++) { var output = _session.Run(inputs); } sw.Stop(); Console.WriteLine($"平均耗时: {sw.ElapsedMilliseconds / 100f} ms");这三件事做完，你才知道瓶颈是前处理、推理还是后处理。我的习惯是在发布版里留一个--benchmark命令行参数，方便现场同事直接在客户机器上跑性能基线，不用重新换程序。每个人做部署的路径不同，但把模型结构摸清、把映射参数统一定义、把 UI 跨线程处理好，这套方案就能从 demo 变成能交付的东西。希望这一路踩过的坑能帮到你。
本文还有配套的精品资源，点击获取
