Python模型转ONNX，skl2onnx提升推理速度

本文深入解析了使用skl2onnx将scikit-learn模型转换为ONNX格式的关键实践与常见陷阱：强调模型必须先完成fit才能提供必要元信息（如classes_、feature_names_in_），输入示例X_sample需严格匹配真实推理的shape和dtype，输出应优先通过字段名（如'label'、'probabilities'）而非索引访问以确保语义一致；同时澄清ONNX模型体积显著增大是因参数被展开为常量节点所致，属正常现象，真正影响推理性能的是ONNX Runtime的执行器配置与硬件加速器（如CUDA）选用——转换成功只是起点，类型对齐、输出解析和运行时优化才是落地加速的核心。

skl2onnx 保存 sklearn 模型为 ONNX 的基本流程

skl2onnx 不是把模型“导出”就完事，它本质是把 sklearn 的训练逻辑翻译成 ONNX 的计算图。必须提供一个带类型信息的输入示例（X_sample），否则会报 ValueError: Unable to infer schema。

• 先用 convert_sklearn，传入训练好的模型、模型名（任意字符串）、X_sample（必须是 numpy array，shape 和 dtype 要匹配真实推理输入）
• X_sample 维度不能是空或动态 batch：比如模型实际接收 (1, 4)，你就得给 np.array([[1.0, 2.0, 3.0, 4.0]])，而不是 np.array([1.0, 2.0, 3.0, 4.0])
• 支持的 sklearn 版本和 ONNX opset 有强绑定：skl2onnx 1.15+ 推荐配 ONNX 1.14+ 和 opset=15；用太低的 opset（如 12）可能触发 UnsupportedShapeError

常见报错：AttributeError: 'LogisticRegression' object has no attribute 'classes_'

这是模型没调用 fit() 就直接传给 convert_sklearn——skl2onnx 依赖 classes_、feature_names_in_ 等拟合后属性推导输出结构。哪怕你用 predict_proba，也得先 fit 一次（哪怕只喂一行 dummy 数据）。

• 解决方法：在保存前补一句 model.fit(X_dummy, y_dummy)，其中 X_dummy 形状和真实数据一致，y_dummy 类型匹配（分类任务用 int，回归用 float）
• 注意 y_dummy 必须和训练时一致：比如训练用的是 ['cat', 'dog']，那 y_dummy 得是 np.array(['cat'])，不能是 [0]，否则转换后输出 label 映射错乱
• 如果模型本身不支持 fit（如某些 pipeline 中间步骤），说明它根本不该被单独转 ONNX——得整个 pipeline 一起转，或拆掉该组件

ONNX 推理时 output shape 和 sklearn 不一致？

skl2onnx 默认把 sklearn 的 predict() 输出映射为 ONNX 的第一个 output，但像 RandomForestClassifier 这类模型，ONNX 图里 label 和 probability 是两个独立 output，而 sklearn 的 predict() 只返回 label。如果你只取第一个 output，看起来对，但其实绕过了概率校准逻辑。

• 用 onnxruntime.InferenceSession 加载后，先看 session.get_inputs()[0].shape 和 session.get_outputs() 确认输入 shape 和输出字段名
• 分类模型通常有两个输出：label（int64）和 probabilities（float32，shape=(N, n_classes)）；别硬套 sklearn 的 predict() 返回习惯
• 如果需要和 sklearn 行为完全一致，建议在 ONNX runtime 里显式取 outputs['label'][0]，而不是 outputs[0][0]——字段名比位置更可靠

为什么 ONNX 模型体积比 joblib 大很多？

skl2onnx 把模型参数全部展开成常量节点写进图里，不像 joblib 那样做紧凑序列化。尤其树模型（如 DecisionTreeClassifier）转完 ONNX 后体积可能翻 3–5 倍，不是 bug，是 ONNX 计算图的表达代价。

• 压缩手段有限：可以用 onnx.shape_inference.infer_shapes + onnx.optimizer.optimize（旧版）或 onnxsim.simplify（推荐）做轻量精简，但无法改变底层结构膨胀
• 真正影响推理速度的不是文件大小，而是 ONNX Runtime 是否启用了优化执行器（如 ExecutionMode.ORT_PARALLEL）和 provider（CUDAExecutionProvider 优先于 CPUExecutionProvider）
• 如果部署环境内存紧张，与其纠结 ONNX 体积，不如检查是否真需要把整个 pipeline 转过去——有时只转核心 estimator，前后处理留在 Python 更实际

ONNX 的坑不在“能不能转”，而在“转完怎么用”。类型对齐、output 字段语义、runtime provider 选择，这三处漏掉任何一环，都可能让加速变成减速。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Python模型转ONNX，skl2onnx提升推理速度》文章吧，也可关注golang学习网公众号了解相关技术文章。