在.NET圈子里C#调YOLO做目标检测最让人头疼的往往不是推理精度也不是检测速度而是内存。7×24小时跑着跑着内存从300MB涨到1GB再到3GB最后进程被系统干掉或者卡死重启这种情况我见过太多次了。这篇文章就是要把C#YOLO这套组合的内存账一笔一笔算清楚从技术栈选型到代码写法到运行时配置全部围绕“长期稳定运行内存控制在200MB左右”这个目标展开。文章适合的人群很明确用C#做桌面工具、工控机程序、边缘盒子应用已经在调YOLO或者正准备调YOLO并且被内存问题折磨过的人。如果你是刚接触YOLO的入门用户这篇文章也能帮你从一开始就避开那些坑省掉后面几个月的排查时间。1. 先说结论这个内存问题到底从哪里来1.1 7×24小时场景的真实内存增长轨迹先说一个我反复观察到的现象很多人接YOLO之后本地跑一张图片测一次内存表现还挺正常大概200~400MB测完就关了根本看不出问题。但是一旦放到7×24小时不间断运行的场景里比如摄像头轮询、定时抓拍分析、生产线视觉质检内存就像慢性病一样一个小时涨几十MB然后每天翻一倍两三天后进程就开始喘了。为什么会这样核心原因是单次推理泄漏的量不大但架不住高频次。假设程序每30秒做一次推理一天就是2880次如果每次泄漏5MB一天就是14GB的垃圾堆积。哪怕其中大部分能被垃圾回收只要有一小部分对象被无意间引用住内存曲线就是一条持续向上的斜线。从我的经验看这种增长通常不是某个“惊天大坑”造成的而是三四个小问题叠加的结果。每个看起来都很普通一个List忘记清理、一个Bitmap没有Dispose、一个Session频繁重建……但合在一起就是7×24小时场景下必然爆发的内存灾难。1.2 200MB意味着什么一行行算内存账很多人觉得“稳定在200MB”是个挺宽泛的目标其实不是。咱们把进程的内存账拆开看看就知道200MB是个什么概念。一个典型的C#进程跑起来之后大致由这么几块构成CLR运行时与JIT相关大约15~30MB如果发布时用ReadyToRun可以压到更低。托管堆上的业务对象、缓存、字符串、检测结果集合大约30~60MB取决于你的代码怎么组织。模型权重本身YOLOv8n的FP32权重约6MB运行时会加载到内存或做内存映射s版本约22MBl版本就奔着40~50MB去了。推理引擎的原生缓冲区和线程栈空间大约20~50MB这和Session数量、线程数直接相关。图像解码、预处理、输出Tensor的临时缓冲如果不复用这一块很容易超过50MB。这几项加起来你会发现200MB其实是相当紧凑的预算。你没有任何挥霍空间每一处分配都得命中要害每一块缓冲区都得活得好好的。这也就意味着那种“反正内存才几百MB不管了”的心态在这个目标下绝对行不通。1.3 三个最常见的“内存元凶”我总结了一下在C#接YOLO的场景里最常见的三个内存问题就是反复创建InferenceSession。很多人为了方便每次推理都new一个Session。一个Session初始化时要把模型加载、算子图优化、创建内部内存分配器这个动作本身就非常重。Session用完不释放或者释放不及时内存就会持续堆积。这是所有问题里最要命的一个。图像缓冲区没有Dispose或没有复用。C#里接摄像头、接图片最常用的是Bitmap或Mat。很多人写了new Bitmap()之后忘记Dispose()或者干脆每次处理都新建一个byte[]来装像素数据。一帧图像可能就是几MB到几十MB每天几千帧托管堆的压力非常大。NMS后处理里无界增长的集合。YOLO输出的原始结果是几百个候选框后处理时需要用NMS过滤。很多人直接在方法里新建List、做大量LINQ操作如果这些List被静态变量引用或者事件订阅没有解除就会一直堆积。这个最隐蔽因为单次运行根本看不出来但是一旦跑几个小时问题就非常明显。这三个元凶几乎解释了90%的C#YOLO内存失控案例后面我会逐个给出解法。2. 技术栈选择先选对再谈优化2.1 三条常见路线的内存特点对比C#调用YOLO主流路线就几条ONNX Runtime、OpenCvSharp的Dnn模块、OpenVINO的C#封装。我先把三者的内存表现和技术特点做一个横向对比这决定了你后面优化的工作量差异。技术路线内存占用特点线程控制能力集成复杂度适用场景ONNX Runtime内存分配行为规范支持内存模式优化缓冲复用方便强可以精确设置算子并行线程数中需要自己处理输入输出Tensor长期运行、内存敏感场景首选OpenCvSharp Dnn依赖Mat生命周期管理稍不注意就泄漏弱底层线程控制主要交给OpenCV内部低API上手很快快速验证、临时工具OpenVINO C# API推理性能强但端侧内存分配策略略“重”中支持配置但需要理解它的调度模型中高环境配置相对复杂对性能敏感、且能接受更多配置成本的场景这里要说明一下我并不是说其他两家不能做优化而是说从“内存控制”的精细化角度来看ONNX Runtime的API设计更透明。它的SessionOptions可以直接控制线程数、内存优化模式输入输出Tensor也可以自己复用缓冲区。相比起来OpenCvSharp的Mat机制虽然灵活但Dispose时机完全靠自律在大流量的7×24小时场景里很容易翻车。2.2 为什么我优先推荐ONNX Runtime CPU版很多人在选型的时候习惯性觉得“CUDA加速好”但在内存敏感场景下CPU版反而是更理性的选择原因很实在。第一CPU版不涉及显存和宿主内存的联动内存模型更单纯。GPU推理过程中CPU内存和显存之间要做频繁的Tensor拷贝一旦某个环节没有同步等待或者缓冲区没复用内存就会像过山车一样起伏。CPU推理虽然速度慢一些但内存曲线更容易压平。第二ONNX Runtime的SessionOptions里有个EnableMemoryPattern开关开启之后推理引擎会分析模型的输入输出模式复用内部的缓冲区块减少重复分配。这个优化对长期运行非常友好实测下来能把内存抖动幅度压下去不少。第三ONNX Runtime的线程控制很直观。你可以直接设置IntraOpNumThreads和InterOpNumThreads把线程数量限制在一个合理范围。不要小看线程数C#里每个线程默认栈就有1MB左右模型内部算子如果开了几十个线程光是线程栈就能吃你几十MB内存。控制住线程数就等于控制住了这部分内存的大头。所以我自己做这类项目的时候第一选择永远是ONNX Runtime的CPU包而不是先折腾GPU。先把CPU稳定跑起来内存达标了再考虑要不要加GPU这是更稳妥的路线。2.3 模型选型模型文件本身就占内存预算接着说一下模型本身。YOLO有多个版本n、s、m、l、x体积和精度递增但很多人忽略了这对内存的直接影响。以YOLOv8系列为例FP32精度下YOLOv8n权重约6MB推理时运行内存占用在20~30MB左右。YOLOv8s权重约22MB推理时运行内存占用在50MB左右。YOLOv8m权重约49MB推理时运行内存占用接近100MB。如果你的目标是200MB稳定运行用n还是s就是一道分水岭。我在一个边缘盒子项目里测试过跑YOLOv8s的模型光模型加载和推理缓冲就占了接近80MB再加上图像处理、托管对象和运行时开销非常逼近预算上限。换成YOLOv8n之后省出来的30~40MB让整个系统从容了很多。另外如果你对精度要求没那么极端可以考虑INT8量化的模型。同样的模型结构INT8权重基本是FP32的四分之一推理时的中间缓冲也会小一圈。代价是精度会掉一点但如果你的业务场景是“检测大目标”“识别安装状态”“判断设备有没有开机”这种宽泛类别INT8完全够用。量化模型需要一些转换工具但收益相当直接内存预算难题立刻缓解。3. 让内存7×24小时稳定的核心策略3.1 单例Session最值得先做的一步先解决那个最大的问题InferenceSession必须全局唯一。我见过最夸张的写法是在每次推理时new一个Session用完也不释放。这相当于每来一帧图像就把整个模型重新加载一遍内存不被撑爆才怪。Session的初始化开销非常大内部要处理模型图的解析、算子调度方案的生成、内存分配器的准备这个流程走一遍就是几十MB的临时分配。正确做法是整个进程生命周期内只创建一次Session所有推理共享这一个实例。代码上可以写成一个单例或者用依赖注入容器注册为Singleton。这里给一个最基础的封装public sealed class YoloDetector : IDisposable { private readonly InferenceSession _session; private readonly object _lock new object(); public YoloDetector(string modelPath) { var options new SessionOptions { GraphOptimizationLevel GraphOptimizationLevel.ORT_ENABLE_ALL, EnableMemoryPattern true, IntraOpNumThreads 2, InterOpNumThreads 1 }; options.AppendExecutionProvider_CPU(0); _session new InferenceSession(modelPath, options); } public void Dispose() { _session.Dispose(); } }这里有个细节值得展开IntraOpNumThreads 2。这个参数决定了一个算子内部并行计算的线程数。如果你的机器是4核8线程理论上可以写4但内存敏感场景下我建议从2开始调。YOLO模型在CPU上跑算子内部的并行度提升对总耗时的影响远没有你想象的那么大但是每多一个线程就多一截栈内存和线程上下文开销。2个线程是性能和内存的平衡点。EnableMemoryPattern true也必须打开。这个开关允许ONNX Runtime在多次推理时复用之前已经分配好的内存块而不是每次从头分配。它专门针对“同一模型反复推理”的场景设计的和我们的7×24小时目标完美匹配。3.2 用ArrayPool和固定缓冲区管理图像和中间数据Session解决了大头的常量内存接下来要对付的是每次推理都会产生的临时内存。图像解码、像素拷贝、归一化、Tensor构建这一整套流程如果每次都是new托管堆的压力会非常大GC频繁触发CPU占用也会跟着飙高。思路其实很朴素既然每张输入图片的尺寸是固定的那所有中间缓冲区的尺寸也就是固定的。与其反复申请不如提前分配好练完一帧又把它们“还回去”。.NET框架里有一个非常适合这个场景的东西System.Buffers.ArrayPoolT。它维护了一个数组池你Rent出来的数组用完Return回去避免每次new byte[]的开销。我用一个实际例子说明。假设你的YOLO模型输入是640×640×3那么每次推理都需要一个长度为1,228,800的float数组来装归一化后的输入数据。常规写法是每次new float[1228800]然后交给GC处理。用ArrayPool的写法是这样float[] inputBuffer ArrayPoolfloat.Shared.Rent(640 * 640 * 3); try { // 用inputBuffer填充像素数据做归一化 // 构建Tensor推理取结果 } finally { ArrayPoolfloat.Shared.Return(inputBuffer); }这里要注意Rent出来的数组长度可能比请求的长度大不能假设它正好是你要的长度。我一般会单独记录一个_requestedLength字段填数据时严格按这个长度来不要越界。同样的思路也适用于图像解码。如果每次从摄像头拿帧都new Bitmap内存抖动明显。我会用一个固定尺寸的Bitmap或byte[]作为中转先把摄像头数据LockBits到非托管区域再复制到复用好的托管缓冲里整个过程不产生多余的大对象。这一步做完托管堆上的大对象数量会急剧下降GC的压力会小一个量级。3.3 NMS后处理藏着最隐蔽的泄漏点接下来这个坑特别隐蔽因为它不会在单次调试里露馅只会在长时间运行后让你抓狂。YOLO的原始输出是一个巨大的Tensor比如8400个候选框每个框有85个值框坐标置信度80个类别概率。你需要从里面筛出置信度高的框再做NMS去除重叠框。这个过程如果写得随意会产生非常多的中间对象。我见过几种常见写法每一个都踩雷用LINQ的Where、OrderByDescending筛选候选框每次操作都产生一堆匿名对象和闭包。每次循环都new Listfloat()或者new RectangleF[]。用一个静态的List存检测结果却只往里面Add从不Clear。这些代码在单帧跑的时候毫无问题但7×24小时一跑那些看似不起眼的小对象就会像雪球一样滚大。有些朋友排查半天发现内存涨到1GB多转储文件里一看全是某个ListDetection的实例这就是典型的无界增长。我的做法是把NMS用到的所有中间数据结构都提成复用对象。候选框数组固定长度排序用Array.Sort而不是LINQ的OrderByDescending结果列表复用同一个每帧开始前先Clear()。大致结构如下private Detection[] _candidates new Detection[MAX_BOX_COUNT]; private ListDetection _results new ListDetection(); private int _candidateCount 0; private void PostProcess(float[] output, int count) { _results.Clear(); // 过滤低置信度框填充到_candidates数组 // 用Array.Sort按置信度排序 // 遍历做IoU过滤把保留的框Add到_results // 调用方直接读取_results }NMS算法本身不复杂但纯手写一遍需要注意几个细节IoU计算时坐标要转换到原始图像尺寸排序是降序排列重叠框的阈值一般设在0.4~0.5之间。这些细节直接影响结果质量但今天咱们重点是内存先说结论集合复用比算法本身更影响长期运行的稳定性。代码里的_candidates数组是固定分配的排序是原地排序除了_results本身整个NMS过程几乎不产生新的引用类型对象托管堆的压力就小了非常多。3.4 线程与GC配置坐实200MB的关键参数Session和缓冲区都控制好了之后还有一个容易被忽视的环节GC模式和线程数量的全局配置。这两个配置写在项目文件里很多人从头到尾都没看过。先说GC模式。C#的运行时默认在大多数项目里用的是Workstation GC但如果你发布的是服务器应用或者默认配置不小心开启了Server GC情况就完全不同。Server GC会为每个逻辑处理器创建独立的托管堆多个堆意味着更大的预留内存和更频繁的并行GC。在单进程、单场景的推理程序里这纯粹是浪费。强制关闭Server GC用Workstation GC的并发模式内存占用会更紧凑。配置方式是在runtimeconfig.json里写明{ runtimeOptions: { configProperties: { System.GC.Server: false, System.GC.Concurrent: true } } }再说线程数。除了IntraOpNumThreadsC#自己的线程池也要限制。ONNX Runtime内部调用算子时不一定都走C#线程池但你的代码里如果有Task.Run、Parallel.For之类的用法线程池会智能调整线程数默认可能拉高到几十个。在内存敏感场景下我会在Program.cs的入口处做一个明确的限制ThreadPool.SetMinThreads(2, 2); ThreadPool.SetMaxThreads(4, 4);这个限制看着粗暴但它保证了线程池不会因为突发流量而疯狂增线程。每个线程的默认栈大小是1MB20个线程就是20MB对一个200MB预算的程序来说这可不是小数目。还有一个很多人都忽略的小技巧在主线程之外确保推理过程只在单一线程内执行。如果有并发请求别让它们同时去调用同一个Session因为ONNX Runtime的Session本身不是完全线程安全的并发调用要么排队要么出错。要么你加锁要么用SemaphoreSlim(1,1)把推理过程串行化。串行化还有一个额外好处内存曲线更好看因为同一时间只有一组缓冲在工作。4. 实操一个内存稳定的YOLO检测器完整实现4.1 单例检测器的骨架代码前面讲了思路这里给一个完整的、可以直接拿去改的检测器骨架。它包含了单例Session、固定缓冲区、输出复用等所有关键点。public sealed class YoloDetector : IDisposable { private readonly InferenceSession _session; private readonly int _inputWidth 640; private readonly int _inputHeight 640; private readonly float[] _inputBuffer; private readonly float[] _outputBuffer; private readonly SemaphoreSlim _gate new SemaphoreSlim(1, 1); public YoloDetector(string modelPath) { var options new SessionOptions { GraphOptimizationLevel GraphOptimizationLevel.ORT_ENABLE_ALL, EnableMemoryPattern true, IntraOpNumThreads 2, InterOpNumThreads 1 }; options.AppendExecutionProvider_CPU(0); _session new InferenceSession(modelPath, options); int inputLength 1 * 3 * _inputHeight * _inputWidth; _inputBuffer new float[inputLength]; // 输出长度可以通过_session的输出metadata动态获取 // 这里以8400候选框做示例实际请根据模型输出维度换算 _outputBuffer new float[8400 * 85]; } public ListDetection Detect(Bitmap image) { _gate.Wait(); try { Preprocess(image); var inputTensor new DenseTensorfloat(_inputBuffer, new[] { 1, 3, _inputHeight, _inputWidth }); var inputs new ListNamedOnnxValue { NamedOnnxValue.CreateFromTensor(images, inputTensor) }; using (var results _session.Run(inputs)) { var output results.First(r r.Name output0).AsTensorfloat(); output.ToArray().CopyTo(_outputBuffer, 0); // 注意上面CopyTo稍显浪费生产环境建议直接指向output.Buffer return PostProcess(_outputBuffer); } } finally { _gate.Release(); } } public void Dispose() { _gate.Dispose(); _session.Dispose(); } }这里有个细节要说清楚using (var results _session.Run(...))。Run返回的对象集合实现了IDisposable它会持有输出Tensor的原生内存如果不用using包住输出缓冲不会及时释放。很多人漏了这一步导致输出Tensor的缓冲泄漏这在长期运行场景下是致命的。4.2 图像预处理少拷贝用指针输入图像到_inputBuffer的过程是另一个容易产生垃圾的地方。常规做法是用Bitmap.GetPixel挨个像素读取但这个API极慢而且会创建大量Color对象不可取。正确姿势是LockBits直接锁住像素缓冲区然后用指针操作。private void Preprocess(Bitmap image) { var rect new Rectangle(0, 0, image.Width, image.Height); var bmpData image.LockBits(rect, ImageLockMode.ReadOnly, PixelFormat.Format24bppRgb); try { unsafe { byte* ptr (byte*)bmpData.Scan0; int stride bmpData.Stride; float scaleX (float)_inputWidth / image.Width; float scaleY (float)_inputHeight / image.Height; // 这里要做的是缩放 归一化 格式转换(BGR-RGB) // 推荐先用Canvas/GDI画到640x640的中间图上再做像素拷贝 // 下面简化演示单点采样逻辑 for (int y 0; y _inputHeight; y) { for (int x 0; x _inputWidth; x) { int srcX (int)(x / scaleX); int srcY (int)(y / scaleY); byte* pixel ptr srcY * stride srcX * 3; int idx y * _inputWidth x; _inputBuffer[idx] pixel[2] / 255f; // R _inputBuffer[idx _inputWidth * _inputHeight] pixel[1] / 255f; // G _inputBuffer[idx _inputWidth * _inputHeight * 2] pixel[0] / 255f; // B } } } } finally { image.UnlockBits(bmpData); } }这种方法虽然用了不安全代码但优势非常明显除了_inputBuffer整个预处理过程没有产生任何托管大对象。LockBits的内存来自非托管区域UnlockBits之后会释放。只要using或者try-finally保证释放这块内存就不会参与GC周期也不会造成托管堆压力。需要提醒的是如果你的输入尺寸和原图比例不一致直接缩放会导致检测框坐标偏移。生产环境建议用GDI先把图像等比缩放到合适尺寸再填充到640×640的画布中灰边补零。这里为节省篇幅只展示了核心逻辑大家在实际做的时候要把缩放和填充的步骤补全。4.3 推理与输出复用代码里我用了output.ToArray().CopyTo(_outputBuffer, 0)这句其实有一点浪费ToArray()本身会生成一个新的数组。更优的写法是直接访问output.Buffer属性如果输出Tensor是连续内存可以直接把它当成数组用。var outputData output.Buffer; // 如果Buffer类型是float[]可以直接用 Array.Copy(outputData, _outputBuffer, _outputBuffer.Length);或者更激进一点如果确认每次输出Tensor都会指向同一个内部缓冲可以直接读取outputData里的数据而不再拷贝到_outputBuffer。但这样做有一个风险一旦results被Dispose输出缓冲可能被回收你就不能再持有这些数据了。所以稳妥起见我倾向于拷贝一份到自己的固定数组里代价是一次1MB左右的浅拷贝但换来了内存管理的确定性。值得多提一句results集合本身的问题。session.Run返回的集合不是简单的数组它后面可能挂着原生内存引用。你必须在finally或者using里把它释放掉。很多内存泄漏排查半天最后发现是这里扔了一堆没有Dispose的IDisposable对象。4.4 内存监控装满不涨才叫稳定程序写完之后别急着就扔到生产环境。先给程序加一个简单的心脏监测让它在日志里记录内存变化这样就拥有了“问题发生时先有报告”的主动性。我一般会在后台线程里跑一个轻量监控器private async Task MonitorMemoryLoop() { var process Process.GetCurrentProcess(); while (!_cancellation.IsCancellationRequested) { long managed GC.GetTotalMemory(false); long workingSet process.WorkingSet64; long privateMem process.PrivateMemorySize64; _logger.Info($WorkingSet{workingSet / 1024 / 1024}MB, ManagedHeap{managed / 1024 / 1024}MB, Private{privateMem / 1024 / 1024}MB); // 如果托管堆持续超过阈值主动GC if (managed 150 * 1024 * 1024) { GC.Collect(2, GCCollectionMode.Optimized, true, compacting: true); } await Task.Delay(TimeSpan.FromMinutes(5), _cancellation.Token); } }这里有个分寸不要每一帧都调用GC.Collect()。GC的成本很高频繁调用反而拖慢推理速度增加CPU占用。我的策略是设置一个阈值比如托管堆超过150MB才触发一次强制回收正常情况让GC自己工作。监控的价值在于你可以在运行一天之后看日志确认内存曲线是平的还是斜向上的。另外WorkingSet64会包含很多操作系统层面的东西比如内存映射文件、线程栈等它不是纯粹的“程序泄漏”指标。判断内存泄漏更要看PrivateMemorySize64和托管堆的大小。如果托管堆稳定但Private持续上涨那问题大概率出在非托管资源上比如Session未释放、图像未UnlockBits等。4.5 项目发布配置别忽略这些开关最后把项目层面的配置一并说了。发布.NET应用的时候控制台程序的默认配置不一定适合内存敏感场景。第一runtimeconfig.json里把System.GC.Server设为false。这是上一节说的这里再强调一下因为很多工控机是多核的默认的Server GC会在多核机器上自动开启非常占内存。第二发布的时候建议启用ReadyToRun。这个选项会让JIT的编译过程提前完成省去运行时的JIT开销对启动内存和启动速度都有帮助。PropertyGroup PublishReadyToRuntrue/PublishReadyToRun /PropertyGroup第三如果你的程序不需要反射、不需要动态程序集加载可以考虑启用裁剪Trimming。这个收益在自包含部署下尤其明显可能直接省掉十几MB的运行时零头。但裁剪有风险如果你的代码里用了反射或者动态类型要仔细测试。还有一个和模型相关的配置ONNX Runtime支持把模型文件预加载到内存或者使用内存映射。如果是内存映射模式模型文件本身不算进工作集但首次访问会有缺页加载。我的建议是内存预算非常紧张时用普通加载让模型权重常驻内存代码行为更稳定可控。5. 常见问题与排查技巧实录5.1 内存一直涨但GC不回收是怎么回事这是最常遇到的问题。你明明已经把该释放的都释放了但GC.GetTotalMemory还在缓慢上涨。这时候十有八九是存在“根引用”也就是某个对象被静态字段、事件订阅器、或一个长生命周期对象一直持有GC扫描的时候发现它还在被引用自然不回收。常见的坑是事件订阅。摄像头采集到新帧后触发回调事件如果回调里注册了匿名方法或者lambda而你在程序退出或者重建采集器的时候没有-注销那么采集器会一直持有回调方法的引用回调里用的所有对象都不会被释放。排查方法有两种。一种是靠直觉尽量多检查自己的静态变量和事件订阅另一种是麻烦但精准的用内存转储分析。我用后面的方式定位过好几次问题效率极高。5.2 Session释放了内存也不降怎么回事很多朋友会在收到“内存过高”的告警后把Session Dispose掉却发现内存纹丝不动。这个现象很迷惑但原因其实很清晰。Session的内部原生内存被释放之后内存不会立刻归还给操作系统。常见的运行时实现里malloc/free的小块内存可能继续留在进程的堆里等待复用。你看到的WorkingSet64确实没降但进程内部已经有空间可以重新分配了。怎么看是“真泄漏”还是“内存没还回去”方法是用性能计数器观察Gen2 heap size如果托管堆里的Gen2垃圾不断增加就是真泄漏如果Gen2很稳定只是WorkingSet高那是运行时在高水位上挂着不是泄漏。如果后者一般不用过分担心只要总内存不突破你的预算就行。5.3 开了GPU后内存涨得比CPU还快这个情况我遇到过好几次。NVidia GPU推理时输入输出需要在CPU内存和显存之间复制ONNX Runtime的CUDA执行提供方会为每个推理分配临时的CPU端缓冲区。如果你用的是CUDA 11的旧版ONNX Runtime内存管理还有不少坑最容易出现的是显存池和CPU内存池各自为政导致CPU内存也跟着涨。如果确认必须用GPU建议多测几个版本的ONNX Runtime。不同版本的内存表现差异巨大有些版本原生内存释放很果断有些则像“铁公鸡”一样把内存攥在手里。还要确保每次Run的结果都及时释放特别是输出Tensor千万别缓存进静态字段。5.4 快速定位真凶转储文件分析如果你怀疑自己的程序有泄漏但又说不出来在哪最直接的办法是抓内存转储然后分析对象分布。用.NET自带的工具链在程序内存涨到高位时执行dotnet-dump collect -p pid dotnet-dump analyze dumpfile进入分析交互界面之后我一般先执行dumpheap -stat看看哪些类型堆里的对象特别多。如果发现某个自定义的检测结果类有几十万个实例那这个类的引用链条就是泄漏的核心。再用gcroot查看它的引用路径很快就能定位到是哪个集合、哪个事件把它死死拽住了。这里有一个非常直接的建议排查内存泄漏不要猜要抓证据。你对着代码猜两小时效率远不如抓一次转储看5分钟。6. 长期运行的观测与维护建议6.1 长期运行要盯哪些指标程序稳定跑起来之后不是说就万事大吉了日常运维还是要盯几个关键指标。我的习惯是每分钟记录一次日志保留7天这样一旦内存异常可以从历史曲线倒推出问题是从什么时候开始的。重点盯这几个WorkingSet64进程整体内存占用是最直观的指标。PrivateMemorySize64进程私有的内存不包含共享图像缓冲等判断统一性好一些。Gen2 heap size托管堆里大对象堆的大小。这个值如果持续上涨说明有大对象在堆积。ThreadPool.ThreadCount线程数是否被异常拉高。每5分钟记录一次推理耗时如果内存压力大导致GC频繁推理耗时也会同步飙升这是一个额外信号。如果这些指标在24小时内都保持平直只有轻微的波动说明程序的内存系统基本健康。如果某个指标每天的收盘价都比前一天高哪怕只高5MB都要警惕因为它意味着存在缓慢泄漏再过几天就会爆发。6.2 多路视频或并发请求时的内存控制如果你的7×24小时系统不只是单路推理而是多路摄像头或者多个业务请求共用一个进程内存控制会更复杂一些。最重要的原则是限制并发推理数。每一路推理都要占用一份输入输出缓冲再加上ONNX Runtime内部的执行状态如果同时跑8路推理光瞬时缓冲就能轻易突破200MB预算。我通常用前面代码里那个SemaphoreSlim把所有推理请求排队让并发数收敛到1或者2。代价是响应时间变长但换来的是内存的确定性。另一个策略是把模型复制为多个Session实例每个实例服务于一路摄像头。这个方案适合总内存预算较宽裕的情况因为多个Session会共享模型权重但推理缓冲是独立分配的。在200MB的严格预算下我建议先排队限流而不是复制Session。6.3 可以继续压缩内存的方向上面这套方案做完正常能把进程压到200MB左右。如果你还想进一步压有几个方向可以做。第一把模型转成INT8。这样模型加载本身少占用几十MB推理时的中间Tensor也变小内存收益非常直接。第二进一步压低ONNX Runtime的内部线程数。从2降到1内存会更少但推理耗时可能明显增加。这个要根据实际帧率要求来权衡。第三使用Tensor的复用或推理引擎层面的缓存。ONNX Runtime的RunOptions也可以复用把new RunOptions()改成提前创建并在每次推理传入同一个实例能减少一些分配。第四裁剪未使用的模型输出。如果模型导出时保留了很多后处理用不到的中间层输出可以在导出模型阶段去掉减少输出缓冲的大小。YOLO的原始输出已经是单输出头但如果用的是复合模型这个优化空间就很可观。最后再分享一个我踩过的坑讲一个真实的教训希望能帮大家少走弯路。我之前在某个工控机上做视觉检测程序跑了两天就内存爆掉反复查代码、看日志一直找不到原因。最后用转储文件一分析发现罪魁祸首居然是一个看起来人畜无害的ListRectangleF。当时我在后处理里写了一个静态的检测结果集合想着“反正只有一路摄像头不会有并发问题”。结果某天代码改版之后摄像头采集回调的速率略有波动某些帧的检测结果还没被消费完下一帧又往里追加了集合就永远没有清空的机会。48小时之后那个List里积累了上百万个矩形对象内存就是这么被吃光的。修好之后我就给自己定了一条规矩只要会用到的集合要么在方法内部局部创建并确保生命周期最短要么就做成固定容量的复用结构绝不允许一个List被长生命周期持有而不受控。这条规矩到今天一直在帮我避坑。C#调YOLO的内存优化不是一两个技巧就够的也不可能只靠调一个参数就解决。它需要你在模型选型、Session管理、缓冲复用、GC配置、并发控制几个层面同时下功夫。各个层面都做到位200MB不是一个神话而是一个可预期的稳定结果。希望这篇指南能让你少走点弯路早点和“内存泄漏”这四个字说再见。