1. 项目缘起模型在云端跑得欢端侧掉链子1.1 之前吃过的部署亏我最早接触模型优化纯粹是被线上问题逼的。团队做了一个智能问答系统服务端推理用的是BERT-base单条请求GPU上只要二十多毫秒看着一切正常。但后来业务要往边缘设备上端侧部署要求模型跑在CPU上、内存占用压到500MB以内、单次推理控制在两秒内。我信心满满地把原模型直接转成ONNX丢上板子结果单次推理跑了快八秒内存峰值直接干到1.2GB。那一刻我才意识到训练阶段只要精度、不看开销的模型到了部署阶段会被硬件条件狠狠教育。后来在朋友圈子里聊了一圈发现这不是我一个人的问题。很多算法工程师都会遇到类似的尴尬模型在GPU集群上精调得漂漂亮亮真正落到用户的手机、工控机、边缘盒子上却跑不动。剪枝、量化、蒸馏这些词大家都能说几句但谁也不敢真的上手因为怕精度掉得太狠收不回来。1.2 从“优化一个模型”到“沉淀一套工具”一开始我只是针对那一个BERT模型做加速手工剪掉一些注意力头再用ONNX Runtime跑INT8量化折腾了两周总算达到了部署指标。但紧接着第二个、第三个模型也提了同样的需求我发现自己一直在重复劳动同样的敏感度分析、同样的模型转换、同样的校准数据准备每来一个模型就要把脚本重写一遍。所以我决定把流程沉淀成一个内部工具起名Model-Optimizer。这个工具的目标很明确输入一个训练好的PyTorch或TensorFlow模型输出一个适合端侧推理的轻量化模型同时在优化过程中把每一层精度损失记录成报告方便我判断到底哪个环节把模型改坏了。项目正文、摘要描述在最初整理时几乎是空的但整个开发链路和踩坑记录是真的我把它们补全分享出来给同样做模型部署的人当个参考。2. Model-Optimizer整体设计先定边界再谈性能2.1 工具链的四大模块Model-Optimizer的架构并不复杂我刻意没有搞成一个大而全的框架而是拆成四个可以独立调用的模块pruner负责结构化剪枝和非结构化稀疏化输出剪枝后的模型结构和对应的精度报告。quantizer负责PTQ和QAT两种量化路径封装了校准数据加载、量化参数分析和敏感层保护逻辑。distiller负责知识蒸馏支持软标签蒸馏和中间特征蒸馏两种模式。graph_optimizer负责计算图层面的优化包括算子融合、常量折叠、无用节点消除等。每个模块都由一个Python入口调用输入模型统一转成torch.fx.GraphModule或onnx.ModelProto两种中间表示。之所以定这个边界是因为我不想把工具跟某个推理后端绑死。PyTorch模型先用FX做符号跟踪转换成图结构如果是TensorFlow模型先转ONNX再导入同一套处理链路。2.2 为什么不用现成的NNCF和OpenVINO当时市面上其实已经有OpenVINO的NNCF、TensorRT的Model Optimizer、Intel的Neural Compressor等工具我也都评估过。NNCF的压缩算法很全面但跟Inte