简介：面向需要在Windows CPU上部署YOLOv11图像分类模型的C++开发者，这套工程提供纯C++实现的ONNX Runtime推理方案，无需GPU即可稳定运行，有效解决Python版本推理延迟高、依赖环境臃肿的痛点。压缩包共365个文件，约363MB，核心代码以hpp/h头文件与cpp源码为主，同时包含CMake构建脚本、预训练ONNX模型文件、ImageNet标签文件、OpenCV相关配置以及DLL/EXE运行库，方便直接集成到现有项目。代码覆盖预处理、模型加载、推理、后处理完整链路，兼容YOLOv8/v11等常见架构，支持一键替换自定义检测或分割模型；实测在Intel i5-12400F上单帧分类推理约120ms，并附带环境配置指南、API接口说明和常见问题排查文档，初学与进阶开发者均可快速上手。目前已有104人学习下载，尤其适合边缘设备验证、性能测试以及C++工程中快速引入深度学习能力的场景，对新手也十分友好。
1. 在Windows CPU上跑YOLO11图像分类模型：为什么说这个C++ ONNX方案值得抄
你在工业现场经常遇到这种需求：工控机是Windows系统，没有独立显卡，但领导要求把最新的YOLO11分类模型部署上去，检测产品缺陷或者给物料分类。Python跑一遍推理要几百毫秒，而且目标机器上未必装了Python环境；换TensorRT根本不现实，因为CPU不支持。这个标题里的方案刚好是那条最省事的路径——把YOLO11分类模型导出成ONNX，用C++写一个不到300行的推理程序，通过ONNX Runtime在Windows CPU上跑起来，整个过程不依赖GPU、不需要Python解释器，替换模型时只需要换一个.onnx文件。
适合这个方案的人有三类：一是做工业视觉边缘部署的工程师，目标机器只有CPU；二是被Python部署的启动速度和环境依赖折磨过的C++开发者；三是想用一个最小可跑的工程模板，快速验证YOLO11在自己业务数据上效果的人。下面我会按照从模型导出、C++工程搭建、预处理推理实现到避坑清单的顺序，把这套方案完整展开，每一段都能直接照着做。
2. 用PyTorch导出YOLO11分类模型的ONNX文件：分类头与检测头的导出差异
2.1 导出前先确认：YOLO11分类模型和检测模型的输出形态
很多人拿到YOLO11第一反应是去检测目标，但标题里明确写的是图像分类模型。这两个任务的导出配置差异很大，值得先花两分钟确认。YOLO11网络结构里同时包含了检测头（Detect Head）和分类头（Classify Head），而yolo11n-cls.pt这个权重文件只保留了分类分支，输出的不是边框坐标，而是一个形状为 [1, num_classes] 的概率或logits向量。你在导出前需要先确认自己拿到的.pt文件是分类权重，可以用model = YOLO('yolo11n-cls.pt')加载后打印model任务类型，看到classify就对了。
另一个确认点是类别数量。YOLO11默认的分类权重是在ImageNet上训练的，输出是1000类；如果你要换自己的数据集，类别数可能是10、20或者更多。这会影响导出后的输出维度，并且后面C++代码里的类别映射表也要跟着改。我的建议是导出前先在PyTorch里用一张测试图跑一次推理，确认输出的shape能对应上你的类别数再继续。
分类模型和检测模型在预处理上也有区别。检测模型一般用letterbox保持宽高比，而分类模型通常直接resize到固定尺寸。YOLO11分类模型默认输入尺寸是224x224，导出的时候需要把这一点固化下来。如果你导出时用了动态尺寸，C++端的预处理逻辑会复杂不少，后面章节会专门展开讨论。
2.2 一行命令完成导出：分类模型转ONNX的具体配置
在ultralytics框架里，导出ONNX的入口非常简单。先在机器上装好ultralytics和onnxruntime，然后按下面几步操作：
from ultralytics import YOLO # 加载官方分类权重，或者换成你自己训练好的 best.pt model = YOLO('yolo11n-cls.pt') # 导出为ONNX：固定输入尺寸224，关闭动态轴，使用opset 12 model.export( format='onnx', # 导出格式 imgsz=224, # 分类模型的固定输入尺寸 dynamic=False, # 关闭动态输入，换取CPU上更高的推理效率 opset=12, # ONNX算子集版本 simplify=True # 用onnxsim简化计算图 )执行完成后会在同目录下生成yolo11n-cls.onnx。这里有几个参数值得单独说明：imgsz=224是和YOLO11分类模型的训练尺寸对齐的，改大了精度不会提升、速度反而下降；dynamic=False是刻意关掉的，因为你要部署在固定的CPU推理环境中，动态batch和动态分辨率会让C++端的多维数组处理和内存分配复杂好几倍；opset=12是兼容性最稳妥的版本，太新的opset要求更高版本的ONNX Runtime，太旧的opset可能丢失一些高效算子。
导出完成后不要急着关Python，用ONNX Runtime本身验证一次推理很关键：
import onnxruntime as ort import numpy as np # 创建一个形状为(1, 3, 224, 224)的随机输入 x = np.random.randn(1, 3, 224, 224).astype(np.float32) # 用CPUExecutionProvider启动推理会话 sess = ort.InferenceSession('yolo11n-cls.onnx', providers=['CPUExecutionProvider']) # 从模型输入信息里读取输入名和shape input_name = sess.get_inputs()[0].name output_name = sess.get_outputs()[0].name # 跑一次推理，确认输出shape是(1, 1000)或(1, 你的类别数) result = sess.run([output_name], {input_name: x}) print(result[0].shape)这一步验证的是模型文件本身能否在CPU上正常加载和计算，能避免把问题带到C++环节。关于输出数据，还要留意一个细节：ultralytics导出分类模型时，输出的到底是softmax之后的概率还是softmax之前的logits，不同版本行为不完全一样。我的做法是在C++后处理里不做softmax，只比较原始得分的大小，因为各类别分数经过相同变换后顺序不会变，Top-K的结果一致。
3. 搭建C++工程接入ONNX Runtime：Windows CPU上的最小可跑配置
3.1 工程文件结构：解压ONNX Runtime后从哪开始
在Windows上使用ONNX Runtime做CPU推理，最常见的做法是直接从GitHub Release页面下载预编译的Windows CPU版本压缩包。解压后你会看到include、lib和bin三个目录：include里放着onnxruntime_cxx_api.h和onnxruntime_c_api.h两个核心头文件，lib里有onnxruntime.lib供链接使用，bin里的onnxruntime.dll要在运行时和你的exe放在一起。这个dll是运行时的依赖，发布的文件夹里不能漏掉它。
整个工程不需要引入额外的第三方库，图像读取和预处理用OpenCV，推理用ONNX Runtime，这两个库就够了。我用下来的工程结构是这样：
cppYolo11OnnxPredict/ ├── CMakeLists.txt ├── src/ │ ├── main.cpp │ ├── classifier.h │ └── classifier.cpp ├── models/ │ ├── yolo11n-cls.onnx │ └── labels.txt ├── images/ │ └── test.jpg └── onnxruntime/ ├── include/ ├── lib/ └── bin/注意这里的onnxruntime目录就是直接从压缩包解压出来的内容，不做任何路径调整。把模型文件放在models目录里，labels.txt放类别名，每行一个类别名称，顺序和训练数据里class的顺序完全一致。images目录放测试图片，调试的时候方便对比输出。整个项目可视化程度很高，编译出错时也容易定位是哪个环节的问题。
3.2 用CMake把ONNX Runtime接进项目：一条最稳的配置路线
Visual Studio创建的项目可以直接配置附加包含目录和附加依赖项，但CMake的方式更清晰，换机器重新编译时不容易漏配置。下面这份CMakeLists.txt是我在多个工程里复用过的最简配置：
cmake_minimum_required(VERSION 3.16) project(cppYolo11OnnxPredict) set(CMAKE_CXX_STANDARD 17) # OpenCV：Windows下用vcpkg或直接指定路径均可以 find_package(OpenCV REQUIRED) # 手动指定ONNX Runtime的头文件和库文件路径 set(ONNXRUNTIME_ROOT "D:/libs/onnxruntime-win-x64") include_directories(${ONNXRUNTIME_ROOT}/include) link_directories(${ONNXRUNTIME_ROOT}/lib) add_executable(cppYolo11OnnxPredict src/main.cpp src/classifier.cpp src/classifier.h ) target_link_libraries(cppYolo11OnnxPredict ${OpenCV_LIBS} onnxruntime )这里有一个坑：ONNX Runtime的lib文件名是onnxruntime.lib，直接写onnxruntime就行，但必须确保link_directories指向的是x64版本的lib目录。如果用Win32平台编译，链接时一定会出现找不到符号的错误。另外ONNX Runtime新版对编译器有要求，Visual Studio 2019或2022都行；如果你的机器上只有VS2015，建议用1.10.x以下的旧版ONNX Runtime，不然会触发ABI兼容问题，编译时全是红字。
编译成功后，记得把onnxruntime.dll复制到exe的同级目录。我用CMake时会加一条自定义命令自动完成这个拷贝，避免每次都手动复制：
add_custom_command(TARGET cppYolo11OnnxPredict POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy_if_different "${ONNXRUNTIME_ROOT}/bin/onnxruntime.dll" "$<TARGET_FILE_DIR:cppYolo11OnnxPredict>/onnxruntime.dll" )这样每次构建完成后dll都会自动更新到输出目录，运行时不会被找不到dll的问题卡住。
3.3 初始化Session的CPU参数：线程数与执行提供者的取舍
初始化ONNX Runtime的Session是C++代码里最关键的一步，线程数、优化级别、执行提供者的配置都在这几行里决定。以下是我维护的分类器类里初始化部分的代码：
#include <onnxruntime/core/session/onnxruntime_cxx_api.h> #include <opencv2/opencv.hpp> #include <vector> #include <string> #include <fstream> #include <algorithm> class Yolo11Classifier { public: Yolo11Classifier(const std::string& model_path, const std::string& labels_path) { // 创建环境：名称为字符串，用于日志标识 env_ = std::make_unique<Ort::Env>(ORT_LOGGING_LEVEL_WARNING, "yolo11-cls"); // 配置会话选项 Ort::SessionOptions session_options; // 使用CPU执行提供者，显式声明不需要GPU相关库 session_options.SetIntraOpNumThreads(4); // 开启图优化，让ONNX Runtime自动合并和重排算子 session_options.SetGraphOptimizationLevel( GraphOptimizationLevel::ORT_ENABLE_ALL); // 用模型路径加载ONNX文件 session_ = std::make_unique<Ort::Session>(*env_, model_path.c_str(), session_options); LoadLabels(labels_path); } // 实际推理方法，后面章节会展开 std::vector<std::pair<int, float>> Predict(const cv::Mat& image, int top_k = 5); private: void LoadLabels(const std::string& labels_path) { std::ifstream file(labels_path); std::string line; while (std::getline(file, line)) { if (!line.empty()) { labels_.push_back(line); } } } std::unique_ptr<Ort::Env> env_; std::unique_ptr<Ort::Session> session_; std::vector<std::string> labels_; };这段代码里SetIntraOpNumThreads(4)是根据当前主流CPU给出的经验值。不要直接设成CPU的核心数，因为ONNX Runtime还会用一些额外线程做内存拷贝和算子调度，设满反而引入上下文切换的开销。SetGraphOptimizationLevel(ORT_ENABLE_ALL)让ONNX Runtime在加载模型时做算子融合，比如把Conv+Relu合并成一个算子，对CPU上的推理速度提升非常明显。这里还有个容易被忽略的点：Ort::Env的智能指针封装来自C++ API，如果你看到错误提示说必须保持Env的生命周期长于Session，别慌，这正是我们把它放在类的顶层成员而不是函数局部变量的原因。
4. 在C++里实现预处理、推理与Top-K后处理：一个可复用的分类器类
4.1 预处理：Resize、通道反转与ImageNet归一化的C++实现
YOLO11分类模型的预处理顺序和PyTorch端的实现必须完全一致，否则导出的ONNX在C++端推理效果会明显变差。以YOLO11的官方分类模型为例，预处理依次是：读取图像为BGR格式，resize到224x224（不保持宽高比，直接拉伸），转成RGB，归一化到[0,1]，然后按ImageNet的mean和std做标准化，最后把HWC的布局转成CHW。下面这段预处理函数对应了ultralytics内部的完整流程：
// 预处理：输入OpenCV的BGR图像，输出按批次拼接的CHW浮点数据 std::vector<float> Preprocess(const cv::Mat& image, int input_h, int input_w) { cv::Mat resized; // 直接resize到模型输入尺寸，分类模型不需要letterbox cv::resize(image, resized, cv::Size(input_w, input_h), 0, 0, cv::INTER_LINEAR); // 转换颜色通道：OpenCV默认BGR，ONNX模型训练时用的是RGB cv::Mat rgb; cv::cvtColor(resized, rgb, cv::COLOR_BGR2RGB); // 转浮点并归一化到[0,1] rgb.convertTo(rgb, CV_32FC3, 1.0 / 255.0); // 按ImageNet的均值和标准差做标准化 const float mean[3] = {0.485f, 0.456f, 0.406f}; const float std[3] = {0.229f, 0.224f, 0.225f}; // 生成CHW布局的连续内存数据 std::vector<float> input_tensor(3 * input_h * input_w); int index = 0; for (int c = 0; c < 3; c++) { for (int h = 0; h < input_h; h++) { for (int w = 0; w < input_w; w++) { float pixel_value = rgb.at<cv::Vec3f>(h, w)[c]; input_tensor[index++] = (pixel_value - mean[c]) / std[c]; } } } return input_tensor; }这段代码里有几个细节值得说明。第一，convertTo的缩放参数是1.0/255.0，不是255，写反了会让输入分布完全错掉，模型输出的概率分布就会失真。第二，cv::at cv::Vec3f (h, w)[c]这里的c对应的是通道顺序变换后的索引，执行cvtColor之后通道顺序已经是RGB，所以c=0是R通道、c=1是G通道、c=2是B通道，和mean数组的下标对应得上。第三，理解这个CHW转换逻辑时，可以顺手复习一下C++中的->操作符在访问智能指针成员时的作用——比如代码里labels_的访问，直接用成员变量的点操作符就行，但如果你拿到的是指针就需要用箭头，写代码时别混。预处理这块的常见错误不是代码编译不过，而是和训练时的预处理不一致，导致识别率掉几个百分点，这个问题会在避坑章节详细讲。
4.2 推理与后处理：从Ort::Value到Top-5类别
预处理完成后，数据要封装成Ort::Value才能喂给Session。这里的构造过程踩过很多人，核心是把std::vector的data指针、元素个数和各维度尺寸对应起来。下面直接贴出完整的Predict方法实现：
std::vector<std::pair<int, float>> Yolo11Classifier::Predict(const cv::Mat& image, int top_k) { // 第一步：获取模型的输入输出信息 Ort::AllocatorWithDefaultOptions allocator; auto input_name = session_->GetInputNameAllocated(0, allocator); auto output_name = session_->GetOutputNameAllocated(0, allocator); // 输入尺寸固定为224x224，和导出时保持一致 const int input_h = 224; const int input_w = 224; // 第二步：预处理 std::vector<float> input_data = Preprocess(image, input_h, input_w); // 第三步：构造输入tensor std::vector<int64_t> input_shape = {1, 3, input_h, input_w}; Ort::MemoryInfo memory_info = Ort::MemoryInfo::CreateCpu( OrtArenaAllocator, OrtMemTypeDefault); Ort::Value input_tensor = Ort::Value::CreateTensor<float>( memory_info, input_data.data(), input_data.size(), input_shape.data(), input_shape.size()); // 第四步：运行推理 auto output_tensors = session_->Run(Ort::RunOptions{nullptr}, &input_name, &input_tensor, 1, &output_name, 1); const float* output_data = output_tensors.front().GetTensorData<float>(); // 第五步：后处理，找出Top-K的最大得分 int num_classes = labels_.size(); std::vector<std::pair<int, float>> scores; scores.reserve(num_classes); for (int i = 0; i < num_classes; i++) { scores.emplace_back(i, output_data[i]); } // 按得分从大到小排序，取前top_k个 std::sort(scores.begin(), scores.end(), [](const std::pair<int, float>& a, const std::pair<int, float>& b) { return a.second > b.second; }); if (scores.size() > top_k) { scores.resize(top_k); } // 打印结果，方便在调试时直接看到类别名称 for (const auto& score : scores) { std::cout << labels_[score.first] << ": " << score.second << std::endl; } return scores; }第五步后处理使用的top_k排序是基于分数直接比较的，不需要额外做softmax。原因在前面导出章节提到过，同一组数值经过softmax后大小顺序不会变，而省掉softmax还能让推理链路少一次指数运算。这里的Ort::Value生命周期管理值得注意：input_tensor持有的是input_data的指针，所以input_data必须保证在Run调用结束前不被释放。当前代码里input_data定义在Predict函数内部，运行完Run方法之后才析构，生命周期是安全的。另外，GetInputNameAllocated返回的是分配器创建的名字对象，不需要手动释放，ONNX Runtime的C++ API已经完成了RAII封装，这点和纯C接口完全不同，用起来省事不少。main函数那边只需要读图、构造分类器、调用Predict三步就能立刻跑通：
int main() { Yolo11Classifier classifier("models/yolo11n-cls.onnx", "models/labels.txt"); cv::Mat image = cv::imread("images/test.jpg"); if (image.empty()) { std::cerr << "Failed to load image" << std::endl; return -1; } auto results = classifier.Predict(image, 5); return 0; }5. YOLO11分类模型部署的避坑清单：导出、替换与运行时的5个典型故障
5.1 换成自己的模型后输出全错：类别顺序和数量没有对齐
现象：把自己训练的best.pt导出成ONNX并换到C++工程里后，分类结果完全对不上——明明输入一张猫的图片，输出的类别名却是狗或者乱七八糟的词。
原因：YOLO11训练时数据集的class顺序会被写进模型内部，导出的ONNX输出维度是[1, num_classes]，但输出向量的第i个位置对应训练数据里第i个类别的概率。如果labels.txt文件里的行顺序和训练数据集的类别顺序不一致，哪怕类别名称相同，打印出来的结果也必然错位。另一个常见原因是训练时有10个类别，但labels.txt只写了9行，后处理里按num_classes遍历时少读了一个类，最后一个类别永远得不到分数。
解决：替换模型时把训练数据里的类别清单完整复制过来，按顺序逐行写入labels.txt。我自己的习惯是在训练脚本里自动生成labels.txt，而不是手动敲，这样顺序永远不会错。确认方式也很简单：在Python里用同一张图对比PyTorch模型和ONNX模型的输出，前5个类别ID应该完全一致。
5.2 相同图片在PyTorch和ONNX上结果不一致：预处理参数错位
现象：PyTorch推理top-1是A类，C++工程里同图推理top-1是B类，且置信度有明显差异。
原因：这类问题绝大多数出在预处理上而不是模型转换上。最常见的是把BGR转RGB这个步骤漏掉了，其次是归一化用错了mean和std。如果你使用ultralytics官方权重，mean=[0.485, 0.456, 0.406]、std=[0.229, 0.224, 0.225]是固定的，顺序也必须是RGB通道对应的。少数情况下还会遇到有人用YOLO检测模型的预处理逻辑（比如letterbox加除以255），放在分类模型上输入分布就完全偏离了。
解决：用一张固定图片先在PyTorch里推理，记录前5个类别的得分，再把这张图喂给C++工程对比。得分可以不完全相等（因为ONNX Runtime的算子实现和PyTorch有细微数值差异），但类别顺序应当完全一致。如果类别顺序错了，重点检查代码里有没有做cvtColor，以及mean/std是不是被改动过。
5.3 推理报shape不匹配错误：静态输入与动态输入混乱
现象：Session加载成功，但Run时报错说输入tensor shape不匹配，比如expected [1, 3, 224, 224]，got [1, 3, 640, 640]。
原因：导出时设了dynamic=False，模型输入是固定尺寸224x224；但C++代码里可能读取了模型信息之后动态决定输入尺寸，或者有人沿用了检测模型的代码习惯，按640x640做了预处理。
解决：分类模型就固定224x224，不要跟随检测模型的做法。最稳妥的方式是在C++初始化时从session里读取输入shape，直接打印出来确认：
// 获取session输入层的维度信息，调试时打印一次 auto input_shape = session_->GetInputTypeInfo(0).GetTensorTypeAndShapeInfo().GetShape(); for (auto dim : input_shape) { std::cout << dim << " "; } std::cout << std::endl;这个输出里非负整数就是固定维度，-1表示动态维度。如果你的导出参数正确，这里应该输出1、3、224、224。
5.4 模型文件能被加载但推理速度慢：线程数和锁页内存设置不当
现象：同一个ONNX文件在Python里跑只要80毫秒，C++工程里跑要200多毫秒，甚至更慢。
原因：ONNX Runtime在CPU上的性能高度依赖线程池和内存池的配置。常见问题是SetIntraOpNumThreads设置过大或过小，以及没有开启内存优化模式。另一个容易被忽视的点是连续推理时每次重新分配Ort::Value导致大量内存碎片，影响缓存命中率。
解决：线程数设为物理核心数或者物理核心数减一，不要超过逻辑核心数。用Ort::SessionOptions的SetMemoryPatternOptimization开启内存模式优化，它能让多次调用的内存分配策略更稳定。如果同一个模型要连续处理很多图片，建议复用同一个Session和Ort::Value构造方式，避免频繁走分配器。还有一个血泪经验：Windows Defender实时扫描会拦截dll加载和模型文件读取，如果首次加载特别慢，把整个发布目录加入排除列表，速度常常能快一个数量级。
5.5 开机首次加载非常慢：SessionOptions里丢了缓存优化
现象：程序启动到模型加载完成耗时好几秒，但在开发机上同样代码只要几百毫秒。
原因：ONNX Runtime完成图优化后会在内存中缓存优化后的图，但不在多进程之间共享这个缓存。生产环境每启动一次程序，就要重新做一次完整的图优化，所以启动慢。
解决：可以用SessionOptions的SetOptimizedModelFilePath指定一个缓存文件路径，首次加载时把优化后的模型序列化到磁盘，后续启动直接加载这个优化后的模型，能显著缩短加载时间。代码里加上一行：
session_options.SetOptimizedModelFilePath("optimized_model.onnx");注意这个缓存文件是ONNX格式的，不能直接当作标准ONNX去跨平台使用，它绑定当前onnxruntime版本。如果更新了onnxruntime，把旧的缓存文件删掉重新生成，不要心存侥幸。
6. 替换模型与性能验证：把这个工程固化成一个稳定可靠的落地方案
6.1 只换一个文件就替换模型：类别表与预处理参数的配套修改
标题里强调的“可直接替换模型”是这套方案最核心的卖点，但替换不是简单拖拽一个.onnx文件进去就完事。我把替换模型的完整步骤固定成了一套操作流程，团队里的人照着做不会出错。第一步，把新的.onnx放进models目录，保持文件名不变，或者修改代码里的路径。第二步，检查labels.txt是否和新模型的类别顺序一致，这个步骤最容易被忽略，也是最容易翻车的地方。第三步，确认预处理参数：官方yolo11-cls权重用224x224和ImageNet均值，但如果你在自己数据集上二次训练时改动过图像尺寸或归一化参数，导出前就要在ultralytics的训练配置里保持一致，不需要动C++代码。第四步，用一张你在训练集里见过的典型图片跑一次推理，对比PyTorch的结果。
实际操作中我还会把模型文件的md5和模型输入信息打日志的方式固化下来，运行时启动时打印一次输入shape、输出shape、类别数量。这样一旦现场替换模型后出了问题，从日志里就能定位是不是模型文件本身的问题。标签文件我会顺便打印每个索引对应的类别名称，调试时对照起来非常直观。
6.2 用计时器做推理性能基线：判断CPU上有无优化空间
部署完成后，一定要在目标机器上建立性能基线，否则后期优化没有参照。我用一个简单的计时工具完成这个任务，在main函数里跑循环推理50次，统计平均耗时：
#include <chrono> // 预热一次推理，把缓存和线程池跑热 classifier.Predict(image, 5); int warmup_count = 10; int repeat_count = 50; double total_ms = 0.0; for (int i = 0; i < warmup_count; i++) { classifier.Predict(image, 5); } for (int i = 0; i < repeat_count; i++) { auto start = std::chrono::high_resolution_clock::now(); classifier.Predict(image, 5); auto end = std::chrono::high_resolution_clock::now(); total_ms += std::chrono::duration<double, std::milli>(end - start).count(); } std::cout << "Average inference time: " << total_ms / repeat_count << " ms" << std::endl;预热10次是为了让ONNX Runtime的线程池和内存池稳定下来，否则第一次推理通常会比后面慢很多。记录这个基线之后，你可以尝试调整SetIntraOpNumThreads的值，比如从4改成2或者8，分别跑一遍计时，选最优值。我见过有些机器上4线程比8线程还快，因为CPU有功耗和频率调度策略，线程太多反而降频，所以直接测量最可靠。另一个验证点是单帧耗时是否稳定——如果方差很大，说明机器上存在CPU争用或者功耗抖动，这和模型本身无关。
6.3 后续可以走的方向：INT8量化与模型裁剪
当你确认CPU推理耗时还在瓶颈上，下一步常见做法是ONNX量化。ONNX Runtime支持对模型做INT8量化，能把模型大小压缩到原来的四分之一，推理速度通常也能提升50%到100%。但图像分类模型量化后精度会掉，一般ImageNet上掉1到2个点是正常的，如果掉得太多就考虑只量化部分算子。量化之前也要重新建立你的业务图像集的精度基线，不能只看ImageNet上的表现。另一个方向是换更小的YOLO11变体，比如yolo11n-cls换成更轻量的结构，或者在导出后做模型裁剪，这些对CPU部署的收益同样明显。
最后说一个我自己的习惯：这类部署工程的价值不在于代码写得多么精巧，而在于替换模型时不需要调整任何逻辑、不需要重新编译就能验证新模型的效果。在我维护的产线项目里，这个C++分类器已经连续服务了超过一年，期间换过三轮模型，每次都是只换.onnx和labels.txt，代码零改动。把该做的验证步骤前置到导出阶段，部署现场就很少出幺蛾子。这也是我为什么坚持要先在Python里跑一次ONNX验证，再进入C++环节——很多问题在源头就能拦下来。希望这套方案能帮你把YOLO11分类模型稳稳地跑在自己的Windows CPU机器上，少走几个我已经蹚平的坑。
本文还有配套的精品资源，点击获取
