1. 先看看 ST 的 Model Zoo 里到底有什么1.1 官方主线SAM、SAM 2、SAM 2.1先说清一个前提。标题里的 ST我理解就是 Segment Anything 这一大家族——从 Meta 发布 SAM 开始到现在 SAM 2、SAM 2.1再到社区里长出来的一堆变体整个生态已经膨胀得不像一个“模型库”更像一片森林。官方仓库里挂着 ViT-B、ViT-L、ViT-H 三档权重ViT-H 那个 checkpoint 解压出来几个 GB 级别显存小一点的卡加载都费劲。SAM 2 又把单图分割升级成视频流式分割带上了 memory 机制权重规模也没有变小。但官方模型只是这座 Model Zoo 的地基真正让它变得“看起来什么都有”的是社区里爆发式出现的衍生模型。MobileSAM 把 image encoder 换成轻量结构整体 checkpoint 缩小到几十 MB 量级FastSAM 直接拿 YOLOv8-seg 做底子走的是实例分割路线速度比原版快一截EfficientSAM 用 MAE 预训练和蒸馏思路在相似精度下把模型又压缩了一轮。还有面向医疗影像的 MedSAM、SAM-Med2D面向遥感场景的各种 fine-tune 版本几乎每个细分方向都能翻出对应的权重文件。1.2 衍生模型的爆发MobileSAM、FastSAM、EfficientSAM 为什么会出现如果只看 Model Zoo 的丰富程度确实会有一种“还需要自己设计模型吗”的错觉。但把时间线拉长看这些衍生模型本身就是“自研”的结果。MobileSAM 的作者并没有简单地把 SAM 原样打包而是重新设计了一个耦合更松散的 encoder-decoder 结构然后用蒸馏把大模型的知识迁移到小模型里。FastSAM 更是彻底换了一条技术路线把分割任务重新建模成实例分割的检测问题。换句话说Model Zoo 里多出来的这些变体不是官方施舍的而是大量团队在真实项目里被原版模型的体积、延迟、部署成本逼到墙角之后自己动手改出来的。它们被放回 Zoo 里成了后人的“免费午餐”但生产这些模型的团队没有一个是靠“从 Zoo 里挑一个”完成任务的。1.3 Model Zoo 的本质是社区分工不是“裁判已定”所以我对 Model Zoo 的理解是它更像一个开源社区的分工成果而不是一套标准答案。它解决的是“通用场景下已经有人把路趟平了”的问题让你不需要从零训练一个能在自然图片上分割一切的大模型。但它没有解决你的专属问题——你的数据分布、你的延迟预算、你的部署硬件、你的标签体系都不可能和原版模型的训练环境完全一致。想明白这一点就不会被“Zoo 很大”这件事唬住。Zoo 再大也只是别人解题过程的结果你需要不需要自己做模型取决于你手里的题跟别人解过的题重不重合。2. 三个让我放弃“拿来即用”的真实场景2.1 延迟指标从实验室到产线差了多少个数量级我在 2023 年底接过一个工业质检项目需求是在产线上实时分割产品表面的缺陷区域。同事最开始的想法非常朴素SAM 这么强直接用呗。我们当时在一张 V100 上跑原版 SAM 的 ViT-H 权重输入 1024x1024 的图单张推理大概三百毫秒上下。听起来不算慢但产线要求单帧处理是四十毫秒以内这还不算前置预处理和后端判定逻辑。三百毫秒到四十毫秒不是一个量级的差距是接近一个数量级的差距。而且产线端根本不可能放一张 V100现场是边缘盒子算力更弱。原版 SAM 在这个项目里连“验证可行性”这一步都没通过不是精度不行是延迟根本撑不住。类似的情况我估计很多人也遇到过实验室里跑通 demo 很兴奋一算线上的硬指标立刻冷静。2.2 域偏移通用模型在特定数据上的“失明”延迟是第一道坎第二道坎是精度。通用分割模型在自然图像上确实强但你的数据往往不是自然图像。当时我们把 SAM 放到 PCB 焊点图上做点选 prompt 测试发现两个问题一是边界预测经常把焊盘和背景混在一起二是对微小缺陷目标模型的 mask 稳定性很差有时同一个点选位置换张光照略有变化的图输出的 mask 就差得离谱。医学影像方向的朋友也跟我吐槽过类似情况CT 图像里 SAM 能切出器官轮廓但对病灶区域的细粒度边界基本靠不住。原因不复杂预训练数据里这种低对比度、小目标、纹理重复的工业或医学图像占了很小的比例模型学到的特征分布跟你的实际数据分布之间有一道隐形的墙。这时你再怎么调 prompt 都是扬汤止沸问题出在模型容量和预训练分布上不在推理策略上。2.3 部署环境的显存、算力和模型体积硬约束第三个场景更直接客户环境根本不支持。边缘设备比如 Jetson Orin 或者 RK3588 这类盒子内存和算力都是按兆来算的。原版 SAM 的 ViT-H 权重就别提了连 MobileSAM 这种轻量模型想跑满帧率也需要做量化。更常见的是纯 CPU 环境或者老旧的工控机你给他一个三百兆的模型他现场存储都不一定够。我见过一个项目客户要求模型文件不能超过 10MB推理必须在 CPU 上做到单张 100ms 以内。这种情况下Model Zoo 里根本没有现成选项MobileSAM 也得再压一刀FastSAM 的参数量也不达标。说白了Model Zoo 的丰富是基于“还有一块像样的 GPU”这个隐含前提的真实交付场景里这个前提经常不成立。3. 自研模型之前先回答这五个问题3.1 任务是“分割”还是“判断分割结果属于哪一类”很多人把“用不用自研”想复杂了其实先看任务性质就够了。SAM 这个家族本质上只做一件事把目标轮廓切出来它不告诉你切出来的东西是什么。如果你的业务只需要“把前景和背景分开”比如抠图、目标提取那现成模型完全够用。但工业质检、医学诊断这类场景真正困难的是“这个缺陷属于哪一类、严不严重、要不要停机”。你需要的不只是一个 mask还需要在 mask 的基础上做分类、分级。这时候单一分割模型完成不了闭环要么你在它后面接分类器要么你设计一个带语义标签头的分割网络。后者就是“自研设计”的一种——不一定是重头训练一个几十亿参数的大模型而是针对任务重新组织结构。3.2 数据集规模与标注质量第二个问题是数据。自研模型的底气来自数据不是来自灵感。如果你的业务场景能攒到几万张高质量标注图每一张都有精确的 mask 和类别标签那自研一个轻量分割模型完全有戏。如果手里只有一两千张图标注还比较毛糙那别说自研连微调都得小心过拟合。我自己的经验是低于五千张图轻易不要走全量训练路线优先考虑从预训练模型出发做微调或者蒸馏。数据量不是唯一的约束数据的多样性更关键。工业场景里可能 90% 的样本是良品缺陷样本稀稀拉拉分布在几十个类别里这种长尾极不均衡的数据做自研之前一定要把数据增强和类别权重方案先想清楚。3.3 实时性、功耗和边缘部署指标第三个问题是部署指标必须前置。我建议在项目立项时就把延迟、内存、模型体积、硬件平台这几个数字写在文档里后面所有模型选型都对着数字来。如果数字是“单帧 30ms 以内、模型 20MB 以内、Jetson 平台、INT8 可用”那你基本已经知道答案了现成 Model Zoo 大概率没有完全符合的选项需要在轻量模型基础上做蒸馏、剪枝、量化中的至少两步。很多团队把部署优化放到训练完之后才考虑这是最容易翻车的顺序。等模型训完了发现跑不动再回头做结构改造等于白训一轮。我在后面第五节会展开讲判断法则这里先强调一句部署约束必须在选型之前就摆上桌。3.4 迭代节奏与团队能力第四个问题偏组织层面你打算只交付一次还是要长期迭代如果是一次性交付且场景和预训练分布足够接近直接用 Model Zoo 是性价比之王。但很多真实项目不是一次性的产品功能每两个月就加一个需求今天分割缺陷明天分割字符后天又要分割纹理异常。这时候团队如果完全没有“改造模型”的能力每一次新需求都得去 Zoo 里重新找一遍找到了再测测不通就卡住。反之团队有自研能力的话新需求来了可以快速判断“该微调还是该改结构”整个迭代节奏完全不一样。我甚至觉得队长愿不愿意投算法人力这个问题的答案比任何技术指标都重要。3.5 三条路的成本对比表把上面的问题浓缩成一张决策表方便对照方案适用前提时间成本算力成本主要风险直接用 Model Zoo通用场景、延迟不敏感、无需私有标签最低几天内出结果基本为零推理即可边界不可控、域偏移、延迟不达标基于 Zoo 微调/蒸馏有一定数据、域偏移可接受、部署端中等中一到两周单卡即可靠显存吃饭灾难性遗忘、过拟合、数据标注噪声自研轻量模型数据充足、任务独特、部署硬指标严格高两到四周起需要迭代实验多轮但可控训练不稳定、结构调整周期长、团队门槛高这张表不是绝对的但它能帮你把“要不要自研”从情绪问题变成一个资源分配问题。大多数情况下答案不是“要”或“不要”而是“走到哪一步需要自己动手”。4. 从“用 Zoo”到“改模型”一次工业级轻量分割的完整复盘4.1 预研基线先把现成模型跑一遍拿我自己最近做的一个纺织表面瑕疵分割项目来举例吧这个流程基本能代表一类典型情况。项目背景是布匹产线上检测破洞、油污、织造瑕疵三类缺陷要求模型文件不超过 8MB单张 512x512 的推理延迟不超过 20ms跑在 RK3588 上。我当时没有直接开训而是先花两天时间做了预研基线。步骤很简单把原版 SAM 和 MobileSAM 分别在我们的数据集上跑了一遍用点选 prompt 的方式记录性能。测下来的结果是惨不忍睹的mIoU 只有 0.4 左右漏检率也很高。原因跟前面说的一样纺织图像纹理太特殊通用模型的特征分布对不上。但这一步非常值钱因为它给了我们一个低起点后面所有模型改进都有了对比对象。4.2 轻量化改造三步走蒸馏、剪枝、结构再设计拿到基线之后我开始设计改造方案。第一步是选教师模型。原版 SAM 太大蒸馏成本高我直接选了 MobileSAM 做教师因为它已经有了一定轻量化能力而且特征对齐起来比大模型容易。第二步是设计学生网络。学生模型没有沿用 MobileSAM 的结构而是换成了一个更简单的卷积编码器加轻量解码器参数预算控制在 3M 左右这样量化后能稳稳压进 8MB。这里有个关键决策不直接用 MobileSAM 微调而是搞蒸馏。原因很简单MobileSAM 的推理延迟在 RK3588 上还是要 30ms 开外达不到客户指标。我必须把模型压得更小只靠微调做不到。蒸馏的 loss 我配了三项像素级 mask 的 BCE、区域的 Dice、以及中间特征的蒸馏 loss。特征蒸馏帮了大忙学生模型的收敛速度肉眼可见地变快。4.3 关键训练细节和三个坑训练过程中的坑我记得最清楚的有三个。第一个是 BatchNorm 在小 batch 下不稳定。刚开始我用单卡、batch size 设成 8每个 batch 里的图像背景差异又大BN 的统计量抖动得很厉害loss 曲线跟心电图似的。后来我把 batch 提到 16并把部分 BN 换成 GroupNorm 才稳住。如果你只有一张卡batch 又上不去建议优先考虑 GroupNorm 或者用更大的图像块做数据采样。第二个是标注噪声。纺织瑕疵的边界本身很模糊标注人员标的 mask 质量波动大模型学完噪声之后边界反而更毛糙。我后来加了一个置信度阈值过滤把训练时预测置信度极低的像素排除在 loss 之外效果立竿见影。第三个是量化掉点。PTQ 量化到 INT8 之后mIoU 直接从 0.85 掉到了 0.82看着不多但产线上误检率会被放大。我被迫换成了 QAT量化感知训练模型精度才稳定回来。这个经历让我形成了一个习惯如果目标平台是边缘盒子训练一开始就把量化误差模拟进去别等到最后再补。4.4 最终效果精度、速度、体积的取舍结果最终交付的模型不到 4MB单张 512 输入在 RK3588 上实测延迟 12ms 左右mIoU 从基线的 0.4 提到了 0.87三类缺陷的分类准确率也到了业务方要求的 95% 以上。这个结果如果只靠从 Model Zoo 里“拿一个模型”是无论如何拿不到的。但如果完全从零设计结构不借助 MobileSAM 的蒸馏知识训练周期至少翻一倍。所以我对这个项目的定义是这不是一次“纯自研”而是一次从 Zoo 出发、逐步走到结构再设计的完整链条。链条的前半段是拿来主义后半段是自研能力缺一不可。5. 我的结论模型可以共用思考模型不能外包5.1 80/20 的判断法则经历了这些项目之后我给自己总结了一个经验法则可以叫 80/20 法则百分之八十的模型选型问题应该从 Model Zoo 出发先跑通、再评估、再决定要不要替换剩下百分之二十当发现 Zoo 里没有任何模型能同时满足精度、延迟和体积三个约束时就必须启动自研或改造。这个法则的核心不是“不要自研”而是“自研要作为第二步再考虑”。很多团队一上来就雄心勃勃要自研模型结果花了一个月训出来的东西还不如直接微调一个 MobileSAM 靠谱。反过来也有些团队被 Model Zoo 宠坏了动辄“等待开源社区新模型”结果项目卡在需求验收上一等就是半年。我个人的取舍是先把 Zoo 里的模型当作免费预研资源用最短的时间找到现实约束下的天花板然后看清天花板和业务需求之间的差距再决定要不要自己动手。换句话说Model Zoo 是标尺不是终点。5.2 真正值钱的“设计”是审题不是画网络图说到“自己设计模型”很多人第一反应是画网络结构图、调 attention 层数、写训练脚本。这些当然重要但我在项目里最大的体会是真正不可外包的能力是“审题”——把业务问题翻译成模型问题的能力。举个例子。纺织瑕疵分割这个项目业务方一开始只告诉我“要把缺陷分割出来”。如果我直接照做可能就陷入通用分割的坑里了。后来我反复跟业务方确认才知道他们真正需要的是“缺陷类别置信度”而且对误检率极其敏感宁可漏检也不愿意停机误报。这两个信息直接改变了模型设计方向我在解码器上加了分类分支并优化了误检率指标而不是单纯追求 mIoU。这种“审题”能力跟 Model Zoo 大不大没有任何关系。Zoo 给你的是工具但怎么选工具、怎么改工具、怎么判断工具适不适合你的问题只能靠你自己想明白。5.3 最后一点个人体会这几年我看过太多团队在两个极端之间摇摆。迷信 Model Zoo 的遇到域偏移就原地打转等着社区更新模型自己的项目进度一拖再拖迷信自研的把别人已经解决过的问题重做一遍复制了一堆轮子最后维护成本爆炸。我自己的心态已经变成把 Model Zoo 当成一个巨大的“他山之石”先看清楚哪些石头能直接用哪些石头需要打磨一下再用哪些石头材质不对、必须自己烧一块。这个过程中最值钱的能力从来不是“自己烧石头”本身而是你在面对项目时能快速判断手里这块石头到底合不合适。模型可以共用思考模型这件事不能外包。